Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 1F0C1212C for ; 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 ; 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 , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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