public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Gregory Maxwell <greg@xiph•org>
To: achow101-lists@achow101•com,
	 Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Witness serialization in PSBT non-witness UTXOs
Date: Mon, 13 Aug 2018 20:39:38 +0000	[thread overview]
Message-ID: <CAAS2fgS7umEfkE3PkJexgc_jo5bWpWkozxKW6rQTS5A-FZXt-g@mail.gmail.com> (raw)
In-Reply-To: <7A_00K2wcfdgZMimY9aZ4gUFWyVIPOVrnueAFAosM-S-gIIoHXez6v5GcC8OrfTULz0NZ6n1g3T9jfVbgBvU_jKbgmNd-zlVqQVOC00NphA=@achow101.com>

An alternative is to require reading either or but also require
writing without the witness.  It's likely that two years from now,
nothing will write the witnesses, and the requirement to support
reading them could be dropped.
On Mon, Aug 13, 2018 at 8:32 PM Achow101 via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> Hi,
>
> Since the BIP is already in proposed status, I think that we should specify the non-witness utxo to just be "witness or non-witness" serialization. This maintains compatibility with things that have already implemented but also maintains the forwards compatibility that is needed.
>
> Andrew
>
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On August 13, 2018 11:56 AM, Pieter Wuille via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> > Hello all,
> >
> > BIP174 currently specifies that non-witness UTXOs (the transactions
> > being spent by non-witness inputs) should be serialized in network
> > format.
> >
> > I believe there are two issues with this.
> >
> > 1.  Even in case the transaction whose output being spent itself has a
> >     witness, this witness is immaterial to PSBT. It's only there to be
> >     able to verify the txid commits to the output/amount being spent,
> >     which can be done without witness.
> >
> > 2.  "Network format" is a bit ambiguous. We can imagine a future
> >     softfork that introduces a new type of witness. Network format could
> >     be interpreted as including that new witness type, which is clearly
> >     unnecessary (by the above argument), and would gratuitously break
> >     compatibility with existing signers if implemented pedantically.
> >
> >     So my suggestion is to update the specification to state that
> >     non-witness UTXOs must be serialized without witness. If it's too late
> >     for that, it should instead be updated to explicitly specify with or
> >     witnout witness, but it's safe to drop the witness.
> >
> >     Opinions?
> >
> >     Cheers,
> >
> >     --
> >     Pieter
> >
> >
> > bitcoin-dev mailing list
> > bitcoin-dev@lists•linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


      reply	other threads:[~2018-08-13 20:39 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-13 18:56 Pieter Wuille
2018-08-13 20:32 ` Achow101
2018-08-13 20:39   ` Gregory Maxwell [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAAS2fgS7umEfkE3PkJexgc_jo5bWpWkozxKW6rQTS5A-FZXt-g@mail.gmail.com \
    --to=greg@xiph$(echo .)org \
    --cc=achow101-lists@achow101$(echo .)com \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox