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
|
Return-Path: <jgarzik@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id EC5751386
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Sep 2015 21:32:06 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com
[209.85.212.180])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3484C256
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Sep 2015 21:32:06 +0000 (UTC)
Received: by wiclk2 with SMTP id lk2so91696522wic.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Sep 2015 14:32:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:date:message-id:subject:from:to:content-type;
bh=89KhZSy3zJpLo5J8P44BCFSwN306tv39QbBrb+UbIXQ=;
b=TYNq1BRLyOaoSaqELu7EzlJRC5M6ZZNauPpugfeORL5lfWFYRMw4/RrUzYdvRO2AE7
jFuKrKFTeuvCXq9+2xO/5C1hwivp+G3S6pOgCLrvFKk95dFw920dOlHGE8S6ZtNCGx6L
uzo2ioLtrwwh79hAfsARXw/L0z7YAeDEKemWEXVP6mHXzImqBvIMAi4rjSWOIbYl0B23
Og/yWZzJpSldYuACoVhueikN2tFfHgf8wzQm7/wwYOEHaBaLWyG+Yam0ESj7El4kYrcH
9E3deEbRyj5rCcHyzu3xB7RfFxptjjkfJH7vvkRC7ayub/9RnvRICepLO529HgQPmgN6
3oGA==
MIME-Version: 1.0
X-Received: by 10.180.87.1 with SMTP id t1mr627579wiz.33.1442439124713; Wed,
16 Sep 2015 14:32:04 -0700 (PDT)
Received: by 10.28.158.9 with HTTP; Wed, 16 Sep 2015 14:32:04 -0700 (PDT)
Date: Wed, 16 Sep 2015 17:32:04 -0400
Message-ID: <CADm_WcaLKqhR=WcJ5B52Q9SAAa+AdZY6Kz5OCQVUc_RQm6e9gg@mail.gmail.com>
From: Jeff Garzik <jgarzik@gmail.com>
To: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=f46d044481afa38664051fe407f3
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,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
Subject: [bitcoin-dev] Scaling Bitcoin conference micro-report
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, 16 Sep 2015 21:32:07 -0000
--f46d044481afa38664051fe407f3
Content-Type: text/plain; charset=UTF-8
During Scaling Bitcoin, Bitcoin Core committers and notable contributors
got together and chatted about where a "greatest common denominator" type
consensus might be. The following is a without-attribution (Chatham House)
summary. This is my own personal summary of the chat; any errors are my
own; this is _not_ a consensus statement or anything formal.
- Background (pre-conference, was on public IRC): "net-utxo", calculating
transaction size within block by applying a delta to transaction size based
on the amount of data added, or removed, from the UTXO set. Fee is then
evaluated after the delta is applied. This aligns user incentives with
UTXO resource usage/cost. Original idea by gmaxwell (and others??).
- Many interested or at least willing to accept a "short term bump", a hard
fork to modify block size limit regime to be cost-based via "net-utxo"
rather than a simple static hard limit. 2-4-8 and 17%/year were debated
and seemed "in range" with what might work as a short term bump - net after
applying the new cost metric.
- Hard fork method: Leaning towards "if (timestamp > X)" flag day hard
fork Y months in the future. Set high bit in version, resulting in a
negative number, to more cleanly fork away. "miner advisement" - miners,
as they've done recently, signal non-binding (Bitcoin Core does not examine
the value) engineering readiness for a hard fork via coinbase moniker.
Some fork cancellation method is useful, if unsuccessful after Z time
elapses.
- As discussed publicly elsewhere, other forks may be signaled via setting
a bit in version, and then triggering a fork'ing change once a threshold is
reached.
Chat participants are invited to reply to this message with their own
corrections and comments and summary in their view.
For the wider community, take this as one of many "inputs" described at
Scaling Bitcoin. Over the next few months developers and the community
should evaluate everything discussed and work towards some concrete
proposal(s) that are implemented, tested and simulated in December in Hong
Kong.
--f46d044481afa38664051fe407f3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><br></div><div>During Scaling Bitcoin, Bitcoin Core c=
ommitters and notable contributors got together and chatted about where a &=
quot;greatest common denominator" type consensus might be.=C2=A0 The f=
ollowing is a without-attribution (Chatham House) summary.=C2=A0 This is my=
own personal summary of the chat; any errors are my own; this is _not_ a c=
onsensus statement or anything formal.</div><br style=3D"font-size:13px"><s=
pan style=3D"font-size:13px">- Background (pre-conference, was on public IR=
C): "net-utxo", calculating transaction size within block by appl=
ying a delta to transaction size based on the amount of data added, or remo=
ved, from the UTXO set.=C2=A0 Fee is then evaluated after the delta is appl=
ied.=C2=A0 This aligns user incentives with UTXO resource usage/cost.=C2=A0=
Original idea by gmaxwell (and others??).</span><br style=3D"font-size:13p=
x"><br style=3D"font-size:13px"><span style=3D"font-size:13px">- Many inter=
ested or at least willing to accept a "short term bump", a hard f=
ork to modify block size limit regime to be cost-based via "net-utxo&q=
uot; rather than a simple static hard limit. =C2=A02-4-8 and 17%/year were =
debated and seemed "in range" with what might work as a short ter=
m bump - net after applying the new cost metric.</span><br style=3D"font-si=
ze:13px"><br style=3D"font-size:13px"><span style=3D"font-size:13px">- Hard=
fork method: =C2=A0Leaning towards "if (timestamp > X)" flag =
day hard fork Y months in the future.=C2=A0 Set high bit in version, result=
ing in a negative number, to more cleanly fork away. =C2=A0"miner advi=
sement" - miners, as they've done recently, signal non-binding (Bi=
tcoin Core does not examine the value) engineering readiness for a hard for=
k via coinbase moniker.=C2=A0 Some fork cancellation method is useful, if u=
nsuccessful after Z time elapses.</span><br style=3D"font-size:13px"><br st=
yle=3D"font-size:13px"><span style=3D"font-size:13px">- As discussed public=
ly elsewhere, other forks may be signaled via setting a bit in version, and=
then triggering a fork'ing change once a threshold is reached.</span><=
br><div><span style=3D"font-size:13px"><br></span></div><div>Chat participa=
nts are invited to reply to this message with their own corrections and com=
ments and summary in their view.</div><div><br></div><div>For the wider com=
munity, take this as one of many "inputs" described at Scaling Bi=
tcoin.=C2=A0 Over the next few months developers and the community should e=
valuate everything discussed and work towards some concrete proposal(s) tha=
t are implemented, tested and simulated in December in Hong Kong.</div><div=
><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div=
><br></div></div>
--f46d044481afa38664051fe407f3--
|
