Re: [bitcoin-dev] SAS: Succinct Atomic Swap

2020-05-14 Thread ZmnSCPxj via bitcoin-dev
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

2020-05-14 Thread William Casarin via bitcoin-dev


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

2020-05-14 Thread Keagan McClelland via bitcoin-dev
> 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

2020-05-14 Thread Ruben Somsen via bitcoin-dev
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

2020-05-14 Thread Dmitry Petukhov via bitcoin-dev
В 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