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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1SUhNX-00042U-DA
for bitcoin-development@lists.sourceforge.net;
Wed, 16 May 2012 16:47:11 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.175 as permitted sender)
client-ip=74.125.82.175; envelope-from=mh.in.england@gmail.com;
helo=mail-we0-f175.google.com;
Received: from mail-we0-f175.google.com ([74.125.82.175])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1SUhNR-0004nw-VY
for bitcoin-development@lists.sourceforge.net;
Wed, 16 May 2012 16:47:11 +0000
Received: by werg55 with SMTP id g55so811348wer.34
for <bitcoin-development@lists.sourceforge.net>;
Wed, 16 May 2012 09:46:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.207.151 with SMTP id n23mr2448089weo.100.1337186819787;
Wed, 16 May 2012 09:46:59 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.216.80.31 with HTTP; Wed, 16 May 2012 09:46:59 -0700 (PDT)
In-Reply-To: <1337186094.12490.YahooMailNeo@web121005.mail.ne1.yahoo.com>
References: <1337186094.12490.YahooMailNeo@web121005.mail.ne1.yahoo.com>
Date: Wed, 16 May 2012 18:46:59 +0200
X-Google-Sender-Auth: HOWLbO8LaNbNVIl6kDOq26DjX2c
Message-ID: <CANEZrP1t-xhHqJ0xGQwxxx-ddtRh7jtn9Yhcau2prKNt+PZHgw@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Amir Taaki <zgenjix@yahoo.com>
Content-Type: multipart/alternative; boundary=0016e6d622c8644a6004c02a117d
X-Spam-Score: -0.5 (/)
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
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
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
X-Headers-End: 1SUhNR-0004nw-VY
Cc: "bitcoin-development@lists.sourceforge.net"
<bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] BIP 33 - Stratized Nodes
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: Wed, 16 May 2012 16:47:11 -0000
--0016e6d622c8644a6004c02a117d
Content-Type: text/plain; charset=UTF-8
Thanks for getting this started.
With regards to the specific proposal, I don't believe it's the best option
and still plan to eventually implement the original design outlined more
than a year ago in this thread:
https://bitcointalk.org/index.php?topic=7972.msg116285#msg116285
Namely that you use a new protocol command to set a Bloom filter on a
connection. Only transactions matching that filter will appear in relayed
inventory. Blocks that are requested will arrive as a header plus
transaction/merkle branch pairs. Clients are expected to maintain and track
the block chain as per usual, but instead of downloading the whole chain
and then dropping the irrelevant transactions, that filtering is done
server side. By strengthening or weakening the Bloom filters you can choose
your preferred point on the privacy/bandwidth-usage spectrum. It is a
fairly simple change to the Satoshi and BitcoinJ codebases but still allows
clients to gain confidence in their balance by examining the chain, and
this is true even in the presence of a hijacked internet connection (you
can't trust pending transactions that way, but you can still trust
confirmed transactions).
The filters would be applied to each data block in each script rather than
having a specific knowledge of addresses. In this way you can select for
things like multisig outputs or outputs which don't use addresses / pubkeys
to authenticate.
I could write a BIP for this alternative protocol if somebody else wants to
implement it. I was going to wait until I had time to do both BIP and
implementation, but I think some simple optimizations to BitcoinJ can keep
its performance good enough for the short term.
--0016e6d622c8644a6004c02a117d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Thanks for getting this started.=C2=A0<div><br></div><div>With regards to t=
he specific proposal, I don't believe it's the best option and stil=
l plan to eventually implement the original design outlined more than a yea=
r ago in this thread:</div>
<div><br></div><div>=C2=A0=C2=A0<a href=3D"https://bitcointalk.org/index.ph=
p?topic=3D7972.msg116285#msg116285">https://bitcointalk.org/index.php?topic=
=3D7972.msg116285#msg116285</a></div><div><br></div><div>Namely that you us=
e a new protocol command to set a Bloom filter on a connection. Only transa=
ctions matching that filter will appear in relayed inventory. Blocks that a=
re requested will arrive as a header plus transaction/merkle branch pairs. =
Clients are expected to maintain and track the block chain as per usual, bu=
t instead of downloading the whole chain and then dropping the irrelevant t=
ransactions, that filtering is done server side. By strengthening or weaken=
ing the Bloom filters you can choose your preferred point on the privacy/ba=
ndwidth-usage spectrum. It is a fairly simple change to the Satoshi and Bit=
coinJ codebases but still allows clients to gain confidence in their balanc=
e by examining the chain, and this is true even in the presence of a hijack=
ed internet connection (you can't trust pending transactions that way, =
but you can still trust confirmed transactions).</div>
<div><br></div><div>The filters would be applied to each data block in each=
script rather than having a specific knowledge of addresses. In this way y=
ou can select for things like multisig outputs or outputs which don't u=
se addresses / pubkeys to authenticate.</div>
<div><br></div><div>I could write a BIP for this alternative protocol if so=
mebody else wants to implement it. I was going to wait until I had time to =
do both BIP and implementation, but I think some simple optimizations to Bi=
tcoinJ can keep its performance good enough for the short term.</div>
--0016e6d622c8644a6004c02a117d--
|
