Can RBF be used to replace a graph of transactions in the mempool? [SOLVED]

[hvelo33]

I have three transactions that build a graph, i.e. the output of the first transaction is the input of the second transaction and the output of the second transaction is the input of the third transaction. RBF is enabled. All three transactions are still unconfirmed in the mempool. Now I want to replace all three transactions by a new graph of three transactions that each pay one satoshi per byte more fee than the old ones. Is it possible to replace all three transactions this way, or is it necessary that the first transaction of the new graph pays more fee than all three transactions of the first graph combined?

I ask this, because I have manually tried this with the Broadcast raw transaction online tool of the Blockstream website. I generate the raw transactions with my own program.
I was successfull to send the first three transactions of the first graph with a fee of 9 sat/byte. Then I wanted to replace the graph, so I incremented the sequence by one and increased the fee to 10 sat/byte and spent the same input that was spent by the first graph. But when I wanted to broadcast the first transaction I got the message, that the replacing tx does not pay enough fee, it should pay more fee, and the number it suggested was so high that it seems to me it wanted that the transaction paid a higher fee than the whole graph it opted to replace.

Now, I wonder if it would work, if I sent the new graph with a client directly to the network, where I could announce all three transactions of the new graph at once by an "inv" message, instead of using the online broadcasting tool where I can only send one tx at once.

If it does not work to replace a graph as I described then I think that would be a bug.

Please enlighten me

[hosseinimr93]

You can replace any of those transactions with a new one.
If you replace the first one, nodes will remove the second and third one from their mempool too. If you replace the second one, nodes will keep the first one in their mempool and remove the third one too.
If you replace the third one, nodes will keep the two other transactions in their mempool.

I was successfull to send the first three transactions of the first graph with a fee of 9 sat/byte. Then I wanted to replace the graph, so I incremented the sequence by one and increased the fee to 10 sat/byte and spent the same input that was spent by the first graph. But when I wanted to broadcast the first transaction I got the message, that the replacing tx does not pay enough fee, it should pay more fee, and the number it suggested was so high that it seems to me it wanted that the transaction paid a higher fee than the whole graph it opted to replace.

According to BIP125, the fee paid for the replacement transaction must be higher than the total fee of the transactions that should be removed from the mempool after the replacement.
If you replace the first transactions with a new one, the second and third transactions will be removed from mempools too and the fee you pay for the new transaction must be higher than the total fee paid for the transactions.

If you want all the transactions to be confirmed fast, it's better to increase the fee of the third transaction. With doing so, all your three transactions will be included in the same block, if their effective fee rate is high enough. The effective fee rate is equal to the total fee divided by the total (vitual) size of transactions.

[hvelo33]

According to BIP125, the fee paid for the replacement transaction must be higher than the total fee of the transactions that should be removed from the mempool after the replacement.
If you replace the first transactions with a new one, the second and third transactions will be removed from mempools too and the fee you pay for the new transaction must be higher than the total fee paid for the transactions.

If I understand correctly, this is poses a problem for me. What I want to do is to replace all three transactions.
Let's say my first graph looks like this

TX₁₁ (9 sat/B) -> TX₂₁ (9 sat/B) -> TX₃₁ (9 sat/B)

Now I want this graph be replaced by this graph

TX₁₂ (10 sat/B) -> TX₂₂ (10 sat/B) -> TX₃₂ (10 sat/B)

For the miner it would make sense to replace the first graph with the second one since it pays 10 sat/B instead of 9. However, if I understand you correctly, when I broadcast the first RBF transaction TX₁₂, the miner does not yet know that I am up to also replace TX₂₁ and TX₃₁. So he wants me to pay a transaction fee of like 30 sat/B for TX₁₂ which is not what I want, since I intend to replace TX₂₁ and TX₃₁ with TX₂₂ and TX₃₂ as well.
Is there a solution to my problem?

[nc50lc]

Let's say my first graph looks like this

TX₁₁ (9 sat/B) -> TX₂₁ (9 sat/B) -> TX₃₁ (9 sat/B)

Now I want this graph be replaced by this graph

TX₁₂ (10 sat/B) -> TX₂₂ (10 sat/B) -> TX₃₂ (10 sat/B)

That graph is confusing.
In the first graph, where's TX₁₂ to TX₂₀ and TX₂₂ to TX₃₀?

If it's meant to be: the transaction on the right is the child of the transaction on the left, then it's better to use an example like this:
TX_1A (9 sat/B) -> TX_2A (9 sat/B) -> TX_3A (9 sat/B)

In the second graph, you may tell the replacement by changing A to B:
TX_1B (10 sat/B) -> TX_2B (10 sat/B) -> TX_3B (10 sat/B)

However, if I understand you correctly, when I broadcast the first RBF transaction TX₁₂, the miner does not yet know that I am up to also replace TX₂₁ and TX₃₁. So he wants me to pay a transaction fee of like 30 sat/B for TX₁₂ which is not what I want,

