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
|
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 58899487
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 30 Jul 2015 14:10:50 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com
[209.85.212.182])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 11E737C
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 30 Jul 2015 14:10:48 +0000 (UTC)
Received: by wicmv11 with SMTP id mv11so22862840wic.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 30 Jul 2015 07:10:47 -0700 (PDT)
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
:content-transfer-encoding;
bh=htqOSpxrR5OcFfcIaNpWR7nkwBsLq/H4YxeqU7JGlBg=;
b=d7pQR9avOhW/My2PYOEVSHBinrzNmU3VfjD2k+Gzswy074/XcFO2k62nJukTStdwpU
FcmfwhhBMzTEfx2a34tPNMyxrJnQxzvIOq/yPP/m83R3iTkEVPgWEeTYUgGHPRxDj3nQ
Q3NDySQquqwPSUGGN8ItfLw+zIybKmErBFXC13v0ppxKy+R6V3SswL0BQVZ4jYLPUv2e
TwW51hcrvaCJOlg57GD3Qs/93+X3QqampcMLioilHMf4Ns44gcEHBfcxndVVYMm71aPx
MTVxPt6eIxzH49+1VCD10+YwfH1hYWUk9G/tLcU1/f8Ln6BBteqBvjTpJU2gEobWCvlB
w+BA==
X-Gm-Message-State: ALoCoQn513m+QR3ixiHmbKWEkdpndB1fpdhUAQIdO8beX71x5asdb8NIkvSraHRyeHccug2B98G8
MIME-Version: 1.0
X-Received: by 10.180.37.74 with SMTP id w10mr6438679wij.92.1438265447544;
Thu, 30 Jul 2015 07:10:47 -0700 (PDT)
Received: by 10.194.95.168 with HTTP; Thu, 30 Jul 2015 07:10:46 -0700 (PDT)
In-Reply-To: <55BA2795.70805@mail.bihthai.net>
References: <1B7F00D3-41AE-44BF-818D-EC4EF279DC11@gmail.com>
<CA+w+GKTfPXkVPaCC+3ZsQv=_DPMHoRwbigS40Testpyq4rZxsw@mail.gmail.com>
<D25BD175-7099-4A6B-89BB-A35E94F555A9@gmail.com>
<CA+w+GKTZV5sgXNU_xoBby1_X6eae=5_vhENmyKY0yxWHcBiU5g@mail.gmail.com>
<37D282C2-EF9C-4B8B-91E8-7D613B381824@phauna.org>
<CAAS2fgSaRqxi3X0J3F05nA-tyRRikY1whkpAOuGJJpFSAR017w@mail.gmail.com>
<COL131-DS222F0D512C6A5B47BF62C2CD8C0@phx.gbl>
<55B94FAD.7040205@mail.bihthai.net>
<COL131-DS95F86B1D5B93CE1275911CD8C0@phx.gbl>
<CALqxMTEUAtNxkYMQwA9g9xH_LiX98yYOooGjUho1T3fMY2J5jQ@mail.gmail.com>
<55B9EB68.9020703@mail.bihthai.net>
<CABm2gDpJjimF486qca=JGQ0h6k9qzike-hjVUU2NhOuCzbBkow@mail.gmail.com>
<55BA2795.70805@mail.bihthai.net>
Date: Thu, 30 Jul 2015 16:10:46 +0200
Message-ID: <CABm2gDqPCuAOaPXf5XQ=BQBBMSuRB+OQvN3DUHkRZYk4kvTdqQ@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: venzen@mail.bihthai.net
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure
isn'ttemporary
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: Thu, 30 Jul 2015 14:10:50 -0000
On Thu, Jul 30, 2015 at 2:29 PM, Gavin via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> I would like (and have been asking) those people to take the time to quan=
tify those costs and write up those risks in a careful way.
I agree that having a "minimal hardware requirements" specification
would greatly help with this discussions.
> I believe the costs and risks of 8MB blocks are minimal, and that the ben=
efits of supporting more transaction FAR outweigh those costs and risks, bu=
t it is hard to have a rational conversation about that when even simple qu=
estions like 'what is s reasonable cost to run a full node' are met with si=
lence.
These tests by Rusty (strong advocate of IBLT and working on it) seem
to indicate otherwise: http://rusty.ozlabs.org/?p=3D509
On Thu, Jul 30, 2015 at 2:50 PM, Pieter Wuille via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> I think the risks of trying to make a controversial change to the network
> FAR outweighs the benefits of a small constant factor that "kicks the can
> down the road".
I think the risks of a controversial deployment in consensus rules
changes, outweigh by far potential benefits of ANY consensus forks, no
matter how amazing the potential benefits may seem. Bitcoin may not
survive a controversial hardfork or go 3 years back in adoption,
nobody knows.
> Let's scale the block size gradually over time, according to technologica=
l
> growth.
I agree. Unfortunately, technological and economic growth is very hard
to predict.
On Thu, Jul 30, 2015 at 3:33 PM, Venzen Khaosan <venzen@mail.bihthai.net> w=
rote:
> 2. Bitcoin is much more than a payment network. A lot of the
> non-payment features are, arguably, what gives Bitcoin most of its
> value. Yet, the payment functionality is a major design feature and
> all agree that it should scale - subject to axiom 1.
I just explained why I disagree with this point. Bitcoin fees depend
on transaction sizes rather than amounts moved. Even ignoring
script-based signatures and all the other advantages in Bitcoin, that
fact alone makes it extremely competitive with "traditional systems"
for many use cases (say, sending 1000 usd from the US to M=C3=A9xico).
I agree overall with your other points.
Extremely cheap and instant transactions can be provided by lightning,
but cannot be provided by Bitcoin in-chain alone in the long term (it
can't even provide instant irreversible transactions).
> Since I've maintained your interest up to the final sentence, I say:
> as an insurance against a capacity crisis before layer 2 is deployed,
> why not implement bip100's 2MB blocksize proposals in a testnet?
Of all blocksize proposals, bip102 (the one with the single doubling
to 2MB) is the one I dislike less because it doesn't make any
assumptions about future technological or economic growth (I loved
your Bohr cite).
But it still has something that I dislike from all proposals: the
numbers just seem pulled out of a hat.
But I already created that testnet you propose (and
std::numeric_limits<uint64_t>::max() -1 more testnets for other sizes)
in https://github.com/bitcoin/bitcoin/pull/6382
You can run it with the following runtime options: -chain=3Dsizetest
-blocksize=3D2000000
Unfortunately, nobody seems interested in running some tests for
several sizes before proposing a concrete size.
As far as I know, nobody has used that branch to test different sizes.
|