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
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <sergiolerner@certimix.com>) id 1WdY7h-0007p2-6b
for bitcoin-development@lists.sourceforge.net;
Fri, 25 Apr 2014 04:52:29 +0000
X-ACL-Warn:
Received: from p3plsmtpa06-04.prod.phx3.secureserver.net ([173.201.192.105])
by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1WdY7d-0000s9-Lz for bitcoin-development@lists.sourceforge.net;
Fri, 25 Apr 2014 04:52:29 +0000
Received: from [192.168.1.101] ([190.19.169.149])
by p3plsmtpa06-04.prod.phx3.secureserver.net with
id u4sH1n0053DkUH2014sJNm; Thu, 24 Apr 2014 21:52:19 -0700
Message-ID: <5359EA1C.6050404@certimix.com>
Date: Fri, 25 Apr 2014 01:52:44 -0300
From: Sergio Lerner <sergiolerner@certimix.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
X-Enigmail-Version: 1.6
Content-Type: multipart/alternative;
boundary="------------020202060900050109070904"
X-Spam-Score: 1.0 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
1.0 HTML_MESSAGE BODY: HTML included in message
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [173.201.192.105 listed in list.dnswl.org]
X-Headers-End: 1WdY7d-0000s9-Lz
Subject: [Bitcoin-development] =?windows-1252?q?SmartSPV_=96_A_better_Simp?=
=?windows-1252?q?lified_Payment_Verification_for_Smartphones?=
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: Fri, 25 Apr 2014 04:52:29 -0000
This is a multi-part message in MIME format.
--------------020202060900050109070904
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
In a previous e-mail Mike Hearn asked me how I was going to handle 17K
block headers a day in my NimbleCoin currency in a the SPV mode.
I designed a variation of the standard headers-only SPV mode I called
SmartSPV. This mode could also be implemented by BitcoinJ for Bitcoin.
The method is explained here:
http://bitslog.wordpress.com/2014/04/25/smartspv-a-better-simplified-payment-verification-for-smartphones/
But I copy the whole blog post in this e-mail so you don't need to click
on it.
SmartSPV – A better Simplified Payment Verification for Smartphones
NimbleCoin <http://NimbleCoin.com> is a new cryptocurrency I’ll be
hopefully launching soon. One of its nice features is that it uses the
FastBlock5
<http://bitslog.wordpress.com/2014/02/17/5-sec-block-interval/> protocol
(a 5 seconds block interval) to achieve near instant payments. Because
NimbleCoin also implements merged mining
<http://bitslog.wordpress.com/2014/02/20/safe-merged-mining/>, each
block header can be as large as 700 bytes (including Merkle branch and
coinbase transaction). Yesterday Mike Hearn asked my a difficult
question: how would NimbleCoin SPV nodes (such as the ones running on
smartphones) process tons of headers if the bandwidth is limited or the
clients are disconnected from the Internet for long periods?
The answer is Smart-SPV, a variation of the standard SPV headers-only
<https://en.bitcoin.it/wiki/Thin_Client_Security> mode that allows a
smartphone to keep a fairly accurate state of the wallet balance without
downloading all the missing headers and without sacrificing battery life
and time.
Headers-only SPV clients
<http://bitcoin.stackexchange.com/questions/11054/understanding-spv-simple-payment-verification>
downloads a complete copy of the headers for all blocks in the entire
blockchain but not all the transactions. In order to update the user
wallet, SPV clients ask their peers to filter those blocks that contains
transactions that the SPV is interested in, such as those that have
payments to their own bitcoin addresses. This is done using bloom
filters <https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki>.
In Smart-SPV mode, when a client is missing block headers two things
happen simultaneously:
1. The client starts downloading block headers from the last one solved
backwards.
2. The client starts downloading the blocks headers from the first
missing header, forward.
While the client catches up with all the missing blocks, the wallet
balance may not be fully reliable. Nevertheless if a new payment is
received and confirmed, or a new payment is made, the wallet will
increased the balance and show it. This is what the user expects.
*How it works*
A live block is a block which is the last block of the block-chain and
it’s received on time (it has a time-stamp near the current time). Each
time a live block is received, it is flagged as LIVE and this flag is
stored permanently with the block. A live transaction is a transaction
that is included in a live block. When a live transaction is confirmed
by 6 blocks flagged as LIVE the transaction is considered mature. A
mature transaction may be included in a block that is still orphan. All
mature transactions are scanned and used to compute the balance of the
wallet. Also all transactions that are included in blocks rooted at the
last checkpoint and finishing in the last live block are also considered
mature (this is the standard condition). Since the wallet always
modifies the balance according to mature transactions, an payment is
received and acknowledged even if the branch where it is included is
still orphaned. If the SPV client clock is correctly synchronized, the
Smart-SPV protocol does not pose any additional security risk different
from the known SPV limitations.
--------------020202060900050109070904
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
In a previous e-mail Mike Hearn asked me how I was going to handle
17K block headers a day in my NimbleCoin currency in a the SPV mode.<br>
I designed a variation of the standard headers-only SPV mode I
called SmartSPV. This mode could also be implemented by BitcoinJ for
Bitcoin.<br>
<br>
The method is explained here:
<a class="moz-txt-link-freetext" href="http://bitslog.wordpress.com/2014/04/25/smartspv-a-better-simplified-payment-verification-for-smartphones/">http://bitslog.wordpress.com/2014/04/25/smartspv-a-better-simplified-payment-verification-for-smartphones/</a><br>
<br>
But I copy the whole blog post in this e-mail so you don't need to
click on it.<br>
<br>
<h2 class="title">SmartSPV – A better Simplified Payment
Verification for Smartphones</h2>
<p><a href="http://NimbleCoin.com">NimbleCoin</a> is a new
cryptocurrency I’ll be hopefully launching soon. One of its nice
features is that it uses the <a
href="http://bitslog.wordpress.com/2014/02/17/5-sec-block-interval/">FastBlock5</a>
protocol (a 5 seconds block interval) to achieve near instant
payments. Because NimbleCoin also implements <a
href="http://bitslog.wordpress.com/2014/02/20/safe-merged-mining/">merged
mining</a>, each block header can be as large as 700 bytes
(including Merkle branch and coinbase transaction). Yesterday Mike
Hearn asked my a difficult question: how would NimbleCoin SPV
nodes (such as the ones running on smartphones) process tons of
headers if the bandwidth is limited or the clients are
disconnected from the Internet for long periods?</p>
<p>The answer is Smart-SPV, a variation of the standard <a
href="https://en.bitcoin.it/wiki/Thin_Client_Security">SPV
headers-only</a> mode that allows a smartphone to keep a fairly
accurate state of the wallet balance without downloading all the
missing headers and without sacrificing battery life and time.</p>
<p><a
href="http://bitcoin.stackexchange.com/questions/11054/understanding-spv-simple-payment-verification">Headers-only
SPV clients</a> downloads a complete copy of the headers for all
blocks in the entire blockchain but not all the transactions. In
order to update the user wallet, SPV clients ask their peers to
filter those blocks that contains transactions that the SPV is
interested in, such as those that have payments to their own
bitcoin addresses. This is done using <a
href="https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki">bloom
filters</a>.</p>
<p>In Smart-SPV mode, when a client is missing block headers two
things happen simultaneously:</p>
<p>1. The client starts downloading block headers from the last one
solved backwards.</p>
<p>2. The client starts downloading the blocks headers from the
first missing header, forward.</p>
<p>While the client catches up with all the missing blocks, the
wallet balance may not be fully reliable. Nevertheless if a new
payment is received and confirmed, or a new payment is made, the
wallet will increased the balance and show it. This is what the
user expects.</p>
<p><strong>How it works</strong></p>
<p>A live block is a block which is the last block of the
block-chain and it’s received on time (it has a time-stamp near
the current time). Each time a live block is received, it is
flagged as LIVE and this flag is stored permanently with the
block. A live transaction is a transaction that is included in a
live block. When a live transaction is confirmed by 6 blocks
flagged as LIVE the transaction is considered mature. A mature
transaction may be included in a block that is still orphan. All
mature transactions are scanned and used to compute the balance of
the wallet. Also all transactions that are included in blocks
rooted at the last checkpoint and finishing in the last live block
are also considered mature (this is the standard condition). Since
the wallet always modifies the balance according to mature
transactions, an payment is received and acknowledged even if the
branch where it is included is still orphaned. If the SPV client
clock is correctly synchronized, the Smart-SPV protocol does not
pose any additional security risk different from the known SPV
limitations.</p>
<br>
<br>
<br>
<br>
<br>
</body>
</html>
--------------020202060900050109070904--
|
