diff options
author | Erik Aronesty <erik@q32.com> | 2017-08-22 16:06:01 -0400 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2017-08-22 20:06:04 +0000 |
commit | ddc6c1ff573591354ff12a4291f874dfd0142685 (patch) | |
tree | 2684b6a606310f138adde117a9b5281540d396f7 | |
parent | 7a2b7511d20d31357c62385f4249691952c7591c (diff) | |
download | pi-bitcoindev-ddc6c1ff573591354ff12a4291f874dfd0142685.tar.gz pi-bitcoindev-ddc6c1ff573591354ff12a4291f874dfd0142685.zip |
Re: [bitcoin-dev] UTXO growth scaling solution proposal
-rw-r--r-- | 98/1e6a2812102a69f1891d41500d0b13c40c13d4 | 440 |
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>> 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'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 "2000 year proof".<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 "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's like "h= +eat death of the universe" 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"><<a = +href=3D"mailto:criley@gmail.com" target=3D"_blank">criley@gmail.com</a>>= +</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, "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....= +"<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's law could imp= +act bitcoin.=C2=A0 Changing bitcoin so as to require that early coins start= + getting "scavenged" 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"><<a href= +=3D"mailto:matthew.beton@gmail.com" target=3D"_blank">matthew.beton@gmail.c= +om</a>></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'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 <<a href=3D"mailto:dermoth@aei.ca" target=3D"_bl= +ank">dermoth@aei.ca</a>> 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'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_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"><<a href=3D"mailto:bit= +coin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.lin= +uxfounda<wbr>tion.org</a>></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 "stale"= +; or + someone is "hoarding" is=C2=A0antithetical to one o= +f 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.=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't aware) after 100 + or 200 years expecting his coins to be there only to + find out that his coins were deemed "stale" so we= +re + "reclaimed" (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 "stale" before = +they + are available.=C2=A0 He said in March 2013, "I think t= +hey're + safe enough" stored in a paper wallet.=C2=A0 Perhaps a= +ny + 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 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"><<a = +href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bit= +coin-dev@lists.linuxfounda<wbr>tion.org</a>></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'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-- + |