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] [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients
Orfeas Stefanos Thyfronitis Litos writes: > ZmnSCPxj via Lightning-dev writes: >> 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. > > Private full nodes serving headers to a handful of weak devices have > been mentioned many times as a good solution against all sorts of > problems in a future full of LN + SPV nodes. I agree. It should be > therefore a top priority to make the UX of connecting my mobile LN > client to my home full node extremely easy, so that centralised > services can't improve much on that step. Especially if I already run > a full node. > > Could someone briefly describe how this UX looks currently? And if > it's not as seamless as it could, what blockers are there? The UX for this doesn't have to be complicated. All you need is a node provider like FullyNoded, Casa, etc. My setup at home is a desktop with: - bitcoind - clightning - zerotier (or tailscale) (private vpn for connecting to your node from anywhere) - sparkwallet (clightning webui) bound to a zerotier interface So as long as you have a node that runs these bits of software, perhaps assumeutxo to speed up IBD, and a QR-code automagic setup, then UX should be pretty smooth. You would still need to deal with lightning backups and liquidity issues, but we just need to do more work on the software side to make that experience nicer. Cheers, Will -- https://jb55.com ___ 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
> It should be therefore a top priority to make the UX of connecting my mobile LN client to my home full node extremely easy, so that centralised services can't improve much on that step. Especially if I already run a full node. For what it's worth, this is a main research area for us at Start9 Labs. > Could someone briefly describe how this UX looks currently? And if it's not as seamless as it could, what blockers are there? At the root of all of these problems is that a "private server" is considered inconvenient. There is no fundamental reason this has to be the case. The main UX challenges we've found are around installation and configuration of server applications, not to mention, that users don't have an existing mental model for how to imagine applications. Most people who do not work on computers for a living have heard of servers but their firsthand experience with software is "apps". The fact that there is a component of their applications that runs remotely on computers they don't own. So in short: 1. Educating on the distinction between client and server apps is an open question whose burden will likely fall on the entire industry if we want to get this right and not have an exchange takeover of Bitcoin. 2. Apps that either require "zero configuration" or have very easy in-app walkthroughs of the bare essentials of configuration 3. GUI style installs of server applications familiar to those who have installed desktop or mobile software. I'm sure there are more things we'll learn as we grow but these are the top three observations we've made and this is our primary area of work. > Private full nodes serving headers to a handful of weak devices have been mentioned many times as a good solution against all sorts of problems in a future full of LN + SPV nodes. I agree. This is the main thesis I've been going on for a while. Once your full node has synced the whole blockchain and the total set of headers is known, you don't actually even need to carry 100% of the block data, as you can re-fetch a needed block from elsewhere and verify the block data matches the header you've already checked for consensus. From there the header chain can serve as base truth for a whole set of L2+ services or L1 SPV wallets. Ideally, in a model like this, more expensive peer services would be authenticated so that your other applications could get the data they need without exposing your full node to the extra costs of those who are not running their own nodes. Typically we've used Core's RPC API for this but as others have mentioned upthread JSON is a wasteful format and there are good reasons that you'd want Lightning to be able to request peer services without necessarily having ownership control over the node. The other thing I wanted to note is the fact that the issue isn't that Lightning does SPV, the issue is around whether or not the node it is tethered to is *actually* trusted since SPV necessarily trusts some dimensions of the information supplied to it. Doing SPV against a full node you own is no more dangerous than indexing watch only addresses in Core and then asking for wallet/utxo information over RPC. Keagan On Thu, May 14, 2020 at 12:50 AM Orfeas Stefanos Thyfronitis Litos < o.thyfroni...@ed.ac.uk> wrote: > > > >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. > > Private full nodes serving headers to a handful of weak devices have been > mentioned many times as a good solution against all sorts of problems in a > future full of LN + SPV nodes. I agree. It should be therefore a top > priority to make the UX of connecting my mobile LN client to my home full > node extremely easy, so that centralised services can't improve much on > that step. Especially if I already run a full node. > > Could someone briefly describe how this UX looks currently? And if it's > not as seamless as it could, what blockers are there? > > Best, > Orfeas > > -- > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. > > ___ > Lightning-dev mailing list > lightning-...@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > ___ 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
Hi Dmitry, >But it should be noted that it is not enough that Bob publishes success_tx before refund_tx_1 became valid. The success_tx needs to be confirmed before refund_tx_1 became valid. Agreed, my write-up would benefit from pointing this out more explicitly. Cheers, Ruben On Thu, May 14, 2020 at 9:05 AM Dmitry Petukhov wrote: > В Thu, 14 May 2020 07:31:13 +0200 > Ruben Somsen wrote: > > > 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. > > Right. But it should be noted that it is not enough that Bob publishes > success_tx before refund_tx_1 became valid. The success_tx needs to be > confirmed before refund_tx_1 became valid. > > Only Bob can spend success_tx so this is unlikely to be the practical > problem, unless the original fee of success_tx is too small and Bob > epically screws up CPFP-ing it. > > > >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 somehow missed it, and steps 5 and 6 in the diagram was not modelled > at all (on the other hand, it made the model simpler and I had > something working relatively quick). I now made the `signers_map` into > variable that can be changed to give Bob the ability to sign for Alice. > > With that change, step 6 can be modelled, but this will add a bunch of > new txs to the model (each Alice spend will have 'Bob unilateral > override' case) > ___ 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
В Thu, 14 May 2020 07:31:13 +0200 Ruben Somsen wrote: > 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. Right. But it should be noted that it is not enough that Bob publishes success_tx before refund_tx_1 became valid. The success_tx needs to be confirmed before refund_tx_1 became valid. Only Bob can spend success_tx so this is unlikely to be the practical problem, unless the original fee of success_tx is too small and Bob epically screws up CPFP-ing it. > >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 somehow missed it, and steps 5 and 6 in the diagram was not modelled at all (on the other hand, it made the model simpler and I had something working relatively quick). I now made the `signers_map` into variable that can be changed to give Bob the ability to sign for Alice. With that change, step 6 can be modelled, but this will add a bunch of new txs to the model (each Alice spend will have 'Bob unilateral override' case) ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev