David A. Harding [ARCHIVE] on Nostr: 📅 Original date posted:2019-12-17 📝 Original message: On Tue, Dec 17, 2019 at ...
📅 Original date posted:2019-12-17
📝 Original message:
On Tue, Dec 17, 2019 at 09:34:07AM +0100, Bastien TEINTURIER wrote:
> With Phoenix [1], we've been experimenting with pay-to-open [2].
>
> That works well in practice and provides a great UX for newcomers, but
> it requires temporary trust between the user and our node (until the
> funding tx confirms).
>
> That trust relationship appears in two places:
> [...]
> b. The user trusts that we won't double-spend the funding transaction
> [...]
> I'm more concerned about fixing (b). As long as the funding
> transaction is unconfirmed, there's a risk of double-spending by the
> funder.
The typical proposed solution for this type of problem is a single-show
signature[1], a signature that will reveal the private key used to
create it if it's combined with another signature from the same private
key. In other words, if you sign two different spends of the same UTXO,
someone who see both spends will be able to redirect all of that UTXO's
value to themselves. In that case, your change output becomes a form of
fidelity bond---you get to keep it if you act honestly; otherwise,
someone else gets it (most likely whoever mines the next block).
I'm not aware of any way to currently force single-show signatures in
Bitcoin, so this is pretty theoretical. Also, single-show signatures
add a lot of fragility to any setup and make useful features like RBF
fee bumping unavailable.
As a less complete but more practical solution, you might want to
consider a signing federation. This doesn't change the need for trust,
but it does allow spreading that trust around. E.g. if spending your
funds requires three signatures each from one of five different
respected companies helping pioneer LN (perhaps all in different legal
jurisdictions), that might help mitigate user concerns about double
spending. Besides the extra communicating and signing, your existing
workflow wouldn't need to change.
-Dave
[1] Here's some math for single show signatures in ECDSA:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-December/007038.html
Probably a more practical way to enforce single-show in Bitcoin
would be something like OP_CHECKSIGFROMSTACK, e.g. as implemented in
Elements:
https://elementsproject.org/features/opcodes
Maybe SIGHASH_NOINPUT/SIGHASH_ANYPREVOUT could also be used to
enforce single-show with the right script? I'm not so sure about
that.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191217/dcd8987d/attachment.sig>;
📝 Original message:
On Tue, Dec 17, 2019 at 09:34:07AM +0100, Bastien TEINTURIER wrote:
> With Phoenix [1], we've been experimenting with pay-to-open [2].
>
> That works well in practice and provides a great UX for newcomers, but
> it requires temporary trust between the user and our node (until the
> funding tx confirms).
>
> That trust relationship appears in two places:
> [...]
> b. The user trusts that we won't double-spend the funding transaction
> [...]
> I'm more concerned about fixing (b). As long as the funding
> transaction is unconfirmed, there's a risk of double-spending by the
> funder.
The typical proposed solution for this type of problem is a single-show
signature[1], a signature that will reveal the private key used to
create it if it's combined with another signature from the same private
key. In other words, if you sign two different spends of the same UTXO,
someone who see both spends will be able to redirect all of that UTXO's
value to themselves. In that case, your change output becomes a form of
fidelity bond---you get to keep it if you act honestly; otherwise,
someone else gets it (most likely whoever mines the next block).
I'm not aware of any way to currently force single-show signatures in
Bitcoin, so this is pretty theoretical. Also, single-show signatures
add a lot of fragility to any setup and make useful features like RBF
fee bumping unavailable.
As a less complete but more practical solution, you might want to
consider a signing federation. This doesn't change the need for trust,
but it does allow spreading that trust around. E.g. if spending your
funds requires three signatures each from one of five different
respected companies helping pioneer LN (perhaps all in different legal
jurisdictions), that might help mitigate user concerns about double
spending. Besides the extra communicating and signing, your existing
workflow wouldn't need to change.
-Dave
[1] Here's some math for single show signatures in ECDSA:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-December/007038.html
Probably a more practical way to enforce single-show in Bitcoin
would be something like OP_CHECKSIGFROMSTACK, e.g. as implemented in
Elements:
https://elementsproject.org/features/opcodes
Maybe SIGHASH_NOINPUT/SIGHASH_ANYPREVOUT could also be used to
enforce single-show with the right script? I'm not so sure about
that.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191217/dcd8987d/attachment.sig>;