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
174
175
176
177
178
179
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1TBZmV-0006aq-RM
for bitcoin-development@lists.sourceforge.net;
Tue, 11 Sep 2012 23:22:11 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.216.175 as permitted sender)
client-ip=209.85.216.175; envelope-from=gmaxwell@gmail.com;
helo=mail-qc0-f175.google.com;
Received: from mail-qc0-f175.google.com ([209.85.216.175])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1TBZmU-0006p3-VB
for bitcoin-development@lists.sourceforge.net;
Tue, 11 Sep 2012 23:22:11 +0000
Received: by qcad10 with SMTP id d10so715781qca.34
for <bitcoin-development@lists.sourceforge.net>;
Tue, 11 Sep 2012 16:22:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.134.207 with SMTP id k15mr5291802qct.60.1347405725510;
Tue, 11 Sep 2012 16:22:05 -0700 (PDT)
Received: by 10.49.35.180 with HTTP; Tue, 11 Sep 2012 16:22:05 -0700 (PDT)
In-Reply-To: <19ED4257-0BCA-41C5-A533-B0AB9B500181@godofgod.co.uk>
References: <2104FC7F-0AE0-4C55-9987-B20EFCE19FC3@godofgod.co.uk>
<CAAS2fgSymOJ=cQnNwK9+nvRYszHHH4vtUpoQYWNNYoVaYB5Gpg@mail.gmail.com>
<19ED4257-0BCA-41C5-A533-B0AB9B500181@godofgod.co.uk>
Date: Tue, 11 Sep 2012 19:22:05 -0400
Message-ID: <CAAS2fgRfXBrsFm_zdNFe7Z4FN7uQ5zSg++scng=hNrHZZV93VQ@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.3 (-)
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.3 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1TBZmU-0006p3-VB
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 23:22:11 -0000
On Tue, Sep 11, 2012 at 5:48 PM, Matthew Mitchell
<matthewmitchell@godofgod.co.uk> wrote:
> You wouldn't need to pipeline the requests, just place more than one inve=
ntory vector in get data, right? Well my messages would save the space of t=
hose inventory vectors. Instead of needing 36 byte inventory vectors for ea=
ch transaction and a var int, you would need two var ints only. And then th=
e transaction responses only need one header, so you save 24 bytes for each=
transaction after the first. You could say that is a small benefit.
But you only need to request the transactions you don't have. Most of
time you should already have almost all of the transactions.
> Look at bittorrent. With bittorrent you don't download files from a singl=
e peer all at once.
You can fetch transactions from multiple peers with just a simple
mechanism that gives you the headers plus the txn list. And if you
want ArgumentAdSomethingElse, thats what bittorrent does too: the
torrent file contains the list of block hashes, and you get it from
one place.
> Why wouldn't requesting minimum fees in the software work as is done curr=
ently?
Because there is no motivation not to set them to zero, if you don't
someone else will. Right now the income from fees is hardly relevant,
and the ability to drive more non-existant because there isn't enough
load to create scarcity.
> So what you essentially suggest is having bitcoin banks that maintain tru=
st through Open Transaction contracts which contains proof of agreement, pr=
oviding some legal protection? One wonders why have bitcoin at all then? Wh=
y not have an elaborate e-money system between several banks using Open Tra=
nsactions?
Because it can't resist inflation. You have to trust that the banks
won't conspire to their mutual benefit to inflate the base currency.
OT can make it so a 'bank' (which is really a distributed collection
of nodes, not a single point of trust) can trivially prove how much
"gold certificates" it has issued, but you also need to prove how much
'gold' exists and which keys hold it, and for that you need a _global_
consensus; which bitcoin provides...
If you don't like
>Bitcoin doesn't just contain proof of if something was done right or not, =
it contains actual certainty that it will be done right. And how does Open =
>Transactions prevent fractional reserve fraud?
Well, Bitcoin gives you no certainty that any particular transaction
will be confirmed at all, ever; so perhaps best not to overstate it
too much. But yes, Bitcoin is great. ... but all that greatness
depends on there being a way to fund enough computation so that
attacks are too costly to be justified and that the cost of
maintaining a system to fully validate the system's rules (e.g. that
the miners aren't mining duplicate txns to create inflation for
themselves) is low enough that it will naturally enormously
distributed so that a conspiracy is effectively impossible. Otherwise
everything consolidates down to a few meganodes and the attractive
properties are all gone.
OT's issuers can prove how much bitcoin they hold on the blockchain
(by nothing more sophisticated than signmessage) and they can prove
how many tokens they've issued against it.
And I didn't mean to suggest OT as a unique solution. Another path is
ripple, the idea of which is a sort of a p2p hawala where you have
pairwise trust and debt. It can allow you to circulate around tokens
between a community of users and only settle infrequently (as
determined by your level of trust, the debt involved, and the cost of
the bitcoin transaction) against bitcoin.
> I suppose when people consider bitcoin banks, they will consider bitcoin =
being useless.
They already exist, in crappy centralized form=E2=80=94 e.g. look at mtgox
codes and user to user instant transfers; and bitcoin isn't useless.
Plus some extra system of some kind is the _only_ way to securely
irreversible transactions which are reliably fast, so it's not like
there is any real prospect of using bitcoin directly for all kinds of
uses at scale. (yes, blocks are 'only' 10 minutes apart on average,
but if you care about fast, you care about e.g. the 99% not the
average)
> As far as I see it, if bitcoin won't scale, then it's worth looking at so=
mething different to bitcoin that will scale.
Bitcoin scales fine. It is not a singular replacement for everything
you can imagine it being a replacement for, however, or at least not a
good replacement. The fact that you could conceivably make it
directly scale up to handle e.g. the volume of all the credit network
doesn't make that a good idea. It would still be a very poor
replacement for a credit network (slow transactions; which can't be
fixed by tweaking some parameters, the bitcoin blockchain consensus
algorithm has infinite convergence time when the block time falls
below the hash-power-weighed latency), and that kind of scaling would
absolutely ruin the decentralization, making it so only large states
and megabanks could run full nodes, and even at that level it couldn't
match the worldwide volume of cash transactions or 'internal' money
transactions (like money moving around on all the poker tables in the
world). It's like someone made the mistake of saying the floor wax
is edible (linseed oil) and now you complain that its a crappy desert
topping. :P
Maybe people will ultimately agree to raise the block sizes, but I
expect and hope that they'll only do so when it is entirely
uncontroversial that doing so won't significantly degrade the
decentralization (certainly not the case today: a large portion of the
network appears to have trouble keeping up with large blocks right
now, though upcoming software improvements will help enormously), or
the mining economics. And yes, of course, you schedule the change
for the future, but as you note that it doesn't solve the problem of
people opposing it.
|
