Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id D7E451BB for ; Wed, 21 Oct 2015 08:50:56 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2DE2DA6 for ; Wed, 21 Oct 2015 08:50:56 +0000 (UTC) Received: by wicfv8 with SMTP id fv8so64258481wic.0 for ; Wed, 21 Oct 2015 01:50:55 -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=jZcAvp6jyrlvDFpgJvbucd0CTYj3e18185UAR9b2ifo=; b=nctUdj6vMHewKz1mA1vwP7Xkg+VYITFtHUhJA9SofrxKkdHwBddg2Z8+dnCmTEVSHp RqQsUaGTiHxGMRCJP3/nAPsaLXn0noHeYHoFM8h98f+QI//GubB7zv+AqMSbxKoaTUCm C+P7/z+fqhCffLt+qJ+OMiRewCojYwKzWO8jZ5kyvEJJD4JZuKv29P9351KtWD4EGMaT qXE9UnTw3b5S8XBqzYV+J6OBVoPQr801UG0PvVmUOPvc0R/E6gJPJQ7mu9Hm0uvrp6uJ PPUU6fGud0ekVOGC5e4GPqoYDukoYGvYXho/dgcqE+SJt6R7Nmhe8LgHN+TOk/81XIux ZZ4A== X-Received: by 10.180.88.34 with SMTP id bd2mr17243750wib.82.1445417454766; Wed, 21 Oct 2015 01:50:54 -0700 (PDT) MIME-Version: 1.0 References: <201510210618.56159.luke@dashjr.org> In-Reply-To: From: Christian Decker Date: Wed, 21 Oct 2015 08:50:45 +0000 Message-ID: To: Gregory Maxwell , Luke Dashjr Content-Type: multipart/alternative; boundary=f46d04428f24f1aef20522997952 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: Wed, 21 Oct 2015 08:50:56 -0000 --f46d04428f24f1aef20522997952 Content-Type: text/plain; charset=UTF-8 Ok, so the normalization step could add a sorting step for inputs/outputs (which is going to be nasty for SIGHASH_SINGLE), that would solve the issue. On Wed, Oct 21, 2015 at 10:49 AM Christian Decker < decker.christian@gmail.com> wrote: > On Wed, Oct 21, 2015 at 10:26 AM Gregory Maxwell > wrote: > >> On Wed, Oct 21, 2015 at 7:48 AM, Gregory Maxwell >> wrote: >> > I'm still sad that uniform segregated witeness is so hard to deploy, >> > adding another id to every utxo set won't be a nice cost. :( But I >> > have been trying for a long time to come up with anything better and >> > not being successful. >> >> Oh good. Luke solved it. >> >> To deploy SW without a disruptive flag day this encoding could be used: >> >> A new P2SH like scriptPubkey type is defined. In the soft-fork, the >> scriptsig for this scriptPubkey is required to be empty. >> >> Signatures are not covered under txid, but carried along side. Then >> committed to in blocks in a separate hashtree. >> >> > Isn't that sort of what this BIP describes as well? Except that we use the > scriptSig to transport the signatures internally to the transactions and > strip them when it comes to signing/checking? The wire format and transport > of transactions do not change so old clients continue to fetch and process > transactions as before, they just can't verify the TX. Blocks still > reference the instance but verification uses the stripped TX with the > signatures on the side, etc. > > >> The only disadvantage to the approach used in elements alpha that I >> can come up with so far (in the few minutes since luke turned my can't >> into a can) is that that the approach in EA did not disrupt the normal >> relay handling process, and this would, since relay that transports >> the extradata either needs to use a different hash that includes the >> witness, or have a separate mechanism for witness transport. >> > --f46d04428f24f1aef20522997952 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ok, so the normalization step could add a sorting step for= inputs/outputs (which is going to be nasty for SIGHASH_SINGLE), that would= solve the issue.

On W= ed, Oct 21, 2015 at 10:49 AM Christian Decker <decker.christian@gmail.com> wrote:
On Wed, Oct 21, 2015 at 10:26 AM Gregory Maxwell <gmaxwell@gmail.com>= wrote:
On Wed, Oct 21, 2015 at 7:4= 8 AM, Gregory Maxwell <gmaxwell@gmail.com> wrote:
> I'm still sad that uniform segregated witeness is so hard to deplo= y,
> adding another id to every utxo set won't be a nice cost. :( But I=
> have been trying for a long time to come up with anything better and > not being successful.

Oh good. Luke solved it.

To deploy SW without a disruptive flag day this encoding could be used:

A new P2SH like scriptPubkey type is defined. In the soft-fork, the
scriptsig for this scriptPubkey is required to be empty.

Signatures are not covered under txid, but carried along side. Then
committed to in blocks in a separate hashtree.


Isn't that sort of what this BIP describes as well? E= xcept that we use the scriptSig to transport the signatures internally to t= he transactions and strip them when it comes to signing/checking? The wire = format and transport of transactions do not change so old clients continue = to fetch and process transactions as before, they just can't verify the= TX. Blocks still reference the instance but verification uses the stripped= TX with the signatures on the side, etc.
=C2=A0
The only disadvantage to the approach used in elements alpha that I
can come up with so far (in the few minutes since luke turned my can't<= br> into a can) is that that the approach in EA did not disrupt the normal
relay handling process, and this would, since relay that transports
the extradata either needs to use a different hash that includes the
witness, or have a separate mechanism for witness transport.
--f46d04428f24f1aef20522997952--