Skip to content
This repository has been archived by the owner on May 13, 2022. It is now read-only.

Transaction cut-through for JoinMarket, for reducing costs and scaling better #218

Open
chris-belcher opened this issue Sep 5, 2015 · 2 comments

Comments

@chris-belcher
Copy link
Collaborator

Based on this idea https://bitcointalk.org/index.php?topic=281848.0

The idea there is that you work up a collection of unconfirmed transactions, and if you discover you're able to cut out the middlemen and the singers are still online, you do.
so the market makers get cut out
if a timeout happens you transmit. so basically coins that bounce multiple times unconfirmed can have their middles cut out.
and yea, for joinmarket that would be what you'd do. I think.
could conceivably be possible if a market taker then announces an offer to do this and watches other similar offers
might improve privacy... and performance, so you could take an offer instantly but later swap it out to a better pairing with another user.
does this rely on RBF? for the later tx to be replacing the old one
the assumption there is that you'd refrain from broadcasting and potentially use nlocktime to prevent it.
e.g. if the transaction is nlocktimed for a few blocks in the future, then you have up until then to optimize before it even could be broadcast.
if someone goes early it doesn't break anything.
a problem with the nlocktime thing is market takers usually want their payment to happen straight away, thats their role in this market
ill think about it some more, there might be some way

@chris-belcher chris-belcher changed the title Transaction cut-through for JoinMarket Transaction cut-through for JoinMarket, for reducing costs and scaling better Sep 5, 2015
@raedah
Copy link
Contributor

raedah commented Dec 15, 2015

just adding my comment here..

Along the same lines of Coin Swap, is the concept of Transaction Cut-through. https://bitcointalk.org/index.php?topic=281848.0 Gmaxwells description uses nlocktime for people to join and supercede transactions that have already been broadcast. But without needing any bitcoin protocol modifications, we could implement this in a similar way by giving the full signed transaction to all parties involved, with instructions to delay the broadcasting of the transaction. Then all parties could wait around for additional parties to join in and expand the transaction for whatever decided interval. If that doesnt happen, or if the signing process gets disturbed, no big deal, because the earlier complete transaction can just be broadcast by any party.

@Giszmo
Copy link

Giszmo commented Dec 15, 2015

Just to visualize with a JoinMarket context:

Taker wanted to pay $4: UTXOs $12, $5, $6 -> 3 x $4, $8_, $1, $2
Taker wanted to pay $3: UTXOs $8_, $7, $27 -> 3 x $3, $5, $4, $24

"$4" (and "$3") provide privacy and can't be cut-through but the UTXO4 can be removed:

UTXOs $12, $5, $7, $6, $27 -> 3 x $4, $1, $3, 3 x $5, $3, $1, $22

As JoinMarket gives away the matching on the part that isn't the payment anyway, there should be no harm in doing this.

Replacing UTXOs though is a problem. If a participant decided to not bring $5 in tx1 and $7 in tx2 to the table, but to cut through bringing $11 for both, then participants learn that UTXOs $5, $7 and $11 are of the same user.

Participants would have less anxiety bringing bigger UTXOs to the table if takers ever pay for bitcoin days destroyed but allowed a cut-through. (I assume bitcoin days destroyed will be an important aspect as outputs that go directly into the next join transaction would look like makers if there was a shortage of makers, so takers might incentivize makers to bring old coins.)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants