public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed

* [bitcoin-dev] SAS: Succinct Atomic Swap
@ 2020-05-11 15:29 Ruben Somsen
  2020-05-11 16:45 ` ZmnSCPxj
  2020-05-12  6:10 ` Lloyd Fournier
  0 siblings, 2 replies; 20+ messages in thread
From: Ruben Somsen @ 2020-05-11 15:29 UTC (permalink / raw)
  To: Bitcoin Protocol Discussion

Works today with single signer ECDSA adaptor signatures[0], or with
Schnorr + MuSig.

Diagram here:
https://gist.github.com/RubenSomsen/8853a66a64825716f51b409be528355f#file-succinctatomicswap-svg


Advantages:

- Requires merely two on-chain transactions for successful completion,
as opposed to four
- Scriptless, and one of the chains doesn't need to support timelocks
- Can be used for efficient privacy swaps, e.g. Payswap[1]


Disadvantages:

- Access to money is contingent on remembering secrets (backup complexity)
- Online/watchtower requirement for the timelock supporting chain (not
needed with 3 tx protocol)


Protocol steps:


0.) Alice & Bob pre-sign the following transactions, with exception of
the signatures in [brackets]:

- success_tx (money to Bob): [sigSuccessAlice] + [sigSuccessBob]
- revoke_tx (timelock): sigRevokeAlice + sigRevokeBob, which must then
be spent by:
  -- refund_tx (relative timelock, refund to Alice): [sigRefundAlice]
+ {sigRefundBob}
  -- timeout_tx (longer relative timelock, money to Bob):
sigTimeoutAlice + [sigTimeoutBob]

{sigRefundBob} is an adaptor signature, which requires secretAlice to complete


1.) Alice proceeds to lock up 1 BTC with Bob, using keyAlice & keyBob as pubkeys

If protocol is aborted after step 1:

- Alice publishes the revoke_tx, followed by the refund_tx &
sigRefundBob, to get her BTC back
- If Alice neglects to publish the refund_tx in time, Bob will claim
the BTC with the timeout_tx


2.) Bob locks up altcoins with Alice, using secretAlice & secretBob as pubkeys

If protocol is aborted after step 2:

- Once Alice publishes sigRefundBob, Bob learns secretAlice and
regains control over the altcoins


3.) Protocol completion:

- Alice hands adaptor signature {sigSuccessAlice} to Bob, which
requires secretBob to complete
- Bob could now claim the BTC via the success_tx, reveal secretBob,
and thus give Alice control over the altcoins (= 3 tx protocol)
- Instead, Bob simply hands secretBob to Alice
- Likewise, Alice hands keyAlice to Bob to forego her claim on the refund_tx
- Bob continues to monitor the chain, because he'll have to respond if
Alice ever publishes the revoke_tx


More graceful protocol failure:

If the protocol aborts after step 1, Alice would have been forced to
make three transactions in total, while Bob has made none. We can
reduce that to two by introducing a second refund_tx with timelock
that can be published ahead of the revoke_tx and directly spends from
the funding transaction. Publishing this transaction would also reveal
secretAlice to Bob via an adaptor signature. In the 3 tx protocol,
this output can go directly to Alice. In the 2 tx protocol with
online/watchtower requirement, this output needs a script: spendable
by Alice + Bob right away OR by Alice after a relative timelock. It is
important to note that this transaction must NOT be published during
step 3. Once Bob can complete the success_tx, the revoke_tx is needed
to invalidate the success_tx prior to revealing secretAlice.


FAQ:

- Why not allow Alice to still claim the altcoins if she accidentally
lets Bob publish the timeout_tx?

Alice could send the revoke_tx at the same time, revealing both
secrets and causing likely losses. This can be solved by adding yet
another transaction, but it wouldn't be efficient and wouldn't
motivate Alice to behave.

- Is it possible to implement this protocol on chains which only
support absolute timelocks?

Yes, but then Bob must spend his swapped coins before the timelock
expires (or use the 3 tx protocol). Be aware that the revoke_tx MUST
confirm before the timeout_tx becomes valid, which may become a
problem if fees suddenly rise. The refund_tx can also not be allowed
to CPFP the timeout_tx, as they must confirm independently in order to
invalidate the success_tx first.

- Can't Alice just publish the revoke_tx after protocol completion?

Yes, she'd first have to move the altcoins (to invalidate
secretAlice), and could then try to claim the BTC by publishing the
revoke_tx, forcing Bob to react on-chain before the refund_tx becomes
valid. The eltoo[2] method of paying for fees (requires
sighash_anyprevout) or a second CPFP-able output may be an improvement
here (and also mitigates fee rising issues), but note that this also
increases the required amount of tx data if the protocol doesn't
complete successfully.

- Can this be made to work with hash locks?

Yes, by making the altcoins spendable via sigAlice + preimageBob OR
sigBob + preimageAlice, and ensuring the contracts on the BTC side
reveal either pre-image. Do note that this is not scriptless and will
thus increase the transaction size.


Open question:

Perhaps it's possible to perform an atomic swap in and out of
Lightning with only a single on-chain transaction. This would require
some kind of secondary set of HTLCs, allowing the sender to cancel a
Lightning payment by revealing a secret after a certain period of
time.


-- Ruben Somsen




Thanks to Lloyd Fournier for feedback and review.

If you find any further errors, I will endeavor to fix them here:
https://gist.github.com/RubenSomsen/8853a66a64825716f51b409be528355f


Related work:

Tier Nolan Atomic Swap:
https://bitcointalk.org/index.php?topic=193281.msg2224949#msg2224949
Monero Atomic Swap:
https://github.com/h4sh3d/xmr-btc-atomic-swap/blob/master/README.md


[0] https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-November/002316.html

