summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorErik Aronesty <erik@q32.com>2017-08-22 16:06:01 -0400
committerbitcoindev <bitcoindev@gnusha.org>2017-08-22 20:06:04 +0000
commitddc6c1ff573591354ff12a4291f874dfd0142685 (patch)
tree2684b6a606310f138adde117a9b5281540d396f7
parent7a2b7511d20d31357c62385f4249691952c7591c (diff)
downloadpi-bitcoindev-ddc6c1ff573591354ff12a4291f874dfd0142685.tar.gz
pi-bitcoindev-ddc6c1ff573591354ff12a4291f874dfd0142685.zip
Re: [bitcoin-dev] UTXO growth scaling solution proposal
-rw-r--r--98/1e6a2812102a69f1891d41500d0b13c40c13d4440
1 files changed, 440 insertions, 0 deletions
diff --git a/98/1e6a2812102a69f1891d41500d0b13c40c13d4 b/98/1e6a2812102a69f1891d41500d0b13c40c13d4
new file mode 100644
index 000000000..76ae74555
--- /dev/null
+++ b/98/1e6a2812102a69f1891d41500d0b13c40c13d4
@@ -0,0 +1,440 @@
+Return-Path: <earonesty@gmail.com>
+Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
+ [172.17.192.35])
+ by mail.linuxfoundation.org (Postfix) with ESMTPS id 8D1E48D7
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Tue, 22 Aug 2017 20:06:04 +0000 (UTC)
+X-Greylist: whitelisted by SQLgrey-1.7.6
+Received: from mail-wm0-f53.google.com (mail-wm0-f53.google.com [74.125.82.53])
+ by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 21A611AC
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Tue, 22 Aug 2017 20:06:04 +0000 (UTC)
+Received: by mail-wm0-f53.google.com with SMTP id b189so1760863wmd.0
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Tue, 22 Aug 2017 13:06:03 -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=8D8AZdnFjMg1mUZNZ1rrmtaRuiHhOFkdqW5HYWrKaAY=;
+ b=bGTKQv0YUsZGnNp54SyDSqUs4RwRUT18EBUpAaRR4ZOQTkR4JibH9MvgJt29pMs4n1
+ pnUP3bBiY36Q8uLfLnTqzkq/6jyLwDwiuNwlUflaeYgq08q51U8r1Ek1KGzH/KBZ98bl
+ S6td0lyMbwdggNB4T98GVHy37+ZBSQZm0m3XVRni+DlQCuVpC4dGq1eeNmcz7Ed2/8yB
+ /Yl69Vwnfs/toDPoDEpKX/rPWldA/WSN88G8nUec5C4JIfSA/OAOFv2MW3lkPdN/0TJs
+ rvL4syXLLsSPgLkLBvD+rwtpcVMA+qAhy9xtno6k49sQt2uxhOuT7t5U0/CJdcBYTssa
+ M9JA==
+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=8D8AZdnFjMg1mUZNZ1rrmtaRuiHhOFkdqW5HYWrKaAY=;
+ b=r6Ak0rz3QSxmuTU9zCCiv17l+YsnGddb6PoEx8dUEvGzq0L+jloW6wWiQacdhQu1Wj
+ LPashq9Rig9gpB+Dd145btEEUbJoCJFahdXljqlRAApem91hfdxQ3dOTXg3HNeHZcj2I
+ cyCetXz0GHX81AYv615kmoENGTf5LXiAMvNO997wxdo+dj95IFk8RStDF/5xPoyR1lGq
+ OUH687z32Nh4iqD8qXSJacA8kVhulhupZUd5RiEJXnbYdzISdvfUxADDqPe0sLxnO541
+ 36mov7VcKmrAtBXTFWI+W5VuY6wxaOx9oHmTxY6E0IxLPeI+PGwRsdCTOQhVKVOWLfo3
+ WVLw==
+X-Gm-Message-State: AHYfb5jKO29kJn0UdvIUw0kkjN0LCBlJVykoTu1nRqVCdjFhtnXdGZta
+ kHv7hBSRgK84VZQeeHf77ByXssuwUA==
+X-Received: by 10.28.136.8 with SMTP id k8mr367896wmd.67.1503432362485; Tue,
+ 22 Aug 2017 13:06:02 -0700 (PDT)
+MIME-Version: 1.0
+Sender: earonesty@gmail.com
+Received: by 10.28.225.135 with HTTP; Tue, 22 Aug 2017 13:06:01 -0700 (PDT)
+In-Reply-To: <CAL5BAw2Tv-=_j7nPL5a+M0zaPQEKBEP9U_oCLL1J6Gefmrrh=g@mail.gmail.com>
+References: <CALKSEdq0CUKPY2u+WfAaWtg5nXYKCJzRnDbU2iMs8PQQSpPDGA@mail.gmail.com>
+ <CAL5BAw2GoQb3-R1Ybe581MbOQvx8wvT0bLoEQ29caNVJTFShmA@mail.gmail.com>
+ <CAJowKgJhN=Se=kqrFR_B4zJQGf3iBpM6hU+xeUN9eANsmVuwXQ@mail.gmail.com>
+ <4c39bee6-f419-2e36-62a8-d38171b15558@aei.ca>
+ <CALKSEdrQoQkW7gQF5k=HFqzq6txfXwPpw8ui5um9bp+gZKNonw@mail.gmail.com>
+ <CAL5BAw2Tv-=_j7nPL5a+M0zaPQEKBEP9U_oCLL1J6Gefmrrh=g@mail.gmail.com>
+From: Erik Aronesty <erik@q32.com>
+Date: Tue, 22 Aug 2017 16:06:01 -0400
+X-Google-Sender-Auth: 6NMa2yNsWVUZTiIZ2QljehBdBm4
+Message-ID: <CAJowKg+LSKcB8p3ab1jcd5-OnSavFqE+Brkf80tGGFxsDD+mHQ@mail.gmail.com>
+To: Chris Riley <criley@gmail.com>
+Content-Type: multipart/alternative; boundary="001a114434fae8f03605575d1f1c"
+X-Mailman-Approved-At: Tue, 22 Aug 2017 20:10:48 +0000
+Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
+ Matthew Beton <matthew.beton@gmail.com>
+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 <bitcoin-dev.lists.linuxfoundation.org>
+List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
+ <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
+List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
+List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
+List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
+List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
+ <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
+X-List-Received-Date: Tue, 22 Aug 2017 20:06:04 -0000
+
+--001a114434fae8f03605575d1f1c
+Content-Type: text/plain; charset="UTF-8"
+
+> 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.
+>>>>>
+>>>>
+>>>
+>
+
+--001a114434fae8f03605575d1f1c
+Content-Type: text/html; charset="UTF-8"
+Content-Transfer-Encoding: quoted-printable
+
+<div dir=3D"ltr"><div><div>&gt; The initial message I replied to stated:<br=
+><br>Yes, 3 years is silly.=C2=A0 But coin expiration and quantum resistanc=
+e is something I&#39;ve been thinking about for a while, so I tried to stee=
+r the conversation away from stealing old money for no reason ;).=C2=A0=C2=
+=A0 Plus I like the idea of making Bitcoin &quot;2000 year proof&quot;.<br>=
+<br>- I cannot imagine either SHA256 or any of our existing wallet formats=
+=20
+surviving 200 years, if we expect both moores law and quantum computing to =
+be a thing.=C2=A0=C2=A0 I would expect the PoW to be rendered obsolete befo=
+re the Bitcoin addresses.<br><br></div>=C2=A0- A PoW change using Keccak an=
+d a flexible number of bits can be designed as a &quot;future hard fork&quo=
+t;.=C2=A0 That is:=C2=A0 the existing POW can be automatically rendered obs=
+olete... but only in the event that difficulty rises to the level of obsole=
+scence.=C2=A0=C2=A0 Then the code for a new algorithm with a flexible numbe=
+r of bits and a difficulty that can scale for thousands of years can then a=
+utomatically kick in.<br><br>=C2=A0- A new addresses format and signing pro=
+tocols that use a flexible number of bits can be introduced.=C2=A0=C2=A0 Th=
+e maximum number of supported bits can be configurable, and trivially chang=
+ed.=C2=A0=C2=A0 These can be made immediately available but completely opti=
+onal.<br><br>=C2=A0- The POW difficulty can be used to inform the expiratio=
+n of any addresses that can be compromised within 5 years assuming this pow=
+er was somehow used to compromise them.=C2=A0=C2=A0 Some mechanism for tran=
+slating global hashpower to brute force attack power can be researched, and=
+ consesrvative estimates made.=C2=A0=C2=A0 Right now, it&#39;s like &quot;h=
+eat death of the universe&quot; amount of time to crack with every machine =
+on the planet.=C2=A0=C2=A0 But hey... things change and 2000 years is a lon=
+g time.=C2=A0=C2=A0 This information can be used to inform the expiration a=
+nd reclamation of old, compromised public addresses.<br><br></div>- Plannin=
+g a hard fork 100 to 1000 years out is a fun exercise<br><br><div><div><br>=
+<br></div></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_qu=
+ote">On Tue, Aug 22, 2017 at 2:55 PM, Chris Riley <span dir=3D"ltr">&lt;<a =
+href=3D"mailto:criley@gmail.com" target=3D"_blank">criley@gmail.com</a>&gt;=
+</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
+8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">The initi=
+al message I replied to stated in part, &quot;Okay so I quite like this ide=
+a. If we start removing at height 630000 or 840000 (gives us 4-8 years to d=
+evelop this solution), it stays nice and neat with the halving interval....=
+&quot;<div><br></div><div>That is less than 3 years or less than 7 years =
+=C2=A0away. Much sooner than it is believed QC or Moore&#39;s law could imp=
+act bitcoin.=C2=A0 Changing bitcoin so as to require that early coins start=
+ getting &quot;scavenged&quot; at that date seems unneeded and irresponsibl=
+e.=C2=A0 Besides, your ECDSA is only revealed when you spend the coins whic=
+h does provide some quantum resistance.=C2=A0 Hal was just an example of pe=
+ople 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. =C2=A0</div><di=
+v><br></div><div>:-)</div><div><div class=3D"h5"><div><br></div><div><div><=
+br></div><div><br><div class=3D"gmail_extra"><div class=3D"gmail_quote">On =
+Tue, Aug 22, 2017 at 1:33 PM, Matthew Beton <span dir=3D"ltr">&lt;<a href=
+=3D"mailto:matthew.beton@gmail.com" target=3D"_blank">matthew.beton@gmail.c=
+om</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg=
+in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir=3D"ltr">V=
+ery true, if Moore&#39;s law is still functional in 200 years, computers wi=
+ll be 2^100 times faster (possibly more if quantum computing becomes common=
+place), and so old wallets may be easily cracked.</p>
+<p dir=3D"ltr">We will need a way to force people to use newer, higher secu=
+rity wallets, and turning coins to mining rewards is better solution than t=
+hem just being hacked.</p><div class=3D"m_-1302125287424471762HOEnZb"><div =
+class=3D"m_-1302125287424471762h5">
+<br><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, 22 Aug 2017, 7:24 p=
+m Thomas Guyot-Sionnest &lt;<a href=3D"mailto:dermoth@aei.ca" target=3D"_bl=
+ank">dermoth@aei.ca</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quot=
+e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+ =20
+ =20
+ =20
+ <div bgcolor=3D"#FFFFFF" text=3D"#000000">
+ 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)<br>
+ <br>
+ I just don&#39;t get that argument that you can&#39;t be &quot;your own=
+ bank&quot;.
+ 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&#39;s not &quot;if&quot; but &quot;when&quot; =
+it happens, and by
+ telling firsthand people that their coins requires moving every once
+ in a long while you ensure they won&#39;t do stupid things or come back
+ 50 years from now and complain their addresses have been scavenged.<br>
+ <br>
+ --<br>
+ Thomas</div><div bgcolor=3D"#FFFFFF" text=3D"#000000"><br>
+ <br>
+ <div class=3D"m_-1302125287424471762m_3177413587481095407m_503058591858=
+1810662moz-cite-prefix">On 22/08/17 10:29 AM, Erik Aronesty via
+ bitcoin-dev wrote:<br>
+ </div>
+ <blockquote type=3D"cite">
+ <div dir=3D"ltr">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 <b=
+r>
+ </div>
+ <div class=3D"gmail_extra"><br>
+ <div class=3D"gmail_quote">On Tue, Aug 22, 2017 at 9:45 AM, Chris
+ Riley via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bit=
+coin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.lin=
+uxfounda<wbr>tion.org</a>&gt;</span>
+ wrote:<br>
+ <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
+er-left:1px #ccc solid;padding-left:1ex">
+ <div dir=3D"ltr">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 date because they are &quot;stale&quot=
+; or
+ someone is &quot;hoarding&quot; is=C2=A0antithetical to one o=
+f the points
+ of bitcoin in that you can no longer control your own
+ money (&quot;be your own bank&quot;) 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.=C2=A0 Once the rule is established that there ar=
+e
+ valid reasons why someone should not have control of their
+ own bitcoins, what other reasons will then be determined
+ to be valid?
+ <div><br>
+ </div>
+ <div>I can imagine Hal Finney being revived (he was
+ cryo-preserved at Alcor if you aren&#39;t aware) after 100
+ or 200 years expecting his coins to be there only to
+ find out that his coins were deemed &quot;stale&quot; so we=
+re
+ &quot;reclaimed&quot; (in the current doublespeak - e.g. st=
+olen or
+ confiscated).=C2=A0 Or perhaps he locked some for his
+ children and they are found to be &quot;stale&quot; before =
+they
+ are available.=C2=A0 He said in March 2013, &quot;I think t=
+hey&#39;re
+ safe enough&quot; stored in a paper wallet.=C2=A0 Perhaps a=
+ny
+ remaining coins are no longer &quot;safe enough.&quot;<br>
+ <div><br>
+ </div>
+ <div>Again, this seems (a) more about an
+ alt-coin/bitcoin fork or (b) better in bitcoin-discuss
+ at best vs bitcoin-dev. I&#39;ve seen it discussed many
+ times since 2010 and still do not agree with the
+ rational that embracing allowing someone to steal
+ someone else&#39;s coins for any reason is a useful chang=
+e
+ to bitcoin.</div>
+ <div><br>
+ </div>
+ <div><br>
+ </div>
+ <div><br>
+ </div>
+ </div>
+ </div>
+ <div class=3D"gmail_extra"><br>
+ <div class=3D"gmail_quote">
+ <div>
+ <div class=3D"m_-1302125287424471762m_3177413587481095407=
+m_5030585918581810662h5">On Tue, Aug 22, 2017 at 4:19 AM,
+ Matthew Beton via bitcoin-dev <span dir=3D"ltr">&lt;<a =
+href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bit=
+coin-dev@lists.linuxfounda<wbr>tion.org</a>&gt;</span>
+ wrote:<br>
+ </div>
+ </div>
+ <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
+x;border-left:1px #ccc solid;padding-left:1ex">
+ <div>
+ <div class=3D"m_-1302125287424471762m_31774135874810954=
+07m_5030585918581810662h5"><span>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:</spa=
+n><br>
+ <br>
+ <span>B - the current block number</span><br>
+ <span>P - how many blocks behind current the coin
+ burning block is. (630000, 840000, or
+ otherwise.)</span><br>
+ <br>
+ <span>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&#39;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.</s=
+pan>
+ <br>
+ </div>
+ </div>
+ <span></span></blockquote>
+ </div>
+ </div>
+ </blockquote>
+ </div>
+ </div>
+ </blockquote>
+ <br>
+ </div></blockquote></div>
+</div></div></blockquote></div><br></div></div></div></div></div></div>
+</blockquote></div><br></div>
+
+--001a114434fae8f03605575d1f1c--
+