Free Lunch: Testing free relay with new minimum relay fee rate

[1440000bytes]

Most mining pools have started including sub 1 sat/vB transaction in blocks and some nodes have reduced minrelaytxfee to 0.1 sat/vB. The default minrelaytxfee in bitcoin core was also changed to 0.1 sat/vB in PR 33106. However, transactions with 0.1 sat/vB have been unconfirmed since couple of weeks. Some of them recently got re-broadcasted. Example: db2eb7f83b4b9ff8dfa74a69bf8b3e05ce1ad77d007906716f1ee14605cc6300

I am curious if these 10-15 sat fee transactions with some ancestors in the mempool will ever get mined. So, I have created 'free lunch' to test relay on bitcoin p2p network. You can join me with some sats and relay low fee transactions. It won't require more than 1000 sats. Read the docs for more information and feel free to suggest any improvements.

Docs: https://freelunch.lol/docs/
Leaderboard: https://freelunch.lol/leaderboard/

[stwenhao]

I am curious if these 10-15 sat fee transactions with some ancestors in the mempool will ever get mined.

For that reason, things can be signed with SIGHASH_ALL | SIGHASH_ANYONECANPAY. Then, all outputs will be protected, but more inputs could be added by anyone, to bump fees, when needed.

Also, the interesting fact about using such sighashes, is that people can make free transactions, or even negative fee transactions, and they can be perfectly valid, if more inputs will be added by someone else. Which means, that senders can make interesting transactions, and they can be sponsored by those, who will want to get them confirmed on-chain.

I think there could be some reasons, why people may be interested in negative fee transactions in the future. For example: it is perfect use case for any dust amounts: you can make an invoice with negative fee, and receive some payment, while also sweeping some dust UTXO into something bigger.

Edit: Example transaction, where bc1qts0jh2d2nesmketmw3thedwrx939k2tqu04gy90x9hd4049g4uhs83ltjx used negative fee: https://mempool.space/tx/8349df0753e80cce322322f1b76789e1d0fd6693aed2f4de4e49576423081ae7 (and of course, bc1q9nw84cph4dn2pw78pnaec68c82h7pxvv55cla8 sponsored it, which made fees positive, and bumped it to 128 sats).

Edit: https://delvingbitcoin.org/t/changing-the-minimum-relay-feerate/1886/5

So, to sum up: any given transaction can use two ways to deal with spam: one is transaction fee, another is Proof of Work. And then, it is all about finding an equilibrium, and deciding, if a given user wants to put more coins in, or more Proof of Work instead. Personally, I have nothing against allowing even free transactions, as long as they will have significant Proof of Work requirements, to prevent it from being abused.

And I would add more into that: I would happily accept even negative fee transactions, if they would contain some Proof of Work, to not flood my node, when it would receive them. In general, the lower bound is minus 21 million BTC, and not just zero. If accepting negative fees would mean, that people would use more Proof of Work, then it is fine by me. The free market will find its equilibrium somewhere, and the optimal fee can be negative as well.

Because now, the recent trend is to lift all limits, one-by-one: TapScript commitment limit (now up to 4 MB per block), OP_RETURN limit (now up to 1 MB per block), minimal fee limit (now 0.1 sat/vB, but I expect some misconfigured nodes accept free transactions unconditionally, and can be easily flooded). So, if the future of on-chain Bitcoin is to be flooded, then go on, and suffer: reasonable people will put some protections, everyone else will be flooded. The good way of anti-DoS is just Proof of Work, but other things can be done, if it will be necessary. And now, every user can apply Proof of Work inside Script, so there is a way to make a proof, that someone is not a spammer, if needed.

[1440000bytes]

For that reason, things can be signed with SIGHASH_ALL | SIGHASH_ANYONECANPAY. Then, all outputs will be protected, but more inputs could be added by anyone, to bump fees, when needed.

The goal of free relay is to keep the transaction in mempool and never get included in a block. It can be used by an attacker to waste bandwidth, memory etc. for nodes in the p2p network. SIGHASH_ALL | SIGHASH_ANYONECANPAY isn't used by a lot of transactions. Although it has some use cases and joinstr(coinjoin implementation) uses this sighash flag.

[stwenhao]

The goal of free relay is to keep the transaction in mempool and never get included in a block.

Then it should use zero fees. In other cases, some miner may include it anyway, and then, it is no longer "free", when real satoshis are taken out of users. Also, the chain of transactions can form a package, so that after many free transactions, you can end the chain with some non-zero-fee transaction, bumping effective fee rate by CPFP.

Also, by rejecting any free transactions upfront, miners can lose a lot of coins. This is how Garlo Nicon made his coins hard to steal: https://mempool.space/testnet4/tx/94444d3f15c1ca6905368c2121a0240c098ed62b061c1ac923cc9bff67991b55

In practice, anyone could take 9950 tBTC. But because the initial transaction was free, and the next one paid absurdly high fees, he could be pretty sure, that nobody will take it, even if his node would happily share it with anyone, willing to request it. But nodes used 1 sat/vB as a minimum, so they didn't see the first transaction, so they never heard about the second one, and they became aware of it, only when they saw it included in a block. And even then, it was mined on just a CPU, but nobody was fast enough to notice it, and reorg the chain, before ASICs set all of that in stone, by mining on top of his block.

SIGHASH_ALL | SIGHASH_ANYONECANPAY isn't used by a lot of transactions.

This attack can be made stronger, by using different sighashes, than SIGHASH_ALL. Because then, after making a long chain of transactions, anyone would be able to break it at any point, just by adding more inputs or outputs. Normally, if signatures with different sighashes could be chained, it wouldn't be the case, but in existing network circumstances, if some previous output is referred by txid:vout, then exactly this txid:vout is actually signed, so if a single input or output in any previous transaction is altered in any way, then all following transactions are invalidated (which means they were propagated literally for free).

[Kruw]

The goal of free relay is to keep the transaction in mempool and never get included in a block. It can be used by an attacker to waste bandwidth, memory etc. for nodes in the p2p network.

Nodes limit their mempools to 300MB by default, so there's not really a large surface to attack.

[stwenhao]

Nodes limit their mempools to 300MB by default, so there's not really a large surface to attack.

Yes. However, that 300 MB is reusable. Which means, that if there is 100 MB of real traffic, and 200 MB of free space, then you can first fill 200 MB with 0.1 sat/vB, and then you can bump it a little, by using full-RBF. Then, if you replace just a single transaction, and everything behind it will be invalidated, just because of changed "txid:vout", then guess what: you have yet another 200 MB to fill it again! Which means, that everything, which was sent before, was basically free, unless some miners will decide to confirm it anyway (which is not done by default).

Previously, the minimal price for 1 MB was 0.01 BTC, when transaction fees were set to 1 sat/vB. Now, when they are set to 0.1 sat/vB, for 0.01 BTC, you can send 10 MB. Which means, that filling the whole mempool should in theory cost something around 0.30 BTC. However, in practice, that cost is lower, because if you bump the first transaction, then all following ones will be invalidated, so you can start filling mempools again, and again, and again, until you reach 1 sat/vB, when more nodes will start getting that traffic, and potentially confirming it on-chain.

Also, that's why I said, that using something else than SIGHASH_ALL can make the attack worse. Because then, you can send something, and then, you can blame random users for adding more inputs and outputs to your transaction, so if someone will call you a spammer, you can say "It's not me, I didn't change my transaction, some random users did it!".

[1440000bytes]

The goal of free relay is to keep the transaction in mempool and never get included in a block. It can be used by an attacker to waste bandwidth, memory etc. for nodes in the p2p network.

Nodes limit their mempools to 300MB by default, so there's not really a large surface to attack.

https://en.wikipedia.org/wiki/Bandwidth

[Kruw]

Yes. However, that 300 MB is reusable. Which means, that if there is 100 MB of real traffic, and 200 MB of free space, then you can first fill 200 MB with 0.1 sat/vB, and then you can bump it a little, by using full-RBF.

Bumping the fee rate would cause the transaction to get mined, so it would no longer be free for the attacker.

Then, if you replace just a single transaction, and everything behind it will be invalidated, just because of changed "txid:vout", then guess what: you have yet another 200 MB to fill it again! Which means, that everything, which was sent before, was basically free, unless some miners will decide to confirm it anyway (which is not done by default).

This is the reason why BIP125 has multiple conditions for a replacement to be accepted:

3. The replacement transaction pays an absolute fee of at least the sum paid by the original transactions.

