path: root/8c/f4a50e32f323dacad3cfeba016e32185585167

Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <thyshizzle@outlook.com>) id 1Ybgu6-0002sy-DA
	for bitcoin-development@lists.sourceforge.net;
	Sat, 28 Mar 2015 02:55:18 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of outlook.com
	designates 65.54.190.231 as permitted sender)
	client-ip=65.54.190.231; envelope-from=thyshizzle@outlook.com;
	helo=BAY004-OMC4S26.hotmail.com; 
Received: from bay004-omc4s26.hotmail.com ([65.54.190.231])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.76) id 1Ybgu3-0007OJ-TK
	for bitcoin-development@lists.sourceforge.net;
	Sat, 28 Mar 2015 02:55:18 +0000
Received: from BAY403-EAS54 ([65.54.190.200]) by BAY004-OMC4S26.hotmail.com
	over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751);
	Fri, 27 Mar 2015 19:55:10 -0700
X-TMN: [Q0D1lCHEUL39EBNBKkiZFscaNKaMYhse]
X-Originating-Email: [thyshizzle@outlook.com]
Message-ID: <BAY403-EAS545988A99880C56808398CC2F70@phx.gbl>
Content-Type: multipart/alternative;
	boundary="_5b864581-de3c-4f53-b886-9ca70f2ba1ba_"
MIME-Version: 1.0
To: Robert McKay <robert@mckay.com>, Matt Whitlock <bip@mattwhitlock.name>
From: Thy Shizzle <thyshizzle@outlook.com>
Date: Sat, 28 Mar 2015 13:55:00 +1100
X-OriginalArrivalTime: 28 Mar 2015 02:55:10.0183 (UTC)
	FILETIME=[9ACEA770:01D06902]
X-Spam-Score: -0.2 (/)
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(thyshizzle[at]outlook.com)
	-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
	no trust [65.54.190.231 listed in list.dnswl.org]
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	0.2 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1Ybgu3-0007OJ-TK
Cc: bitcoin-development@lists.sourceforge.net
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: Sat, 28 Mar 2015 02:55:18 -0000

--_5b864581-de3c-4f53-b886-9ca70f2ba1ba_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"

If the IP discovery is your main motivation=2C why don't you introduce some=
 onion routing into transactions? That would solve this problem easily=2C o=
f course there is an overhead which will slightly slow down the relay of tr=
ansactions but not significantly=2C also make it an option not enforced=2C =
for those worried about IP association.
________________________________
From: Robert McKay<mailto:robert@mckay.com>
Sent: =E2=80=8E28/=E2=80=8E03/=E2=80=8E2015 2:33 AM
To: Matt Whitlock<mailto:bip@mattwhitlock.name>
Cc: bitcoin-development@lists.sourceforge.net<mailto:bitcoin-development@li=
sts.sourceforge.net>
Subject: Re: [Bitcoin-development] "network disruption as a service" and pr=
oof of local storage

The main motivation is to try and stop a single entity running lots of
nodes in order to harvest transaction origin IPs. That's what's behind
this.

Probably the efforts are a waste of time.. if someone has to keep a few
hundred copies of the blockchain around in order to keep IP specific
precomputed data around for all the IPs they listen on then they'll just
buy a handful of 5TB HDs and call it a day.. still some of the ideas
proposed are quite interesting and might not have much downside.

Rob


