Re: [bitcoin-dev] idea post: trimming and demurrage

From: Aymeric Vitte <vitteaymeric@gmail•com>
To: Patrick Sharp <psharp.x13@gmail•com>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>,
	ZmnSCPxj <ZmnSCPxj@protonmail•com>
Subject: Re: [bitcoin-dev] idea post: trimming and demurrage
Date: Tue, 26 Sep 2017 00:43:02 +0200	[thread overview]
Message-ID: <883ac262-1de8-ac16-f57d-90c683da9e7d@gmail.com> (raw)
In-Reply-To: <CAES+R-rWiyn65+HYadu+OVBuG0zDeuw+0GN404rZ233CSEFVxA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 6979 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 12469 bytes --]