From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 78F3BC016F for ; Wed, 13 May 2020 12:33:44 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id 6E8A5885DD for ; Wed, 13 May 2020 12:33:44 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from hemlock.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78YpXIg4feFn for ; Wed, 13 May 2020 12:33:43 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-ej1-f65.google.com (mail-ej1-f65.google.com [209.85.218.65]) by hemlock.osuosl.org (Postfix) with ESMTPS id E6ACF885CF for ; Wed, 13 May 2020 12:33:42 +0000 (UTC) Received: by mail-ej1-f65.google.com with SMTP id nv1so14056838ejb.0 for ; Wed, 13 May 2020 05:33:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2oMGTeUhweRfNPGr/gt7Kbt9XBHqlvXLyLpFxDkSSv8=; b=KN/NurPfni2vW5WPy8PNEwaxpe+uGaKy5Fcw4xit34pqM5zE2FYT94rsBe5iOVjOSm PdlQNZWm1Lh93EgmglQQslh1YyZ/MOxpewT4KFCKtPpWqEhqjiNtxqEP6CzwoURw6QVQ /EJs0i2PS3mjmlky9YYK2ItwDnYPqiP9fYCWB6GV2oY0QZ+tAUWBvAeR6pWbJzfKBQSC 8DpxUh1d0duv/QVr3R8PxaiveAHa1+J+g8+nRc6Cj3e/IEK7g643lmTBAg+92WXSKsGf gMC6vJZgrGEoCFdpyp1tmHzkf1z6x8tSegs23GekWAIos93Dg7koKOrXTOYxO4Wb43lU p7Iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2oMGTeUhweRfNPGr/gt7Kbt9XBHqlvXLyLpFxDkSSv8=; b=ivY6F1DCm0MMSvkRFbwj/UB/41O90RID68v7EtXPDgMKHovGchWnkX5B3AS1PkPIns n2df6ipJQQ4ya2qR9LZIFlp1hHMLlv/4u9kFzgZ4fM0gu5VJmHDYbmLQAVKhzWQCzq6q 5wuv5U48PvhgnPbFVjZWPmkgS4MZ/TFhGADr5g+QUEqb2kl+UYXucpVzjoJCx4BvnEBV Zk+fUkohqR9yEEBJxi/e5yUTLjM+/EI+UM/bZel+WrNN/DOMwV8MtL7+R35l0ZmhdTKd 5xV0Wl71iA05fIZLPAdXb3cckhMu4srAJ5z7N40VRf1VN4XR/oe4DduuSZY+Z5pAzWqg Duww== X-Gm-Message-State: AGi0Pub/Q994zmJeDJ0XPzYsu2KXi28/t0djUVxJ8Qy5IS7LhSMX26KV hgk10d7mXKHmfg9dfLk2Bs5HZ7PhntkD5AGAjVwNYZl7 X-Google-Smtp-Source: APiQypLLa97X0J3qlfEa84Pj0awHgkBkyh7ERN5xBM8rdzZ0Ipb2c7Z8vc8tvF7LsxEmlJUNpAi0IteKTcKgLXNPkf0= X-Received: by 2002:a17:906:7f0d:: with SMTP id d13mr22632781ejr.312.1589373220824; Wed, 13 May 2020 05:33:40 -0700 (PDT) MIME-Version: 1.0 References: <2-ZZw_6q-EBo5DmIK5PtzWCE9zd9FdNtYuhFf84FKxRHwmL7g7kA9YvYB9iqFFkGy_xoXARzRW8hiZa-ZcLPWeZ60PNMQc9yMdZLnTsp1yo=@protonmail.com> In-Reply-To: From: Ruben Somsen Date: Wed, 13 May 2020 14:33:21 +0200 Message-ID: To: Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="0000000000003e296105a586ca28" X-Mailman-Approved-At: Wed, 13 May 2020 12:34:08 +0000 Subject: Re: [bitcoin-dev] SAS: Succinct Atomic Swap X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2020 12:33:44 -0000 --0000000000003e296105a586ca28 Content-Type: text/plain; charset="UTF-8" Hi ZmnSCPxj, >on completion of the protocol, if Bob lets the refund tx#1 become valid (i.e. does not spend the BTC txo) then Alice can broadcast it, putting both their funds into chaos You forget, refund tx #1 has a script (which btw won't be visible with taproot): "Alice & Bob OR Alice in +1 day" (relative) so if Alice broadcasts it after protocol completion, she is just giving Bob the key to her LTC (note: if she's wise she'd move the LTC beforehand), but Bob doesn't lose the BTC because he has both keys and can just react before the relative timelock expires. No chaos. >This is why we eventually decided in Lightning to use two CPFP outpoints rather than one I appreciate the explanation. I see the problem now, and yes, that does seem like a headache. Cheers, Ruben On Wed, May 13, 2020 at 1:39 PM ZmnSCPxj wrote: > Good morning Ruben, > > > Hi ZmnSCPxj, > > > > >potentially both Alice and Bob know all the secrets on the LTC side and > end up competing over it > > > > That's exactly right. > > > > >Bob can thus give a copy of the revoke tx with signature directly to > its favorite miner, forcing Alice to take 3 transactions > > > > Note that the timelock on the revoke tx is longer than the timelock on > refund tx #1. The idea is that Alice aborts the protocol by publishing > refund tx #1 if the protocol hasn't reached step 4 in the svg by the time > it becomes valid. This should entirely mitigate the issue you're describing. > > But if refund tx #1 at all exists, then you drop to the same issue you > objected to with my proposal, which is that, on completion of the protocol, > if Bob lets the refund tx#1 become valid (i.e. does not spend the BTC txo) > then Alice can broadcast it, putting both their funds into chaos. > > So you might as well just use my counterproposal instead, which is > simpler, gets bring-your-own-fees for free, etc. > > I suppose there is some *slight* improvement in that with your proposal, > Alice *can* use revoke tx -> refund tx #2, but still, if Alice is insane > then it could very well mess with the protocol by instead using refund tx > #1. > Thus, if Bob wants to survive in an environment where Alices are possibly > insane (e.g. the real world), it should do everything in its power to > ensure that the BTC txo is spent before the timeout of refund tx #1, if > refund tx #1 exists at all. > And if Bob is already going to do that, then Alice and Bob might as well > just use my counterproposal etc etc. > > > >adding two CPFP outputs (one for each participant) > > > > There seems to be a situation where RBF can be disabled by the other > party, but I'm not sure I see it... Why would a single output spendable by > either key be insufficient? > > If one party quickly broadcasts a long chain of low-feerate transactions > on top of the single output, then the output is "pinned". > > Low feerate means it is undesirable for miners to mine it, because it pays > low for the amount of blockspace it has. > But because there is a long chain of transactions, the absolute fee of > that chain can be sizable, and we have a rule in RBF which, paraphrased, > goes something like "the replacing transaction should also have a higher > absolute fee than *all* the transactions it replaces", meaning the fee jump > that the other side has to offer *has to be* pretty big. > > If the other outputs of the tx are then multisig, then the pinning > participant can simply refuse to sign for those, and if the existing txes > spending the other outputs are relative-time-locked, they cannot be used to > CPFP the revoke tx onchain. > > This is why we eventually decided in Lightning to use two CPFP outpoints > rather than one, and are also realizing just how much of a headache the RBF > rules are, sigh. > > Still, in your proposed protocol the dependent transactions are all > relative-timelocked, so timely confirmation of the revoke tx is not > necessary, unlike in the case of Lightning where all HTLCs have to use an > absolute timelock because we have to coordinate multiple HTLCs in > forwarding and violation of the timelocks can lead to headaches and fund > loss and so on. > So maybe a single hook output, or even none at all, is workable. > > > > > >We could use `SIGHASH_SINGLE | SIGHASH_ANYONECANPAY` as well > > > > Allowing others to add inputs/outputs would introduce malleability. > Refund tx #2 and the timeout tx would become invalid. > > Ah, right, you still need `SIGHASH_ANYPREVOUT`/`SIGHASH_NOINPUT` for that. > > > >Bob cannot safely perform step 2 before getting both signatures for the > revoke tx > > > > That's right, as you guessed, he does receive a copy of the signed > revoke tx at protocol start. > > > > >>alternatively Bob can just spend before the timelock expires. > > >This seems to be the safest alternative > > > > I agree not giving Alice time to publish the revoke tx is safest, but > one does not preclude the other. The revoke tx is on an absolute timelock, > so spending it before that time means you don't have anything to > worry about, and spending it later means you'll have to be online and keep > an eye out. If staying online is not a problem, then fee wise that seems > preferable. As long as less than half of all valid (i.e. the timelock was > reached) revoke transactions get broadcast, you'll be saving on fees. > > In a world where Alice may be insane and mess with the protocol just to > grief Bob even if Alice loses its money (e.g. the real world), Bob should > not depend on Alice behaving correctly or politely, so it should still have > backup watchers set up in case it accidentally goes to sleep and so on. > > Regards, > ZmnSCPxj > --0000000000003e296105a586ca28 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi ZmnSCPxj,

