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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from
<SRS0=nh6BJu=HM=godofgod.co.uk=matthewmitchell@eigbox.net>)
id 1TCA3a-0006FK-6e for bitcoin-development@lists.sourceforge.net;
Thu, 13 Sep 2012 14:06:14 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of eigbox.net
designates 66.96.186.17 as permitted sender)
client-ip=66.96.186.17;
envelope-from=SRS0=nh6BJu=HM=godofgod.co.uk=matthewmitchell@eigbox.net;
helo=bosmailout17.eigbox.net;
Received: from bosmailout17.eigbox.net ([66.96.186.17])
by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1TCA3U-0004I5-KM for bitcoin-development@lists.sourceforge.net;
Thu, 13 Sep 2012 14:06:14 +0000
Received: from bosmailscan12.eigbox.net ([10.20.15.12])
by bosmailout17.eigbox.net with esmtp (Exim) id 1TCA3P-0000Hx-2P
for bitcoin-development@lists.sourceforge.net;
Thu, 13 Sep 2012 10:06:03 -0400
Received: from bosimpout01.eigbox.net ([10.20.55.1])
by bosmailscan12.eigbox.net with esmtp (Exim)
id 1TCA3O-0001k9-Rd; Thu, 13 Sep 2012 10:06:02 -0400
Received: from bosauthsmtp17.eigbox.net ([10.20.18.17])
by bosimpout01.eigbox.net with NO UCE
id ye621j01g0N5uqq01e62o8; Thu, 13 Sep 2012 10:06:02 -0400
X-Authority-Analysis: v=2.0 cv=aPZHX8Bm c=1 sm=1
a=Vnyysazsc9gF4v5jbSvB8A==:17 a=Goz4v7xpImgA:10 a=JhU9KSwl1l8A:10
a=RmqW3wxksLsA:10 a=kj9zAlcOel0A:10 a=eGitJVp2AAAA:8 a=-aUnnjAAwhoA:10
a=t1VQV7EkAAAA:8 a=j4oatsTgFnEDZAen5aAA:9 a=CjuIK1q_8ugA:10
a=6m3agaRMXGwA:10 a=f4kFLigMKr8AH7rIJ//qJA==:117
X-EN-OrigOutIP: 10.20.18.17
X-EN-IMPSID: ye621j01g0N5uqq01e62o8
Received: from [109.175.173.27]
by bosauthsmtp17.eigbox.net with esmtpsa (TLSv1:AES128-SHA:128)
(Exim) id 1TCA3N-0002Cf-VL; Thu, 13 Sep 2012 10:06:02 -0400
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\))
From: Matthew Mitchell <matthewmitchell@godofgod.co.uk>
In-Reply-To: <CANEZrP0HHhSXyN9pWODtTxHMfRB4B0w-eSdvNHH13WwLVgECrw@mail.gmail.com>
Date: Thu, 13 Sep 2012 15:05:29 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <FC0AF926-2CBD-49BA-A3B7-AF9D70A83CE4@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>
<CAAS2fgRfXBrsFm_zdNFe7Z4FN7uQ5zSg++scng=hNrHZZV93VQ@mail.gmail.com>
<CANEZrP0HHhSXyN9pWODtTxHMfRB4B0w-eSdvNHH13WwLVgECrw@mail.gmail.com>
To: Mike Hearn <mike@plan99.net>, 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.27
X-EN-OrigHost: unknown
X-Spam-Score: -0.4 (/)
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 SPF_PASS SPF: sender matches SPF record
-0.5 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain 1.6 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1TCA3U-0004I5-KM
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: Thu, 13 Sep 2012 14:06:14 -0000
On 13 Sep 2012, at 09:42, Mike Hearn <mike@plan99.net> wrote:
> For what it's worth I disagree with Gregory on nearly all these
> points, so don't take it as some kind of consensus from the Bitcoin
> community ;)
>=20
> Matts change is reasonable but I think we all agree it has minimal
> impact at the moment relative to other things, so something even more
> complex than that seems like a non-starter. Bloom filtering is a lot
> more important.
Sure other things may be done before this, I was seeing this as a change =
somewhere down the line but not urgent.
@Gregory
> But you only need to request the transactions you don't have. Most of
> time you should already have almost all of the transactions.
Yes, my proposal allows you to do this. You skip out transactions your =
already have. My proposal is simply better than others because it takes =
full advantage of the merkle tree structure with minor additions that =
are simple to implement. How hard is it to get the hashes at a =
particular level of a merkle tree? Not hard at all. How hard is it to =
place a selection of transactions from a block into a message Not hard =
at all. Implementation of the protocol requirements would be a piece of =
cake. The harder bit would be to create an algorithm to determine the =
best level of segmentation but this is not required to comply with the =
protocol.
> Because there is no motivation not to set them to zero, if you don't
> someone else will
The motivation to incentivise miners and maintain stronger security? The =
difficulty only has to be high enough to prevent a cartel of malicious =
miners taking control of the network, something that is potentially a =
problem today with the large mining pools. Remember that the more =
transactions there are the more fees there can be for miners to collect. =
The more people that are using bitcoin, the greater bitcoins will be =
worth. A bigger network should be good for miners when relying on fees.
> 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.
If it's so controversial that it creates a split making two separated =
currencies then I'd see it turning out like the format wars (VHS vs =
Betamax and Blu-ray vs HD-DVD). Eventually people will move towards one =
or the other since it's better for people to have universalised =
agreement on a system.=
|
