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
|
Return-Path: <pete@petertodd.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id D8AD1E44
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 8 Feb 2016 22:55:12 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from outmail148110.authsmtp.com (outmail148110.authsmtp.com
[62.13.148.110])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id 0B538138
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 8 Feb 2016 22:55:11 +0000 (UTC)
Received: from mail-c247.authsmtp.com (mail-c247.authsmtp.com [62.13.128.247])
by punt20.authsmtp.com (8.14.2/8.14.2/) with ESMTP id u18MtA5G080835;
Mon, 8 Feb 2016 22:55:10 GMT
Received: from petertodd.org (ec2-52-5-185-120.compute-1.amazonaws.com
[52.5.185.120]) (authenticated bits=0)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id u18Mt5Rm036190
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
Mon, 8 Feb 2016 22:55:06 GMT
Received: from [127.0.0.1] (localhost [127.0.0.1])
by petertodd.org (Postfix) with ESMTPSA id 5786340012;
Mon, 8 Feb 2016 22:51:50 +0000 (UTC)
Received: by savin (Postfix, from userid 1000)
id 9983313FCD4; Mon, 8 Feb 2016 17:55:04 -0500 (EST)
Received: by savin (hashcash-sendmail, from uid 1000);
Mon, 8 Feb 2016 17:54:36 -0500
Date: Mon, 8 Feb 2016 17:54:36 -0500
From: Peter Todd <pete@petertodd.org>
To: Simon Liu <simon@bitcartel.com>
Message-ID: <20160208225436.GB25684@savin.petertodd.org>
References: <56B8EBF8.4050602@mattcorallo.com> <56B9187F.3040104@bitcartel.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="E39vaYmALEf/7YXx"
Content-Disposition: inline
In-Reply-To: <56B9187F.3040104@bitcartel.com>
X-Hashcash: 1:28:160208:simon@bitcartel.com::JkrbYFQqoLNii6Y9:000000000000000000
000000000000000000000005o+Px
X-Hashcash: 1:28:160208:lf-lists@mattcorallo.com::D12y0UeG9GdlhVm1:0000000000000
000000000000000000000005wR3U
X-Hashcash: 1:28:160208:bitcoin-dev@lists.linuxfoundation.org::8k1gvoUZrIJaLsIt:
000000000000000000000002d3hA
X-Server-Quench: ff3e1ee1-ceb6-11e5-bcde-0015176ca198
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aQdMdgoUHlAWAgsB AmAbWVZeVVh7WWU7 bghPaBtcak9QXgdq
T0pMXVMcUQRgfFgE ZEMeUR9zfgUIeX13 YkAsCCZYCUUvIEdg
ERsGE3AHZDJldTJM BBVFdwNVdQJNeEwU a1l3GhFYa3VsNCMk
FAgyOXU9MCtqYANT CiEEN14cRlwIBXY9 QVgeHThnNkoDWygj
M1QhJBYnEUkuM1la
X-Authentic-SMTP: 61633532353630.1038:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 52.5.185.120/25
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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
X-Mailman-Approved-At: Tue, 09 Feb 2016 03:56:35 +0000
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] On Hardforks in the Context of SegWit
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: Mon, 08 Feb 2016 22:55:13 -0000
--E39vaYmALEf/7YXx
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Mon, Feb 08, 2016 at 02:36:47PM -0800, Simon Liu via bitcoin-dev wrote:
> > 1) The segregated witness discount is changed from 75% to 50%. The block
> > size limit (ie transactions + witness/2) is set to 1.5MB. This gives a
> > maximum block size of 3MB and a "network-upgraded" block size of roughly
> > 2.1MB. This still significantly discounts script data which is kept out
> > of the UTXO set, while keeping the maximum-sized block limited.
>=20
> What is the rationale for offering a discount?
UTXO set space is significantly more expensive for the network as all
full nodes must keep the entire UTXO set.
Additionally, transaction input/output data in general is argued by some
to be less expensive than signatures, as you have more options with
regard to skipping validation of signatures (e.g. how Bitcoin Core skips
validation of signatures prior to checkpoints).
> Is there an economic basis for setting the original discount at 75%
> instead of some other number?
>=20
> If it's okay to arbitrarily reduce the discount by 1/3, what are the
> actual boundary limits: 50% - 75% ? 40% - 80% ?
So, something to keep in mind in general in all these discussions is
that at best engineering always has "magic numbers" involved, the
question is where?
For example, I've proposed that we use a 99% miner vote threshold for
hard-forks (remember that the threshold can always be soft-forked down
later). The rational there is, among other things, you want to ensure
that the non-adopting miners' chain is useless for transacting due to
extremely long block times, as well as we want it to receive
confirmations slowly to prevent fraud. (of course, there's also the
non-technical argument that we want to adopt hard-forks with extremely
wide adoption) At 99% the 1% remaining chain will have a block interval
of about 16 hours.
Now, I've been asked "why 99%? isn't that a magic number?"
I could have instead said my goal was to increase the block interval to
24 hours, in which case I'd have used a 99.3% threshold. But again,
isn't 24 hours a magic number? Why not 25hrs?
The answer is 24 hours *is* a magic number - but trying to eliminate
that with yet another meta level of engineering analysis becomes a game
of diminishing returns.
--=20
https://petertodd.org 'peter'[:-1]@petertodd.org
000000000000000001ae7ca66e52359d67c407a739fde42b83ecc746d3ab735d
--E39vaYmALEf/7YXx
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQGrBAEBCACVBQJWuRynXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAwNDJjOWZmZGJjODM3Mzc4MTIzYzViZWNhNzBhYzM4YmY0
YTAzYjc5NTNjZDgzM2EvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfuGQAgAjWK7TMEXWwtzzBwBzzj1epIe
Tz6oLcdbw28UZ7UQ9FzQVMAoZaAernO68i0P48d6CsICBW6EBH+jlqJYNcZtywff
Ff9dvmDY9wUvkZr9bFcr8qW+p+Ow65Jw5w0nvB41XGC8FegezYfTI1FQ/WmefOLu
SZZ4q/Yp2cpGt4GyZfQ0DKOM+qfw1LQ6PkcHo4B9eFPDShngBwa+hyVTZsuAFWrb
h+UTO/tk1OkKTMPdcilSkTBnP4H8RAPPjsRV3LLBbFYQECxvQN/XqRSmqj/oPGl4
z2HWNu07xorxfc0IzBPt5+6qbciEox0RaSJmIKKMAaY6/ompEup+GX97I/g3Hw==
=gnxj
-----END PGP SIGNATURE-----
--E39vaYmALEf/7YXx--
|