>on completion of t= he protocol, if Bob lets the refund tx#1 become valid (i.e. does not spend = the BTC txo) then Alice can broadcast it, putting both their funds into cha= os

You forget, refund tx #1 has a script (which bt= w won't be visible with taproot): "Alice & Bob OR Alice in=C2= =A0+1 day" (relative) so if Alice broadcasts it after protocol complet= ion, she is just giving Bob the key to her LTC (note: if she's wise she= 'd move the LTC beforehand), but Bob doesn't lose the BTC because h= e has both keys and can just react before the relative timelock expires. No= chaos.

>This is why we eventually decided in L= ightning to use two CPFP outpoints rather than one

I appreciate the explanation. I see the problem now, and yes, that does se= em like a headache.

Cheers,
Ruben
<= /div>
O= n Wed, May 13, 2020 at 1:39 PM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
Good morning Ruben,

> Hi ZmnSCPxj,
>
> >potentially both Alice and Bob know all the secrets on the LTC sid= e and end up competing over it
>
> That's exactly right.
>
> >Bob can thus give a copy of the revoke tx with signature directly = to its favorite miner, forcing Alice to take 3 transactions
>
> Note that the timelock on the revoke tx is longer than the timelock on= refund tx #1. The idea is that Alice aborts the protocol by publishing ref= und tx #1 if the protocol hasn't reached step 4 in the svg by the time = it becomes valid. This should entirely mitigate the issue you're descri= bing.

