path: root/2e/6761857c1633f2464cc853bb754a0043608405

Return-Path: <mark@friedenbach.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id EDF7998A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 22 Aug 2017 20:20:52 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pg0-f42.google.com (mail-pg0-f42.google.com [74.125.83.42])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DED1D4A2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 22 Aug 2017 20:20:52 +0000 (UTC)
Received: by mail-pg0-f42.google.com with SMTP id s14so14655338pgs.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 22 Aug 2017 13:20:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=friedenbach-org.20150623.gappssmtp.com; s=20150623;
	h=mime-version:subject:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to;
	bh=0ceo/GixKY/8XjtQDDxpY6wQny45KnWClgjtIyZecC0=;
	b=htE0ROQ6frVFig+B/NT53T3chlAZyTl0G3/XcGVgCf3Fwq9lmqGNQjL0G1DrGnxIQI
	Cpmj6DJX1SrfWNpmLqDBEE7xezr9Ukt0lymRSKIvbdWuR0+TcrNBJfE2XoAR6uR4bvXH
	9LlZe+3uAO9r5KitDMPArwTL8NY8q63DNEBlbGTluxoQQk4b4M2X3sCjy0bxTrU0FwER
	P3Xw88nqhJCcjVC+habtieexe8yUsEGhL2kFLyd0ncBMwzzphICepYHD1HGhqN1dRFfh
	dfEFTAxGdVMxBnJG1UZ1TnOZURKGbdrQXFOsutLVWd6RleQ47pps1AKKz2lbNLnZZCCP
	++NQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to;
	bh=0ceo/GixKY/8XjtQDDxpY6wQny45KnWClgjtIyZecC0=;
	b=Dkx7uBvjDDmUO+lTjGe14M83yav7mgKOtpxlQw4++URA0QvaWg4S6lioRlryLK5Lr3
	ORMbQhFeNWRcc8pWjwLxY+/eBZvpyaOe1haI763zDS+feqVHaxUlNptu5tU1renoV8sU
	5nZ5kWjffBRy/Jovn4e2nnWLLzDEHDEzENnoA8WHNEQcZhEHEHKx5V+mqxZAHL8+DBKI
	q0lr3o7rkLx9ETgWsAwEoT4Cb47wERvwkmtwJlSlzqpVVKoV3XnCBg5nAxD+n5+NBH3d
	/xgB18qzzRAQkhRrVQriYNu52fbhGBEGeLqh4whl0uumkeUQWzYZv1x7H/EPomRi8nde
	fhEw==
X-Gm-Message-State: AHYfb5i6GaMSFoJUOcKcn6ykZlNM2z67leAyT7wDc+x+qy7nxZCaiFGn
	OrmIx0vhtCMS9R7kjahlMQ==
X-Received: by 10.99.105.8 with SMTP id e8mr327972pgc.165.1503433252287;
	Tue, 22 Aug 2017 13:20:52 -0700 (PDT)
Received: from ?IPv6:2607:fb90:a763:3a55:e57d:8633:335a:491a?
	([2607:fb90:a763:3a55:e57d:8633:335a:491a])
	by smtp.gmail.com with ESMTPSA id
	w124sm30237582pfd.179.2017.08.22.13.20.43
	(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 22 Aug 2017 13:20:50 -0700 (PDT)
Content-Type: multipart/alternative;
	boundary=Apple-Mail-092E1A86-58FB-4B83-98EE-BF81B98A10AE
Mime-Version: 1.0 (1.0)
From: Mark Friedenbach <mark@friedenbach.org>
X-Mailer: iPhone Mail (14G60)
In-Reply-To: <CAJowKg+LSKcB8p3ab1jcd5-OnSavFqE+Brkf80tGGFxsDD+mHQ@mail.gmail.com>
Date: Tue, 22 Aug 2017 13:20:41 -0700
Content-Transfer-Encoding: 7bit
Message-Id: <3E90F36F-A583-4B46-A6AF-2C78FE3F48B2@friedenbach.org>
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>
	<CAJowKg+LSKcB8p3ab1jcd5-OnSavFqE+Brkf80tGGFxsDD+mHQ@mail.gmail.com>
To: Erik Aronesty <erik@q32.com>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
X-Mailman-Approved-At: Tue, 22 Aug 2017 20:21:46 +0000
Cc: 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:20:53 -0000


--Apple-Mail-092E1A86-58FB-4B83-98EE-BF81B98A10AE
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

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@li=
sts.linuxfoundation.org> wrote:
>=20
> > The initial message I replied to stated:
>=20
> Yes, 3 years is silly.  But coin expiration and quantum resistance is some=
thing I've been thinking about for a while, so I tried to steer the conversa=
tion away from stealing old money for no reason ;).   Plus I like the idea o=
f making Bitcoin "2000 year proof".
>=20
> - I cannot imagine either SHA256 or any of our existing wallet formats sur=
viving 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 a=
ddresses.
>=20
>  - 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 r=
endered 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 aut=
omatically kick in.
>=20
>  - 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 co=
nfigurable, and trivially changed.   These can be made immediately available=
 but completely optional.
