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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1TfyIR-00028z-Fm
for bitcoin-development@lists.sourceforge.net;
Tue, 04 Dec 2012 19:36:47 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.210.169 as permitted sender)
client-ip=209.85.210.169; envelope-from=gmaxwell@gmail.com;
helo=mail-ia0-f169.google.com;
Received: from mail-ia0-f169.google.com ([209.85.210.169])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1TfyIO-0006Ei-Ps
for bitcoin-development@lists.sourceforge.net;
Tue, 04 Dec 2012 19:36:47 +0000
Received: by mail-ia0-f169.google.com with SMTP id r4so3907623iaj.14
for <bitcoin-development@lists.sourceforge.net>;
Tue, 04 Dec 2012 11:36:39 -0800 (PST)
MIME-Version: 1.0
Received: by 10.50.57.200 with SMTP id k8mr3960276igq.29.1354649799418; Tue,
04 Dec 2012 11:36:39 -0800 (PST)
Received: by 10.64.171.73 with HTTP; Tue, 4 Dec 2012 11:36:39 -0800 (PST)
In-Reply-To: <CACh7GpHUE2CYAMfRdAVPv1WAk102z94KYCWPV87fzzQEaP_hfw@mail.gmail.com>
References: <CANEZrP3=GdyTe+2=cp-ROOJ8_t=yCqO-7GQ4hA-3aksg46p+ww@mail.gmail.com>
<CACh7GpHUE2CYAMfRdAVPv1WAk102z94KYCWPV87fzzQEaP_hfw@mail.gmail.com>
Date: Tue, 4 Dec 2012 14:36:39 -0500
Message-ID: <CAAS2fgSGa3HJcZVi1QS8qpsypvtxhLLZmAseVyx9UkbRPh36CA@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Mark Friedenbach <mark@monetize.io>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.6 (-)
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
(gmaxwell[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
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: 1TfyIO-0006Ei-Ps
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Roadmap to getting users onto SPV clients
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, 04 Dec 2012 19:36:47 -0000
On Tue, Dec 4, 2012 at 1:57 PM, Mark Friedenbach <mark@monetize.io> wrote:
> Alan's
:(
> UTxO meta-chain proposal becomes vastly easier to do now that
> ultraprune is merged.
No, not really. Somewhat easier due to some structural changes, but it
still needs to invent and get consensus on a normative data structure
and people need to write implementations of the required operations on
it (implementations probably required to prove performance for
consensus). We still have to sort through the tradeoff of making a
_single_ data structure the normative merkle tree representation for
the UTxO set to the preclusion of other implementations=E2=80=94 including
ones which are asymptotically faster, such as a straight hash table.
There are also issues that need to be sorted out like key structure=E2=80=
=94
the most useful index for validation is txid:vout keyed, but Alan
wanted 'address' prefixed, which is not friendly for validation but
enables robust query by address=E2=80=94 a query that the referce normal
bitcoin software doesn't even optionally support right now. Any
disagreements on this point must be hammed out because the structure
would be normative.
> That would allow the Satoshi client to know it's
> wallet balance and operate with a >=3DSPV level of security during the in=
itial
> block download, and keep them on the path of becoming a full node. If use=
rs
> can see their balances, send and receive transactions, and otherwise go
> about their business (except for mining) during the initial block downloa=
d,
> would that not address your concerns?
The above said, that is all good stuff too. And I do thing starting
fast with reduced security (be it to SPV+ or SPV) is a good idea.
|
