From: Ruben Somsen <rsomsen@gmail•com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] SAS: Succinct Atomic Swap
Date: Wed, 13 May 2020 14:33:21 +0200 [thread overview]
Message-ID: <CAPv7TjaG3jxCDv5PtSeLeXi3Emo1_hvgYP1KEQg8+LU41SUqqQ@mail.gmail.com> (raw)
In-Reply-To: <oIiSWK9E-M53lQD3BxO8vQBHzZ7vUSISzDElSaA0v3BFS4_WeFAHNybHttJLstlAiz6Xem4VWy9Ktp6hgklsPqkvqnKVMOUAuA_aKpjOFLA=@protonmail.com>
[-- Attachment #1: Type: text/plain, Size: 5686 bytes --]
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 <ZmnSCPxj@protonmail•com> 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
>
[-- Attachment #2: Type: text/html, Size: 6382 bytes --]
next prev parent reply other threads:[~2020-05-13 12:33 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-11 15:29 Ruben Somsen
2020-05-11 16:45 ` ZmnSCPxj
2020-05-11 17:50 ` Ruben Somsen
2020-05-12 4:41 ` ZmnSCPxj
2020-06-03 9:04 ` Dmitry Petukhov
2020-06-03 14:36 ` ZmnSCPxj
2020-05-12 22:50 ` Chris Belcher
2020-05-12 6:10 ` Lloyd Fournier
2020-05-12 6:50 ` Lloyd Fournier
2020-05-12 11:30 ` Ruben Somsen
2020-05-12 11:34 ` Ruben Somsen
2020-05-12 15:05 ` ZmnSCPxj
2020-05-12 16:30 ` Ruben Somsen
2020-05-13 8:39 ` ZmnSCPxj
2020-05-13 9:57 ` Ruben Somsen
2020-05-13 9:58 ` Ruben Somsen
2020-05-13 11:39 ` ZmnSCPxj
2020-05-13 12:33 ` Ruben Somsen [this message]
2020-05-15 4:39 ` ZmnSCPxj
2020-05-15 19:47 ` Ruben Somsen
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=CAPv7TjaG3jxCDv5PtSeLeXi3Emo1_hvgYP1KEQg8+LU41SUqqQ@mail.gmail.com \
--to=rsomsen@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