diff options
| author | ZmnSCPxj <ZmnSCPxj@protonmail.com> | 2019-07-19 18:07:56 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2019-07-19 18:08:09 +0000 |
| commit | 31edf6171baaec31cea76012773909247f29f27d (patch) | |
| tree | 4eb8c13e11c7fac0f453d8438397b890f3e69e67 | |
| parent | 16ff6716a932a224716a31ea02ac366b3b50f98d (diff) | |
| download | pi-bitcoindev-31edf6171baaec31cea76012773909247f29f27d.tar.gz pi-bitcoindev-31edf6171baaec31cea76012773909247f29f27d.zip | |
Re: [bitcoin-dev] PubRef - Script OP Code For Public Data References
| -rw-r--r-- | 93/058fd620017284a62dc5638ea8b67f89e0b287 | 105 |
1 files changed, 105 insertions, 0 deletions
diff --git a/93/058fd620017284a62dc5638ea8b67f89e0b287 b/93/058fd620017284a62dc5638ea8b67f89e0b287 new file mode 100644 index 000000000..9c040e49d --- /dev/null +++ b/93/058fd620017284a62dc5638ea8b67f89e0b287 @@ -0,0 +1,105 @@ +Return-Path: <ZmnSCPxj@protonmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 1F0C1212C + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 19 Jul 2019 18:08:09 +0000 (UTC) +X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 +Received: from mail-40136.protonmail.ch (mail-40136.protonmail.ch + [185.70.40.136]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 618D18EC + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 19 Jul 2019 18:08:08 +0000 (UTC) +Date: Fri, 19 Jul 2019 18:07:56 +0000 +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; + s=default; t=1563559685; + bh=CULi5w1OLOPMmnUiAU1p2iqNhpt7V/7vnna+2Pv9Ckc=; + h=Date:To:From:Reply-To:Subject:In-Reply-To:References:Feedback-ID: + From; + b=Yix+VMS9vnC8YWFAE8ZEUxRfV8zGO9JnvJcXFUXkkDyORtLDOmV6XO2v0q9po113L + iP1Zu4/AHyA+a0TScATy7+TTUZKhPRs3wf56s6GENbbUvXTSE+f45/pRv8T1t6Lcaw + V6Asr66Hd0ji+ocDcv+JCKJLX5ll2ujTI/VSXeTI= +To: Mike Brooks <m@ib.tc>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +From: ZmnSCPxj <ZmnSCPxj@protonmail.com> +Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com> +Message-ID: <nk8ihWbf71QT6w-wVbnunppF_DjS8ywDoDAugBj5mYM_LCpSzec0j6lkaTKBK4t3CsXwRSXWmzbWiW7nmqT4y0W2fn8X-3oXv-TAYXwP1R4=@protonmail.com> +In-Reply-To: <CALFqKjQkQwuxjeYkGWO_Y_HhNQmJgrjqF3m04hbORV7FSbsi3Q@mail.gmail.com> +References: <CALFqKjQkQwuxjeYkGWO_Y_HhNQmJgrjqF3m04hbORV7FSbsi3Q@mail.gmail.com> +Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable +X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, + DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL, + RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 +X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on + smtp1.linux-foundation.org +X-Mailman-Approved-At: Fri, 19 Jul 2019 19:12:38 +0000 +Subject: Re: [bitcoin-dev] PubRef - Script OP Code For Public Data References +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: Fri, 19 Jul 2019 18:08:09 -0000 + +Good morning Mike, + +> PubRef is not susceptible to malleability attacks because the blockchain = +is immutable. + +This is not quite accurate. +While very old blocks are indeed immutable-in-practice, chain tips are not,= + and are often replaced. +At least specify that such data can only be referred to if buried under 100= + blocks. + +-- + +There are a number of other issues: + +* It strongly encourages pubkey reuse, reducing privacy. +* There is a design-decision wherein a SCRIPT can only access data in the t= +ransaction that triggers its execution. + In particular, it cannot access data in the block the transaction is in, = +or in past blocks. + For example, `OP_CHECKLOCKTIMEVERIFY` does not check the blockheight of t= +he block that the transaction is confirmed in, but instead checks only `nLo= +ckTime`, a field in the transaction. + * This lets us run SCRIPT in isolation on a transaction, exactly one time= +, when the transaction is about to be put into our mempool. + When a new block arrives, transactions in our mempool that are in the b= +lock do not need to have their SCRIPTs re-executed or re-validated. + +> In order for a client to make use of the PUBREF operations they=E2=80= +=99ll need access to a database that look up public-keys and resolve their = +PUBREF index.=C2=A0 A value can be resolved to an index with a hash-table l= +ookup in O(1) constant time. Additionally, all instances of PUSHDATA can be= + indexed as an ordered list, resolution of a PUBREF index to the intended v= +alue would be an O(1) array lookup.=C2=A0 Although the data needed to build= + and resolve public references is already included with every full node, ad= +ditional computational effort is needed to build and maintain these indices= + - a tradeoff which provides smaller transaction sizes and relieving the ne= +ed to store repetitive data on the blockchain. + +This is not only necessary at the creator of the transaction --- it is also= + necessary at every validator. + +In particular, consider existing pruning nodes, which cannot refer to previ= +ous block data. + +We would need to have another new database containing every `PUSHDATA` in e= +xistence. +And existing pruning nodes would need to restart from genesis, as this data= +base would not exist yet. + +Regards, +ZmnSCPxj + |