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
>