diff options
| author | Johnson Lau <jl2012@xbt.hk> | 2017-09-21 16:02:42 +0800 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2017-09-21 08:02:56 +0000 |
| commit | 80a1a96b79c2ca51f89aa299809a25f38a5f6bc4 (patch) | |
| tree | 15f76a3ceb5317e655565fa028332a01361eef03 | |
| parent | 9e94dbcacca3118cb9de60b659367b3e7c3522bf (diff) | |
| download | pi-bitcoindev-80a1a96b79c2ca51f89aa299809a25f38a5f6bc4.tar.gz pi-bitcoindev-80a1a96b79c2ca51f89aa299809a25f38a5f6bc4.zip | |
Re: [bitcoin-dev] cleanstack alt stack & softfork improvements (Was: Merkle branch verification & tail-call semantics for generalized MAST)
| -rw-r--r-- | 9f/10ad24fea948661191bc39312c993018a53591 | 120 |
1 files changed, 120 insertions, 0 deletions
diff --git a/9f/10ad24fea948661191bc39312c993018a53591 b/9f/10ad24fea948661191bc39312c993018a53591 new file mode 100644 index 000000000..676377d00 --- /dev/null +++ b/9f/10ad24fea948661191bc39312c993018a53591 @@ -0,0 +1,120 @@ +Return-Path: <jl2012@xbt.hk> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id D974A8E2 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 21 Sep 2017 08:02:56 +0000 (UTC) +X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 +Received: from sender-of-o52.zoho.com (sender-of-o52.zoho.com [135.84.80.217]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2DD35163 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 21 Sep 2017 08:02:55 +0000 (UTC) +Received: from [10.7.45.226] (ip-123-255-103-86.wlan.cuhk.edu.hk + [123.255.103.86]) by mx.zohomail.com + with SMTPS id 1505980971508787.250021505688; + Thu, 21 Sep 2017 01:02:51 -0700 (PDT) +Content-Type: text/plain; charset=utf-8 +Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) +From: Johnson Lau <jl2012@xbt.hk> +In-Reply-To: <201709210411.50642.luke@dashjr.org> +Date: Thu, 21 Sep 2017 16:02:42 +0800 +Content-Transfer-Encoding: quoted-printable +Message-Id: <21D6060D-97F0-439A-86D3-065C21BACC3F@xbt.hk> +References: <5B6756D0-6BEF-4A01-BDB8-52C646916E29@friedenbach.org> + <201709190309.08669.luke@dashjr.org> + <B8C5E7EF-9062-4431-9B63-06FF855B1D78@xbt.hk> + <201709210411.50642.luke@dashjr.org> +To: Luke Dashjr <luke@dashjr.org> +X-Mailer: Apple Mail (2.3273) +X-ZohoMailClient: External +X-Spam-Status: No, score=0.0 required=5.0 tests=RCVD_IN_DNSWL_NONE + autolearn=disabled version=3.3.1 +X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on + smtp1.linux-foundation.org +Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> +Subject: Re: [bitcoin-dev] cleanstack alt stack & softfork improvements + (Was: Merkle branch verification & tail-call semantics for generalized + MAST) +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.12 +Precedence: list +List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Thu, 21 Sep 2017 08:02:57 -0000 + + +> On 21 Sep 2017, at 12:11 PM, Luke Dashjr <luke@dashjr.org> wrote: +>=20 +> On Wednesday 20 September 2017 5:13:04 AM Johnson Lau wrote: +>> 2. OP_RETURNTRUE does not work well with signature aggregation. = +Signature +>> aggregation will collect (pubkey, message) pairs in a tx, combine = +them, +>> and verify with one signature. However, consider the following case: +>>=20 +>> OP_RETURNTRUE OP_IF <pubkey> OP_CHECKSIGVERIFY OP_ENDIF OP_TRUE +>>=20 +>> For old nodes, the script terminates at OP_RETURNTRUE, and it will = +not +>> collect the (pubkey, message) pair. +>>=20 +>> If we use a softfork to transform OP_RETURNTRUE into OP_17 (pushing = +the +>> number 17 to the stack), new nodes will collect the (pubkey, message) = +pair +>> and try to aggregate with other pairs. This becomes a hardfork. +>=20 +> This seems like a problem for signature aggregation to address, not a = +problem=20 +> for OP_RETURNTRUE... In any case, I don't think it's insurmountable. = +Signature=20 +> aggregation can simply be setup upfront, and have the Script verify = +inclusion=20 +> of keys in the aggregation? + +I think it=E2=80=99s possible only if you spend more witness space to = +store the (pubkey, message) pairs, so that old clients could understand = +the aggregation produced by new clients. But this completely defeats the = +purpose of doing aggregation. + +We use different skills to save space. For example, we use 1-byte = +SIGHASH flag to imply the 32-byte message. For maximal space saving, sig = +aggregation will also rely on such skills. However, the assumption is = +that all signatures aggregated must follow exactly the same set of = +rules. + + +>=20 +>> Technically, we could create ANY op code with an OP_NOP. For example, = +if we +>> want OP_MUL, we could have OP_MULVERIFY, which verifies if the 3rd = +stack +>> item is the product of the top 2 stack items. Therefore, OP_MULVERIFY +>> OP_2DROP is functionally same as OP_MUL, which removes the top 2 = +items and +>> returns the product. The problem is it takes more witness space. +>=20 +> This is another approach, and one that seems like a good idea in = +general. I'm=20 +> not sure it actually needs to take more witness space - in theory, = +such stack=20 +> items could be implied if the Script engine is designed for it = +upfront. Then=20 +> it would behave as if it were non-verify, while retaining backward=20 +> compatibility. + +Sounds interesting but I don=E2=80=99t get it. For example, how could = +you make a OP_MUL out of OP_NOP? + + +>=20 +> Luke + + + |