summaryrefslogtreecommitdiff
path: root/01/8a460fd8408a1b16fd54231a29fd419958b8a1
blob: c59a6c9874e219b039e21bd7a86783fb3f70d498 (plain)
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--