>=20
>  - The POW difficulty can be used to inform the expiration of any addresse=
s that can be compromised within 5 years assuming this power was somehow use=
d to compromise them.   Some mechanism for translating global hashpower to b=
rute 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.
>=20
> - Planning a hard fork 100 to 1000 years out is a fun exercise
>=20
>=20
>=20
>=20
>> 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 th=
is 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=
...."
>>=20
>> 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 un=
needed and irresponsible.  Besides, your ECDSA is only revealed when you spe=
nd the coins which does provide some quantum resistance.  Hal was just an ex=
ample of people putting their coins away expecting them to be there at X yea=
rs in the future, whether it is for himself or for his kids and wife. =20
>>=20
>> :-)
>>=20
>>=20
>>=20
>>> 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 wi=
ll be 2^100 times faster (possibly more if quantum computing becomes commonp=
lace), and so old wallets may be easily cracked.
>>>=20
>>> 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 bein=
g hacked.
>>>=20
>>>=20
>>>> On Tue, 22 Aug 2017, 7:24 pm Thomas Guyot-Sionnest <dermoth@aei.ca> wro=
te:
>>>> In any case when Hal Finney do not wake up from his 200years cryo-prese=
rvation (because unfortunately for him 200 years earlier they did not know h=
ow to preserve a body well enough to resurrect it) he would find that advanc=
e 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 a=
s it became profitable to crack down the huge stash of coins stale in the ea=
rly blocks)
>>>>=20
>>>> I just don't get that argument that you can't be "your own bank". The o=
nly requirement coming from this would be to move your coins about once ever=
y 10 years or so, which you should be able to do if you have your private ke=
ys (you should!). You say it may be something to consider when computer brea=
kthroughs makes old outputs vulnerable, but I say it's not "if" but "when" i=
t happens, and by telling firsthand people that their coins requires moving e=
very once in a long while you ensure they won't do stupid things or come bac=
k 50 years from now and complain their addresses have been scavenged.
>>>>=20
>>>> --
>>>> Thomas
>>>>=20
>>>>=20
>>>>> 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 th=
reat to the security of Bitcoin.  =20
>>>>>=20
>>>>>> 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 tha=
t 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 bitc=
oin in that you can no longer control your own money ("be your own bank") be=
cause someone can at a later date take your coins for some reason that is ou=
tside your control and solely based on some rationalization by a third party=
.  Once the rule is established that there are valid reasons why someone sho=
uld not have control of their own bitcoins, what other reasons will then be d=
etermined to be valid?
>>>>>>=20
>>>>>> I can imagine Hal Finney being revived (he was cryo-preserved at Alco=
r if you aren't aware) after 100 or 200 years expecting his coins to be ther=
e only to find out that his coins were deemed "stale" so were "reclaimed" (i=
n the current doublespeak - e.g. stolen or confiscated).  Or perhaps he lock=
ed some for his children and they are found to be "stale" before they are av=
ailable.  He said in March 2013, "I think they're safe enough" stored in a p=
aper wallet.  Perhaps any remaining coins are no longer "safe enough."
>>>>>>=20
>>>>>> Again, this seems (a) more about an alt-coin/bitcoin fork or (b) bett=
er in bitcoin-discuss at best vs bitcoin-dev. I've seen it discussed many ti=
mes since 2010 and still do not agree with the rational that embracing allow=
ing someone to steal someone else's coins for any reason is a useful change t=
o bitcoin.
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> On Tue, Aug 22, 2017 at 4:19 AM, Matthew Beton via bitcoin-dev <bitco=
in-dev@lists.linuxfoundation.org>                     wrote:
>>>>>>> Okay so I quite like this idea. If we start removing at height 63000=
0 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:
>>>>>>>=20
>>>>>>> B - the current block number
>>>>>>> P - how many blocks behind current the coin burning block is. (63000=
0, 840000, or otherwise.)
>>>>>>>=20
>>>>>>> Every time we mine a new block, we go to block (B-P), and check for s=
tale coins. These coins get burnt up and pooled into block B's miner fees. T=
his keeps the mining rewards up in the long term, people are less likely to s=
top                         mining due to too low fees. It also encourages p=
eople to keep moving their money around the enconomy instead of just hording=
 and leaving it.=20
>>>>=20
>>=20
>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

--Apple-Mail-092E1A86-58FB-4B83-98EE-BF81B98A10AE
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div>A fun exercise to be sure, but perhaps=
 off topic for this list?<br></div><div><br>On Aug 22, 2017, at 1:06 PM, Eri=
k Aronesty via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoun=
dation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br><br></di=
v><blockquote type=3D"cite"><div><div dir=3D"ltr"><div><div>&gt; The initial=
 message I replied to stated:<br><br>Yes, 3 years is silly.&nbsp; But coin e=
xpiration 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 fo=
r no reason ;).&nbsp;&nbsp; Plus I like the idea of making Bitcoin "2000 yea=
r proof".<br><br>- I cannot imagine either SHA256 or any of our existing wal=
let formats=20
surviving 200 years, if we expect both moores law and quantum computing to b=
e a thing.&nbsp;&nbsp; I would expect the PoW to be rendered obsolete before=
 the Bitcoin addresses.<br><br></div>&nbsp;- A PoW change using Keccak and a=
 flexible number of bits can be designed as a "future hard fork".&nbsp; That=
 is:&nbsp; the existing POW can be automatically rendered obsolete... but on=
ly in the event that difficulty rises to the level of obsolescence.&nbsp;&nb=
sp; Then the code for a new algorithm with a flexible number of bits and a d=
ifficulty that can scale for thousands of years can then automatically kick i=
n.<br><br>&nbsp;- A new addresses format and signing protocols that use a fl=
exible number of bits can be introduced.&nbsp;&nbsp; The maximum number of s=
upported bits can be configurable, and trivially changed.&nbsp;&nbsp; These c=
an be made immediately available but completely optional.<br><br>&nbsp;- The=
 POW difficulty can be used to inform the expiration of any addresses that c=
an be compromised within 5 years assuming this power was somehow used to com=
promise them.&nbsp;&nbsp; Some mechanism for translating global hashpower to=
 brute force attack power can be researched, and consesrvative estimates mad=
e.&nbsp;&nbsp; Right now, it's like "heat death of the universe" amount of t=
ime to crack with every machine on the planet.&nbsp;&nbsp; But hey... things=
 change and 2000 years is a long time.&nbsp;&nbsp; This information can be u=
