summaryrefslogtreecommitdiff
path: root/00/9bdb35f91e33c8997157df871f246af2738746
blob: 0fdb62125da8f61a5103161548ecd70ba1f1d659 (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
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.