[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017595.html

[2] https://blockstream.com/eltoo.pdf


^ permalink raw reply	[flat|nested] 20+ messages in thread

• * Re: [bitcoin-dev] SAS: Succinct Atomic Swap
    2020-05-11 15:29 [bitcoin-dev] SAS: Succinct Atomic Swap Ruben Somsen
  @ 2020-05-11 16:45 ` ZmnSCPxj
    2020-05-11 17:50   ` Ruben Somsen
    2020-05-12  6:10 ` Lloyd Fournier
    1 sibling, 1 reply; 20+ messages in thread
  From: ZmnSCPxj @ 2020-05-11 16:45 UTC (permalink / raw)
    To: Ruben Somsen, Bitcoin Protocol Discussion
  
  Good morning Ruben,
  
  CoinSwap for privacy is practically a "cross" chain atomic swap with the same chain and token for both sides of the swap, see also this set of ideas: https://github.com/AdamISZ/CoinSwapCS/issues/53
  
  "Instead, Bob simply hands secretBob to Alice" is basically the same as private key turnover, as best as I can understand it, and gives significant advantages, also described in passing here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-May/017816.html
  
  Overall, this looks very much like a working CoinSwap as well.
  
  The Refund tx does not need anything more than a 2-of-2 script.
  The "OR Alice in +1 day" branch can be implemented, at least on Bitcoin and similar blockchains, by signing a specific `nSequence`, or if the chain forking predates BIP68, by using absolute locktimes and signing a specific `nLockTime`, with the destination being just "Alice".
  This should help privacy, as now all `scriptPubKey`s will be 2-of-2 (or P2PKH with 2p-ECDSA).
  
  (It strikes me that the relative locktime is unnecessary on the output of this refund tx --- as long as both participants agree on either Alice or Bob having a longer locktime, you can just use the locktime on the refund tx directly as backout; see the topic "`nLockTime`-protected Backouts" on the CoinSwapCS issue link)
  
  If you are willing to accept protocol complexity, having a variety of different versions of the transactions with different feerates could be used rather than the Decker-Russell-Osuntokun "eltoo" bring-your-own-fees method.
  In terms of privacy this is better as you would not be using anything other than the most boring `SIGHASH_ALL` signing flag, whereas the Decker-Russell-Osuntokun will be identifiable onchain (and thus possibly flag the transaction as "of interest" to surveillors) due to use of `SIGHASH_ANYPREVOUT`.
  As long as the one resolving a particular side of the swap is the one that ocmpletes the signature (which I believe holds true for all branches?) then it would select the version of the transaction with the best feerate, which it effectively pays out to what it recovers.
  
  
  Regards,
  ZmnSCPxj
  
  
  > Works today with single signer ECDSA adaptor signatures[0], or with
  > Schnorr + MuSig.
  >
  > Diagram here:
  > https://gist.github.com/RubenSomsen/8853a66a64825716f51b409be528355f#file-succinctatomicswap-svg
  >
  > Advantages:
  >
  > -   Requires merely two on-chain transactions for successful completion,
  >     as opposed to four
  >
  > -   Scriptless, and one of the chains doesn't need to support timelocks
  > -   Can be used for efficient privacy swaps, e.g. Payswap[1]
  >
  >     Disadvantages:
  >
  > -   Access to money is contingent on remembering secrets (backup complexity)
  > -   Online/watchtower requirement for the timelock supporting chain (not
  >     needed with 3 tx protocol)
  >
  >     Protocol steps:
  >
  >     0.) Alice & Bob pre-sign the following transactions, with exception of
  >     the signatures in [brackets]:
  >
  > -   success_tx (money to Bob): [sigSuccessAlice] + [sigSuccessBob]
  > -   revoke_tx (timelock): sigRevokeAlice + sigRevokeBob, which must then
  >     be spent by:
  >     -- refund_tx (relative timelock, refund to Alice): [sigRefundAlice]
  >
  >
  > -   {sigRefundBob}
  >     -- timeout_tx (longer relative timelock, money to Bob):
  >     sigTimeoutAlice + [sigTimeoutBob]
  >
  >     {sigRefundBob} is an adaptor signature, which requires secretAlice to complete
  >
  >     1.) Alice proceeds to lock up 1 BTC with Bob, using keyAlice & keyBob as pubkeys
  >
  >     If protocol is aborted after step 1:
  >
  >
  > -   Alice publishes the revoke_tx, followed by the refund_tx &
  >     sigRefundBob, to get her BTC back
  >
  > -   If Alice neglects to publish the refund_tx in time, Bob will claim
  >     the BTC with the timeout_tx
  >
  >     2.) Bob locks up altcoins with Alice, using secretAlice & secretBob as pubkeys
  >
  >     If protocol is aborted after step 2:
  >
  > -   Once Alice publishes sigRefundBob, Bob learns secretAlice and
  >     regains control over the altcoins
  >
  >     3.) Protocol completion:
  >
  > -   Alice hands adaptor signature {sigSuccessAlice} to Bob, which
  >     requires secretBob to complete
  >
  > -   Bob could now claim the BTC via the success_tx, reveal secretBob,
  >     and thus give Alice control over the altcoins (= 3 tx protocol)
  >
  > -   Instead, Bob simply hands secretBob to Alice
  > -   Likewise, Alice hands keyAlice to Bob to forego her claim on the refund_tx
  > -   Bob continues to monitor the chain, because he'll have to respond if
  >     Alice ever publishes the revoke_tx
  >
  >     More graceful protocol failure:
  >
  >     If the protocol aborts after step 1, Alice would have been forced to
  >     make three transactions in total, while Bob has made none. We can
  >     reduce that to two by introducing a second refund_tx with timelock
  >     that can be published ahead of the revoke_tx and directly spends from
  >     the funding transaction. Publishing this transaction would also reveal
  >     secretAlice to Bob via an adaptor signature. In the 3 tx protocol,
  >     this output can go directly to Alice. In the 2 tx protocol with
  >     online/watchtower requirement, this output needs a script: spendable
  >     by Alice + Bob right away OR by Alice after a relative timelock. It is
  >     important to note that this transaction must NOT be published during
  >     step 3. Once Bob can complete the success_tx, the revoke_tx is needed
  >     to invalidate the success_tx prior to revealing secretAlice.
  >
  >     FAQ:
  >
  > -   Why not allow Alice to still claim the altcoins if she accidentally
  >     lets Bob publish the timeout_tx?
  >
  >     Alice could send the revoke_tx at the same time, revealing both
  >     secrets and causing likely losses. This can be solved by adding yet
  >     another transaction, but it wouldn't be efficient and wouldn't
  >     motivate Alice to behave.
  >
  > -   Is it possible to implement this protocol on chains which only
  >     support absolute timelocks?
  >
  >     Yes, but then Bob must spend his swapped coins before the timelock
  >     expires (or use the 3 tx protocol). Be aware that the revoke_tx MUST
  >     confirm before the timeout_tx becomes valid, which may become a
  >     problem if fees suddenly rise. The refund_tx can also not be allowed
  >     to CPFP the timeout_tx, as they must confirm independently in order to
  >     invalidate the success_tx first.
  >
  > -   Can't Alice just publish the revoke_tx after protocol completion?
  >
  >     Yes, she'd first have to move the altcoins (to invalidate
  >     secretAlice), and could then try to claim the BTC by publishing the
  >     revoke_tx, forcing Bob to react on-chain before the refund_tx becomes
  >     valid. The eltoo[2] method of paying for fees (requires
  >     sighash_anyprevout) or a second CPFP-able output may be an improvement
  >     here (and also mitigates fee rising issues), but note that this also
  >     increases the required amount of tx data if the protocol doesn't
  >     complete successfully.
  >
  > -   Can this be made to work with hash locks?
  >
  >     Yes, by making the altcoins spendable via sigAlice + preimageBob OR
  >     sigBob + preimageAlice, and ensuring the contracts on the BTC side
  >     reveal either pre-image. Do note that this is not scriptless and will
  >     thus increase the transaction size.
  >
  >     Open question:
  >
  >     Perhaps it's possible to perform an atomic swap in and out of
  >     Lightning with only a single on-chain transaction. This would require
  >     some kind of secondary set of HTLCs, allowing the sender to cancel a
  >     Lightning payment by revealing a secret after a certain period of
  >     time.
  >
  >     -- Ruben Somsen
  >
  >     Thanks to Lloyd Fournier for feedback and review.
  >
  >     If you find any further errors, I will endeavor to fix them here:
  >     https://gist.github.com/RubenSomsen/8853a66a64825716f51b409be528355f
  >
  >     Related work:
  >
  >     Tier Nolan Atomic Swap:
  >     https://bitcointalk.org/index.php?topic=193281.msg2224949#msg2224949
  >     Monero Atomic Swap:
  >     https://github.com/h4sh3d/xmr-btc-atomic-swap/blob/master/README.md
  >
  >     [0] https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-November/002316.html
  >
  >     [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017595.html
  >
  >     [2] https://blockstream.com/eltoo.pdf
  >
  >
  > bitcoin-dev mailing list
  > bitcoin-dev@lists•linuxfoundation.org
  > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
  
  
  
  
  ^ permalink raw reply	[flat|nested] 20+ messages in thread

• • * Re: [bitcoin-dev] SAS: Succinct Atomic Swap
      2020-05-11 16:45 ` ZmnSCPxj
    @ 2020-05-11 17:50   ` Ruben Somsen
      2020-05-12  4:41     ` ZmnSCPxj
      2020-05-12 22:50     ` Chris Belcher
      0 siblings, 2 replies; 20+ messages in thread
    From: Ruben Somsen @ 2020-05-11 17:50 UTC (permalink / raw)
      To: ZmnSCPxj; +Cc: Bitcoin Protocol Discussion
    
    Hi ZmnSCPxj,
    
    Thanks for your feedback :)
    
    >CoinSwap for privacy is practically a "cross" chain atomic swap with the same chain and token for both sides of the swap
    
    I agree, I didn't mean to imply that was new, only that this protocol
    makes it more efficient.
    
    >"Instead, Bob simply hands secretBob to Alice" is basically the same as private key turnover
    
    Thanks for the link. I will add it to the links at the bottom of the
    write-up, as I agree it's related. Do note there are a few key
    differences:
    
    - The swap is set up in an "asymmetric" way with only timelocks on one
    side, so on the other side the swap *never* expires
    - The timelocks are set up in such a way that the swap does not expire
    unless Alice starts the relative timelock countdown (the revoke
    transaction)
    - This relative timelock setup comes practically for free, because the
    asymmetry naturally requires that kind of setup
    
    >The "OR Alice in +1 day" branch can be implemented, at least on Bitcoin and similar blockchains, by signing a specific `nSequence`
    
    "OR Alice in +1 day" is "refund transaction #1" from the diagram. If
    I'm not mistaken, the change you are suggesting is exactly how "refund
    transaction #2" is constructed. Note that #1 and #2 serve the same
    purpose. Strictly speaking, #1 is not needed at all, but it's there to
    give Alice the option to back out of the swap in two transactions as
    opposed to three.
    
    >It strikes me that the relative locktime is unnecessary on the output of this refund tx
    
    I believe I addressed this in the FAQ section (the question about
    absolute timelocks). An absolute timelock is possible, but you then
    need to make absolutely sure that the revoke transaction confirms in
    time, otherwise the protocol can fail (namely after Bob has received a
    copy of the success transaction and just waits and does nothing). You
    also lose the ability to keep the channel open indefinitely.
    
    >having a variety of different versions of the transactions with different feerates could be used
    
    That's a good point.
    
    >As long as the one resolving a particular side of the swap is the one that ocmpletes the signature (which I believe holds true for all branches?)
    
    Unfortunately this does not hold for the revoke transaction. It would
    be a bit awkward if Alice had a high fee copy after the protocol
    completes. She could send it to the blockchain and essentially Bob
    would be paying for it. I'm not as concerned about the other
    transactions, because those could all be bumped with CPFP if needed,
    but having different feerates would be nice.
    
    And a general comment about privacy: it seems inevitable that some
    information will be leaked if the protocol does not complete
    cooperatively. As long as the cooperative case is not traceable, that
    seems about as good as it can get. That's my view, at least. I'd be
    curious to hear if you see that differently.
    
    Cheers,
    Ruben
    
    
    
    On Mon, May 11, 2020 at 6:45 PM ZmnSCPxj <ZmnSCPxj@protonmail•com> wrote:
    >
    > Good morning Ruben,
    >
    > CoinSwap for privacy is practically a "cross" chain atomic swap with the same chain and token for both sides of the swap, see also this set of ideas: https://github.com/AdamISZ/CoinSwapCS/issues/53
    >
    > "Instead, Bob simply hands secretBob to Alice" is basically the same as private key turnover, as best as I can understand it, and gives significant advantages, also described in passing here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-May/017816.html
    >
    > Overall, this looks very much like a working CoinSwap as well.
    >
    > The Refund tx does not need anything more than a 2-of-2 script.
    > The "OR Alice in +1 day" branch can be implemented, at least on Bitcoin and similar blockchains, by signing a specific `nSequence`, or if the chain forking predates BIP68, by using absolute locktimes and signing a specific `nLockTime`, with the destination being just "Alice".
    > This should help privacy, as now all `scriptPubKey`s will be 2-of-2 (or P2PKH with 2p-ECDSA).
    >
    > (It strikes me that the relative locktime is unnecessary on the output of this refund tx --- as long as both participants agree on either Alice or Bob having a longer locktime, you can just use the locktime on the refund tx directly as backout; see the topic "`nLockTime`-protected Backouts" on the CoinSwapCS issue link)
    >
    > If you are willing to accept protocol complexity, having a variety of different versions of the transactions with different feerates could be used rather than the Decker-Russell-Osuntokun "eltoo" bring-your-own-fees method.
    > In terms of privacy this is better as you would not be using anything other than the most boring `SIGHASH_ALL` signing flag, whereas the Decker-Russell-Osuntokun will be identifiable onchain (and thus possibly flag the transaction as "of interest" to surveillors) due to use of `SIGHASH_ANYPREVOUT`.
    > As long as the one resolving a particular side of the swap is the one that ocmpletes the signature (which I believe holds true for all branches?) then it would select the version of the transaction with the best feerate, which it effectively pays out to what it recovers.
    >
    >
    > Regards,
    > ZmnSCPxj
    >
    >
    > > Works today with single signer ECDSA adaptor signatures[0], or with
    > > Schnorr + MuSig.
    > >
    > > Diagram here:
    > > https://gist.github.com/RubenSomsen/8853a66a64825716f51b409be528355f#file-succinctatomicswap-svg
    > >
    > > Advantages:
    > >
    > > -   Requires merely two on-chain transactions for successful completion,
    > >     as opposed to four
    > >
    > > -   Scriptless, and one of the chains doesn't need to support timelocks
    > > -   Can be used for efficient privacy swaps, e.g. Payswap[1]
    > >
    > >     Disadvantages:
    > >
    > > -   Access to money is contingent on remembering secrets (backup complexity)
    > > -   Online/watchtower requirement for the timelock supporting chain (not
    > >     needed with 3 tx protocol)
    > >
    > >     Protocol steps:
    > >
    > >     0.) Alice & Bob pre-sign the following transactions, with exception of
    > >     the signatures in [brackets]:
    > >
    > > -   success_tx (money to Bob): [sigSuccessAlice] + [sigSuccessBob]
    > > -   revoke_tx (timelock): sigRevokeAlice + sigRevokeBob, which must then
    > >     be spent by:
    > >     -- refund_tx (relative timelock, refund to Alice): [sigRefundAlice]
    > >
    > >
    > > -   {sigRefundBob}
    > >     -- timeout_tx (longer relative timelock, money to Bob):
    > >     sigTimeoutAlice + [sigTimeoutBob]
    > >
    > >     {sigRefundBob} is an adaptor signature, which requires secretAlice to complete
    > >
    > >     1.) Alice proceeds to lock up 1 BTC with Bob, using keyAlice & keyBob as pubkeys
    > >
    > >     If protocol is aborted after step 1:
    > >
    > >
    > > -   Alice publishes the revoke_tx, followed by the refund_tx &
    > >     sigRefundBob, to get her BTC back
    > >
    > > -   If Alice neglects to publish the refund_tx in time, Bob will claim
    > >     the BTC with the timeout_tx
    > >
    > >     2.) Bob locks up altcoins with Alice, using secretAlice & secretBob as pubkeys
    > >
    > >     If protocol is aborted after step 2:
    > >
    > > -   Once Alice publishes sigRefundBob, Bob learns secretAlice and
    > >     regains control over the altcoins
    > >
    > >     3.) Protocol completion:
    > >
    > > -   Alice hands adaptor signature {sigSuccessAlice} to Bob, which
    > >     requires secretBob to complete
    > >
    > > -   Bob could now claim the BTC via the success_tx, reveal secretBob,
    > >     and thus give Alice control over the altcoins (= 3 tx protocol)
    > >
    > > -   Instead, Bob simply hands secretBob to Alice
    > > -   Likewise, Alice hands keyAlice to Bob to forego her claim on the refund_tx
    > > -   Bob continues to monitor the chain, because he'll have to respond if
    > >     Alice ever publishes the revoke_tx
    > >
    > >     More graceful protocol failure:
    > >
    > >     If the protocol aborts after step 1, Alice would have been forced to
    > >     make three transactions in total, while Bob has made none. We can
    > >     reduce that to two by introducing a second refund_tx with timelock
    > >     that can be published ahead of the revoke_tx and directly spends from
    > >     the funding transaction. Publishing this transaction would also reveal
    > >     secretAlice to Bob via an adaptor signature. In the 3 tx protocol,
    > >     this output can go directly to Alice. In the 2 tx protocol with
    > >     online/watchtower requirement, this output needs a script: spendable
    > >     by Alice + Bob right away OR by Alice after a relative timelock. It is
    > >     important to note that this transaction must NOT be published during
    > >     step 3. Once Bob can complete the success_tx, the revoke_tx is needed
    > >     to invalidate the success_tx prior to revealing secretAlice.
    > >
    > >     FAQ:
    > >
    > > -   Why not allow Alice to still claim the altcoins if she accidentally
    > >     lets Bob publish the timeout_tx?
    > >
    > >     Alice could send the revoke_tx at the same time, revealing both
    > >     secrets and causing likely losses. This can be solved by adding yet
    > >     another transaction, but it wouldn't be efficient and wouldn't
    > >     motivate Alice to behave.
    > >
    > > -   Is it possible to implement this protocol on chains which only
    > >     support absolute timelocks?
    > >
    > >     Yes, but then Bob must spend his swapped coins before the timelock
    > >     expires (or use the 3 tx protocol). Be aware that the revoke_tx MUST
    > >     confirm before the timeout_tx becomes valid, which may become a
    > >     problem if fees suddenly rise. The refund_tx can also not be allowed
    > >     to CPFP the timeout_tx, as they must confirm independently in order to
    > >     invalidate the success_tx first.
    > >
    > > -   Can't Alice just publish the revoke_tx after protocol completion?
    > >
    > >     Yes, she'd first have to move the altcoins (to invalidate
    > >     secretAlice), and could then try to claim the BTC by publishing the
    > >     revoke_tx, forcing Bob to react on-chain before the refund_tx becomes
    > >     valid. The eltoo[2] method of paying for fees (requires
    > >     sighash_anyprevout) or a second CPFP-able output may be an improvement
    > >     here (and also mitigates fee rising issues), but note that this also
    > >     increases the required amount of tx data if the protocol doesn't
    > >     complete successfully.
    > >
    > > -   Can this be made to work with hash locks?
    > >
    > >     Yes, by making the altcoins spendable via sigAlice + preimageBob OR
    > >     sigBob + preimageAlice, and ensuring the contracts on the BTC side
    > >     reveal either pre-image. Do note that this is not scriptless and will
    > >     thus increase the transaction size.
    > >
    > >     Open question:
    > >
    > >     Perhaps it's possible to perform an atomic swap in and out of
    > >     Lightning with only a single on-chain transaction. This would require
    > >     some kind of secondary set of HTLCs, allowing the sender to cancel a
    > >     Lightning payment by revealing a secret after a certain period of
    > >     time.
    > >
    > >     -- Ruben Somsen
    > >
    > >     Thanks to Lloyd Fournier for feedback and review.
    > >
    > >     If you find any further errors, I will endeavor to fix them here:
    > >     https://gist.github.com/RubenSomsen/8853a66a64825716f51b409be528355f
    > >
    > >     Related work:
    > >
    > >     Tier Nolan Atomic Swap:
    > >     https://bitcointalk.org/index.php?topic=193281.msg2224949#msg2224949
    > >     Monero Atomic Swap:
    > >     https://github.com/h4sh3d/xmr-btc-atomic-swap/blob/master/README.md
    > >
    > >     [0] https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-November/002316.html
    > >
    > >     [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017595.html
    > >
    > >     [2] https://blockstream.com/eltoo.pdf
    > >
    > >
    > > bitcoin-dev mailing list
    > > bitcoin-dev@lists•linuxfoundation.org
    > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
    >
    >
    
    
    ^ permalink raw reply	[flat|nested] 20+ messages in thread

  • • * Re: [bitcoin-dev] SAS: Succinct Atomic Swap
        2020-05-11 17:50   ` Ruben Somsen
      @ 2020-05-12  4:41     ` ZmnSCPxj
        2020-06-03  9:04       ` Dmitry Petukhov
        2020-05-12 22:50     ` Chris Belcher
        1 sibling, 1 reply; 20+ messages in thread
      From: ZmnSCPxj @ 2020-05-12  4:41 UTC (permalink / raw)
        To: Ruben Somsen; +Cc: Bitcoin Protocol Discussion
      
      Good morning Ruben,
      
      > Hi ZmnSCPxj,
      >
      > Thanks for your feedback :)
      >
      > > CoinSwap for privacy is practically a "cross" chain atomic swap with the same chain and token for both sides of the swap
      >
      > I agree, I didn't mean to imply that was new, only that this protocol
      > makes it more efficient.
      >
      
      Indeed; basically, any innovations in cross-chain swaps can be adapted to a CoinSwap (though not necessarily vice-versa, if a CoinSwap innovation requires certain specific blockchain features).
      
      > > "Instead, Bob simply hands secretBob to Alice" is basically the same as private key turnover
      >
      > Thanks for the link. I will add it to the links at the bottom of the
      > write-up, as I agree it's related. Do note there are a few key
      > differences:
      >
      > -   The swap is set up in an "asymmetric" way with only timelocks on one
      >     side, so on the other side the swap never expires
      >
      
      An interesting setup.
      
      So I was wondering why something like this would not work instead:
      
      0.  Alice has BTC, Bob has LTC, they agree on exchange rates and two future timelock L1 and L2 such that L1 < L2.
      1.  Alice creates keypairs Alice[0] Alice[1] Alice[2], Bob creates Bob[0] Bob[1] Bob[2], and share the pubkeys.
      2.  Alice creates, but does not sign, a funding tx on BTC whose output requires Alice[0] && Bob[0].
      3.  Bob creates a backout transaction spending the BTC funding txo, with an absolute timelock L1, whose output goes to Alice[2], then provides to Alice a signature for Bob[0] and requires an adaptor such that completing the signature with Alice[0] reveals Alice[1].
      
                               nLockTime L1
          BTC funding txo ---> Alice[0] && Bob[0]    --->  Alice[2]
                                   reveals Alice[1]
      
      4.  Alice creates a timeout transaction spending the BTC funding txo, with an absolute timelock L2, whose output goes to Bob[2], then provides to Bob a signature for Alice[0] and requires an adaptor such that completing the signature with Bob[0] reveals Bob[1].
      
                               nLockTime L2
          BTC funding txo ---> Alice[0] && Bob[0]    --->  Bob[2]
                                   reveals Bob[1]
      
      5.  Alice signs the BTC funding tx and broadcasts it.
      6.  Alice and Bob wait for the BTC funding tx to be confirmed.
      7.  Bob creates an LTC funding tx whose output requires Alice[1] && Bob[1].
      8.  Alice and Bob wait for the LTC funding tx to be confirmed.
      9.  Alice creates a success transaction spending the BTC funding txo, with no practical absolute timelock (current blockheight + 1), whose output goes to Bob[2], then provides to Bob a signature for Alice[0] and requires an adaptor such that completing the signature with Bob[0] reveals Bob[1].
      
                               nLockTime now
          BTC funding txo ---> Alice[0] && Bob[0]    --->  Bob[2]
                                   reveals Bob[1]
      
      10.  Bob gives the secret key of Bob[1] to Alice.
      11.  Alice gives the secret key of Alice[0] to Bob.
      12.  Bob claims the BTC funding txo before L1.
      
      Aborts and stalls:
      
      * Aborts before step 5 are safe: no money is ever committed yet.
        Stalls before step 5 can be promoted to aborts.
      * If aborted between step 5 and step 8, Alice reclaims her BTC via the backout transaction.
        Since Bob did not confirm any locked funds in LTC, revealing Alice[1] does not give Bob any extra funds it did not already have.
        If Bob stalls before step 8 Alice can abort at L1 using the backout transaction.
      * If Alice stalls at step 9, Bob can force the completion using the timeout transaction at L2, revealing Bob[1] and claiming the BTC.
      * If Alice instead aborts at step 9 using the backout transaction at L1, Bob learns Alice[1] and can reclaim its LTC.
      * Steps 10 and 11 are optional and "only" give Alice and Bob extra flexibility in what they can do with the funds (such as sweeping multiple swaps, RBFing, performing another swap, etc.), i.e. private key turnover.
        Bob can always claim the BTC funding txo before L1 by signing and broadcasting the success transaction.
      
      Would this not work?
      It requires that at least one chain involved supports witness segregation, in order to allow signing a dependent transaction before signing what it spends.
      
      This has the advantage of using only absolute timelocks, which are better for privacy since ordinary wallets like Bitcoin Core and C-Lightning use absolute timelocks for ordinary spends onchain.
      
      
      >
      > Unfortunately this does not hold for the revoke transaction. It would
      > be a bit awkward if Alice had a high fee copy after the protocol
      > completes. She could send it to the blockchain and essentially Bob
      > would be paying for it. I'm not as concerned about the other
      > transactions, because those could all be bumped with CPFP if needed,
      > but having different feerates would be nice.
      >
      > And a general comment about privacy: it seems inevitable that some
      > information will be leaked if the protocol does not complete
      > cooperatively. As long as the cooperative case is not traceable, that
      > seems about as good as it can get. That's my view, at least. I'd be
      > curious to hear if you see that differently.
      
      
      If the above counterproposal would work, it seems to me that all abort and stall scenarios "just" involve an absolute-timelock `SIGHASH_ALL` signed transaction, so it might not be so inevitable.
      
      In addition, the above counterproposal has the transaction signatures be completed by whoever ends up getting the money, so will rationally use the version with the best feerate.
      
      While leaking information in case of uncooperative abort is acceptable, it still seems to me that in this case, we can have a solution where an uncooperative abort has no information leak.
      My thesis is that, if relative locktimes are used as often as absolute locktimes for block-sniping-prevention and a decent Scriptless Script system, then all protocol aborts should be doable with no information leaks, at the cost of pre-signing a bunch of timelocked transactions.
      
      ---
      
      A sidenote as well, that if Alice typically uses an HD wallet, the UTXO on the LTC side would not be in that HD, and if Alice wants to cold-store the LTC, it should move the money as well into an HD pubkey.
      
      Regards,
      ZmnSCPxj
      
      
      ^ permalink raw reply	[flat|nested] 20+ messages in thread

    • • * Re: [bitcoin-dev] SAS: Succinct Atomic Swap
          2020-05-12  4:41     ` ZmnSCPxj
        @ 2020-06-03  9:04       ` Dmitry Petukhov
          2020-06-03 14:36         ` ZmnSCPxj
          0 siblings, 1 reply; 20+ messages in thread
        From: Dmitry Petukhov @ 2020-06-03  9:04 UTC (permalink / raw)
          To: bitcoin-dev
        
        I made a version of the TLA+ spec according to the suggested variant,
        as I understood it from your description. This version is in
        the separate branch in the SASwap repo, 'variant_ZmnSCPxj' [1]
        
        If I understood and specified your variant correctly, there is a
        deadlock possible after step 9, if Bob fails to publish success tx in
        time. After refund tx becomes spendable, Alice cannot publish it via
        mempool, because Bob can learn her secret and has a chance invalidate
        her refund tx by giving his success tx to friendly miner, while taking
        back the locked LTC because both secrets are known. At the same time,
        Bob cannot publish success tx via mempool, because then Alice can do
        the same thing, invalidating his success tx with refund tx via friednly
        miner.
        
        There is a possibility that this deadlock can be resolved if one
        participant indeed has possibility to confirm their tx directly,
        bypassing the mempool, so the counterparty won't learn the secret until
        transaction is in the block. But then this just raises the cost of the
        attack because the counterparty will need to invalidate (orphan) the
        whole block instead of just a transaction in the mempool, after
        learning the other secret from the recent block.
        
        [1] https://github.com/dgpv/SASwap_TLAplus_spec/tree/variant_ZmnSCPxj
        
        В Tue, 12 May 2020 04:41:43 +0000
        ZmnSCPxj via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
        
        > Good morning Ruben,
        > 
        > > Hi ZmnSCPxj,
        > >
        > > Thanks for your feedback :)
        > >  
        > > > CoinSwap for privacy is practically a "cross" chain atomic swap
        > > > with the same chain and token for both sides of the swap  
        > >
        > > I agree, I didn't mean to imply that was new, only that this
        > > protocol makes it more efficient.
        > >  
        > 
        > Indeed; basically, any innovations in cross-chain swaps can be
        > adapted to a CoinSwap (though not necessarily vice-versa, if a
        > CoinSwap innovation requires certain specific blockchain features).
        > 
        > > > "Instead, Bob simply hands secretBob to Alice" is basically the
        > > > same as private key turnover  
        > >
        > > Thanks for the link. I will add it to the links at the bottom of the
        > > write-up, as I agree it's related. Do note there are a few key
        > > differences:
        > >
        > > -   The swap is set up in an "asymmetric" way with only timelocks
        > > on one side, so on the other side the swap never expires
        > >  
        > 
        > An interesting setup.
        > 
        > So I was wondering why something like this would not work instead:
        > 
        > 0.  Alice has BTC, Bob has LTC, they agree on exchange rates and two
        > future timelock L1 and L2 such that L1 < L2. 1.  Alice creates
        > keypairs Alice[0] Alice[1] Alice[2], Bob creates Bob[0] Bob[1]
        > Bob[2], and share the pubkeys. 2.  Alice creates, but does not sign,
        > a funding tx on BTC whose output requires Alice[0] && Bob[0]. 3.  Bob
        > creates a backout transaction spending the BTC funding txo, with an
        > absolute timelock L1, whose output goes to Alice[2], then provides to
        > Alice a signature for Bob[0] and requires an adaptor such that
        > completing the signature with Alice[0] reveals Alice[1].
        > 
        >                          nLockTime L1
        >     BTC funding txo ---> Alice[0] && Bob[0]    --->  Alice[2]
        >                              reveals Alice[1]
        > 
        > 4.  Alice creates a timeout transaction spending the BTC funding txo,
        > with an absolute timelock L2, whose output goes to Bob[2], then
        > provides to Bob a signature for Alice[0] and requires an adaptor such
        > that completing the signature with Bob[0] reveals Bob[1].
        > 
        >                          nLockTime L2
        >     BTC funding txo ---> Alice[0] && Bob[0]    --->  Bob[2]
        >                              reveals Bob[1]
        > 
        > 5.  Alice signs the BTC funding tx and broadcasts it.
        > 6.  Alice and Bob wait for the BTC funding tx to be confirmed.
        > 7.  Bob creates an LTC funding tx whose output requires Alice[1] &&
        > Bob[1]. 8.  Alice and Bob wait for the LTC funding tx to be confirmed.
        > 9.  Alice creates a success transaction spending the BTC funding txo,
        > with no practical absolute timelock (current blockheight + 1), whose
        > output goes to Bob[2], then provides to Bob a signature for Alice[0]
        > and requires an adaptor such that completing the signature with
        > Bob[0] reveals Bob[1].
        > 
        >                          nLockTime now
        >     BTC funding txo ---> Alice[0] && Bob[0]    --->  Bob[2]
        >                              reveals Bob[1]
        > 
        > 10.  Bob gives the secret key of Bob[1] to Alice.
        > 11.  Alice gives the secret key of Alice[0] to Bob.
        > 12.  Bob claims the BTC funding txo before L1.
        > 
        > Aborts and stalls:
        > 
        > * Aborts before step 5 are safe: no money is ever committed yet.
        >   Stalls before step 5 can be promoted to aborts.
        > * If aborted between step 5 and step 8, Alice reclaims her BTC via
        > the backout transaction. Since Bob did not confirm any locked funds
        > in LTC, revealing Alice[1] does not give Bob any extra funds it did
        > not already have. If Bob stalls before step 8 Alice can abort at L1
        > using the backout transaction.
        > * If Alice stalls at step 9, Bob can force the completion using the
        > timeout transaction at L2, revealing Bob[1] and claiming the BTC.
        > * If Alice instead aborts at step 9 using the backout transaction at
        > L1, Bob learns Alice[1] and can reclaim its LTC.
        > * Steps 10 and 11 are optional and "only" give Alice and Bob extra
        > flexibility in what they can do with the funds (such as sweeping
        > multiple swaps, RBFing, performing another swap, etc.), i.e. private
        > key turnover. Bob can always claim the BTC funding txo before L1 by
        > signing and broadcasting the success transaction.
        > 
        > Would this not work?
        > It requires that at least one chain involved supports witness
        > segregation, in order to allow signing a dependent transaction before
        > signing what it spends.
        > 
        > This has the advantage of using only absolute timelocks, which are
        > better for privacy since ordinary wallets like Bitcoin Core and
        > C-Lightning use absolute timelocks for ordinary spends onchain.
        > 
        > 
        > >
        > > Unfortunately this does not hold for the revoke transaction. It
        > > would be a bit awkward if Alice had a high fee copy after the
        > > protocol completes. She could send it to the blockchain and
        > > essentially Bob would be paying for it. I'm not as concerned about
        > > the other transactions, because those could all be bumped with CPFP
        > > if needed, but having different feerates would be nice.
        > >
        > > And a general comment about privacy: it seems inevitable that some
        > > information will be leaked if the protocol does not complete
        > > cooperatively. As long as the cooperative case is not traceable,
        > > that seems about as good as it can get. That's my view, at least.
        > > I'd be curious to hear if you see that differently.  
        > 
        > 
        > If the above counterproposal would work, it seems to me that all
        > abort and stall scenarios "just" involve an absolute-timelock
        > `SIGHASH_ALL` signed transaction, so it might not be so inevitable.
        > 
        > In addition, the above counterproposal has the transaction signatures
        > be completed by whoever ends up getting the money, so will rationally
        > use the version with the best feerate.
        > 
        > While leaking information in case of uncooperative abort is
        > acceptable, it still seems to me that in this case, we can have a
        > solution where an uncooperative abort has no information leak. My
        > thesis is that, if relative locktimes are used as often as absolute
        > locktimes for block-sniping-prevention and a decent Scriptless Script
        > system, then all protocol aborts should be doable with no information
        > leaks, at the cost of pre-signing a bunch of timelocked transactions.
        > 
        > ---
        > 
        > A sidenote as well, that if Alice typically uses an HD wallet, the
        > UTXO on the LTC side would not be in that HD, and if Alice wants to
        > cold-store the LTC, it should move the money as well into an HD
        > pubkey.
        > 
        > Regards,
        > ZmnSCPxj
        > _______________________________________________
        > bitcoin-dev mailing list
        > bitcoin-dev@lists•linuxfoundation.org
        > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
        
        
        
        ^ permalink raw reply	[flat|nested] 20+ messages in thread

      • • * Re: [bitcoin-dev] SAS: Succinct Atomic Swap
            2020-06-03  9:04       ` Dmitry Petukhov
          @ 2020-06-03 14:36         ` ZmnSCPxj
            0 siblings, 0 replies; 20+ messages in thread
          From: ZmnSCPxj @ 2020-06-03 14:36 UTC (permalink / raw)
            To: Dmitry Petukhov; +Cc: bitcoin-dev
          
          Good morning Dmitry,
          
          > I made a version of the TLA+ spec according to the suggested variant,
          > as I understood it from your description. This version is in
          > the separate branch in the SASwap repo, 'variant_ZmnSCPxj' [1]
          >
          > If I understood and specified your variant correctly, there is a
          > deadlock possible after step 9, if Bob fails to publish success tx in
          > time. After refund tx becomes spendable, Alice cannot publish it via
          > mempool, because Bob can learn her secret and has a chance invalidate
          > her refund tx by giving his success tx to friendly miner, while taking
          > back the locked LTC because both secrets are known. At the same time,
          > Bob cannot publish success tx via mempool, because then Alice can do
          > the same thing, invalidating his success tx with refund tx via friednly
          > miner.
          
          Indeed, this is precisely the issue Ruben pointed out.
          
          Rationally, neither side will want this condition due to the deadlock and Bob will strive to avoid this, having a short real-world timeout after which Bob will force publication of the success tx if Alice does not respond in time.
          There *is* a reason why it says "Bob claims the BTC funding txo before L1."
          
          Of course, computers do crash occasionally, I am informed, so complete accidents may occur that way.
          This can be mitigated by running multiple servers who are given copies of the success tx, and which will publish it regardless after a short sidereal time duration, unless countermanded by the main server (i,e, a dead man switch system).
          With sufficient distribution the probability of this occurring can drop to negligible levels compared to other theoretical attacks.
          
          Regards,
          ZmnSCPxj
          
          
          
          ^ permalink raw reply	[flat|nested] 20+ messages in thread

    • * Re: [bitcoin-dev] SAS: Succinct Atomic Swap
        2020-05-11 17:50   ` Ruben Somsen
        2020-05-12  4:41     ` ZmnSCPxj
      @ 2020-05-12 22:50     ` Chris Belcher
        1 sibling, 0 replies; 20+ messages in thread
      From: Chris Belcher @ 2020-05-12 22:50 UTC (permalink / raw)
        To: Ruben Somsen, Bitcoin Protocol Discussion, ZmnSCPxj
      
      Hello list,
      
      This proposal is very cool. It is very useful to have a coinswap scheme
      requiring only two transactions.
      
      As well as improving the scalability of the system by saving block
      space, it also improves privacy because the coins could stay unspend for
      a long time, potentially indefinitely. While in the original coinswap
      proposal an analyst of the chain would always see a funding transaction
      followed closely in time by a success transaction, and this could be
      used as a fingerprint.
      
      On 11/05/2020 18:50, Ruben Somsen via bitcoin-dev wrote:
      > Hi ZmnSCPxj,
      > 
      > Thanks for your feedback :)
      >
      >> CoinSwap for privacy is practically a "cross" chain atomic swap with the same chain and token for both sides of the swap, see also this set of ideas: https://github.com/AdamISZ/CoinSwapCS/issues/53
      >>
      >> "Instead, Bob simply hands secretBob to Alice" is basically the same as private key turnover
      > 
      > Thanks for the link. I will add it to the links at the bottom of the
      > write-up, as I agree it's related. Do note there are a few key
      > differences:
      > 
      > - The swap is set up in an "asymmetric" way with only timelocks on one
      > side, so on the other side the swap *never* expires
      > - The timelocks are set up in such a way that the swap does not expire
      > unless Alice starts the relative timelock countdown (the revoke
      > transaction)
      > - This relative timelock setup comes practically for free, because the
      > asymmetry naturally requires that kind of setup
      
      You could create an old-style coinswap scheme using relative timelocks
      (with OP_CSV). The original proposal uses absolute timelocks but there's
      no reason relative timelocks can't be used instead, as long as the party
      who starts with knowledge of the preimage has a timelock further away in
      the future.
      
      Using relative timelocks and private key handover for old-style
      coinswaps would give us the same two-transaction effect and the
      corresponding efficiency and privacy gains.
      
      Of course we still don't get the effect that the swap on the other side
      never expires.
      
      A fun fact is that the idea of private key handover was mentioned as
      early as 2016 in the original Lightning Network paper. The bottom of
      page 27 says: "Instead  of disclosing the BR1a/BR1b signatures, it’s
      also possible to just disclose the private keys to the counterparty.
      This is more effective as described later in the key storage section".
      Although it looks like nobody thought to apply it to coinswap or
      realized the benefits.
      
      
      Regards
      CB
      
      
      ^ permalink raw reply	[flat|nested] 20+ messages in thread

• * Re: [bitcoin-dev] SAS: Succinct Atomic Swap
    2020-05-11 15:29 [bitcoin-dev] SAS: Succinct Atomic Swap Ruben Somsen
    2020-05-11 16:45 ` ZmnSCPxj
  @ 2020-05-12  6:10 ` Lloyd Fournier
    2020-05-12  6:50   ` Lloyd Fournier
    1 sibling, 1 reply; 20+ messages in thread
  From: Lloyd Fournier @ 2020-05-12  6:10 UTC (permalink / raw)
    To: Ruben Somsen, Bitcoin Protocol Discussion
  
  [-- Attachment #1: Type: text/plain, Size: 3936 bytes --]
  
  Ruben,
  
  In my opinion, this protocol is theoretical breakthrough as well as a
  practical protocol. Well done! I want to try and distil the core abstract
  ideas here as they appear to me. From my view, the protocol is a
  combination of two existing ideas and one new one:
  
  1. In atomic swaps you can make the refund transaction on one chain
  dependent on the refund on the other using secret revelation. Thus only one
  chain needs to have a timelock and the other refund can be conditioned on a
  secret that is revealed when that first refund goes through. (This idea is
  in the monero atomic swap [1]).
  2. Secret revelations can be used to give unconstrained spending power to
  one party. With an adaptor signature, rather than reveal a decryption key
  for another signature, you can just make the decryption key your signing
  key in the multisig so when you reveal it with the adaptor signautre the
  other party gains full knowledge of the private key for the output and can
  spend it arbitrarily. (this is just folklore and already what happens in
  HTLCs -- though it looks like lightning people are about to get rid of the
  unconstrained spend I think).
  
  The combination of these two ideas is novel in itself. The problem with
  idea (2) is that your unconstrained spending power over an output doesn't
  matter much if there is a pre-signed refund transaction spending from it --
  you still have to spend it before the refund becomes valid. But if you
  bring in idea (1)  this problem goes away!
  However, you are left with a new problem: What if the party with the
  timelock never refunds? Then the funds are locked forever.
  
  Here's where the truly novel part comes in. Ruben solves this by extending
  the standard *TLC contract:
  1. Bob redeem with secret
  2. Alice refund after T1
  3. Bob redeem without secret after T2
  
  We might call this a "Forced Refund *TLC". Alice must claim the refund or
  lose her money. This forces the refund secret revelation through
  punishment. If Alice refuses to refund Bob gets the asset he wanted anyway!
  
  The resulting protocol you get from applying these ideas is three
  transactions. At the end, one party has their funds in a non HD key output
  but if they want that they can just transfer it to an HD output in which
  case you get four transactions again. Thus I consider this to be a strict
  improvement over the four transaction protocol. Furthermore, one of the
  chains does not need a timelock. This is remarkable as the four transaction
  atomic swap is one of the most basic and most studied protocols. I
  considered it to be kind of "perfect" in a way. It just goes to show that
  this field is still very new and there are still things to discover in what
  we think is the most well trodden ground.
  
  I don't want to ignore that Ruben presents us with a two transaction
  protocol. He made a nice video explaining it here:
  https://www.youtube.com/watch?v=TlCxpdNScCA. It is harder to see the
  elegance of the idea in the two tx protocol because it involves revocation
  and relative timelocks etc. Actually, it is straightforward to naively
  achieve a two tx atomic swap with payment channels:
  1. Alice and Bob set up payment channels to each other on different chains
  2. They atomic swap the balances of the channels off-chain using HTLCs
  using the standard protocol.
  3. Since one party exclusively owns the funds in each channel the party
  with no funds simply reveals their key in the funding OP_CHECKMULTISIG to
  the other
  4. Both parties now watch the chain to see if the other tries to post a
  commitment transactions.
  
  The advantages that Ruben's two tx protocol has over this is that timelocks
  and monitoring is only needed on one of the chains. This is nothing to
  scoff at but for me the three tx protocol is the most elegant expression of
  the idea and the two tx protocol is a more optimised version that might
  make sense in some circumstances.
  
  [1] https://github.com/h4sh3d/xmr-btc-atomic-swap/blob/master/README.md
  
  LL
  
  [-- Attachment #2: Type: text/html, Size: 4498 bytes --]
  
  ^ permalink raw reply	[flat|nested] 20+ messages in thread

• • * Re: [bitcoin-dev] SAS: Succinct Atomic Swap
      2020-05-12  6:10 ` Lloyd Fournier
    @ 2020-05-12  6:50   ` Lloyd Fournier
      2020-05-12 11:30     ` Ruben Somsen
      0 siblings, 1 reply; 20+ messages in thread
    From: Lloyd Fournier @ 2020-05-12  6:50 UTC (permalink / raw)
      To: Ruben Somsen, Bitcoin Protocol Discussion
    
    [-- Attachment #1: Type: text/plain, Size: 445 bytes --]
    
    A quick correction to my post:
    
    >
    > Here's where the truly novel part comes in. Ruben solves this by extending
    > the standard *TLC contract:
    > 1. Bob redeem with secret
    > 2. Alice refund after T1
    > 3. Bob redeem without secret after T2
    >
    > This is actually:
    
    1. Bob redeem with redeem secret
    2. Alice refund after T1 with refund secret
    3. Bob redeem without secret after T2
    
    The fact that Alice reveals a secret when she refunds is crucial.
    
    LL
    
    [-- Attachment #2: Type: text/html, Size: 856 bytes --]
    
    ^ permalink raw reply	[flat|nested] 20+ messages in thread

  • • * Re: [bitcoin-dev] SAS: Succinct Atomic Swap
        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
        0 siblings, 2 replies; 20+ messages in thread
      From: Ruben Somsen @ 2020-05-12 11:30 UTC (permalink / raw)
        To: Bitcoin Protocol Discussion
      
      [-- Attachment #1: Type: text/plain, Size: 2292 bytes --]
      
      Hi ZmnSCPxj,
      
      >Would this not work?
      
      I considered and rejected that model for the following reason: there are
      moments where both Alice and Bob can claim the BTC. If they both attempt to
      do so, it also reveals both secrets, causing the LTC to also be claimable
      by both parties. This chaotic scenario is a failure mode that did not seem
      acceptable to me. The revoke transaction was specifically added to mitigate
      that issue (invalidating any attempt of Bob to claim the coins and reveal
      his secret). That said, it doesn't particularly seem in either party's
      interest wait until a moment where two timelocks become valid, so maybe it
      is not quite as bad as I thought. However, it still means that the
      incompetence/malevolence of one party can lead to losses for both parties.
      I have my doubts a gain in privacy in the uncooperative case is worth that
      risk.
      
      Of course it also reverts the protocol to 3 transactions, instead of 2, but
      regardless, not having to watch the chain is probably more practical in
      many cases. As an aside, if both chains support timelocks then we can
      ensure that the more expensive chain only receives one transaction.
      
      >if relative locktimes are used as often as absolute locktimes for
      block-sniping-prevention and a decent Scriptless Script system, then all
      protocol aborts should be doable with no information leaks
      
      I see your point, interesting observation.
      
      >A sidenote as well, that if Alice typically uses an HD wallet, the UTXO on
      the LTC side would not be in that HD, and if Alice wants to cold-store the
      LTC, it should move the money as well into an HD pubkey.
      
      Agreed, I had that listed as one of the disadvantages: "Access to money is
      contingent on remembering secrets (backup complexity)"
      
      Cheers,
      Ruben
      
      
      On Tue, May 12, 2020 at 8:50 AM Lloyd Fournier <lloyd.fourn@gmail•com>
      wrote:
      
      > A quick correction to my post:
      >
      >>
      >> Here's where the truly novel part comes in. Ruben solves this by
      >> extending the standard *TLC contract:
      >> 1. Bob redeem with secret
      >> 2. Alice refund after T1
      >> 3. Bob redeem without secret after T2
      >>
      >> This is actually:
      >
      > 1. Bob redeem with redeem secret
      > 2. Alice refund after T1 with refund secret
      > 3. Bob redeem without secret after T2
      >
      > The fact that Alice reveals a secret when she refunds is crucial.
      >
      > LL
      >
      
      [-- Attachment #2: Type: text/html, Size: 3064 bytes --]
      
      ^ permalink raw reply	[flat|nested] 20+ messages in thread

    • • * Re: [bitcoin-dev] SAS: Succinct Atomic Swap
          2020-05-12 11:30     ` Ruben Somsen
        @ 2020-05-12 11:34       ` Ruben Somsen
          2020-05-12 15:05       ` ZmnSCPxj
          1 sibling, 0 replies; 20+ messages in thread
        From: Ruben Somsen @ 2020-05-12 11:34 UTC (permalink / raw)
          To: Bitcoin Protocol Discussion
        
        [-- Attachment #1: Type: text/plain, Size: 3282 bytes --]
        
        Hi Lloyd,
        
        >In my opinion, this protocol is theoretical breakthrough as well as a
        practical protocol. Well done!
        
        Thanks for the kind praise, and for providing a summary of what you think
        makes the protocol useful. Your different perspective is undoubtedly useful
        for others who are trying to understand it.
        
        >We might call this a "Forced Refund *TLC"
        
        Good description, I like it.
        
        >The advantages that Ruben's two tx protocol has over this is that
        timelocks and monitoring is only needed on one of the chains.
        
        Well put, and I agree with your point that the traditional 4 tx protocol
        can also be turned into 2 tx with an online requirement. One minor thing to
        add is that this would make the 4 tx protocol more clunky in the
        non-cooperative case (a 4 tx timeout). In the SAS protocol it comes at no
        cost.
        
        Cheers,
        Ruben
        
        On Tue, May 12, 2020 at 1:30 PM Ruben Somsen <rsomsen@gmail•com> wrote:
        
        > Hi ZmnSCPxj,
        >
        > >Would this not work?
        >
        > I considered and rejected that model for the following reason: there are
        > moments where both Alice and Bob can claim the BTC. If they both attempt to
        > do so, it also reveals both secrets, causing the LTC to also be claimable
        > by both parties. This chaotic scenario is a failure mode that did not seem
        > acceptable to me. The revoke transaction was specifically added to mitigate
        > that issue (invalidating any attempt of Bob to claim the coins and reveal
        > his secret). That said, it doesn't particularly seem in either party's
        > interest wait until a moment where two timelocks become valid, so maybe it
        > is not quite as bad as I thought. However, it still means that the
        > incompetence/malevolence of one party can lead to losses for both parties.
        > I have my doubts a gain in privacy in the uncooperative case is worth that
        > risk.
        >
        > Of course it also reverts the protocol to 3 transactions, instead of 2,
        > but regardless, not having to watch the chain is probably more practical in
        > many cases. As an aside, if both chains support timelocks then we can
        > ensure that the more expensive chain only receives one transaction.
        >
        > >if relative locktimes are used as often as absolute locktimes for
        > block-sniping-prevention and a decent Scriptless Script system, then all
        > protocol aborts should be doable with no information leaks
        >
        > I see your point, interesting observation.
        >
        > >A sidenote as well, that if Alice typically uses an HD wallet, the UTXO
        > on the LTC side would not be in that HD, and if Alice wants to cold-store
        > the LTC, it should move the money as well into an HD pubkey.
        >
        > Agreed, I had that listed as one of the disadvantages: "Access to money is
        > contingent on remembering secrets (backup complexity)"
        >
        > Cheers,
        > Ruben
        >
        >
        > On Tue, May 12, 2020 at 8:50 AM Lloyd Fournier <lloyd.fourn@gmail•com>
        > wrote:
        >
        >> A quick correction to my post:
        >>
        >>>
        >>> Here's where the truly novel part comes in. Ruben solves this by
        >>> extending the standard *TLC contract:
        >>> 1. Bob redeem with secret
        >>> 2. Alice refund after T1
        >>> 3. Bob redeem without secret after T2
        >>>
        >>> This is actually:
        >>
        >> 1. Bob redeem with redeem secret
        >> 2. Alice refund after T1 with refund secret
        >> 3. Bob redeem without secret after T2
        >>
        >> The fact that Alice reveals a secret when she refunds is crucial.
        >>
        >> LL
        >>
        >
        
        [-- Attachment #2: Type: text/html, Size: 4479 bytes --]
        
        ^ permalink raw reply	[flat|nested] 20+ messages in thread

      • * Re: [bitcoin-dev] SAS: Succinct Atomic Swap
          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
          1 sibling, 1 reply; 20+ messages in thread
        From: ZmnSCPxj @ 2020-05-12 15:05 UTC (permalink / raw)
          To: Ruben Somsen; +Cc: Bitcoin Protocol Discussion
        
        Good morning Ruben,
        
        > >Would this not work?
        >
        > I considered and rejected that model for the following reason: there are moments where both Alice and Bob can claim the BTC. If they both attempt to do so, it also reveals both secrets, causing the LTC to also be claimable by both parties. This chaotic scenario is a failure mode that did not seem acceptable to me. The revoke transaction was specifically added to mitigate that issue (invalidating any attempt of Bob to claim the coins and reveal his secret). That said, it doesn't particularly seem in either party's interest wait until a moment where two timelocks become valid, so maybe it is not quite as bad as I thought. However, it still means that the incompetence/malevolence of one party can lead to losses for both parties. I have my doubts a gain in privacy in the uncooperative case is worth that risk.
        >
        > Of course it also reverts the protocol to 3 transactions, instead of 2, but regardless, not having to watch the chain is probably more practical in many cases. As an aside, if both chains support timelocks then we can ensure that the more expensive chain only receives one transaction.
        
        If the shortened refund transaction exists (labeled "refund transaction #1" in the SVG) then the same issue still occurs: after 1 day it is possible for either success or refund#1 to be broadcasted, leading to revelation of both secrets, leading to the same failure mode you described.
        
        Without the refund#1 in your proposal, Bob refusing cooperation after Alice puts the BTC into lock for 3 days and 2 further onchain transactions (with the refund#2 transaction being relative-locked, meaning it cannot be used to CPFP the revoke transaction; my formulation allows any of the result transactions to be CPFP directly by their beneficiaries).
        
        It seems to me that there is still an onlineness requirement in case Bob does not complete the protocol: once the revoke tx becomes valid an online Bob can cheat an offline Alice by broadcasting the revoke tx (which, if my understanding of the protocol is correct, the signatures are shared to both Alice and Bob).
        So Alice needs to be online starting at 2 days to 3 days in order to ensure it reclaims it funds.
        
        I have not seen the 2-tx variant video yet, as I prefer to read than listen, but I will also check it if I can find an opportunity.
        
        Regardless, the overall protocol of using 3 clauses in the swap, and reusing the privkey as the payment secret demanded by the pointlocks, is still a significant innovation.
        
        
        
        In the context of CoinSwap, a proposal is that a CoinSwap server would provide swapping service to incoming clients.
        Using my counterproposal, the Bob position can be taken by the server and the Alice position taken by the client.
        In this context, the L1 can be made reasonably close in the future and L2 far in the future, in which case Alice the client can be "weakly offline" most of the time until L2, and even in a protocol abort would be able to recover its funds.
        If the protocol completes, the server Bob can claim its funds before L1, and (with knowledge of Alice[0]) can immediately put it in a new funding tx for a new incoming client before L1, which is a fine tradeoff for server Bob since presumably Bob is always online.
        
        Regards,
        ZmnSCPxj
        
        
        
        
        ^ permalink raw reply	[flat|nested] 20+ messages in thread

      • • * Re: [bitcoin-dev] SAS: Succinct Atomic Swap
            2020-05-12 15:05       ` ZmnSCPxj
          @ 2020-05-12 16:30         ` Ruben Somsen
            2020-05-13  8:39           ` ZmnSCPxj
            0 siblings, 1 reply; 20+ messages in thread
          From: Ruben Somsen @ 2020-05-12 16:30 UTC (permalink / raw)
            To: ZmnSCPxj; +Cc: Bitcoin Protocol Discussion
          
          [-- Attachment #1: Type: text/plain, Size: 6909 bytes --]
          
          Hi ZmnSCPxj,
          
          >If the shortened refund transaction exists (labeled "refund transaction
          #1" in the SVG) then the same issue still occurs
          
          Yes, but there is one crucial difference: at that point in the protocol
          (Bob has the success transaction and then stops cooperating) Alice and Bob
          both had the opportunity not to take that path. Bob could have sent the
          success transaction, and Alice could have waited and sent the revoke
          transaction. They would essentially be "colluding" to fail.
          
          >Without the refund#1 in your proposal, Bob refusing cooperation after
          Alice puts the BTC into lock for 3 days and 2 further onchain transactions
          
          I'm not sure if I correctly understood what you're saying, but it's as
          follows:
          
          Refund #1 can only safely be used before the signed success tx is given to
          Bob. The cost to Alice at this point if Bob aborts is two on-chain
          transactions while Bob hasn't put anything on-chain yet.
          
          Refund #2 needs to be used after Bob receives the signed success tx. The
          cost to Alice is now three transactions, but Bob also went-on-chain by this
          point, so causing this wasn't costless to Bob and is thus a similar failure
          mode.
          
          >my formulation allows any of the result transactions to be CPFP directly
          by their beneficiaries
          
          Yes, that is indeed very nice. The way I set it up, insufficient fees can
          unfortunately cause delays, but they should not be able to cause losses.
          
          >there is still an onlineness requirement in case Bob does not complete the
          protocol
          
          Yes, that is very much the design. Alice needs to be on time with claiming
          her refund (and revealing her secret), otherwise Bob takes it.
          
          >I have not seen the 2-tx variant video yet, as I prefer to read than listen
          
          The video is not required, it just restates what is in the write-up. I
          personally find it easier to understand concepts from video, but I seem to
          be in the minority when I ask other devs about this. But let me reiterate
          one part you might be confused about (though you probably mostly get it
          already):
          
          The online requirement I was alluding to doesn't expire, and is
          specifically how the 2 tx SAS protocol is performed. Bob never broadcasts
          the success transaction (unless he prefers not to have to be online, i.e.
          the 3 tx SAS protocol) and instead Alice and Bob swap their keys: first Bob
          hands over secretAlice, then Alice hands over her key. Now the swap is
          complete, but Bob has to remain online to make sure Alice never attempts to
          broadcast her refund tx. It doesn't expire either because of the relative
          timelocks.
          
          Just take a look at the slide 6m8s into the video:
          https://youtu.be/TlCxpdNScCA?t=6m8s
          
          I also agree with your observation that alternatively Bob can just spend
          before the timelock expires.
          
          >Regardless, the overall protocol of using 3 clauses in the swap, and
          reusing the privkey as the payment secret demanded by the pointlocks, is
          still a significant innovation.
          
          I'm glad you like it :)
          
          >In the context of CoinSwap, a proposal is that a CoinSwap server would
          provide swapping service to incoming clients.
          
          That is an excellent use case that takes good advantage of the asymmetry of
          SAS. I completely agree with your observation that the "Bob" side is
          perfect for servers (online and/or spending again soon) and the "Alice"
          side is perfect for clients (settled in 1 tx). I similarly hope that this
          may pave the way for a practical implementation of Payswap between
          merchants and customers!
          
          Cheers,
          Ruben
          
          On Tue, May 12, 2020 at 5:06 PM ZmnSCPxj <ZmnSCPxj@protonmail•com> wrote:
          
          > Good morning Ruben,
          >
          > > >Would this not work?
          > >
          > > I considered and rejected that model for the following reason: there are
          > moments where both Alice and Bob can claim the BTC. If they both attempt to
          > do so, it also reveals both secrets, causing the LTC to also be claimable
          > by both parties. This chaotic scenario is a failure mode that did not seem
          > acceptable to me. The revoke transaction was specifically added to mitigate
          > that issue (invalidating any attempt of Bob to claim the coins and reveal
          > his secret). That said, it doesn't particularly seem in either party's
          > interest wait until a moment where two timelocks become valid, so maybe it
          > is not quite as bad as I thought. However, it still means that the
          > incompetence/malevolence of one party can lead to losses for both parties.
          > I have my doubts a gain in privacy in the uncooperative case is worth that
          > risk.
          > >
          > > Of course it also reverts the protocol to 3 transactions, instead of 2,
          > but regardless, not having to watch the chain is probably more practical in
          > many cases. As an aside, if both chains support timelocks then we can
          > ensure that the more expensive chain only receives one transaction.
          >
          > If the shortened refund transaction exists (labeled "refund transaction
          > #1" in the SVG) then the same issue still occurs: after 1 day it is
          > possible for either success or refund#1 to be broadcasted, leading to
          > revelation of both secrets, leading to the same failure mode you described.
          >
          > Without the refund#1 in your proposal, Bob refusing cooperation after
          > Alice puts the BTC into lock for 3 days and 2 further onchain transactions
          > (with the refund#2 transaction being relative-locked, meaning it cannot be
          > used to CPFP the revoke transaction; my formulation allows any of the
          > result transactions to be CPFP directly by their beneficiaries).
          >
          > It seems to me that there is still an onlineness requirement in case Bob
          > does not complete the protocol: once the revoke tx becomes valid an online
          > Bob can cheat an offline Alice by broadcasting the revoke tx (which, if my
          > understanding of the protocol is correct, the signatures are shared to both
          > Alice and Bob).
          > So Alice needs to be online starting at 2 days to 3 days in order to
          > ensure it reclaims it funds.
          >
          > I have not seen the 2-tx variant video yet, as I prefer to read than
          > listen, but I will also check it if I can find an opportunity.
          >
          > Regardless, the overall protocol of using 3 clauses in the swap, and
          > reusing the privkey as the payment secret demanded by the pointlocks, is
          > still a significant innovation.
          >
          >
          >
          > In the context of CoinSwap, a proposal is that a CoinSwap server would
          > provide swapping service to incoming clients.
          > Using my counterproposal, the Bob position can be taken by the server and
          > the Alice position taken by the client.
          > In this context, the L1 can be made reasonably close in the future and L2
          > far in the future, in which case Alice the client can be "weakly offline"
          > most of the time until L2, and even in a protocol abort would be able to
          > recover its funds.
          > If the protocol completes, the server Bob can claim its funds before L1,
          > and (with knowledge of Alice[0]) can immediately put it in a new funding tx
          > for a new incoming client before L1, which is a fine tradeoff for server
          > Bob since presumably Bob is always online.
          >
          > Regards,
          > ZmnSCPxj
          >
          >
          >
          
          [-- Attachment #2: Type: text/html, Size: 7918 bytes --]
          
          ^ permalink raw reply	[flat|nested] 20+ messages in thread

        • • * Re: [bitcoin-dev] SAS: Succinct Atomic Swap
              2020-05-12 16:30         ` Ruben Somsen
            @ 2020-05-13  8:39           ` ZmnSCPxj
              2020-05-13  9:57             ` Ruben Somsen
              0 siblings, 1 reply; 20+ messages in thread
            From: ZmnSCPxj @ 2020-05-13  8:39 UTC (permalink / raw)
              To: Ruben Somsen; +Cc: Bitcoin Protocol Discussion
            
            Good morning Ruben,
            
            > >If the shortened refund transaction exists (labeled "refund transaction #1" in the SVG) then the same issue still occurs 
            >
            > Yes, but there is one crucial difference: at that point in the protocol (Bob has the success transaction and then stops cooperating) Alice and Bob both had the opportunity not to take that path. Bob could have sent the success transaction, and Alice could have waited and sent the revoke transaction. They would essentially be "colluding" to fail.
            
            Okay, so the concern is basically, that Bob misses the deadline, then Alice feels obligated to reclaim the funds.
            In your proposal, the tx competition is between the secret-revealing success TX and the non-secret-revealing revoke tx.
            Whereas in my counterproposal, under the same conditions, the tx competition is between the secret-revealing success tx and the secret-revealing backout tx, and both transactions becoming visible on P2P network means potentially both Alice and Bob know all the secrets on the LTC side and end up competing over it, RBFing each other until the entire fund goes to miners.
            
            
            > >Without the refund#1 in your proposal, Bob refusing cooperation after Alice puts the BTC into lock for 3 days and 2 further onchain transactions
            >
            > I'm not sure if I correctly understood what you're saying, but it's as follows:
            >
            > Refund #1 can only safely be used before the signed success tx is given to Bob. The cost to Alice at this point if Bob aborts is two on-chain transactions while Bob hasn't put anything on-chain yet.
            >
            > Refund #2 needs to be used after Bob receives the signed success tx. The cost to Alice is now three transactions, but Bob also went-on-chain by this point, so causing this wasn't costless to Bob and is thus a similar failure mode.
            
            I think it is not accurate that Bob is already on-chain before Alice can be forced to use 3 transactions to fail.
            
            The revoke tx signatures are shared at step 0 of your protocol description.
            Thus Bob has a copy of the revoke tx that is valid once Alice signs and confirms the funding transaction.
            Bob can thus give a copy of the revoke tx with signature directly to its favorite miner, forcing Alice to take 3 transactions to back out of the swap.
            
            Since Bob gave the tx directly to its favorite miner (TANSTAAGM: "There ain't no such thing as a global mempool"), Alice will only know about this event when the revoke tx is confirmed once, at which point it is very difficult to reverse, even if Alice has a refund#1 tx prepared.
            
            Bob can do this before step 2 in your protocol description, meaning before Bob locks up any funds, so Bob can do this for free, and will even use funds going back to Alice to pay for confirmation of the revoke tx.
            Because Bob can do this for free, there is no disincentive for trolling Bobs to exist whose sole life goal is to just grief possible Alices.
            
            This can be slightly mitigated by adding two CPFP outputs (one for each participant) and using the minimum relayable feerate for the revoke tx so that Bob is forced to bring its own fees in order to incentivize miners.
            This is similar to the "bring your own fees" currently proposed for Lightning, but note the recent hand-wringing about the various problems this adds to mempools and CPFP and RBF rules and etc etc: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-April/017757.html
            
            We could use `SIGHASH_SINGLE | SIGHASH_ANYONECANPAY` as well for a bring-your-own-fees, but that is not `SIGHASH_ALL` and thus marks the transaction graph as special.
            And forcing bring-your-own-fees means neither Alice nor Bob can swap all their funds in a single operation, they have to keep a reserve.
            
            
            Bob cannot safely perform step 2 before getting both signatures for the revoke tx, as without Bob having access to the rveoke tx, if Bob locks up LTC, Alice can stop responding and lock both their funds indefinitely with Bob not having any way to recover its funds, which a rich Alice can use to completely lock out an impoverished Bob.
            But if Bob is given both signatures for the revoke tx before step 2, then Bob can send the revoke tx to its favorite miner, forcing Alice to take 3 transactions to back out, before Bob locks any funds in LTC side.
            
            >
            > I also agree with your observation that alternatively Bob can just spend before the timelock expires.
            
            This seems to be the safest alternative; in my context, where Bob is a CoinSwap server/maker, Bob can wait a short while for new clients/takers, and if no new clients arrive, spend.
            Bob can run multiple servers, each of which are given the completed success transaction, and the servers can check that if the timeout is near, to spam the Bitcoin P2P network with the completed success transactions.
            (these servers need not even run fullnodes, they could just periodically poll a number of blockchain explorers and electrum servers, and when the blockheight approaches, attempt broadcast; if the "main" server that accepts clients/takers has already spent the TXO the broadcast of the completed success tx is simply rejected by the Bitcoin P2P network; if the timeout is based on sidereal time then the backup servers only need to be running NTP)
            
            
            
            Regards,
            ZmnSCPxj
            
            
            ^ permalink raw reply	[flat|nested] 20+ messages in thread

          • • * Re: [bitcoin-dev] SAS: Succinct Atomic Swap
                2020-05-13  8:39           ` ZmnSCPxj
              @ 2020-05-13  9:57             ` Ruben Somsen
                2020-05-13  9:58               ` Ruben Somsen
                0 siblings, 1 reply; 20+ messages in thread
              From: Ruben Somsen @ 2020-05-13  9:57 UTC (permalink / raw)
                To: Bitcoin Protocol Discussion
              
              [-- Attachment #1: Type: text/plain, Size: 6332 bytes --]
              
              Hi Chris,
              
              Thanks for taking a look :)
              
              >it also improves privacy because the coins could stay unspend for a long
              time, potentially indefinitely
              
              Excellent point. The pre-swap setup transactions would still be subject to
              timing/amount analysis, but it's clearly a lot less problematic than the
              traditional 4 tx swap. And Payswap may be able to mitigate the amount
              analysis.
              
              >Using relative timelocks and private key handover for old-style coinswaps
              would give us the same two-transaction effect
              
              I agree, Lloyd pointed out the same thing. One thing to add is that such a
              setup would result in four on-chain transactions if the protocol is
              aborted, due to the need to invalidate the refund transaction.
              
              >the idea of private key handover was mentioned as early as 2016 in the
              original Lightning Network paper
              
              Interesting! Thanks for pointing that out.
              
              Cheers,
              Ruben
              
              On Wed, May 13, 2020 at 10:39 AM ZmnSCPxj <ZmnSCPxj@protonmail•com> wrote:
              
              > Good morning Ruben,
              >
              > > >If the shortened refund transaction exists (labeled "refund transaction
              > #1" in the SVG) then the same issue still occurs
              > >
              > > Yes, but there is one crucial difference: at that point in the protocol
              > (Bob has the success transaction and then stops cooperating) Alice and Bob
              > both had the opportunity not to take that path. Bob could have sent the
              > success transaction, and Alice could have waited and sent the revoke
              > transaction. They would essentially be "colluding" to fail.
              >
              > Okay, so the concern is basically, that Bob misses the deadline, then
              > Alice feels obligated to reclaim the funds.
              > In your proposal, the tx competition is between the secret-revealing
              > success TX and the non-secret-revealing revoke tx.
              > Whereas in my counterproposal, under the same conditions, the tx
              > competition is between the secret-revealing success tx and the
              > secret-revealing backout tx, and both transactions becoming visible on P2P
              > network means potentially both Alice and Bob know all the secrets on the
              > LTC side and end up competing over it, RBFing each other until the entire
              > fund goes to miners.
              >
              >
              > > >Without the refund#1 in your proposal, Bob refusing cooperation after
              > Alice puts the BTC into lock for 3 days and 2 further onchain transactions
              > >
              > > I'm not sure if I correctly understood what you're saying, but it's as
              > follows:
              > >
              > > Refund #1 can only safely be used before the signed success tx is given
              > to Bob. The cost to Alice at this point if Bob aborts is two on-chain
              > transactions while Bob hasn't put anything on-chain yet.
              > >
              > > Refund #2 needs to be used after Bob receives the signed success tx. The
              > cost to Alice is now three transactions, but Bob also went-on-chain by this
              > point, so causing this wasn't costless to Bob and is thus a similar failure
              > mode.
              >
              > I think it is not accurate that Bob is already on-chain before Alice can
              > be forced to use 3 transactions to fail.
              >
              > The revoke tx signatures are shared at step 0 of your protocol description.
              > Thus Bob has a copy of the revoke tx that is valid once Alice signs and
              > confirms the funding transaction.
              > Bob can thus give a copy of the revoke tx with signature directly to its
              > favorite miner, forcing Alice to take 3 transactions to back out of the
              > swap.
              >
              > Since Bob gave the tx directly to its favorite miner (TANSTAAGM: "There
              > ain't no such thing as a global mempool"), Alice will only know about this
              > event when the revoke tx is confirmed once, at which point it is very
              > difficult to reverse, even if Alice has a refund#1 tx prepared.
              >
              > Bob can do this before step 2 in your protocol description, meaning before
              > Bob locks up any funds, so Bob can do this for free, and will even use
              > funds going back to Alice to pay for confirmation of the revoke tx.
              > Because Bob can do this for free, there is no disincentive for trolling
              > Bobs to exist whose sole life goal is to just grief possible Alices.
              >
              > This can be slightly mitigated by adding two CPFP outputs (one for each
              > participant) and using the minimum relayable feerate for the revoke tx so
              > that Bob is forced to bring its own fees in order to incentivize miners.
              > This is similar to the "bring your own fees" currently proposed for
              > Lightning, but note the recent hand-wringing about the various problems
              > this adds to mempools and CPFP and RBF rules and etc etc:
              > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-April/017757.html
              >
              > We could use `SIGHASH_SINGLE | SIGHASH_ANYONECANPAY` as well for a
              > bring-your-own-fees, but that is not `SIGHASH_ALL` and thus marks the
              > transaction graph as special.
              > And forcing bring-your-own-fees means neither Alice nor Bob can swap all
              > their funds in a single operation, they have to keep a reserve.
              >
              >
              > Bob cannot safely perform step 2 before getting both signatures for the
              > revoke tx, as without Bob having access to the rveoke tx, if Bob locks up
              > LTC, Alice can stop responding and lock both their funds indefinitely with
              > Bob not having any way to recover its funds, which a rich Alice can use to
              > completely lock out an impoverished Bob.
              > But if Bob is given both signatures for the revoke tx before step 2, then
              > Bob can send the revoke tx to its favorite miner, forcing Alice to take 3
              > transactions to back out, before Bob locks any funds in LTC side.
              >
              > >
              > > I also agree with your observation that alternatively Bob can just spend
              > before the timelock expires.
              >
              > This seems to be the safest alternative; in my context, where Bob is a
              > CoinSwap server/maker, Bob can wait a short while for new clients/takers,
              > and if no new clients arrive, spend.
              > Bob can run multiple servers, each of which are given the completed
              > success transaction, and the servers can check that if the timeout is near,
              > to spam the Bitcoin P2P network with the completed success transactions.
              > (these servers need not even run fullnodes, they could just periodically
              > poll a number of blockchain explorers and electrum servers, and when the
              > blockheight approaches, attempt broadcast; if the "main" server that
              > accepts clients/takers has already spent the TXO the broadcast of the
              > completed success tx is simply rejected by the Bitcoin P2P network; if the
              > timeout is based on sidereal time then the backup servers only need to be
              > running NTP)
              >
              >
              >
              > Regards,
              > ZmnSCPxj
              >
              
              [-- Attachment #2: Type: text/html, Size: 7142 bytes --]
              
              ^ permalink raw reply	[flat|nested] 20+ messages in thread

            • • * Re: [bitcoin-dev] SAS: Succinct Atomic Swap
                  2020-05-13  9:57             ` Ruben Somsen
                @ 2020-05-13  9:58               ` Ruben Somsen
                  2020-05-13 11:39                 ` ZmnSCPxj
                  0 siblings, 1 reply; 20+ messages in thread
                From: Ruben Somsen @ 2020-05-13  9:58 UTC (permalink / raw)
                  To: Bitcoin Protocol Discussion
                
                [-- Attachment #1: Type: text/plain, Size: 8340 bytes --]
                
                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.
                
                >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?
                
                >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.
                
                >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.
                
                Cheers,
                Ruben
                
                On Wed, May 13, 2020 at 11:57 AM Ruben Somsen <rsomsen@gmail•com> wrote:
                
                > Hi Chris,
                >
                > Thanks for taking a look :)
                >
                > >it also improves privacy because the coins could stay unspend for a long
                > time, potentially indefinitely
                >
                > Excellent point. The pre-swap setup transactions would still be subject to
                > timing/amount analysis, but it's clearly a lot less problematic than the
                > traditional 4 tx swap. And Payswap may be able to mitigate the amount
                > analysis.
                >
                > >Using relative timelocks and private key handover for old-style coinswaps
                > would give us the same two-transaction effect
                >
                > I agree, Lloyd pointed out the same thing. One thing to add is that such a
                > setup would result in four on-chain transactions if the protocol is
                > aborted, due to the need to invalidate the refund transaction.
                >
                > >the idea of private key handover was mentioned as early as 2016 in the
                > original Lightning Network paper
                >
                > Interesting! Thanks for pointing that out.
                >
                > Cheers,
                > Ruben
                >
                > On Wed, May 13, 2020 at 10:39 AM ZmnSCPxj <ZmnSCPxj@protonmail•com> wrote:
                >
                >> Good morning Ruben,
                >>
                >> > >If the shortened refund transaction exists (labeled "refund
                >> transaction #1" in the SVG) then the same issue still occurs
                >> >
                >> > Yes, but there is one crucial difference: at that point in the protocol
                >> (Bob has the success transaction and then stops cooperating) Alice and Bob
                >> both had the opportunity not to take that path. Bob could have sent the
                >> success transaction, and Alice could have waited and sent the revoke
                >> transaction. They would essentially be "colluding" to fail.
                >>
                >> Okay, so the concern is basically, that Bob misses the deadline, then
                >> Alice feels obligated to reclaim the funds.
                >> In your proposal, the tx competition is between the secret-revealing
                >> success TX and the non-secret-revealing revoke tx.
                >> Whereas in my counterproposal, under the same conditions, the tx
                >> competition is between the secret-revealing success tx and the
                >> secret-revealing backout tx, and both transactions becoming visible on P2P
                >> network means potentially both Alice and Bob know all the secrets on the
                >> LTC side and end up competing over it, RBFing each other until the entire
                >> fund goes to miners.
                >>
                >>
                >> > >Without the refund#1 in your proposal, Bob refusing cooperation after
                >> Alice puts the BTC into lock for 3 days and 2 further onchain transactions
                >> >
                >> > I'm not sure if I correctly understood what you're saying, but it's as
                >> follows:
                >> >
                >> > Refund #1 can only safely be used before the signed success tx is given
                >> to Bob. The cost to Alice at this point if Bob aborts is two on-chain
                >> transactions while Bob hasn't put anything on-chain yet.
                >> >
                >> > Refund #2 needs to be used after Bob receives the signed success tx.
                >> The cost to Alice is now three transactions, but Bob also went-on-chain by
                >> this point, so causing this wasn't costless to Bob and is thus a similar
                >> failure mode.
                >>
                >> I think it is not accurate that Bob is already on-chain before Alice can
                >> be forced to use 3 transactions to fail.
                >>
                >> The revoke tx signatures are shared at step 0 of your protocol
                >> description.
                >> Thus Bob has a copy of the revoke tx that is valid once Alice signs and
                >> confirms the funding transaction.
                >> Bob can thus give a copy of the revoke tx with signature directly to its
                >> favorite miner, forcing Alice to take 3 transactions to back out of the
                >> swap.
                >>
                >> Since Bob gave the tx directly to its favorite miner (TANSTAAGM: "There
                >> ain't no such thing as a global mempool"), Alice will only know about this
                >> event when the revoke tx is confirmed once, at which point it is very
                >> difficult to reverse, even if Alice has a refund#1 tx prepared.
                >>
                >> Bob can do this before step 2 in your protocol description, meaning
                >> before Bob locks up any funds, so Bob can do this for free, and will even
                >> use funds going back to Alice to pay for confirmation of the revoke tx.
                >> Because Bob can do this for free, there is no disincentive for trolling
                >> Bobs to exist whose sole life goal is to just grief possible Alices.
                >>
                >> This can be slightly mitigated by adding two CPFP outputs (one for each
                >> participant) and using the minimum relayable feerate for the revoke tx so
                >> that Bob is forced to bring its own fees in order to incentivize miners.
                >> This is similar to the "bring your own fees" currently proposed for
                >> Lightning, but note the recent hand-wringing about the various problems
                >> this adds to mempools and CPFP and RBF rules and etc etc:
                >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-April/017757.html
                >>
                >> We could use `SIGHASH_SINGLE | SIGHASH_ANYONECANPAY` as well for a
                >> bring-your-own-fees, but that is not `SIGHASH_ALL` and thus marks the
                >> transaction graph as special.
                >> And forcing bring-your-own-fees means neither Alice nor Bob can swap all
                >> their funds in a single operation, they have to keep a reserve.
                >>
                >>
                >> Bob cannot safely perform step 2 before getting both signatures for the
                >> revoke tx, as without Bob having access to the rveoke tx, if Bob locks up
                >> LTC, Alice can stop responding and lock both their funds indefinitely with
                >> Bob not having any way to recover its funds, which a rich Alice can use to
                >> completely lock out an impoverished Bob.
                >> But if Bob is given both signatures for the revoke tx before step 2, then
                >> Bob can send the revoke tx to its favorite miner, forcing Alice to take 3
                >> transactions to back out, before Bob locks any funds in LTC side.
                >>
                >> >
                >> > I also agree with your observation that alternatively Bob can just
                >> spend before the timelock expires.
                >>
                >> This seems to be the safest alternative; in my context, where Bob is a
                >> CoinSwap server/maker, Bob can wait a short while for new clients/takers,
                >> and if no new clients arrive, spend.
                >> Bob can run multiple servers, each of which are given the completed
                >> success transaction, and the servers can check that if the timeout is near,
                >> to spam the Bitcoin P2P network with the completed success transactions.
                >> (these servers need not even run fullnodes, they could just periodically
                >> poll a number of blockchain explorers and electrum servers, and when the
                >> blockheight approaches, attempt broadcast; if the "main" server that
                >> accepts clients/takers has already spent the TXO the broadcast of the
                >> completed success tx is simply rejected by the Bitcoin P2P network; if the
                >> timeout is based on sidereal time then the backup servers only need to be
                >> running NTP)
                >>
                >>
                >>
                >> Regards,
                >> ZmnSCPxj
                >>
                >
                
                [-- Attachment #2: Type: text/html, Size: 9730 bytes --]
                
                ^ permalink raw reply	[flat|nested] 20+ messages in thread

              • • * Re: [bitcoin-dev] SAS: Succinct Atomic Swap
                    2020-05-13  9:58               ` Ruben Somsen
                  @ 2020-05-13 11:39                 ` ZmnSCPxj
                    2020-05-13 12:33                   ` Ruben Somsen
                    0 siblings, 1 reply; 20+ messages in thread
                  From: ZmnSCPxj @ 2020-05-13 11:39 UTC (permalink / raw)
                    To: Ruben Somsen; +Cc: Bitcoin Protocol Discussion
                  
                  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
                  
                  
                  ^ permalink raw reply	[flat|nested] 20+ messages in thread

                • • * Re: [bitcoin-dev] SAS: Succinct Atomic Swap
                      2020-05-13 11:39                 ` ZmnSCPxj
                    @ 2020-05-13 12:33                   ` Ruben Somsen
                      2020-05-15  4:39                     ` ZmnSCPxj
                      0 siblings, 1 reply; 20+ messages in thread
                    From: Ruben Somsen @ 2020-05-13 12:33 UTC (permalink / raw)
                      To: Bitcoin Protocol Discussion
                    
                    [-- 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 --]
                    
                    ^ permalink raw reply	[flat|nested] 20+ messages in thread

                  • • * Re: [bitcoin-dev] SAS: Succinct Atomic Swap
                        2020-05-13 12:33                   ` Ruben Somsen
                      @ 2020-05-15  4:39                     ` ZmnSCPxj
                        2020-05-15 19:47                       ` Ruben Somsen
                        0 siblings, 1 reply; 20+ messages in thread
                      From: ZmnSCPxj @ 2020-05-15  4:39 UTC (permalink / raw)
                        To: Ruben Somsen; +Cc: Bitcoin Protocol Discussion
                      
                      Good morning Ruben,
                      
                      > 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.
                      
                      Ah, that explains the existence of the Alice && Bob clause in that output then.
                      
                      The attack is now as follows:
                      
                      * Alice completes the protocol up to handing over `sigSuccessAlice` to Bob.
                      * Bob returns the `secretBob`.
                      * Alice stalls the protocol and never sends the `Alice` privkey, and waits for 1 day, then sneaks the refund tx #1 and spends the LTC via direct miner collusion.
                      
                      The proper response here is that Bob should broadcast success tx before the refund tx #1 becomes valid.
                      (Which I think is the point: chaos can only occur if you let backouts become valid, and it is the best policy for Bob to just spend the BTC txo well before the timeout.
                      Even if the protocol is completed, without a bring-your-own-fees that lets you malleate the tx (i.e. CPFP hooks still require the transction itself to reduce the fund by at least the minimum feerate), at least part of the fund must be lost in fees and Bob can still suffer a small loss of funds.)
                      
                      --
                      
                      Tangentially, I now think in the case of client-server CoinSwap, the server should take Alice position and the client should take Bob position.
                      
                      Suppose a client wants to do some mixing of its own received coins.
                      It should not depend on only one server, as the server might secretly be a surveillor (or hacked by a surveillor) and recording swaps.
                      Thus, a client will want to make multiple CoinSwaps in sequence, to obscure its history.
                      
                      (Do note the objections under "Directionality" in https://zmnscpxj.github.io/bitcoin/multiswap.html though; a counter to this objections is that the analysis there is only applicable if the surveillor already identified the CoinSwap sequence, but hopefully the increased steganography of CoinSwaps means they are not identifiable anyway.)
                      
                      Since Bob really should spend its received coin before a timeout, it is best for Bob to be the client; it is likely that the client will need to swap "soon" again, meaning it has to redirect the funds to a new 2-of-2 anyway.
                      
                      For the final swap, the client can then spend the final coins to an HD wallet it controls, reducing the key backup load on the client to be the same as normal HD wallets.
                      Presumably the server in this situation has greater ability to dynamically update its backups to include key backups for `secretAlice` keys.
                      
                      Further, if the client program has the policy that all spends out of the wallet must be done via a swap (similar to a rule imposed by JoinMarket where sendpayment.py always does 1 CoinJoin), then this still matches well with the requirement on Bob to spend the fund before the first timeout of refund tx #1.
                      
                      If the client needs to spend to a classic, address-using service, then nothing in the SAS protocol allows Alice to receive its funds directly into a specific third-party address.
                      However, Bob can hand over a specific third-party address to use in the success tx.
                      Indeed, the SAS protocol can be modified so that Bob can specify a set of address/value pairs to be put in the success tx instead of just Bob pubkey; for example, Bob might swap more than the amoutn that needs to be paid to the third-party service, in order to give some additional leeway later for RBF once Alice hands over the Alice privkey and Bob can remake the success tx (and more importantly, ensure the txo is spent before refund tx #1 becoms valid).
                      
                      
                      Regards,
                      ZmnSCPxj
                      
                      
                      ^ permalink raw reply	[flat|nested] 20+ messages in thread

                    • • * Re: [bitcoin-dev] SAS: Succinct Atomic Swap
                          2020-05-15  4:39                     ` ZmnSCPxj
                        @ 2020-05-15 19:47                       ` Ruben Somsen
                          0 siblings, 0 replies; 20+ messages in thread
                        From: Ruben Somsen @ 2020-05-15 19:47 UTC (permalink / raw)
                          To: ZmnSCPxj; +Cc: Bitcoin Protocol Discussion
                        
                        [-- Attachment #1: Type: text/plain, Size: 6399 bytes --]
                        
                        Hi ZmnSCPxj,
                        
                        >The proper response here is that Bob should broadcast success tx before
                        the refund tx #1 becomes valid.
                        
                        That's right. And even if Bob neglects to do that, it still won't cause
                        chaos for Alice as long as she chooses the path for refund tx #2.
                        
                        >at least part of the fund must be lost in fees and Bob can still suffer a
                        small loss
                        
                        Yes, after protocol completion Alice can broadcast one more transaction
                        that is paid for by Bob, and Bob would have to respond with another
                        transaction of his own. As you said, bring-your-own-fees would be better
                        here (also see FAQ question "Can't Alice just publish the revoke_tx after
                        protocol completion?").
                        
                        >the server should take Alice position and the client should take Bob
                        position [...] a client will want to make multiple CoinSwaps in sequence
                        
                        I think this can be summarized as: whoever is planning to spend their UTXO
                        first should be Bob.
                        
                        In your protocol it might make sense for the server and client to swap
                        roles depending on what the client plans to do. If they plan to swap again
                        soon, they can be Bob, if they don't, they're Alice.
                        
                        But there's also another consideration: whoever is less likely to abort the
                        protocol should be Bob.
                        
                        Clients can be unreliable. If clients are Bob, they can waste Alice's
                        resources by initiating the protocol and aborting (which imo is more severe
                        than the risk of the revoke tx getting published). Whereas if the client is
                        Alice, she'd be first to commit resources before the server commits
                        anything.
                        
                        >ensure the txo is spent before refund tx #1 becoms valid
                        
                        Yes, this is important. Luckily, pretty much all the options we discussed
                        could be applied here, including sighash_single + anyonecanpay. In your
                        specific example this seems preferable to adding a change output and making
                        multiple transactions with different RBF amounts, especially since this
                        only concerns a situation where the protocol stalls at a specific step
                        (after the success tx).
                        
                        And I agree with your general assessment that three transactions are
                        required in order to pay a third party. This could be done from either side
                        of the swap, but of course it makes more sense to pay from the timelock
                        side and get rid of the online requirement.
                        
                        Cheers,
                        Ruben
                        
                        On Fri, May 15, 2020 at 6:39 AM ZmnSCPxj <ZmnSCPxj@protonmail•com> wrote:
                        
                        > Good morning Ruben,
                        >
                        > > 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.
                        >
                        > Ah, that explains the existence of the Alice && Bob clause in that output
                        > then.
                        >
                        > The attack is now as follows:
                        >
                        > * Alice completes the protocol up to handing over `sigSuccessAlice` to Bob.
                        > * Bob returns the `secretBob`.
                        > * Alice stalls the protocol and never sends the `Alice` privkey, and waits
                        > for 1 day, then sneaks the refund tx #1 and spends the LTC via direct miner
                        > collusion.
                        >
                        > The proper response here is that Bob should broadcast success tx before
                        > the refund tx #1 becomes valid.
                        > (Which I think is the point: chaos can only occur if you let backouts
                        > become valid, and it is the best policy for Bob to just spend the BTC txo
                        > well before the timeout.
                        > Even if the protocol is completed, without a bring-your-own-fees that lets
                        > you malleate the tx (i.e. CPFP hooks still require the transction itself to
                        > reduce the fund by at least the minimum feerate), at least part of the fund
                        > must be lost in fees and Bob can still suffer a small loss of funds.)
                        >
                        > --
                        >
                        > Tangentially, I now think in the case of client-server CoinSwap, the
                        > server should take Alice position and the client should take Bob position.
                        >
                        > Suppose a client wants to do some mixing of its own received coins.
                        > It should not depend on only one server, as the server might secretly be a
                        > surveillor (or hacked by a surveillor) and recording swaps.
                        > Thus, a client will want to make multiple CoinSwaps in sequence, to
                        > obscure its history.
                        >
                        > (Do note the objections under "Directionality" in
                        > https://zmnscpxj.github.io/bitcoin/multiswap.html though; a counter to
                        > this objections is that the analysis there is only applicable if the
                        > surveillor already identified the CoinSwap sequence, but hopefully the
                        > increased steganography of CoinSwaps means they are not identifiable
                        > anyway.)
                        >
                        > Since Bob really should spend its received coin before a timeout, it is
                        > best for Bob to be the client; it is likely that the client will need to
                        > swap "soon" again, meaning it has to redirect the funds to a new 2-of-2
                        > anyway.
                        >
                        > For the final swap, the client can then spend the final coins to an HD
                        > wallet it controls, reducing the key backup load on the client to be the
                        > same as normal HD wallets.
                        > Presumably the server in this situation has greater ability to dynamically
                        > update its backups to include key backups for `secretAlice` keys.
                        >
                        > Further, if the client program has the policy that all spends out of the
                        > wallet must be done via a swap (similar to a rule imposed by JoinMarket
                        > where sendpayment.py always does 1 CoinJoin), then this still matches well
                        > with the requirement on Bob to spend the fund before the first timeout of
                        > refund tx #1.
                        >
                        > If the client needs to spend to a classic, address-using service, then
                        > nothing in the SAS protocol allows Alice to receive its funds directly into
                        > a specific third-party address.
                        > However, Bob can hand over a specific third-party address to use in the
                        > success tx.
                        > Indeed, the SAS protocol can be modified so that Bob can specify a set of
                        > address/value pairs to be put in the success tx instead of just Bob pubkey;
                        > for example, Bob might swap more than the amoutn that needs to be paid to
                        > the third-party service, in order to give some additional leeway later for
                        > RBF once Alice hands over the Alice privkey and Bob can remake the success
                        > tx (and more importantly, ensure the txo is spent before refund tx #1
                        > becoms valid).
                        >
                        >
                        > Regards,
                        > ZmnSCPxj
                        >
                        
                        [-- Attachment #2: Type: text/html, Size: 7304 bytes --]
                        
                        ^ permalink raw reply	[flat|nested] 20+ messages in thread

end of thread, other threads:[~2020-06-03 14:36 UTC | newest]

Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-11 15:29 [bitcoin-dev] SAS: Succinct Atomic Swap 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
2020-05-15  4:39                     ` ZmnSCPxj
2020-05-15 19:47                       ` Ruben Somsen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox