public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Matthew Beton <matthew.beton@gmail•com>
To: Chris Riley <criley@gmail•com>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] UTXO growth scaling solution proposal
Date: Tue, 22 Aug 2017 14:04:49 +0000	[thread overview]
Message-ID: <CALKSEdrtCKvPUWTmsBnWgj3gHjktRajDU0NGonQ-SS8-854ONA@mail.gmail.com> (raw)
In-Reply-To: <CAL5BAw2GoQb3-R1Ybe581MbOQvx8wvT0bLoEQ29caNVJTFShmA@mail.gmail.com>

[-- 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 --]

  reply	other threads:[~2017-08-22 14:05 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-22  8:19 Matthew Beton
2017-08-22 13:45 ` Chris Riley
2017-08-22 14:04   ` Matthew Beton [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CALKSEdrtCKvPUWTmsBnWgj3gHjktRajDU0NGonQ-SS8-854ONA@mail.gmail.com \
    --to=matthew.beton@gmail$(echo .)com \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=criley@gmail$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox