Re: [bitcoin-dev] On the scalability issues of onboarding millions of LN mobile clients

2020-05-12 Thread Chris Belcher via bitcoin-dev
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

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

2020-05-12 Thread Chris Belcher via bitcoin-dev
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.

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

2020-05-12 Thread Lloyd Fournier via bitcoin-dev
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.

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

2020-05-12 Thread Lloyd Fournier via bitcoin-dev
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

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

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

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

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

Re: [bitcoin-dev] [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients

2020-05-12 Thread Richard Myers via bitcoin-dev
Thanks for sharing your thoughts ZmnSCPxj. I think I can summarize your concern as: A node without direct internet connectivity can not rely on an opportunistically incentivized local network peer for blockchain information because the off-grid node's direct LN peers could collude to not forward

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

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

Re: [bitcoin-dev] [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients

2020-05-12 Thread ZmnSCPxj via bitcoin-dev
Good morning Richard, > Thanks for sharing your thoughts ZmnSCPxj. I think I can summarize your > concern as: A node without direct internet connectivity can not rely on an > opportunistically incentivized local network peer for blockchain information > because the off-grid node's direct LN

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

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