summaryrefslogtreecommitdiff
path: root/4a/b7880df5c8b87e0ac10390ae9a010e00a6c3f7
blob: 4170762ba345e3ae517486105a309f9e7df12929 (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
Return-Path: <jtimon@jtimon.cc>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 1584EDCD
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed,  9 Dec 2015 11:08:20 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f46.google.com (mail-vk0-f46.google.com
	[209.85.213.46])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 64F97133
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed,  9 Dec 2015 11:08:16 +0000 (UTC)
Received: by vkha189 with SMTP id a189so41447013vkh.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 09 Dec 2015 03:08:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=jtimon-cc.20150623.gappssmtp.com; s=20150623;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=yFs0JIhFskss2F33lj+1PcjEpElCgBMpYs+zJ6sfmT4=;
	b=Rbv7dP8i4YaRk+EX+pOxpWhE/1/SU3KvnnYt9odPLROqJVx9i0tNbXx3lAuK//UfBr
	4krnj3MB1MmpvV30tOEXrgIYQTgvvcqeyfIAKB0EisDlXrPYUbjmTgDHu9m/BWRsbF76
	GnCMnqoEBYhwF4CHmiEVGepUUSxPmsk91ajdLOCieIJqXfHCuW7+OWVyURfnG/MKT80T
	ZtcBHqyN1gpC/vDFSUaVtkShqZE6wZMwCwX1tQpflK0ya1CAml1UkE1jnVRPcBVXrTxp
	Wr9JuXfW0x/dGdvGnmo0sDZBNcHCnk6wppv5BhJYrX6QtBXM8U/qjTaPQH1XfvAG7JpR
	mLKQ==
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:date
	:message-id:subject:from:to:cc:content-type;
	bh=yFs0JIhFskss2F33lj+1PcjEpElCgBMpYs+zJ6sfmT4=;
	b=G5dDHW+1amTyrcdxh7vBWvmxpk2MjGCFtYcV6rR0tjT+H3egkXXzLBt4msn5a+Pld5
	hP7ak1XYlQO+bSzh586BIUc9XWKbu56cUy21GFZZo2ZU+R2tMV/cRZYWVyX4WlUlovGv
	JlKfdt0mv4hRr7o1pchHPNjXSsqD+zpOFtdysdztG2zvMTd7I6hO6dT+A83llvEqNxqw
	ahc4CoXnPFo9L0cKXePsZlRtB0m8OfL6LLcWAZ0djNgDmNHKLximoKCM/PnqI1j7VOfl
	HuL1tcX57C8kHNgFG9b8AV9up5tOq1wuGlHvztD+gepHbuV4SESC7smLKit2jDQpAwBQ
	0Teg==
X-Gm-Message-State: ALoCoQnQxxRcggZrt01x7wgbdstlYNFra+KPiym5hhxumJ2w6xaBCBlG0b0tebLkCOWk3503VIk5hDmGxZ0Xnuua1bTTuYo/bQ==
MIME-Version: 1.0
X-Received: by 10.31.169.137 with SMTP id s131mr4147119vke.144.1449659295532; 
	Wed, 09 Dec 2015 03:08:15 -0800 (PST)
Received: by 10.31.236.70 with HTTP; Wed, 9 Dec 2015 03:08:14 -0800 (PST)
Received: by 10.31.236.70 with HTTP; Wed, 9 Dec 2015 03:08:14 -0800 (PST)
In-Reply-To: <CAAS2fgTAFgANJ495xiOkiW-OeFA_VZHhhR5uL+jVaoYQz_yBPg@mail.gmail.com>
References: <CAAS2fgQyVs1fAEj+vqp8E2=FRnqsgs7VUKqALNBHNxRMDsHdVg@mail.gmail.com>
	<20151208110752.GA31180@amethyst.visucore.com>
	<CABm2gDpcek=u=Rpe68EMOq6M7Bji9J=s5VvoQWKRqaQDAP5kTw@mail.gmail.com>
	<CABsx9T1wga3Tandoe2mVGSKdHJytHoc9Ko7HRm2SvJXABEFk9w@mail.gmail.com>
	<CAAS2fgTGYSiAJHZq80rD4UieV8XetS=W0b45b5onWAS9gF-F7g@mail.gmail.com>
	<CABsx9T1i50Gvxj18W=n2mYGNpsMrSkDT26CdA3aQqT5FFN86yw@mail.gmail.com>
	<CAAS2fgSxpSat3VOje3-C4zgaRUVJVx-eRJbSYJqhvfR5SvCDwA@mail.gmail.com>
	<CAF_2MyUJMdJyh7FKq6UYCtwJZQ59i-pnWT_tFEK5EQx65iwHDQ@mail.gmail.com>
	<CAAS2fgS-jjEVeHf_LErppTadtAaSeBum+KiGHpoo=Jz5BZArsQ@mail.gmail.com>
	<CABm2gDq4f0ettDhh14jZ0zztSwSJ0Z=KDEeMTOJxTHF8VV+KXw@mail.gmail.com>
	<CAAS2fgTAFgANJ495xiOkiW-OeFA_VZHhhR5uL+jVaoYQz_yBPg@mail.gmail.com>
Date: Wed, 9 Dec 2015 12:08:14 +0100
Message-ID: <CABm2gDratPeF8ibxFO-WYhVeAnT6GG6O0tZenNhfX257+ue0dQ@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Gregory Maxwell <greg@xiph.org>
Content-Type: multipart/alternative; boundary=001a11425bf05b1fa60526751b2a
X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,URIBL_BLACK autolearn=no
	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: Wed, 09 Dec 2015 11:08:20 -0000

--001a11425bf05b1fa60526751b2a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Fair enough.
On Dec 9, 2015 4:03 PM, "Gregory Maxwell" <greg@xiph.org> wrote:

> On Wed, Dec 9, 2015 at 7:54 AM, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrote=
:
> > From this question one could think that when you said "we can do the
> > cleanup hardfork later" earlier you didn't really meant it. And that
> > you will oppose to that hardfork later just like you are opposing to
> > it now.
> > As said I disagree that making a softfork first and then move the
> > commitment is less disruptive (because people will need to adapt their
> > software twice), but if the intention is to never do the second part
> > then of course I agree it would be less disruptive.
> > How long after the softfork would you like to do the hardfork?
> > 1 year after the softfork? 2 years? never?
>
> I think it would be logical to do as part of a hardfork that moved
> commitments generally; e.g. a better position for merged mining (such
> a hardfork was suggested in 2010 as something that could be done if
> merged mining was used), room for commitments to additional block
> back-references for compact SPV proofs, and/or UTXO set commitments.
> Part of the reason to not do it now is that the requirements for the
> other things that would be there are not yet well defined. For these
> other applications, the additional overhead is actually fairly
> meaningful; unlike the fraud proofs.
>

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

<p dir=3D"ltr">Fair enough.</p>
<div class=3D"gmail_quote">On Dec 9, 2015 4:03 PM, &quot;Gregory Maxwell&qu=
ot; &lt;<a href=3D"mailto:greg@xiph.org">greg@xiph.org</a>&gt; wrote:<br ty=
pe=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, Dec 9, 2015 at 7:=
54 AM, Jorge Tim=C3=B3n &lt;jtimon@jtimon.cc&gt; wrote:<br>
&gt; From this question one could think that when you said &quot;we can do =
the<br>
&gt; cleanup hardfork later&quot; earlier you didn&#39;t really meant it. A=
nd that<br>
&gt; you will oppose to that hardfork later just like you are opposing to<b=
r>
&gt; it now.<br>
&gt; As said I disagree that making a softfork first and then move the<br>
&gt; commitment is less disruptive (because people will need to adapt their=
<br>
&gt; software twice), but if the intention is to never do the second part<b=
r>
&gt; then of course I agree it would be less disruptive.<br>
&gt; How long after the softfork would you like to do the hardfork?<br>
&gt; 1 year after the softfork? 2 years? never?<br>
<br>
I think it would be logical to do as part of a hardfork that moved<br>
commitments generally; e.g. a better position for merged mining (such<br>
a hardfork was suggested in 2010 as something that could be done if<br>
merged mining was used), room for commitments to additional block<br>
back-references for compact SPV proofs, and/or UTXO set commitments.<br>
Part of the reason to not do it now is that the requirements for the<br>
other things that would be there are not yet well defined. For these<br>
other applications, the additional overhead is actually fairly<br>
meaningful; unlike the fraud proofs.<br>
</blockquote></div>

--001a11425bf05b1fa60526751b2a--