Transaction cut-through

[ertil]

Well, if we are going to do it in some interactive way, then maybe it is possible to just use RBF for that. So, if we have two transactions: A->B->C and both of them are using RBF, then it may be done at mempool level, just by creating A->C transaction and not treating it as double-spending attempt if A->B and B->C transactions are present in mempool. All that is needed is accepting such RBF transactions by miners, nothing else needed.

[spartacusrex]

Wouldn't the RBF need to pay more than the combined total from the separate transactions though ?

If the miner could make make more by adding the 2 separate transactions than the single cut through ?

When there is only one transaction rbf works, since miner makes more. When you are replacing multiple transactions the rbf would need to override the sum of all of them.

Only publishing the final cut-through txn removes any tricky decisions.

[ertil]

Wouldn't the RBF need to pay more than the combined total from the separate transactions though ?

Yes, according to the current rules it need more coins. But one joined transaction will pay more than each of those two transactions are paying separately if we take satoshi per byte ratio. Imagine you have two transactions, each paying 1000 satoshi fee and each having 1000 bytes in size. Then, after doing cut-through on them, you can for example have one transaction paying 2000 satoshi fee and having 1500 bytes in size (because of cut-through). Then, from miner's perspective, including this one transaction is more profitable than including two separate transactions. Miner have nothing to lose, fees remain the same. However, as there is less space needed, such miner can fit more other transactions in the same block and receive more fees from that block.

If miners are mining for profit, they should quickly see that cut-through is working in favor of them and should activate such rules, because they will get the same amount of coins and they will need less space to include them in their blocks. Also, as they are RBF transactions, they don't have to be kept forever, finally only transactions included in blocks will be kept and the rest will be rejected forever as "provably never confirming transaction". Sooner or later, each miner by default will throw such transactions out of its mempool.

If the miner could make make more by adding the 2 separate transactions than the single cut through ?

No. Fees should remain at least the same to make sure that miner don't have to pay for having more space in a block. Miners shouldn't have a dilemma between transaction sizes and their fees, they should have an incentive to activate it (having the same fees occupying less disk space should be enough to convince them).

When there is only one transaction rbf works, since miner makes more.

When N transactions are joined into one, miner also makes more, because satoshi per byte ratio will be higher.

Only publishing the final cut-through txn removes any tricky decisions.

Yes. If transaction is confirmed, other transactions can be safely removed, as they are needed only to show other nodes that some replacement is not some double-spending attempt, but is honestly joined by cut-through.

[vjudeu]

In the first scenario, there is no need for any implementation at all:
Unconfirmed transactions could be sent (even privately) between parties and whenever it is possible they are summarized by the original senders.

I think that at least some implementation is needed. Is allowing RBF cut-through transactions with higher or equal fees in Core a good idea or not? I mean: if Alice sent some transaction to Bob and it is marked as RBF transaction and if Bob also sent some RBF transaction to Charlie (by using coins from Alice), should it be possible for Alice to create cut-through RBF transaction by joining both transactions and signing it? Optionally, it should be possible to add more inputs and outputs to increase fees, as it is possible in other RBF transactions.

Doing it privately is always possible. But I think that having such option for all RBF transactions that are already in mempool should be also possible. Thoughts?

[ertil]

Is allowing RBF cut-through transactions with higher or equal fees in Core a good idea or not?

Since full-RBF, batching can be done for all unconfirmed transactions, no matter if they should be cut-through or not. Unconfirmed means unconfirmed. And I think wallets should start implementing cut-through for unconfirmed transactions, because that could help unclogging mempools. Then, if you have "Alice -> Bob -> Charlie" transaction, Alice's wallet could allow signing "Alice -> Charlie" as a replacement, while keeping the same fees for a smaller transaction (that would increase satoshis per virtual byte rate).

[tromp]

Is allowing RBF cut-through transactions with higher or equal fees in Core a good idea or not?

No; that's not a good idea. If Alice can have tx1 A -> A1 relayed to all mempools for fee f,
and then have tx2 A -> A1 -> A2 relayed to all mempools, and so on until
txn A -> A1 -> A2 -> ... -> An for the same fee, then this one time fee f was used to generate
an arbitrary amount of network traffic, which amounts to a DOS attack.

That's why you want replacement txs to have enough fees to cover both the cost of their own relay,
as well as the relay of the tx they're replacing.