To: bitcoin-dev@lists.linuxfoundation.org
References: <CAFVRnypbQQ-vsSLqv48cYaqTCty4R1DmFRqfAvxe4mAqyQNXxQ@mail.gmail.com>
	<2226058.Q8lHjYE4Pt@strawberry>
	<CAE-z3OVXLKqyBb3R5yzOYdnRALot4KUhJ53r9y2jXkf6Yt=KnA@mail.gmail.com>
From: Aymeric Vitte <vitteaymeric@gmail.com>
Message-ID: <ccb96920-4387-ed91-e03e-15f4b2772aa3@gmail.com>
Date: Wed, 19 Apr 2017 01:19:04 +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: <CAE-z3OVXLKqyBb3R5yzOYdnRALot4KUhJ53r9y2jXkf6Yt=KnA@mail.gmail.com>
Content-Type: multipart/alternative;
	boundary="------------1514DC795F898B236CF0BF5D"
Subject: Re: [bitcoin-dev] Small Nodes: A Better Alternative to Pruned Nodes
Precedence: list

This is a multi-part message in MIME format.
--------------1514DC795F898B236CF0BF5D
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit

From the initial post " The situation would likely become problematic
quickly if bitcoin-core were to ship with the defaults set to a pruned
node."

Sorry to be straight, I read the (painful) thread below, and most of
what is in there is inept, wrong, obsolete... or biased, cf the first
sentence above, if the idea is to invent a workaround to the fact that
pruning might/will become the default or might/will be set by the users
as the default so full nodes might/will disappear then just say it
clearly instead of proposing this kind of non-solution as a solution to
secure the blockchain

I can't believe this is serious, people now are supposed to prune but
will be forced to host a part of the blockchain, how do you expect this
to work, why people would do this? Knowing that to start pruning they
need a full node, then since we are there, why not continuing with a
full node... but indeed, why should they continue with a full node, and
therefore why should they accept to host a part of the blockchain if
they decline the first proposal?

This is absurd, you are not addressing the first priority given the
context which is to quickly increase the full nodes and which obviously
includes an incentive for people to run them

It gives also the feeling that bitcoin wants to reinvent everything not
capitalizing on/knowing what exists, sorry again but the concepts of the
proposal and others like archival nodes are just funny


Le 18/04/2017 à 15:07, Tier Nolan via bitcoin-dev a écrit :
> This has been discussed before.
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008101.html
>
> including a list of nice to have features by Maxwell
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008110.html
>
> You meet most of these rules, though you do have to download blocks
> from multiple peers.
>
> The suggestion in that thread were for a way to compactly indicate
> which blocks a node has.  Each node would then store a sub-set of all
> the blocks.  You just download the blocks you want from the node that
> has them.
>
> Each node would be recommended to store the last few days worth anyway.
>
>
> _______________________________________________
> 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


--------------1514DC795F898B236CF0BF5D
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <p>From the initial post " The situation would likely become
      problematic quickly if bitcoin-core were to ship with the defaults
      set to a pruned node."</p>
    <p>Sorry to be straight, I read the (painful) thread below, and most
      of what is in there is inept, wrong, obsolete... or biased, cf the
      first sentence above, if the idea is to invent a workaround to the
      fact that pruning might/will become the default or might/will be
      set by the users as the default so full nodes might/will disappear
      then just say it clearly instead of proposing this kind of
      non-solution as a solution to secure the blockchain<br>
    </p>
    <p>I can't believe this is serious, people now are supposed to prune
      but will be forced to host a part of the blockchain, how do you
      expect this to work, why people would do this? Knowing that to
      start pruning they need a full node, then since we are there, why
      not continuing with a full node... but indeed, why should they
      continue with a full node, and therefore why should they accept to
      host a part of the blockchain if they decline the first proposal?<br>
    </p>
    This is absurd, you are not addressing the first priority given the
    context which is to quickly increase the full nodes and which
    obviously includes an incentive for people to run them<br>
    <br>
    It gives also the feeling that bitcoin wants to reinvent everything
    not capitalizing on/knowing what exists, sorry again but the
    concepts of the proposal and others like archival nodes are just
    funny<br>
    <br>
    <br>
    <div class="moz-cite-prefix">Le 18/04/2017 à 15:07, Tier Nolan via
      bitcoin-dev a écrit :<br>
    </div>
    <blockquote
cite="mid:CAE-z3OVXLKqyBb3R5yzOYdnRALot4KUhJ53r9y2jXkf6Yt=KnA@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>
          <div>
            <div>
              <div>
                <div>
                  <div>
                    <div>This has been discussed before.<br>
                      <br>
                      <a moz-do-not-send="true"
href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008101.html">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008101.html</a><br>
                      <br>
                    </div>
                    including a list of nice to have features by Maxwell<br>
                    <br>
                    <a moz-do-not-send="true"
href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008110.html">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008110.html</a><br>
                    <br>
                  </div>
                </div>
              </div>
            </div>
            You meet most of these rules, though you do have to download
            blocks from multiple peers.<br>
            <br>
          </div>
          The suggestion in that thread were for a way to compactly
          indicate which blocks a node has.  Each node would then store
          a sub-set of all the blocks.  You just download the blocks you
          want from the node that has them.<br>
          <br>
        </div>
        Each node would be recommended to store the last few days worth
        anyway.<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>

--------------1514DC795F898B236CF0BF5D--