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