summaryrefslogtreecommitdiff
path: root/df/6a580dacac20898b23193d4f35f130329f6f30
blob: 26aef934750c68e8bf0440997421ad1c28b4b97f (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
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
Return-Path: <shadders.del@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 8F459BAC
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 21 Nov 2017 13:10:30 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pg0-f43.google.com (mail-pg0-f43.google.com [74.125.83.43])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C952D1E1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 21 Nov 2017 13:10:29 +0000 (UTC)
Received: by mail-pg0-f43.google.com with SMTP id 4so10134639pge.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 21 Nov 2017 05:10:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to; 
	bh=a/UDVMTzmGyQGBkGJGHe+wb6iLCxCnZ5b9WhiobBEao=;
	b=ehQVSNPcGuEasZSROvLhTIWh5Sm34hmfFN2cGikRMO2yqRk3DV3V8Fxon9/z1uH5M+
	ShCFzzH4Skz55LmXzd23sHBWYedV80ce4muygql2fMxNNFpF8CMrzWh7Pu2j+KURz6Ar
	iymjZCG+N/c0soksEr0n1EfskwBB7vf35YbGZL9FXAx8sdOIut1fYmPm/3KPD4pPpiUU
	KeFGgelx9h7dhISoZlgB2MbX1dHtXXWS6Mfk5jq7pJLMTk5ZlRpYAbYa19rYC6FpQGci
	9PRWTPxA4lqk6/WwH+5NXs0oEeEgF9du6nKk9x8BlDVF/waSfij+N9iXKf1nx2y5NsyF
	WHFw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to;
	bh=a/UDVMTzmGyQGBkGJGHe+wb6iLCxCnZ5b9WhiobBEao=;
	b=L89V7O6wWTw9LWlUi4k0hveSmGRPru+UITiqqxlrUcFyTct6YZPys94MP6gzsRbEVN
	eL4jUx8p62V60DyPTxcEqZTqmAbRgXy8Q8fB/uqX4zl4xUwFYLyKJI0U6KGZQThTrCBm
	Ltc2+PVzdXB0AhpkKGfFTJV8nN79gM2N07uhTQ7JTpxHBRuDLTJSDm81PdKlBPapk4d8
	NxoIusXBbWPuIa3aT5uBVh8tcg9iSld3j3bbosvxz1VwP/X3wNRDkv4HdTamK/5TBRjF
	mHQKjnDgT+sDugOI1+obxCNX5ScjDjh7+qhUe+ZXcQHNVbx5PR8PMRnXw7bdwuTUtuFt
	BXuA==
X-Gm-Message-State: AJaThX4elrs6ateFTj3Q3/AuvrSy6d0lezR5JdF29t4lTgOwcuIxOLJV
	gcYmyid2V0K5rJFI5oRykU0jO/UU+Tg25RGLskA=
X-Google-Smtp-Source: AGs4zMZZFs1oR9IKhNkQJtMq0dlRNV9GWe46foKc0EtZ/FcffWXETIlX8rTgoXATNegN+nWCj6+Sn2EKIMWcIM+goss=
X-Received: by 10.84.137.106 with SMTP id 97mr6755342plm.429.1511269829381;
	Tue, 21 Nov 2017 05:10:29 -0800 (PST)
MIME-Version: 1.0
Received: by 10.100.135.86 with HTTP; Tue, 21 Nov 2017 05:10:28 -0800 (PST)
Received: by 10.100.135.86 with HTTP; Tue, 21 Nov 2017 05:10:28 -0800 (PST)
In-Reply-To: <CAAUFj1091C3xXL+2j1EovE2j_2kDYsjP_O4ZOKBaxmHuKN=1Lg@mail.gmail.com>
References: <CAAQs3wuDPktHc6kiZXqTaatOheX4KP=TRgje0_-ED5h8iNs-MA@mail.gmail.com>
	<F392E62C-00CF-4D91-BB6B-706F2A59C63B@xbt.hk>
	<CAAUFj10ZRQrtEzB_2wp-WS8Q-FGcSegpc_Z6kqvqnDLzNn=DrA@mail.gmail.com>
	<CAAUFj11_Vh2K4MrmuBre5KaX6F16Jg3PYAsj6SSfzoYYRz_WyA@mail.gmail.com>
	<CAAUFj1091C3xXL+2j1EovE2j_2kDYsjP_O4ZOKBaxmHuKN=1Lg@mail.gmail.com>
From: Steve Shadders <shadders.del@gmail.com>
Date: Tue, 21 Nov 2017 23:10:28 +1000
Message-ID: <CAOPxoMtPvKm0t1ih8vw5YmiGUYjR5Y5a8ZLvjaKo06mH+iHjoA@mail.gmail.com>
To: DKBryant@gmail.com, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="94eb2c13ee245711e7055e7dedde"
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: Tue, 21 Nov 2017 14:01:31 +0000
Subject: Re: [bitcoin-dev] Why SegWit Anyway?
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: Tue, 21 Nov 2017 13:10:30 -0000

--94eb2c13ee245711e7055e7dedde
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

There is incentive because of artificially distorted block weight rules. It
is favourable for a miner to choose a segwit tx over a non segwit tx as
they can fit more of them into a block and earn more fees.

On Nov 21, 2017 11:06 PM, "Dan Bryant via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Is there any incentive for miners to pick segwit transactions over
> non-segwit transaction.  Do they require less, equal, or more compute to
> process?
>
> On Nov 20, 2017 11:46 AM, "Johnson Lau via bitcoin-dev" <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> We can=E2=80=99t =E2=80=9Cjust compute the Transaction ID the same way th=
e hash for
> signing the transaction is computed=E2=80=9D because with different SIGHA=
SH flags,
> there are 6 (actually 256) ways to hash a transaction.
>
> Also, changing the definition of TxID is a hardfork change, i.e. everyone
> are required to upgrade or a chain split will happen.
>
> It is possible to use =E2=80=9Cnormalised TxID=E2=80=9D (BIP140) to fix m=
alleability
> issue. As a softfork, BIP140 doesn=E2=80=99t change the definition of TxI=
D.
> Instead, the normalised txid (i.e. txid with scriptSig removed) is used
> when making signature. Comparing with segwit (BIP141), BIP140 does not ha=
ve
> the side-effect of block size increase, and doesn=E2=80=99t provide any i=
ncentive
> to control the size of UTXO set. Also, BIP140 makes the UTXO set
> permanently bigger, as the database needs to store both txid and normalis=
ed
> txid
>
> On 21 Nov 2017, at 1:24 AM, Praveen Baratam via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Bitcoin Noob here. Please forgive my ignorance.
>
> From what I understand, in SegWit, the transaction needs to be serialized
> into a data structure that is different from the current one where
> signatures are separated from the rest of the transaction data.
>
> Why change the format at all? Why cant we just compute the Transaction ID
> the same way the hash for signing the transaction is computed?
>
> --
> Dr. Praveen Baratam
>
> about.me <http://about.me/praveen.baratam>
> _______________________________________________
>
> 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
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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

<div dir=3D"auto">There is incentive because of artificially distorted bloc=
k weight rules. It is favourable for a miner to choose a segwit tx over a n=
on segwit tx as they can fit more of them into a block and earn more fees.<=
/div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Nov 21, 2=
017 11:06 PM, &quot;Dan Bryant via bitcoin-dev&quot; &lt;<a href=3D"mailto:=
bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.or=
g</a>&gt; wrote:<br type=3D"attribution"><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v dir=3D"auto">Is there any incentive for miners to pick segwit transaction=
s over non-segwit transaction.=C2=A0 Do they require less, equal, or more c=
ompute to process?</div><div class=3D"gmail_extra"><br><div class=3D"gmail_=
quote">On Nov 20, 2017 11:46 AM, &quot;Johnson Lau via bitcoin-dev&quot; &l=
t;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank=
">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>&gt; wrote:<br type=3D"attr=
ibution"><blockquote class=3D"m_-6431831756956729977quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style=3D"word-=
wrap:break-word;line-break:after-white-space"><div>We can=E2=80=99t =E2=80=
=9Cjust compute the Transaction ID the same way the hash for signing the tr=
ansaction is computed=E2=80=9D because with different SIGHASH flags, there =
are 6 (actually 256) ways to hash a transaction.</div><div><br></div><div>A=
lso, changing the definition of TxID is a hardfork change, i.e. everyone ar=
e required to upgrade or a chain split will happen.</div><div><br></div>It =
is possible to use =E2=80=9Cnormalised TxID=E2=80=9D (BIP140) to fix mallea=
bility issue. As a softfork, BIP140 doesn=E2=80=99t change the definition o=
f TxID. Instead, the normalised txid (i.e. txid with scriptSig removed) is =
used when making signature. Comparing with segwit (BIP141), BIP140 does not=
 have the side-effect of block size increase, and doesn=E2=80=99t provide a=
ny incentive to control the size of UTXO set. Also, BIP140 makes the UTXO s=
et permanently bigger, as the database needs to store both txid and normali=
sed txid<br><div><div><br><blockquote type=3D"cite"><div class=3D"m_-643183=
1756956729977elided-text"><div>On 21 Nov 2017, at 1:24 AM, Praveen Baratam =
via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org=
" target=3D"_blank">bitcoin-dev@lists.linuxfounda<wbr>tion.org</a>&gt; wrot=
e:</div><br class=3D"m_-6431831756956729977m_-2919472362485226639Apple-inte=
rchange-newline"></div><div><div class=3D"m_-6431831756956729977elided-text=
"><div dir=3D"ltr"><div><span style=3D"font-family:Verdana,arial,sans-serif=
;font-size:14px">Bitcoin Noob here. Please forgive my ignorance.</span></di=
v><span style=3D"font-family:Verdana,arial,sans-serif;font-size:14px"><div>=
<span style=3D"font-family:Verdana,arial,sans-serif;font-size:14px"><br></s=
pan></div>From what I understand, in SegWit, the transaction needs to be se=
rialized into a data structure that is different from the current one where=
 signatures are separated from the rest of the transaction data.</span><div=
><span style=3D"font-family:Verdana,arial,sans-serif;font-size:14px"><br></=
span></div><div><span style=3D"font-family:Verdana,arial,sans-serif;font-si=
ze:14px">Why change the format at all? Why cant we just compute the Transac=
tion ID the same way the hash for signing the transaction is computed?</spa=
n><br clear=3D"all"><div><br></div>-- <br><div class=3D"m_-6431831756956729=
977m_-2919472362485226639gmail_signature"><div style=3D"color:rgb(34,34,34)=
;font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,2=
55)">Dr. Praveen Baratam</div><div style=3D"color:rgb(34,34,34);font-family=
:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)"><br></d=
iv><div style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size=
:13px;background-color:rgb(255,255,255)"><a href=3D"http://about.me/praveen=
.baratam" style=3D"color:rgb(17,85,204)" target=3D"_blank">about.me</a></di=
v></div>
</div></div></div>
______________________________<wbr>_________________<div class=3D"m_-643183=
1756956729977quoted-text"><br>bitcoin-dev mailing list<br><a href=3D"mailto=
:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists=
.linuxfoundat<wbr>ion.org</a><br><a href=3D"https://lists.linuxfoundation.o=
rg/mailman/listinfo/bitcoin-dev" target=3D"_blank">https://lists.linuxfound=
ation.<wbr>org/mailman/listinfo/bitcoin-d<wbr>ev</a><br></div></div></block=
quote></div><br></div></div><br>______________________________<wbr>________=
_________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-d<wbr>ev</a><br>
<br></blockquote></div><br></div>
<br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></blockquote></div></div>

--94eb2c13ee245711e7055e7dedde--