Topic: Something vexes me .. transaction fee issue. (Read 4117 times)

Good.

And yes it is, I'm quite good at it - plaintext is just a poor way to transfer complex language nuances like sarcasm.

And I don't put it past quite a few people to say something like that, unfortunately.

Yes, it's sarcasm.

Is English not your first language?

Governments are terrorists

Wow. Please tell me this is sarcasm?

Bitcoin users are terrorists!

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".

Yes, I see now. That's what I get for trying to analyze code late at night.

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


Notice that nMinFee can also be 0 in the first (normal) case when a larger fee is given. The fee is claimed elsewhere:

Each transaction in the block is looped through, and its fee is added to nFees:
Even the fee-exempt transactions go through this.

After all fees are tallied, the amount is added to the generation transaction:

Except that's not what the patch did. It did not change the fee when the transaction was generated, but when it was collected into a block. There were no other changes with Gavin's patch, which means the transaction would be broadcast normally and it would be a race to see who included it in the block first. If someone else did, then they got any fees included in the transaction.


I was going to explain, with references to the code, why it was the opposite, but I realized I misread the check in CBlock::ConnectBlock. I thought it tested that the block fees were exactly correct, but it tests to make sure the miner isn't claiming too much in fees (otherwise a rogue miner could hack the client and give himself 500BTC or 5000BTC per block). Here's the line I misread:

But in any case, the patch is even worse than I originally thought. The patch did not change the transaction creation code, so any fees which would be accrued according to the rules would be baked into the transaction (e.g. if the transaction is 5000 bytes then it would bake in a 5 cent fee). 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.

Now, just so there's no confusion, I'm still talking about the patch submitted by Gavin. And I'm not opposed to the concept, I'm just pointing out that the submitted patch doesn't work as advertised.

Luke-Jr, I haven't had a look at your policy branch and revised code yet, but I will over the weekend.

Just to clarify: 'myFreeTx' is my branch, not Gavin's. He created the pull request for it at my suggestion, because I have been asked numerous times on IRC about that change. I didn't (and won't) create any pull requests on GitHub myself, because their terms of service are draconian and I don't agree to contracts I won't abide by out of principle.

See my 'policy' branch at http://luke.dashjr.org/programs/bitcoin/w/bitcoind/luke-jr.git ; fixed 'myFreeTx' is also there.

Note that these are my personal branches, not necessarily intended or designed for any mainstream use, possibly not even working (eg, IPv6).
Policies are not protocol. There are miners who accept less (or even none, in some cases) fees. You just have to connect your client to the Free transaction relay network to get across the anti-social clients that refuse to relay anything they wouldn't personally accept.

The problem with "simply" collecting your own fee is that someone else can collect it too. Sometimes, you might prefer to WAIT for your own block, rather than MAYBE get the fee if you by unlikely chance generate the next one...

This was in response to the earlier suggestion for a similar patch, but one which treated a known address (not in the miner's wallet) as "fee", trusting the holder of that address to distribute earnings fairly.

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. Since there is currently no way to cancel a transaction that has been sent, and these transactions might never clear, sending one of these transactions is risky, and it shouldn't be enabled by default.

It doesn't violate the protocol. Miners decide what fees to charge, so if you mine a block, you can fill it to 1MB with free transactions if you want.

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

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. That patch does not give you any control over who gets the fee.

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

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

I really like justmoon's solution...it works without absolutely no modification to the bitcoin protocol.  It's elegant and simple.  There might even be a market for mining services that are verified to uphold certain standards of the community.  (but I also agree that it's probably not near to the top of most people's priority lists)

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.

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.

Thanks for everyones input.

I'm no longer vexed. 

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.