Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id CE881B4B for ; Tue, 22 Aug 2017 14:29:28 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wr0-f194.google.com (mail-wr0-f194.google.com [209.85.128.194]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8B8E9460 for ; Tue, 22 Aug 2017 14:29:28 +0000 (UTC) Received: by mail-wr0-f194.google.com with SMTP id a47so2446029wra.0 for ; Tue, 22 Aug 2017 07:29:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=t1w+Phxas8gTyhenJXhs999/BU03LkmFUkuGT2KKuQA=; b=i1IulTXnjk/WBWR31gr8T++5J3JBwUrxaqWkcTd/9dMP1nIuJtwKQJ1dyB3VSsZxk3 r7UI7zzkWg34QxHLH6wtPCnlRE9GTzP594yvbwqr5oWoytsL3rUkKH9CQv/BIx80jcdi T1YUi5WnqKiiwo686YjgX0Hmy2sg6xFz8ynxkuHtB0rBUnmuq7nFUHacgvJWiqjAwGkV JgJdQz3Vu0hFludQfw/KnJNOv4pymoE8B4HrD1K3h1zKIpCNSewKxWA3NFQZkfF/KgM3 eVMiJIq6RBdaPvzPdFpDgtekNNvoKKQMy4djjbEH61c/NwyqpPyNKXTxp+HSOJXAROR0 PGuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=t1w+Phxas8gTyhenJXhs999/BU03LkmFUkuGT2KKuQA=; b=blnaQi0njUoU33qbDLtbUHsO75l5IEffD8Mje2BEN1Uc3j1FVKmPJ7/+odCOq0/Klr EkzDuAJn/8gqNcAxE3bJu9LsjnrWJ8ti+jB7uD4VzhCkZalzYf3Nn+2ypdvq2aJX7J2j Z1SrPZlz3YUBKwRRjNeuRtEAPrijBhwu/vvcs9LksKqLkDD4oXLT0e1O78pmlUx0mijE 1cccstD1sfOkaJK8nUeOMYysZgU+aLKS2oxOLNPFKyYiiN0gNWzIA9r8DmfrnUYSYaVM yEMSFEtE8rLrRB+R4co/EAWMSJ6wHqZnionBozdV4IMEjvr/G+43B/TBTMgUfOepeHNZ ROUg== X-Gm-Message-State: AHYfb5g57h7NWTqFFeSsCGktelNxosX1TCOZouPJD6NxpeQdlTXVoQ9q lD5XoClvpQd8MRAvCgcw0i5gQfL2IiLd X-Received: by 10.28.64.197 with SMTP id n188mr531534wma.135.1503412167029; Tue, 22 Aug 2017 07:29:27 -0700 (PDT) MIME-Version: 1.0 Sender: earonesty@gmail.com Received: by 10.28.225.135 with HTTP; Tue, 22 Aug 2017 07:29:26 -0700 (PDT) In-Reply-To: References: From: Erik Aronesty Date: Tue, 22 Aug 2017 10:29:26 -0400 X-Google-Sender-Auth: j6v51s3HU7jnrmV9-hQGBFTbm7k Message-ID: To: Chris Riley , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="001a114b2e022abaad0557586c71" X-Mailman-Approved-At: Tue, 22 Aug 2017 14:32:30 +0000 Cc: Matthew Beton Subject: Re: [bitcoin-dev] UTXO growth scaling solution proposal X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2017 14:29:28 -0000 --001a114b2e022abaad0557586c71 Content-Type: text/plain; charset="UTF-8" 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 > > --001a114b2e022abaad0557586c71 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree, it is only a good idea in the event of a quantum = computing threat to the security of Bitcoin.=C2=A0=C2=A0

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.= =C2=A0 The idea that we can change the rules and steal coins at a later dat= e because they are "stale" or someone is "hoarding" is= =C2=A0antithetical to one of the points of bitcoin in that you can no longe= r 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 contr= ol and solely based on some rationalization by a third party.=C2=A0 Once th= e rule is established that there are valid reasons why someone should not h= ave control of their own bitcoins, what other reasons will then be determin= ed 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 ye= ars expecting his coins to be there only to find out that his coins were de= emed "stale" so were "reclaimed" (in the current double= speak - e.g. stolen or confiscated).=C2=A0 Or perhaps he locked some for hi= s children and they are found to be "stale" before they are avail= able.=C2=A0 He said in March 2013, "I think they're safe enough&qu= ot; stored in a paper wallet.=C2=A0 Perhaps any remaining coins are no long= er "safe enough."

Again, this seems (a) mo= re 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 som= eone 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 <bitc= oin-dev@lists.linuxfoundation.org> wrote:
Okay so I quit= e 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 halvi= ng interval. We can look at this like so:

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

Ever= y 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 k= eeps 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


--001a114b2e022abaad0557586c71--