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
|
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 <sergiolerner@certimix.com>) id 1Yd8h1-0000sd-Qh
for bitcoin-development@lists.sourceforge.net;
Wed, 01 Apr 2015 02:47:47 +0000
X-ACL-Warn:
Received: from p3plsmtpa08-07.prod.phx3.secureserver.net ([173.201.193.108])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES128-SHA:128)
(Exim 4.76) id 1Yd8gz-0007V9-Ty
for bitcoin-development@lists.sourceforge.net;
Wed, 01 Apr 2015 02:47:47 +0000
Received: from [192.168.0.23] ([190.17.239.92])
by p3plsmtpa08-07.prod.phx3.secureserver.net with
id ASaz1q00720JPBy01Sb424; Tue, 31 Mar 2015 19:35:06 -0700
Message-ID: <551B5950.3030603@certimix.com>
Date: Tue, 31 Mar 2015 23:34:56 -0300
From: Sergio Lerner <sergiolerner@certimix.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Jeremy Spilman <jeremy@taplink.co>,
bitcoin-development <bitcoin-development@lists.sourceforge.net>
References: <55034205.4030607@localhost.local>
<7854077.3GbzoT9yL1@crushinator> <f903ef03dc8bb30873e0bbbb9b3786e9@webmail.mckay.com> <2210650.iUsfZECcCc@crushinator>
<2B8DBE05-E38E-433F-A4D2-A6D93D2FD4AA@taplink.co>
In-Reply-To: <2B8DBE05-E38E-433F-A4D2-A6D93D2FD4AA@taplink.co>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
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 [173.201.193.108 listed in list.dnswl.org]
X-Headers-End: 1Yd8gz-0007V9-Ty
Subject: Re: [Bitcoin-development] "network disruption as a service" and
proof of local storage
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, 01 Apr 2015 02:47:47 -0000
Matt is right: the goal is to prove digital copies of a public file.
Nothing more, nothing less.
Regarding the IP, I don't claim that every machine should provide the
protocol. Mobiles phones shouldn't. But machines that what to be
prioritized in some way or that want to be rewarded for hosting a node
should use a fixed IP. That's the cost of prioritization/reward. The
protocol could be a service bit, advertised in the version message.
My response to your comment below:
On 27/03/2015 03:40 p.m., Jeremy Spilman wrote:
>
> It would be extremely impressive to achieve a reliable mechanism for di=
scerning a local copy exists under these constraints, particularly withou=
t false positives and false negatives, and without imposing very substant=
ial one-time encoding costs, e.g. on par with doubling the verification c=
ost.=20
I see it differently. The asymmetric-time protocol is quite reliable. If
can be made to have almost no false positives/false negatives (not
considering rare communication problems, such as congestion and packet
loss for more than 5 seconds).
These are my back-of-the-envelope calculations:
Bitcoind takes approximately 1 second to serve a 1 Mb block (seek time,
but mostly transfer time)
Then decryption of a block can take 150 msec without problem (15%
overhead). The last N blocks could be cached so they don't need to be
decrypted to be sent.
In 150 msec a PC can decrypt a 1MB of data split over 1024-bit blocks
decrypted by modexp 3 (0.2 msec for 3 bigint multiplications), so a full
block can be decrypted.
Encrypting such block would take approximately 15 seconds (which is much
less than the 10 minutes available to encrypt each block)
Then the protocol works with a security margin of approximately 50x.
A communication problem during 5 seconds would be needed to disturb a
protocol of that takes 100 msec for the prover.
Regards,
Sergio.
|
