Re: [bitcoin-dev] CoinPool, exploring generic payment pools for Fun and Privacy

2020-06-12 Thread ZmnSCPxj via bitcoin-dev
Good morning Antoine and Gleb, I have not studied the proposal in close detail yet, but anyway, my main takeaway roughly is: * The core of CoinPool is some kind of multiparticipant (N > 2) offchain update mechanism (Decker-Wattenhofer or Decker-Russell-Osuntokun). * The output at each state

Re: [bitcoin-dev] WabiSabi Inside Batched CoinSwap

2020-06-12 Thread ZmnSCPxj via bitcoin-dev
Good morning list, > - Alice (resp. Bob or Carol) creates (but does not sign) a funding > transaction from Alice coins to MuSig(Alice, Macky). > - Alice and Macky create a backout transaction, with `nLockTime` at L2, and > complete the plain MuSig signing ritual. > - Alice broadcasts the

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

[bitcoin-dev] Blind Statechains

2020-06-12 Thread Tom Trevethan via bitcoin-dev
Hello, A statechain implementation and service co-signs 'backup' (off-chain) transactions to transfer ownership of a UTXO from one owner to the next. A suggested here https://medium.com/@RubenSomsen/statechains-non-custodial-off-chain-bitcoin-transfer-1ae4845a4a39 , this service (the statechain

Re: [bitcoin-dev] CoinPool, exploring generic payment pools for Fun and Privacy

2020-06-12 Thread Antoine Riard via bitcoin-dev
Hi Jeremy, For the records, I didn't know between Greg and you was at the origin of payment pools. Thanks for your pioneer work here, obviously this draws inspiration from OP_CTV use cases and Channel Factories works, even if we picked up different assumptions and tried to address another set of

Re: [bitcoin-dev] CoinPool, exploring generic payment pools for Fun and Privacy

2020-06-12 Thread ZmnSCPxj via bitcoin-dev
Good morning Antoine, > Yes, that's part of future research, defining better *in-pool* observer. > Sadly, right now, even if you use mask construction inside, it's quite easy > to trace leaves by value weight. Of course, you can enforce equal-value > leaves, as for a regular onchain CoinJoin.

Re: [bitcoin-dev] CoinPool, exploring generic payment pools for Fun and Privacy

2020-06-12 Thread ZmnSCPxj via bitcoin-dev
Good morning Antoine, By dropping the requirement that a participant can seamlessly leave the CoinPool, it allows participants to split up their coins among new aliases and to use a different identity for later claiming coins. With WabiSabi, none of the other participants can get a mapping

Re: [bitcoin-dev] CoinPool, exploring generic payment pools for Fun and Privacy

2020-06-12 Thread Antoine Riard via bitcoin-dev
Hi ZmnSCPxj, > I have not studied the proposal in close detail yet, but anyway, my main takeaway roughly is: > > * The core of CoinPool is some kind of multiparticipant (N > 2) offchain update mechanism (Decker-Wattenhofer or Decker-Russell-Osuntokun). > * The output at each state of the update