But if refund tx #1 at all exists, then you drop to the same issue you obje= cted to with my proposal, which is that, on completion of the protocol, if = Bob lets the refund tx#1 become valid (i.e. does not spend the BTC txo) the= n Alice can broadcast it, putting both their funds into chaos.

So you might as well just use my counterproposal instead, which is simpler,= gets bring-your-own-fees for free, etc.

I suppose there is some *slight* improvement in that with your proposal, Al= ice *can* use revoke tx -> refund tx #2, but still, if Alice is insane t= hen it could very well mess with the protocol by instead using refund tx #1= .
Thus, if Bob wants to survive in an environment where Alices are possibly i= nsane (e.g. the real world), it should do everything in its power to ensure= that the BTC txo is spent before the timeout of refund tx #1, if refund tx= #1 exists at all.
And if Bob is already going to do that, then Alice and Bob might as well ju= st use my counterproposal etc etc.

> >adding two CPFP outputs (one for each participant)
>
> There seems to be a situation where RBF can be disabled by the other p= arty, but I'm not sure I see it... Why would a single output spendable = by either key be insufficient?

If one party quickly broadcasts a long chain of low-feerate transactions on= top of the single output, then the output is "pinned".

Low feerate means it is undesirable for miners to mine it, because it pays = low for the amount of blockspace it has.
But because there is a long chain of transactions, the absolute fee of that= chain can be sizable, and we have a rule in RBF which, paraphrased, goes s= omething like "the replacing transaction should also have a higher abs= olute fee than *all* the transactions it replaces", meaning the fee ju= mp that the other side has to offer *has to be* pretty big.

If the other outputs of the tx are then multisig, then the pinning particip= ant can simply refuse to sign for those, and if the existing txes spending = the other outputs are relative-time-locked, they cannot be used to CPFP the= revoke tx onchain.

This is why we eventually decided in Lightning to use two CPFP outpoints ra= ther than one, and are also realizing just how much of a headache the RBF r= ules are, sigh.

Still, in your proposed protocol the dependent transactions are all relativ= e-timelocked, so timely confirmation of the revoke tx is not necessary, unl= ike in the case of Lightning where all HTLCs have to use an absolute timelo= ck because we have to coordinate multiple HTLCs in forwarding and violation= of the timelocks can lead to headaches and fund loss and so on.
So maybe a single hook output, or even none at all, is workable.

>
> >We could use `SIGHASH_SINGLE | SIGHASH_ANYONECANPAY` as well
>
> Allowing others to add inputs/outputs would introduce malleability. Re= fund tx #2 and the timeout tx would become invalid.

Ah, right, you still need `SIGHASH_ANYPREVOUT`/`SIGHASH_NOINPUT` for that.<= br>
> >Bob cannot safely perform step 2 before getting both signatures fo= r the revoke tx
>
> That's right, as you guessed, he does receive a copy of the signed= revoke tx at protocol start.
>
> >>alternatively Bob can just spend before the timelock expires.<= br> > >This seems to be the safest alternative
>
> I agree not giving Alice time to publish the revoke tx is safest, but = one does not preclude the other. The revoke tx is on an absolute timelock, = so spending it before that time means you don't have anything to worry= =C2=A0about, and spending it later means you'll have to be online and k= eep an eye out. If staying online is not a problem, then fee wise that seem= s preferable. As long as less than half of all valid (i.e. the timelock was= reached)=C2=A0revoke transactions get broadcast, you'll be saving on f= ees.

In a world where Alice may be insane and mess with the protocol just to gri= ef Bob even if Alice loses its money (e.g. the real world), Bob should not = depend on Alice behaving correctly or politely, so it should still have bac= kup watchers set up in case it accidentally goes to sleep and so on.

Regards,
ZmnSCPxj
--0000000000003e296105a586ca28--