summaryrefslogtreecommitdiff
path: root/5c/a2bcdc97c238bc4925c6157fce5bb04c1c8ff5
blob: 84aa2a83489d04bd22929508e5b7d3d8ffeeb9d2 (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
Return-Path: <mark@friedenbach.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id E87D6C5F
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue,  8 Dec 2015 17:41:43 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f177.google.com (mail-ig0-f177.google.com
	[209.85.213.177])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 40B7118D
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue,  8 Dec 2015 17:41:43 +0000 (UTC)
Received: by igl9 with SMTP id 9so100883149igl.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 08 Dec 2015 09:41:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=friedenbach-org.20150623.gappssmtp.com; s=20150623;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=nM1oEQZhc7RokrCav1MEjsxEq11rbJdvLSgELJmtqCM=;
	b=gVijGovZiI/OlbxnYI/NFQo3XmKUJ5E5SnAjgsT4R0TdOX159i9wZdWbY3FwDREn2m
	lNbsPYKK3PqSkC8hzF2/MY/EeWbKkLks0xVK6ArdD/q3wKEsuQMJ9zDFZWkuDztk2v2h
	Vx1rpVt79TxKXddb8NKgnsb0jnxhuBMd1k328CZI0q2aimySzEV50b9mbG/scuhC7Yzn
	2sHCxgVD59+NuumWvYFDpB54eJVHta8R0vlOKp1GmQeNfAuueTc75WZcntpk6jn8SzeB
	Zn9zGZY9UPX9OVKT0th/O+Nu92MnhE94y344KZoSYgsaCRb3G2DjRxfYtpAudRh6ozlk
	1Dbg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type;
	bh=nM1oEQZhc7RokrCav1MEjsxEq11rbJdvLSgELJmtqCM=;
	b=PM0IWMb6HXDBjA5McHp1Q0LmftPEki9FGduIVmktRyXWyVs4x4x+eep06ecSVxlJ0s
	4zuwnuvVxIKET/OPxHoGy/xLQX49sAxGs0Q/cJANPdRa4aWID9gJwI9Vn4MkvvJZ3QI7
	vlOATGNNglH4tzyBLtDlC1ggzwrFBXxcRWGV+ZtqlmoRtUymf2uH6rg24bVgCLJtk+fA
	ipKn8UBIR6Uic81zSUMlON+BeRi6A9B7FD5al53CxFn5xsdvWHXi3sH4XU7xfd3esb7e
	wdSs0j9BdXdsZ9oqnc17JkoVnfn8xDKwH31PF3Evnj7AzCUk1sZcCiFGeqi3NEJE5zOy
	skqg==
X-Gm-Message-State: ALoCoQknnpjqt1egNIY7KsTk6N2v2yzEFx1btg6BejoOx1AYlKVRXbilkzYRZD/wP2IU1ZC0OpggjBC7jFjkbnMdvESrAATmSg==
X-Received: by 10.50.66.144 with SMTP id f16mr21523988igt.22.1449596502686;
	Tue, 08 Dec 2015 09:41:42 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.133.217 with HTTP; Tue, 8 Dec 2015 09:41:23 -0800 (PST)
X-Originating-IP: [45.64.240.209]
In-Reply-To: <5666FD8D.8050201@openbitcoinprivacyproject.org>
References: <CAAS2fgQyVs1fAEj+vqp8E2=FRnqsgs7VUKqALNBHNxRMDsHdVg@mail.gmail.com>
	<20151208110752.GA31180@amethyst.visucore.com>
	<CABm2gDpcek=u=Rpe68EMOq6M7Bji9J=s5VvoQWKRqaQDAP5kTw@mail.gmail.com>
	<CABsx9T1wga3Tandoe2mVGSKdHJytHoc9Ko7HRm2SvJXABEFk9w@mail.gmail.com>
	<5666FD8D.8050201@openbitcoinprivacyproject.org>
From: Mark Friedenbach <mark@friedenbach.org>
Date: Wed, 9 Dec 2015 01:41:23 +0800
Message-ID: <CAOG=w-vW36Q5_NMqzZsBgc-p7QEDEYp9OtLkg5tzbAN0YRXFUA@mail.gmail.com>
To: Justus Ranvier <justus@openbitcoinprivacyproject.org>
Content-Type: multipart/alternative; boundary=047d7bdc9dae9c561d0526667c0d
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Capacity increases for the Bitcoin system.
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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, 08 Dec 2015 17:41:44 -0000

--047d7bdc9dae9c561d0526667c0d
Content-Type: text/plain; charset=UTF-8

A far better place than the generation transaction (which I assume means
coinbase transaction?) is the last transaction in the block. That allows
you to save, on average, half of the hashes in the Merkle tree.

On Tue, Dec 8, 2015 at 11:55 PM, Justus Ranvier via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On 12/08/2015 09:12 AM, Gavin Andresen via bitcoin-dev wrote:
> > Stuffing the segwitness merkle tree in the coinbase
>
> If such a change is going to be deployed via a soft fork instead of a
> hard fork, then the coinbase is the worst place to put the segwitness
> merkle root.
>
> Instead, put it in the first output of the generation transaction as an
> OP_RETURN script.
>
> This is a better pattern because coinbase space is limited while output
> space is not. The next time there's a good reason to tie another merkle
> tree to a block, that proposal can be designated for the second output
> of the generation transaction.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

--047d7bdc9dae9c561d0526667c0d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">A far better place than the generation transaction (which =
I assume means coinbase transaction?) is the last transaction in the block.=
 That allows you to save, on average, half of the hashes in the Merkle tree=
.<br></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue=
, Dec 8, 2015 at 11:55 PM, Justus Ranvier via bitcoin-dev <span dir=3D"ltr"=
>&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><span class=3D"">On 12/08/2015 09:12 AM, Gavin Andr=
esen via bitcoin-dev wrote:<br>
&gt; Stuffing the segwitness merkle tree in the coinbase<br>
<br>
</span>If such a change is going to be deployed via a soft fork instead of =
a<br>
hard fork, then the coinbase is the worst place to put the segwitness<br>
merkle root.<br>
<br>
Instead, put it in the first output of the generation transaction as an<br>
OP_RETURN script.<br>
<br>
This is a better pattern because coinbase space is limited while output<br>
space is not. The next time there&#39;s a good reason to tie another merkle=
<br>
tree to a block, that proposal can be designated for the second output<br>
of the generation transaction.<br>
<br>
<br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></blockquote></div><br></div>

--047d7bdc9dae9c561d0526667c0d--