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 > 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 > > To: 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