On 2015-03-27 15:16=2C Matt Whitlock wrote:
> I agree that someone could do this=2C but why is that a problem? Isn't
> the goal of this exercise to ensure more full nodes on the network?
> In
> order to be able to answer the challenges=2C an entity would need to be
> running a full node somewhere. Thus=2C they have contributed at least
> one additional full node to the network. I could certainly see a case
> for a company to host hundreds of lightweight (e.g.=2C EC2) servers all
> backed by a single copy of the block chain. Why force every single
> machine to have its own copy? All you really need to require is that
> each agency/participant have its own copy.
>
>
> On Friday=2C 27 March 2015=2C at 2:32 pm=2C Robert McKay wrote:
>> Basically the problem with that is that someone could setup a single
>> full node that has the blockchain and can answer those challenges
>> and
>> then a bunch of other non-full nodes that just proxy any such
>> challenges
>> to the single full node.
>>
>> Rob
>>
>> On 2015-03-26 23:04=2C Matt Whitlock wrote:
>> > Maybe I'm overlooking something=2C but I've been watching this
>> thread
>> > with increasing skepticism at the complexity of the offered
>> solution.
>> > I don't understand why it needs to be so complex. I'd like to
>> offer
>> > an
>> > alternative for your consideration...
>> >
>> > Challenge:
>> > "Send me: SHA256(SHA256(concatenation of N pseudo-randomly
>> selected
>> > bytes from the block chain))."
>> >
>> > Choose N such that it would be infeasible for the responding node
>> to
>> > fetch all of the needed blocks in a short amount of time. In other
>> > words=2C assume that a node can seek to a given byte in a block
>> stored
>> > on local disk much faster than it can download the entire block
>> from
>> > a
>> > remote peer. This is almost certainly a safe assumption.
>> >
>> > For example=2C choose N =3D 1024. Then the proving node needs to
>> perform
>> > 1024 random reads from local disk. On spinning media=2C this is
>> likely
>> > to take somewhere on the order of 15 seconds. Assuming blocks are
>> > averaging 500 KiB each=2C then 1024 blocks would comprise 500 MiB of
>> > data. Can 500 MiB be downloaded in 15 seconds? This data transfer
>> > rate
>> > is 280 Mbps. Almost certainly not possible. And if it is=2C just
>> > increase N. The challenge also becomes more difficult as average
>> > block
>> > size increases.
>> >
>> > This challenge-response protocol relies on the lack of a "partial
>> > getdata" command in the Bitcoin protocol: a node cannot ask for
>> only
>> > part of a block=3B it must ask for an entire block. Furthermore=2C
>> nodes
>> > could ban other nodes for making too many random requests for
>> blocks.
>> >
>> >
>> > On Thursday=2C 26 March 2015=2C at 7:09 pm=2C Sergio Lerner wrote:
>> >>
>> >> > If I understand correctly=2C transforming raw blocks to keyed
>> blocks
>> >> > takes 512x longer than transforming keyed blocks back to raw.
>> The
>> >> key
>> >> > is public=2C like the IP=2C or some other value which perhaps
>> changes
>> >> less
>> >> > frequently.
>> >> >
>> >> Yes. I was thinking that the IP could be part of a first layer of
>> >> encryption done to the blockchain data prior to the asymetric
>> >> operation.
>> >> That way the asymmetric operation can be the same for all users
>> (no
>> >> different primers for different IPs=2C and then the verifiers does
>> not
>> >> have to verify that a particular p is actually a pseudo-prime
>> >> suitable
>> >> for P.H. ) and the public exponent can be just 3.
>> >>
>> >> >
>> >> >> Two protocols can be performed to prove local possession:
>> >> >> 1. (prover and verifier pay a small cost) The verifier sends a
>> >> seed to
>> >> >> derive some n random indexes=2C and the prover must respond with
>> >> the hash
>> >> >> of the decrypted blocks within a certain time bound. Suppose
>> that
>> >> >> decryption of n blocks take 100 msec (+-100 msec of network
>> >> jitter).
>> >> >> Then an attacker must have a computer 50 faster to be able to
>> >> >> consistently cheat. The last 50 blocks should not be part of
>> the
>> >> list to
>> >> >> allow nodes to catch-up and encrypt the blocks in background.
>> >> >>
>> >> >
>> >> > Can you clarify=2C the prover is hashing random blocks of
>> >> *decrypted*=2C
>> >> > as-in raw=2C blockchain data? What does this prove other than=2C
>> >> perhaps=2C
>> >> > fast random IO of the blockchain? (which is useful in its own
>> >> right=2C
>> >> > e.g. as a way to ensure only full-node IO-bound mining if baked
>> >> into
>> >> > the PoW)
>> >> >
>> >> > How is the verifier validating the response without possession
>> of
>> >> the
>> >> > full blockchain?
>> >>
>> >> You're right=2C It is incorrect. Not the decrypted blocks must be
>> >> sent=2C
>> >> but the encrypted blocks. There correct protocol is this:
>> >>
>> >> 1. (prover and verifier pay a small cost) The verifier sends a
>> seed
>> >> to
>> >> derive some n random indexes=2C and the prover must respond with
>> the
>> >> the
>> >> encrypted blocks within a certain time bound. The verifier
>> decrypts
>> >> those blocks to check if they are part of the block-chain.
>> >>
>> >> But then there is this improvement which allows the verifier do
>> >> detect
>> >> non full-nodes with much less computation:
>> >>
>> >> 3. (prover pays a small cost=2C verifier smaller cost) The verifier
>> >> asks
>> >> the prover to send a Merkle tree root of hashes of encrypted
>> blocks
>> >> with
>> >> N indexes selected by a psudo-random function seeded by a
>> challenge
>> >> value=2C where each encrypted-block is previously prefixed with the
>> >> seed
>> >> before being hashed (e.g. N=3D100). The verifier receives the
>> Markle
>> >> Root
>> >> and performs a statistical test on the received information. From
>> >> the N
>> >> hashes blocks=2C it chooses M < N (e.g. M =3D 20)=2C and asks the
>> proved
>> >> for
>> >> the blocks at these indexes. The prover sends the blocks=2C the
>> >> verifier
>> >> validates the blocks by decrypting them and also verifies that
>> the
>> >> Merkle tree was well constructed for those block nodes. This
>> proves
>> >> with
>> >> high probability that the Merkle tree was built on-the-fly and
>> >> specifically for this challenge-response protocol.
>> >>
>> >> > I also wonder about the effect of spinning disk versus SSD.
>> Seek
>> >> time
>> >> > for 1=2C000 random reads is either nearly zero or dominating
>> >> depending
>> >> > on the two modes. I wonder if a sequential read from a random
>> >> index is
>> >> > a possible trade-off=2C=3B it doesn't prove possession of the whole
>> >> chain
>> >> > nearly as well=2C but at least iowait converges significantly.
>> Then
>> >> > again=2C that presupposes a specific ordering on disk which might
>> >> not
>> >> > exist. In X years it will all be solid-state=2C so eventually
>> it's
>> >> moot.
>> >> >
>> >> Good idea.
>> >>
>> >> Also we don't need that every node implements the protocol=2C but
>> only
>> >> nodes that want to prove full-node-ness=2C such as the ones which
>> want
>> >> to
>> >> receive bitnodes subsidy.
>> >
>> >
>> >
>> >
>> ------------------------------------------------------------------------=
------
>> > Dive into the World of Parallel Programming The Go Parallel
>> Website=2C
>> > sponsored
>> > by Intel and developed in partnership with Slashdot Media=2C is your
>> > hub for all
>> > things parallel software development=2C from weekly thought
>> leadership
>> > blogs to
>> > news=2C videos=2C case studies=2C tutorials and more. Take a look and
>> join
>> > the
>> > conversation now. http://goparallel.sourceforge.net/
>> > _______________________________________________
>> > Bitcoin-development mailing list
>> > Bitcoin-development@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>>
>> ------------------------------------------------------------------------=
------
>> Dive into the World of Parallel Programming The Go Parallel Website=2C
>> sponsored
>> by Intel and developed in partnership with Slashdot Media=2C is your
>> hub for all
>> things parallel software development=2C from weekly thought leadership
>> blogs to
>> news=2C videos=2C case studies=2C tutorials and more. Take a look and jo=
in
>> the
>> conversation now. http://goparallel.sourceforge.net/
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development


---------------------------------------------------------------------------=
---
Dive into the World of Parallel Programming The Go Parallel Website=2C spon=
sored
by Intel and developed in partnership with Slashdot Media=2C is your hub fo=
r all
things parallel software development=2C from weekly thought leadership blog=
s to
news=2C videos=2C case studies=2C tutorials and more. Take a look and join =
the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--_5b864581-de3c-4f53-b886-9ca70f2ba1ba_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="utf-8"

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html=3B charset=3Dutf-8">
</head>
<body>
<div>
<div style=3D"font-family: Calibri=2Csans-serif=3B font-size: 11pt=3B">If t=
he IP discovery is your main motivation=2C why don't you introduce some oni=
on routing into transactions? That would solve this problem easily=2C of co=
urse there is an overhead which will slightly
 slow down the relay of transactions but not significantly=2C also make it =
an option not enforced=2C for those worried about IP association.</div>
</div>
<div dir=3D"ltr">
<hr>
<span style=3D"font-family: Calibri=2Csans-serif=3B font-size: 11pt=3B font=
-weight: bold=3B">From:
</span><span style=3D"font-family: Calibri=2Csans-serif=3B font-size: 11pt=
=3B"><a href=3D"mailto:robert@mckay.com">Robert McKay</a></span><br>
<span style=3D"font-family: Calibri=2Csans-serif=3B font-size: 11pt=3B font=
-weight: bold=3B">Sent:
</span><span style=3D"font-family: Calibri=2Csans-serif=3B font-size: 11pt=
=3B">=E2=80=8E28/=E2=80=8E03/=E2=80=8E2015 2:33 AM</span><br>
<span style=3D"font-family: Calibri=2Csans-serif=3B font-size: 11pt=3B font=
-weight: bold=3B">To:
</span><span style=3D"font-family: Calibri=2Csans-serif=3B font-size: 11pt=
=3B"><a href=3D"mailto:bip@mattwhitlock.name">Matt Whitlock</a></span><br>
<span style=3D"font-family: Calibri=2Csans-serif=3B font-size: 11pt=3B font=
-weight: bold=3B">Cc:
</span><span style=3D"font-family: Calibri=2Csans-serif=3B font-size: 11pt=
=3B"><a href=3D"mailto:bitcoin-development@lists.sourceforge.net">bitcoin-d=
evelopment@lists.sourceforge.net</a></span><br>
<span style=3D"font-family: Calibri=2Csans-serif=3B font-size: 11pt=3B font=
-weight: bold=3B">Subject:
</span><span style=3D"font-family: Calibri=2Csans-serif=3B font-size: 11pt=
=3B">Re: [Bitcoin-development] &quot=3Bnetwork disruption as a service&quot=
=3B and proof of local storage</span><br>
<br>
</div>
<div class=3D"BodyFragment">
<div class=3D"PlainText">The main motivation is to try and stop a single en=
tity running lots of
<br>
nodes in order to harvest transaction origin IPs. That's what's behind <br>
this.<br>
<br>
Probably the efforts are a waste of time.. if someone has to keep a few <br=
>
hundred copies of the blockchain around in order to keep IP specific <br>
precomputed data around for all the IPs they listen on then they'll just <b=
r>
buy a handful of 5TB HDs and call it a day.. still some of the ideas <br>
proposed are quite interesting and might not have much downside.<br>
<br>
Rob<br>
<br>
<br>
On 2015-03-27 15:16=2C Matt Whitlock wrote:<br>
&gt=3B I agree that someone could do this=2C but why is that a problem? Isn=
't<br>
&gt=3B the goal of this exercise to ensure more full nodes on the network? =
<br>
&gt=3B In<br>
&gt=3B order to be able to answer the challenges=2C an entity would need to=
 be<br>
&gt=3B running a full node somewhere. Thus=2C they have contributed at leas=
t<br>
&gt=3B one additional full node to the network. I could certainly see a cas=
e<br>
&gt=3B for a company to host hundreds of lightweight (e.g.=2C EC2) servers =
all<br>
&gt=3B backed by a single copy of the block chain. Why force every single<b=
r>
&gt=3B machine to have its own copy? All you really need to require is that=
<br>
&gt=3B each agency/participant have its own copy.<br>
&gt=3B<br>
&gt=3B<br>
&gt=3B On Friday=2C 27 March 2015=2C at 2:32 pm=2C Robert McKay wrote:<br>
&gt=3B&gt=3B Basically the problem with that is that someone could setup a =
single<br>
&gt=3B&gt=3B full node that has the blockchain and can answer those challen=
ges <br>
&gt=3B&gt=3B and<br>
&gt=3B&gt=3B then a bunch of other non-full nodes that just proxy any such =
<br>
&gt=3B&gt=3B challenges<br>
&gt=3B&gt=3B to the single full node.<br>
&gt=3B&gt=3B<br>
&gt=3B&gt=3B Rob<br>
&gt=3B&gt=3B<br>
&gt=3B&gt=3B On 2015-03-26 23:04=2C Matt Whitlock wrote:<br>
&gt=3B&gt=3B &gt=3B Maybe I'm overlooking something=2C but I've been watchi=
ng this <br>
&gt=3B&gt=3B thread<br>
&gt=3B&gt=3B &gt=3B with increasing skepticism at the complexity of the off=
ered <br>
&gt=3B&gt=3B solution.<br>
&gt=3B&gt=3B &gt=3B I don't understand why it needs to be so complex. I'd l=
ike to <br>
&gt=3B&gt=3B offer<br>
&gt=3B&gt=3B &gt=3B an<br>
&gt=3B&gt=3B &gt=3B alternative for your consideration...<br>
&gt=3B&gt=3B &gt=3B<br>
&gt=3B&gt=3B &gt=3B Challenge:<br>
&gt=3B&gt=3B &gt=3B &quot=3BSend me: SHA256(SHA256(concatenation of N pseud=
o-randomly <br>
&gt=3B&gt=3B selected<br>
&gt=3B&gt=3B &gt=3B bytes from the block chain)).&quot=3B<br>
&gt=3B&gt=3B &gt=3B<br>
&gt=3B&gt=3B &gt=3B Choose N such that it would be infeasible for the respo=
nding node <br>
&gt=3B&gt=3B to<br>
&gt=3B&gt=3B &gt=3B fetch all of the needed blocks in a short amount of tim=
e. In other<br>
&gt=3B&gt=3B &gt=3B words=2C assume that a node can seek to a given byte in=
 a block <br>
&gt=3B&gt=3B stored<br>
&gt=3B&gt=3B &gt=3B on local disk much faster than it can download the enti=
re block <br>
&gt=3B&gt=3B from<br>
&gt=3B&gt=3B &gt=3B a<br>
&gt=3B&gt=3B &gt=3B remote peer. This is almost certainly a safe assumption=
.<br>
&gt=3B&gt=3B &gt=3B<br>
&gt=3B&gt=3B &gt=3B For example=2C choose N =3D 1024. Then the proving node=
 needs to <br>
&gt=3B&gt=3B perform<br>
&gt=3B&gt=3B &gt=3B 1024 random reads from local disk. On spinning media=2C=
 this is <br>
&gt=3B&gt=3B likely<br>
&gt=3B&gt=3B &gt=3B to take somewhere on the order of 15 seconds. Assuming =
blocks are<br>
&gt=3B&gt=3B &gt=3B averaging 500 KiB each=2C then 1024 blocks would compri=
se 500 MiB of<br>
&gt=3B&gt=3B &gt=3B data. Can 500 MiB be downloaded in 15 seconds? This dat=
a transfer<br>
&gt=3B&gt=3B &gt=3B rate<br>
&gt=3B&gt=3B &gt=3B is 280 Mbps. Almost certainly not possible. And if it i=
s=2C just<br>
&gt=3B&gt=3B &gt=3B increase N. The challenge also becomes more difficult a=
s average<br>
&gt=3B&gt=3B &gt=3B block<br>
&gt=3B&gt=3B &gt=3B size increases.<br>
&gt=3B&gt=3B &gt=3B<br>
&gt=3B&gt=3B &gt=3B This challenge-response protocol relies on the lack of =
a &quot=3Bpartial<br>
&gt=3B&gt=3B &gt=3B getdata&quot=3B command in the Bitcoin protocol: a node=
 cannot ask for <br>
&gt=3B&gt=3B only<br>
&gt=3B&gt=3B &gt=3B part of a block=3B it must ask for an entire block. Fur=
thermore=2C <br>
&gt=3B&gt=3B nodes<br>
&gt=3B&gt=3B &gt=3B could ban other nodes for making too many random reques=
ts for <br>
&gt=3B&gt=3B blocks.<br>
&gt=3B&gt=3B &gt=3B<br>
&gt=3B&gt=3B &gt=3B<br>
&gt=3B&gt=3B &gt=3B On Thursday=2C 26 March 2015=2C at 7:09 pm=2C Sergio Le=
rner wrote:<br>
&gt=3B&gt=3B &gt=3B&gt=3B<br>
&gt=3B&gt=3B &gt=3B&gt=3B &gt=3B If I understand correctly=2C transforming =
raw blocks to keyed <br>
&gt=3B&gt=3B blocks<br>
&gt=3B&gt=3B &gt=3B&gt=3B &gt=3B takes 512x longer than transforming keyed =
blocks back to raw. <br>
&gt=3B&gt=3B The<br>
&gt=3B&gt=3B &gt=3B&gt=3B key<br>
&gt=3B&gt=3B &gt=3B&gt=3B &gt=3B is public=2C like the IP=2C or some other =
value which perhaps <br>
&gt=3B&gt=3B changes<br>
&gt=3B&gt=3B &gt=3B&gt=3B less<br>
&gt=3B&gt=3B &gt=3B&gt=3B &gt=3B frequently.<br>
&gt=3B&gt=3B &gt=3B&gt=3B &gt=3B<br>
&gt=3B&gt=3B &gt=3B&gt=3B Yes. I was thinking that the IP could be part of =
a first layer of<br>
&gt=3B&gt=3B &gt=3B&gt=3B encryption done to the blockchain data prior to t=
he asymetric<br>
&gt=3B&gt=3B &gt=3B&gt=3B operation.<br>
&gt=3B&gt=3B &gt=3B&gt=3B That way the asymmetric operation can be the same=
 for all users <br>
&gt=3B&gt=3B (no<br>
&gt=3B&gt=3B &gt=3B&gt=3B different primers for different IPs=2C and then t=
he verifiers does <br>
&gt=3B&gt=3B not<br>
&gt=3B&gt=3B &gt=3B&gt=3B have to verify that a particular p is actually a =
pseudo-prime<br>
&gt=3B&gt=3B &gt=3B&gt=3B suitable<br>
&gt=3B&gt=3B &gt=3B&gt=3B for P.H. ) and the public exponent can be just 3.=
<br>
&gt=3B&gt=3B &gt=3B&gt=3B<br>
&gt=3B&gt=3B &gt=3B&gt=3B &gt=3B<br>
&gt=3B&gt=3B &gt=3B&gt=3B &gt=3B&gt=3B Two protocols can be performed to pr=
ove local possession:<br>
&gt=3B&gt=3B &gt=3B&gt=3B &gt=3B&gt=3B 1. (prover and verifier pay a small =
cost) The verifier sends a<br>
&gt=3B&gt=3B &gt=3B&gt=3B seed to<br>
&gt=3B&gt=3B &gt=3B&gt=3B &gt=3B&gt=3B derive some n random indexes=2C and =
the prover must respond with<br>
&gt=3B&gt=3B &gt=3B&gt=3B the hash<br>
&gt=3B&gt=3B &gt=3B&gt=3B &gt=3B&gt=3B of the decrypted blocks within a cer=
tain time bound. Suppose <br>
&gt=3B&gt=3B that<br>
&gt=3B&gt=3B &gt=3B&gt=3B &gt=3B&gt=3B decryption of n blocks take 100 msec=
 (&#43=3B-100 msec of network<br>
&gt=3B&gt=3B &gt=3B&gt=3B jitter).<br>
&gt=3B&gt=3B &gt=3B&gt=3B &gt=3B&gt=3B Then an attacker must have a compute=
r 50 faster to be able to<br>
&gt=3B&gt=3B &gt=3B&gt=3B &gt=3B&gt=3B consistently cheat. The last 50 bloc=
ks should not be part of <br>
&gt=3B&gt=3B the<br>
&gt=3B&gt=3B &gt=3B&gt=3B list to<br>
&gt=3B&gt=3B &gt=3B&gt=3B &gt=3B&gt=3B allow nodes to catch-up and encrypt =
the blocks in background.<br>
&gt=3B&gt=3B &gt=3B&gt=3B &gt=3B&gt=3B<br>
&gt=3B&gt=3B &gt=3B&gt=3B &gt=3B<br>
&gt=3B&gt=3B &gt=3B&gt=3B &gt=3B Can you clarify=2C the prover is hashing r=
andom blocks of<br>
&gt=3B&gt=3B &gt=3B&gt=3B *decrypted*=2C<br>
&gt=3B&gt=3B &gt=3B&gt=3B &gt=3B as-in raw=2C blockchain data? What does th=
is prove other than=2C<br>
&gt=3B&gt=3B &gt=3B&gt=3B perhaps=2C<br>
&gt=3B&gt=3B &gt=3B&gt=3B &gt=3B fast random IO of the blockchain? (which i=
s useful in its own<br>
&gt=3B&gt=3B &gt=3B&gt=3B right=2C<br>
&gt=3B&gt=3B &gt=3B&gt=3B &gt=3B e.g. as a way to ensure only full-node IO-=
bound mining if baked<br>
&gt=3B&gt=3B &gt=3B&gt=3B into<br>
&gt=3B&gt=3B &gt=3B&gt=3B &gt=3B the PoW)<br>
&gt=3B&gt=3B &gt=3B&gt=3B &gt=3B<br>
&gt=3B&gt=3B &gt=3B&gt=3B &gt=3B How is the verifier validating the respons=
e without possession <br>
&gt=3B&gt=3B of<br>
&gt=3B&gt=3B &gt=3B&gt=3B the<br>
&gt=3B&gt=3B &gt=3B&gt=3B &gt=3B full blockchain?<br>
&gt=3B&gt=3B &gt=3B&gt=3B<br>
&gt=3B&gt=3B &gt=3B&gt=3B You're right=2C It is incorrect. Not the decrypte=
d blocks must be<br>
&gt=3B&gt=3B &gt=3B&gt=3B sent=2C<br>
&gt=3B&gt=3B &gt=3B&gt=3B but the encrypted blocks. There correct protocol =
is this:<br>
&gt=3B&gt=3B &gt=3B&gt=3B<br>
&gt=3B&gt=3B &gt=3B&gt=3B 1. (prover and verifier pay a small cost) The ver=
ifier sends a <br>
&gt=3B&gt=3B seed<br>
&gt=3B&gt=3B &gt=3B&gt=3B to<br>
&gt=3B&gt=3B &gt=3B&gt=3B derive some n random indexes=2C and the prover mu=
st respond with <br>
&gt=3B&gt=3B the<br>
&gt=3B&gt=3B &gt=3B&gt=3B the<br>
&gt=3B&gt=3B &gt=3B&gt=3B encrypted blocks within a certain time bound. The=
 verifier <br>
