From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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: Content-Type: multipart/alternative; boundary="_5b864581-de3c-4f53-b886-9ca70f2ba1ba_" MIME-Version: 1.0 To: Robert McKay , Matt Whitlock From: Thy Shizzle 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 Sent: =E2=80=8E28/=E2=80=8E03/=E2=80=8E2015 2:33 AM To: Matt Whitlock Cc: bitcoin-development@lists.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"
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.
From: Robert McKay
Sent: =E2=80=8E28/=E2=80=8E03/=E2=80=8E2015 2:33 AM
To: Matt Whitlock
Cc: bitcoin-d= evelopment@lists.sourceforge.net
Subject: Re: [Bitcoin-development] "=3Bnetwork disruption as a service"= =3B and proof of local storage

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


---------------------------------------------------------------------------= ---
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://gop= arallel.sourceforge.net/
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--_5b864581-de3c-4f53-b886-9ca70f2ba1ba_--