Bitcoin Forum
February 27, 2017, 04:19:46 PM *
News: Latest stable version of Bitcoin Core: 0.13.2  [Torrent]. (New!)
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Transaction cut-through  (Read 4592 times)
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2100



View Profile
August 26, 2013, 10:17:19 PM
 #1

As an aside from the CoinJoin discussion, it occurred to me that another transaction size optimization is possible with CoinJoin like transactions.

Say there is a collection of related unconfirmed transactions:
(u signifies an unconfirmed output)


             / uI     
A -> uB -> uH  - uJ
       /
     C

D -> uE -\
          uK -> uL       
F -> uG -/


The authors of the earliest unconfirmed transactions could write replacements for their transactions:


A->ul/uj
    /   
   C
 D   
  \   
F->uL 


This transformation is lossless with respect to the final coin ownership, but the intermediate transactions were cut-through. This works even if the original coin ending up in the final outputs came from multiple parties, as they can coinjoin to preserve the final outcome.

Because the replacements are atomic and consume the original inputs this transformation is safe, assuming people in the middle can handle any accounting complications that arise. (E.g. figuring out that their payment really was completed). So you'd want to have a way of signaling "I permit you to conflict this transaction with one that pays its children, if you can figure out how".

Nlocktime could be set in the mild future in order to create time for these kinds of arrangements to be found, and if blocks are found to fast— no harm, the cutthrough doesn't have to happen all the time.

Because people don't currently spend unconfirmed inputs I expect this wouldn't get much compression now, but in the future it might have quite an impact.
1488212386
Hero Member
*
Offline Offline

Posts: 1488212386

View Profile Personal Message (Offline)

Ignore
1488212386
Reply with quote  #2

1488212386
Report to moderator
1488212386
Hero Member
*
Offline Offline

Posts: 1488212386

View Profile Personal Message (Offline)

Ignore
1488212386
Reply with quote  #2

1488212386
Report to moderator
1488212386
Hero Member
*
Offline Offline

Posts: 1488212386

View Profile Personal Message (Offline)

Ignore
1488212386
Reply with quote  #2

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

Activity: 1064


View Profile
August 27, 2013, 09:00:16 AM
 #2

So, something like

A pays W and X
B pays Y and Z

X and Y pays H

You can replace it with a combined transaction of

A and B pays W, H and Z

However, to create that tx, you need A and B to sign.

This can happen in stages

B = Y + Z must be less than H + Z, since H > Y.

This means that the owner of B can broadcast

B pays W, H and Z, ANYONE_CAN_PAY

This is not a valid transaction, since B is less than H + Z (and so less than H + Z + W), but it counts as an offer. 

The relay rules would need to be modified, for it to work.

Nodes could check that the fragment doesn't violate the double spending rules and so forward the fragment.

A could see the transaction and then sign and broadcast the combined tx.  This makes it decentralised.

It would also act to reduce fees paid.  However, if you reduce fees, then miners might just include the original tx.

If block space is limited, then miners might still use the smaller tx, as long as it paid more in tx per kB than the original tx.

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
keystroke
Hero Member
*****
Offline Offline

Activity: 828


advocate of a cryptographic attack on the globe


View Profile
December 11, 2015, 01:35:44 AM
 #3

Has anyone done research into simulations to estimate the possible savings which would be fained by using transaction cut-through?

"The difference between a castle and a prison is only a question of who holds the keys."
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2100



View Profile
December 11, 2015, 07:16:18 PM
 #4

Has anyone done research into simulations to estimate the possible savings which would be fained by using transaction cut-through?
I did back then but it was very low because virtually no wallets spent unconfirmed coins.  Today unconfirmed spends are much higher and there would be actual savings.

Possible is hard to estimate, because if this were available it would call for a change in usage, e.g. intentionally avoiding confirmation for some time to give time to find cut-throughs.

Probably the greatest savings from cut-through is just repeated payments that reuse change; which with Opt-In RBF is much easier to implement than generic multi-part cut-through.
riplin
Member
**
Offline Offline

Activity: 116


View Profile
December 15, 2015, 05:15:53 AM
 #5

I wrote a post on reddit somewhere back in January about something similar. It wasn't multi-party in, multi-party out, but one party in, multi-party out.

Here's a writeup how it would work:

Most financial relationships between merchants and suppliers, employers and employees, subscriptions, leases, mortgages, rent, etc ,etc, are long standing relationships. The vast majority of payments flow through these channels. And we can do some really smart things with these.

Let’s look at a website.

A customer selects a number of goods on a website and proceeds to checkout. He selects bitcoin as payment option. The web server now contacts the payment router and requests a payment request for $X. The payment router now looks in its local database of creditors and starts to query a number of them for partial amounts. A couple of seconds later they all respond and the payment router now combines these payment requests, signs it, and feeds it back to the web server. The web server presents this payment request to the user, user makes payment and done. For the next customer, a completely different set of creditors could be selected, etc. You get the picture.

We just settled a number of partial debts across multiple creditors with a single transaction. Not only that, but for all we know, those creditors did the same thing and also forwarded the request to one or more of its creditors. So it could very well be that we went several hops deep (depending on the allotted time, I’m sure prefetching could work here as well).

The velocity of those coins just increased significantly.

And there are other advantages too:

- Number of transactions is reduced, reducing pressure on the blockchain;
- Large part of the debt settlement between multiple parties is now extracted out of the transaction chain, increasing privacy amongst all participants;
- No changes needed to user wallets to make this work. BIP 70 support is enough;
- No changes needed to Bitcoin either, it’s all just plain transactions;
- Would still work nicely with multi-party transactions (escrow) - the final payout transactions would contain the routing part;
- Hardly any real protocol development needed, other than the communication between payment routers, which should be minimal;
- Accounting side is simple. The relevant transaction outputs show up on both sides of the balance sheet;
- It’s completely distributed. The relationships are all one to one, but can chain and fan out quite easily and dynamically;
- You could still forward parts to a payment processor for conversion to fiat;
- Since you never take possession of (some) of the payment, there’s no exposure to volatility on the bitcoin that’s forwarded;
- Graceful degradation - the payment router can even collect on a local xpub address if all other options fail.

There’s no way you’d even be able to come close to something like this using traditional payment methods.

It would work for individual users as well. You can either setup your own payment router, add your own creditors, your savings xpub, your spending xpub, etc, and have your local wallet send out payment requests to that router when you request payment from someone. Your employer can hook up to it and trickle your salary in that way or you could use a service setup by some company to handle it for you.

Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!