summaryrefslogtreecommitdiff
path: root/66/a5d44d8f1b24980ac2214d44570667df2a3c97
blob: c78983a54aee02f8ccf0616febc41d8e756c15ac (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
Return-Path: <natanael.l@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 07F78C88
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed,  3 May 2017 19:10:50 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-yw0-f182.google.com (mail-yw0-f182.google.com
	[209.85.161.182])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7EB4B192
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed,  3 May 2017 19:10:49 +0000 (UTC)
Received: by mail-yw0-f182.google.com with SMTP id 203so89946393ywe.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 03 May 2017 12:10:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc; bh=hrXPCRA1yDfCa9aOj6kKUu/tiwUGaB4A0/GEgak1Qwk=;
	b=ljZL/v/AxTSZngr8wtsD8eq7TWTA+Euy99K+lfL4ZAVe3rjvgayUejghakaejeKaU1
	L2wiAjSlDZWolKE+htaAA7Ad7nxaMdvQn+AgZxOpKDhAVOi/HjcHJdwajLoQXv5gG7D6
	vmG4N+TE+H72lzFNaj/Qqgav9DvyLMxGZoXchPv8z9EzC/DjRzlbEtHIb02YGf7RyYQt
	Xla0orqyDpQSAVvhTI+ezHpih5DoJs7t9A4wKd+P1Z0jj6GyynkZOjEriNCUPwvoRkqw
	KuSEnikvUVA7tIVoMh0/yv256QTkHSHWmLOwnpMmzgsPLEu7Jt/heXF+YPPFLc8wklHN
	RQnw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc;
	bh=hrXPCRA1yDfCa9aOj6kKUu/tiwUGaB4A0/GEgak1Qwk=;
	b=NP3YNgfv8Q//5N2wYodhtvp+M+vCYBbq1HYPdgOsFeVvwPTGD+0FrrVMe6mP83sn6K
	ZgEeyubrSj87kV37I88VljOywVy57YA1iGpsmonv2Mz8gWTMs0+j3vsSsyBjryJeSHDt
	4GIvB+tdeZXfai7eCvKVNkCg5tpU5QvgVNEaSJ0edu3EcBL2ohABI/3gEasjyloXdIgq
	l+8vWCDkL4/D7lzoTTTlUtjvbLc+V/gUvYR72kzFXk9EnOAz/7vv1bmnBKz3TeuUYJ63
	K837FM0AlVBo3Di7kZNReE/AMywOyRQqp6ijDmBqT2lAKJ4OT/ACnrRsfMD3uTRYk0te
	YKYA==
X-Gm-Message-State: AN3rC/4I1DLqxgwK1qfyHt4qDv5q8bdScGc5XCNiu9j3bKncPuOcA4m8
	j/LXaAXQ7TxkV82KoCCCOrl5o0W2ew==
X-Received: by 10.129.85.72 with SMTP id j69mr30870084ywb.220.1493838648721;
	Wed, 03 May 2017 12:10:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.35.88 with HTTP; Wed, 3 May 2017 12:10:47 -0700 (PDT)
Received: by 10.37.35.88 with HTTP; Wed, 3 May 2017 12:10:47 -0700 (PDT)
In-Reply-To: <CAJowKg+UTKeU0Dj5pJbtw+LZtO9kn5LBJum9Akd11zCsW+6o4Q@mail.gmail.com>
References: <CAFVRnypbQQ-vsSLqv48cYaqTCty4R1DmFRqfAvxe4mAqyQNXxQ@mail.gmail.com>
	<CAAS2fgT5pJh68xufv_81+N8K0asxH16WdX7PLLXGjRPmJOkYFQ@mail.gmail.com>
	<CAJowKg+UTKeU0Dj5pJbtw+LZtO9kn5LBJum9Akd11zCsW+6o4Q@mail.gmail.com>
From: Natanael <natanael.l@gmail.com>
Date: Wed, 3 May 2017 21:10:47 +0200
Message-ID: <CAAt2M1_TH=1Xw=65QxxCHMZzE-fzC3UhRaEk+KkKY2SHkN6CbQ@mail.gmail.com>
To: Erik Aronesty <erik@q32.com>
Content-Type: multipart/alternative; boundary=001a113f1bbe0260e2054ea36a4e
X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE, 
	RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Small Nodes: A Better Alternative to Pruned Nodes
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 03 May 2017 19:10:50 -0000

--001a113f1bbe0260e2054ea36a4e
Content-Type: text/plain; charset=UTF-8

Den 3 maj 2017 16:05 skrev "Erik Aronesty via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org>:

> But as you've observed, the failure probabilities are rather high,
> especially if an active attacker targets nodes carrying less commonly
> available blocks.

Wouldn't the solution be for nodes to use whatever mechanism an attacker
uses to determine less commonly available blocks and choose to store a
random percentage of them as well as their deterministic random set?

IE X blocks end of chain (spv bootstrap), Y% deterministic random set,  Z%
patch/fill set to deter attacks


Then he uses Sybil attacks to obscure what's actually rare and not. Even
proof of storage isn't enough, you need proof of INDEPENDENT storage, which
is essentially impossible, as well as a way of determining which nodes are
run by the same people (all the AWS nodes should essentially count as one).

--001a113f1bbe0260e2054ea36a4e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div data-smartmail=3D"gmail_signature" dir=3D"auto"><br>=
</div><div class=3D"gmail_extra" dir=3D"auto"><div class=3D"gmail_quote">De=
n 3 maj 2017 16:05 skrev &quot;Erik Aronesty via bitcoin-dev&quot; &lt;<a h=
ref=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linu=
xfoundation.org</a>&gt;:<br type=3D"attribution"><blockquote class=3D"quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><=
div dir=3D"ltr"><div><div class=3D"quoted-text"><div>&gt; But as you&#39;ve=
 observed, the failure probabilities are rather high,<br>&gt; especially if=
 an active attacker targets nodes carrying less commonly<br>&gt; available =
blocks.=C2=A0 <br><br></div></div>Wouldn&#39;t the solution be for nodes to=
 use whatever mechanism an attacker uses to determine less commonly availab=
le blocks and choose to store a random percentage of them as well as their =
deterministic random set?=C2=A0 <br><br>IE X blocks end of chain (spv boots=
trap), Y% deterministic random set,=C2=A0 Z% patch/fill set to deter attack=
s<br></div></div></blockquote></div></div><div dir=3D"auto"><br></div><div =
dir=3D"auto">Then he uses Sybil attacks to obscure what&#39;s actually rare=
 and not. Even proof of storage isn&#39;t enough, you need proof of INDEPEN=
DENT storage, which is essentially impossible, as well as a way of determin=
ing which nodes are run by the same people (all the AWS nodes should essent=
ially count as one).=C2=A0</div><div class=3D"gmail_extra" dir=3D"auto"><di=
v class=3D"gmail_quote"><blockquote class=3D"quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></di=
v></div></blockquote></div></div></div>

--001a113f1bbe0260e2054ea36a4e--