Something vexes me .. transaction fee issue.

[theymos]

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.

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.

[1715585848]

1715585848

[Luke-Jr]

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.

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?

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

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.

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

No, it just allows the address-controller to decide which other miner is allowed to 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.

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.

[Luke-Jr]

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

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.

[Jim Hyslop]

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.

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.

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

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:

Code:

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

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.

[theymos]

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.

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

Code:

// 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;

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:

Code:

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

Even the fee-exempt transactions go through this.

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

Code:

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

[Jim Hyslop]

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

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

[gigabytecoin]

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

[error]

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

Bitcoin users are terrorists!

[Garrett Burgwardt]

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

Wow. Please tell me this is sarcasm?

[deadlizard]

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

Bitcoin users are terrorists!

Governments are terrorists

[MoonShadow]

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

Wow. Please tell me this is sarcasm?

Yes, it's sarcasm.

Is English not your first language?

[Garrett Burgwardt]

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

Wow. Please tell me this is sarcasm?

Yes, it's sarcasm.

Is English not your first language?

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.