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 mechanism is some kind of
splitting construction (which I have not studied in detail).
>   * At each update of the state, all participants must sign off on the
new state.

Overall, that's a really accurate description. I would add you can embed a
funding outpoint of any offchain protocol on the splitting construction,
modulo some timelocks shenanigans.

> In order to hide transfers from the elected WabiSabi server, participants
can maintain two coins in every state, and move coins randomly across the
two coins they own at each state update, in order to hide "real" transfers
from the elected server.

Yes I'm quite sure you can reuse WabiSabi as a communication channel
between participants, assuming you support tapscript and merkle branch
transports, and server build a tree. Generally, we tried to keep design as
flexible as we can to reuse privacy tools.

> Indeed, from what I can understand, in order to properly set up the
splitting transactions in the first place, at each state every participant
needs to know how much each other participant actually owns in the CoinPool
at that point in time.

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. I think it comes with a higher
onchain cost in case of pool breakage.

> That way, output addresses can be to fresh pseudonyms of the participant,
removing all linkages of participant to amount they own, and each
participant can maintain multiple outputs per state for their own purposes
and to mildly obscure exactly how much they own in total.

That's right that an in-pool observer may learn a link between an exit and
an onchain withdraw. There is a future optimization, if you can swap your
withdraw with an already onchain output, therefore breaking heuristics.

> We can do this by using `SIGHASH_ANYPREVOUT` to force whoever performs a
unilateral close of the CoinPool to pay the onchain fees involved, so that
it would have to be a good reason indeed to perform a unilateral close.

Absolutely, for the fee structure, as the withdraw output is at the
discretion of user, I was thinking some CPFP. There is maybe a better
solution, haven't spend that much on the exact adequate, incentives-align
mechanism beyond a "withdraw-must-pay-its-fees".

Thanks for the high-quality review, as usual ;)

Antoine

Le ven. 12 juin 2020 à 04:39, ZmnSCPxj  a écrit :

> 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 of the update mechanism is some kind of
> splitting construction (which I have not studied in detail).
>   * At each update of the state, all participants must sign off on the new
> state.
>
> It seems to me that it would be possible to use a [WabiSabi protocol](
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/017969.html)
> during negotiation of a new state.
>
> Now, WabiSabi is a client-server protocol.
> As all participants in the CoinPool are needed in order to ratify each new
> state anyway, they can simply elect one of their number by drawing lots, to
> act as server for a particular state update.
>
> Then the participants can operate as WabiSabi clients.
> Each participant registers the outputs they currently own in the current
> state, getting credentials that sum up to the correct value.
> Then, during the WabiSabi run, they can exchange credentials among the
> participants in order to perform value transfers inside the WabiSabi
> construction.
> Then, at output registration, they register new outputs to put in the next
> state of the CoinPool.
>
> In order to hide transfers from the elected WabiSabi server, participants
> can maintain two coins in every state, and move coins randomly across the
> two coins they own at each state update, in order to hide "real" transfers
> from the elected server.
>
> Then, after output registration, the participants ratify the new state by
> signing off on the new state and revoking the previous state, using the
> update mechanism.
>
> Of course, we should note that one desired feature for CoinPool in the
> original proposal is that a participant can exit, and the CoinPool would
> still remain valid, but only for the remaining participants.
>
> This is arguably a mild privacy leak: every other participant now knows
> how much that particular participant 

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 between 
current-state aliases and the actual participants.

Now, in order to authorize moving coins from an output on the current state to 
a new output on the next state, obviously the pool needs to get a signature 
from its current owner.
Ideally, we would not want to have to implement SCRIPT inside the CoinPool 
software.

And with Taproot, a pubkey can hide one or more SCRIPTs.
If we use pubkeys as the identities of owners of coins, then it allows an alias 
to encode a SCRIPT.

With the combination of both features, we can instantiate HTLCs (or, with 
`SIGHASH_ANYPREVOUT`, PTLCs) inside a CoinPool "alias" pubkey identity, 
allowing for interoperation with LN.

Now suppose I have 1.0 BTC in a CoinPool.
I want to make an HTLC with you (hashlocked to you, timelocked to me), for 0.5 
BTC.

I encode the HTLC SCRIPT, and put it into a Taproot whose internal pubkey is a 
MuSig of fresh identities of mine and yours.

Then, inside the CoinPool, I split my 1.0BTC to a 0.5BTC coin to a fresh 
identity of mine, and 0.5BTC to our HTLC Taproot.

