Bitcoin Forum
July 25, 2021, 05:25:31 AM *
News: Latest Bitcoin Core release: 0.21.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 [2]  All
  Print  
Author Topic: Transaction cut-through  (Read 8772 times)
ertil
Newbie
*
Offline Offline

Activity: 12
Merit: 33


View Profile
January 10, 2021, 08:56:53 AM
 #21

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.
1627190731
Hero Member
*
Offline Offline

Posts: 1627190731

View Profile Personal Message (Offline)

Ignore
1627190731
Reply with quote  #2

1627190731
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1627190731
Hero Member
*
Offline Offline

Posts: 1627190731

View Profile Personal Message (Offline)

Ignore
1627190731
Reply with quote  #2

1627190731
Report to moderator
spartacusrex
Hero Member
*****
Offline Offline

Activity: 719
Merit: 537



View Profile
January 11, 2021, 11:58:45 AM
 #22

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.

Life is Code.
ertil
Newbie
*
Offline Offline

Activity: 12
Merit: 33


View Profile
January 11, 2021, 05:36:26 PM
 #23

Quote
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.

Quote
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).

Quote
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.

Quote
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
Full Member
***
Offline Offline

Activity: 166
Merit: 117


View Profile
January 25, 2021, 06:48:36 AM
 #24

Quote
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?
Pages: « 1 [2]  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!