Page MenuHomePhabricator
Create Task
Maniphest T706

Reintroducing free transactions
Open, Needs TriagePublic
Actions

Description

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.

Related Objects

Event Timeline

markblundeberg created this task.Jan 7 2020, 22:43
markblundeberg added a comment.EditedJan 8 2020, 00:33

One possibility that comes to mind is:

  • Calculate the coin-age of inputs as the lower of: BCH amount * number of confirmations, or BCH amount * N where N is some number in the 100s to 1000s. In other words, calculate coin-age as usual but clamp the age to some number ~ day-week length.
  • When limiting mempool entry (when comparing to minfeerate), calculate the fee as: actual_fee + X * input_coin_age for some very small X.

Note that this dropping of fee floor would not have to necessarily have to affect the *priority* of these low fee transactions. The free transactions may very well still be the first to be evicted from mempool, and be the last to be mined, in times of congestion. But it could also affect priority, if that is desired. Since congestion should be rare, it shouldn't matter that much either way aside from how it affects DoS behaviour.

The effects:

  • Assuming 1 sat/byte min feerate, this means you could get a totally free transaction provided input_coin_age >= total_tx_size * (1 sat / byte) / X.
  • If you let your inputs saturate in age (>=N confs), then for a typical tx pattern (220 bytes for each input) you need inputs to be at least 220 sat / (N * X) for them to be fully free. Smaller or less-aged inputs could be partly-free.
  • Another way to see it: for each 1 BCH you have, you get a N*X BCH fee discount that builds up over N confirmations. For a recent utxo, each new confirmation gives you an additional X BCH of credit.
  • The total possible free transaction size in mempool will then be (21e14) * N * X bytes, assuming the maximum possible circulating (21 million BCH).
  • The maximum sustained throughput of free transactions would be (21e14) * X bytes per block, assuming the maximum possible circulating (21 million BCH).
  • I say 21 million BCH (the upper limit) but in practice we shouldn't expect so much to be circulating.

As an example we could have X = 1e-8 (1 sat per BCH-conf) and N = 288 (2 days). This would mean a 0.76 BCH input could be transacted for free once aged for 2 days. Assuming 1M BCH in regular circulation, then at most 300 MB of free transactions could be in mempool, and the throughput of free transactions would be ~1 MB per block. As network capacity increases, the value of X could be increased (assuming the 1 sat/byte floor stays) or X could be maintained while the 1 sat/byte floor is lowered.

markblundeberg updated the task description. (Show Details)Jan 8 2020, 00:51
jasonbcox added a subscriber: jasonbcox.Jan 8 2020, 01:45
Klakurka added a subscriber: Klakurka.Jan 8 2020, 02:07

Some additional context from Development Meeting 18: https://www.youtube.com/watch?v=ywVePiAcRa4&t=4124

Nicknameul added a subscriber: Nicknameul.Jan 14 2020, 00:10