Two small free transaction policy changes

gavinandresen commented at 2:15 am on September 18, 2013: contributor

This is part of my quest to eliminate hard-coded fees from the reference implementation.

The first: Remove the rule that all outputs of free transactions must be greater than 0.01 XBT. Dust spam is now taken care of by making dusty outputs non-standard.

I did not change the coin selection algorithm, it will still try to avoid creating outputs less than 0.01 XBT. That could be changed/simplified a release after this rolls out to miners/relay nodes (before then, there is too much risk your free transactions would never confirm).

The second: Changes the maximum size of a free transaction that will be created from 10,000 bytes to 1,000 bytes. The idea behind this change is to make the free transaction area available to a greater number of people; with the default 27K-per-block, just three very-large very-high-priority transactions could fill the space.

I did not change the relay policy for free transactions (yet); you can still send a 26,000 byte zero-fee transaction and it will be relayed and might be mined. This just stops somebody moving a lot of old coins from accidentally monopolizing the free transaction area when they would almost certainly be perfectly happy to pay the fee.

mikehearn commented at 1:17 pm on September 23, 2013: contributor

The free transaction area is still useless because in reality if you create free transactions, you never know when they will confirm. So I don’t see why we even bother keeping the “free area” at all.

petertodd commented at 1:32 pm on September 23, 2013: contributor

Getting rid of free transactions and hence priority would simplify a lot of the codebase - my child-pays-for-parent mempool patch ignored priority for that reason.

mikehearn commented at 1:46 pm on September 23, 2013: contributor

That wasn’t what I meant. Free transactions are good. People like free transactions. But free transactions that are in practice useless and never generated by real-world wallets are bad. They give an easy ride to people doing custom stuff and ordinary users lose out.

It’d be better if there was a single ranking of all transactions that acted as if free transactions had a fee attached equivalent to their days destroyed or something like that. The current system isn’t conceptually wrong, it’s just got this bizarre 27kb limit that in practice makes the entire feature worthless.

petertodd commented at 1:52 pm on September 23, 2013: contributor

@mikehearn Before you try to propose that get some good figures on the marginal cost each KB of transactions costs miners, particularly smaller ones, in terms of increased orphans. I did a rough estimate and came up with IIRC 0.00025 BTC/KB myself.

FWIW that’s exactly what I had in mind with my mempool rewrite for the mining code: a simple priority->BTC conversion ratio and a setting for how many BTC worth of free transactions you were willing to donate per block.

petertodd commented at 2:00 pm on September 23, 2013: contributor

It’s also worth considering that allowing unlimited free transactions is basically saying that owning BTC is a right to use up a certain amount of blockchain space per block indefinitely.

That’s the kind of thing that will give an easy ride to people doing custom, and undesirable, stuff like dumping data and timestamps into the blockchain at the expense of people using Bitcoin as it was intended.

jgarzik commented at 3:04 pm on September 23, 2013: contributor

We are not getting rid of free transactions until blockchain evidence proves it is pointless. e.g. if no non-free transactions are mined in a 3 month period, the code is clearly pointless.

We are nowhere near that point yet.

Miners appear to currently be happy with free transactions, as long as they receive their block reward. It brings new users into the system.

mikehearn commented at 3:20 pm on September 23, 2013: contributor

Currently fees aren’t funding hashpower, we’re a long way from that day, so they act just as an anti-flooding mechanism. Using up coin days is just as good a method for that as using up bitcoins themselves, hence the desire to keep free transactions - it’s a HUGE draw for merchants and a free tx is much simpler for users.

petertodd commented at 4:07 pm on September 23, 2013: contributor

@jgarzik cost-vs-benefit: given how almost all third-party wallets ignore priority in favor of adding minimum fees obviously there isn’t much demand for the feature; while that isn’t a reason to remove the code immediately, it is a reason to not bother re-implementing it in a rewrite. @mikehearn If free transaction was such a huge draw wallets would implement them, but they don’t bother. Secondly using up coin days is not just as good a method, because owning coins give you a steady supply of new coin days.

It’s rather obnoxious that I could, for instance, create a timestamping app that made timestamps for free using whatever high-priority coins you had lying around using a bare/p2sh CHECKMULTISIG txout; individually timestamping every single Bitcoin git commit as they were created would only require a BTC or two.

gmaxwell commented at 4:31 pm on September 23, 2013: contributor

@mikehearn I would agree with what you’re actually saying, except I don’t see how it wouldn’t just result in every block being the maximum size miner’s are willing to create. This size is rationally smaller than the size they’re willing to create full of free stuff because a lot of free stuff is DOS attack cruft (e.g. the millions of correct horse transactions) or just due to the increased orphaning risk @jgarzik He’s not suggesting we get rid of free transactions, he’s suggesting that for the purpose of prioritizing transactions we convert priority into an “equivalent fee” and just have one list and no separate free transaction limit.

jgarzik commented at 4:40 pm on September 23, 2013: contributor

Oh, ok, that’s more reasonable.

Overall the issue will sort itself out once blocks regularly hit 1MB, and a real pricing market emerges. Right now many of our signals are artificial and hardcoded, rather than dynamic and market-driven.

petertodd commented at 4:59 pm on September 23, 2013: contributor

@jgarzik Yup. Converting everything to BTC makes things like artificial priority modifications, perhaps due to an out-of-band fee payment promise or just because the tx one of yours, easier to reason about as well.

Anyway essentially all of this stuff is us saying “We know the technical limits are 1MB/10minutes, but we know there isn’t actually that much genuine blockchain demand yet so we’d rather set artificial limits so we don’t waste our startup capital on spam too soon.” Not to mention that we really want people to get used to the idea that transaction have some kind of cost associated with them, however minor, so apps and business plans aren’t written with bad assumptions baked in.

