From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Luke Dashjr <luke@dashjr•org>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Cc: Pieter Wuille <pieter.wuille@gmail•com>
Subject: Re: [bitcoin-dev] Taproot proposal
Date: Wed, 08 May 2019 03:44:29 +0000 [thread overview]
Message-ID: <sujR-1TPC3DI-bNyQD2U5c5E0qkkfi6WezKQOfB9YgP7UbLj3x-maV0ooIqvJ4C2V_yjkrq78F7QqIZ5LyoZuSKcpC08RFWapH2k-FF3_zc=@protonmail.com> (raw)
In-Reply-To: <201905062017.11396.luke@dashjr.org>
Good morning Luke,
> Is there any way to use the Taproot construct here while retaining external
> script limitations that the involved party(ies) cannot agree to override?
> For example, it is conceivable that one might wish to have an unconditional
> CLTV enforced in all circumstances.
Perhaps this can be enforced offchain, by participants refusing to sign a transaction unless it has an `nLockTime` of the agreed-upon "unconditional CLTV".
Then the CLTV need only be on branches which have a strict subset of the participants as signers.
>
> It may be useful to have a way to add a salt to tap branches.
Would not adding `OP_PUSH(<salt>) OP_DROP` to the leaves work?
If you enforce always salting with a 32-byte salt, that "only" saves 3 bytes of witness data (for the `OP_PUSHDATA1+size` and `OP_DROP` opcodes).
Or do you refer to always salting every node?
(I am uncertain, but would not adding a salt to every leaf be sufficient?)
(in any case, if you use different pubkeys for each contract, rather than reusing keys, is that not enough randomization to prevent creating rainbow tables of scripts?)
>
> Some way to sign an additional script (not committed to by the witness
> program) seems like it could be a trivial addition.
It seems to me the annex can be used for this, by having it contain both the script and the signature somehow concatenated.
Regards,
ZmnSCPxj
next prev parent reply other threads:[~2019-05-08 3:44 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-06 17:57 Pieter Wuille
2019-05-06 20:17 ` Luke Dashjr
2019-05-07 20:42 ` Sjors Provoost
2019-05-08 4:37 ` ZmnSCPxj
2019-05-08 5:16 ` ZmnSCPxj
2019-05-08 23:06 ` Pieter Wuille
2019-05-18 17:51 ` ZmnSCPxj
2019-05-08 3:44 ` ZmnSCPxj [this message]
2019-05-09 16:56 ` Johnson Lau
2019-05-10 5:38 ` ZmnSCPxj
2019-05-08 4:49 ` Anthony Towns
2019-05-08 13:10 ` Luke Dashjr
2019-05-21 17:20 ` Russell O'Connor
2019-05-23 2:06 ` Pieter Wuille
2019-05-23 2:32 ` Russell O'Connor
2019-05-22 14:14 ` John Newbery
2019-09-16 16:18 ` Greg Sanders
2019-09-17 4:09 ` ZmnSCPxj
2019-09-18 21:21 ` Pieter Wuille
2019-06-27 0:08 ` Russell O'Connor
2019-06-28 9:49 ` Anthony Towns
2019-06-28 11:16 ` Russell O'Connor
2019-08-09 14:58 Elichai Turkel
2019-08-09 18:29 ` Pieter Wuille
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='sujR-1TPC3DI-bNyQD2U5c5E0qkkfi6WezKQOfB9YgP7UbLj3x-maV0ooIqvJ4C2V_yjkrq78F7QqIZ5LyoZuSKcpC08RFWapH2k-FF3_zc=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=luke@dashjr$(echo .)org \
--cc=pieter.wuille@gmail$(echo .)com \
/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