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
|
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 <tier.nolan@gmail.com>) id 1Wh3h7-0007mf-Se
for bitcoin-development@lists.sourceforge.net;
Sun, 04 May 2014 21:11:33 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.192.51 as permitted sender)
client-ip=209.85.192.51; envelope-from=tier.nolan@gmail.com;
helo=mail-qg0-f51.google.com;
Received: from mail-qg0-f51.google.com ([209.85.192.51])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Wh3h6-0004ti-W2
for bitcoin-development@lists.sourceforge.net;
Sun, 04 May 2014 21:11:33 +0000
Received: by mail-qg0-f51.google.com with SMTP id q107so2519037qgd.10
for <bitcoin-development@lists.sourceforge.net>;
Sun, 04 May 2014 14:11:27 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.229.112.5 with SMTP id u5mr39166804qcp.3.1399237887300; Sun,
04 May 2014 14:11:27 -0700 (PDT)
Received: by 10.140.25.86 with HTTP; Sun, 4 May 2014 14:11:27 -0700 (PDT)
In-Reply-To: <CAAS2fgS3cU4-yJMSMA4TSY4_mrw53d--543OVmize2BYVjUAqQ@mail.gmail.com>
References: <CA+s+GJCn9U2kmyMH6w3o+m99NCfO0ws=SccvGBYJv07WVuF=eA@mail.gmail.com>
<CAAt2M18z_Qkqat1OETiXAz0QQey4+y5J6=pC7nkoJfyfrpj3=A@mail.gmail.com>
<CAAS2fgScWkentFy7Ak0bpYVLsOFL+xkwPm5QRu9ENeX9oCtPug@mail.gmail.com>
<534570A2.9090502@gmx.de>
<CA+s+GJAXu3SEXFDDwi85dNFjO2rfPXJrg-aKHYwbogAHfu3vfQ@mail.gmail.com>
<0B038624-8861-438E-B7B1-566B4A8E126B@bitsofproof.com>
<CA+s+GJCQSCUyq7Ajv0EgZ8Vbcv4Xt7G-y_8D12fsoKjyFjnhwg@mail.gmail.com>
<CAPg+sBjWL_hKhWW-6i=WAHnx+Ue5JE=A9RrxnWuAYOXw19qiDw@mail.gmail.com>
<CAAS2fgTkgddRGGXuuAza-A=Dgjfr5aNF8yxDePPixN4M7Rbpyg@mail.gmail.com>
<c3726067-5a9f-45b9-b798-1070bdde2ac4@email.android.com>
<CAE-z3OV4w+vQ0b6h9E+7cSyxkKENduyfHenhdF3q3-0i2chnGQ@mail.gmail.com>
<CAAS2fgS3cU4-yJMSMA4TSY4_mrw53d--543OVmize2BYVjUAqQ@mail.gmail.com>
Date: Sun, 4 May 2014 22:11:27 +0100
Message-ID: <CAE-z3OXw8-3ezMOL4ik1hgDJ1sXioXHot6KgRT6rx+U67Jxhng@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=001a11330a743ab37104f899751c
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [209.85.192.51 listed in list.dnswl.org]
-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
(tier.nolan[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-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: 1Wh3h6-0004ti-W2
Subject: Re: [Bitcoin-development] Bitcoind-in-background mode for SPV
wallets
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, 04 May 2014 21:11:34 -0000
--001a11330a743ab37104f899751c
Content-Type: text/plain; charset=UTF-8
On Fri, Apr 11, 2014 at 5:54 PM, Gregory Maxwell <gmaxwell@gmail.com> wrote:
> For the non-error-coded case I believe nodes
> with random spans of blocks works out asymptotically to the same
> failure rates as random.
>
If each "block" is really 512 blocks in sequence, then each "slot" is more
likely to be hit. It effectively reduces the number of blocks by the
minimum run lengths.
ECC seemed cooler though.
> (The conversation Peter Todd was referring to was one where I was
> pointing out that with suitable error coding you also get an
> anti-censorship effect where its very difficult to provide part of the
> data without potentially providing all of it)
>
Interesting too.
>
> I think in the network we have today and for the foreseeable future we
> can reasonably count on there being a reasonable number of nodes that
> store all the blocks... quite likely not enough to satisfy the
> historical block demand from the network alone, but easily enough to
> supply blocks that have otherwise gone missing.
>
That's true. Scaling up the transactions per second increases the chance
of data lost.
With side/tree chains, the odds of data loss in the less important chains
increases (though they are by definition lower value chains)
--001a11330a743ab37104f899751c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Fri, Apr 11, 2014 at 5:54 PM, Gregory Maxwell <span dir=
=3D"ltr"><<a href=3D"mailto:gmaxwell@gmail.com" target=3D"_blank">gmaxwe=
ll@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi=
ng-left:1ex">
For the non-error-coded case I believe nodes<br>
with random spans of blocks works out asymptotically to the same<br>
failure rates as random.<br></blockquote><div><br></div><div>If each=20
"block" is really 512 blocks in sequence, then each "slot&qu=
ot; is more=20
likely to be hit.=C2=A0 It effectively reduces the number of blocks by the=
=20
minimum run lengths.<br><br></div><div>ECC seemed cooler though.<br></div><=
div>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
(The conversation Peter Todd was referring to was one where I was<br>
pointing out that with suitable error coding you also get an<br>
anti-censorship effect where its very difficult to provide part of the<br>
data without potentially providing all of it)<br></blockquote><div><br></di=
v><div>Interesting too.<br></div><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le=
ft:1ex">
<div class=3D""><br>
</div>I think in the network we have today and for the foreseeable future w=
e<br>
can reasonably count on there being a reasonable number of nodes that<br>
store all the blocks... quite likely not enough to satisfy the<br>
historical block demand from the network alone, but easily enough to<br>
supply blocks that have otherwise gone missing.<br></blockquote><div><br></=
div><div>That's true.=C2=A0 Scaling up the transactions per second incr=
eases the chance of data lost.<br><br>With
side/tree chains, the odds of data loss in the less important chains=20
increases (though they are by definition lower value chains)<br></div></div=
>
--001a11330a743ab37104f899751c--
|
