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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from
<SRS0=rXVvyT=HK=godofgod.co.uk=matthewmitchell@eigbox.net>)
id 1TBYKD-0002gP-Fl for bitcoin-development@lists.sourceforge.net;
Tue, 11 Sep 2012 21:48:53 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of eigbox.net
designates 66.96.188.16 as permitted sender)
client-ip=66.96.188.16;
envelope-from=SRS0=rXVvyT=HK=godofgod.co.uk=matthewmitchell@eigbox.net;
helo=bosmailout16.eigbox.net;
Received: from bosmailout16.eigbox.net ([66.96.188.16])
by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1TBYKC-0006qY-Ns for bitcoin-development@lists.sourceforge.net;
Tue, 11 Sep 2012 21:48:53 +0000
Received: from bosmailscan01.eigbox.net ([10.20.15.1])
by bosmailout16.eigbox.net with esmtp (Exim) id 1TBYK7-00013x-Ee
for bitcoin-development@lists.sourceforge.net;
Tue, 11 Sep 2012 17:48:47 -0400
Received: from bosimpout01.eigbox.net ([10.20.55.1])
by bosmailscan01.eigbox.net with esmtp (Exim)
id 1TBYK7-0000Fx-4A; Tue, 11 Sep 2012 17:48:47 -0400
Received: from bosauthsmtp06.eigbox.net ([10.20.18.6])
by bosimpout01.eigbox.net with NO UCE
id xxon1j00307rX7u01xonKK; Tue, 11 Sep 2012 17:48:47 -0400
X-Authority-Analysis: v=2.0 cv=aPZHX8Bm c=1 sm=1
a=cRTwvq1SzvVpLn7uyA08BA==:17 a=Goz4v7xpImgA:10 a=JhU9KSwl1l8A:10
a=RmqW3wxksLsA:10 a=N659UExz7-8A:10 a=eGitJVp2AAAA:8 a=-aUnnjAAwhoA:10
a=pGLkceISAAAA:8 a=xWRbeWez38hbk6K_X2AA:9 a=pILNOxqGKmIA:10
a=MSl-tDqOz04A:10
a=7KhLVuCWMc1eCxG9:21 a=RC34QbZKBvMb1Vmp:21
a=fIc3/5IyPUehxkj7BpkQ7Q==:117
X-EN-OrigOutIP: 10.20.18.6
X-EN-IMPSID: xxon1j00307rX7u01xonKK
Received: from [109.175.173.22]
by bosauthsmtp06.eigbox.net with esmtpsa (TLSv1:AES128-SHA:128)
(Exim) id 1TBYK6-0000bF-PZ; Tue, 11 Sep 2012 17:48:46 -0400
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\))
From: Matthew Mitchell <matthewmitchell@godofgod.co.uk>
In-Reply-To: <CAAS2fgSymOJ=cQnNwK9+nvRYszHHH4vtUpoQYWNNYoVaYB5Gpg@mail.gmail.com>
Date: Tue, 11 Sep 2012 22:48:43 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <19ED4257-0BCA-41C5-A533-B0AB9B500181@godofgod.co.uk>
References: <2104FC7F-0AE0-4C55-9987-B20EFCE19FC3@godofgod.co.uk>
<CAAS2fgSymOJ=cQnNwK9+nvRYszHHH4vtUpoQYWNNYoVaYB5Gpg@mail.gmail.com>
To: Gregory Maxwell <gmaxwell@gmail.com>,
"bitcoin-development@lists.sourceforge.net"
<bitcoin-development@lists.sourceforge.net>
X-Mailer: Apple Mail (2.1486)
X-EN-UserInfo: c68a83c59c94ef03b40bb4bc312c51e4:dffc0a9b4c8a0435ad832ff5852cab82
X-EN-AuthUser: godofgod@godofgod.co.uk
Sender: Matthew Mitchell <matthewmitchell@godofgod.co.uk>
X-EN-OrigIP: 109.175.173.22
X-EN-OrigHost: unknown
X-Spam-Score: 1.1 (+)
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
1.5 RCVD_IN_PSBL RBL: Received via a relay in PSBL
[66.96.188.16 listed in psbl.surriel.com]
-0.0 SPF_PASS SPF: sender matches SPF record
-0.3 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain 1.5 SF_NO_SPF_SPAM SF_NO_SPF_SPAM
X-Headers-End: 1TBYKC-0006qY-Ns
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 21:48:53 -0000
On 11 Sep 2012, at 20:42, Gregory Maxwell <gmaxwell@gmail.com> wrote:
> Someone can do that just by pipelining the one at a time requests.
> How much bandwidth do you think you could save over that?
You wouldn't need to pipeline the requests, just place more than one =
inventory vector in get data, right? Well my messages would save the =
space of those inventory vectors. Instead of needing 36 byte inventory =
vectors for each transaction and a var int, you would need two var ints =
only. And then the 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.
=20
> 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?
Well it depends on wether you seriously think bitcoin blocks should be =
limited at a million bytes or not.
> 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.
Look at bittorrent. With bittorrent you don't download files from a =
single peer all at once.
> Bitcoin gets its value through scarcity. There are two kinds of
> scarcity that are economically important, scarcity of the coins=97 =
there
> will never be more than 21 million=97 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.
Why wouldn't requesting minimum fees in the software work as is done =
currently?
> 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=97
> who the heck wants to possibly wait an hour to get a 1 confirm
> sodapop??).
So what you essentially suggest is having bitcoin banks that maintain =
trust through Open Transaction contracts which contains proof of =
agreement, providing some legal protection? One wonders why have bitcoin =
at all then? Why not have an elaborate e-money system between several =
banks using Open Transactions? 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?
I suppose when people consider bitcoin banks, they will consider bitcoin =
being useless.
> but I know that changing it is precisely as
> technically difficult as changing the 21 million limit
Set the change to occur at some block in the future leaving time for =
people to upgrade. Send out alert messages to notify users to upgrade. =
Issue is, some people might not like the change for whatever reasons.
As far as I see it, if bitcoin won't scale, then it's worth looking at =
something different to bitcoin that will scale.=
|
