From: Johnson Lau <jl2012@xbt•hk>
To: bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: [bitcoin-dev] Safety of committing only to transaction outputs
Date: Fri, 24 May 2019 04:54:01 +0800 [thread overview]
Message-ID: <77218514-9118-4FE2-8F7F-7BB215CF2BB6@xbt.hk> (raw)
[-- Attachment #1: Type: text/plain, Size: 2842 bytes --]
This is a meta-discussion for any approach that allows the witness committing to only transaction outputs, but not inputs.
We can already do the following things with the existing bitcoin script system:
* commit to both inputs and outputs: SIGHASH_ALL or SIGHASH_SINGLE, with optional SIGHASH_ANYONECANPAY
* commit to only inputs but not outputs: SIGHASH_NONE with optional SIGHASH_ANYONECANPAY
* not commit to any input nor output: not using any sigop; using a trivial private key; using the SIGHASH_SINGLE bug in legacy script
The last one is clearly unsafe as any relay/mining node may redirect the payment to any output it chooses. The witness/scriptSig is also replayable, so any future payment to this script will likely be swept immediately
SIGHASH_NONE with ANYONECANPAY also allows redirection of payment, but the signature is not replayable
But it’s quite obvious that not committing to outputs are inherently insecure
The existing system doesn’t allow committing only to outputs, and we now have 3 active proposals for this function:
1. CAT and CHECKSIGFROMSTACK (CSFS): https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016946.html <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016946.html>
2. ANYPREVOUT (aka NOINPUT): https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016929.html <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016929.html>
3. CHECKOUTPUTSHASHVERIFY (COHV): https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016934.html <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016934.html>
With outputs committed, redirecting payment is not possible. On the other hand, not committing to any input means the witness is replayable without the consent of address owner. Whether replayability is acceptable is subject to controversy, but the ANYPREVOUT proposal fixes this by requiring a chaperone signature that commits to input. However, if the rationale for chaperone signature stands, it should be applicable to all proposals listed above.
A more generic approach is to always require a “safe" signature that commits to at least one input. However, this interacts poorly with the "unknown public key type” upgrade path described in bip-tapscript (https://github.com/sipa/bips/blob/bip-schnorr/bip-tapscript.mediawiki <https://github.com/sipa/bips/blob/bip-schnorr/bip-tapscript.mediawiki>), since it’d be a hardfork to turn an “unknown type sig” into a “safe sig”. But we could still use a new “leaf version” every time we introduce new sighash types, so we could have a new definition for “safe sig”. I expect this would be a rare event and it won’t consume more than a couple leaf versions. By the way, customised sighash policies could be done with CAT/CSFS.
[-- Attachment #2: Type: text/html, Size: 3626 bytes --]
next reply other threads:[~2019-05-23 20:54 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-23 20:54 Johnson Lau [this message]
2019-05-24 20:59 ` Jeremy
2019-05-25 7:53 ` Johnson Lau
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=77218514-9118-4FE2-8F7F-7BB215CF2BB6@xbt.hk \
--to=jl2012@xbt$(echo .)hk \
--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