From: Johnson Lau <jl2012@xbt•hk>
To: Jeremy <jlrubin@mit•edu>
Cc: bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Safety of committing only to transaction outputs
Date: Sat, 25 May 2019 15:53:34 +0800 [thread overview]
Message-ID: <EB79DBDB-9C29-4699-9A06-27D1A2896661@xbt.hk> (raw)
In-Reply-To: <CAD5xwhhsk_4+C3dROGhBZqjmiqmOO+hGYR9qawbJ9MDW0so4=Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1632 bytes --]
> On 25 May 2019, at 4:59 AM, Jeremy <jlrubin@mit•edu> wrote:
>
> 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.
>
The salt will be published when it is first spent. Salting won’t help if the address is reused.
> 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.
It is circular dependent: the script has to commit to the txid, and the txid is a function of script
>
> 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.
>
This restricts replayability to input with same value, but is still replay-able, just like ANYPREVOUT committing to the input value
> Best,
>
> Jeremy
> --
> @JeremyRubin <https://twitter.com/JeremyRubin> <https://twitter.com/JeremyRubin>
[-- Attachment #2: Type: text/html, Size: 4331 bytes --]
prev parent reply other threads:[~2019-05-25 7:53 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-23 20:54 Johnson Lau
2019-05-24 20:59 ` Jeremy
2019-05-25 7:53 ` Johnson Lau [this message]
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=EB79DBDB-9C29-4699-9A06-27D1A2896661@xbt.hk \
--to=jl2012@xbt$(echo .)hk \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=jlrubin@mit$(echo .)edu \
/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