<unnamed>

Public Key

npub136w76t4elj3fpxvzq0tpkm2smaav9aku7y7ccjzvhhhyqhuk8hmsgdtjc5

Profile Code

nprofile1qqsga80d96uleg5snxpq84smd4gd77kz7mw0z0vvfpxtmmjqt7trmacpzemhxue69uhhyetvv9ujuurjd9kkzmpwdejhgc9rhp3

Publishing to

relay.primal.net

Last Notes

2023-06-07 20:04:54 CEST

- reply

📅 Original date posted:2017-08-22
📝 Original message:In any case when Hal Finney do not wake up from his 200years
cryo-preservation (because unfortunately for him 200 years earlier they
did not know how to preserve a body well enough to resurrect it) he
would find that advance in computer technology made it trivial for
anyone to steal his coins using the long-obsolete secp256k1 ec curve
(which was done long before, as soon as it became profitable to crack
down the huge stash of coins stale in the early blocks)
I just don't get that argument that you can't be "your own bank". The
only requirement coming from this would be to move your coins about once
every 10 years or so, which you should be able to do if you have your
private keys (you should!). You say it may be something to consider when
computer breakthroughs makes old outputs vulnerable, but I say it's not
"if" but "when" it happens, and by telling firsthand people that their
coins requires moving every once in a long while you ensure they won't
do stupid things or come back 50 years from now and complain their
addresses have been scavenged.
--
Thomas
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 at lists.linuxfoundation.org
> <mailto:bitcoin-dev at 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 at lists.linuxfoundation.org
> <mailto:bitcoin-dev at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170822/bc4992c0/attachment.html>

2023-06-07 20:04:52 CEST

- reply

📅 Original date posted:2017-08-21
📝 Original message: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 at lists.linuxfoundation.org
> <mailto:bitcoin-dev at 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