[bitcoin-dev] Blind Statechains

[Tom Trevethan]

Hi Ruben,

Thanks for the comments.

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

My understanding was that users would need to verify the uniqueness of the
ownership of the previous owner, and verify that the ownership had been
signed over (which acts as proof of ownership in case the SE steals) but
that backup transaction rules would be enforced by the SE (the SE must be
trusted to not collude with a previous owner to sign a 'theft' transaction
before the UTXO is sold on). Even if a new owner verifying that all of the
previous backup transactions are correct does not prove that the SE has not
signed anything else we don't know about.

In the case of a blinded SE, we were thinking the way it could work is that
the SE would still need to be trusted to state how many times it had
co-signed. So a new owner would ask the SE how many times it has signed
something (e.g. 27) and then the new owner would need to check that there
are exactly 27 back up transactions and verify that each one was following
the rules. Then when it came to transfer, they would send the 27 + their
own backup to the new owner, who would then ask the SE again how many it
had signed.

Yes, the SE can store all of these transactions, encrypted with the current
owners key, to make the UX easier.

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

Yes, that is the aim. Like you mentioned, this may help a lot with legal
status of the SE, but also prevent the SE from being able to link swaps
(while still performing them atomically).

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

Interesting point. I guess it is not in the interest of the owner to tell
the SE that they have pegged-out a UTXO (as the SE might be able to
correlate with on-chain txs). Maybe the user wallet can send the SE
a message that the UTXO is pegged out some random interval after it has
happened.

Cheers,

Tom

On Fri, Jun 12, 2020 at 9:35 PM Ruben Somsen <rsomsen at gmail.com> wrote:

> 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 at 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 at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200614/b23d055a/attachment.html>