gavinandresen commented at 7:41 pm on September 23, 2013: contributor

All this talk about free transactions is lovely… … are there any comments relevant to this PARTICULAR baby-step change?

mikehearn commented at 10:56 am on September 24, 2013: contributor

The change is OK as long as you realise it only helps people using Bitcoin-Qt. Other kinds of wallets won’t be generating free transactions even with this modification, because they’ll continue to be too unreliable.

petertodd commented at 5:03 pm on September 24, 2013: contributor

(responding to some concerns I’ve seen elsewhere)

The first commit does make sending small utxo-spamming transactions cheaper, but that’s such a niche case I think simplifying wallet code is more important. (I’ve had tx’s get stuck on testnet at least because I forgot that case while writing wallet code that calculated fees on a per/kb basis)

The other commit will help prevent free tx’s getting stuck, and the overhead added when you’re just cleaning up inputs is insignificant.

ACK

cozz commented at 9:32 pm on September 26, 2013: contributor

Instead of removing the “CENT-output free transaction rule” you may want to consider doing this:

0if (GMF_SEND && nMinFee < nBaseFee)

So only remove for gmf_relay. Otherwise you still have the risk of people creating never confirming free txs. The code could then be removed completely in the future after most people have this new relay rule.

mikehearn commented at 9:12 am on October 4, 2013: contributor

Putting aside the strategy discussions: LGTM, this change looks good to me.

wtogami commented at 9:36 am on October 4, 2013: contributor

I am in agreement with @cozz in that the network needs a way to smoothly transition into this.

petertodd commented at 9:43 am on October 4, 2013: contributor

@wtogami There are very few >1000byte free transactions being created, and nearly only the Bitcoin reference client creates free transactions; the network doesn’t upgrade to new versions overnight giving a transition period anyway.

wtogami commented at 10:17 am on October 4, 2013: contributor

I was thinking about the other removed requirement, > 0.01 BTC, which is very common.

petertodd commented at 10:43 am on October 4, 2013: contributor

@wtogami The wallet doesn’t use GetMinFee() to determine if nMinTxFee must be paid so it’ll continue to create nMinFee-paying transactions when there is a subcent output; see CWallet::CreateTransaction()

Remove CENT-output free transaction rule when relaying

Remove the (relay/mempool) rule that all outputs of free transactions
must be greater than 0.01 XBT. Dust spam is now taken care of by making
dusty outputs non-standard.

ea1cd5b47f

Lower maximum size for free transaction creation

Changes the maximum size of a free transaction that will be created
from 10,000 bytes to 1,000 bytes.

The idea behind this change is to make the free transaction area
available to a greater number of people; with the default 27K-per-block,
just three very-large very-high-priority transactions could fill the space.

16b3ff66e0

gavinandresen commented at 12:11 pm on October 4, 2013: contributor

@cozz : good idea. I updated the first commit with your suggestion, and added comments on two places in the code that can be simplified once the network upgrades. @petertodd : I think you’re confused by the code that avoids creating a free transaction with a change output less than 0.01. The edge case is a user who creates a high-priority transaction (maybe a 10 BTC, well-aged input) with a sub-CENT output (maybe they’re sending 0.001 BTC, so have a 9.999 BTC change output) during the transition period when most of the network hasn’t upgraded to 0.9 yet. The first version of this pull would send that without a fee, and their transaction would likely never confirm.

petertodd commented at 12:17 pm on October 4, 2013: contributor

@gavinandresen Yeah, I think you’re correct there, my mistake.

BitcoinPullTester commented at 1:07 pm on October 4, 2013: none

Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/16b3ff66e0137b68de0d08ad88ce9798bce2d68d for binaries and test log. This test script verifies pulls every time they are updated. It, however, dies sometimes and fails to test properly. If you are waiting on a test, please check timestamps to verify that the test.log is moving at http://jenkins.bluematt.me/pull-tester/current/ Contact BlueMatt on freenode if something looks broken.

gavinandresen referenced this in commit d3b0fa1d82 on Oct 20, 2013

gavinandresen merged this on Oct 20, 2013

gavinandresen closed this on Oct 20, 2013

wtogami commented at 11:50 am on October 22, 2013: contributor

I was surprised that this was merged without any explicit ACK’s. It isn’t necessarily bad, I am just curious why 1KB was chosen as opposed to any other arbitrary size?

wtogami referenced this in commit 8b69377a08 on Oct 24, 2013

wtogami referenced this in commit 23fdcae07d on Oct 25, 2013

wtogami referenced this in commit a41ab59f44 on Oct 27, 2013

wtogami referenced this in commit 7684b23be0 on Oct 27, 2013

wtogami referenced this in commit 649b298487 on Oct 29, 2013

wtogami referenced this in commit b96ec1a29f on Oct 29, 2013

wtogami referenced this in commit 5e9587646d on Nov 2, 2013

gavinandresen deleted the branch on Nov 4, 2013

wtogami referenced this in commit 9bec9feb87 on Nov 23, 2013

wtogami referenced this in commit 70373e4f22 on Nov 23, 2013

laudney referenced this in commit 59111a11a9 on Mar 19, 2014

destenson referenced this in commit 9d10b24d68 on Jun 26, 2016

Bushstar referenced this in commit b9aadc071b on Apr 8, 2020

Bushstar referenced this in commit 321bbf5af4 on Apr 8, 2020

DrahtBot locked this on Sep 8, 2021

Two small free transaction policy changes #3008