If you can acquire the hash, you give it to me, and I am supposed to hand you a 
partial signature share to the HTLC Taproot that you can later complete and 
present to the CoinPool in the next update round in order to get the HTLC value.
If I do not hand you the signature share even after you hand the hash, you just 
drop the entire CoinPool onchain, instantiating the HTLC Taproot output 
onchain, and using the SCRIPT branch to claim using the hash you know.

If the timelock expires, I ask you to hand over your partial signature to the 
HTLC Taproot that I can later complete and present to the CoinPool in the next 
update round to recover the HTLC value.
If you do not hand over the signature share, I drop the CoinPool onchain, which 
instantiates the HTLC Taproot output onchain, and use the SCRIPT branch to 
claim using the timelock branch.

You can also ask to abort the HTLC "early", before the timelock expires, by 
handing over your partial signature to the HTLC Taproot, which I can later 
complete and present to the CoinPool in the next update round.
This is equivalent to `update_fail_htlc` in the current LN BOLT spec.

This allows operation of any SCRIPT, incidentally, without requiring that 
CoinPool software include a SCRIPT interpreter, only signature validation.
Any time an output absolutely needs a SCRIPT, we just drop the CoinPool onchain 
and let onchain handle the SCRIPT interpretation.

Regards,
ZmnSCPxj

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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. I think it comes with a higher 
> onchain cost in case of pool breakage.


Perhaps not necessarily.

An advantage of WabiSabi is I can pretend to be two or more participants.

For example, I can pretend to be "Alice" and "Bob", and pretend that "Alice" 
owes a life debt to "Bob".

At initial state setup, I put a 1.0 BTC coin as "Alice" and a 0.5 BTC coin as 
"Bob".

Now, at each state update I need to sign as "Alice" and "Bob".
However, after the first initial state, I can use a new persona "Bobby" to 
*own* my coins, even though I still have to sign as "Alice" and "Bob" in every 
state update.

What the other pool participants see is that the 1.0 BTC "Alice" coin and the 
0.5 BTC "Bob" coin are merged into the 1.5 BTC "Bobby" coin.
What they cannot be sure of is:

* "Alice" paid to "Bob", who is now pretending to be "Bobby".
* "Bob" paid to "Alice", who is now pretending to be "Bobby".
* "Alice" and "Bob" are the same person, and is also pretending to be "Bobby".

All the other participants know is that whoever owns the coin *now* is still 
part of the pool, but cannot be sure which participant *really* owns which 
coin, and whether participants are sockpuppets (which is why it should use 
n-of-n at each state update, incidentally).

In effect, it "imports" the possibility of PayJoin inside the CoinPool 
construction.



Regards,
ZmnSCPxj
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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 issues.

With regards to scalability, I hit it on my own while inquiring
covenanted-Bitcoin contracts for international trade. I mentioned the
any-order issue on such multi-party complex contracts in a talk last summer
(https://github.com/ariard/talk-slides/blob/master/advanced-contracts.pdf).

> All of these channels can be constructed and set up non-interatively using
> CTV, and updated interactively. By default payments can happen with
minimal
> coordination of parties by standard lightning channel updates at the leaf
> nodes, and channels can be rebalanced at higher layers with more
> participation.

Side review note on OP_CTV: I think it would be great to define
non-interactivity better, namely at least between 3 phases: establishment,
operation, closing.

Even OP_CTV protocols assume interactivity at establishment, at least 1) to
learn payees pubkeys endpoint (and internal leaves pubkeys if you want
update at operation) 2) validate transaction tree correctness between
participants.

