Re: [bitcoin-dev] Blind Statechains

2020-06-12 Thread Ruben Somsen via bitcoin-dev
Hi Tom, Blind signatures are certainly a nice feature, great to see that you're considering it. >So each new owner of a UTXO must receive, store and verify the full sequence of previous owner backup transactions to make sure that no previous owner has asked the SE to sign a transaction that

Re: [bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility

2020-06-01 Thread Ruben Somsen via bitcoin-dev
Hi ZmnSCPxj, >If Alice is paying to a non-SAS aware payee Yeah, I agree that this use case is not possible without a third transaction (preferably from the timelocked side, in the case of SAS). My point was merely that you can swap and simultaneously merge some of your outputs into the post-swap

Re: [bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility

2020-05-31 Thread Ruben Somsen via bitcoin-dev
Hi ZmnSCPxj, >Just to be clear, you mean we can use the MuSig key-combination protocol for the non-timelocked SAS output, but (of course) not the signing protocol which is inherently Schnorr. Then knowledge of both of the original private keys is enough to derive the single combined private key.

Re: [bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility

2020-05-30 Thread Ruben Somsen via bitcoin-dev
Hey Chris, Excellent write-up. I learned a few new things while reading this (particularly how to overcome the heuristics for address reuse and address types), so thank you for that. I have a few thoughts about how what you wrote relates to Succinct Atomic Swaps (SAS)[0]. Perhaps it's useful.

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

2020-05-15 Thread Ruben Somsen via bitcoin-dev
Hi ZmnSCPxj, >The proper response here is that Bob should broadcast success tx before the refund tx #1 becomes valid. That's right. And even if Bob neglects to do that, it still won't cause chaos for Alice as long as she chooses the path for refund tx #2. >at least part of the fund must be lost

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,

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] 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

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] 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

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

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] SAS: Succinct Atomic Swap

2020-05-11 Thread Ruben Somsen via bitcoin-dev
Hi ZmnSCPxj, Thanks for your feedback :) >CoinSwap for privacy is practically a "cross" chain atomic swap with the same >chain and token for both sides of the swap I agree, I didn't mean to imply that was new, only that this protocol makes it more efficient. >"Instead, Bob simply hands

[bitcoin-dev] SAS: Succinct Atomic Swap

2020-05-11 Thread Ruben Somsen via bitcoin-dev
Works today with single signer ECDSA adaptor signatures[0], or with Schnorr + MuSig. Diagram here: https://gist.github.com/RubenSomsen/8853a66a64825716f51b409be528355f#file-succinctatomicswap-svg Advantages: - Requires merely two on-chain transactions for successful completion, as opposed to

Re: [bitcoin-dev] Statechain implementations

