* Re: [bitcoin-dev] UTXO growth scaling solution proposal
@ 2017-08-22 8:19 Matthew Beton
2017-08-22 13:45 ` Chris Riley
0 siblings, 1 reply; 24+ messages in thread
From: Matthew Beton @ 2017-08-22 8:19 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 698 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 770 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] UTXO growth scaling solution proposal
2017-08-22 8:19 [bitcoin-dev] UTXO growth scaling solution proposal Matthew Beton
@ 2017-08-22 13:45 ` Chris Riley
2017-08-22 14:04 ` Matthew Beton
2017-08-22 14:29 ` Erik Aronesty
0 siblings, 2 replies; 24+ messages in thread
From: Chris Riley @ 2017-08-22 13:45 UTC (permalink / raw)
To: Matthew Beton, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 2480 bytes --]
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
>
>
[-- Attachment #2: Type: text/html, Size: 3240 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] UTXO growth scaling solution proposal
2017-08-22 13:45 ` Chris Riley
@ 2017-08-22 14:04 ` Matthew Beton
2017-08-22 14:29 ` Erik Aronesty
1 sibling, 0 replies; 24+ messages in thread
From: Matthew Beton @ 2017-08-22 14:04 UTC (permalink / raw)
To: Chris Riley, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 3005 bytes --]
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:
> 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
>>
>>
>
[-- Attachment #2: Type: text/html, Size: 4263 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] UTXO growth scaling solution proposal
2017-08-22 13:45 ` Chris Riley
2017-08-22 14:04 ` Matthew Beton
@ 2017-08-22 14:29 ` Erik Aronesty
2017-08-22 17:24 ` Thomas Guyot-Sionnest
1 sibling, 1 reply; 24+ messages in thread
From: Erik Aronesty @ 2017-08-22 14:29 UTC (permalink / raw)
To: Chris Riley, Bitcoin Protocol Discussion; +Cc: Matthew Beton
[-- Attachment #1: Type: text/plain, Size: 2954 bytes --]
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-dev
>>
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
[-- Attachment #2: Type: text/html, Size: 4274 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] UTXO growth scaling solution proposal
2017-08-22 14:29 ` Erik Aronesty
@ 2017-08-22 17:24 ` Thomas Guyot-Sionnest
2017-08-22 17:33 ` Matthew Beton
0 siblings, 1 reply; 24+ messages in thread
From: Thomas Guyot-Sionnest @ 2017-08-22 17:24 UTC (permalink / raw)
To: Erik Aronesty, Bitcoin Protocol Discussion, Chris Riley; +Cc: Matthew Beton
[-- Attachment #1: Type: text/plain, Size: 4107 bytes --]
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
> <mailto: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
> <mailto: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.
>
[-- Attachment #2: Type: text/html, Size: 6637 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] UTXO growth scaling solution proposal
2017-08-22 17:24 ` Thomas Guyot-Sionnest
@ 2017-08-22 17:33 ` Matthew Beton
2017-08-22 18:55 ` Chris Riley
0 siblings, 1 reply; 24+ messages in thread
From: Matthew Beton @ 2017-08-22 17:33 UTC (permalink / raw)
To: Thomas Guyot-Sionnest, Erik Aronesty,
Bitcoin Protocol Discussion, Chris Riley
[-- Attachment #1: Type: text/plain, Size: 4251 bytes --]
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.
>>>
>>
>
[-- Attachment #2: Type: text/html, Size: 7308 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] UTXO growth scaling solution proposal
2017-08-22 17:33 ` Matthew Beton
@ 2017-08-22 18:55 ` Chris Riley
2017-08-22 20:06 ` Erik Aronesty
0 siblings, 1 reply; 24+ messages in thread
From: Chris Riley @ 2017-08-22 18:55 UTC (permalink / raw)
To: Matthew Beton; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 5189 bytes --]
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.
>>>>
>>>
>>
[-- Attachment #2: Type: text/html, Size: 8716 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] UTXO growth scaling solution proposal
2017-08-22 18:55 ` Chris Riley
@ 2017-08-22 20:06 ` Erik Aronesty
2017-08-22 20:20 ` Mark Friedenbach
0 siblings, 1 reply; 24+ messages in thread
From: Erik Aronesty @ 2017-08-22 20:06 UTC (permalink / raw)
To: Chris Riley; +Cc: Bitcoin Protocol Discussion, Matthew Beton
[-- Attachment #1: Type: text/plain, Size: 7233 bytes --]
> 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.
>>>>>
>>>>
>>>
>
[-- Attachment #2: Type: text/html, Size: 11228 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] UTXO growth scaling solution proposal
2017-08-22 20:06 ` Erik Aronesty
@ 2017-08-22 20:20 ` Mark Friedenbach
0 siblings, 0 replies; 24+ messages in thread
From: Mark Friedenbach @ 2017-08-22 20:20 UTC (permalink / raw)
To: Erik Aronesty, Bitcoin Protocol Discussion; +Cc: Matthew Beton
[-- Attachment #1: Type: text/plain, Size: 7579 bytes --]
A fun exercise to be sure, but perhaps off topic for this list?
> 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-dev
[-- Attachment #2: Type: text/html, Size: 12022 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] UTXO growth scaling solution proposal
2017-08-22 23:29 ` Thomas Guyot-Sionnest
@ 2017-08-23 3:26 ` Mark Friedenbach
0 siblings, 0 replies; 24+ messages in thread
From: Mark Friedenbach @ 2017-08-23 3:26 UTC (permalink / raw)
To: Thomas Guyot-Sionnest, Bitcoin Protocol Discussion; +Cc: Rodney Morris
[-- Attachment #1: Type: text/plain, Size: 3147 bytes --]
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.
> 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
[-- Attachment #2: Type: text/html, Size: 4665 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] UTXO growth scaling solution proposal
2017-08-22 22:58 Rodney Morris
@ 2017-08-22 23:29 ` Thomas Guyot-Sionnest
2017-08-23 3:26 ` Mark Friedenbach
0 siblings, 1 reply; 24+ messages in thread
From: Thomas Guyot-Sionnest @ 2017-08-22 23:29 UTC (permalink / raw)
To: Rodney Morris, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 2700 bytes --]
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 <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
>
[-- Attachment #2: Type: text/html, Size: 3716 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] UTXO growth scaling solution proposal
2017-08-22 22:17 Daniele Pinna
@ 2017-08-22 23:27 ` Thomas Guyot-Sionnest
0 siblings, 0 replies; 24+ messages in thread
From: Thomas Guyot-Sionnest @ 2017-08-22 23:27 UTC (permalink / raw)
To: Daniele Pinna, Bitcoin Protocol Discussion
On 22/08/17 06:17 PM, Daniele Pinna via bitcoin-dev wrote:
> 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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] UTXO growth scaling solution proposal
@ 2017-08-22 22:58 Rodney Morris
2017-08-22 23:29 ` Thomas Guyot-Sionnest
0 siblings, 1 reply; 24+ messages in thread
From: Rodney Morris @ 2017-08-22 22:58 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 3600 bytes --]
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
> 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
>
>
>
[-- Attachment #2: Type: text/html, Size: 4581 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] UTXO growth scaling solution proposal
@ 2017-08-22 22:17 Daniele Pinna
2017-08-22 23:27 ` Thomas Guyot-Sionnest
0 siblings, 1 reply; 24+ messages in thread
From: Daniele Pinna @ 2017-08-22 22:17 UTC (permalink / raw)
To: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 163 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 202 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] UTXO growth scaling solution proposal
2017-08-21 14:26 ` Moral Agent
@ 2017-08-21 17:24 ` Erik Aronesty
0 siblings, 0 replies; 24+ messages in thread
From: Erik Aronesty @ 2017-08-21 17:24 UTC (permalink / raw)
To: Moral Agent, Bitcoin Protocol Discussion; +Cc: Major Kusanagi
[-- Attachment #1: Type: text/plain, Size: 6118 bytes --]
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:
> 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
>
>
[-- Attachment #2: Type: text/html, Size: 8217 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] UTXO growth scaling solution proposal
2017-08-21 13:35 ` Thomas Guyot-Sionnest
@ 2017-08-21 14:26 ` Moral Agent
2017-08-21 17:24 ` Erik Aronesty
0 siblings, 1 reply; 24+ messages in thread
From: Moral Agent @ 2017-08-21 14:26 UTC (permalink / raw)
To: Thomas Guyot-Sionnest, Bitcoin Protocol Discussion; +Cc: Major Kusanagi
[-- Attachment #1: Type: text/plain, Size: 4404 bytes --]
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
>
[-- Attachment #2: Type: text/html, Size: 5815 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] UTXO growth scaling solution proposal
2017-07-21 19:59 ` Lucas Clemente Vella
2017-07-21 20:17 ` Moral Agent
2017-07-22 6:45 ` Major Kusanagi
@ 2017-08-21 13:35 ` Thomas Guyot-Sionnest
2017-08-21 14:26 ` Moral Agent
2 siblings, 1 reply; 24+ messages in thread
From: Thomas Guyot-Sionnest @ 2017-08-21 13:35 UTC (permalink / raw)
To: Lucas Clemente Vella, Bitcoin Protocol Discussion, Major Kusanagi
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] UTXO growth scaling solution proposal
2017-07-21 19:59 ` Lucas Clemente Vella
2017-07-21 20:17 ` Moral Agent
@ 2017-07-22 6:45 ` Major Kusanagi
2017-08-21 13:35 ` Thomas Guyot-Sionnest
2 siblings, 0 replies; 24+ messages in thread
From: Major Kusanagi @ 2017-07-22 6:45 UTC (permalink / raw)
To: Lucas Clemente Vella, bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 2328 bytes --]
On Fri, Jul 21, 2017 at 12:59 PM, Lucas Clemente Vella <lvella@gmail•com>
wrote:
> 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.
> 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
> 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.
> --
> Lucas Clemente Vella
> lvella@gmail•com
>
[-- Attachment #2: Type: text/html, Size: 4087 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] UTXO growth scaling solution proposal
2017-07-21 19:54 ` Jameson Lopp
@ 2017-07-22 6:43 ` Major Kusanagi
0 siblings, 0 replies; 24+ messages in thread
From: Major Kusanagi @ 2017-07-22 6:43 UTC (permalink / raw)
To: Jameson Lopp, bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 8330 bytes --]
On Fri, Jul 21, 2017 at 12:54 PM, Jameson Lopp <jameson.lopp@gmail•com>
wrote:
> 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.
> 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.
> 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.
> 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.
> - 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
>>
>>
>
[-- Attachment #2: Type: text/html, Size: 10269 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] UTXO growth scaling solution proposal
2017-07-21 19:59 ` Lucas Clemente Vella
@ 2017-07-21 20:17 ` Moral Agent
2017-07-22 6:45 ` Major Kusanagi
2017-08-21 13:35 ` Thomas Guyot-Sionnest
2 siblings, 0 replies; 24+ messages in thread
From: Moral Agent @ 2017-07-21 20:17 UTC (permalink / raw)
To: Lucas Clemente Vella, Bitcoin Protocol Discussion; +Cc: Major Kusanagi
[-- Attachment #1: Type: text/plain, Size: 2492 bytes --]
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:
> 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
>
>
[-- Attachment #2: Type: text/html, Size: 3896 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] UTXO growth scaling solution proposal
2017-07-21 19:28 Major Kusanagi
2017-07-21 19:52 ` Jeremy
2017-07-21 19:54 ` Jameson Lopp
@ 2017-07-21 19:59 ` Lucas Clemente Vella
2017-07-21 20:17 ` Moral Agent
` (2 more replies)
2 siblings, 3 replies; 24+ messages in thread
From: Lucas Clemente Vella @ 2017-07-21 19:59 UTC (permalink / raw)
To: Major Kusanagi, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 1577 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 2358 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] UTXO growth scaling solution proposal
2017-07-21 19:28 Major Kusanagi
2017-07-21 19:52 ` Jeremy
@ 2017-07-21 19:54 ` Jameson Lopp
2017-07-22 6:43 ` Major Kusanagi
2017-07-21 19:59 ` Lucas Clemente Vella
2 siblings, 1 reply; 24+ messages in thread
From: Jameson Lopp @ 2017-07-21 19:54 UTC (permalink / raw)
To: Major Kusanagi, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 6829 bytes --]
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:
> 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
>
>
[-- Attachment #2: Type: text/html, Size: 7558 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] UTXO growth scaling solution proposal
2017-07-21 19:28 Major Kusanagi
@ 2017-07-21 19:52 ` Jeremy
2017-07-21 19:54 ` Jameson Lopp
2017-07-21 19:59 ` Lucas Clemente Vella
2 siblings, 0 replies; 24+ messages in thread
From: Jeremy @ 2017-07-21 19:52 UTC (permalink / raw)
To: Major Kusanagi, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 6265 bytes --]
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 <
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
>
>
[-- Attachment #2: Type: text/html, Size: 7730 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* [bitcoin-dev] UTXO growth scaling solution proposal
@ 2017-07-21 19:28 Major Kusanagi
2017-07-21 19:52 ` Jeremy
` (2 more replies)
0 siblings, 3 replies; 24+ messages in thread
From: Major Kusanagi @ 2017-07-21 19:28 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 5446 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 5725 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2017-08-23 3:26 UTC | newest]
Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-08-22 8:19 [bitcoin-dev] UTXO growth scaling solution proposal Matthew Beton
2017-08-22 13:45 ` Chris Riley
2017-08-22 14:04 ` Matthew Beton
2017-08-22 14:29 ` Erik Aronesty
2017-08-22 17:24 ` Thomas Guyot-Sionnest
2017-08-22 17:33 ` Matthew Beton
2017-08-22 18:55 ` Chris Riley
2017-08-22 20:06 ` Erik Aronesty
2017-08-22 20:20 ` Mark Friedenbach
-- strict thread matches above, loose matches on Subject: below --
2017-08-22 22:58 Rodney Morris
2017-08-22 23:29 ` Thomas Guyot-Sionnest
2017-08-23 3:26 ` Mark Friedenbach
2017-08-22 22:17 Daniele Pinna
2017-08-22 23:27 ` Thomas Guyot-Sionnest
2017-07-21 19:28 Major Kusanagi
2017-07-21 19:52 ` Jeremy
2017-07-21 19:54 ` Jameson Lopp
2017-07-22 6:43 ` Major Kusanagi
2017-07-21 19:59 ` Lucas Clemente Vella
2017-07-21 20:17 ` Moral Agent
2017-07-22 6:45 ` Major Kusanagi
2017-08-21 13:35 ` Thomas Guyot-Sionnest
2017-08-21 14:26 ` Moral Agent
2017-08-21 17:24 ` Erik Aronesty
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox