Re: [bitcoin-dev] SAS: Succinct Atomic Swap
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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] SAS: Succinct Atomic Swap
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 + ZmnSCPxj via bitcoin-dev 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
Re: [bitcoin-dev] SAS: Succinct Atomic Swap
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 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
Re: [bitcoin-dev] SAS: Succinct Atomic Swap
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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] SAS: Succinct Atomic Swap
Hi ZmnSCPxj, >on completion of the protocol, if Bob lets the refund tx#1 become valid (i.e. does not spend the BTC txo) then Alice can broadcast it, putting both their funds into chaos You forget, refund tx #1 has a script (which btw won't be visible with taproot): "Alice & Bob OR Alice in +1 day" (relative) so if Alice broadcasts it after protocol completion, she is just giving Bob the key to her LTC (note: if she's wise she'd move the LTC beforehand), but Bob doesn't lose the BTC because he has both keys and can just react before the relative timelock expires. No chaos. >This is why we eventually decided in Lightning to use two CPFP outpoints rather than one I appreciate the explanation. I see the problem now, and yes, that does seem like a headache. Cheers, Ruben On Wed, May 13, 2020 at 1:39 PM ZmnSCPxj wrote: > Good morning Ruben, > > > Hi ZmnSCPxj, > > > > >potentially both Alice and Bob know all the secrets on the LTC side and > end up competing over it > > > > That's exactly right. > > > > >Bob can thus give a copy of the revoke tx with signature directly to > its favorite miner, forcing Alice to take 3 transactions > > > > Note that the timelock on the revoke tx is longer than the timelock on > refund tx #1. The idea is that Alice aborts the protocol by publishing > refund tx #1 if the protocol hasn't reached step 4 in the svg by the time > it becomes valid. This should entirely mitigate the issue you're describing. > > But if refund tx #1 at all exists, then you drop to the same issue you > objected to with my proposal, which is that, on completion of the protocol, > if Bob lets the refund tx#1 become valid (i.e. does not spend the BTC txo) > then Alice can broadcast it, putting both their funds into chaos. > > So you might as well just use my counterproposal instead, which is > simpler, gets bring-your-own-fees for free, etc. > > I suppose there is some *slight* improvement in that with your proposal, > Alice *can* use revoke tx -> refund tx #2, but still, if Alice is insane > then it could very well mess with the protocol by instead using refund tx > #1. > Thus, if Bob wants to survive in an environment where Alices are possibly > insane (e.g. the real world), it should do everything in its power to > ensure that the BTC txo is spent before the timeout of refund tx #1, if > refund tx #1 exists at all. > And if Bob is already going to do that, then Alice and Bob might as well > just use my counterproposal etc etc. > > > >adding two CPFP outputs (one for each participant) > > > > There seems to be a situation where RBF can be disabled by the other > party, but I'm not sure I see it... Why would a single output spendable by > either key be insufficient? > > If one party quickly broadcasts a long chain of low-feerate transactions > on top of the single output, then the output is "pinned". > > Low feerate means it is undesirable for miners to mine it, because it pays > low for the amount of blockspace it has. > But because there is a long chain of transactions, the absolute fee of > that chain can be sizable, and we have a rule in RBF which, paraphrased, > goes something like "the replacing transaction should also have a higher > absolute fee than *all* the transactions it replaces", meaning the fee jump > that the other side has to offer *has to be* pretty big. > > If the other outputs of the tx are then multisig, then the pinning > participant can simply refuse to sign for those, and if the existing txes > spending the other outputs are relative-time-locked, they cannot be used to > CPFP the revoke tx onchain. > > This is why we eventually decided in Lightning to use two CPFP outpoints > rather than one, and are also realizing just how much of a headache the RBF > rules are, sigh. > > Still, in your proposed protocol the dependent transactions are all > relative-timelocked, so timely confirmation of the revoke tx is not > necessary, unlike in the case of Lightning where all HTLCs have to use an > absolute timelock because we have to coordinate multiple HTLCs in > forwarding and violation of the timelocks can lead to headaches and fund > loss and so on. > So maybe a single hook output, or even none at all, is workable. > > > > > >We could use `SIGHASH_SINGLE | SIGHASH_ANYONECANPAY` as well > > > > Allowing others to add inputs/outputs would introduce malleability. > Refund tx #2 and the timeout tx would become invalid. > > Ah, right, you still need `SIGHASH_ANYPREVOUT`/`SIGHASH_NOINPUT` for that. > > > >Bob cannot safely perform step 2 before getting both signatures for the > revoke tx > > > > That's right, as you guessed, he does receive a copy of the signed > revoke tx at protocol start. > > > > >>alternatively Bob can just spend before the timelock expires. > > >This seems to be the safest alternative > > > > I agree not giving Alice time to publish the revoke tx is safest, but > one does not preclude the other. The revoke tx is on an absolute timelock, > so spending it before that time
Re: [bitcoin-dev] SAS: Succinct Atomic Swap
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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] SAS: Succinct Atomic Swap
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 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 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
Re: [bitcoin-dev] SAS: Succinct Atomic Swap
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 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,
Re: [bitcoin-dev] SAS: Succinct Atomic Swap
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
Re: [bitcoin-dev] SAS: Succinct Atomic Swap
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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] SAS: Succinct Atomic Swap
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 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
Re: [bitcoin-dev] SAS: Succinct Atomic Swap
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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] SAS: Succinct Atomic Swap
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 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 > 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 >> > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] SAS: Succinct Atomic Swap
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 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 > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] SAS: Succinct Atomic Swap
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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] SAS: Succinct Atomic Swap
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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] SAS: Succinct Atomic Swap
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
Re: [bitcoin-dev] SAS: Succinct Atomic Swap
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 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?)
Re: [bitcoin-dev] SAS: Succinct Atomic Swap
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
[bitcoin-dev] SAS: Succinct Atomic Swap
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
