Aymeric Vitte [ARCHIVE] on Nostr: đź“… Original date posted:2017-09-25 đź“ť Original message:Maybe I missed or did not ...
đź“… Original date posted:2017-09-25
đź“ť Original message: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 at protonmail.com
> <mailto:ZmnSCPxj at 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 at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> To: bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170926/9fbdd815/attachment.html>;
đź“ť Original message: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 at protonmail.com
> <mailto:ZmnSCPxj at 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 at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> To: bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170926/9fbdd815/attachment.html>;