From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Antoine Riard <antoine.riard@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap
Date: Tue, 25 Aug 2020 03:16:05 +0000 [thread overview]
Message-ID: <VpsctPiYOV704v9wZiSROdRggid7uRv2mZVnCIILEPL4_VmwKhMVdNMPBj9XaF73-39jFLl3cq1o2tSk8h45tMuWM9W_i4_MQHKoJdYh9ew=@protonmail.com> (raw)
In-Reply-To: <CALZpt+GxKDEDAGUH3Jb3rcZdh_jy_depLRE5KzGTpkZOLVH+QA@mail.gmail.com>
Good morning Antoine,
> Note, I think this is independent of picking up either relative or absolute timelocks as what matters is the block delta between two links.
I believe it is quite dependent on relative locktimes.
Relative locktimes *require* a contract transaction to kick off the relative locktime period.
On the other hand, with Scriptless Script (which we know how to do with 2p-ECDSA only, i.e. doable pre-Taproot), absolute locktimes do not need a contract transaction.
With absolute locktimes + Scriptless SCript, in a single onchain PTLC, one participant holds a completely-signed timelock transaction while the other participant holds a completely-signed pointlock transaction.
This can be arranged by having one side offer partial signatures for the transaction of the other, and once completing the signature, not sharing it with the other until we are ready to actually broadcast the transaction of our own volition.
There is no transaction that both participants hold in completely-signed form.
This should remove most of the shenanigans possible, and makes the 30xRBF safe for any range of fees.
I think.
Since for each PTLC a participant holds only its "own" transaction, it is possible for a participant to define its range of fees for the RBF versions of the transaction it owns, without negotiation with the other participant.
Since the fee involved is deducted from its own transaction, each participant can define this range of RBFed fees and impose it on the partial signatures it gets from the other participant.
--
Private key turnover is still useful even in an absolute-timelock world.
If we need to bump up the block delta between links, it might be impractical to have the total delta of a multi-hop swap be too long at the taker.
As a concrete example, suppose A is a taker who wants to route over makers B and C.
However, B and C require a CLTV delta of 1 week.
If A wants to route "directly" A->B->C->A, then if something bad happens, it could be looking at having its funds locked for two weeks.
To reduce this risk, A can instead first swap A->B->A, then when that completes, A->C->A.
This limits its funding lockup to 1 week.
Private key turnover is useful since as soon as the A->B->A swap completes, it can directly fund the A->C->A swap from the B-side funding transaction of the A->B->A swap.
| A->B->A | A->C->A |
: : :
A -:->funding A&B--> B : :
: : :
B -:->funding A&B -----:--> funding A&C --> C :
: : :
: :C-> funding A&C ------:-> to-cold A -->
: : :
This increases the number of transactions by 1 per swap beyond the first, compared to a direct routing A->B->C->A, but this may be worth it for A if the timelocks involved are too big for A.
With 2p-ECDSA, a funding A&C looks exactly the same as a to-cold A, so B is unable to reliably determine if it is the last hop in the route.
Without private key turnover, A would have:
**NO** private key turnover!
| A->B->A | A->C->A |
: : :
A -:->funding A&B--> B : :
: : :
B -:->funding A&B -----:--> claim A -> funding A&C --> C :
: : :
: : C-> funding A&C ------:-> to-cold A -->
: : :
So if timelock-deltas are possibly-high (to reduce the probability of the MAD-HTLC argument, and other attacks, succeeding), takers might prefer to route by completing one swap first before starting the next one, and private key turnover is useful by reducing blockspace required by each hop.
For reference, this is how it looks like with a single A->B->C->A swap with private key turnover:
| A->B->C->A |
: :
A -:->funding A&B--> B :
: :
B -:->funding B&C -> C :
: :
C -:->funding A&C -----:-> to-cold A -->
: :
This is still smaller than in the A->B->A, A->C->A with private key turnover, by one funding tx per hop.
However, A risks a much higher timelock (twice the timelock).
Thus, A might prefer a lower timelock in exchange for paying for an additional transaction.
Regards,
ZmnSCPxj
next prev parent reply other threads:[~2020-08-25 3:16 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-11 12:05 Chris Belcher
2020-08-20 11:17 ` ZmnSCPxj
2020-08-20 15:28 ` Nadav Kohen
2020-08-20 21:38 ` ZmnSCPxj
2020-08-20 22:37 ` Chris Belcher
2020-08-20 22:15 ` Chris Belcher
2020-08-21 4:20 ` ZmnSCPxj
2020-08-21 9:47 ` Chris Belcher
2020-08-22 1:09 ` ZmnSCPxj
2020-08-24 19:30 ` Antoine Riard
2020-08-25 3:16 ` ZmnSCPxj [this message]
2020-09-03 9:00 ` Chris Belcher
2020-09-03 9:45 ` ZmnSCPxj
2020-09-03 10:50 ` Chris Belcher
2020-09-03 23:39 ` ZmnSCPxj
2020-09-05 2:45 ` ZmnSCPxj
2020-09-05 1:10 ` Antoine Riard
2020-09-05 2:29 ` ZmnSCPxj
2020-08-29 22:03 ` Chris Belcher
2020-08-30 13:38 ` ZmnSCPxj
2020-09-05 1:07 ` Antoine Riard
2020-09-06 3:06 ` seid Mohammed
2020-10-03 10:36 ` [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap appendium Chris Belcher
2020-10-03 13:31 ` ZmnSCPxj
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='VpsctPiYOV704v9wZiSROdRggid7uRv2mZVnCIILEPL4_VmwKhMVdNMPBj9XaF73-39jFLl3cq1o2tSk8h45tMuWM9W_i4_MQHKoJdYh9ew=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=antoine.riard@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox