From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 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 , bitcoin-development References: <55034205.4030607@localhost.local> <7854077.3GbzoT9yL1@crushinator> <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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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.