Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id B974798C for ; Thu, 20 Apr 2017 23:42:07 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wm0-f53.google.com (mail-wm0-f53.google.com [74.125.82.53]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A8DB6140 for ; Thu, 20 Apr 2017 23:42:05 +0000 (UTC) Received: by mail-wm0-f53.google.com with SMTP id o81so4335234wmb.1 for ; Thu, 20 Apr 2017 16:42:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=fAdYePRRNWVsGnnZTrmMk6oBkn0aZilnY4hXBsFPkUI=; b=EZBw8mhlo2D8rscwFfZfM1zq16gX7XvwDb2Wb8mZp8ZDSPA41kgLd4JwPDGmc6ueMK Dv3LqxsB3uduyMOvO6NNzeQJfIODvjwHS1MFHfyRAh5yk+UeAogjQR45AuJ+3Jvz9Uqy dR5/AYf+Vv8waX66qA2PhexBSgoJRL10JAweBUxQPwm+gGTi9jv0DLd1dQElb/UBHSS8 WvQ9kDibUmFIKs9ODrSZNAg/hPAnc+0gpXFnSK0qblszeddRE1Q4i5Na4w5kHC71mAAx 5t5dC8C42NioAq4AYnmkvtIPh7Jx6CrSUBmzcDxi4CJNZdhxf5B2b6TlwKzlT99UkSTj ToYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=fAdYePRRNWVsGnnZTrmMk6oBkn0aZilnY4hXBsFPkUI=; b=NiUXhgZrChaji7EE0vO1qEcbrV2HOykO/9pWydIUSe9IZy0kQy1pkGjTjEVd24Ntv4 bjK3keIPJSpZIYd+CcNv/8Aw5IojIOoQXpEZa7T7J6J4ckQIH6Cs3RHVThyYpg86vwO6 fKH+aUuQ/WOIvHXWalg0w8EV+VRKppSaErTuX4v75KrHDkaKj9Uib45KNlgYbK6tLaS+ xM/x3zd37FbVbo3rcza2QurAJQFFQNaEWKRYuhzdYrOdfMZJova+EVU9ANcbGZeHrwH5 yLxl/6rLYSBdkxva/bdbZ9psbYEHGViT8sY0yMzBHDeeBSG5oCjrmIWMPy33VUXnppXj Mowg== X-Gm-Message-State: AN3rC/7VID002+AMXAkNCTN9MDV8fPjU9ClYRBqhiXzPzZ8OAE/Y6564 2s5FneLHpDVJMGMs X-Received: by 10.28.56.1 with SMTP id f1mr5854761wma.20.1492731724093; Thu, 20 Apr 2017 16:42:04 -0700 (PDT) Received: from [192.168.1.10] (ANice-654-1-153-20.w86-205.abo.wanadoo.fr. [86.205.80.20]) by smtp.googlemail.com with ESMTPSA id v7sm4016824wrb.68.2017.04.20.16.42.02 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Apr 2017 16:42:03 -0700 (PDT) To: bitcoin-dev@lists.linuxfoundation.org References: From: Aymeric Vitte Message-ID: Date: Fri, 21 Apr 2017 01:42:03 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.3; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------AA5ADC5A396E498A58089402" X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Small Nodes: A Better Alternative to Pruned Nodes X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 23:42:07 -0000 This is a multi-part message in MIME format. --------------AA5ADC5A396E498A58089402 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit ??? what do you mean? (https://www.soyoustart.com/fr/serveurs-essential/) Le 20/04/2017 à 17:50, Erik Aronesty via bitcoin-dev a écrit : > Try to find 1TB dedicated server hosting ... > > If you want to set up an ecommerce site somewhere besides your living > room, storage costs are still a concern. > > On Mon, Apr 17, 2017 at 3:11 AM, Danny Thorpe via bitcoin-dev > > wrote: > > 1TB HDD is now available for under $40 USD. How is the 100GB > storage requirement preventing anyone from setting up full nodes? > > On Apr 16, 2017 11:55 PM, "David Vorick via bitcoin-dev" > > wrote: > > *Rationale:* > > A node that stores the full blockchain (I will use the term > archival node) requires over 100GB of disk space, which I > believe is one of the most significant barriers to more people > running full nodes. And I believe the ecosystem would benefit > substantially if more users were running full nodes. > > The best alternative today to storing the full blockchain is > to run a pruned node, which keeps only the UTXO set and throws > away already verified blocks. The operator of the pruned node > is able to enjoy the full security benefits of a full node, > but is essentially leeching the network, as they performed a > large download likely without contributing anything back. > > This puts more pressure on the archival nodes, as the archival > nodes need to pick up the slack and help new nodes bootstrap > to the network. As the pressure on archival nodes grows, fewer > people will be able to actually run archival nodes, and the > situation will degrade. The situation would likely become > problematic quickly if bitcoin-core were to ship with the > defaults set to a pruned node. > > Even further, the people most likely to care about saving > 100GB of disk space are also the people least likely to care > about some extra bandwidth usage. For datacenter nodes, and > for nodes doing lots of bandwidth, the bandwidth is usually > the biggest cost of running the node. For home users however, > as long as they stay under their bandwidth cap, the bandwidth > is actually free. Ideally, new nodes would be able to > bootstrap from nodes that do not have to pay for their > bandwidth, instead of needing to rely on a decreasing > percentage of heavy-duty archival nodes. > > I have (perhaps incorrectly) identified disk space consumption > as the most significant factor in your average user choosing > to run a pruned node or a lite client instead of a full node. > The average user is not typically too worried about bandwidth, > and is also not typically too worried about initial blockchain > download time. But the 100GB hit to your disk space can be a > huge psychological factor, especially if your hard drive only > has 500GB available in the first place, and 250+ GB is already > consumed by other files you have. > > I believe that improving the disk usage situation would > greatly benefit decentralization, especially if it could be > done without putting pressure on archival nodes. > > *Small Nodes Proposal:* > > I propose an alternative to the pruned node that does not put > undue pressure on archival nodes, and would be acceptable and > non-risky to ship as a default in bitcoin-core. For lack of a > better name, I'll call this new type of node a 'small node'. > The intention is that bitcoin-core would eventually ship > 'small nodes' by default, such that the expected amount of > disk consumption drops from today's 100+ GB to less than 30 GB. > > My alternative proposal has the following properties: > > + Full nodes only need to store ~20% of the blockchain > + With very high probability, a new node will be able to > recover the entire blockchain by connecting to 6 random small > node peers. > + An attacker that can eliminate a chosen+ 95% of the full > nodes running today will be unable to prevent new nodes from > downloading the full blockchain, even if the attacker is also > able to eliminate all archival nodes. (assuming all nodes > today were small nodes instead of archival nodes) > > Method: > > A small node will pick an index [5, 256). This index is that > node's permanent index. When storing a block, instead of > storing the full block, the node will use Reed-Solomon coding > to erasure code the block using a 5-of-256 scheme. The result > will be 256 pieces that are 20% of the size of the block each. > The node picks the piece that corresponds to its index, and > stores that instead. (Indexes 0-4 are reserved for archival > nodes - explained later) > > The node is now storing a fragment of every block. Alone, this > fragment cannot be used to recover any piece of the > blockchain. However, when paired with any 5 unique fragments > (fragments of the same index will not be unique), the full > block can be recovered. > > Nodes can optionally store more than 1 fragment each. At 5 > fragments, the node becomes a full archival node, and the > chosen indexes should be 0-4. This is advantageous for the > archival node as the encoded data for the first 5 indexes will > actually be identical to the block itself - there is no > computational overhead for selecting the first indexes. There > is also no need to choose random indexes, because the full > block can be recovered no matter which indexes are chosen. > > When connecting to new peers, the indexes of each peer needs > to be known. Once peers totaling 5 unique indexes are > discovered, blockchain download can begin. Connecting to just > 5 small node peers provides a >95% chance of getting 5 > uniques, with exponentially improving odds of success as you > connect to more peers. Connecting to a single archive node > guarantees that any gaps can be filled. > > A good encoder should be able to turn a block into a 5-of-256 > piece set in under 10 milliseconds using a single core on a > standard consumer desktop. This should not slow down initial > blockchain download substantially, though the overhead is more > than a rounding error. > > *DoS Prevention:* > > A malicious node may provide garbage data instead of the > actual piece. Given just the garbage data and 4 other correct > pieces, it is impossible (best I know anyway) to tell which > piece is the garbage piece. > > One option in this case would be to seek out an archival node > that could verify the correctness of the pieces, and identify > the malicious node. > > Another option would be to have the small nodes store a > cryptographic checksum of each piece. Obtaining the > cryptographic checksum for all 256 pieces would incur a > nontrivial amount of hashing (post segwit, as much as 100MB of > extra hashing per block), and would require an additional ~4kb > of storage per block. The hashing overhead here may be > prohibitive. > > Another solution would be to find additional pieces and > brute-force combinations of 5 until a working combination was > discovered. Though this sounds nasty, it should take less than > five seconds of computation to find the working combination > given 5 correct pieces and 2 incorrect pieces. This > computation only needs to be performed once to identify the > malicious peers. > > I also believe that alternative erasure coding schemes exist > which actually are able to identify the bad pieces given > sufficient good pieces, however I don't know if they have the > same computational performance as the best Reed-Solomon coding > implementations. > > *Deployment:* > > Small nodes are completely useless unless the critical mass of > 5 pieces can be obtained. The first version that supports > small node block downloads should default everyone to an > archival node (meaning indexes 0-4 are used) > > Once there are enough small-node-enabled archive nodes, the > default can be switched so that nodes only have a single index > by default. In the first few days, when there are only a few > small nodes, the previously-deployed archival nodes can help > fill in the gaps, and the small nodes can be useful for > blockchain download right away. > > ---------------------------------- > > This represents a non-trivial amount of code, but I believe > that the result would be a non-trivial increase in the > percentage of users running full nodes, and a healthier > overall network. > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev -- Zcash wallets made simple: https://github.com/Ayms/zcash-wallets Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets Get the torrent dynamic blocklist: http://peersm.com/getblocklist Check the 10 M passwords list: http://peersm.com/findmyass Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org Peersm : http://www.peersm.com torrent-live: https://github.com/Ayms/torrent-live node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms --------------AA5ADC5A396E498A58089402 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

??? what do you mean? (https://www.soyoustart.com/fr/serveurs-essential/)


Le 20/04/2017 à 17:50, Erik Aronesty via bitcoin-dev a écrit :
Try to find 1TB dedicated server hosting ...

If you want to set up an ecommerce site somewhere besides your living room, storage costs are still a concern.

On Mon, Apr 17, 2017 at 3:11 AM, Danny Thorpe via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
1TB HDD is now available for under $40 USD.  How is the 100GB storage requirement preventing anyone from setting up full nodes?

On Apr 16, 2017 11:55 PM, "David Vorick via bitcoin-dev" <bitcoin-dev@lists.linuxfoundation.org> wrote:
Rationale:

A node that stores the full blockchain (I will use the term archival node) requires over 100GB of disk space, which I believe is one of the most significant barriers to more people running full nodes. And I believe the ecosystem would benefit substantially if more users were running full nodes.

The best alternative today to storing the full blockchain is to run a pruned node, which keeps only the UTXO set and throws away already verified blocks. The operator of the pruned node is able to enjoy the full security benefits of a full node, but is essentially leeching the network, as they performed a large download likely without contributing anything back.

This puts more pressure on the archival nodes, as the archival nodes need to pick up the slack and help new nodes bootstrap to the network. As the pressure on archival nodes grows, fewer people will be able to actually run archival nodes, and the situation will degrade. The situation would likely become problematic quickly if bitcoin-core were to ship with the defaults set to a pruned node.

Even further, the people most likely to care about saving 100GB of disk space are also the people least likely to care about some extra bandwidth usage. For datacenter nodes, and for nodes doing lots of bandwidth, the bandwidth is usually the biggest cost of running the node. For home users however, as long as they stay under their bandwidth cap, the bandwidth is actually free. Ideally, new nodes would be able to bootstrap from nodes that do not have to pay for their bandwidth, instead of needing to rely on a decreasing percentage of heavy-duty archival nodes.

I have (perhaps incorrectly) identified disk space consumption as the most significant factor in your average user choosing to run a pruned node or a lite client instead of a full node. The average user is not typically too worried about bandwidth, and is also not typically too worried about initial blockchain download time. But the 100GB hit to your disk space can be a huge psychological factor, especially if your hard drive only has 500GB available in the first place, and 250+ GB is already consumed by other files you have.

I believe that improving the disk usage situation would greatly benefit decentralization, especially if it could be done without putting pressure on archival nodes.

Small Nodes Proposal:

I propose an alternative to the pruned node that does not put undue pressure on archival nodes, and would be acceptable and non-risky to ship as a default in bitcoin-core. For lack of a better name, I'll call this new type of node a 'small node'. The intention is that bitcoin-core would eventually ship 'small nodes' by default, such that the expected amount of disk consumption drops from today's 100+ GB to less than 30 GB.

My alternative proposal has the following properties:

+ Full nodes only need to store ~20% of the blockchain
+ With very high probability, a new node will be able to recover the entire blockchain by connecting to 6 random small node peers.
+ An attacker that can eliminate a chosen+ 95% of the full nodes running today will be unable to prevent new nodes from downloading the full blockchain, even if the attacker is also able to eliminate all archival nodes. (assuming all nodes today were small nodes instead of archival nodes)

Method:

A small node will pick an index [5, 256). This index is that node's permanent index. When storing a block, instead of storing the full block, the node will use Reed-Solomon coding to erasure code the block using a 5-of-256 scheme. The result will be 256 pieces that are 20% of the size of the block each. The node picks the piece that corresponds to its index, and stores that instead. (Indexes 0-4 are reserved for archival nodes - explained later)

The node is now storing a fragment of every block. Alone, this fragment cannot be used to recover any piece of the blockchain. However, when paired with any 5 unique fragments (fragments of the same index will not be unique), the full block can be recovered.

Nodes can optionally store more than 1 fragment each. At 5 fragments, the node becomes a full archival node, and the chosen indexes should be 0-4. This is advantageous for the archival node as the encoded data for the first 5 indexes will actually be identical to the block itself - there is no computational overhead for selecting the first indexes. There is also no need to choose random indexes, because the full block can be recovered no matter which indexes are chosen.

When connecting to new peers, the indexes of each peer needs to be known. Once peers totaling 5 unique indexes are discovered, blockchain download can begin. Connecting to just 5 small node peers provides a >95% chance of getting 5 uniques, with exponentially improving odds of success as you connect to more peers. Connecting to a single archive node guarantees that any gaps can be filled.

A good encoder should be able to turn a block into a 5-of-256 piece set in under 10 milliseconds using a single core on a standard consumer desktop. This should not slow down initial blockchain download substantially, though the overhead is more than a rounding error.

DoS Prevention:

A malicious node may provide garbage data instead of the actual piece. Given just the garbage data and 4 other correct pieces, it is impossible (best I know anyway) to tell which piece is the garbage piece.

One option in this case would be to seek out an archival node that could verify the correctness of the pieces, and identify the malicious node.

Another option would be to have the small nodes store a cryptographic checksum of each piece. Obtaining the cryptographic checksum for all 256 pieces would incur a nontrivial amount of hashing (post segwit, as much as 100MB of extra hashing per block), and would require an additional ~4kb of storage per block. The hashing overhead here may be prohibitive.

Another solution would be to find additional pieces and brute-force combinations of 5 until a working combination was discovered. Though this sounds nasty, it should take less than five seconds of computation to find the working combination given 5 correct pieces and 2 incorrect pieces. This computation only needs to be performed once to identify the malicious peers.

I also believe that alternative erasure coding schemes exist which actually are able to identify the bad pieces given sufficient good pieces, however I don't know if they have the same computational performance as the best Reed-Solomon coding implementations.

Deployment:

Small nodes are completely useless unless the critical mass of 5 pieces can be obtained. The first version that supports small node block downloads should default everyone to an archival node (meaning indexes 0-4 are used)

Once there are enough small-node-enabled archive nodes, the default can be switched so that nodes only have a single index by default. In the first few days, when there are only a few small nodes, the previously-deployed archival nodes can help fill in the gaps, and the small nodes can be useful for blockchain download right away.

----------------------------------

This represents a non-trivial amount of code, but I believe that the result would be a non-trivial increase in the percentage of users running full nodes, and a healthier overall network.

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev




_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


-- 
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
--------------AA5ADC5A396E498A58089402--