Good morning,
This is called "UTXO Set Commitments".
Pieter Wuille I think had concrete proposals for the cryptographic primitive to
use. Try searching "Rolling UTXO Set Commitments".
Regards,
ZmnSCPxj
Sent with [ProtonMail](https://protonmail.com) Secure Email.
> -------- Original Message --------
> Subject: Re: [bitcoin-dev] idea post: trimming and demurrage
> Local Time: September 26, 2017 9:33 AM
> UTC Time: September 26, 2017 1:33 AM
> From: [email protected]
> To: ZmnSCPxj <[email protected]>
> [email protected] <[email protected]>
>
> 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 <[email protected]> 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: [email protected]
>> To: [email protected]
>>
>> 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
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
