From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Ruben Somsen <rsomsen@gmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] SAS: Succinct Atomic Swap
Date: Wed, 13 May 2020 11:39:10 +0000 [thread overview]
Message-ID: <oIiSWK9E-M53lQD3BxO8vQBHzZ7vUSISzDElSaA0v3BFS4_WeFAHNybHttJLstlAiz6Xem4VWy9Ktp6hgklsPqkvqnKVMOUAuA_aKpjOFLA=@protonmail.com> (raw)
In-Reply-To: <CAPv7TjYewKe=Gt8io+uGNzeKmAq758vH9aB2OpFt=rGth8DZEg@mail.gmail.com>
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
next prev parent reply other threads:[~2020-05-13 11:39 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 [this message]
2020-05-13 12:33 ` Ruben Somsen
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='oIiSWK9E-M53lQD3BxO8vQBHzZ7vUSISzDElSaA0v3BFS4_WeFAHNybHttJLstlAiz6Xem4VWy9Ktp6hgklsPqkvqnKVMOUAuA_aKpjOFLA=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=rsomsen@gmail$(echo .)com \
/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