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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <peter@coinlab.com>) id 1SUhQ6-0004DH-12
for bitcoin-development@lists.sourceforge.net;
Wed, 16 May 2012 16:49:50 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of coinlab.com
designates 209.85.214.175 as permitted sender)
client-ip=209.85.214.175; envelope-from=peter@coinlab.com;
helo=mail-ob0-f175.google.com;
Received: from mail-ob0-f175.google.com ([209.85.214.175])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1SUhQ0-00020l-Ky
for bitcoin-development@lists.sourceforge.net;
Wed, 16 May 2012 16:49:50 +0000
Received: by obhx4 with SMTP id x4so1645857obh.34
for <bitcoin-development@lists.sourceforge.net>;
Wed, 16 May 2012 09:49:39 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=google.com; s=20120113;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc:content-type:x-gm-message-state;
bh=LzYREj8qrhn/C+uyLspXwMS6UBzSEvoNZKXgy0+jZ0Q=;
b=pxPUgTzUjt8TSXZjjFWMu+P+DqWYoQpqFeaOe5rPaTNN8lmTy8Z/6V86eDDhtnFa0W
JKIxlY1ehIdsLqpnDQcD8RjnAeHv3Vbmd9NvRSpXdgzshc+yRH5kzuboJzwreak1m4+j
YNR33qjxAVd1OG5jffsC9ye+dVflyu362ncG+JL/LCjeUTdxsj1L+RktKljUfJRyI5vS
oVyfjVmJQa+RXtHaDC2F07ZyXIjMkPAgDzSlu8bM5JHv3g4r3wPl+ybdn1g+DQ8Nf+D3
Mzc4kdyMWzzqZNVPwY9dkbwdTpklRZzc+qgNGD7B0QM/kz8/lJWt8PLX05hSGilNPsFT
WdDQ==
Received: by 10.182.119.101 with SMTP id kt5mr3388331obb.70.1337186979056;
Wed, 16 May 2012 09:49:39 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.35.227 with HTTP; Wed, 16 May 2012 09:49:18 -0700 (PDT)
In-Reply-To: <1337186094.12490.YahooMailNeo@web121005.mail.ne1.yahoo.com>
References: <1337186094.12490.YahooMailNeo@web121005.mail.ne1.yahoo.com>
From: Peter Vessenes <peter@coinlab.com>
Date: Wed, 16 May 2012 09:49:18 -0700
Message-ID: <CAMGNxUuPYYtTB=aOyQjb7Gw=RZODFry=7DWkWST0EN_67rjK8g@mail.gmail.com>
To: Amir Taaki <zgenjix@yahoo.com>
Content-Type: multipart/alternative; boundary=f46d0444ee1fe28bcd04c02a1a38
X-Gm-Message-State: ALoCoQnnDhSrzns/zw7/5YN60diojZq9PUkOc9/uHaaCmSKvBVGXDWAP1+gBf3qG/NA2sqdn9KhH
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 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
X-Headers-End: 1SUhQ0-00020l-Ky
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:49:50 -0000
--f46d0444ee1fe28bcd04c02a1a38
Content-Type: text/plain; charset=ISO-8859-1
Thanks for this, Amir.
My initial reactions:
1) This is cool and useful (but see 3)
2) This is significantly less secure than validating an entire blockchain;
it's certainly worth working out some use cases here in more detail than
just a sample conversation. More on this below
3) What about discovery? Will a client now have the chance to look for
NODE_STRATIZED clients on IRC? How do you envision a stratized server
decides which transactions to relay/store? Or is it just a caching layer in
front of a high quality blockchain service? If it is just a caching
service, the question of cache hits / misses is an interesting one as well.
4) What are the economic motivations to run a stratized server? Other than
cheating people of course.
5) Seems like a 'send me everything for this source address' is going to
save a lot of roundtrip conversations for what I imagine the most common
request will be.
Inre: majority agreement on transactions, and even balances, it would be
nice to work out some theoretical security / cost / value calculations for
the following scenarios:
Likely value and cost to someone of subverting / lying about
1) An n-confirmation transaction, n > 0
2) A 0 confirmation transaction
3) A NODE_STRATIZED transaction chain for a client with m connections to
NODE_STRATIZED servers
4) An address balance request for a client with m connections to
NODE_BALANCE_INFO (I made this name up) servers
Peter
--f46d0444ee1fe28bcd04c02a1a38
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div>Thanks for this, Amir.
</div><div><br></div><div>My initial reactions:</div><div><br></div><div>1)=
This is cool and useful (but see 3)</div><div>2) This is significantly les=
s secure than validating an entire blockchain; it's certainly worth wor=
king out some use cases here in more detail than just a sample conversation=
. More on this below</div>
<div>3) What about discovery? Will a client now have the chance to look for=
NODE_STRATIZED clients on IRC? How do you envision a stratized server deci=
des which transactions to relay/store? Or is it just a caching layer in fro=
nt of a high quality blockchain service? If it is just a caching service, t=
he question of cache hits / misses is an interesting one as well.=A0</div>
<div>4) What are the economic motivations to run a stratized server? Other =
than cheating people of course.</div><div>5) Seems like a 'send me ever=
ything for this source address' is going to save a lot of roundtrip con=
versations for what I imagine the most common request will be.</div>
<div><br></div><div>Inre: majority agreement on transactions, and even bala=
nces, it would be nice to work out some theoretical security / cost / value=
calculations for the following scenarios:</div><div><br></div><div>Likely =
value and cost to someone of subverting / lying about</div>
<div>1) An n-confirmation transaction, n > 0</div><div>2) A 0 confirmati=
on transaction</div><div>3) A NODE_STRATIZED transaction chain for a client=
with m connections to NODE_STRATIZED servers</div><div>4) An address balan=
ce request for a client with m connections to NODE_BALANCE_INFO (I made thi=
s name up) servers</div>
<div><br></div><div>Peter</div>
--f46d0444ee1fe28bcd04c02a1a38--
|
