summaryrefslogtreecommitdiff
path: root/3d/26d6e8ef176b11e1d386bdb26f8d2907487cc3
blob: b871329ac6ec898557898adf734bfc855d995d10 (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
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
Return-Path: <kkarasavvas@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id D351914EB
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 27 May 2019 07:26:34 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lj1-f174.google.com (mail-lj1-f174.google.com
	[209.85.208.174])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 24D0BA9
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 27 May 2019 07:26:34 +0000 (UTC)
Received: by mail-lj1-f174.google.com with SMTP id 188so13739383ljf.9
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 27 May 2019 00:26:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:references:in-reply-to:from:date:message-id:subject:to; 
	bh=UddGfSPsL242711cQeI15/TyDyU59R4JOjCPrdHMDpY=;
	b=q1oIJdMLEWn7YeZDSN9OA/9oJr8d4OCoAIyDdsAl9j/q2cAbYbza/Wem1YysgyOxAi
	n9X+OVGn8FLFVPPgARRTsV8Qe+6S6jDT0jzppXIghOTi2NSTIY0luUBUYjFh9DM6mb35
	nQmdlLBUMVX6zkapPwOBRWaD7kB+BRemmL5owOU1CjmWSrcD+cw8Gez49O8GWD7n++OZ
	p2Chx/SvRndCy7Q6tXOtPacHmNVmQhRavk66QtbBiUarxsa+OJNqGvDtXdHaJlWrRzEZ
	mlnWQsKWWKUUZ9DQB16S0raMxOTUBDPf4nr6Sf1afDwp/4rDdBDOG/sJbAmfIWlDsU2G
	Xl7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:references:in-reply-to:from:date
	:message-id:subject:to;
	bh=UddGfSPsL242711cQeI15/TyDyU59R4JOjCPrdHMDpY=;
	b=oZnvyiwLnbdxE3Hk89+ptst3e4oFCi3Ukb9/zke3xtdMSlQ3vnFEI1dhWCers0baIP
	obqZQ6HMkBuzMp0D4EHQ+0X4GjSX37ozhowVxSvWfWHRgkk21baX27AwFE/rDBARWoCv
	ypagZmEJWiyLDFsH2PjwAlR+wCpZ/GQCSxHtfIF6uCOBAgy255x5u5iV47SIicskzg9F
	+ew8jELm7ttgW+B048Wmrs3H1MmocH41Gm9xa5NR0PylWR1yOxtgCETeY0ppYEbEEe2C
	s/o3uqlTv2RP8f/+7bJSndbeRG6otkqXi1tDyukAb7IgMNBVVwRTOuBlVLZ+8/51Fbdg
	EaAw==
X-Gm-Message-State: APjAAAXqQ3YCb5hxwzJhGopO4m1hCW+t37Quo1s8w6iDC0Q1alQyzt/P
	XW1e8Mfl6sJy221q1MANM8YWZ9JJic6R//t9Sy8=
X-Google-Smtp-Source: APXvYqzXOAw+dHzlvthXXva9mDrXKK1si5+TImPn208rp6b9vrg2ACz1ugEr+zlW1+O98DeTW5qJVIaNdGSksLX89bI=
X-Received: by 2002:a2e:8796:: with SMTP id n22mr2225475lji.75.1558941992532; 
	Mon, 27 May 2019 00:26:32 -0700 (PDT)
MIME-Version: 1.0
References: <e537e781-e10f-7299-fddb-67fab74124c0@gmail.com>
In-Reply-To: <e537e781-e10f-7299-fddb-67fab74124c0@gmail.com>
From: Kostas Karasavvas <kkarasavvas@gmail.com>
Date: Mon, 27 May 2019 10:26:21 +0300
Message-ID: <CABE6yHsCf7Mz+wDq7wPUR3YT0ua2i4O20XjF1-GZD_zJ8BXkVQ@mail.gmail.com>
To: Aymeric Vitte <vitteaymeric@gmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000b0bd630589d9771d"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	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:29:09 +0000
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: Mon, 27 May 2019 07:26:34 -0000

--000000000000b0bd630589d9771d
Content-Type: text/plain; charset="UTF-8"

On Sun, May 26, 2019 at 5:07 PM Aymeric Vitte via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I realized recently that my segwit implementation was not correct,
> basically some time ago, wrongly reading the specs (and misleaded by
> what follows), I thought that scriptsig would go into witness data as it
> was, but that's not the case, op_pushdata is replaced by varlen
>
> Now reading correctly the specs, they seem to be not totally correct,
> then the first question is: why OP_0 is 00 in witness data and not 0100?
> Does this apply to other op_codes? This does not look logical at all
>
>
op_pushdata allows for unsigned integers and thus it uses the extra byte to
specify that.

A varint (varlen) is unsigned.  0 and anything <= 252 is one byte length,
so 00.


> The second question is: why for non segwit inputs there is a 00 length
> in segwit data, what is the rational for that? It should just be nothing
> since you don't need this to reconciliate things
>
>
Because you don't have the number of witnesses as you have for
inputs/outputs. The witness data length is assumed to be the same as the
inputs length. And then for non-segwit inputs you need the 00 to specify
that it is empty.

Hope that helps.

--000000000000b0bd630589d9771d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Sun, May 26, 2019 at 5:07 PM Aymer=
ic Vitte via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfound=
ation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft:1px solid rgb(204,204,204);padding-left:1ex">I realized recently that my=
 segwit implementation was not correct,<br>
basically some time ago, wrongly reading the specs (and misleaded by<br>
what follows), I thought that scriptsig would go into witness data as it<br=
>
was, but that&#39;s not the case, op_pushdata is replaced by varlen<br>
<br>
Now reading correctly the specs, they seem to be not totally correct,<br>
then the first question is: why OP_0 is 00 in witness data and not 0100?<br=
>
Does this apply to other op_codes? This does not look logical at all<br>
<br></blockquote><div><br></div><div>op_pushdata allows for unsigned intege=
rs and thus it uses the extra byte to specify that.</div><div><br></div><di=
v>A varint (varlen) is unsigned.=C2=A0 0 and anything &lt;=3D 252 is one by=
te length, so 00.=C2=A0</div><div>=C2=A0</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20=
4);padding-left:1ex">
The second question is: why for non segwit inputs there is a 00 length<br>
in segwit data, what is the rational for that? It should just be nothing<br=
>
since you don&#39;t need this to reconciliate things<br>
<br></blockquote><div><br></div><div>Because you don&#39;t have the number =
of witnesses as you have for inputs/outputs. The witness data length is ass=
umed to be the same as the inputs length. And then for non-segwit inputs yo=
u need the 00 to specify that it is empty.</div><div>=C2=A0</div><div></div=
></div><div dir=3D"ltr" class=3D"gmail_signature"><div dir=3D"ltr"><div><di=
v>Hope that helps.<br></div></div><div><br></div></div></div></div>

--000000000000b0bd630589d9771d--