This cut-through mechanism is the modus operandi of the Mimblewimble protocol [1], where it doesn't need interaction with any of the tx signers and can be applied across the entire blockchain history to slim down the Initial Block Download.
[1] https://github.com/mimblewimble/grin/blob/master/doc/intro.md
Topic: Transaction cut-through - page 2. (Read 9005 times)
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.
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.
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.
Has anyone done research into simulations to estimate the possible savings which would be fained by using transaction cut-through?
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.
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.
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.
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.
Jump to: