Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id ED9733EE for ; Thu, 22 Oct 2015 11:54:28 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 37A8AA9 for ; Thu, 22 Oct 2015 11:54:28 +0000 (UTC) Received: by wijp11 with SMTP id p11so28100340wij.0 for ; Thu, 22 Oct 2015 04:54:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=YVW3ggXwGNi73WJZBQaYmpzCBkC1KmX6j8zjNlW1Ta8=; b=q9+7dba+KpMX0lfrtv8e2ieBBjQ4J5+ZJVgmCSCvmgK4bF5Itr3xCUurU+G/Ztn5NM 072nX0WRAFACkjpCckS57yWLVI1V67yigmCa+qJkhJY8I3hReC0LttGmkfUa1Zwh8Hj5 MOWTSLRL45ZiZsxyKtPyr+2mID4BTYRgbCWYJJ1I70pU9nIpu0lsX+PdNMXGQ0EagRzr 7BXiz9HwyzxN5ZslHZ6CUNeg3WuS9aM+/LoObBHqnBM1FNGyiiwQCSk3EzGzeLWh/2gZ RgYHwR7pZ2hwSRsu4eiOOhsQWGrfl1rvTPrMDTqvXjYuwk/WIqmjsg2fBruqmOthvr1L LEdw== X-Received: by 10.194.11.71 with SMTP id o7mr16920452wjb.75.1445514866733; Thu, 22 Oct 2015 04:54:26 -0700 (PDT) MIME-Version: 1.0 References: <201510210846.43988.luke@dashjr.org> <201510212320.31052.luke@dashjr.org> In-Reply-To: From: Christian Decker Date: Thu, 22 Oct 2015 11:54:17 +0000 Message-ID: To: Gregory Maxwell Content-Type: multipart/alternative; boundary=047d7b4508de264bbc0522b0288e X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,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 Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] [BIP] Normalized transaction IDs X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2015 11:54:29 -0000 --047d7b4508de264bbc0522b0288e Content-Type: text/plain; charset=UTF-8 Indeed the reason I got started with all of this is the use of normalized transaction IDs within smart contracts with multiple signers. Sorry if I was perceived as overselling it :-) So to summarize the discussions that have been on-going here as well as in the PR so far, most people seem to agree that the BIP is an improvement for smart-contracts as well as the third-party modification scenario. It comes at the cost of increased UTXO size due to the additional hash being stored per transaction with unclaimed outputs and some additional computations. The additional computation is for the normalized ID computation and the swapping in of normalized IDs during verification. No additional coin lookups are needed as they are retrieved and cached anyway when verifying the transaction. Would everybody agree with this assessment so far? On the PR there were some additional suggestions of treating singlesig transactions as 1-of-1 transactions and using Schnorr signatures for the new opcode. Schnorr has been in the works for a long time and gives a multitude of advantages, e.g., batch validation, and seems like a good addition. Since the verify flag is mandatory due to the soft-fork migration and we might merge singlesig and multisig into a single opcode we can replace the bitmap of flags with a simple version number. Clients would fall back to OP_NOP behaviour for versions they do not implement, maintaining soft-fork semantics to build more future signing and verification methods. On Thu, Oct 22, 2015 at 10:57 AM Gregory Maxwell wrote: > On Thu, Oct 22, 2015 at 8:26 AM, Christian Decker via bitcoin-dev > wrote: > > Normalized transaction IDs do help in the case that the single signer > wants > > to immediately follow up its transaction with another transaction > spending > > the first one's change output, and it prevents any modification in the > > multi-signer scenario. > > For ordinary transactions which are not performing interesting smart > contracts that particular is better addressed via canonical encoding, > which is immediately available and doesn't have the associated costs > (new pubkey type adoption, 20%-30% UTXO size increase, need for nodes > to fixup txid references, etc.). > > Please, as I said up-thread: this is good and importantstuff to work > on, but it shouldn't be oversold. > --047d7b4508de264bbc0522b0288e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Indeed the reason I got started with all of this is the us= e of normalized transaction IDs within smart contracts with multiple signer= s. Sorry if I was perceived as overselling it :-)

So to = summarize the discussions that have been on-going here as well as in the PR= so far, most people seem to agree that the BIP is an improvement for smart= -contracts as well as the third-party modification scenario. It comes at th= e cost of increased UTXO size due to the additional hash being stored per t= ransaction with unclaimed outputs and some additional computations. The add= itional computation is for the normalized ID computation and the swapping i= n of normalized IDs during verification. No additional coin lookups are nee= ded as they are retrieved and cached anyway when verifying the transaction.= Would everybody agree with this assessment so far?

On the PR there were some additional suggestions of treating singlesig tr= ansactions as 1-of-1 transactions and using Schnorr signatures for the new = opcode. Schnorr has been in the works for a long time and gives a multitude= of advantages, e.g., batch validation, and seems like a good addition. Sin= ce the verify flag is mandatory due to the soft-fork migration and we might= merge singlesig and multisig into a single opcode we can replace the bitma= p of flags with a simple version number. Clients would fall back to OP_NOP = behaviour for versions they do not implement, maintaining soft-fork semanti= cs to build more future signing and verification methods.

On Thu, Oct 22, 2015 at 10:57 AM G= regory Maxwell <gmaxwell@gmail.com= > wrote:
On Thu, Oct 22, 201= 5 at 8:26 AM, Christian Decker via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> Normalized transaction IDs do help in the case that the single signer = wants
> to immediately follow up its transaction with another transaction spen= ding
> the first one's change output, and it prevents any modification in= the
> multi-signer scenario.

For ordinary transactions which are not performing interesting smart
contracts that particular is better addressed via canonical encoding,
which is immediately available and doesn't have the associated costs (new pubkey type adoption, 20%-30% UTXO size increase, need for nodes
to fixup txid references, etc.).

Please, as I said up-thread: this is good and importantstuff to work
on, but it shouldn't be oversold.
--047d7b4508de264bbc0522b0288e--