At operation, it depends if participants want to dynamically rebalance
value across channels or not. If you desire dynamically rebalancing, assume
internal leaves scriptpubkeys are (multisig-all OR OP_CTV'ed merkle_tree).
Using OP_CTV is a saving in message rounds for every constant expression
across tree updates.

At closing, depends again if participants have committed update keys or
not. If dynamic update, you can prune the whole tree and just commit final
balances onchain, either with a O(N) fan-out transaction (N outputs) or a
O(log(N)) congestion tree (N transactions).

So I would say the originality of a hashchain covenant like OP_CTV is to
provide onchain *immutability* (unforgeability?) of the offchain
transaction tree and thus provides instant finality to payees. You can get
the same semantic with off-chain covenant, pre-signed set of transactions,
assuming more communications rounds and performance hit.

That said, IMO, immutability comes with a security trade-off, namely if any
payout key committed in your OP_CTV tree gets compromised your funds are at
stake. And you can't update the tree anymore at the root to rotate keys. I
think this should be weighted by anyone designing covenant protocols,
especially vaults.

> I don't think the following requirement: "A
> CoinPool must satisfy the following *non-interactive any-order withdrawal*
> property: at any point in time and any possible sequence of previous
> CoinPool events, a participant should be able to move their funds from the
> CoinPool to any address the participant wants without cooperation with
> other CoinPool members." is desirable in O(1) space.

With current design (Pool_tx+Split_tx) it's O(2) space. Pool_tx is similar
to a commitment tx and thus enables off-chain novation of pool distribution.

> Let's be favorable to Accumulators and assume O(1), but keep in mind
constant may
> be somewhat large/operations might be expensive in validation for updates.

Using a Merkle Tree as an accumulator should be constant-size in space, but
likely it has to be O(log(N) in computation (N set elements). This overhead
in computation should be accounted for in accumulator sigops to avoid
network validation resources free-riding, but I think it's a better
trade-off minimizing chain footprint.

> So in this context, CTV Pool has a clear benefit. The last recipient can
> always clear in Log(N) time whereas in the accumulator pool, the last
> recipient has to wait much much longer. There's no asymptotic difference
in
> Tx Size, but I suspect that CTV is at least as good or cheaper since it's
> just one tx hash and doesn't depend on implementation.

Yes I agree CTV pool performs better in the worst-case scenario. In my
opinon what we should really look on is the probability of withdrawal
scenarios. I see 2 failure cases:
* a pool participant being offline, thus halting the pool
* a pool participant with external protocol requirement to fulfill, like a
HTLC to timeout onchain

With regards to 1) we assume that watchtower infra are likely to become
ubiquitous in the future (if you want a secure LN experience), so user
uptime should be near to 100%. Of course,  it's a new architecture which
comes with trade-offs, but interesting to explore.

With regards to 2) as of today channel-failure-rate (like unilateral close)
it's still quite important (30% IIRC) so it plays in favor of OP_CTV pool
but in the future I expect single-digit
therefore making CoinPool far more competitive. Do we envision protocol
more time-sensitive than LN in the future (atomic swaps...) ? Hard to gauge.

Do you see other ways to refine model, like integrating out-of-pool
liquidity needs rate ?

Note, I think 

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 could be used to
steal the UTXO. This may end up making wallets more bloated and clunky,
given that ownership of a UTXO could change hands thousands of times
off-chain.

Users would have to validate the history of the chain regardless, even if
it wasn't blind, to verify whether the statechain entity hasn't been
cheating, so the main difference would be in unblinding the data.

One of my original ideas was to use the transitory key to derive the
secrets that blind the signatures (basically like an HD wallet). The
statechain entity would then store and serve blind signatures, and any new
owner would download and unblind/verify them using the transitory key (no
extensive peer-to-peer transfer needed). It's possible to make the
off-chain transactions themselves deterministic, so they can just be
generated by the client without any additional data transfer. The only
potentially unique thing in a transaction is the refund address, but this
can be the same key as the ownership key on the statechain, tweaked with
the transitory key via Diffie-Hellman (to ensure it's not linkable if it
goes on-chain).

The general downside of this method is that all transactions are exposed to
anyone who learns the transitory key -- not just for the current
transactions (which can always be leaked no matter what you do), but also
all future transactions in that particular statechain. However, I should
note there doesn't actually seem to be much to learn, because the history
of each statechain is actually quite uninformative. The money just goes
from one pseudonymous owner to the next.

Of course you now have scheme that changes the transitory key with each
step, so I instead suggest you introduce a secondary "blinding key" to
achieve what I described.

I'm not sure whether this can also apply to 2P-ECDSA, but with Schnorr the
statechain entity wouldn't even learn the address for the funding
transaction, so it wouldn't be able to tell which UTXO it controls by
watching the blockchain. Ideally, this functionality would be preserved to
ensure the statechain entity can't be aware of the funds it's holding.

Another thing to note is that you won't know when a statechain has been
pegged out, so pruning will be impossible. You may wish to consider some
kind of liveness rule where one statechain transaction needs to be made per
year. If they miss the deadline, they're just forced on-chain, which is not
terrible, in any case.

Hope this helps!

Cheers,
Ruben



