summaryrefslogtreecommitdiff
path: root/35/0f6b5cd9be4fe3826b3c8701f531624b151bab
blob: a9df26ac9f7a07110da95def29cde84cbe38a731 (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
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <mark@monetize.io>) id 1WeIoe-0001tC-6Z
	for bitcoin-development@lists.sourceforge.net;
	Sun, 27 Apr 2014 06:43:56 +0000
Received: from mail-pa0-f51.google.com ([209.85.220.51])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1WeIoc-0002xA-QU
	for bitcoin-development@lists.sourceforge.net;
	Sun, 27 Apr 2014 06:43:56 +0000
Received: by mail-pa0-f51.google.com with SMTP id fb1so3995715pad.38
	for <bitcoin-development@lists.sourceforge.net>;
	Sat, 26 Apr 2014 23:43:48 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:organization:user-agent
	:mime-version:to:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=cyBziu0ANP7nndCd6e/LYpJrbdZVXnrEQjOz+6ZaZe4=;
	b=N63/EEcdMxCCXhLuWDPnnwQ2PsVMv2gmWo4apiTFE0ym6GclrD4Y7uUrQbMRwMIvOu
	XNS8+KChhU0xbmZ/gae4t80a+SruiNgq4oIYyhGAriSua6VCN+YWLz4BFv4Kqx+KGPRq
	4481rmhmAFF01zdCMm0d3s5DGFIwo+gT2zMk/FXdNYPg/ebNIhh1yf/hyXrnLErzvkbf
	vBBTbE44YDBglJwh48B8v34GHssyRFEYTMD1phyGkpSvRw9MX3CyJNKQIhFMILC7HSTb
	cKE8d6jBJKNAcluwvQ8+HPAQbDOqMxAgej1vjPeMNqMYt8yePrytTV6uzbJgnUj9Xen/
	lkFQ==
X-Gm-Message-State: ALoCoQnN6KAFAkgNK8gJkcUfm4Xh+yuiqPxQ8Si3dyFrbqIQWEdGEAFH041FSedG86jZU8V7Fd1f
X-Received: by 10.69.31.235 with SMTP id kp11mr18022341pbd.33.1398581028694;
	Sat, 26 Apr 2014 23:43:48 -0700 (PDT)
Received: from [192.168.127.189] (50-0-36-93.dsl.dynamic.sonic.net.
	[50.0.36.93]) by mx.google.com with ESMTPSA id
	nh8sm26613830pbc.25.2014.04.26.23.43.46
	for <bitcoin-development@lists.sourceforge.net>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Sat, 26 Apr 2014 23:43:47 -0700 (PDT)
Message-ID: <535CA722.1000704@monetize.io>
Date: Sat, 26 Apr 2014 23:43:46 -0700
From: Mark Friedenbach <mark@monetize.io>
Organization: Monetize.io Inc.
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <535C587F.90005@certimix.com> <535C60C8.5030605@monetize.io>
	<535C6DEC.9040505@certimix.com>
In-Reply-To: <535C6DEC.9040505@certimix.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
X-Headers-End: 1WeIoc-0002xA-QU
Subject: Re: [Bitcoin-development] About Compact SPV proofs via block header
 commitments
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: Sun, 27 Apr 2014 06:43:56 -0000

I don't think there's an official definition of "SPV proof." I wasn't
trying to make a argument "from definition" (that would be fallacious!).
Rather I suspected that we had different concepts in mind and wanted to
check.

That said, I do think that the definition I gave matches how the term is
used in the Satoshi whitepaper, and the way in which SPV clients like
BitcoinJ work. "Best chain" is typically taken to mean the most-work,
*valid* chain. Without invoking moon math or assumptions of honest peers
and jamming-free networks, the only way to know a chain is valid is to
witness the each and every block. SPV nodes on the other hand, simply
trust that the most-work chain is a valid chain, based on economic
arguments about the opportunity cost of mining invalid blocks. These SPV
nodes use block headers as proofs to determine the most-work block
connected to the genesis block or most recent checkpoint. So yes,
operationally at least this is what the community seems to mean by "SPV
proof".

Now regarding your use case:

> For the remaining peers, the client starts asking for parents blocks 
> until all parents agree (this is the last common parent).

This linear scan of block headers is what I would prefer to avoid. By
using back-links you make it have log(N) space usage.

On 04/26/2014 07:39 PM, Sergio Lerner wrote:
> El 26/04/2014 10:43 p.m., Mark Friedenbach escribió:
>> Sergio,
>> 
>> First of all, let's define what an SPV proof is: it is a succinct 
>> sequence of bits which can be transmitted as part of a 
>> non-interactive protocol that convincingly establishes for a
>> client without access to the block chain that for some block B, B
>> has an ancestor A at some specified height and work distance back,
>> and the cost of creating a false proof is at least as much work as
>> it claims to represent.
> Ok. I was thinking with another definition SPV proof.
> 
> For me a SPV proof is a sequence of bits which can be transmitted as
>  part of a non-interactive protocol that convincingly establishes
> for a client without access to the block chain that a block B is part
> of the best-chain.
> 
> I understand that SPV nodes require SPV proofs as defined in my 
> definition, but I can't realize how to prove that SPV nodes require 
> SPV proofs under your definition. So your definition sounds to me 
> like one possible solution, but not the need.
> 
> Is your definition something well-established in the community?
> 
> 
> 
> 
> ------------------------------------------------------------------------------
>
>
> 
Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software Java Based 
> Open Source Intranet - Social, Extensible, Cloud Ready Get Started 
> Now And Turn Your Intranet Into A Collaboration Platform 
> http://p.sf.net/sfu/ExoPlatform 
> _______________________________________________ Bitcoin-development 
> mailing list Bitcoin-development@lists.sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>