<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <p>??? what do you mean?
      (<a class="moz-txt-link-freetext" href="https://www.soyoustart.com/fr/serveurs-essential/">https://www.soyoustart.com/fr/serveurs-essential/</a>)<br>
    </p>
    <br>
    <div class="moz-cite-prefix">Le 20/04/2017 à 17:50, Erik Aronesty
      via bitcoin-dev a écrit :<br>
    </div>
    <blockquote
cite="mid:CAJowKg++8GD3gE15pdwe0Bj-L0A6MAzG0_uTSLASaRT9yVb1aQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">Try to find 1TB dedicated server hosting ... <br>
        <br>
        If you want to set up an ecommerce site somewhere besides your
        living room, storage costs are still a concern.<br>
      </div>
      <div class="gmail_extra"><br>
        <div class="gmail_quote">On Mon, Apr 17, 2017 at 3:11 AM, Danny
          Thorpe via bitcoin-dev <span dir="ltr">&lt;<a
              moz-do-not-send="true"
              href="mailto:bitcoin-dev@lists.linuxfoundation.org"
              target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div dir="auto">1TB HDD is now available for under <span
                class="m_2752087275107902543money">$40</span> USD.  How
              is the 100GB storage requirement preventing anyone from
              setting up full nodes?</div>
            <div class="gmail_extra"><br>
              <div class="gmail_quote">
                <div>
                  <div class="h5">On Apr 16, 2017 11:55 PM, "David
                    Vorick via bitcoin-dev" &lt;<a
                      moz-do-not-send="true"
                      href="mailto:bitcoin-dev@lists.linuxfoundation.org"
                      target="_blank">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>&gt;
                    wrote:<br type="attribution">
                  </div>
                </div>
                <blockquote class="gmail_quote" style="margin:0 0 0
                  .8ex;border-left:1px #ccc solid;padding-left:1ex">
                  <div>
                    <div class="h5">
                      <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 &gt;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>
                          ------------------------------<wbr>----<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>
                    </div>
                  </div>
                  ______________________________<wbr>_________________<br>
                  bitcoin-dev mailing list<br>
                  <a moz-do-not-send="true"
                    href="mailto:bitcoin-dev@lists.linuxfoundation.org"
                    target="_blank">bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br>
                  <a moz-do-not-send="true"
                    href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev"
                    rel="noreferrer" target="_blank">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-d<wbr>ev</a><br>
                  <br>
                </blockquote>
              </div>
            </div>
            <br>
            ______________________________<wbr>_________________<br>
            bitcoin-dev mailing list<br>
            <a moz-do-not-send="true"
              href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a><br>
            <a moz-do-not-send="true"
              href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev"
              rel="noreferrer" target="_blank">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
            <br>
          </blockquote>
        </div>
        <br>
      </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>