Tom Trevethan [ARCHIVE] on Nostr: 📅 Original date posted:2020-06-12 📝 Original message:Hello, A statechain ...
📅 Original date posted:2020-06-12
📝 Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200612/3dbd6277/attachment.html>;
📝 Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200612/3dbd6277/attachment.html>;