Discussion:
UTXO growth scaling solution proposal
Add Reply
Major Kusanagi via bitcoin-dev
2017-07-21 19:28:57 UTC
Reply
Permalink
Raw Message
Hi all,

I have a scaling solution idea that I would be interested in getting some
feedback on. I’m new to the mailing list and have not been in the Bitcoin
space as long as some have been, so I don’t know if anyone has thought of
this idea.

Arguably the biggest scaling problem for Bitcoin is the unbounded UTXO
growth. Current scaling solutions like Segregated Witness, Lighting
Network, and larger blocks does not address this issue. As more and more
blocks are added to the block chain the size of the UTXO set that miners
have to maintain continues to grow. This is the case even if the block size
were to remain at 1 megabyte. There is no way out of solving this
fundamental scaling problem other then to limit the maximum size of the
UTXO set.

The following soft fork solution is proposed. Any UTXO that is not spent
within a set number of blocks is considered invalid. What this means for
miners and nodes in the Bitcoin network is that they only have to ever
store that set number of blocks. In others words the block chain will never
be larger then the set number of blocks and the size of the block chain is
capped.

But what this means for users is that bitcoins that have not been spent for
a long time are “lost” forever. This proposed solution is likely a
difficult thing for Bitcoin users to accept. What Bitcoin users will
experience is that all of a sudden their bitcoins are spendable one moment
and the next moment they are not. The experience that they get is that all
of a sudden their old bitcoins are gone forever.

The solution can be improved by adding this new mechanism to Bitcoin, that
I will call luster. UTXO’s that are less then X blocks old has not lost any
luster and have a luster value of 1. As UTXO’s get older, the luster value
will continuously decrease until the UTXO’s become Z blocks old (where Z >
X), and has lost all it’s luster and have a luster value of 0. UTXO’s that
are in between X and Z blocks old have a luster value between 0 and 1. The
luster value is then used to compute the amount of bitcoins that must be
burned in order for a transaction with that UTXO to be included in a block.
So for example, a UTXO with a luster value of 0.5 must burn at least 50
percent of its bitcoin value, a UTXO with a luster value of 0.25 must burn
at least 75 percent of its bitcoin value, and a UTXO with a luster value of
0 must burn 100 percent of its bitcoin value. Thus the coins/UTXOs that
have a luster value of 0 means it has no monetary value, and it would be
safe for bitcoins nodes to drop those UTXOs from the set they maintain.

The idea is that coins that are continuously being used in Bitcoin economy
will never lose it’s luster. But coins that are old and not circulating
will start to lose its luster up until all luster is lost and they become
valueless. Or they reenter the economy and regains all its luster.

But at what point should coins start losing their luster? A goal would be
that we want to minimize the scenarios of when coins start losing their
luster. One reasonable answer is that coins should only starting losing its
luster after the lifespan of the average human. The idea being that a
person will eventually have to spend all his coins before he dies,
otherwise it will get lost anyways (assuming that only the dying person has
the ability to spend those coins). Otherwise there are few cases where a
person would never spend their bitcoins in there human life time. One
example is in the case of inheritance where a dying person does not want to
spend his remaining coins and have another person take them over. But with
this propose scaling solution, coins can be stilled inherited, but it would
have to be an on-chain inheritance. The longest lifespan of a human
currently is about 120 years old. So a blockchain that stores the last 150
years of history seems like one reasonable option.

Then the question of how large blocks should be is simply a matter of what
is the disk size requirement for a full node. For simplicity, assuming that
a block is created every 10 minute, the blockchain size in terabyte can be
express as the following.
blockSize MB * 6 * 24 * 365 * years /1000000 = blockchainSize TB

Example values:
blockSize = 1MB, years = 150 -> blockchainSize = 7.884 TB
blockSize = 2MB, years = 150 -> blockchainSize = 15.768 TB

So if we don’t want the block chain to be bigger then 8 TB, then we should
have a block size of 1 MB. If we don’t want the block chain to be bigger
then 16 TB, then we should have a block size of 2 MB and so on. The idea is
that base on how cheap disk space gets, we can adjust the target max block
chain size and the block size accordingly.

I believe that this proposal is a good solution to the UTXO growth problem.
The proposal being a soft fork is a big plus. It also keeps the block chain
size finite even if given a infinite amount of time. But there are other
things to considered, like how best should wallet software handle this? How
can this work with sidechains? More thought would need to be put into this.
But the fact is that if we want to make bitcoins last forever, we have the
accept unbounded UTXO growth, which is unscalable. So the only solution is
to limit UTXO growth, meaning bitcoins cannot last forever. This proposed
solution however does not prevent Bitcoin from lasting forever.
Jameson Lopp via bitcoin-dev
2017-07-21 19:54:26 UTC
Reply
Permalink
Raw Message
Sounds like demurrage to me, which has been implemented in other
cryptocurrencies such as Freicoin - http://freico.in/

While it's an interesting to apply this line of thinking from a scaling
perspective, I suspect most would find it untenable from a monetary policy
perspective.

You have touched on a scaling issue, the cost of node operation, that I
think is really the root cause of a lot of the debate. Thus even if your
proposal was implemented, we'd still have to solve the problem of finding a
consensus for CONOP.

I think you may have misapplied your logic to the total size of the
blockchain, however. Are you suggesting that pruning of the old UTXOs would
also enable pruning of old blocks from all nodes? Those things aren't
really related, plus someone would still have to keep old blocks around in
order to facilitate new nodes syncing from genesis.

- Jameson

On Fri, Jul 21, 2017 at 3:28 PM, Major Kusanagi via bitcoin-dev <
Post by Major Kusanagi via bitcoin-dev
Hi all,
I have a scaling solution idea that I would be interested in getting some
feedback on. I’m new to the mailing list and have not been in the Bitcoin
space as long as some have been, so I don’t know if anyone has thought of
this idea.
Arguably the biggest scaling problem for Bitcoin is the unbounded UTXO
growth. Current scaling solutions like Segregated Witness, Lighting
Network, and larger blocks does not address this issue. As more and more
blocks are added to the block chain the size of the UTXO set that miners
have to maintain continues to grow. This is the case even if the block size
were to remain at 1 megabyte. There is no way out of solving this
fundamental scaling problem other then to limit the maximum size of the
UTXO set.
The following soft fork solution is proposed. Any UTXO that is not spent
within a set number of blocks is considered invalid. What this means for
miners and nodes in the Bitcoin network is that they only have to ever
store that set number of blocks. In others words the block chain will never
be larger then the set number of blocks and the size of the block chain is
capped.
But what this means for users is that bitcoins that have not been spent
for a long time are “lost” forever. This proposed solution is likely a
difficult thing for Bitcoin users to accept. What Bitcoin users will
experience is that all of a sudden their bitcoins are spendable one moment
and the next moment they are not. The experience that they get is that all
of a sudden their old bitcoins are gone forever.
The solution can be improved by adding this new mechanism to Bitcoin, that
I will call luster. UTXO’s that are less then X blocks old has not lost any
luster and have a luster value of 1. As UTXO’s get older, the luster value
will continuously decrease until the UTXO’s become Z blocks old (where Z >
X), and has lost all it’s luster and have a luster value of 0. UTXO’s that
are in between X and Z blocks old have a luster value between 0 and 1. The
luster value is then used to compute the amount of bitcoins that must be
burned in order for a transaction with that UTXO to be included in a block.
So for example, a UTXO with a luster value of 0.5 must burn at least 50
percent of its bitcoin value, a UTXO with a luster value of 0.25 must burn
at least 75 percent of its bitcoin value, and a UTXO with a luster value of
0 must burn 100 percent of its bitcoin value. Thus the coins/UTXOs that
have a luster value of 0 means it has no monetary value, and it would be
safe for bitcoins nodes to drop those UTXOs from the set they maintain.
The idea is that coins that are continuously being used in Bitcoin economy
will never lose it’s luster. But coins that are old and not circulating
will start to lose its luster up until all luster is lost and they become
valueless. Or they reenter the economy and regains all its luster.
But at what point should coins start losing their luster? A goal would be
that we want to minimize the scenarios of when coins start losing their
luster. One reasonable answer is that coins should only starting losing its
luster after the lifespan of the average human. The idea being that a
person will eventually have to spend all his coins before he dies,
otherwise it will get lost anyways (assuming that only the dying person has
the ability to spend those coins). Otherwise there are few cases where a
person would never spend their bitcoins in there human life time. One
example is in the case of inheritance where a dying person does not want to
spend his remaining coins and have another person take them over. But with
this propose scaling solution, coins can be stilled inherited, but it would
have to be an on-chain inheritance. The longest lifespan of a human
currently is about 120 years old. So a blockchain that stores the last 150
years of history seems like one reasonable option.
Then the question of how large blocks should be is simply a matter of what
is the disk size requirement for a full node. For simplicity, assuming that
a block is created every 10 minute, the blockchain size in terabyte can be
express as the following.
blockSize MB * 6 * 24 * 365 * years /1000000 = blockchainSize TB
blockSize = 1MB, years = 150 -> blockchainSize = 7.884 TB
blockSize = 2MB, years = 150 -> blockchainSize = 15.768 TB
So if we don’t want the block chain to be bigger then 8 TB, then we should
have a block size of 1 MB. If we don’t want the block chain to be bigger
then 16 TB, then we should have a block size of 2 MB and so on. The idea is
that base on how cheap disk space gets, we can adjust the target max block
chain size and the block size accordingly.
I believe that this proposal is a good solution to the UTXO growth
problem. The proposal being a soft fork is a big plus. It also keeps the
block chain size finite even if given a infinite amount of time. But there
are other things to considered, like how best should wallet software handle
this? How can this work with sidechains? More thought would need to be put
into this. But the fact is that if we want to make bitcoins last forever,
we have the accept unbounded UTXO growth, which is unscalable. So the only
solution is to limit UTXO growth, meaning bitcoins cannot last forever.
This proposed solution however does not prevent Bitcoin from lasting
forever.
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Major Kusanagi via bitcoin-dev
2017-07-22 06:43:45 UTC
Reply
Permalink
Raw Message
Post by Jameson Lopp via bitcoin-dev
Sounds like demurrage to me, which has been implemented in other
cryptocurrencies such as Freicoin - http://freico.in/
I don’t think it’s like demurrage in Freicoin at all. The purpose of the
proposal is to help Bitcoin scale, which is not the purpose of Freicoin’s
demurrage fee. Demurrage fee is not optional in Freicoin, and with this
proposal most users will likely never have to burn any coins at all given
how long it would take for bitcoins to lose their luster.
Post by Jameson Lopp via bitcoin-dev
While it's an interesting to apply this line of thinking from a scaling
perspective, I suspect most would find it untenable from a monetary policy
perspective.
I don’t think most would find it untenable, because the proposal in
practice would not affect 99.9% of users because it is unlikely that coins
will ever get to the point where they start losing their luster.
Post by Jameson Lopp via bitcoin-dev
You have touched on a scaling issue, the cost of node operation, that I
think is really the root cause of a lot of the debate. Thus even if your
proposal was implemented, we'd still have to solve the problem of finding a
consensus for CONOP.
I believe with this proposal, finding a consensus for CONOP becomes a lot
less controversial. Because by putting a cap on the block chain size and
UTXO set, we know exactly how much disk space and RAM a node needs to run a
full node.
Post by Jameson Lopp via bitcoin-dev
I think you may have misapplied your logic to the total size of the
blockchain, however. Are you suggesting that pruning of the old UTXOs would
also enable pruning of old blocks from all nodes? Those things aren't
really related, plus someone would still have to keep old blocks around in
order to facilitate new nodes syncing from genesis.
Sorry, let me clarify. I forgot to address the issue of how new nodes sync
the block chain. I mean to say that we should prune the old UTXOs along
with the old blocks. This would mean that we would have to create a
checkpoint every ~150 fifty years (base on my example) and node would drop
blocks older then those checkpoints. This would mean new nodes would start
syncing from the checkpoint not the genesis block.
Post by Jameson Lopp via bitcoin-dev
- Jameson
On Fri, Jul 21, 2017 at 3:28 PM, Major Kusanagi via bitcoin-dev <
Post by Major Kusanagi via bitcoin-dev
Hi all,
I have a scaling solution idea that I would be interested in getting some
feedback on. I’m new to the mailing list and have not been in the Bitcoin
space as long as some have been, so I don’t know if anyone has thought of
this idea.
Arguably the biggest scaling problem for Bitcoin is the unbounded UTXO
growth. Current scaling solutions like Segregated Witness, Lighting
Network, and larger blocks does not address this issue. As more and more
blocks are added to the block chain the size of the UTXO set that miners
have to maintain continues to grow. This is the case even if the block size
were to remain at 1 megabyte. There is no way out of solving this
fundamental scaling problem other then to limit the maximum size of the
UTXO set.
The following soft fork solution is proposed. Any UTXO that is not spent
within a set number of blocks is considered invalid. What this means for
miners and nodes in the Bitcoin network is that they only have to ever
store that set number of blocks. In others words the block chain will never
be larger then the set number of blocks and the size of the block chain is
capped.
But what this means for users is that bitcoins that have not been spent
for a long time are “lost” forever. This proposed solution is likely a
difficult thing for Bitcoin users to accept. What Bitcoin users will
experience is that all of a sudden their bitcoins are spendable one moment
and the next moment they are not. The experience that they get is that all
of a sudden their old bitcoins are gone forever.
The solution can be improved by adding this new mechanism to Bitcoin,
that I will call luster. UTXO’s that are less then X blocks old has not
lost any luster and have a luster value of 1. As UTXO’s get older, the
luster value will continuously decrease until the UTXO’s become Z blocks
old (where Z > X), and has lost all it’s luster and have a luster value of
0. UTXO’s that are in between X and Z blocks old have a luster value
between 0 and 1. The luster value is then used to compute the amount of
bitcoins that must be burned in order for a transaction with that UTXO to
be included in a block. So for example, a UTXO with a luster value of 0.5
must burn at least 50 percent of its bitcoin value, a UTXO with a luster
value of 0.25 must burn at least 75 percent of its bitcoin value, and a
UTXO with a luster value of 0 must burn 100 percent of its bitcoin value.
Thus the coins/UTXOs that have a luster value of 0 means it has no monetary
value, and it would be safe for bitcoins nodes to drop those UTXOs from the
set they maintain.
The idea is that coins that are continuously being used in Bitcoin
economy will never lose it’s luster. But coins that are old and not
circulating will start to lose its luster up until all luster is lost and
they become valueless. Or they reenter the economy and regains all its
luster.
But at what point should coins start losing their luster? A goal would be
that we want to minimize the scenarios of when coins start losing their
luster. One reasonable answer is that coins should only starting losing its
luster after the lifespan of the average human. The idea being that a
person will eventually have to spend all his coins before he dies,
otherwise it will get lost anyways (assuming that only the dying person has
the ability to spend those coins). Otherwise there are few cases where a
person would never spend their bitcoins in there human life time. One
example is in the case of inheritance where a dying person does not want to
spend his remaining coins and have another person take them over. But with
this propose scaling solution, coins can be stilled inherited, but it would
have to be an on-chain inheritance. The longest lifespan of a human
currently is about 120 years old. So a blockchain that stores the last 150
years of history seems like one reasonable option.
Then the question of how large blocks should be is simply a matter of
what is the disk size requirement for a full node. For simplicity, assuming
that a block is created every 10 minute, the blockchain size in terabyte
can be express as the following.
blockSize MB * 6 * 24 * 365 * years /1000000 = blockchainSize TB
blockSize = 1MB, years = 150 -> blockchainSize = 7.884 TB
blockSize = 2MB, years = 150 -> blockchainSize = 15.768 TB
So if we don’t want the block chain to be bigger then 8 TB, then we
should have a block size of 1 MB. If we don’t want the block chain to be
bigger then 16 TB, then we should have a block size of 2 MB and so on. The
idea is that base on how cheap disk space gets, we can adjust the target
max block chain size and the block size accordingly.
I believe that this proposal is a good solution to the UTXO growth
problem. The proposal being a soft fork is a big plus. It also keeps the
block chain size finite even if given a infinite amount of time. But there
are other things to considered, like how best should wallet software handle
this? How can this work with sidechains? More thought would need to be put
into this. But the fact is that if we want to make bitcoins last forever,
we have the accept unbounded UTXO growth, which is unscalable. So the only
solution is to limit UTXO growth, meaning bitcoins cannot last forever.
This proposed solution however does not prevent Bitcoin from lasting
forever.
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Jeremy via bitcoin-dev
2017-07-21 19:52:45 UTC
Reply
Permalink
Raw Message
Hi Major,

I think that you'll enjoy Peter Todd's blogpost on TXO commitments[1]. It
has a better scalability improvement with fewer negative consequence.

Best,

Jeremy



[1] https://petertodd.org/2016/delayed-txo-commitments


--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>

On Fri, Jul 21, 2017 at 3:28 PM, Major Kusanagi via bitcoin-dev <
Post by Major Kusanagi via bitcoin-dev
Hi all,
I have a scaling solution idea that I would be interested in getting some
feedback on. I’m new to the mailing list and have not been in the Bitcoin
space as long as some have been, so I don’t know if anyone has thought of
this idea.
Arguably the biggest scaling problem for Bitcoin is the unbounded UTXO
growth. Current scaling solutions like Segregated Witness, Lighting
Network, and larger blocks does not address this issue. As more and more
blocks are added to the block chain the size of the UTXO set that miners
have to maintain continues to grow. This is the case even if the block size
were to remain at 1 megabyte. There is no way out of solving this
fundamental scaling problem other then to limit the maximum size of the
UTXO set.
The following soft fork solution is proposed. Any UTXO that is not spent
within a set number of blocks is considered invalid. What this means for
miners and nodes in the Bitcoin network is that they only have to ever
store that set number of blocks. In others words the block chain will never
be larger then the set number of blocks and the size of the block chain is
capped.
But what this means for users is that bitcoins that have not been spent
for a long time are “lost” forever. This proposed solution is likely a
difficult thing for Bitcoin users to accept. What Bitcoin users will
experience is that all of a sudden their bitcoins are spendable one moment
and the next moment they are not. The experience that they get is that all
of a sudden their old bitcoins are gone forever.
The solution can be improved by adding this new mechanism to Bitcoin, that
I will call luster. UTXO’s that are less then X blocks old has not lost any
luster and have a luster value of 1. As UTXO’s get older, the luster value
will continuously decrease until the UTXO’s become Z blocks old (where Z >
X), and has lost all it’s luster and have a luster value of 0. UTXO’s that
are in between X and Z blocks old have a luster value between 0 and 1. The
luster value is then used to compute the amount of bitcoins that must be
burned in order for a transaction with that UTXO to be included in a block.
So for example, a UTXO with a luster value of 0.5 must burn at least 50
percent of its bitcoin value, a UTXO with a luster value of 0.25 must burn
at least 75 percent of its bitcoin value, and a UTXO with a luster value of
0 must burn 100 percent of its bitcoin value. Thus the coins/UTXOs that
have a luster value of 0 means it has no monetary value, and it would be
safe for bitcoins nodes to drop those UTXOs from the set they maintain.
The idea is that coins that are continuously being used in Bitcoin economy
will never lose it’s luster. But coins that are old and not circulating
will start to lose its luster up until all luster is lost and they become
valueless. Or they reenter the economy and regains all its luster.
But at what point should coins start losing their luster? A goal would be
that we want to minimize the scenarios of when coins start losing their
luster. One reasonable answer is that coins should only starting losing its
luster after the lifespan of the average human. The idea being that a
person will eventually have to spend all his coins before he dies,
otherwise it will get lost anyways (assuming that only the dying person has
the ability to spend those coins). Otherwise there are few cases where a
person would never spend their bitcoins in there human life time. One
example is in the case of inheritance where a dying person does not want to
spend his remaining coins and have another person take them over. But with
this propose scaling solution, coins can be stilled inherited, but it would
have to be an on-chain inheritance. The longest lifespan of a human
currently is about 120 years old. So a blockchain that stores the last 150
years of history seems like one reasonable option.
Then the question of how large blocks should be is simply a matter of what
is the disk size requirement for a full node. For simplicity, assuming that
a block is created every 10 minute, the blockchain size in terabyte can be
express as the following.
blockSize MB * 6 * 24 * 365 * years /1000000 = blockchainSize TB
blockSize = 1MB, years = 150 -> blockchainSize = 7.884 TB
blockSize = 2MB, years = 150 -> blockchainSize = 15.768 TB
So if we don’t want the block chain to be bigger then 8 TB, then we should
have a block size of 1 MB. If we don’t want the block chain to be bigger
then 16 TB, then we should have a block size of 2 MB and so on. The idea is
that base on how cheap disk space gets, we can adjust the target max block
chain size and the block size accordingly.
I believe that this proposal is a good solution to the UTXO growth
problem. The proposal being a soft fork is a big plus. It also keeps the
block chain size finite even if given a infinite amount of time. But there
are other things to considered, like how best should wallet software handle
this? How can this work with sidechains? More thought would need to be put
into this. But the fact is that if we want to make bitcoins last forever,
we have the accept unbounded UTXO growth, which is unscalable. So the only
solution is to limit UTXO growth, meaning bitcoins cannot last forever.
This proposed solution however does not prevent Bitcoin from lasting
forever.
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Lucas Clemente Vella via bitcoin-dev
2017-07-21 19:59:42 UTC
Reply
Permalink
Raw Message
2017-07-21 16:28 GMT-03:00 Major Kusanagi via bitcoin-dev <
[...] But the fact is that if we want to make bitcoins last forever, we
have the accept unbounded UTXO growth, which is unscalable. So the only
solution is to limit UTXO growth, meaning bitcoins cannot last forever.
This proposed solution however does not prevent Bitcoin from lasting
forever.
Unless there is a logical contradiction in this phrasing, the proposed
solution does not improves scalability:
- "Bitcoins lasting forever" implies "unscalable";
- "not prevent Bitcoin from lasting forever" implies "Bitcoins lasting
forever";
- Thus: "not prevent Bitcoin from lasting forever" implies "unscalable".

In practice, the only Bitcoin lost would be those whose owners forgot about
or has lost the keys, because everyone with a significant amount of
Bitcoins would always shift them around before it loses any luster (I
wouldn't bother to move my Bitcoins every 10 years). I don't know how to
estimate the percentage of UTXO is actually lost/forgotten, but I have the
opinion it isn't worth the hassle.

As a side note, your estimate talks about block size, which is determines
blockchain size, which can be "safely" pruned (if you are not considering
new nodes might want to join the network, in case the full history is
needed to be stored somewhere). But UTXO size, albeit related to the full
blockchain size, is the part that currently can not be safely pruned, so I
don't see the relevance of the analysis.
--
Lucas Clemente Vella
***@gmail.com
Moral Agent via bitcoin-dev
2017-07-21 20:17:39 UTC
Reply
Permalink
Raw Message
If we have a problem with a UTXO set that is too large, seems like maybe
the fair way to approach it is to enforce a limit on the growth of the UTXO
set.

Miners would eventually be forced to generate blocks that are UTXO neutral
and would factor that into their algorithm for prioritizing transactions.
Users who wish to generate a lot of outputs would need to find a buddy with
lots of inputs to consolidate and create a tumble-bit with them. A market
would spring up that would charge people for creating UTXOs and pay them
for disposing of UTXOs.

On Fri, Jul 21, 2017 at 3:59 PM, Lucas Clemente Vella via bitcoin-dev <
Post by Lucas Clemente Vella via bitcoin-dev
2017-07-21 16:28 GMT-03:00 Major Kusanagi via bitcoin-dev <
[...] But the fact is that if we want to make bitcoins last forever, we
have the accept unbounded UTXO growth, which is unscalable. So the only
solution is to limit UTXO growth, meaning bitcoins cannot last forever.
This proposed solution however does not prevent Bitcoin from lasting
forever.
Unless there is a logical contradiction in this phrasing, the proposed
- "Bitcoins lasting forever" implies "unscalable";
- "not prevent Bitcoin from lasting forever" implies "Bitcoins lasting
forever";
- Thus: "not prevent Bitcoin from lasting forever" implies "unscalable".
In practice, the only Bitcoin lost would be those whose owners forgot
about or has lost the keys, because everyone with a significant amount of
Bitcoins would always shift them around before it loses any luster (I
wouldn't bother to move my Bitcoins every 10 years). I don't know how to
estimate the percentage of UTXO is actually lost/forgotten, but I have the
opinion it isn't worth the hassle.
As a side note, your estimate talks about block size, which is determines
blockchain size, which can be "safely" pruned (if you are not considering
new nodes might want to join the network, in case the full history is
needed to be stored somewhere). But UTXO size, albeit related to the full
blockchain size, is the part that currently can not be safely pruned, so I
don't see the relevance of the analysis.
--
Lucas Clemente Vella
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Major Kusanagi via bitcoin-dev
2017-07-22 06:45:54 UTC
Reply
Permalink
Raw Message
Post by Lucas Clemente Vella via bitcoin-dev
2017-07-21 16:28 GMT-03:00 Major Kusanagi via bitcoin-dev <
[...] But the fact is that if we want to make bitcoins last forever, we
have the accept unbounded UTXO growth, which is unscalable. So the only
solution is to limit UTXO growth, meaning bitcoins cannot last forever.
This proposed solution however does not prevent Bitcoin from lasting
forever.
Unless there is a logical contradiction in this phrasing, the proposed
- "Bitcoins lasting forever" implies "unscalable";
- "not prevent Bitcoin from lasting forever" implies "Bitcoins lasting
forever";
- Thus: "not prevent Bitcoin from lasting forever" implies "unscalable".
I made a distinction between lowercase bitcoin meaning the unit of account
in uppercase Bitcoin, the system as a whole. The proposal would make
bitcoins not last forever, which allows the Bitcoin system to scale better
and have a better chance of lasting forever.
Post by Lucas Clemente Vella via bitcoin-dev
In practice, the only Bitcoin lost would be those whose owners forgot
about or has lost the keys, because everyone with a significant amount of
Bitcoins would always shift them around before it loses any luster (I
wouldn't bother to move my Bitcoins every 10 years). I don't know how to
estimate the percentage of UTXO is actually lost/forgotten, but I have the
opinion it isn't worth the hassle.
Exactly. That’s the whole idea. Why bother have nodes store UTXO’s for lost
bitcoins? This proposal would essentially sanitize the UTXO set that nodes
keep track of and clear up wasted space.


As a side note, your estimate talks about block size, which is determines
Post by Lucas Clemente Vella via bitcoin-dev
blockchain size, which can be "safely" pruned (if you are not considering
new nodes might want to join the network, in case the full history is
needed to be stored somewhere). But UTXO size, albeit related to the full
blockchain size, is the part that currently can not be safely pruned, so I
don't see the relevance of the analysis.
I believe I’ve address this with the checkpoint mechanism in my reply to
Jameson.
Post by Lucas Clemente Vella via bitcoin-dev
--
Lucas Clemente Vella
Thomas Guyot-Sionnest via bitcoin-dev
2017-08-21 13:35:22 UTC
Reply
Permalink
Raw Message
Post by Lucas Clemente Vella via bitcoin-dev
2017-07-21 16:28 GMT-03:00 Major Kusanagi via bitcoin-dev
[...] But the fact is that if we want to make bitcoins last forever,
we have the accept unbounded UTXO growth, which is unscalable. So
the only solution is to limit UTXO growth, meaning bitcoins cannot
last forever. This proposed solution however does not prevent
Bitcoin from lasting forever.
Unless there is a logical contradiction in this phrasing, the proposed
- "Bitcoins lasting forever" implies "unscalable";
- "not prevent Bitcoin from lasting forever" implies "Bitcoins lasting
forever";
- Thus: "not prevent Bitcoin from lasting forever" implies "unscalable".
In practice, the only Bitcoin lost would be those whose owners forgot
about or has lost the keys, because everyone with a significant amount
of Bitcoins would always shift them around before it loses any luster (I
wouldn't bother to move my Bitcoins every 10 years). I don't know how to
estimate the percentage of UTXO is actually lost/forgotten, but I have
the opinion it isn't worth the hassle.
As a side note, your estimate talks about block size, which is
determines blockchain size, which can be "safely" pruned (if you are not
considering new nodes might want to join the network, in case the full
history is needed to be stored somewhere). But UTXO size, albeit related
to the full blockchain size, is the part that currently can not be
safely pruned, so I don't see the relevance of the analysis.
I think if we wanted to burn lost/stale coins a better approach would be
returning them to miner's as a fee - there will always be lost coins and
miners will be able to get that additional revenue stream as the mining
reward halves. I also don't think we need to worry about doing a gradual
value loss neither, we should just put a limit on UTXO age in block
count (actually I would round it up to 210k blocks as explained below...).


So lets say for example we decide to keep 5 210k blocks "generations"
(that's over 15 years), then on the first block of the 6th generation
all UTXO's from the 1st generation are invalidated and returned into a
"pool".

Given these (values in satoshis):

Pool "P" (invalided UTXO minus total value reclaimed since last halving)
Leftover blocks "B" (210,000 minus blocks mined since last halving)

Then every mined block can reclaim FLOOR(P/B) satoshi in addition to
miner's reward and tx fees.

If the last block of a generation does not get the remainder of the pool
(FLOOR(P/1) == P) it should get carried over.


This would ensure we can clear old blocks after a few generations and
that burnt/lost coins eventually get back in circulation. Also it would
reduce the reliance of miners on actual TX fees.


To avoid excessive miner reward initially, for the first few iterations
the value of B could be increased (I haven't calculated the UTXO size of
the first 210k blocks but it could be excessively high...) or the value
each block can reclaim could be caped (so we would reclaim at an
artificial capacity until the pool depletes...).


Regards,

--
Thomas
Moral Agent via bitcoin-dev
2017-08-21 14:26:35 UTC
Reply
Permalink
Raw Message
A more forgiving option would be to have coins past a certain age evaporate
into mining rewards at some rate, rather than all at once. People might
find this approach easier to stomach as it avoids the "I waited 1 block to
many and all of my coins vanished" scenario.

Another approach would to demand that a certain minimum mining fee be
included that is calculated based on the age of an input like this idea:
https://www.reddit.com/r/Bitcoin/comments/35ilir/prioritizing_utxos_using_a_minimum_mining_fee/

This would result in the coins continuing to exist but not being
economically spendable, and therefore the UTXO information could be
archived.

On Mon, Aug 21, 2017 at 9:35 AM, Thomas Guyot-Sionnest via bitcoin-dev <
Post by Thomas Guyot-Sionnest via bitcoin-dev
Post by Lucas Clemente Vella via bitcoin-dev
2017-07-21 16:28 GMT-03:00 Major Kusanagi via bitcoin-dev
[...] But the fact is that if we want to make bitcoins last forever,
we have the accept unbounded UTXO growth, which is unscalable. So
the only solution is to limit UTXO growth, meaning bitcoins cannot
last forever. This proposed solution however does not prevent
Bitcoin from lasting forever.
Unless there is a logical contradiction in this phrasing, the proposed
- "Bitcoins lasting forever" implies "unscalable";
- "not prevent Bitcoin from lasting forever" implies "Bitcoins lasting
forever";
- Thus: "not prevent Bitcoin from lasting forever" implies "unscalable".
In practice, the only Bitcoin lost would be those whose owners forgot
about or has lost the keys, because everyone with a significant amount
of Bitcoins would always shift them around before it loses any luster (I
wouldn't bother to move my Bitcoins every 10 years). I don't know how to
estimate the percentage of UTXO is actually lost/forgotten, but I have
the opinion it isn't worth the hassle.
As a side note, your estimate talks about block size, which is
determines blockchain size, which can be "safely" pruned (if you are not
considering new nodes might want to join the network, in case the full
history is needed to be stored somewhere). But UTXO size, albeit related
to the full blockchain size, is the part that currently can not be
safely pruned, so I don't see the relevance of the analysis.
I think if we wanted to burn lost/stale coins a better approach would be
returning them to miner's as a fee - there will always be lost coins and
miners will be able to get that additional revenue stream as the mining
reward halves. I also don't think we need to worry about doing a gradual
value loss neither, we should just put a limit on UTXO age in block
count (actually I would round it up to 210k blocks as explained below...).
So lets say for example we decide to keep 5 210k blocks "generations"
(that's over 15 years), then on the first block of the 6th generation
all UTXO's from the 1st generation are invalidated and returned into a
"pool".
Pool "P" (invalided UTXO minus total value reclaimed since last halving)
Leftover blocks "B" (210,000 minus blocks mined since last halving)
Then every mined block can reclaim FLOOR(P/B) satoshi in addition to
miner's reward and tx fees.
If the last block of a generation does not get the remainder of the pool
(FLOOR(P/1) == P) it should get carried over.
This would ensure we can clear old blocks after a few generations and
that burnt/lost coins eventually get back in circulation. Also it would
reduce the reliance of miners on actual TX fees.
To avoid excessive miner reward initially, for the first few iterations
the value of B could be increased (I haven't calculated the UTXO size of
the first 210k blocks but it could be excessively high...) or the value
each block can reclaim could be caped (so we would reclaim at an
artificial capacity until the pool depletes...).
Regards,
--
Thomas
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Erik Aronesty via bitcoin-dev
2017-08-21 17:24:09 UTC
Reply
Permalink
Raw Message
1. If it only affects "old dust" UTXO's where the # of coins in the UTXO
aren't sufficient to pay some lower quantile of transaction fees, then
there can be little argument of theft or loss.

2. There's another use-case for demurrage as well.

Computation power may grow rapidly if quantum computing becomes more
common. At some point, Bitcoin may have to change the public key format
for coins and the POW used.

In order to do this, old coins will have to transact on the network, moving
their value to a new format, with many more bits in the public key, for
example. But since quantum computing isn't bounded by moore's law, so
this may need to be a regular upgrade every X years. Rather than a
regular "bit widening hard fork", the number of bits needed in a public
address format could be scaled to the difficulty of the new quantum hashing
algorithm that *also must *now grow in the # of bits over time. To ensure
that coins are secure, those with too few bits must drop off the network.
So the timing for old coin demurrage can effectively be based on the
quantum POW difficulty adjustments. As long as the subsequent exponential
rate of computation increase can be reasonably predicted (quantum version
of moore's law), the new rate of decay can be pegged to a number of years.



On Mon, Aug 21, 2017 at 10:26 AM, Moral Agent via bitcoin-dev <
Post by Moral Agent via bitcoin-dev
A more forgiving option would be to have coins past a certain age
evaporate into mining rewards at some rate, rather than all at once. People
might find this approach easier to stomach as it avoids the "I waited 1
block to many and all of my coins vanished" scenario.
Another approach would to demand that a certain minimum mining fee be
https://www.reddit.com/r/Bitcoin/comments/35ilir/
prioritizing_utxos_using_a_minimum_mining_fee/
This would result in the coins continuing to exist but not being
economically spendable, and therefore the UTXO information could be
archived.
On Mon, Aug 21, 2017 at 9:35 AM, Thomas Guyot-Sionnest via bitcoin-dev <
Post by Lucas Clemente Vella via bitcoin-dev
Post by Lucas Clemente Vella via bitcoin-dev
2017-07-21 16:28 GMT-03:00 Major Kusanagi via bitcoin-dev
[...] But the fact is that if we want to make bitcoins last forever,
we have the accept unbounded UTXO growth, which is unscalable. So
the only solution is to limit UTXO growth, meaning bitcoins cannot
last forever. This proposed solution however does not prevent
Bitcoin from lasting forever.
Unless there is a logical contradiction in this phrasing, the proposed
- "Bitcoins lasting forever" implies "unscalable";
- "not prevent Bitcoin from lasting forever" implies "Bitcoins lasting
forever";
- Thus: "not prevent Bitcoin from lasting forever" implies
"unscalable".
Post by Lucas Clemente Vella via bitcoin-dev
In practice, the only Bitcoin lost would be those whose owners forgot
about or has lost the keys, because everyone with a significant amount
of Bitcoins would always shift them around before it loses any luster (I
wouldn't bother to move my Bitcoins every 10 years). I don't know how to
estimate the percentage of UTXO is actually lost/forgotten, but I have
the opinion it isn't worth the hassle.
As a side note, your estimate talks about block size, which is
determines blockchain size, which can be "safely" pruned (if you are not
considering new nodes might want to join the network, in case the full
history is needed to be stored somewhere). But UTXO size, albeit related
to the full blockchain size, is the part that currently can not be
safely pruned, so I don't see the relevance of the analysis.
I think if we wanted to burn lost/stale coins a better approach would be
returning them to miner's as a fee - there will always be lost coins and
miners will be able to get that additional revenue stream as the mining
reward halves. I also don't think we need to worry about doing a gradual
value loss neither, we should just put a limit on UTXO age in block
count (actually I would round it up to 210k blocks as explained below...).
So lets say for example we decide to keep 5 210k blocks "generations"
(that's over 15 years), then on the first block of the 6th generation
all UTXO's from the 1st generation are invalidated and returned into a
"pool".
Pool "P" (invalided UTXO minus total value reclaimed since last halving)
Leftover blocks "B" (210,000 minus blocks mined since last halving)
Then every mined block can reclaim FLOOR(P/B) satoshi in addition to
miner's reward and tx fees.
If the last block of a generation does not get the remainder of the pool
(FLOOR(P/1) == P) it should get carried over.
This would ensure we can clear old blocks after a few generations and
that burnt/lost coins eventually get back in circulation. Also it would
reduce the reliance of miners on actual TX fees.
To avoid excessive miner reward initially, for the first few iterations
the value of B could be increased (I haven't calculated the UTXO size of
the first 210k blocks but it could be excessively high...) or the value
each block can reclaim could be caped (so we would reclaim at an
artificial capacity until the pool depletes...).
Regards,
--
Thomas
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Matthew Beton via bitcoin-dev
2017-08-22 08:19:26 UTC
Reply
Permalink
Raw Message
Okay so I quite like this idea. If we start removing at height 630000 or
840000 (gives us 4-8 years to develop this solution), it stays nice and
neat with the halving interval. We can look at this like so:

B - the current block number
P - how many blocks behind current the coin burning block is. (630000,
840000, or otherwise.)

Every time we mine a new block, we go to block (B-P), and check for stale
coins. These coins get burnt up and pooled into block B's miner fees. This
keeps the mining rewards up in the long term, people are less likely to
stop mining due to too low fees. It also encourages people to keep moving
their money around the enconomy instead of just hording and leaving it.
Chris Riley via bitcoin-dev
2017-08-22 13:45:12 UTC
Reply
Permalink
Raw Message
This seems to be drifting off into alt-coin discussion. The idea that we
can change the rules and steal coins at a later date because they are
"stale" or someone is "hoarding" is antithetical to one of the points of
bitcoin in that you can no longer control your own money ("be your own
bank") because someone can at a later date take your coins for some reason
that is outside your control and solely based on some rationalization by a
third party. Once the rule is established that there are valid reasons why
someone should not have control of their own bitcoins, what other reasons
will then be determined to be valid?

I can imagine Hal Finney being revived (he was cryo-preserved at Alcor if
you aren't aware) after 100 or 200 years expecting his coins to be there
only to find out that his coins were deemed "stale" so were "reclaimed" (in
the current doublespeak - e.g. stolen or confiscated). Or perhaps he
locked some for his children and they are found to be "stale" before they
are available. He said in March 2013, "I think they're safe enough" stored
in a paper wallet. Perhaps any remaining coins are no longer "safe enough."

Again, this seems (a) more about an alt-coin/bitcoin fork or (b) better in
bitcoin-discuss at best vs bitcoin-dev. I've seen it discussed many times
since 2010 and still do not agree with the rational that embracing allowing
someone to steal someone else's coins for any reason is a useful change to
bitcoin.




On Tue, Aug 22, 2017 at 4:19 AM, Matthew Beton via bitcoin-dev <
Post by Matthew Beton via bitcoin-dev
Okay so I quite like this idea. If we start removing at height 630000 or
840000 (gives us 4-8 years to develop this solution), it stays nice and
B - the current block number
P - how many blocks behind current the coin burning block is. (630000,
840000, or otherwise.)
Every time we mine a new block, we go to block (B-P), and check for stale
coins. These coins get burnt up and pooled into block B's miner fees. This
keeps the mining rewards up in the long term, people are less likely to
stop mining due to too low fees. It also encourages people to keep moving
their money around the enconomy instead of just hording and leaving it.
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Matthew Beton via bitcoin-dev
2017-08-22 14:04:49 UTC
Reply
Permalink
Raw Message
Ok, I see your point. I was just thinking about the number of bitcoins tied
up in wallets in which people lost the keys, but I suppose this isn't so
much of a problem if it's well known that the bitcoins are all tied up. It
would be impossible to distinguish between bitcoins people have lost access
to, and bitcoins that people have just left in the same wallet for a long
time.
Post by Chris Riley via bitcoin-dev
This seems to be drifting off into alt-coin discussion. The idea that we
can change the rules and steal coins at a later date because they are
"stale" or someone is "hoarding" is antithetical to one of the points of
bitcoin in that you can no longer control your own money ("be your own
bank") because someone can at a later date take your coins for some reason
that is outside your control and solely based on some rationalization by a
third party. Once the rule is established that there are valid reasons why
someone should not have control of their own bitcoins, what other reasons
will then be determined to be valid?
I can imagine Hal Finney being revived (he was cryo-preserved at Alcor if
you aren't aware) after 100 or 200 years expecting his coins to be there
only to find out that his coins were deemed "stale" so were "reclaimed" (in
the current doublespeak - e.g. stolen or confiscated). Or perhaps he
locked some for his children and they are found to be "stale" before they
are available. He said in March 2013, "I think they're safe enough" stored
in a paper wallet. Perhaps any remaining coins are no longer "safe enough."
Again, this seems (a) more about an alt-coin/bitcoin fork or (b) better in
bitcoin-discuss at best vs bitcoin-dev. I've seen it discussed many times
since 2010 and still do not agree with the rational that embracing allowing
someone to steal someone else's coins for any reason is a useful change to
bitcoin.
On Tue, Aug 22, 2017 at 4:19 AM, Matthew Beton via bitcoin-dev <
Post by Matthew Beton via bitcoin-dev
Okay so I quite like this idea. If we start removing at height 630000 or
840000 (gives us 4-8 years to develop this solution), it stays nice and
B - the current block number
P - how many blocks behind current the coin burning block is. (630000,
840000, or otherwise.)
Every time we mine a new block, we go to block (B-P), and check for stale
coins. These coins get burnt up and pooled into block B's miner fees. This
keeps the mining rewards up in the long term, people are less likely to
stop mining due to too low fees. It also encourages people to keep moving
their money around the enconomy instead of just hording and leaving it.
_______________________________________________
Post by Matthew Beton via bitcoin-dev
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Erik Aronesty via bitcoin-dev
2017-08-22 14:29:26 UTC
Reply
Permalink
Raw Message
I agree, it is only a good idea in the event of a quantum computing threat
to the security of Bitcoin.

On Tue, Aug 22, 2017 at 9:45 AM, Chris Riley via bitcoin-dev <
Post by Chris Riley via bitcoin-dev
This seems to be drifting off into alt-coin discussion. The idea that we
can change the rules and steal coins at a later date because they are
"stale" or someone is "hoarding" is antithetical to one of the points of
bitcoin in that you can no longer control your own money ("be your own
bank") because someone can at a later date take your coins for some reason
that is outside your control and solely based on some rationalization by a
third party. Once the rule is established that there are valid reasons why
someone should not have control of their own bitcoins, what other reasons
will then be determined to be valid?
I can imagine Hal Finney being revived (he was cryo-preserved at Alcor if
you aren't aware) after 100 or 200 years expecting his coins to be there
only to find out that his coins were deemed "stale" so were "reclaimed" (in
the current doublespeak - e.g. stolen or confiscated). Or perhaps he
locked some for his children and they are found to be "stale" before they
are available. He said in March 2013, "I think they're safe enough" stored
in a paper wallet. Perhaps any remaining coins are no longer "safe enough."
Again, this seems (a) more about an alt-coin/bitcoin fork or (b) better in
bitcoin-discuss at best vs bitcoin-dev. I've seen it discussed many times
since 2010 and still do not agree with the rational that embracing allowing
someone to steal someone else's coins for any reason is a useful change to
bitcoin.
On Tue, Aug 22, 2017 at 4:19 AM, Matthew Beton via bitcoin-dev <
Post by Matthew Beton via bitcoin-dev
Okay so I quite like this idea. If we start removing at height 630000 or
840000 (gives us 4-8 years to develop this solution), it stays nice and
B - the current block number
P - how many blocks behind current the coin burning block is. (630000,
840000, or otherwise.)
Every time we mine a new block, we go to block (B-P), and check for stale
coins. These coins get burnt up and pooled into block B's miner fees. This
keeps the mining rewards up in the long term, people are less likely to
stop mining due to too low fees. It also encourages people to keep moving
their money around the enconomy instead of just hording and leaving it.
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Thomas Guyot-Sionnest via bitcoin-dev
2017-08-22 17:24:05 UTC
Reply
Permalink
Raw Message
In any case when Hal Finney do not wake up from his 200years
cryo-preservation (because unfortunately for him 200 years earlier they
did not know how to preserve a body well enough to resurrect it) he
would find that advance in computer technology made it trivial for
anyone to steal his coins using the long-obsolete secp256k1 ec curve
(which was done long before, as soon as it became profitable to crack
down the huge stash of coins stale in the early blocks)

I just don't get that argument that you can't be "your own bank". The
only requirement coming from this would be to move your coins about once
every 10 years or so, which you should be able to do if you have your
private keys (you should!). You say it may be something to consider when
computer breakthroughs makes old outputs vulnerable, but I say it's not
"if" but "when" it happens, and by telling firsthand people that their
coins requires moving every once in a long while you ensure they won't
do stupid things or come back 50 years from now and complain their
addresses have been scavenged.

--
Thomas
Post by Erik Aronesty via bitcoin-dev
I agree, it is only a good idea in the event of a quantum computing
threat to the security of Bitcoin.
On Tue, Aug 22, 2017 at 9:45 AM, Chris Riley via bitcoin-dev
This seems to be drifting off into alt-coin discussion. The idea
that we can change the rules and steal coins at a later date
because they are "stale" or someone is "hoarding" is antithetical
to one of the points of bitcoin in that you can no longer control
your own money ("be your own bank") because someone can at a later
date take your coins for some reason that is outside your control
and solely based on some rationalization by a third party. Once
the rule is established that there are valid reasons why someone
should not have control of their own bitcoins, what other reasons
will then be determined to be valid?
I can imagine Hal Finney being revived (he was cryo-preserved at
Alcor if you aren't aware) after 100 or 200 years expecting his
coins to be there only to find out that his coins were deemed
"stale" so were "reclaimed" (in the current doublespeak - e.g.
stolen or confiscated). Or perhaps he locked some for his
children and they are found to be "stale" before they are
available. He said in March 2013, "I think they're safe enough"
stored in a paper wallet. Perhaps any remaining coins are no
longer "safe enough."
Again, this seems (a) more about an alt-coin/bitcoin fork or (b)
better in bitcoin-discuss at best vs bitcoin-dev. I've seen it
discussed many times since 2010 and still do not agree with the
rational that embracing allowing someone to steal someone else's
coins for any reason is a useful change to bitcoin.
On Tue, Aug 22, 2017 at 4:19 AM, Matthew Beton via bitcoin-dev
Okay so I quite like this idea. If we start removing at height
630000 or 840000 (gives us 4-8 years to develop this
solution), it stays nice and neat with the halving interval.
B - the current block number
P - how many blocks behind current the coin burning block is.
(630000, 840000, or otherwise.)
Every time we mine a new block, we go to block (B-P), and
check for stale coins. These coins get burnt up and pooled
into block B's miner fees. This keeps the mining rewards up in
the long term, people are less likely to stop mining due to
too low fees. It also encourages people to keep moving their
money around the enconomy instead of just hording and leaving it.
Matthew Beton via bitcoin-dev
2017-08-22 17:33:41 UTC
Reply
Permalink
Raw Message
Very true, if Moore's law is still functional in 200 years, computers will
be 2^100 times faster (possibly more if quantum computing becomes
commonplace), and so old wallets may be easily cracked.

We will need a way to force people to use newer, higher security wallets,
and turning coins to mining rewards is better solution than them just being
hacked.
Post by Thomas Guyot-Sionnest via bitcoin-dev
In any case when Hal Finney do not wake up from his 200years
cryo-preservation (because unfortunately for him 200 years earlier they did
not know how to preserve a body well enough to resurrect it) he would find
that advance in computer technology made it trivial for anyone to steal his
coins using the long-obsolete secp256k1 ec curve (which was done long
before, as soon as it became profitable to crack down the huge stash of
coins stale in the early blocks)
I just don't get that argument that you can't be "your own bank". The only
requirement coming from this would be to move your coins about once every
10 years or so, which you should be able to do if you have your private
keys (you should!). You say it may be something to consider when computer
breakthroughs makes old outputs vulnerable, but I say it's not "if" but
"when" it happens, and by telling firsthand people that their coins
requires moving every once in a long while you ensure they won't do stupid
things or come back 50 years from now and complain their addresses have
been scavenged.
--
Thomas
I agree, it is only a good idea in the event of a quantum computing threat
to the security of Bitcoin.
On Tue, Aug 22, 2017 at 9:45 AM, Chris Riley via bitcoin-dev <
Post by Chris Riley via bitcoin-dev
This seems to be drifting off into alt-coin discussion. The idea that we
can change the rules and steal coins at a later date because they are
"stale" or someone is "hoarding" is antithetical to one of the points of
bitcoin in that you can no longer control your own money ("be your own
bank") because someone can at a later date take your coins for some reason
that is outside your control and solely based on some rationalization by a
third party. Once the rule is established that there are valid reasons why
someone should not have control of their own bitcoins, what other reasons
will then be determined to be valid?
I can imagine Hal Finney being revived (he was cryo-preserved at Alcor if
you aren't aware) after 100 or 200 years expecting his coins to be there
only to find out that his coins were deemed "stale" so were "reclaimed" (in
the current doublespeak - e.g. stolen or confiscated). Or perhaps he
locked some for his children and they are found to be "stale" before they
are available. He said in March 2013, "I think they're safe enough" stored
in a paper wallet. Perhaps any remaining coins are no longer "safe enough."
Again, this seems (a) more about an alt-coin/bitcoin fork or (b) better
in bitcoin-discuss at best vs bitcoin-dev. I've seen it discussed many
times since 2010 and still do not agree with the rational that embracing
allowing someone to steal someone else's coins for any reason is a useful
change to bitcoin.
On Tue, Aug 22, 2017 at 4:19 AM, Matthew Beton via bitcoin-dev <
Post by Matthew Beton via bitcoin-dev
Okay so I quite like this idea. If we start removing at height 630000 or
840000 (gives us 4-8 years to develop this solution), it stays nice and
B - the current block number
P - how many blocks behind current the coin burning block is. (630000,
840000, or otherwise.)
Every time we mine a new block, we go to block (B-P), and check for
stale coins. These coins get burnt up and pooled into block B's miner fees.
This keeps the mining rewards up in the long term, people are less likely
to stop mining due to too low fees. It also encourages people to keep
moving their money around the enconomy instead of just hording and leaving
it.
Chris Riley via bitcoin-dev
2017-08-22 18:55:15 UTC
Reply
Permalink
Raw Message
The initial message I replied to stated in part, "Okay so I quite like this
idea. If we start removing at height 630000 or 840000 (gives us 4-8 years
to develop this solution), it stays nice and neat with the halving
interval...."

That is less than 3 years or less than 7 years away. Much sooner than it
is believed QC or Moore's law could impact bitcoin. Changing bitcoin so as
to require that early coins start getting "scavenged" at that date seems
unneeded and irresponsible. Besides, your ECDSA is only revealed when you
spend the coins which does provide some quantum resistance. Hal was just
an example of people putting their coins away expecting them to be there at
X years in the future, whether it is for himself or for his kids and wife.

:-)
Post by Matthew Beton via bitcoin-dev
Very true, if Moore's law is still functional in 200 years, computers will
be 2^100 times faster (possibly more if quantum computing becomes
commonplace), and so old wallets may be easily cracked.
We will need a way to force people to use newer, higher security wallets,
and turning coins to mining rewards is better solution than them just being
hacked.
Post by Thomas Guyot-Sionnest via bitcoin-dev
In any case when Hal Finney do not wake up from his 200years
cryo-preservation (because unfortunately for him 200 years earlier they did
not know how to preserve a body well enough to resurrect it) he would find
that advance in computer technology made it trivial for anyone to steal his
coins using the long-obsolete secp256k1 ec curve (which was done long
before, as soon as it became profitable to crack down the huge stash of
coins stale in the early blocks)
I just don't get that argument that you can't be "your own bank". The
only requirement coming from this would be to move your coins about once
every 10 years or so, which you should be able to do if you have your
private keys (you should!). You say it may be something to consider when
computer breakthroughs makes old outputs vulnerable, but I say it's not
"if" but "when" it happens, and by telling firsthand people that their
coins requires moving every once in a long while you ensure they won't do
stupid things or come back 50 years from now and complain their addresses
have been scavenged.
--
Thomas
I agree, it is only a good idea in the event of a quantum computing
threat to the security of Bitcoin.
On Tue, Aug 22, 2017 at 9:45 AM, Chris Riley via bitcoin-dev <
Post by Chris Riley via bitcoin-dev
This seems to be drifting off into alt-coin discussion. The idea that
we can change the rules and steal coins at a later date because they are
"stale" or someone is "hoarding" is antithetical to one of the points of
bitcoin in that you can no longer control your own money ("be your own
bank") because someone can at a later date take your coins for some reason
that is outside your control and solely based on some rationalization by a
third party. Once the rule is established that there are valid reasons why
someone should not have control of their own bitcoins, what other reasons
will then be determined to be valid?
I can imagine Hal Finney being revived (he was cryo-preserved at Alcor
if you aren't aware) after 100 or 200 years expecting his coins to be there
only to find out that his coins were deemed "stale" so were "reclaimed" (in
the current doublespeak - e.g. stolen or confiscated). Or perhaps he
locked some for his children and they are found to be "stale" before they
are available. He said in March 2013, "I think they're safe enough" stored
in a paper wallet. Perhaps any remaining coins are no longer "safe enough."
Again, this seems (a) more about an alt-coin/bitcoin fork or (b) better
in bitcoin-discuss at best vs bitcoin-dev. I've seen it discussed many
times since 2010 and still do not agree with the rational that embracing
allowing someone to steal someone else's coins for any reason is a useful
change to bitcoin.
On Tue, Aug 22, 2017 at 4:19 AM, Matthew Beton via bitcoin-dev <
Post by Matthew Beton via bitcoin-dev
Okay so I quite like this idea. If we start removing at height 630000
or 840000 (gives us 4-8 years to develop this solution), it stays nice and
B - the current block number
P - how many blocks behind current the coin burning block is. (630000,
840000, or otherwise.)
Every time we mine a new block, we go to block (B-P), and check for
stale coins. These coins get burnt up and pooled into block B's miner fees.
This keeps the mining rewards up in the long term, people are less likely
to stop mining due to too low fees. It also encourages people to keep
moving their money around the enconomy instead of just hording and leaving
it.
Erik Aronesty via bitcoin-dev
2017-08-22 20:06:01 UTC
Reply
Permalink
Raw Message
Yes, 3 years is silly. But coin expiration and quantum resistance is
something I've been thinking about for a while, so I tried to steer the
conversation away from stealing old money for no reason ;). Plus I like
the idea of making Bitcoin "2000 year proof".

- I cannot imagine either SHA256 or any of our existing wallet formats
surviving 200 years, if we expect both moores law and quantum computing to
be a thing. I would expect the PoW to be rendered obsolete before the
Bitcoin addresses.

- A PoW change using Keccak and a flexible number of bits can be designed
as a "future hard fork". That is: the existing POW can be automatically
rendered obsolete... but only in the event that difficulty rises to the
level of obsolescence. Then the code for a new algorithm with a flexible
number of bits and a difficulty that can scale for thousands of years can
then automatically kick in.

- A new addresses format and signing protocols that use a flexible number
of bits can be introduced. The maximum number of supported bits can be
configurable, and trivially changed. These can be made immediately
available but completely optional.

- The POW difficulty can be used to inform the expiration of any addresses
that can be compromised within 5 years assuming this power was somehow used
to compromise them. Some mechanism for translating global hashpower to
brute force attack power can be researched, and consesrvative estimates
made. Right now, it's like "heat death of the universe" amount of time to
crack with every machine on the planet. But hey... things change and 2000
years is a long time. This information can be used to inform the
expiration and reclamation of old, compromised public addresses.

- Planning a hard fork 100 to 1000 years out is a fun exercise
Post by Chris Riley via bitcoin-dev
The initial message I replied to stated in part, "Okay so I quite like
this idea. If we start removing at height 630000 or 840000 (gives us 4-8
years to develop this solution), it stays nice and neat with the halving
interval...."
That is less than 3 years or less than 7 years away. Much sooner than it
is believed QC or Moore's law could impact bitcoin. Changing bitcoin so as
to require that early coins start getting "scavenged" at that date seems
unneeded and irresponsible. Besides, your ECDSA is only revealed when you
spend the coins which does provide some quantum resistance. Hal was just
an example of people putting their coins away expecting them to be there at
X years in the future, whether it is for himself or for his kids and wife.
:-)
Post by Matthew Beton via bitcoin-dev
Very true, if Moore's law is still functional in 200 years, computers
will be 2^100 times faster (possibly more if quantum computing becomes
commonplace), and so old wallets may be easily cracked.
We will need a way to force people to use newer, higher security wallets,
and turning coins to mining rewards is better solution than them just being
hacked.
Post by Thomas Guyot-Sionnest via bitcoin-dev
In any case when Hal Finney do not wake up from his 200years
cryo-preservation (because unfortunately for him 200 years earlier they did
not know how to preserve a body well enough to resurrect it) he would find
that advance in computer technology made it trivial for anyone to steal his
coins using the long-obsolete secp256k1 ec curve (which was done long
before, as soon as it became profitable to crack down the huge stash of
coins stale in the early blocks)
I just don't get that argument that you can't be "your own bank". The
only requirement coming from this would be to move your coins about once
every 10 years or so, which you should be able to do if you have your
private keys (you should!). You say it may be something to consider when
computer breakthroughs makes old outputs vulnerable, but I say it's not
"if" but "when" it happens, and by telling firsthand people that their
coins requires moving every once in a long while you ensure they won't do
stupid things or come back 50 years from now and complain their addresses
have been scavenged.
--
Thomas
I agree, it is only a good idea in the event of a quantum computing
threat to the security of Bitcoin.
On Tue, Aug 22, 2017 at 9:45 AM, Chris Riley via bitcoin-dev <
Post by Chris Riley via bitcoin-dev
This seems to be drifting off into alt-coin discussion. The idea that
we can change the rules and steal coins at a later date because they are
"stale" or someone is "hoarding" is antithetical to one of the points of
bitcoin in that you can no longer control your own money ("be your own
bank") because someone can at a later date take your coins for some reason
that is outside your control and solely based on some rationalization by a
third party. Once the rule is established that there are valid reasons why
someone should not have control of their own bitcoins, what other reasons
will then be determined to be valid?
I can imagine Hal Finney being revived (he was cryo-preserved at Alcor
if you aren't aware) after 100 or 200 years expecting his coins to be there
only to find out that his coins were deemed "stale" so were "reclaimed" (in
the current doublespeak - e.g. stolen or confiscated). Or perhaps he
locked some for his children and they are found to be "stale" before they
are available. He said in March 2013, "I think they're safe enough" stored
in a paper wallet. Perhaps any remaining coins are no longer "safe enough."
Again, this seems (a) more about an alt-coin/bitcoin fork or (b) better
in bitcoin-discuss at best vs bitcoin-dev. I've seen it discussed many
times since 2010 and still do not agree with the rational that embracing
allowing someone to steal someone else's coins for any reason is a useful
change to bitcoin.
On Tue, Aug 22, 2017 at 4:19 AM, Matthew Beton via bitcoin-dev <
Post by Matthew Beton via bitcoin-dev
Okay so I quite like this idea. If we start removing at height 630000
or 840000 (gives us 4-8 years to develop this solution), it stays nice and
B - the current block number
P - how many blocks behind current the coin burning block is. (630000,
840000, or otherwise.)
Every time we mine a new block, we go to block (B-P), and check for
stale coins. These coins get burnt up and pooled into block B's miner fees.
This keeps the mining rewards up in the long term, people are less likely
to stop mining due to too low fees. It also encourages people to keep
moving their money around the enconomy instead of just hording and leaving
it.
Mark Friedenbach via bitcoin-dev
2017-08-22 20:20:41 UTC
Reply
Permalink
Raw Message
A fun exercise to be sure, but perhaps off topic for this list?
Yes, 3 years is silly. But coin expiration and quantum resistance is something I've been thinking about for a while, so I tried to steer the conversation away from stealing old money for no reason ;). Plus I like the idea of making Bitcoin "2000 year proof".
- I cannot imagine either SHA256 or any of our existing wallet formats surviving 200 years, if we expect both moores law and quantum computing to be a thing. I would expect the PoW to be rendered obsolete before the Bitcoin addresses.
- A PoW change using Keccak and a flexible number of bits can be designed as a "future hard fork". That is: the existing POW can be automatically rendered obsolete... but only in the event that difficulty rises to the level of obsolescence. Then the code for a new algorithm with a flexible number of bits and a difficulty that can scale for thousands of years can then automatically kick in.
- A new addresses format and signing protocols that use a flexible number of bits can be introduced. The maximum number of supported bits can be configurable, and trivially changed. These can be made immediately available but completely optional.
- The POW difficulty can be used to inform the expiration of any addresses that can be compromised within 5 years assuming this power was somehow used to compromise them. Some mechanism for translating global hashpower to brute force attack power can be researched, and consesrvative estimates made. Right now, it's like "heat death of the universe" amount of time to crack with every machine on the planet. But hey... things change and 2000 years is a long time. This information can be used to inform the expiration and reclamation of old, compromised public addresses.
- Planning a hard fork 100 to 1000 years out is a fun exercise
The initial message I replied to stated in part, "Okay so I quite like this idea. If we start removing at height 630000 or 840000 (gives us 4-8 years to develop this solution), it stays nice and neat with the halving interval...."
That is less than 3 years or less than 7 years away. Much sooner than it is believed QC or Moore's law could impact bitcoin. Changing bitcoin so as to require that early coins start getting "scavenged" at that date seems unneeded and irresponsible. Besides, your ECDSA is only revealed when you spend the coins which does provide some quantum resistance. Hal was just an example of people putting their coins away expecting them to be there at X years in the future, whether it is for himself or for his kids and wife.
:-)
Very true, if Moore's law is still functional in 200 years, computers will be 2^100 times faster (possibly more if quantum computing becomes commonplace), and so old wallets may be easily cracked.
We will need a way to force people to use newer, higher security wallets, and turning coins to mining rewards is better solution than them just being hacked.
In any case when Hal Finney do not wake up from his 200years cryo-preservation (because unfortunately for him 200 years earlier they did not know how to preserve a body well enough to resurrect it) he would find that advance in computer technology made it trivial for anyone to steal his coins using the long-obsolete secp256k1 ec curve (which was done long before, as soon as it became profitable to crack down the huge stash of coins stale in the early blocks)
I just don't get that argument that you can't be "your own bank". The only requirement coming from this would be to move your coins about once every 10 years or so, which you should be able to do if you have your private keys (you should!). You say it may be something to consider when computer breakthroughs makes old outputs vulnerable, but I say it's not "if" but "when" it happens, and by telling firsthand people that their coins requires moving every once in a long while you ensure they won't do stupid things or come back 50 years from now and complain their addresses have been scavenged.
--
Thomas
I agree, it is only a good idea in the event of a quantum computing threat to the security of Bitcoin.
This seems to be drifting off into alt-coin discussion. The idea that we can change the rules and steal coins at a later date because they are "stale" or someone is "hoarding" is antithetical to one of the points of bitcoin in that you can no longer control your own money ("be your own bank") because someone can at a later date take your coins for some reason that is outside your control and solely based on some rationalization by a third party. Once the rule is established that there are valid reasons why someone should not have control of their own bitcoins, what other reasons will then be determined to be valid?
I can imagine Hal Finney being revived (he was cryo-preserved at Alcor if you aren't aware) after 100 or 200 years expecting his coins to be there only to find out that his coins were deemed "stale" so were "reclaimed" (in the current doublespeak - e.g. stolen or confiscated). Or perhaps he locked some for his children and they are found to be "stale" before they are available. He said in March 2013, "I think they're safe enough" stored in a paper wallet. Perhaps any remaining coins are no longer "safe enough."
Again, this seems (a) more about an alt-coin/bitcoin fork or (b) better in bitcoin-discuss at best vs bitcoin-dev. I've seen it discussed many times since 2010 and still do not agree with the rational that embracing allowing someone to steal someone else's coins for any reason is a useful change to bitcoin.
Post by Matthew Beton via bitcoin-dev
B - the current block number
P - how many blocks behind current the coin burning block is. (630000, 840000, or otherwise.)
Every time we mine a new block, we go to block (B-P), and check for stale coins. These coins get burnt up and pooled into block B's miner fees. This keeps the mining rewards up in the long term, people are less likely to stop mining due to too low fees. It also encourages people to keep moving their money around the enconomy instead of just hording and leaving it.
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Daniele Pinna via bitcoin-dev
2017-08-22 22:17:19 UTC
Reply
Permalink
Raw Message
Also.... how is this not a tax on coin holders? By forcing people to move
coins around you would be chipping away at their wealth in the form of
extorted TX fees.
Thomas Guyot-Sionnest via bitcoin-dev
2017-08-22 23:27:30 UTC
Reply
Permalink
Raw Message
Post by Daniele Pinna via bitcoin-dev
Also.... how is this not a tax on coin holders? By forcing people to
move coins around you would be chipping away at their wealth in the
form of extorted TX fees.
As if the fee for one tx per decade (or more if we'd like) matters, plus
it could be very low priority. In fact we could re-allow free
transactions based on old priority rules (oldest outputs gets higher
priority... I would suggest considering reduction in utxo size as well
but that's another topic).

Actually, to ensure miners allow these transaction one rule could be
that the block must contain free transactions on old utxo's ("old" TBD)
to reclaim from the scavenged pool... One side effect is that mining
empty blocks before previous block TX can be validated would reduce the
reward.

I'd love to find clever approach where we could somehow make a
verifiable block check that old tx refresh are included... I haven't put
much thoughts into it yet but if there was a way a two-step transaction
where 1. a fee is paid to register an UTXO refresh (miners would be
encouraged to accept it and increase their immediate revenue), and 2.
the fee must be returned from the pool on a later block. The idea is to
allow free scavenging of own addresses while discouraging miners from
refusing free transactions so they could eventually reclaim the coins. I
can't think of a way that limits the burden on consensus rules...
--
Thomas
Rodney Morris via bitcoin-dev
2017-08-22 22:58:54 UTC
Reply
Permalink
Raw Message
Thomas et.al.

So, in your minds, anyone who locked up coins using CLTV for their child to
receive on their 21st birthday, for the sake of argument, has effectively
forfeit those coins after the fact? You are going to force anyone who took
coins offline (cryptosteel, paper, doesn't matter) to bring those coins
back online, with the inherent security risks?

In my mind, the only sane way to even begin discussing an approach
implementing such a thing - where coins "expire" after X years - would be
to give the entire ecosystem X*N years warning, where N > 1.5. I'd also
suggest X would need to be closer to the life span of a human than zero.
Mind you, I'd suggest this "feature" would need to be coded and deployed as
a future-hard-fork X*N years ahead of time. A-la Satoshi's blog post
regarding increasing block size limit, a good enough approximation would be
to add a block height check to the code that approximates X*N years, based
on 10 minute blocks. The transparency around such a change would need to
be radical and absolute.

I'd also suggest that, similar to CLTV, it only makes sense to discuss
creating a "never expire" transaction output, if such a feature were being
seriously considered.

If you think discussions around a block size increase were difficult, then
we'll need a new word to describe the challenges and vitriol that would
arise in arguments that will follow this discussion should it be seriously
proposed, IMHO.

I also don't think it's reasonable to conflate the discussion herein with
discussion about what to do when ECC or SHA256 is broken. The
weakening/breaking of ECC poses a real risk to the stability of Bitcoin -
the possible release of Satoshi's stash being the most obvious example -
and what to do about that will require serious consideration when the time
comes. Even if the end result is the same - that coins older than "X" will
be invalidated - everything else important about the scenarios are
different as far as I can see.

Rodney
Date: Tue, 22 Aug 2017 13:24:05 -0400
Subject: Re: [bitcoin-dev] UTXO growth scaling solution proposal
Content-Type: text/plain; charset="windows-1252"
In any case when Hal Finney do not wake up from his 200years
cryo-preservation (because unfortunately for him 200 years earlier they
did not know how to preserve a body well enough to resurrect it) he
would find that advance in computer technology made it trivial for
anyone to steal his coins using the long-obsolete secp256k1 ec curve
(which was done long before, as soon as it became profitable to crack
down the huge stash of coins stale in the early blocks)
I just don't get that argument that you can't be "your own bank". The
only requirement coming from this would be to move your coins about once
every 10 years or so, which you should be able to do if you have your
private keys (you should!). You say it may be something to consider when
computer breakthroughs makes old outputs vulnerable, but I say it's not
"if" but "when" it happens, and by telling firsthand people that their
coins requires moving every once in a long while you ensure they won't
do stupid things or come back 50 years from now and complain their
addresses have been scavenged.
--
Thomas
Thomas Guyot-Sionnest via bitcoin-dev
2017-08-22 23:29:41 UTC
Reply
Permalink
Raw Message
I'm just getting the proposal out... if we decide to go forward (pretty
huge "if" right now) whenever it kicks in after 15, 50 or 100 years
should be decided as early as possible.

Are CheckLockTimeVerify transactions accepted yet? I thought most
special transactions were only accepted on Testnet... In any case we
should be able to scan the blockchain and look for any such transaction.
And I hate to make this more complex, but maybe re-issuing the tx from
coinbase could be an option?

--
Thomas
Thomas et.al <http://et.al>.
So, in your minds, anyone who locked up coins using CLTV for their
child to receive on their 21st birthday, for the sake of argument, has
effectively forfeit those coins after the fact? You are going to
force anyone who took coins offline (cryptosteel, paper, doesn't
matter) to bring those coins back online, with the inherent security
risks?
In my mind, the only sane way to even begin discussing an approach
implementing such a thing - where coins "expire" after X years - would
be to give the entire ecosystem X*N years warning, where N > 1.5. I'd
also suggest X would need to be closer to the life span of a human
than zero. Mind you, I'd suggest this "feature" would need to be
coded and deployed as a future-hard-fork X*N years ahead of time.
A-la Satoshi's blog post regarding increasing block size limit, a good
enough approximation would be to add a block height check to the code
that approximates X*N years, based on 10 minute blocks. The
transparency around such a change would need to be radical and absolute.
I'd also suggest that, similar to CLTV, it only makes sense to discuss
creating a "never expire" transaction output, if such a feature were
being seriously considered.
If you think discussions around a block size increase were difficult,
then we'll need a new word to describe the challenges and vitriol that
would arise in arguments that will follow this discussion should it be
seriously proposed, IMHO.
I also don't think it's reasonable to conflate the discussion herein
with discussion about what to do when ECC or SHA256 is broken. The
weakening/breaking of ECC poses a real risk to the stability of
Bitcoin - the possible release of Satoshi's stash being the most
obvious example - and what to do about that will require serious
consideration when the time comes. Even if the end result is the same
- that coins older than "X" will be invalidated - everything else
important about the scenarios are different as far as I can see.
Rodney
Mark Friedenbach via bitcoin-dev
2017-08-23 03:26:19 UTC
Reply
Permalink
Raw Message
Lock time transactions have been valid for over a year now I believe. In any case we can't scan the block chain for usage patterns in UTXOs because P2SH puts the script in the signature on spend.
I'm just getting the proposal out... if we decide to go forward (pretty huge "if" right now) whenever it kicks in after 15, 50 or 100 years should be decided as early as possible.
Are CheckLockTimeVerify transactions accepted yet? I thought most special transactions were only accepted on Testnet... In any case we should be able to scan the blockchain and look for any such transaction. And I hate to make this more complex, but maybe re-issuing the tx from coinbase could be an option?
--
Thomas
Post by Rodney Morris via bitcoin-dev
Thomas et.al.
So, in your minds, anyone who locked up coins using CLTV for their child to receive on their 21st birthday, for the sake of argument, has effectively forfeit those coins after the fact? You are going to force anyone who took coins offline (cryptosteel, paper, doesn't matter) to bring those coins back online, with the inherent security risks?
In my mind, the only sane way to even begin discussing an approach implementing such a thing - where coins "expire" after X years - would be to give the entire ecosystem X*N years warning, where N > 1.5. I'd also suggest X would need to be closer to the life span of a human than zero. Mind you, I'd suggest this "feature" would need to be coded and deployed as a future-hard-fork X*N years ahead of time. A-la Satoshi's blog post regarding increasing block size limit, a good enough approximation would be to add a block height check to the code that approximates X*N years, based on 10 minute blocks. The transparency around such a change would need to be radical and absolute.
I'd also suggest that, similar to CLTV, it only makes sense to discuss creating a "never expire" transaction output, if such a feature were being seriously considered.
If you think discussions around a block size increase were difficult, then we'll need a new word to describe the challenges and vitriol that would arise in arguments that will follow this discussion should it be seriously proposed, IMHO.
I also don't think it's reasonable to conflate the discussion herein with discussion about what to do when ECC or SHA256 is broken. The weakening/breaking of ECC poses a real risk to the stability of Bitcoin - the possible release of Satoshi's stash being the most obvious example - and what to do about that will require serious consideration when the time comes. Even if the end result is the same - that coins older than "X" will be invalidated - everything else important about the scenarios are different as far as I can see.
Rodney
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Loading...