From: Tom Trevethan <tom@commerceblock•com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: [bitcoin-dev] Blind Statechains
Date: Fri, 12 Jun 2020 19:11:52 +0100 [thread overview]
Message-ID: <CAJvkSsewzYTAsm0tneu6-9MT0a-CcYvJBcSmhzCUkmAJ95=T3A@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 1800 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 2124 bytes --]
next reply other threads:[~2020-06-12 18:12 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-12 18:11 Tom Trevethan [this message]
2020-06-12 20:35 ` Ruben Somsen
2020-06-14 22:24 ` Tom Trevethan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAJvkSsewzYTAsm0tneu6-9MT0a-CcYvJBcSmhzCUkmAJ95=T3A@mail.gmail.com' \
--to=tom@commerceblock$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox