path: root/a5/fc26761161669aa4b2997d90136225e0f12cb3

Return-Path: <vitteaymeric@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id AA6A4A7F
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 26 Sep 2017 09:22:00 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f43.google.com (mail-wm0-f43.google.com [74.125.82.43])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 048D11AE
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 26 Sep 2017 09:21:58 +0000 (UTC)
Received: by mail-wm0-f43.google.com with SMTP id r136so5596253wmf.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 26 Sep 2017 02:21:58 -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:content-language;
	bh=JSezf9F8Fh8Y8zrXk15MYV1JaA3AfKyhjAgsZvr3p7Y=;
	b=jon81yUqQQCEjB+rmBD/8M0v8ukM4Dp83i/sSOdqO1UAsxgiNcbWunKBPlwK61isuQ
	2xc7geIvHd0/Ys5ZGp522UpHhxMD5R/l5k22uwH2yYLp1HD/7EpKFXRLcScrb8J2y3Fl
	zqkaJkwOk5zfmrNFvlwc2ms5jHgdTLLvQ31FlQV//zhsG9B+imVzyZfZSmA1kDPRE6OJ
	9Ptj+U/GpM7iUvc4W2NeIoLD7qBHezuErqax/+GbfeB1IFgGFZf//PVgPbXqRy3p0gL7
	Djz4TTKzsMKFyOlDfSOUEBQ1t4g1TdbMlq0JgPa6Pog+FmTcMtw4osCNhkliAvLY02zj
	Oouw==
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:content-language;
	bh=JSezf9F8Fh8Y8zrXk15MYV1JaA3AfKyhjAgsZvr3p7Y=;
	b=GVUMNsiZ+rFKvULB2NfGmumT7madDMoOw7BItpEeShqapDryFcjMyUBT1CptBmyGHz
	Tsk7NusVIdGW7k0gMdpkx1AMk+viRV+x7ulZ8tmeT3F44pyTYP5AwaAAsOt0fpb5u5SI
	Oll9UIaaeT19rsgjKUt8Xh5HxzkHpQCnNBxgImj+QfpvPfVH2zoQrkE6wp3yWMcqcLGn
	2wlC/dliUXqwBUvqp76ARuFfWW6goKs8sYaU7hxuk4PAH7jcAmLQRnYQc/iNYkEbyEI8
	DwdFYEUtQqw7hUlTqctXdh7WTsIu1PXiemk6C9xxD8wiU48bX8tK5OSghhSQZQFWGh5P
	8DDg==
X-Gm-Message-State: AHPjjUjWtLiolDB5XftR6/lhK5jZQ+IXXCloqaF3FEmnguxc4aLdLZvK
	EK04e+UEwQlaLIUediKlKfg=
X-Google-Smtp-Source: AOwi7QDdCLTyZi8w84u0ArnWbeWpLKXhxmMU5XWGGNFetvIHnwsQL+2xqyyAK8QKXkXa+zqHAtwq1Q==
X-Received: by 10.80.149.236 with SMTP id x41mr16511622eda.4.1506417717626;
	Tue, 26 Sep 2017 02:21:57 -0700 (PDT)
Received: from [192.168.1.10] (ANice-654-1-109-22.w86-203.abo.wanadoo.fr.
	[86.203.44.22]) by smtp.googlemail.com with ESMTPSA id
	f9sm5642310ede.38.2017.09.26.02.21.56
	(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 26 Sep 2017 02:21:56 -0700 (PDT)
To: Patrick Sharp <psharp.x13@gmail.com>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
	ZmnSCPxj <ZmnSCPxj@protonmail.com>
References: <CAES+R-qpBwXdROKnXW0idierJYf7pSRe3Z=KSYvcGwB_S6nXrA@mail.gmail.com>
	<9Rdn-Mm90LWD4Tk_F0x04feUwKQp3nL8yTou9435kqjPCwjXWzNXsYTbWDA8YvO4p6_jBu1sFXEAa1ybvtcIrOqbv7qkghwENdHch6n_EEM=@protonmail.com>
	<CAES+R-rWiyn65+HYadu+OVBuG0zDeuw+0GN404rZ233CSEFVxA@mail.gmail.com>
From: Aymeric Vitte <vitteaymeric@gmail.com>
Message-ID: <883ac262-1de8-ac16-f57d-90c683da9e7d@gmail.com>
Date: Tue, 26 Sep 2017 00:43:02 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.3; rv:52.0) Gecko/20100101
	Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <CAES+R-rWiyn65+HYadu+OVBuG0zDeuw+0GN404rZ233CSEFVxA@mail.gmail.com>
Content-Type: multipart/alternative;
	boundary="------------1BD8B99E9399710B50A86F2D"
Content-Language: fr
X-Spam-Status: No, score=1.5 required=5.0 tests=DATE_IN_PAST_06_12, DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE, 
	RCVD_IN_SORBS_SPAM autolearn=disabled version=3.3.1
X-Spam-Level: *
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] idea post: trimming and demurrage
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Sep 2017 09:22:00 -0000

This is a multi-part message in MIME format.
--------------1BD8B99E9399710B50A86F2D
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

Maybe I missed or did not receive some messages, where was your
centralization concern addressed in the discussion?


Le 26/09/2017 à 03:33, Patrick Sharp via bitcoin-dev a écrit :
> Thank you for your responses. I have been enlightened. For the time
> being the combination of the UTXO's and pruning will accomplish what I
> desire. I suspect that there will come a time when the UTXO database
> becomes too large, but I guess that is a problem for another day. If
> that day ever comes 10 years was just an example, like you said there
> are reasons to preserve value beyond that point, perhaps a human
> lifetime or two would be a better choice.
>
> Side question: wouldn't it be a good idea to store the hash of the
> current or previous UTXO's in the block header so that pruned nodes
> can verify their UTXO's are accurate without having to check the full
> chain? and/or maybe include a snap shot of the UTXO's every x blocks?
>
> You guys are totally awesome!!!
>
> I here by withdraw my proposal for the time being.
>
> On Mon, Sep 25, 2017 at 5:34 PM, ZmnSCPxj <ZmnSCPxj@protonmail.com
> <mailto:ZmnSCPxj@protonmail.com>> wrote:
>
>     Good morning Patrick,
>
>     Demurrage is simply impossible.
>
>     In Bitcoin we already have implemented OP_CHECKLOCKTIMEVERIFY.
>
>     This opcode requires that a certain block height or date has
>     passed before the output can be spent.
>
>     It can be used to make an "in trust for" address, where you
>     disallow spending of that address.  For example, you may have a
>     child to whom you wish to dedicate some inheritance to, and ensure
>     that the child will not spend it recklessly until they achieve
>     some age (when hopefully they would be more mature), regardless of
>     what happens to you.
>
>     If I made a P2SH address with OP_CHECKLOCKTIMEVERIFY that allows
>     spending 18 years from birth of my child, and then suddenly
>     Bitcoin Core announces demurrage, I would be very angry.
>
>     OP_CHECKLOCKTIMEVERIFY cannot be countermanded, and it would be
>     impossible to refresh the UTXO's as required by demurrage, without
>     requiring a hardfork that ignores OP_CHECKLOCKTIMEVERIFY.
>
>     It would be better to put such additional features as demurrage in
>     a sidechain rather than on mainchain.
>
>
>     Regards,
>     ZmnSCPxj
>
>     -------- Original Message --------
>     Subject: [bitcoin-dev] idea post: trimming and demurrage
>     Local Time: September 25, 2017 9:54 PM
>     UTC Time: September 25, 2017 9:54 PM
>     From: bitcoin-dev@lists.linuxfoundation.org
>     <mailto:bitcoin-dev@lists.linuxfoundation.org>
>     To: bitcoin-dev@lists.linuxfoundation.org
>     <mailto:bitcoin-dev@lists.linuxfoundation.org>
>
>     Hello Devs,
>
>     I am Patrick Sharp. I just graduated with a BS is computer
>     science. Forgive my ignorance.
>
>     As per bip-0002 I have scoured each bip available on the wiki to
>     see if these ideas have already been formally proposed and now as
>     per bip-0002 post these ideas here.
>
>     First and foremost I acknowledge that these ideas are not original
>     nor new.
>
>     Trimming and demurrage:
>
>     I am fully aware that demurrage is a prohibited change. I hereby
>     contest. For the record I am not a miner, I am just aware of the
>     economics that drive the costs of bitcoin.
>
>     Without the ability to maintain some sort of limit on the maximum
>     length or size of the block chain, block chain is not only
>     unsustainable in the long run but becomes more and more
>     centralized as the block chain becomes more and more unwieldy.
>
>     Trimming is not a foreign concept. Old block whose transactions
>     are now spent hold no real value. Meaningful trimming is expensive
>     and inhibited by unspent transactions. Old unspent transactions
>     add unnecessary and unfair burden.
>     Old transactions take up real world space that continues incur
>     cost while these transactions they do not continue to contribute
>     to any sort of payment for this cost.
>     One can assume that anybody with access to their bitcoins has the
>     power to move these bitcoins from one address to another (or at
>     least that the software that holds the keys to their coins can do
>     it for them) and it is not unfair to require them to do so at
>     least once every 5 to 10 years.
>     Given the incentive to move it or lose it and software that will
>     do it for them, we can assume that any bitcoin not moved is most
>     likey therefore lost.
>     moving these coins will cost a small transaction fee which is fair
>     as their transactions take up space, they need to contribute
>     most people who use their coins regularly will not even need to
>     worry about this as their coins are moved to a change address anyway.
>     one downside is that paper wallets would then have an expiration
>     date, however I do not think that a paper wallet that needs to be
>     recycled every 5 to 10 years is a terrible idea.
>     Therefore I propose that the block chain length be limited to
>     either 2^18 blocks (slightly less than 5 years) or 2^19 blocks, or
>     slightly less than 10 years. I propose that each time a block is
>     mined the the oldest block(s) (no more than two blocks) beyond
>     this limit is trimmed from the chain and that its unspent
>     transactions are allowed to be included in the reward of the mined
>     block.
>
>     This keeps the block chain from tending towards infinity. This
>     keeps the costs of the miners balanced with the costs of the users.
>
>     Even though I believe this idea will have some friction, it is
>     applicable to the entire community. It will be hard for some users
>     to give up small benefits that they get at the great cost of
>     miners, however miners run the game and this fair proposal is in
>     in their best interest in two different ways. I would like your
>     thoughts and suggestions. I obviously think this is a freaking
>     awesome idea. I know it is quite controversial but it is the next
>     step in evolution that bitcoin needs to take to ensure immortality.
>
>     I come to you to ask if this has any chance of acceptance.
>
>     -Patrick
>
>
>
>
> _______________________________________________
> 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


--------------1BD8B99E9399710B50A86F2D
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>Maybe I missed or did not receive some messages, where was your
      centralization concern addressed in the discussion?<br>
    </p>
    <br>
    <div class="moz-cite-prefix">Le 26/09/2017 à 03:33, Patrick Sharp
      via bitcoin-dev a écrit :<br>
    </div>
    <blockquote type="cite"
cite="mid:CAES+R-rWiyn65+HYadu+OVBuG0zDeuw+0GN404rZ233CSEFVxA@mail.gmail.com">
      <div dir="ltr">
        <div style=""><span style="font-size:12.8px">Thank you for your
            responses. I have been enlightened. For the time being the
            combination of the UTXO's and pruning will accomplish what I
            desire. I suspect that there will come a time when the UTXO
            database becomes too large, but I guess that is a problem
            for another day. If that day ever comes 10 years was just an
            example, like you said there are reasons to preserve value
            beyond that point, perhaps a human lifetime or two would be
            a better choice.</span></div>
        <div style="font-size:12.8px"><span style="font-size:12.8px"><br>
          </span></div>
        <div style="font-size:12.8px">Side question: wouldn't it be a
          good idea to store the hash of the current or previous UTXO's
          in the block header so that pruned nodes can verify their
          UTXO's are accurate without having to check the full chain?
          and/or maybe include a snap shot of the UTXO's every x blocks?</div>
        <div style="font-size:12.8px"><br>
        </div>
        <div style="font-size:12.8px"><span style="font-size:12.8px">You
            guys are totally awesome!!!</span></div>
        <div style="font-size:12.8px"><br>
        </div>
        <div style="font-size:12.8px">I here by withdraw my proposal for
          the time being.</div>
      </div>
      <div class="gmail_extra"><br>
        <div class="gmail_quote">On Mon, Sep 25, 2017 at 5:34 PM,
          ZmnSCPxj <span dir="ltr">&lt;<a
              href="mailto:ZmnSCPxj@protonmail.com" target="_blank"
              moz-do-not-send="true">ZmnSCPxj@protonmail.com</a>&gt;</span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">Good
            morning Patrick,<br>
            <br>
            Demurrage is simply impossible.<br>
            <br>
            In Bitcoin we already have implemented
            OP_CHECKLOCKTIMEVERIFY.<br>
            <br>
            This opcode requires that a certain block height or date has
            passed before the output can be spent.<br>
            <br>
            It can be used to make an "in trust for" address, where you
            disallow spending of that address.  For example, you may
            have a child to whom you wish to dedicate some inheritance
            to, and ensure that the child will not spend it recklessly
            until they achieve some age (when hopefully they would be
            more mature), regardless of what happens to you.<br>
            <br>
            If I made a P2SH address with OP_CHECKLOCKTIMEVERIFY that
            allows spending 18 years from birth of my child, and then
            suddenly Bitcoin Core announces demurrage, I would be very
            angry.<br>
            <br>
            OP_CHECKLOCKTIMEVERIFY cannot be countermanded, and it would
            be impossible to refresh the UTXO's as required by
            demurrage, without requiring a hardfork that ignores
            OP_CHECKLOCKTIMEVERIFY.<br>
            <br>
            It would be better to put such additional features as
            demurrage in a sidechain rather than on mainchain.<br>
            <div><br>
            </div>
            <div><br>
            </div>
            <div>Regards,<br>
            </div>
            <div>ZmnSCPxj<br>
            </div>
            <div class="HOEnZb">
              <div class="h5">
                <div><br>
                </div>
                <div>-------- Original Message --------<br>
                </div>
                <div>Subject: [bitcoin-dev] idea post: trimming and
                  demurrage<br>
                </div>
                <div>Local Time: September 25, 2017 9:54 PM<br>
                </div>
                <div>UTC Time: September 25, 2017 9:54 PM<br>
                </div>
                <div>From: <a
                    href="mailto:bitcoin-dev@lists.linuxfoundation.org"
                    target="_blank" moz-do-not-send="true">bitcoin-dev@lists.<wbr>linuxfoundation.org</a><br>
                </div>
                <div>To: <a
                    href="mailto:bitcoin-dev@lists.linuxfoundation.org"
                    target="_blank" moz-do-not-send="true">bitcoin-dev@lists.<wbr>linuxfoundation.org</a><br>
                </div>
                <div><br>
                </div>
                <div>Hello Devs,<br>
                </div>
                <div><br>
                </div>
                <div>I am Patrick Sharp. I just graduated with a BS is
                  computer science. Forgive my ignorance.<br>
                </div>
                <div><br>
                </div>
                <div>As per bip-0002 I have scoured each bip available
                  on the wiki to see if these ideas have already been
                  formally proposed and now as per bip-0002 post these
                  ideas here.<br>
                </div>
                <div><br>
                </div>
                <div>First and foremost I acknowledge that these ideas
                  are not original nor new.<br>
                </div>
                <div><br>
                </div>
                <div>Trimming and demurrage:<br>
                </div>
                <div><br>
                </div>
                <div>I am fully aware that demurrage is a prohibited
                  change. I hereby contest. For the record I am not a
                  miner, I am just aware of the economics that drive the
                  costs of bitcoin.<br>
                </div>
                <div><br>
                </div>
                <div>Without the ability to maintain some sort of limit
                  on the maximum length or size of the block chain,
                  block chain is not only unsustainable in the long run
                  but becomes more and more centralized as the block
                  chain becomes more and more unwieldy.<br>
                </div>
                <div><br>
                </div>
                <div>Trimming is not a foreign concept. Old block whose
                  transactions are now spent hold no real value.
                  Meaningful trimming is expensive and inhibited by
                  unspent transactions. Old unspent transactions add
                  unnecessary and unfair burden.<br>
                </div>
                <div>Old transactions take up real world space that
                  continues incur cost while these transactions they do
                  not continue to contribute to any sort of payment for
                  this cost.<br>
                </div>
                <div>One can assume that anybody with access to their
                  bitcoins has the power to move these bitcoins from one
                  address to another (or at least that the software that
                  holds the keys to their coins can do it for them) and
                  it is not unfair to require them to do so at least
                  once every 5 to 10 years.<br>
                </div>
                <div>Given the incentive to move it or lose it and
                  software that will do it for them, we can assume that
                  any bitcoin not moved is most likey therefore lost.<br>
                </div>
                <div>moving these coins will cost a small transaction
                  fee which is fair as their transactions take up space,
                  they need to contribute<br>
                </div>
                <div>most people who use their coins regularly will not
                  even need to worry about this as their coins are moved
                  to a change address anyway.<br>
                </div>
                <div>one downside is that paper wallets would then have
                  an expiration date, however I do not think that a
                  paper wallet that needs to be recycled every 5 to 10
                  years is a terrible idea.<br>
                </div>
                <div>Therefore I propose that the block chain length be
                  limited to either 2^18 blocks (slightly less than 5
                  years) or 2^19 blocks, or slightly less than 10 years.
                  I propose that each time a block is mined the the
                  oldest block(s) (no more than two blocks) beyond this
                  limit is trimmed from the chain and that its unspent
                  transactions are allowed to be included in the reward
                  of the mined block.<br>
                </div>
                <div><br>
                </div>
                <div>This keeps the block chain from tending towards
                  infinity. This keeps the costs of the miners balanced
                  with the costs of the users.<br>
                </div>
                <div><br>
                </div>
                <div>Even though I believe this idea will have some
                  friction, it is applicable to the entire community. It
                  will be hard for some users to give up small benefits
                  that they get at the great cost of miners, however
                  miners run the game and this fair proposal is in in
                  their best interest in two different ways. I would
                  like your thoughts and suggestions. I obviously think
                  this is a freaking awesome idea. I know it is quite
                  controversial but it is the next step in evolution
                  that bitcoin needs to take to ensure immortality.<br>
                </div>
                <div><br>
                </div>
                <div>I come to you to ask if this has any chance of
                  acceptance.<br>
                </div>
                <div><br>
                </div>
                <div>-Patrick<br>
                </div>
              </div>
            </div>
          </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>

--------------1BD8B99E9399710B50A86F2D--