[stwenhao]

Bumping the fee rate would cause the transaction to get mined

Only when mempools are not congested. If there is regular traffic with higher fees, then transactions can be relayed for free. By being 100 MB behind the tip, and 4 MB per block, it means at least 25 blocks (and new transactions are constantly created by regular users).

This is the reason why BIP125 has multiple conditions for a replacement to be accepted:

When you have a chain of transactions, then you have to bump only the first transaction, to invalidate everything behind it. Which means, that you relay Alice -> Bob -> Charlie -> ... -> Zack with minimal fees, and then you bump only Alice -> Bob just a little bit. Guess what: Bob -> Charlie -> ... -> Zack chain is now invalid, because "txid:vout" was changed.

So, you can start with 0.1 sat/vB, then keep bumping Alice -> Bob, until reaching something like 0.99 sat/vB, then start bumping Bob->Charlie incrementally, and so on. Miners using 1 sat/vB will never see that traffic at all, and nodes accepting 0.1 sat/vB will keep broadcasting it between themselves.

Another option is to keep using 0.1 sat/vB all the time, and check, if nodes forget about transactions after two weeks, or maybe faster. And then, it still means free relay of something around 200 MB per two weeks, if not more. Also, when nodes forget about previously broadcasted versions, then you can use exactly the same coins again, to relay different versions of the same transaction, with the same fees, which means, that different nodes will then store different transactions in their mempools (which also means, that you won't pay anything for what was relayed before, unless some miner will allocate some space for low-fee transactions, to stop your attack, and take your coins, while also losing opportunity to get fees from other, more expensive transactions).

[Kruw]

Only when mempools are not congested. If there is regular traffic with higher fees, then transactions can be relayed for free.

...but if there isn't regular traffic with higher fees, the attacker loses money to miners.

So, you can start with 0.1 sat/vB, then keep bumping Alice -> Bob, until reaching something like 0.99 sat/vB, then start bumping Bob->Charlie incrementally, and so on. Miners using 1 sat/vB will never see that traffic at all, and nodes accepting 0.1 sat/vB will keep broadcasting it between themselves.

Again, this attack is what Rule 3 of BIP125 already protects nodes against. In order for a replacement to be accepted, it has to pay a higher fee rate (in sat/vbyte) and also a higher absolute fee than the transactions being replaced.

[stwenhao]

In order for a replacement to be accepted, it has to pay a higher fee rate (in sat/vbyte) and also a higher absolute fee than the transactions being replaced.

All of these rules are applied for a single transaction, and not for a chain of transactions. If you replace one transaction, consuming 250 bytes, with another transaction, consuming another 250 bytes, but just using different amounts, to raise feerate, then guess what: behind them, you have outputs. And these outputs are used by next low fee transactions.

And then, you can confirm Alice -> Bob transaction with 0.1 sat/vB, or Alice -> Bob transaction with 0.2 sat/vB. And behind first version, you can put 200 MB of other transactions, and behind a second version, you can put 200 MB of completely different transactions. Which means, that you relayed the first 200 MB for free, just because nodes replaced one 250 byte transaction with another 250 byte transaction, and that invalidated 199.999750 MB behind it.

So, the strategy to maximize damage, can be quite simple:

1. Make small transaction with low fees.
2. Push a lot of transactions on top of it, also with low fees.
3. Bump the first transaction in the unconfirmed chain.
4. Push another load of transactions on top of it.
5. Repeat steps 3 and 4, as long as you want.

Then, even if you pay 1 sat/vB for the first transaction, then it will turn out, that this is your feerate not per 250 bytes, but for example per relaying (not to be confused with on-chain confirming) 250 MB. And that's why you received link to the article, describing what "bandwidth" is.

Also, guess what: if your initial low fee transaction will have 0.99 sat/vB feerate, or if you wait long enough, that nodes will forget about your transaction, then it would mean, that everything you relayed, was basically free, and you paid zero satoshis for doing it.

[gmaxwell]

All of these rules are applied for a single transaction, and not for a chain of transactions.

The replacement logic requires the replacement pay at least the replacement feerate for everything they evict too.  The plural in BIP125 is not a typographical error.

[stwenhao]

The replacement logic requires the replacement pay at least the replacement feerate for everything they evict too.  The plural in BIP125 is not a typographical error.

Yes. But it is applied only to transactions, that your node can see. However, now we have at least two parallel policies: a group of nodes will accept 0.1 sat/vB, while another group of nodes will accept 1 sat/vB. In the worst case, let's assume that you send 0.1 sat/vB as your initial transaction, then put a lot of traffic on top of that, and later, you bump the first transaction to 1 sat/vB. What will happen? Of course, your first replaced transaction will be seen by everyone, but the rest of the low-fee traffic, will be seen only by nodes accepting 0.1 sat/vB. And what happens, when 1 sat/vB will be confirmed? Of course, it will be different than 0.1 sat/vB you relayed earlier. And of course, it will conflict with everything, which was built on top of 0.1 sat/vB first transaction. So, nodes with lower fee requirements, will throw away 200 or 300 MB of what was made on top of it, which will allow you to repeat the attack again.

And what is the conclusion? You can broadcast 250 MB of traffic, and pay 250 satoshis to do it again. Which means, that on-chain, only one small transaction was confirmed. But when it comes to used bandwidth, you wasted 250 MB of that, for just 250 satoshis, so your on-chain fees can be 1 sat/vB or 0.1 sat/vB, but your relay fees are 0.000001 sat/vB in practice.

[gmaxwell]

K, I thought your message was easily misunderstood as an incorrect correction about how replacement. -- the response to you by Ian sure appears to have misunderstood it that way.

But in fact the behavior you were intending to describe existed when there was no replacement in Bitcoin at all.

Any time there transactions that will relay but won't get mined there is some potential for free relay though it's still a finite amount of bandwidth (as the inputs are tied up until they're knocked out by double spending or expiration).   I fail to see the relevance in this case, however, since widespread mining of the lower fee transactions preceded relay.   Due to the graph being incomplete probably some low fee transactions aren't relaying well, but even then there is a significant risk that they do get mined.

[stwenhao]

feel free to suggest any improvements

I wonder how safe is running regtest publicly, to check some edge cases. It is just a matter of exposing the traffic to the world outside localhost, and it can be easily done.

Then, we would have six blocks per second, and a lot of spam. In general, if someone wants to build some network with free P2P relay, then it is probably a good starting point. And then, soft-forks applied on top of regtest can make it safe (signet is the easiest one, but it lacks permissionless mining, so maybe signet challenge can be crafted to allow it). Because even if anyone can produce blocks, then anyone can also ignore them, if rules would be set properly. And because Script is executed, and Proof of Work inside Script is possible, then I guess it could work in practice.

Because testing free relay on mainnet is something, which is done now. But maybe it should be redirected to some kind of testnets instead, to not harm mainnet traffic, if some successful attacks will be discovered.

Edit: Using different sighashes is one improvement. But also, locktime can be used. When I checked it last time, some block explorers allowed timelocked transactions, and stored them for a few days or hours. Maybe they still accept them: https://live.blockcypher.com/btc/pushtx/

Edit: I don't know if people are aware, what are they doing:

Code:

$ bitcoin-cli getpeerinfo | grep minfeefilter
    "minfeefilter": 0.00000000,
    "minfeefilter": 0.00000000,
    "minfeefilter": 0.00001000,
    "minfeefilter": 0.00001000,
    "minfeefilter": 0.00000000,
    "minfeefilter": 0.00001000,
    "minfeefilter": 0.00001000,
    "minfeefilter": 0.00001000,
    "minfeefilter": 0.00001000,
    "minfeefilter": 0.00001000,
    "minfeefilter": 0.00001000,
    "minfeefilter": 0.00000000,
    "minfeefilter": 0.00000000,
    "minfeefilter": 0.00001000,
    "minfeefilter": 0.00000000,
    "minfeefilter": 0.00000000,
    "minfeefilter": 0.00000000,
    "minfeefilter": 0.00000000,
    "minfeefilter": 0.00000000,
    "minfeefilter": 0.00000000,
    "minfeefilter": 0.00000000,
    "minfeefilter": 0.00000000,
    "minfeefilter": 0.00000000,

I would understand going from 0.00001000 to 0.00000100, but it seems that many nodes went straight to 0.00000000. I guess they don't know about potential DoS consequences, or maybe they put other protections (but judging by some posts, I doubt it).