summaryrefslogtreecommitdiff
path: root/db/d0eef365893dcb56d941586c7929a17187f92d
blob: 3f0af6e36e92cb4b7356c1a2fe72890678d7b6a2 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
Return-Path: <jl2012@xbt.hk>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 25BAE1415
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 26 May 2019 17:24:21 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from sender-of-o53.zoho.com (sender-of-o53.zoho.com [135.84.80.218])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 96207878
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 26 May 2019 17:24:20 +0000 (UTC)
ARC-Seal: i=1; a=rsa-sha256; t=1558891459; cv=none; d=zoho.com; s=zohoarc; 
	b=mK7xMx6foHThDaCZVCWKSUN1Q6HNofirNTtxs3EHDw+KbVwlY+mRWDlqgiuMG7zpi5YjGE1E/Fp4IMSYe44sPvToG+endLqWlP9Epe5IsyoEPowi5avCpk7uXMYM9XLLMncBI7DT0Ws13C9Rcq80TFd+50dFdQdLmMbd0Ph6xRc=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com;
	s=zohoarc; t=1558891459;
	h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To:ARC-Authentication-Results;
	bh=3lbw1j4LLv1lfqn7kQ6RQ3Xx5u2x9MMIzab/OxGt8Gc=; 
	b=oThq4+JyNRxS8J2QdEaHO6JAN/Wkj8uiLHhX/hurFXefGhAgGYsmeOMq/YzQb9EY4X6R60q3qpq9TH/RQRc4HJXUFJLE/e7o7t2t8XA3Gov5zpRBFSEq+Pmg3oMH5XGIcXthN2lP8JSydc02nj6T5LO9zdphJaD60T2bELcBgnc=
ARC-Authentication-Results: i=1; mx.zoho.com; dkim=pass  header.i=xbt.hk;
	spf=pass  smtp.mailfrom=jl2012@xbt.hk;
	dmarc=pass header.from=<jl2012@xbt.hk> header.from=<jl2012@xbt.hk>
Received: from [192.168.1.2] (1-64-133-115.static.netvigator.com
	[1.64.133.115]) by mx.zohomail.com
	with SMTPS id 155889145718745.73247323521434;
	Sun, 26 May 2019 10:24:17 -0700 (PDT)
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: <a7742e04-22b1-2015-440a-ef81b5fbeed4@gmail.com>
Date: Mon, 27 May 2019 01:24:13 +0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <DD2C67C8-0DF6-4140-8427-19B7F28FA22C@xbt.hk>
References: <e537e781-e10f-7299-fddb-67fab74124c0@gmail.com>
	<6DFB6C65-D123-40FD-9CE3-49FFCA81EE46@xbt.hk>
	<e342cb8f-a909-a806-bd76-91580234cd7f@gmail.com>
	<253DB697-BECF-4D68-8A1E-1549B52D5AFA@xbt.hk>
	<a7742e04-22b1-2015-440a-ef81b5fbeed4@gmail.com>
To: Aymeric Vitte <vitteaymeric@gmail.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-ZohoMailClient: External
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE
	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: Mon, 27 May 2019 14:27:47 +0000
Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Two questions about segwit implementation
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sun, 26 May 2019 17:24:21 -0000

Empty scriptSig doesn=E2=80=99t imply segwit input: if the previous =
scriptPubKey is OP_1 (which does not allow witness), it could still be =
spent with an empty scriptSig

Similarly, a scriptSig looking like a spend of P2SH-segwit doesn=E2=80=99t=
 imply segwit input: if the previous scriptPubKey is empty, it could be =
spent with a push of any non-zero value.

> On 27 May 2019, at 1:09 AM, Aymeric Vitte <vitteaymeric@gmail.com> =
wrote:
>=20
> I did not phrase correctly in fact, what I meant is: if the validator
> sees empty or witness script in scriptSig, then this is a segwit =
input,
> and doing this one by one the validator can associate the correct =
segwit
> data to the correct segwit input, so 00 does not look to be needed
>=20
> Le 26/05/2019 =C3=A0 18:28, Johnson Lau a =C3=A9crit :
>> 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.
>>=20
>> 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.
>>=20
>>> 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
>>=20