2020-03-28 Thread Ruben Somsen via bitcoin-dev
Hi ZmnSCPxj, the current owner can ask the statechain entity to sign an alternative to > the first stage, with 0 relative locktime Unless I am misunderstanding something, this seems to run into the problem that the original first stage transaction is already out there (and its relative timelock

Re: [bitcoin-dev] Statechain implementations

2020-03-28 Thread Ruben Somsen via bitcoin-dev
Hi Bob, Looks like we're largely thinking along the same lines. It's unlikely that a party sending a UTXO to another party will have a UTXO > of exactly the right size that's needed My original proposal uses adaptor signatures to ensure swapping UTXOs is atomic. All parties choose a secret,

Re: [bitcoin-dev] Statechain implementations

2020-03-27 Thread Ruben Somsen via bitcoin-dev
Hi ZmnSCPxj, I appreciate the input. >Any standardness issue can be fixed by embedding it in a P2WSH / P2SH, you can use an `OP_TRUE` `redeemScript`, for instance. Good point. I guess the conversation I recall reading must have been about avoiding p2sh in order to lower the tx size. >broadcast

Re: [bitcoin-dev] Statechain implementations

2020-03-26 Thread Ruben Somsen via bitcoin-dev
nuxfoundation.org> wrote: > >> Ruben Somsen via bitcoin-dev >> writes: >> > Regarding modification 1, I agree with ZmnSCPxj that >> > Decker-Wattenhofer is your next best option, given that eltoo is not >> > yet available. But if you are going to use a

Re: [bitcoin-dev] Statechain implementations

2020-03-26 Thread Ruben Somsen via bitcoin-dev
Hi Tom, Nice to see you working on this. Regarding modification 1, I agree with ZmnSCPxj that Decker-Wattenhofer is your next best option, given that eltoo is not yet available. But if you are going to use a kickoff transaction, keep in mind that every previous owner will have a copy of it.

Re: [bitcoin-dev] Blind Merged Mining with covenants ( sighash_anyprevout / op_ctv )

2019-12-26 Thread Ruben Somsen via bitcoin-dev
tay? > > https://commerceblock.readthedocs.io/en/latest/mainstay/index.html > > https://mainstay.xyz > > > On Thu, Dec 26, 2019 at 2:25 AM Ruben Somsen via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> Blind Merged Mining (BMM) is

[bitcoin-dev] Blind Merged Mining with covenants ( sighash_anyprevout / op_ctv )

2019-12-25 Thread Ruben Somsen via bitcoin-dev
Blind Merged Mining (BMM) is the idea of committing the hash of another blockchain into a unique location on the Bitcoin blockchain, and paying a Bitcoin fee to miners for the privilege of deciding this hash and capturing the fees inside the other blockchain. Since miners don’t have to know what

Re: [bitcoin-dev] PoW fraud proofs without a soft fork

2019-09-10 Thread Ruben Somsen via bitcoin-dev
Hi ZmnSCPxj, >I suppose the critical difference is that invalid inflation can fool the SPV >node, the fullnode will not be so fooled. That is correct. If you sybil the SPV node, you can break any consensus rule you like. I believe this is inherent to fraud proofs in general, because you skip

[bitcoin-dev] PoW fraud proofs without a soft fork

2019-09-07 Thread Ruben Somsen via bitcoin-dev
After looking more deeply into Tadge Dryja’s utreexo work [0], it has become clear to me that this opens up a way to implement PoW fraud proofs [1] without a soft fork. With utreexo, we can efficiently verify state transitions between blocks. Verifying a block from a valid utreexo hash requires

Re: [bitcoin-dev] Formalizing Blind Statechains as a minimalistic blind signing server

2019-06-14 Thread Ruben Somsen via bitcoin-dev
Hi ZmnSCPxj, >Basically, the "Stale Factory" and "Broken Factory" problems. I see, I'll have to read up on those. >Combining it via MuSig is probably best, as the server is now unable to >recognize even the pubkey (assuming it never is informed `X`). Yes, that's the current thinking. See

Re: [bitcoin-dev] Formalizing Blind Statechains as a minimalistic blind signing server

2019-06-12 Thread Ruben Somsen via bitcoin-dev
Hi ZmnSCPxj, Thanks for the reply. Sorry to keep you waiting, Coredev and Breaking Bitcoin have been keeping me busy. Transcript from Coredev (thanks Bryan): http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2019-06-07-statechains/ Blind Statechains at Breaking Bitcoin:

Re: [bitcoin-dev] Formalizing Blind Statechains as a minimalistic blind signing server

2019-06-06 Thread Ruben Somsen via bitcoin-dev
Hi ZmnSCPxj, Thank you for your comments. >Of note, is that a Decker-Russell-Osuntokun construction ("eltoo") is not >*strictly* required. We can still make use of the Decker-Wattenhofer >construction instead. Yes, an early draft (from before the eltoo paper) was using that construction, but

[bitcoin-dev] Formalizing Blind Statechains as a minimalistic blind signing server

2019-06-04 Thread Ruben Somsen via bitcoin-dev
Hi everyone, For those who are unfamiliar, Statechains enable the transfer UTXOs off-chain with the help of a Statechain entity (trusted server(s)) without giving them full custodial control over your coins [0]. At Scaling Bitcoin ‘18 [1] I briefly mentioned utilizing blind signatures [2] to make

Re: [bitcoin-dev] Improving SPV security with PoW fraud proofs

2019-04-22 Thread Ruben Somsen via bitcoin-dev
Hi ZmnSCPxj, Allow me to reply to your post in mixed order (fraud proofs first): >But peers can be set up to allow you to hear of all chains while denying you >proof of the invalidity of some UTXO. I don't believe this is fundamentally different. In either scenario you end up on the wrong

Re: [bitcoin-dev] Improving SPV security with PoW fraud proofs

2019-04-20 Thread Ruben Somsen via bitcoin-dev
Hi ZmnSCPxj, >There is no safe way to use UTXO sets without identifying who is telling you >those sets are valid, or making it expensive to lie >The first option requires trust and is weaker than SPV, the second requires >committing to a proof-of-work Olaoluwa Osuntokun's BIP157 manages to

Re: [bitcoin-dev] Improving SPV security with PoW fraud proofs

2019-04-19 Thread Ruben Somsen via bitcoin-dev
Hi ZmnSCPxj and Ethan, I apologize if my initial explanation was confusing, but it looks like you figured it out. For every fork, SPV clients only have to download one block. If there is a fork after block N, this means there are two blocks at N+1. You only download and verify N+1 from the longer

[bitcoin-dev] Improving SPV security with PoW fraud proofs

2019-04-18 Thread Ruben Somsen via bitcoin-dev
Simplified-Payment-Verification (SPV) is secure under the assumption that the chain with the most Proof-of-Work (PoW) is valid. As many have pointed out before, and attacks like Segwit2x have shown, this is not a safe assumption. What I propose below improves this assumption -- invalid blocks will

Re: [bitcoin-dev] Safer NOINPUT with output tagging

2018-12-19 Thread Ruben Somsen via bitcoin-dev
Hi Johnson, The design considerations here seem similar to the ML discussion of whether Graftroot should be optional [1]. >While this seems fully compatible with eltoo, is there any other proposals >require NOINPUT, and is adversely affected by either way of tagging? As far as I can tell it

Re: [bitcoin-dev] Guiding transaction fees towards a more censorship resistant outcome

2018-09-06 Thread Ruben Somsen via bitcoin-dev
which are only valid if they are mined on > top of a specific block." - in practice, does that usually means at any > height above a specific block? > > > From: bitcoin-dev-boun...@lists.linuxfoundation.org > on behalf of Ruben Somsen v