sed to inform the expiration and reclamation of old, compromised public addr=
esses.<br><br></div>- Planning a hard fork 100 to 1000 years out is a fun ex=
ercise<br><br><div><div><br><br></div></div></div><div class=3D"gmail_extra"=
><br><div class=3D"gmail_quote">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"><di=
v dir=3D"ltr">The initial message I replied to stated in part, "Okay so I qu=
ite like this idea. If we start removing at height 630000 or 840000 (gives u=
s 4-8 years to develop this solution), it stays nice and neat with the halvi=
ng interval...."<div><br></div><div>That is less than 3 years or less than 7=
 years &nbsp;away. Much sooner than it is believed QC or Moore's law could i=
mpact bitcoin.&nbsp; Changing bitcoin so as to require that early coins star=
t getting "scavenged" at that date seems unneeded and irresponsible.&nbsp; B=
esides, your ECDSA is only revealed when you spend the coins which does prov=
ide some quantum resistance.&nbsp; Hal was just an example of people putting=
 their coins away expecting them to be there at X years in the future, wheth=
er it is for himself or for his kids and wife. &nbsp;</div><div><br></div><d=
iv>:-)</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, 201=
7 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.com</a>&gt;</span> wr=
ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex"><p dir=3D"ltr">Very true, if Moore's l=
aw is still functional in 200 years, computers will be 2^100 times faster (p=
ossibly more if quantum computing becomes commonplace), and so old wallets m=
ay be easily cracked.</p>
<p dir=3D"ltr">We will need a way to force people to use newer, higher secur=
ity wallets, and turning coins to mining rewards is better solution than the=
m just being hacked.</p><div class=3D"m_-1302125287424471762HOEnZb"><div cla=
ss=3D"m_-1302125287424471762h5">
<br><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, 22 Aug 2017, 7:24 pm=
 Thomas Guyot-Sionnest &lt;<a href=3D"mailto:dermoth@aei.ca" target=3D"_blan=
k">dermoth@aei.ca</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" s=
tyle=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'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.<br>
    <br>
    --<br>
    Thomas</div><div bgcolor=3D"#FFFFFF" text=3D"#000000"><br>
    <br>
    <div class=3D"m_-1302125287424471762m_3177413587481095407m_5030585918581=
810662moz-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.&nbsp;&nbsp; <br=
>
      </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:bitc=
oin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linux=
founda<wbr>tion.org</a>&gt;</span>
          wrote:<br>
          <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex">
            <div dir=3D"ltr">This seems to be drifting off into alt-coin
              discussion.&nbsp; The idea that we can change the rules and
              steal coins at a later date because they are "stale" or
              someone is "hoarding" is&nbsp;antithetical to one of the point=
s
              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.&nbsp; 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?
              <div><br>
              </div>
              <div>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).&nbsp; Or perhaps he locked some for his
                children and they are found to be "stale" before they
                are available.&nbsp; He said in March 2013, "I think they're=

                safe enough" stored in a paper wallet.&nbsp; Perhaps any
                remaining coins are no longer "safe enough."<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'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.</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_3177413587481095407m=
_5030585918581810662h5">On Tue, Aug 22, 2017 at 4:19 AM,
                    Matthew Beton via bitcoin-dev <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitco=
in-dev@lists.linuxfounda<wbr>tion.org</a>&gt;</span>
                    wrote:<br>
                  </div>
                </div>
                <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex">
                  <div>
                    <div class=3D"m_-1302125287424471762m_317741358748109540=
7m_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:</span=
><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'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.</sp=
an>
                      <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>
</div></blockquote><blockquote type=3D"cite"><div><span>____________________=
___________________________</span><br><span>bitcoin-dev mailing list</span><=
br><span><a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-de=
v@lists.linuxfoundation.org</a></span><br><span><a href=3D"https://lists.lin=
uxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation=
.org/mailman/listinfo/bitcoin-dev</a></span><br></div></blockquote></body></=
html>=

--Apple-Mail-092E1A86-58FB-4B83-98EE-BF81B98A10AE--