It's more than just 30sat/vB.
The replacement has to pay at least the total "absolute fee" amount paid by all of its children transactions, its original absolute fee and its own bandwidth (+1sat/vB equivalent).
Not the fee rate (like 'sat/vB') but the absolute fee ('n sat/vB' x 'n vBytes') paid by those transactions.
So if those transactions varies in sizes and/or if it changed in size, it wont be the straightforward sum of all their fee rate.

Is there a solution to my problem?

The solution is to mine blocks.
The rule above is only "standard rules" (policy) so if you're a solo miner, pool owner or affiliated to one,
you can (ask to) replace TX_1A, TX_2A and TX_3A with TX_1B, TX_2B & TX_3B in your/their candidate block without following the rule above.
you can even set 0sat/vB if you want to, since it doesn't break any consensus rules.

[odolvlobo]

Would child-pays-for-parent be a solution? In other words, RBF the last transaction with enough fee to pay for its unconfirmed ancestors.

[hosseinimr93]

Would child-pays-for-parent be a solution? In other words, RBF the last transaction with enough fee to pay for its unconfirmed ancestors.

I recommended this too, but since OP is still insisting on replacing all three transactions with new transactions one by one, he/she may want to replace the transactions with new ones sending the fund to different address(es).

[hvelo33]

Would child-pays-for-parent be a solution? In other words, RBF the last transaction with enough fee to pay for its unconfirmed ancestors.

No it's not. Because this is not about payments, these graphs are used for some layer 2 protocol. Each tx in the graph contains one OP_Return output plus a change addess. It's a token. The change output is used by the subsequent tx to make a new token. However, the tokens are only usefull for the layer 2 protocol, if they are inserted in the latest block. If the miner does not include them in the block, they sort of expire from the perspective of layer 2. Therefore they have to be RBF ed.

[vjudeu]

Because this is not about payments

But then, why do you want to do it on Bitcoin? If you want to only push data, and nothing else, then test networks are a better choice, because then your transactions don't affect real payments. And even better solution is to use your own chain, then you can cheaply finalize everything.

Each tx in the graph contains one OP_Return output plus a change addess. It's a token.

In that case, why do you need more than one unconfirmed transaction at all? And why do you want to use OP_RETURN, and tell everyone "Hey! It is a token!", and risk getting it censored? Better just use a single transaction, and tweak your signature, to commit to your data. In this way, a single transaction can confirm the whole state of your L2 network! Because if you have user A with transaction A in some block, and user B with transaction B in the same block, then Proof of Work coverage will be exactly the same.

And if you only tweak a single R-value in your signature, then the total size of your transaction will stay the same, so it will be cheaper to bump it. Also, if you plan to do a lot of replacements, then it is a good idea to start from low fees. If it is only about pushing data, then zero fees seems perfect, and the last user can just replace it with the proper fee, and get things broadcasted to all nodes. Also, using something different than SIGHASH_ALL could help, because if you use for example SIGHASH_ANYONECANPAY, then it will be possible to add more inputs, without invalidating signatures. Similar thing goes with SIGHASH_SINGLE: if you need just a single source and destination, then you can combine both flags, and have just some pairs of input-output, and batch all of that into a single transaction.

[hvelo33]

Because this is not about payments

But then, why do you want to do it on Bitcoin?

Because Bitcoin is the most secure and most widely adopted PoW network.

In that case, why do you need more than one unconfirmed transaction at all?

Because that is how the consensus algo of my layer 2 protocol works. Every token votes for a layer 2 block. The more tokens there are, the more voting power you have, it's similar to PoW. So a layer 2 miner may want the vote with only one token, but he may also chose to increase his voting power by doing several tokens. If his tokens get not included in the next Bitcoin block however, he loses the fee he paid for the tokens, in this case RBF would be good.

[hvelo33]

I hoped that RBF would work as follows:

Assume I have the first graph consisting of the three transactions in the mempool as described earlier.
In order to replace them, I would broadcast an "inv" message containing the inventories of the 3 RBF transactions (the second graph). Upon reception of this inv message, a node would know, that these three transactions come as a package. So when the node sends me the getdata message where he request the three messages. I send back those three messages with three distinct "tx" messages (There is no "txs" message where you can send bulk transactions). Now when the node receives the first RBF tx message, he would not yet reject it, even though it does not pay more fees than the sum of all transactions removed from the mempool, but first it would also evaluate the next two messages. Only then it would decide whether to reject the three RBF txs or not and it would not, because each RBF tx pays one sat/B more that the txs that are replaced. Does that make sense? Is that not how it should, or maybe even is, implemented?

[hvelo33]

I realyzed that I can change the layer 2 algo so that RBF is no longer required.
Thanks for informative help anyway.