Bitcoin Forum

It can't be done without major changes to the protocol.

Major changes that would or would not effect currently circulating coins?

I would definitely drop BitCoin for an identical alternative that had this feature. The power to withold my custom from providers I disaprove of, is extremely important to me.

Am I alone here?

You could claim the same moral issue with basically any currency.

When you buy something to someone, you can't know what this person is going to do with the money.  Maybe he's a ganster, a terrorist or a pedophile, and the business you're having with him is just a front or a money laudering scheme.

I'm not sure it can be done at all. Miners are anonymous. It's not even clear what standard you'd need in order to identify a miner .... business papers? Passports? How do you identify somebody you don't want to do business with in a global network anyway?

Today there is no way to prevent your fees going to miners you don't like, if they solve a block with your transaction in it. If that's a showstopper for you, don't use BitCoin.

AFFECT != EFFECT

OMG! Did you know what I was trying to say? .. Then job done! STFU!

Here are my thoughts. As long as both miners and users are concerned enough about this issue, it would actually be possible to do this without changing the protocol. Disclaimer: This runs a bit contrary to the philosophy of Bitcoin, I don't want to promote it, I just want to solve the OP's problem.

So let's say you only want to support miners who run a "green" data center or miners from Spain or whatever. There would have to be a certification authority who confirms the miner actually fulfills whatever the criterion is.

As a user you would have a Bitcoin client that supports adding a certification authority in the options.

When you actually send money to somebody, the client would create a transaction with no fee and instead add the fee as a normal transaction output to the certification authority's Bitcoin address.

Assuming most miners require fees the transaction would most likely be included by a miner who is a member of the certification authority. Those miners would treat the output to the certification authority the same as they would a fee. The authority would forward the fee to whatever miner solved the block that contained the fee. (The authority may keep a percentage for its own costs. Since the payouts would be micro-transactions, perhaps the miners who are members of that certification authority would agree to include them for free.)

If the block gets included by a miner who is not certified by the authority, he will not get anything for it. The fees would still go to the certification authority's address. It could then use some rule to spread those extra fees fairly among its members.

Miners could be members of as many certification authorities as they want as long as they meet the criteria. Users could pick whatever certification authority best represents their interests.

Note that as a user you would put yourself at a disadvantage if you discriminate in this way. Your transactions would take longer to get confirmed. But your money would go only to miners you approve of - that's the tradeoff.

Justmoon is right, it shouldn't be difficult to implement a sort of white-list discrimination. Actually it could be even easier than what you say, you could just send the transaction to the miners you know and trust, not to the entire network.

But this is quite limiting, and it's not exactly what the OP wanted. He wanted a blacklist - allowing everyone a priori, except a few he doesn't like. That I wouldn't know how to do, probably is not possible as others said.

Even so, it depends in the due diligence of the certification authority... Any one of its members could also operate nodes, that are not a part of that system, for any purpose whatever.

Yeah, not just for boycotting but for supporting green miners and such too. I think your idea is great, but I can see that it will burden the network with extra work. I don't fully comprehend how much work it would take to adopt the feature into the protocol.

But considering that BitCoin is still in Beta, would it be totally out of the question? Obviously if I'm the only person who thinks this way then so be it.

I'm also wondering what exactly are you saying runs contrary to the philosophy of BitCoin? My concern, or your particular suggestion? or ?

You can potentially choose a specific miner by sending the fee portion directly to their address. This requires miners merge the myFreeTx branch, and may be a reason to reconsider merging it into mainline. It doesn't help create a multi-miner whitelist, though.

Luke, stop pushing the myFreeTx patch. As I posted the other day, it won't work, and Gavin dropped the pull request. You can read the discussion here: https://github.com/bitcoin/bitcoin/pull/97 (https://github.com/bitcoin/bitcoin/pull/97).

It works together with my policy changes. I also just pushed a fix so it works by itself. Gavin may wish to reconsider it, based on this new use, but regardless of whether it gets merged or not is irrelevant. Bitcoin isn't a monopolistic centralized proprietary software, it's a community of mostly free software, and miners too are free to run whatever code they wish.

