Jeremy [ARCHIVE] on Nostr: 📅 Original date posted:2019-05-24 📝 Original message:Hi Johnson, As noted on ...

📅 Original date posted:2019-05-24
📝 Original message:Hi Johnson,

As noted on the other thread, witness replay-ability can be helped by
salting the taproot key or the taproot leaf script at the last stage of a
congestion control tree.

I also think that chaperone signatures should be opt-in; there are cases
where we may not want them. OP_COSHV is compatible with an additional
checksig operation.

There are also other mechanisms that can improve the safety. Proposed below:

OP_CHECKINPUTSHASHVERIFY -- allow checking that the hash of the inputs is a
particular value. The top-level of a congestion control tree can check that
the inputs match the desired inputs for that spend, and default to
requiring N of N otherwise. This is replay proof! This is useful for other
applications too.

OP_CHECKFEEVERIFY -- allowing an explicit commitment to the exact amount of
fee limits replay to txns which were funded with the exact amount of the
prior. If there's a mismatch, an alternative branch can be used. This is a
generally useful mechanism, but means that transactions using it must have
all inputs/outputs set.

Best,

Jeremy
--
@JeremyRubin <https://twitter.com/JeremyRubin>;
<https://twitter.com/JeremyRubin>;


On Fri, May 24, 2019 at 7:40 AM Johnson Lau via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> 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
> 2. ANYPREVOUT (aka NOINPUT):
> 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
>
> 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),
> 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.
> _______________________________________________
> 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/20190524/9e31d870/attachment-0001.html>;