<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>While I fully agree with the intent (increasing full nodes so a
big miner waking up in a bad mood can't threaten the world any
longer every day as it is now) I am not sure to get the interest
of this proposal, because:</p>
<p>- it's probably not a good idea to encourage the home users to
run full nodes, there are many people running servers far from
their capacity that could easily run efficient full nodes<br>
</p>
<p>- if someone can't allocate 100 GB today to run a full node, then
we can't expect him to allocate more in the future</p>
<p>- the download time is a real concern</p>
<p>- this proposal is a kind of reinventing torrents, while limiting
the number of connections to something not efficient at all, I
don't see why something that is proven to be super efficient
(torrents) would be needed to be reinvented, I am not saying that
it should be used as the bittorrent network is doing but the
concepts can be reused</p>
<p>- I don't get at all the concept of "archival" nodes since it's
another useless step toward centralization</p>
<p>I think the only way to increase full nodes it to design an
incentive for people to run them<br>
</p>
<br>
<div class="moz-cite-prefix">Le 17/04/2017 à 08:54, David Vorick via
bitcoin-dev a écrit :<br>
</div>
<blockquote
cite="mid:CAFVRnypbQQ-vsSLqv48cYaqTCty4R1DmFRqfAvxe4mAqyQNXxQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div><b>Rationale:</b><br>
</div>
<div><br>
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.<br>
<br>
</div>
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.<br>
<br>
</div>
<div>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.<br>
<br>
</div>
<div>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.<br>
<br>
</div>
<div>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.<br>
<br>
</div>
<div>I believe that improving the disk usage situation would
greatly benefit decentralization, especially if it could be
done without putting pressure on archival nodes.<br>
</div>
<div><br>
</div>
<div><b>Small Nodes Proposal:</b><br>
<br>
</div>
<div>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.<br>
<br>
</div>
<div>My alternative proposal has the following properties:<br>
<br>
</div>
<div>+ Full nodes only need to store ~20% of the blockchain<br>
</div>
<div>+ With very high probability, a new node will be able to
recover the entire blockchain by connecting to 6 random small
node peers.<br>
</div>
<div>+ 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)<br>
<br>
</div>
<div>Method:<br>
<br>
</div>
<div>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)<br>
<br>
</div>
<div>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.<br>
<br>
</div>
<div>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.<br>
<br>
</div>
<div>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.<br>
<br>
</div>
<div>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.<br>
</div>
<div><br>
</div>
<div><b>DoS Prevention:</b><br>
<br>
</div>
<div>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.<br>
<br>
</div>
<div>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.<br>
<br>
</div>
<div>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.<br>
<br>
</div>
<div>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.<br>
<br>
</div>
<div>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.<br>
</div>
<br>
<div><b>Deployment:</b><br>
<br>
</div>
<div>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)<br>
<br>
</div>
<div>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.<br>
<br>
----------------------------------<br>
<br>
</div>
<div>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.<br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
bitcoin-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>
<a class="moz-txt-link-freetext" href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Zcash wallets made simple: <a class="moz-txt-link-freetext" href="https://github.com/Ayms/zcash-wallets">https://github.com/Ayms/zcash-wallets</a>
Bitcoin wallets made simple: <a class="moz-txt-link-freetext" href="https://github.com/Ayms/bitcoin-wallets">https://github.com/Ayms/bitcoin-wallets</a>
Get the torrent dynamic blocklist: <a class="moz-txt-link-freetext" href="http://peersm.com/getblocklist">http://peersm.com/getblocklist</a>
Check the 10 M passwords list: <a class="moz-txt-link-freetext" href="http://peersm.com/findmyass">http://peersm.com/findmyass</a>
Anti-spies and private torrents, dynamic blocklist: <a class="moz-txt-link-freetext" href="http://torrent-live.org">http://torrent-live.org</a>
Peersm : <a class="moz-txt-link-freetext" href="http://www.peersm.com">http://www.peersm.com</a>
torrent-live: <a class="moz-txt-link-freetext" href="https://github.com/Ayms/torrent-live">https://github.com/Ayms/torrent-live</a>
node-Tor : <a class="moz-txt-link-freetext" href="https://www.github.com/Ayms/node-Tor">https://www.github.com/Ayms/node-Tor</a>
GitHub : <a class="moz-txt-link-freetext" href="https://www.github.com/Ayms">https://www.github.com/Ayms</a></pre>
</body>
</html>