Discussion:
[bitcoin-dev] idea post: trimming and demurrage
Patrick Sharp via bitcoin-dev
2017-09-25 21:54:16 UTC
Permalink
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
ZmnSCPxj via bitcoin-dev
2017-09-25 23:34:32 UTC
Permalink
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-***@lists.linuxfoundation.org
To: bitcoin-***@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
Patrick Sharp via bitcoin-dev
2017-09-26 01:33:25 UTC
Permalink
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.
Post by ZmnSCPxj via bitcoin-dev
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
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.
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
Aymeric Vitte via bitcoin-dev
2017-09-25 22:43:02 UTC
Permalink
Maybe I missed or did not receive some messages, where was your
centralization concern addressed in the discussion?
Post by Patrick Sharp via bitcoin-dev
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.
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
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.
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
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
ZmnSCPxj via bitcoin-dev
2017-09-26 07:50:42 UTC
Permalink
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.
Post by ZmnSCPxj via bitcoin-dev
-------- 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
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.
Post by ZmnSCPxj via bitcoin-dev
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
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.
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
Алексей Мутовкин via bitcoin-dev
2017-09-26 07:10:43 UTC
Permalink
Lets call it blocktrain instead of blockchain. Because it is fixed amount
of blocks moving forward on the time axis. Oldest blocks are detached from
the tail of that blockTrain and goes to depot.

2017-09-26 4:33 GMT+03:00 Patrick Sharp via bitcoin-dev <
Post by Patrick Sharp via bitcoin-dev
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.
Post by ZmnSCPxj via bitcoin-dev
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
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.
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Richard Hein via bitcoin-dev
2017-09-25 23:30:23 UTC
Permalink
It kills Bitcoin as a store of value. Disk space is not the problem; bandwidth is. The blockchain won't go to infinity as you suggest, as it is bounded by certain constraints. It's growth is a function of the transactions in a block, and the number of blocks is linear in growth.

Sent from my iPhone
Post by Patrick Sharp via bitcoin-dev
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.
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Loading...