UTXO growth scaling solution proposal
24 messages, 21 Jul to 23 Aug 2017. Started by Major Kusanagi.
Thomas Guyot-Sionnest (4), Major Kusanagi (3), Erik Aronesty (3), Matthew Beton (3), Ethan Scruples (2), Chris Riley (2), Mark F (2), Jeremy Rubin, +4 more
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.
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
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 < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (99 lines)
> 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. > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > >
2017-07-21 16:28 GMT-03:00 Major Kusanagi via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org>:
Quoted text (6 lines)
> [...] 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.
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 < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (41 lines)
> 2017-07-21 16:28 GMT-03:00 Major Kusanagi via bitcoin-dev < > bitcoin-dev@lists•linuxfoundation•org>: > >> [...] 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 > lvella@gmail•com > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > >
On Fri, Jul 21, 2017 at 12:54 PM, Jameson Lopp <jameson.lopp@gmail•com> wrote:
Quoted text (3 lines)
> 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.
Quoted text (5 lines)
> 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.
Quoted text (6 lines)
> 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.
Quoted text (7 lines)
> 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.
Quoted text (107 lines)
> - Jameson > > On Fri, Jul 21, 2017 at 3:28 PM, Major Kusanagi via bitcoin-dev < > bitcoin-dev@lists•linuxfoundation•org> wrote: > >> 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. >> >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists•linuxfoundation•org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> >
On Fri, Jul 21, 2017 at 12:59 PM, Lucas Clemente Vella <lvella@gmail•com> wrote:
Quoted text (17 lines)
> 2017-07-21 16:28 GMT-03:00 Major Kusanagi via bitcoin-dev < > bitcoin-dev@lists•linuxfoundation•org>: > >> [...] 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". >
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.
Quoted text (7 lines)
> 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
Quoted text (7 lines)
> 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.
Quoted text (4 lines)
> -- > Lucas Clemente Vella > lvella@gmail•com >
On 21/07/17 03:59 PM, Lucas Clemente Vella via bitcoin-dev wrote:
Quoted text (31 lines)
> 2017-07-21 16:28 GMT-03:00 Major Kusanagi via bitcoin-dev > <bitcoin-dev@lists•linuxfoundation•org > <mailto:bitcoin-dev@lists.linuxfoundation.org>>: > > [...] 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.
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,
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 < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (80 lines)
> On 21/07/17 03:59 PM, Lucas Clemente Vella via bitcoin-dev wrote: > > 2017-07-21 16:28 GMT-03:00 Major Kusanagi via bitcoin-dev > > <bitcoin-dev@lists•linuxfoundation•org > > <mailto:bitcoin-dev@lists.linuxfoundation.org>>: > > > > [...] 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. > > 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 > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
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 < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (106 lines)
> 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 < > bitcoin-dev@lists•linuxfoundation•org> wrote: > >> On 21/07/17 03:59 PM, Lucas Clemente Vella via bitcoin-dev wrote: >> > 2017-07-21 16:28 GMT-03:00 Major Kusanagi via bitcoin-dev >> > <bitcoin-dev@lists•linuxfoundation•org >> > <mailto:bitcoin-dev@lists.linuxfoundation.org>>: >> > >> > [...] 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. >> >> 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 >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists•linuxfoundation•org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/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. 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.
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 < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (19 lines)
> 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. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > >
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.
On Tue, 22 Aug 2017, 3:45 pm Chris Riley <criley@gmail•com> wrote:
Quoted text (51 lines)
> 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 <
> bitcoin-dev@lists•linuxfoundation•org> wrote:
>
>> 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.
>>
> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation•org
>> https://lists.linuxfoundation.org/mailman/listinfo/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 < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (56 lines)
> 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 <
> bitcoin-dev@lists•linuxfoundation•org> wrote:
>
>> 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.
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation•org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/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.
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.
On Tue, 22 Aug 2017, 7:24 pm Thomas Guyot-Sionnest <dermoth@aei•ca> wrote:
Quoted text (77 lines)
> 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
>
>
> On 22/08/17 10:29 AM, Erik Aronesty via bitcoin-dev wrote:
>
> 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 <
> bitcoin-dev@lists•linuxfoundation•org> wrote:
>
>> 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 <
>> bitcoin-dev@lists•linuxfoundation•org> wrote:
>>
>>> 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.
>>>
>>
>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.
:-)
On Tue, Aug 22, 2017 at 1:33 PM, Matthew Beton <matthew.beton@gmail•com> wrote:
Quoted text (87 lines)
> 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.
>
> On Tue, 22 Aug 2017, 7:24 pm Thomas Guyot-Sionnest <dermoth@aei•ca> wrote:
>
>> 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
>>
>>
>> On 22/08/17 10:29 AM, Erik Aronesty via bitcoin-dev wrote:
>>
>> 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 <
>> bitcoin-dev@lists•linuxfoundation•org> wrote:
>>
>>> 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 <
>>> bitcoin-dev@lists•linuxfoundation•org> wrote:
>>>
>>>> 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.
>>>>
>>>
>>Quoted text (1 line)
> The initial message I replied to stated:
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
On Tue, Aug 22, 2017 at 2:55 PM, Chris Riley <criley@gmail•com> wrote:
Quoted text (109 lines)
> 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.
>
> :-)
>
>
>
> On Tue, Aug 22, 2017 at 1:33 PM, Matthew Beton <matthew.beton@gmail•com>
> wrote:
>
>> 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.
>>
>> On Tue, 22 Aug 2017, 7:24 pm Thomas Guyot-Sionnest <dermoth@aei•ca>
>> wrote:
>>
>>> 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
>>>
>>>
>>> On 22/08/17 10:29 AM, Erik Aronesty via bitcoin-dev wrote:
>>>
>>> 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 <
>>> bitcoin-dev@lists•linuxfoundation•org> wrote:
>>>
>>>> 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 <
>>>> bitcoin-dev@lists•linuxfoundation•org> wrote:
>>>>
>>>>> 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.
>>>>>
>>>>
>>>
>A fun exercise to be sure, but perhaps off topic for this list?
Quoted text (70 lines)
> On Aug 22, 2017, at 1:06 PM, Erik Aronesty via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
>
> > The initial message I replied to stated:
>
> 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
>
>
>
>
>> On Tue, Aug 22, 2017 at 2:55 PM, Chris Riley <criley@gmail•com> wrote:
>> 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.
>>
>> :-)
>>
>>
>>
>>> On Tue, Aug 22, 2017 at 1:33 PM, Matthew Beton <matthew.beton@gmail•com> wrote:
>>> 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.
>>>
>>>
>>>> On Tue, 22 Aug 2017, 7:24 pm Thomas Guyot-Sionnest <dermoth@aei•ca> wrote:
>>>> 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
>>>>
>>>>
>>>>> On 22/08/17 10:29 AM, Erik Aronesty via bitcoin-dev wrote:
>>>>> 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 <bitcoin-dev@lists•linuxfoundation•org> wrote:
>>>>>> 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 <bitcoin-dev@lists•linuxfoundation•org> wrote:
>>>>>>> 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.
>>>>
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-devAlso.... 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 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
Quoted text (35 lines)
> > > Date: Tue, 22 Aug 2017 13:24:05 -0400 > From: Thomas Guyot-Sionnest <dermoth@aei•ca> > To: Erik Aronesty <erik@q32•com>, Bitcoin Protocol Discussion > <bitcoin-dev@lists•linuxfoundation•org>, Chris Riley > <criley@gmail•com> > Cc: Matthew Beton <matthew.beton@gmail•com> > Subject: Re: [bitcoin-dev] UTXO growth scaling solution proposal > Message-ID: <4c39bee6-f419-2e36-62a8-d38171b15558@aei•ca> > 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 > > >
On 22/08/17 06:17 PM, Daniele Pinna via bitcoin-dev wrote:
Quoted text (4 lines)
> 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...
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?
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.
Quoted text (29 lines)
> On Aug 22, 2017, at 4:29 PM, Thomas Guyot-Sionnest via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote: > > 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 > >> On 22/08/17 06:58 PM, Rodney Morris via bitcoin-dev wrote: >> 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 > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev