Change Details

Free transactions have an interesting history: - The very original bitcoin would allocate a small area of the block template for free transactions (~10 kB) but didn't limit relay at all. - In 2010 a 'free limiter' DoS limit was introduced for the mempool. ( 97ee01ad898b0699c2319a1283313881ef4ba430 ) and a coin age priority limit was introduced ( f35e21e2e4fcc0aa52edd9f9b58bd19e347597da ) - Over time the free limiter was variously adjusted in behaviour, however roughly this idea was respected. - In late 2016 the free relay limit was set to 0 and has been 0 ever since. https://github.com/bitcoin/bitcoin/pull/9179 . Effectively from that point onward (and for the entirety of ABC's history) there have been no useful free transactions since the default node would not propagate them. You could enable them for your node but you would just end up having transactions stuck, unless you were a miner in which case you would just be damaging the reliability of unconfirmed transactions. - There were some remnant bugs related to this off-by-default system, where `sendrawtransaction` (used by light wallets) would sometimes succeed in inserting a free transaction to the mempool, which could not propagate. In D4745 the free limit was removed in order to fix that bug. There were a couple of problems with the free limit implementation: - Effectively after every block was mined, there was a window during which people could try to rush to get free transactions into the mempool. - The free acceptance would be pretty subjective in nature, especially due to the racy nature of people trying to submit at same time. Not a good foundation for unconfirmed transaction reliability. It's possible to reintroduce free transactions, however we don't want it to turn into a subjective race over a limited free area that happens after each block. Most ideally, each transaction's acceptability can be judged independently of the existence of other transactions. Practically we know this is not possible in general (the mempool is limited, so at some point transactions do crowd each other out) but we do want to avoid this when possible. Here we can brainstorm some ideas of what a new free transaction system might look like.

Free transactions have an interesting history: - The very original bitcoin would allocate a small area of the block template for free transactions (~10 kB) but didn't limit relay at all. - In 2010 a 'free limiter' DoS limit was introduced for the mempool. ( 97ee01ad898b0699c2319a1283313881ef4ba430 ) and a coin age priority limit was introduced ( f35e21e2e4fcc0aa52edd9f9b58bd19e347597da ) - Over time the free limiter was variously adjusted in behaviour, however roughly this idea was respected. - In late 2016 the free relay limit was set to 0 and has been 0 ever since. https://github.com/bitcoin/bitcoin/pull/9179 . Effectively from that point onward (and for the entirety of ABC's history) there have been no useful free transactions since the default node would not propagate them. You could enable them for your node but you would just end up having transactions stuck, unless you were a miner in which case you would just be damaging the reliability of unconfirmed transactions. - There were some remnant bugs related to this off-by-default system, where `sendrawtransaction` (used by light wallets) would sometimes succeed in inserting a free transaction to the mempool, which could not propagate. In D4745 the free limit was removed in order to fix that bug. There were a couple of problems with the free limit implementation: - Effectively after every block was mined, there was a window during which people could try to rush to get free transactions into the mempool. It looks like one of the later changes might have reduced this somewhat (free limit became independent of block acceptance). - The free acceptance would be pretty subjective in nature, especially due to the racy nature of people trying to submit at same time. Not a good foundation for unconfirmed transaction reliability. It's possible to reintroduce free transactions, however we don't want it to turn into a subjective race over a limited free area that happens after each block. Most ideally, each transaction's acceptability can be judged independently of the existence of other transactions. Practically we know this is not possible in general (the mempool is limited, so at some point transactions do crowd each other out) but we do want to avoid this when possible. Here we can brainstorm some ideas of what a new free transaction system might look like.

Free transactions have an interesting history: - The very original bitcoin would allocate a small area of the block template for free transactions (~10 kB) but didn't limit relay at all. - In 2010 a 'free limiter' DoS limit was introduced for the mempool. ( 97ee01ad898b0699c2319a1283313881ef4ba430 ) and a coin age priority limit was introduced ( f35e21e2e4fcc0aa52edd9f9b58bd19e347597da ) - Over time the free limiter was variously adjusted in behaviour, however roughly this idea was respected. - In late 2016 the free relay limit was set to 0 and has been 0 ever since. https://github.com/bitcoin/bitcoin/pull/9179 . Effectively from that point onward (and for the entirety of ABC's history) there have been no useful free transactions since the default node would not propagate them. You could enable them for your node but you would just end up having transactions stuck, unless you were a miner in which case you would just be damaging the reliability of unconfirmed transactions. - There were some remnant bugs related to this off-by-default system, where `sendrawtransaction` (used by light wallets) would sometimes succeed in inserting a free transaction to the mempool, which could not propagate. In D4745 the free limit was removed in order to fix that bug. There were a couple of problems with the free limit implementation: - Effectively after every block was mined, there was a window during which people could try to rush to get free transactions into the mempool. It looks like one of the later changes might have reduced this somewhat (free limit became independent of block acceptance). - The free acceptance would be pretty subjective in nature, especially due to the racy nature of people trying to submit at same time. Not a good foundation for unconfirmed transaction reliability. It's possible to reintroduce free transactions, however we don't want it to turn into a subjective race over a limited free area that happens after each block. Most ideally, each transaction's acceptability can be judged independently of the existence of other transactions. Practically we know this is not possible in general (the mempool is limited, so at some point transactions do crowd each other out) but we do want to avoid this when possible. Here we can brainstorm some ideas of what a new free transaction system might look like.