You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on May 13, 2022. It is now read-only.
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
The text was updated successfully, but these errors were encountered:
chris-belcher
changed the title
Transaction cut-through for JoinMarket
Transaction cut-through for JoinMarket, for reducing costs and scaling better
Sep 5, 2015
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.
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.)
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
The text was updated successfully, but these errors were encountered: