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
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1TBWM2-00052U-Ha
for bitcoin-development@lists.sourceforge.net;
Tue, 11 Sep 2012 19:42:38 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.210.175 as permitted sender)
client-ip=209.85.210.175; envelope-from=gmaxwell@gmail.com;
helo=mail-iy0-f175.google.com;
Received: from mail-iy0-f175.google.com ([209.85.210.175])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1TBWM1-0006Ov-NE
for bitcoin-development@lists.sourceforge.net;
Tue, 11 Sep 2012 19:42:38 +0000
Received: by iaky10 with SMTP id y10so698432iak.34
for <bitcoin-development@lists.sourceforge.net>;
Tue, 11 Sep 2012 12:42:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.50.178.97 with SMTP id cx1mr17302762igc.48.1347392552391; Tue,
11 Sep 2012 12:42:32 -0700 (PDT)
Received: by 10.64.56.66 with HTTP; Tue, 11 Sep 2012 12:42:32 -0700 (PDT)
In-Reply-To: <2104FC7F-0AE0-4C55-9987-B20EFCE19FC3@godofgod.co.uk>
References: <2104FC7F-0AE0-4C55-9987-B20EFCE19FC3@godofgod.co.uk>
Date: Tue, 11 Sep 2012 15:42:32 -0400
Message-ID: <CAAS2fgSymOJ=cQnNwK9+nvRYszHHH4vtUpoQYWNNYoVaYB5Gpg@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Matthew Mitchell <matthewmitchell@godofgod.co.uk>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.2 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(gmaxwell[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
0.4 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1TBWM1-0006Ov-NE
Cc: "bitcoin-development@lists.sourceforge.net"
<bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Segmented Block Relaying BIP draft.
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Tue, 11 Sep 2012 19:42:38 -0000
On Tue, Sep 11, 2012 at 3:07 PM, Matthew Mitchell
<matthewmitchell@godofgod.co.uk> wrote:
> For some reason sourceforge is not sending me updates anymore but I can s=
ee the replies online=E2=80=A6
>
> There could be a slightly more simple protocol which gives all the transa=
ctions hashes and nodes can then download the transactions separately. Howe=
ver there are two problems:
>
> 1. Downloading all the transactions individually might be inefficient. My=
proposal will allow nodes to request multiple transactions at once.
Someone can do that just by pipelining the one at a time requests.
How much bandwidth do you think you could save over that?
> 2. Why not add a few additional components to the protocol to allow reque=
sts for any level of the merkle tree? It's not very complicated at all and =
protects against the future.
I don't see what value this provides. For protecting against the
future you might as well suggest uploading x86 code which gets
executed to select transactions. "Protects against the future". Can
you clarify some more about exactly how you think it would help?
It's sometimes desirable to be more general rather than more special
case when it's costless... but having couple extra p2p protocol
messages to implement, test for interop, guard against vulnerability,
etc. isn't costless... and should be justified with concrete benefits.
it's not clear to me how your proposal is really all that useful for
very large blocks: I looks like it would lot of bytes sending
redundant tree data.
>The block sizes at the moment are about 0.1MB but what if the bitcoin dema=
nd starts pushing that into megabytes?
And what if? _Bitcoin_ blocksizes can't be any larger. Some future
incompatible system? well perhaps. But we're working on the protocol
for bitcoin now.
> And yes the ~0.95MB limit needs to be changed in order for bitcoin to gro=
w that far. Why would the limit not be lifted? How will bitcoin demand be s=
atisfied other than having large fees to deter transactions, hoping the fee=
s are large enough to balance the demand with the block size limits to prev=
ent many transactions being unconfirmed and annoying users? That limit has =
got to go eventually. And then it could be that block sizes do become large=
enough to worry about the performance in relaying.
The finite size=E2=80=94 and ultimately the contention for space it causes=
=E2=80=94 is
the only thing will creates non-trivial fees. Without the fees there
is no honest economic motivation to mine with adequate computing power
to provide security (lots of dishonest motivations=E2=80=94 e.g. applying
control over the currency exist), you'd just have a race to the
bottom, given unbounded block sizes it is always rational for
decentralized to include any transaction with a fee even if it is very
small=E2=80=94 otherwise the next rational solver is just going to include =
it.
Bitcoin gets its value through scarcity. There are two kinds of
scarcity that are economically important, scarcity of the coins=E2=80=94 th=
ere
will never be more than 21 million=E2=80=94 and scarcity of the block space
which, as the protocol is defined and enforced by every node can not
be more than 1MB. The latter scarcity is what makes the security model
economically sane.
Fortunately, its perfectly possible to make transactions denominated
in bitcoin outside of the blockchain, and in a secure and distributed
manner that respects the principles that make bitcoin attractive, but
with information hiding that improves privacy, transaction speed, and
scalability. See, e.g. the good work being done by Open transactions
to create distributed cryptographic banks. So blockchain scarcity
itself doesn't prevent Bitcoin from being a one world currency
(something which isn't at all sane no matter how big you make the
blocks if you don't allow for other modes of transaction processing=E2=80=
=94
who the heck wants to possibly wait an hour to get a 1 confirm
sodapop??).
From the beginning it was obvious that confirmations would eventually
be slower (or expensive to make merely slow; Bitcoin is incapable of
reliable fast confirmations)=E2=80=94 thats the nature the stochastic
consensus and the fee based security support. You could instead
imagine a future where bitcoin's security came by collusion by major
financial cartels and governments, and where fees aren't important....
But I reject that future, it's a perfectly viable one, but why bother
with Bitcoins in the first place? To make some early adopters a little
bit of money starting off the next big centrally controlled fiat?
Boring.
I can't say for sure if the 1MB limit will stay exactly as is forever,
as I expect the economics work with any limit out of a fairly broad
range that is low enough to both make the space seriously scarce and
low enough that 'inexpensive' (e.g. privately owned) hardware can
continue to audit it to preserve the decentralized security, and the
economic importance of the size limit is more subtle than the
inflation resistance... but I know that changing it is precisely as
technically difficult as changing the 21 million limit: all Bitcoin
node software must be replaced with incompatible software, and I
believe it would be just as economically risky=E2=80=94 if not more so=E2=
=80=94 if
done wrong, as at least inflation would have a easily understood
direct dillution effect while inadequate security would potentially
make all Bitcoin worthless. As such I don't think it's even worth
discussing until there is an urgent demand to clarify the tradeoffs...
Should the block size ever be increased the message format used for
relaying the larger blocks will be the smallest of the issues being
discussed.
|