It may work, but it doesn't seem to DO anything except keep your transactions from being accepted by any other miner.

It works together with my policy changes. I also just pushed a fix so it works by itself. Gavin may wish to reconsider it, based on this new use, but regardless of whether it gets merged or not is irrelevant. Bitcoin isn't a monopolistic centralized proprietary software, it's a community of mostly free software, and miners too are free to run whatever code they wish.

No, it just allows the address-controller to decide which other miner is allowed to get the fee.

You're right, Bitcoin's not proprietary, and you are free to run whatever code you want. But the problem is, the patch that Gavin submitted violates the established protocol. When you generate a transaction that, according to the established protocol would require a transaction fee, but you do not include that fee in your transaction, no other node will accept that transaction. That's why Gavin withdrew the patch. And as I said in the comments for the patch, the patch isn't necessary anyway. If you happen to generate the transaction, you get the transaction fee back and it's free (for you). If someone else generates it, they get the fee.

I don't understand what you mean by "policy changes." Can you elaborate on that?

I just had a look at github, and I didn't see any pull requests along these lines. Do you have a link?

You're right, Bitcoin's not proprietary, and you are free to run whatever code you want. But the problem is, the patch that Gavin submitted violates the established protocol. When you generate a transaction that, according to the established protocol would require a transaction fee, but you do not include that fee in your transaction, no other node will accept that transaction. That's why Gavin withdrew the patch. And as I said in the comments for the patch, the patch isn't necessary anyway. If you happen to generate the transaction, you get the transaction fee back and it's free (for you). If someone else generates it, they get the fee.

Are we talking about the same patch? I'm referring to the "My free tx" patch submitted by Gavin, and described here: https://github.com/bitcoin/bitcoin/pull/97 (https://github.com/bitcoin/bitcoin/pull/97). That patch does not give you any control over who gets the fee.

It doesn't look like Gavin's change even generated no-fee transactions -- it just accepted them, which is harmless.

It's useful if you expect to generate a block in a reasonable time-frame. Unlike sending a transaction with a fee and hoping to get the fee back, sending a no-fee transaction and including it in your blocks guarantees that you will not have to pay a fee.

It doesn't look like Gavin's change even generated no-fee transactions -- it just accepted them, which is harmless.

    if (vtx[0].GetValueOut() > GetBlockValue(pindex->nHeight, nFees))
        return false;

When the transaction gets included in the miner's block, the patch suppresses adding the transaction fee to pblock->vtx[0].vout[0].nValue. So the miner doesn't claim the transaction fee - but the fee has already been taken out of his wallet. The miner ends up ripping himself off for the transaction fee!! Exactly the opposite of what was intended! Plus, it "leaks" the transaction fee out of the economy. That .05BTC is lost forever.

// Transaction fee required depends on block size
bool fAllowFree = (nBlockSize + nTxSize < 4000 || dPriority > COIN * 144 / 250);
int64 nMinFee = tx.GetMinFee(nBlockSize, fAllowFree);

// If our wallet has a key for one of the outputs >= nMinFee, allow it without a fee
if (tx.IsFromMe() || tx.GetCredit() > nMinFee || mapWallet.count(tx.GetHash()))
nMinFee = 0;

if (!tx.ConnectInputs(txdb, mapTestPoolTmp, CDiskTxPos(1,1,1), pindexPrev, nFees, false, true, nMinFee))
   continue;

pblock->vtx[0].vout[0].nValue = GetBlockValue(pindexPrev->nHeight+1, nFees);

It doesn't do that. It just changes the limit at which a transaction would be accepted.

...The power to withold my custom from providers I disaprove of, is extremely important to me.

Am I alone here?

No. Not at all.

I (and the rest of north america) would instantly refuse (without question) to help fund any group labeled as a "terrorist".

No. Not at all.

I (and the rest of north america) would instantly refuse (without question) to help fund any group labeled as a "terrorist".

Bitcoin users are terrorists!

Wow. Please tell me this is sarcasm?

Yes, it's sarcasm.

Is English not your first language?