On Fri, Jun 12, 2020 at 9:23 PM Tom Trevethan via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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 entity or SE) can be engineered to be
> 'blind' to the transactions it is signing (i.e. it does not and cannot know
> the details of the transactions it is signing) which can give significant
> privacy benefits. It would enable more private off-chain coin-swaps, and
> make collusion more difficult.
>
> The only downside of a blind SE is that it can no longer enforce the rules
> governing the sequence of backup transactions it co-signs as owners can ask
> the SE to cosign any transaction. 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 could be used to steal the UTXO. This may end up making wallets more
> bloated and clunky, given that ownership of a UTXO could change hands
> thousands of times off-chain.
>
> In the case of a multisig, and Schnorr signatures, existing blind Schnorr
> protocols could be used to implement a blind SE, however we are opting to
> use two-party ECDSA (because there is no Schnorr yet, and in any case ECDSA
> will give a much bigger anonymity set). There is no current 2P ECDSA
> protocol that enables one of the two signers to be completely blinded, but
> it seems that this would require only minor modifications to an existing 2P
> ECDSA scheme (outlined here
> https://github.com/commerceblock/mercury/blob/master/doc/blind_2p_ecdsa.md
> based on Lindell 2017 https://eprint.iacr.org/2017/552 ).
>
> Any comments on any of this gratefully received.
>
> Tom
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list

[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 entity or SE) can be engineered to be
'blind' to the transactions it is signing (i.e. it does not and cannot know
the details of the transactions it is signing) which can give significant
privacy benefits. It would enable more private off-chain coin-swaps, and
make collusion more difficult.

The only downside of a blind SE is that it can no longer enforce the rules
governing the sequence of backup transactions it co-signs as owners can ask
the SE to cosign any transaction. 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 could be used to steal the UTXO. This may end up making wallets more
bloated and clunky, given that ownership of a UTXO could change hands
thousands of times off-chain.

In the case of a multisig, and Schnorr signatures, existing blind Schnorr
protocols could be used to implement a blind SE, however we are opting to
use two-party ECDSA (because there is no Schnorr yet, and in any case ECDSA
will give a much bigger anonymity set). There is no current 2P ECDSA
protocol that enables one of the two signers to be completely blinded, but
it seems that this would require only minor modifications to an existing 2P
ECDSA scheme (outlined here
https://github.com/commerceblock/mercury/blob/master/doc/blind_2p_ecdsa.md
based on Lindell 2017 https://eprint.iacr.org/2017/552 ).

Any comments on any of this gratefully received.

Tom
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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 original funding transaction.

Sorry, the taker funding transactions should have the nearer locktime L1, and 
the maker funding transctions should be the one with the later locktime L2.
This forces Macky to claim the incoming funds earlier, and claiming any of them 
unlocks the outgoing payout transaction.


Regards,
ZmnSCPxj
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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 of the update mechanism is some kind of splitting 
construction (which I have not studied in detail).
  * At each update of the state, all participants must sign off on the new 
state.

It seems to me that it would be possible to use a [WabiSabi 
protocol](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/017969.html)
 during negotiation of a new state.

Now, WabiSabi is a client-server protocol.
As all participants in the CoinPool are needed in order to ratify each new 
state anyway, they can simply elect one of their number by drawing lots, to act 
as server for a particular state update.

Then the participants can operate as WabiSabi clients.
Each participant registers the outputs they currently own in the current state, 
getting credentials that sum up to the correct value.
Then, during the WabiSabi run, they can exchange credentials among the 
participants in order to perform value transfers inside the WabiSabi 
construction.
Then, at output registration, they register new outputs to put in the next 
state of the CoinPool.

In order to hide transfers from the elected WabiSabi server, participants can 
maintain two coins in every state, and move coins randomly across the two coins 
they own at each state update, in order to hide "real" transfers from the 
elected server.

Then, after output registration, the participants ratify the new state by 
signing off on the new state and revoking the previous state, using the update 
mechanism.

Of course, we should note that one desired feature for CoinPool in the original 
proposal is that a participant can exit, and the CoinPool would still remain 
valid, but only for the remaining participants.

This is arguably a mild privacy leak: every other participant now knows how 
much that particular participant took out from the CoinPool.
Indeed, from what I can understand, in order to properly set up the splitting 
transactions in the first place, at each state every participant needs to know 
how much each other participant actually owns in the CoinPool at that point in 
time.

To hide how much each participant owns in the CoinPool from other participants, 
we would have to make unilateral closes expose all the current outputs, without 
trying to identify *which* participant exited the CoinPool, and thus preventing 
anyone else from figuring out exactly how much each *other* participant 
actually owns in the CoinPool on exit.
That way, output addresses can be to fresh pseudonyms of the participant, 
removing all linkages of participant to amount they own, and each participant 
can maintain multiple outputs per state for their own purposes and to mildly 
obscure exactly how much they own in total.

If we drop that feature (of being able to exit a participant without closing 
the *entire* CoinPool), of course, we need to mildly disincentivize a 
participant closing unilaterally for trivial reasons.
We can do this by using `SIGHASH_ANYPREVOUT` to force whoever performs a 
unilateral close of the CoinPool to pay the onchain fees involved, so that it 
would have to be a good reason indeed to perform a unilateral close.


Regards,
ZmnSCPxj
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev