Re: [bitcoin-dev] TLA+ specification for Succint Atomic Swap
Hi Dmitry,
>While refund_tx_1 is in the mempool, Bob gives success_tx to the friendly
miner
I see, so you're talking about prior to protocol completion, right after
Alice sends Bob the success_tx. The reason this is not an issue is because
Alice and Bob both had to misbehave in order for this to happen. Bob is
misbehaving here because he should have published the success_tx before
refund_tx_1 became valid, and Alice is misbehaving here because she should
have sent the revoke_tx (which invalidates the success_tx) followed by
refund_tx_2 (revealing her secret only AFTER Bob can no longer claim the
BTC). In other words: yes, the protocol can fail if Alice and Bob together
work towards that goal. A feature, not a bug. This won't happen if either
of them doesn't want it to. I imagine this is difficult to model.
>As I understand, this is a way to deny Alice to use refund_tx_1.
That is correct, and it also denies refund_tx_2 by making the revoke_tx
directly spendable by Bob.
>could Bob just spend the Alice output of the very first, "commitment"
transaction that locks BTC
Yes, he can. This is what makes it possible to complete the protocol in
merely two transactions.
>Bob will receive BTC, and the LTC can be locked forever, but Bob doesn't
care, he got his BTC.
No, because diagram step 5 comes before step 6 -- Alice won't give her key
until she learns secretBob.
I hope this clarifies it!
Cheers,
Ruben
On Thu, May 14, 2020 at 6:49 AM Dmitry Petukhov wrote:
> В Wed, 13 May 2020 21:03:17 +0200
> Ruben Somsen wrote:
>
> > Or perhaps you're referring to the issue ZmnSCPxj pointed out after
> > that, where refund transaction #1 and the success transaction could
> > both become valid at the same time. It would make sense for the test
> > to pick up on that, but I believe that is ultimately also not an
> > issue (see my last reply in the thread).
>
> This one.
>
> The issue as I see it: Bob can not broadcast success_tx and wait until
> Alice has broadcasted refund_tx_1. While refund_tx_1 is in the mempool,
> Bob gives success_tx to the friendly miner to have a chance to
> invalidate success_tx. Bob already learned secretAlice, so he grabs
> his LTC back. If the Bob-friendly miner has luck, success_tx is
> confirmed while refund_tx_1 is invalidated, and Bob now have both LTC
> and BTC, while Alice is out of her BTC.
>
> > >I did not understand what the destination of Alice cooperative
> > >spend
> > of refund_tx#1 will be
> >
> > This transaction can be spent by Alice & Bob right away or by Alice a
> > day later (in relative time, so the tx has to confirm first). The
> > Alice & Bob condition is there purely to ensure that Bob can spend
> > the money before Alice once he receives her key at the end of the
> > protocol.
>
> Ah, so this is possible because of the step 5 in the diagram: ``Alice
> gives Bob her key ("Alice")'' -- As I understand, this is a way to deny
> Alice to use refund_tx_1.
>
> Then if Alice gives her _key_ to Bob before Bob has to share secretBob
> via success_tx, could Bob just spend the Alice output of the
> very first, "commitment" transaction that locks BTC ? Bob will receive
> BTC, and the LTC can be locked forever, but Bob doesn't care, he got
> his BTC.
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] TLA+ specification for Succint Atomic Swap
В Wed, 13 May 2020 21:03:17 +0200
Ruben Somsen wrote:
> Or perhaps you're referring to the issue ZmnSCPxj pointed out after
> that, where refund transaction #1 and the success transaction could
> both become valid at the same time. It would make sense for the test
> to pick up on that, but I believe that is ultimately also not an
> issue (see my last reply in the thread).
This one.
The issue as I see it: Bob can not broadcast success_tx and wait until
Alice has broadcasted refund_tx_1. While refund_tx_1 is in the mempool,
Bob gives success_tx to the friendly miner to have a chance to
invalidate success_tx. Bob already learned secretAlice, so he grabs
his LTC back. If the Bob-friendly miner has luck, success_tx is
confirmed while refund_tx_1 is invalidated, and Bob now have both LTC
and BTC, while Alice is out of her BTC.
> >I did not understand what the destination of Alice cooperative
> >spend
> of refund_tx#1 will be
>
> This transaction can be spent by Alice & Bob right away or by Alice a
> day later (in relative time, so the tx has to confirm first). The
> Alice & Bob condition is there purely to ensure that Bob can spend
> the money before Alice once he receives her key at the end of the
> protocol.
Ah, so this is possible because of the step 5 in the diagram: ``Alice
gives Bob her key ("Alice")'' -- As I understand, this is a way to deny
Alice to use refund_tx_1.
Then if Alice gives her _key_ to Bob before Bob has to share secretBob
via success_tx, could Bob just spend the Alice output of the
very first, "commitment" transaction that locks BTC ? Bob will receive
BTC, and the LTC can be locked forever, but Bob doesn't care, he got
his BTC.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients
Good morning Antoine, > While approaching this question, I think you should consider economic weight > of nodes in evaluating miner consensus-hijack success. Even if you expect a > disproportionate ratio of full-nodes-vs-SPV, they may not have the same > economic weight at all, therefore even if miners are able to lure a majority > of SPV clients they may not be able to stir economic nodes. SPV clients users > will now have an incentive to cancel their hijacked history to stay on the > most economic meaningful chain. And it's already assumed, that if you run a > bitcoin business or LN routing node, you do want to run your own full-node. One hope I have for Lightning is that it will replace centralized custodial services, because: * Lightning gains some of the scalability advantage of centralized custodial services, because you can now transfer to any Lightning client without touching the blockchain, for much reduced transfer fees. * At the same time, it retains your-keys-your-coins noncustodiality, because every update of a Lightning channel requires your keys to sign off on it. If most Lightning clients are SPV, then if we compare these two worlds: * There are a few highly-important centralized custodial services with significant economic weight running fullnodes (i.e. now). * There are no highly-important centralized custodial services, and most everyone uses Lightning, but with SPV (i.e. a Lightning future). Then the distribution of economic weight would be different between these two worlds. It may even be possible, that the Lightning future with massive SPV might end up with more economic weight in SPV nodes, than in the world without Lightning and dependent on centralized custodial services to scale. It is also entirely possible that custodial services for Lightning will arise anyway and my hope is already dashed, come on universe, work harder will you, would you really disappoint some randomly-generated Internet person like that. > > I agree it may be hard to evaluate economic-weight-to-chain-backend segments, > specially with offchain you disentangle an onchain output value from its real > payment traffic. To strengthen SPV, you may implement forks detection and > fallback to some backup node(s) which would serve as an authoritative source > to arbiter between branches. Such backup node(s) must be picked up manually > at client initialization, before any risk of conflict to avoid Reddit-style > of hijack during contentious period or other massive social engineering. You > don't want autopilot-style of recommendations for picking up a backup nodes > and avoid cenralization of backups, but somehow a uniform distribution. A > backup node may be a private one, it won't serve you any data beyond headers, > and therefore you preserve public nodes bandwidth, which IMO is the real > bottleneck. I concede it won't work well if you have a ratio of 1000-SPV for > 1-full-node and people are not effectively able to pickup a backup among > their social environment. > What do you think about this model ? Money makes the world go round, so such backup servers that are publicly-facing rather than privately-owned should be somehow incentivized to do so, or else they would not exist in the first place. Of course, a free market tends towards monopoly, because any entity that happens to have even a slight advantage at the business will have more money to use towards business reinvestment and increase its advantage further, until they beat the competition to dust, anyone who has won a 4X game knows to search for and stack those little advantages until you snowball and conquer the world/galaxy/petri dish which is why the endgame of 4X games is so boring compared to the start, we have seen this happen in mining and exchanges and so on, and this works against your desire to have a uniform distribution. If everyone runs such a privately-owned server, on the other hand, this is not so different from having a Lightning node you run at your home that has a fullnode as well and which you access via a remote control mobile device, and it is the inconvenience of having such a server at your home that prevents this in the first place. Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients
Hi Chris, While approaching this question, I think you should consider economic weight of nodes in evaluating miner consensus-hijack success. Even if you expect a disproportionate ratio of full-nodes-vs-SPV, they may not have the same economic weight at all, therefore even if miners are able to lure a majority of SPV clients they may not be able to stir economic nodes. SPV clients users will now have an incentive to cancel their hijacked history to stay on the most economic meaningful chain. And it's already assumed, that if you run a bitcoin business or LN routing node, you do want to run your own full-node. I agree it may be hard to evaluate economic-weight-to-chain-backend segments, specially with offchain you disentangle an onchain output value from its real payment traffic. To strengthen SPV, you may implement forks detection and fallback to some backup node(s) which would serve as an authoritative source to arbiter between branches. Such backup node(s) must be picked up manually at client initialization, before any risk of conflict to avoid Reddit-style of hijack during contentious period or other massive social engineering. You don't want autopilot-style of recommendations for picking up a backup nodes and avoid cenralization of backups, but somehow a uniform distribution. A backup node may be a private one, it won't serve you any data beyond headers, and therefore you preserve public nodes bandwidth, which IMO is the real bottleneck. I concede it won't work well if you have a ratio of 1000-SPV for 1-full-node and people are not effectively able to pickup a backup among their social environment. What do you think about this model ? Cheers, Antoine Le mar. 12 mai 2020 à 17:06, Chris Belcher a écrit : > On 05/05/2020 16:16, Lloyd Fournier via bitcoin-dev wrote: > > On Tue, May 5, 2020 at 9:01 PM Luke Dashjr via bitcoin-dev < > > bitcoin-dev@lists.linuxfoundation.org> wrote: > > > >> On Tuesday 05 May 2020 10:17:37 Antoine Riard via bitcoin-dev wrote: > >>> Trust-minimization of Bitcoin security model has always relied first > and > >>> above on running a full-node. This current paradigm may be shifted by > LN > >>> where fast, affordable, confidential, censorship-resistant payment > >> services > >>> may attract a lot of adoption without users running a full-node. > >> > >> No, it cannot be shifted. This would compromise Bitcoin itself, which > for > >> security depends on the assumption that a supermajority of the economy > is > >> verifying their incoming transactions using their own full node. > >> > > > > Hi Luke, > > > > I have heard this claim made several times but have never understood the > > argument behind it. The question I always have is: If I get scammed by > not > > verifying my incoming transactions properly how can this affect anyone > > else? It's very unintuative. I've been scammed several times in my life > in > > fiat currency transactions but as far as I could tell it never negatively > > affected the currency overall! > > > > The links you point and from what I've seen you say before refer to > "miner > > control" as the culprit. My only thought is that this is because a light > > client could follow a dishonest majority of hash power chain. But this > just > > brings me back to the question. If, instead of BTC, I get a payment in > some > > miner scamcoin on their dishonest fork (but I think it's BTC because I'm > > running a light client) that still seems to only to damage me. Where does > > the side effect onto others on the network come from? > > > > Cheers, > > > > LL > > > > Hello Lloyd, > > The problem comes when a large part of the ecosystem gets scammed at > once, which is how such an attack would happen in practice. > > For example, consider if bitcoin had 1 users. 10 of them use a full > node wallet while the other 9990 use an SPV wallet. If a miner attacked > the system by printing infinite bitcoins and spending coins without a > valid signature, then the 9990 SPV wallets would accept those fake coins > as payment, and trade the coins amongst themselves. After a time those > coins would likely be the ancestors of most active coins in the > 9990-SPV-wallet ecosystem. Bitcoin would split into two currencies: > full-node-coin and SPV-coin. > > Now the fraud miners may become well known, perhaps being published on > bitcoin news portals, but the 9990-SPV-wallet ecosystem has a strong > incentive to be against any rollback. Their recent transactions would > disappear and they'd lose money. They would argue that they've already > been using the coin for a while, and it works perfectly fine, and anyway > a coin that can be spent in 9990 places is more useful than one that can > be spent in just 10 places. The SPV-wallet community might even decide > to use something like `invalidateblock` to make sure their SPV-coin > doesn't get reorg'd out of existence. There'd also likely be a social > attack, with every bitcoin community portal being flooded with bots and
Re: [bitcoin-dev] TLA+ specification for Succint Atomic Swap
Hi Dmitry, Thanks for creating a specification for testing, I appreciate the interest! >The checking of the model encoded in the specification can successfully detect the violation of 'no mutual secret knowledge' invariant when one of the participant can bypass mempool and give the transaction directly to the miner (this problem was pointed out by ZmnSCPxj in the original SAS thread [2]) I'm not sure if I follow. The issue ZmnSCPxj described about bypassing the mempool was not a violation. It was merely a "nuisance" strategy that causes Alice to have to abort in three transactions. Also note that I subsequently pointed out in the thread that this strategy does not work, because Alice is supposed to abort sooner than that if Bob still has not locked up any funds. Or perhaps you're referring to the issue ZmnSCPxj pointed out after that, where refund transaction #1 and the success transaction could both become valid at the same time. It would make sense for the test to pick up on that, but I believe that is ultimately also not an issue (see my last reply in the thread). >I did not understand what the destination of Alice cooperative spend of refund_tx#1 will be This transaction can be spent by Alice & Bob right away or by Alice a day later (in relative time, so the tx has to confirm first). The Alice & Bob condition is there purely to ensure that Bob can spend the money before Alice once he receives her key at the end of the protocol. If it helps, you could model this transaction as two separate transactions instead: txA: 1 day absolute timelock to Alice & Bob (reveals secretAlice), which can then be spent by txB: +1 day relative timelock to Alice This should be functionally equivalent. Also note that the protocol should fully function if refund tx #1 did not exist at all. It merely serves to save block space in certain refund scenarios. >it would be great to have an established framework for modelling of the behavior in Bitcoin-like blockchain networks. In particular, having a model of mempool-related behavior would help to reason about difficult RBF/CPFP issues A laudable goal. Good luck with your efforts. Cheers, Ruben On Wed, May 13, 2020 at 7:07 PM Dmitry Petukhov via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > The Succint Atomic Swap contract presented by Ruben Somsen recently has > drawn much interest. > > I personally am interested in the smart contracts realizeable in the > UTXO model, and also interested in applying formal methods to the > design and implementation of such contracts. > > I think that having formal specifications for the contracts and to be > able to machine-check the properties of these specifications is very > valuable, as it can uncover the corner cases that might be difficult to > uncover otherwise. > > The SAS contract is complex enough that it may benefit from formal > specification and machine checking. > > I created a specification in TLA+ [1] specification language based on > the explanation and the diagram given by Ruben. > > The checking of the model encoded in the specification can successfully > detect the violation of 'no mutual secret knowledge' invariant when one > of the participant can bypass mempool and give the transaction directly > to the miner (this problem was pointed out by ZmnSCPxj in the original > SAS thread [2]) > > There's one transition that was unclear how to model, though: I did not > understand what the destination of Alice cooperative spend of > refund_tx#1 will be, so this transition is not modelled. > > I believe there can be more invariants and temporal properties of the > model that can be checked. At the moment the temporal properties > checking does not work, as I didn't master TLA+ enough yet. The safety > invariants checking should work fine, though, but more work needed to > devise and add the invariants. > > In the future, it would be great to have an established framework for > modelling of the behavior in Bitcoin-like blockchain networks. > In particular, having a model of mempool-related behavior would help to > reason about difficult RBF/CPFP issues. The specification I present > models the mempool, but in a simple way, without regards to the fees. > > The specification can be found in this github repository: > https://github.com/dgpv/SASwap_TLAplus_spec > > There could be mistakes or omissions in the specified model, I hope > that public review can help find these. > > It would be great to receive comments, suggestions and corrections, > especially from people experienced in formal methods and TLA+, as this > is only my second finished TLA+ spec and only my third project using > formal methods (I created bitcoin transaction deserialization code in > Ada/SPARK before that [3]). Please use the github issues or off-list > mail to discuss if the matter is not interesting to the general > bitcoin-dev list audience. > > [1] https://lamport.azurewebsites.net/tla/tla.html > > [2] > >
[bitcoin-dev] TLA+ specification for Succint Atomic Swap
The Succint Atomic Swap contract presented by Ruben Somsen recently has drawn much interest. I personally am interested in the smart contracts realizeable in the UTXO model, and also interested in applying formal methods to the design and implementation of such contracts. I think that having formal specifications for the contracts and to be able to machine-check the properties of these specifications is very valuable, as it can uncover the corner cases that might be difficult to uncover otherwise. The SAS contract is complex enough that it may benefit from formal specification and machine checking. I created a specification in TLA+ [1] specification language based on the explanation and the diagram given by Ruben. The checking of the model encoded in the specification can successfully detect the violation of 'no mutual secret knowledge' invariant when one of the participant can bypass mempool and give the transaction directly to the miner (this problem was pointed out by ZmnSCPxj in the original SAS thread [2]) There's one transition that was unclear how to model, though: I did not understand what the destination of Alice cooperative spend of refund_tx#1 will be, so this transition is not modelled. I believe there can be more invariants and temporal properties of the model that can be checked. At the moment the temporal properties checking does not work, as I didn't master TLA+ enough yet. The safety invariants checking should work fine, though, but more work needed to devise and add the invariants. In the future, it would be great to have an established framework for modelling of the behavior in Bitcoin-like blockchain networks. In particular, having a model of mempool-related behavior would help to reason about difficult RBF/CPFP issues. The specification I present models the mempool, but in a simple way, without regards to the fees. The specification can be found in this github repository: https://github.com/dgpv/SASwap_TLAplus_spec There could be mistakes or omissions in the specified model, I hope that public review can help find these. It would be great to receive comments, suggestions and corrections, especially from people experienced in formal methods and TLA+, as this is only my second finished TLA+ spec and only my third project using formal methods (I created bitcoin transaction deserialization code in Ada/SPARK before that [3]). Please use the github issues or off-list mail to discuss if the matter is not interesting to the general bitcoin-dev list audience. [1] https://lamport.azurewebsites.net/tla/tla.html [2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-May/017846.html [3] https://github.com/dgpv/spark-bitcoin-transaction-example ___ 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
