Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Johnson Lau <jl2012@xbt.hk>
In-Reply-To: <e342cb8f-a909-a806-bd76-91580234cd7f@gmail.com>
Date: Mon, 27 May 2019 00:28:57 +0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <253DB697-BECF-4D68-8A1E-1549B52D5AFA@xbt.hk>
References: <e537e781-e10f-7299-fddb-67fab74124c0@gmail.com>
	<6DFB6C65-D123-40FD-9CE3-49FFCA81EE46@xbt.hk>
	<e342cb8f-a909-a806-bd76-91580234cd7f@gmail.com>
To: Aymeric Vitte <vitteaymeric@gmail.com>
Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Two questions about segwit implementation
Precedence: list

This is not how it works. While the transaction creator may know which =
inputs are segwit, the validators have no way to tell until they look up =
the UTXO set.

In a transaction, all information about an input the validators have is =
the 36-byte outpoint (txid + index). Just by looking at the outpoint, =
there is no way to tell whether it is segwit-enabled or not. So there =
needs to be a way to tell the validator that =E2=80=9Cthe witness for =
this input is empty=E2=80=9D, and it is the =E2=80=9C00=E2=80=9D.

> On 27 May 2019, at 12:18 AM, Aymeric Vitte <vitteaymeric@gmail.com> =
wrote:
>=20
> =E2=80=A6=E2=80=A6. for the 00 number of witness
> data for non segwit inputs the one that is doing the transaction knows
> which inputs are segwit or not, then parsing the transaction you can
> associate the correct input to the correct witness data, without the
> need of 00, so I must be missing the use case