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

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

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

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

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

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

Re: [bitcoin-dev] TLA+ specification for Succint Atomic Swap

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

[bitcoin-dev] TLA+ specification for Succint Atomic Swap

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

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

2020-05-13 Thread Antoine Riard via bitcoin-dev
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

Re: [bitcoin-dev] TLA+ specification for Succint Atomic Swap

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

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

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

Re: [bitcoin-dev] TLA+ specification for Succint Atomic Swap

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

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

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

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

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