&gt=3B&gt=3B decrypts<br>
&gt=3B&gt=3B &gt=3B&gt=3B those blocks to check if they are part of the blo=
ck-chain.<br>
&gt=3B&gt=3B &gt=3B&gt=3B<br>
&gt=3B&gt=3B &gt=3B&gt=3B But then there is this improvement which allows t=
he verifier do<br>
&gt=3B&gt=3B &gt=3B&gt=3B detect<br>
&gt=3B&gt=3B &gt=3B&gt=3B non full-nodes with much less computation:<br>
&gt=3B&gt=3B &gt=3B&gt=3B<br>
&gt=3B&gt=3B &gt=3B&gt=3B 3. (prover pays a small cost=2C verifier smaller =
cost) The verifier<br>
&gt=3B&gt=3B &gt=3B&gt=3B asks<br>
&gt=3B&gt=3B &gt=3B&gt=3B the prover to send a Merkle tree root of hashes o=
f encrypted <br>
&gt=3B&gt=3B blocks<br>
&gt=3B&gt=3B &gt=3B&gt=3B with<br>
&gt=3B&gt=3B &gt=3B&gt=3B N indexes selected by a psudo-random function see=
ded by a <br>
&gt=3B&gt=3B challenge<br>
&gt=3B&gt=3B &gt=3B&gt=3B value=2C where each encrypted-block is previously=
 prefixed with the<br>
&gt=3B&gt=3B &gt=3B&gt=3B seed<br>
&gt=3B&gt=3B &gt=3B&gt=3B before being hashed (e.g. N=3D100). The verifier =
receives the <br>
&gt=3B&gt=3B Markle<br>
&gt=3B&gt=3B &gt=3B&gt=3B Root<br>
&gt=3B&gt=3B &gt=3B&gt=3B and performs a statistical test on the received i=
nformation. From<br>
&gt=3B&gt=3B &gt=3B&gt=3B the N<br>
&gt=3B&gt=3B &gt=3B&gt=3B hashes blocks=2C it chooses M &lt=3B N (e.g. M =
=3D 20)=2C and asks the <br>
&gt=3B&gt=3B proved<br>
&gt=3B&gt=3B &gt=3B&gt=3B for<br>
&gt=3B&gt=3B &gt=3B&gt=3B the blocks at these indexes. The prover sends the=
 blocks=2C the<br>
&gt=3B&gt=3B &gt=3B&gt=3B verifier<br>
&gt=3B&gt=3B &gt=3B&gt=3B validates the blocks by decrypting them and also =
verifies that <br>
&gt=3B&gt=3B the<br>
&gt=3B&gt=3B &gt=3B&gt=3B Merkle tree was well constructed for those block =
nodes. This <br>
&gt=3B&gt=3B proves<br>
&gt=3B&gt=3B &gt=3B&gt=3B with<br>
&gt=3B&gt=3B &gt=3B&gt=3B high probability that the Merkle tree was built o=
n-the-fly and<br>
&gt=3B&gt=3B &gt=3B&gt=3B specifically for this challenge-response protocol=
.<br>
&gt=3B&gt=3B &gt=3B&gt=3B<br>
&gt=3B&gt=3B &gt=3B&gt=3B &gt=3B I also wonder about the effect of spinning=
 disk versus SSD. <br>
&gt=3B&gt=3B Seek<br>
&gt=3B&gt=3B &gt=3B&gt=3B time<br>
&gt=3B&gt=3B &gt=3B&gt=3B &gt=3B for 1=2C000 random reads is either nearly =
zero or dominating<br>
&gt=3B&gt=3B &gt=3B&gt=3B depending<br>
&gt=3B&gt=3B &gt=3B&gt=3B &gt=3B on the two modes. I wonder if a sequential=
 read from a random<br>
&gt=3B&gt=3B &gt=3B&gt=3B index is<br>
&gt=3B&gt=3B &gt=3B&gt=3B &gt=3B a possible trade-off=2C=3B it doesn't prov=
e possession of the whole<br>
&gt=3B&gt=3B &gt=3B&gt=3B chain<br>
&gt=3B&gt=3B &gt=3B&gt=3B &gt=3B nearly as well=2C but at least iowait conv=
erges significantly. <br>
&gt=3B&gt=3B Then<br>
&gt=3B&gt=3B &gt=3B&gt=3B &gt=3B again=2C that presupposes a specific order=
ing on disk which might<br>
&gt=3B&gt=3B &gt=3B&gt=3B not<br>
&gt=3B&gt=3B &gt=3B&gt=3B &gt=3B exist. In X years it will all be solid-sta=
te=2C so eventually <br>
&gt=3B&gt=3B it's<br>
&gt=3B&gt=3B &gt=3B&gt=3B moot.<br>
&gt=3B&gt=3B &gt=3B&gt=3B &gt=3B<br>
&gt=3B&gt=3B &gt=3B&gt=3B Good idea.<br>
&gt=3B&gt=3B &gt=3B&gt=3B<br>
&gt=3B&gt=3B &gt=3B&gt=3B Also we don't need that every node implements the=
 protocol=2C but <br>
&gt=3B&gt=3B only<br>
&gt=3B&gt=3B &gt=3B&gt=3B nodes that want to prove full-node-ness=2C such a=
s the ones which <br>
&gt=3B&gt=3B want<br>
&gt=3B&gt=3B &gt=3B&gt=3B to<br>
&gt=3B&gt=3B &gt=3B&gt=3B receive bitnodes subsidy.<br>
&gt=3B&gt=3B &gt=3B<br>
&gt=3B&gt=3B &gt=3B<br>
&gt=3B&gt=3B &gt=3B<br>
&gt=3B&gt=3B &gt=3B <br>
&gt=3B&gt=3B --------------------------------------------------------------=
----------------<br>
&gt=3B&gt=3B &gt=3B Dive into the World of Parallel Programming The Go Para=
llel <br>
&gt=3B&gt=3B Website=2C<br>
&gt=3B&gt=3B &gt=3B sponsored<br>
&gt=3B&gt=3B &gt=3B by Intel and developed in partnership with Slashdot Med=
ia=2C is your<br>
&gt=3B&gt=3B &gt=3B hub for all<br>
&gt=3B&gt=3B &gt=3B things parallel software development=2C from weekly tho=
ught <br>
&gt=3B&gt=3B leadership<br>
&gt=3B&gt=3B &gt=3B blogs to<br>
&gt=3B&gt=3B &gt=3B news=2C videos=2C case studies=2C tutorials and more. T=
ake a look and <br>
&gt=3B&gt=3B join<br>
&gt=3B&gt=3B &gt=3B the<br>
&gt=3B&gt=3B &gt=3B conversation now. <a href=3D"http://goparallel.sourcefo=
rge.net/">http://goparallel.sourceforge.net/</a><br>
&gt=3B&gt=3B &gt=3B _______________________________________________<br>
&gt=3B&gt=3B &gt=3B Bitcoin-development mailing list<br>
&gt=3B&gt=3B &gt=3B Bitcoin-development@lists.sourceforge.net<br>
&gt=3B&gt=3B &gt=3B <a href=3D"https://lists.sourceforge.net/lists/listinfo=
/bitcoin-development">https://lists.sourceforge.net/lists/listinfo/bitcoin-=
development</a><br>
&gt=3B&gt=3B<br>
&gt=3B&gt=3B<br>
&gt=3B&gt=3B <br>
&gt=3B&gt=3B --------------------------------------------------------------=
----------------<br>
&gt=3B&gt=3B Dive into the World of Parallel Programming The Go Parallel We=
bsite=2C <br>
&gt=3B&gt=3B sponsored<br>
&gt=3B&gt=3B by Intel and developed in partnership with Slashdot Media=2C i=
s your <br>
&gt=3B&gt=3B hub for all<br>
&gt=3B&gt=3B things parallel software development=2C from weekly thought le=
adership <br>
&gt=3B&gt=3B blogs to<br>
&gt=3B&gt=3B news=2C videos=2C case studies=2C tutorials and more. Take a l=
ook and join <br>
&gt=3B&gt=3B the<br>
&gt=3B&gt=3B conversation now. <a href=3D"http://goparallel.sourceforge.net=
/">http://goparallel.sourceforge.net/</a><br>
&gt=3B&gt=3B _______________________________________________<br>
&gt=3B&gt=3B Bitcoin-development mailing list<br>
&gt=3B&gt=3B Bitcoin-development@lists.sourceforge.net<br>
&gt=3B&gt=3B <a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoi=
n-development">https://lists.sourceforge.net/lists/listinfo/bitcoin-develop=
ment</a><br>
<br>
<br>
---------------------------------------------------------------------------=
---<br>
Dive into the World of Parallel Programming The Go Parallel Website=2C spon=
sored<br>
by Intel and developed in partnership with Slashdot Media=2C is your hub fo=
r all<br>
things parallel software development=2C from weekly thought leadership blog=
s to<br>
news=2C videos=2C case studies=2C tutorials and more. Take a look and join =
the <br>
conversation now. <a href=3D"http://goparallel.sourceforge.net/">http://gop=
arallel.sourceforge.net/</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
Bitcoin-development@lists.sourceforge.net<br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a><br>
</div>
</div>
</body>
</html>

--_5b864581-de3c-4f53-b886-9ca70f2ba1ba_--