From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YZzGF-00081R-Cw for bitcoin-development@lists.sourceforge.net; Mon, 23 Mar 2015 10:07:07 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of outlook.com designates 65.55.34.12 as permitted sender) client-ip=65.55.34.12; envelope-from=thyshizzle@outlook.com; helo=COL004-OMC1S2.hotmail.com; Received: from col004-omc1s2.hotmail.com ([65.55.34.12]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1YZzGD-00053g-7s for bitcoin-development@lists.sourceforge.net; Mon, 23 Mar 2015 10:07:07 +0000 Received: from COL401-EAS404 ([65.55.34.7]) by COL004-OMC1S2.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Mon, 23 Mar 2015 03:06:58 -0700 X-TMN: [STWWraZ8xonjUijGmeik/jd9Hrv4GP8C] X-Originating-Email: [thyshizzle@outlook.com] Message-ID: Content-Type: multipart/alternative; boundary="_736f674a-abbd-4e9c-b0dc-604efc5db805_" MIME-Version: 1.0 To: Sergio Lerner , From: Thy Shizzle Date: Mon, 23 Mar 2015 21:06:48 +1100 X-OriginalArrivalTime: 23 Mar 2015 10:06:58.0892 (UTC) FILETIME=[198928C0:01D06551] X-Spam-Score: -0.8 (/) 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 SPF_PASS SPF: sender matches SPF record -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [65.55.34.12 listed in list.dnswl.org] 1.0 HTML_MESSAGE BODY: HTML included in message -0.2 AWL AWL: Adjusted score from AWL reputation of From: address X-Headers-End: 1YZzGD-00053g-7s 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: Mon, 23 Mar 2015 10:07:07 -0000 --_736f674a-abbd-4e9c-b0dc-604efc5db805_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Wow=2C that's quite impressive. But what comes to my mind is if such an ext= ravagant solution really need to be implemented regarding proof of storage?= I mean=2C my idea whilst building my node was to do something along the li= nes of "tell me what you got" i.e get block height from the version message= =2C and then fire off your getblock=2C getdata etc and simply if a node doe= s not respond with the requested data after a few attempts=2C we disconnect= and perhaps blacklist until the node restarts or something. I am of cour= se purely looking at it from the perspective of useless nodes consuming con= nection slots=2C there may be other scenarios where you require proof of st= orage that I am not considering. I just think that simple blacklist rules c= ould easily avoid this without the extra resource usage? I mean if you star= t doing encryption for every task then before you know it you need to dedic= ate all your cpu to the node! Especially for tasks that are not mission cri= tical or require verification=2C I mean useless nodes are more of an annoya= nce with the potential to disrupt the network=2C slow it down=2C but not co= mpromise it=2C so I shouldn't think it would be something that you would tu= rn to encryption for right? I feel this anyway. ________________________________ From: Sergio Lerner Sent: =E2=80=8E17/=E2=80=8E03/=E2=80=8E2015 3:45 AM To: bitcoin-development@lists.sourceforge.net Subject: [Bitcoin-development] "network disruption as a service" and proof = of local storage The problem of pseudo-nodes will come over and over. The cat and mouse chase is just beginning. It has been discussed some times that the easiest solution world be to request some kind of resource consumption on each peer to be allowed to connect to other peers. Gmaxwell proposed Proof of Storage here: https://bitcointalk.org/index.php?topic=3D310323.msg3332919#msg3332919 I proposed a (what I think) is better protocol for Proof of Storage that I call "Proof of Local storage" here https://bitslog.wordpress.com/2014/11/03/proof-of-local-blockchain-storage/ . It's better because it does not need the storage of additional data=2C but more importantly=2C it allows you to prove full copy of the blockchain is being maintained by the peer. This is specially important now that Bitnodes is trying a full-node incentive program that may be easily cheated (http://qntra.net/2015/02/pseudonode-proxy-fools-bitcoin-full-node-incentiv= e-program/) Proof of local storage allows a node to prove another peer that he is storing a LOCAL copy of a PUBLIC file=2C such as the blockchain. So the peer need not waste more resources (well=2C just some resources to encode/decode the block-chain). The main idea is to use what I called asymmetric-time-encoding. Basically you encode the block-chain in a way that it takes 100 more times to write it than to read it. Since the block-chain is an append-only (write-only) file=2C this fit good for our needs. For instance (and as a simplification)=2C choosing a global 1024-bit prime=2C then splitting the block-chain in 1024-bit blocks=2C and encrypting each block using Polihg-Hellman (modexp) with decryption exponent 3. Then encryption is at least 100 times slower than decryption. Before PH encryption each node must xor each block with a pseudo-random mask derived from the public IP and the block index. So block encryption could be: BlockEncryptIndex(i) =3D E(IP+i=2Cblock(i))^inv(3) (mod p)=2C where inv(3) is 3^-1 mod (p-1). E() could be a fast tweaked encryption routine (tweak =3D index)=2C but we only need the PRNG properties of E() an= d that E() does share algebraic properties with P.H.. 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. 2. (prover pay a high cost=2C verified pays negligible cost). The verifier chooses a seed n=2C and then pre-computes the encrypted blocks derived from the seed using the prover's IP. Then the verifier sends the seed=2C and the prover must respond with the hash of the encrypted blocks within a certain time bound. The proved does not require to do any PH decryption=2C just take the encrypted blocks for indexes derived from the seed=2C hash them and send the hash back to the verifier. The verifier validates the time bound and the hash. Both protocols can me made available by the client=2C under different states. For instance=2C new nodes are only allowed to request protocol 2 (and so they get an initial assurance their are connecting to full-nodes). After a first-time mutual authentication=2C they are allowed to periodically perform protocol 1. Also new nodes may be allowed to perform protocol 1 with a small index set=2C and increase the index set over time=2C to get higher confidence. The important difference between this protocol and classical remote software attestation protocols=2C is that the time gap between a good peer and a malicious peer can be made arbitrarily high=2C picking a larger p. Maybe there is even another crypto primitive which is more asymmetric than exponent 3 decryption (the LUC or NTRU cryptosystem?). In GMaxwell proposal each peer builds a table for each other peer. In my proposal=2C each peer builds a single table (the encrypted blockchain)=2C s= o it could be still possible to establish a thousands of connections to the network from a single peer. Nevertheless=2C the attacker's IP will be easily detected (he cannot hide under a thousands different IPs). It's also possible to restrict the challenge-response to a portion of the block-chain=2C the portion offset being derived from the hash of both IP addresses and one random numbers provided by each peer. Suppose each connection has a C-R space equivalent to 1% of the block-chain. Then having 100 connections and responding to C-R on each connection means storing approximate 1 copy of the block-chain (there may be overlaps=2C which would need to be stored twice) =2C while having 1K connections would require storing 10 copies of the blockchain. Best regards=2C Sergio ---------------------------------------------------------------------------= --- 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 --_736f674a-abbd-4e9c-b0dc-604efc5db805_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
Wow= =2C that's quite impressive. But what comes to my mind is if such an extrav= agant solution really need to be implemented regarding proof of storage? I = mean=2C my idea whilst building my node was to do something along the lines of "=3Btell me what you got"=3B i.e g= et block height from the version message=2C and then fire off your getblock= =2C getdata etc and simply if a node does not respond with the requested da= ta after a few attempts=2C we disconnect =3B and perhaps blacklist until the =3B node restarts or something. I am of course pur= ely looking at it from the perspective of useless nodes consuming connectio= n slots=2C there may be other scenarios where you require proof of storage = that I am not considering. I just think that simple blacklist rules could easily avoid this without the extra resource = usage? I mean if you start doing encryption for every task then before you = know it you need to dedicate all your cpu to the node! Especially for tasks= that are not mission critical or require verification=2C I mean useless nodes are more of an annoyance with= the potential to disrupt the network=2C slow it down=2C but not compromise= it=2C so I shouldn't think it would be something that you would turn to en= cryption for right? I feel this anyway.
From: Sergio Lerner<= br> Sent: =E2=80=8E17/=E2=80=8E03/=E2=80=8E2015 3:45 AM
To: bitcoin-d= evelopment@lists.sourceforge.net
Subject: [Bitcoin-development] "=3Bnetwork disruption as a service"=3B = and proof of local storage

The problem of pseudo-nodes will come over and ove= r. The cat and mouse
chase is just beginning.
It has been discussed some times that the easiest solution world be to
request some kind of resource consumption on each peer to be allowed to
connect to other peers.
Gmaxwell proposed Proof of Storage here:
https://bitcointalk.org/index.php?topic=3D310323.msg3332919#msg3332= 919

I proposed a (what I think) is better protocol for Proof of Storage that I call "=3BProof of Local storage"=3B here
https://bitslog.wordpress.com/2014/11/03/proof-of-local-blockc= hain-storage/
. It's better because it does not need the storage of additional data=2C but more importantly=2C it allows you to prove full copy of the blockchain<= br> is being maintained by the peer.
This is specially important now that Bitnodes is trying a full-node
incentive program that may be easily cheated
(http://qntra.net/2015/02/pseudonode-proxy-fools-bitc= oin-full-node-incentive-program/)

Proof of local storage allows a node to prove another peer that he is
storing a LOCAL copy of a PUBLIC file=2C such as the blockchain. So the
peer need not waste more resources (well=2C just some resources to
encode/decode the block-chain).
The main idea is to use what I called asymmetric-time-encoding.
Basically you encode the block-chain in a way that it takes 100 more
times to write it than to read it. Since the block-chain is an
append-only (write-only) file=2C this fit good for our needs. For instance<= br> (and as a simplification)=2C choosing a global 1024-bit prime=2C then
splitting the block-chain in 1024-bit blocks=2C and encrypting each block using Polihg-Hellman (modexp) with decryption exponent 3. =3B Then
encryption is at least 100 times slower than decryption. Before PH
encryption each node must xor each block with a pseudo-random mask
derived from the public IP and the block index. =3B So block encryption=
could be:
BlockEncryptIndex(i) =3D E(IP+=3Bi=2Cblock(i))^inv(3) (mod p)=2C

where inv(3) is 3^-1 mod (p-1). E() could be a fast tweaked encryption
routine (tweak =3D index)=2C but we only need the PRNG properties of E() an= d
that E() does share algebraic properties with P.H..

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 (+=3B-100 msec of network jitter).<= br> 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.

2. (prover pay a high cost=2C verified pays negligible cost). The verifier<= br> chooses a seed n=2C and then pre-computes the encrypted blocks derived
from the seed using the prover's IP. Then the verifier sends the =3B se= ed=2C
and the prover must respond with the hash of the encrypted blocks within a certain time bound. The proved does not require to do any PH
decryption=2C just take the encrypted blocks for indexes derived from the seed=2C hash them and send the hash back to the verifier. The verifier
validates the time bound and the hash.

Both protocols can me made available by the client=2C under different
states. For instance=2C new nodes are only allowed to request protocol 2 (and so they get an initial assurance their are connecting to
full-nodes). After a first-time mutual authentication=2C they are allowed to periodically perform protocol 1. Also new nodes may be allowed to
perform protocol 1 with a small index set=2C and increase the index set
over time=2C to get higher confidence.

The important difference between this protocol and classical remote
software attestation protocols=2C is that the time gap between a good peer<= br> and a malicious peer can be made arbitrarily high=2C picking a larger p. Maybe there is even another crypto primitive which is more asymmetric
than exponent 3 decryption (the LUC or NTRU cryptosystem?).

In GMaxwell proposal each peer builds a table for each other peer. In my proposal=2C each peer builds a single table (the encrypted blockchain)=2C s= o
it could be still possible to establish a thousands of connections to
the network from a single peer. Nevertheless=2C the attacker's IP will be easily detected (he cannot hide under a thousands different IPs). It's
also possible to restrict the challenge-response to a portion of the
block-chain=2C the portion offset being derived from the hash of both IP addresses and one random numbers provided by each peer. Suppose each
connection has a C-R space equivalent to 1% of the block-chain. Then
having 100 connections and responding to C-R on each connection means
storing approximate 1 copy of the block-chain (there may be overlaps=2C
which would need to be stored twice) =2C while having 1K connections would<= br> require storing 10 copies of the blockchain.


Best regards=2C
 =3BSergio


---------------------------------------------------------------------------= ---
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
--_736f674a-abbd-4e9c-b0dc-604efc5db805_--