path: root/de/9ec4d6bf0b53058510dffa9afa4c88b3d3009b

Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <akaramaoun@gmail.com>) id 1Yr3T5-000062-Vo
	for bitcoin-development@lists.sourceforge.net;
	Sat, 09 May 2015 12:02:56 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.213.181 as permitted sender)
	client-ip=209.85.213.181; envelope-from=akaramaoun@gmail.com;
	helo=mail-ig0-f181.google.com; 
Received: from mail-ig0-f181.google.com ([209.85.213.181])
	by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Yr3T3-0006C8-R8
	for bitcoin-development@lists.sourceforge.net;
	Sat, 09 May 2015 12:02:55 +0000
Received: by igbyr2 with SMTP id yr2so40140877igb.0
	for <bitcoin-development@lists.sourceforge.net>;
	Sat, 09 May 2015 05:02:48 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.50.33.51 with SMTP id o19mr3072082igi.45.1431172968438; Sat,
	09 May 2015 05:02:48 -0700 (PDT)
Sender: akaramaoun@gmail.com
Received: by 10.64.20.229 with HTTP; Sat, 9 May 2015 05:02:48 -0700 (PDT)
In-Reply-To: <CADZB0_bK+YsK8sN-di2pynvjsq5VjSvnEu0-cCGhPqFunyVm7Q@mail.gmail.com>
References: <554A91BE.6060105@bluematt.me>
	<CANEZrP3wGWHdz+ut6pvke5TJJsc1rTFt8sn2KziX35oL5LAsyg@mail.gmail.com>
	<CABm2gDpDvk2VsQ+mJ-BoeBKmvu9jBXNujZEFKuCStRNjFL6VOA@mail.gmail.com>
	<CANEZrP2zAGCCBhNa4=9yw+A_Dn5o4SQXoPTE_qcJzZ1dFuF2tw@mail.gmail.com>
	<CABm2gDqd6iHRUDKZWWTudcC1QkYa+rCuHjz7pMC2K1Db8wpgfA@mail.gmail.com>
	<CANEZrP1CU0kB0vXeXUX1L8byaT-Zf2xg+3N+GeNthi_i6bn1qw@mail.gmail.com>
	<CABsx9T2Nxvr4fqREMw3_LXftzsxrUAR1+9sVMa8_EpTnH1nN1Q@mail.gmail.com>
	<554BA032.4040405@bluematt.me>
	<CANEZrP3yM9wsSPNgpOsXDk-DjUy5PW2XuRTvK2AyCNbVJ5hZHw@mail.gmail.com>
	<CADJgMzti7ROH90APiwg4NOAT5+Av=4i295b8VN0sbSLr4+WWRw@mail.gmail.com>
	<CANEZrP39jWHLF02z-81Z4+9X1vH5+hMuS=-3ED81=Q1o9U=DKw@mail.gmail.com>
	<554BBDA2.7040508@gmail.com>
	<CAJHLa0NcxOHkrtW2=-JgfsXQJkCO8Ym7icBwMx_2RsaWcPBnTw@mail.gmail.com>
	<554CCF56.3000604@gmail.com>
	<CAL8tG=kA7V5wuRB9ob9ue4XAwGpkhh_yO_-EWDkYstV0q4PR5A@mail.gmail.com>
	<CALf2ePx-m+Of-kkWnUpVboiWxsnbTdWyT45eBAziJtbsL_P41Q@mail.gmail.com>
	<CADZB0_bK+YsK8sN-di2pynvjsq5VjSvnEu0-cCGhPqFunyVm7Q@mail.gmail.com>
Date: Sat, 9 May 2015 12:02:48 +0000
X-Google-Sender-Auth: TY3kD_VDTYEdzneqT2CGeT67gdQ
Message-ID: <CAL8tG=nu30RPgvHtz+uC+-+oi-Wf5OmSsQNYbngt4gaxsHHnyQ@mail.gmail.com>
From: Andrew <onelineproof@gmail.com>
To: Angel Leon <gubatron@gmail.com>
Content-Type: multipart/alternative; boundary=089e0158b066655fd70515a4ecbc
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(akaramaoun[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1Yr3T3-0006C8-R8
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Block Size Increase
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Sat, 09 May 2015 12:02:56 -0000

--089e0158b066655fd70515a4ecbc
Content-Type: text/plain; charset=UTF-8

The nice thing about 1 MB is that you can store ALL bitcoin transactions
relevant to your lifetime (~100 years) on one 5 TB hard drive
(1*6*24*365*100=5256000). Any regular person can run a full node and store
this 5 TB hard drive easily at their home. With 10 MB blocks you need a 50
TB drive just for your bitcoin transactions! This is not doable for most
regular people due to space and monetary constraints. Being able to review
all transactions relevant to your lifetime is one of the key important
properties of Bitcoin. How else can people audit the financial transactions
of companies and governments that are using the Bitcoin blockchain? How
else can we achieve this level of transparency that is essential to keeping
corrupt governments/companies in check? How else can we keep track of our
own personal transactions without relying on others to keep track of them
for us? As time passes, storage technology may increase, but so may human
life expectancy. So yes, in this sense, 1 MB just may be the magic number.

Assuming that we have a perfectly functional off-chain transaction system,
what do we actually gain by going from 1 MB to 1000 MB (my approximate
limit for regular users having enough processing power)? If there is no
clear and substantial gain, then it is foolish to venture into this
territory, i.e. KEEP IT AT 1 MB! For example Angel said he wants to see
computers transacting with computers at super speeds. Why do you need to do
this on the main chain? You will lose all the transparency of the current
system, an essential feature.


On Fri, May 8, 2015 at 10:36 PM, Angel Leon <gubatron@gmail.com> wrote:

> I believe 100MB is still very conservative, I think that's barely 666 tps.
>
> I also find it not very creative that people are imagining these limits
> for 10 billion people using bitcoin, I think bitcoin's potential is
> realized with computers transacting with computers, which can eat those 666
> tps in a single scoup (what if bittorrent developers got creative with
> seeding, or someone created a decentralized paid itunes on top of bitcoin,
> or the openbazaar developers actually pulled a decentralized amazon with no
> off-chain transaction since they want the thing to be fully decentralized,
> bitcoin would collapse right away)
>
> I truly hope people see past regular people running nodes at home, that's
> never going to happen. This should be about the miner's networking, storage
> and cpu capacity. They will have gigabit access, they will have shitload of
> storage, and they already have plenty of processing power, all of which are
> only going to get cheaper.
>
> In order to have the success we all dream we'll need gigabit blocks. Let's
> hope adoption remains slow.
>
> http://twitter.com/gubatron
>
> On Fri, May 8, 2015 at 1:51 PM, Alan Reiner <etotheipi@gmail.com> wrote:
>
>> Actually I believe that side chains and off-main-chain transactions will
>> be a critical part for the overall scalability of the network.  I was
>> actually trying to make the point that (insert some huge block size here)
>> will be needed to even accommodate the reduced traffic.
>>
>> I believe that it is definitely over 20MB. If it was determined to be 100
>> MB ten years from now, that wouldn't surprise me.
>>
>> Sent from my overpriced smartphone
>> On May 8, 2015 1:17 PM, "Andrew" <onelineproof@gmail.com> wrote:
>>
>>>
>>>
>>> On Fri, May 8, 2015 at 2:59 PM, Alan Reiner <etotheipi@gmail.com> wrote:
>>>
>>>>
>>>> This isn't about "everyone's coffee".  This is about an absolute
>>>> minimum amount of participation by people who wish to use the network.   If
>>>> our goal is really for bitcoin to really be a global, open transaction
>>>> network that makes money fluid, then 7tps is already a failure.  If even 5%
>>>> of the world (350M people) was using the network for 1 tx per month
>>>> (perhaps to open payment channels, or shift money between side chains),
>>>> we'll be above 100 tps.  And that doesn't include all the non-individuals
>>>> (organizations) that want to use it.
>>>>
>>>
>>>> The goals of "a global transaction network" and "everyone must be able
>>>> to run a full node with their $200 dell laptop" are not compatible.  We
>>>> need to accept that a global transaction system cannot be fully/constantly
>>>> audited by everyone and their mother.  The important feature of the network
>>>> is that it is open and anyone *can* get the history and verify it.  But not
>>>> everyone is required to.   Trying to promote a system wher000e the history
>>>> can be forever handled by a low-end PC is already falling out of reach,
>>>> even with our miniscule 7 tps.  Clinging to that goal needlessly limits the
>>>> capability for the network to scale to be a useful global payments system
>>>>
>>>
>>> These are good points and got me thinking (but I think you're wrong). If
>>> we really want each of the 10 billion people soon using bitcoin once per
>>> month, that will require 500MB blocks. That's about 2 TB per month. And if
>>> you relay it to 4 peers, it's 10 TB per month. Which I suppose is doable
>>> for a home desktop, so you can just run a pruned full node with all
>>> transactions from the past month. But how do you sync all those
>>> transactions if you've never done this before or it's been a while since
>>> you did? I think it currently takes at least 3 hours to fully sync 30 GB of
>>> transactions. So 2 TB will take 8 days, then you take a bit more time to
>>> sync the days that passed while you were syncing. So that's doable, but at
>>> a certain point, like 10 TB per month (still only 5 transactions per month
>>> per person), you will need 41 days to sync that month, so you will never
>>> catch up. So I think in order to keep the very important property of anyone
>>> being able to start clean and verify the thing, then we need to think of
>>> bitcoin as a system that does transactions for a large number of users at
>>> once in one transaction, and not a system where each person will make a
>>> ~monthly transaction on. We need to therefore rely on sidechains,
>>> treechains, lightning channels, etc...
>>>
>>> I'm not a bitcoin wizard and this is just my second post on this mailing
>>> list, so I may be missing something. So please someone, correct me if I'm
>>> wrong.
>>>
>>>>
>>>>
>>>>
>>>> On 05/07/2015 03:54 PM, Jeff Garzik wrote:
>>>>
>>>>  On Thu, May 7, 2015 at 3:31 PM, Alan Reiner <etotheipi@gmail.com>
>>>> wrote:
>>>>
>>>>
>>>>>  (2) Leveraging fee pressure at 1MB to solve the problem is actually
>>>>> really a bad idea.  It's really bad while Bitcoin is still growing, and
>>>>> relying on fee pressure at 1 MB severely impacts attractiveness and
>>>>> adoption potential of Bitcoin (due to high fees and unreliability).  But
>>>>> more importantly, it ignores the fact that for a 7 tps is pathetic for a
>>>>> global transaction system.  It is a couple orders of magnitude too low for
>>>>> any meaningful commercial activity to occur.  If we continue with a cap of
>>>>> 7 tps forever, Bitcoin *will* fail.  Or at best, it will fail to be
>>>>> useful for the vast majority of the world (which probably leads to
>>>>> failure).  We shouldn't be talking about fee pressure until we hit 700 tps,
>>>>> which is probably still too low.
>>>>>
>>>>  [...]
>>>>
>>>>  1) Agree that 7 tps is too low
>>>>
>>>>  2) Where do you want to go?  Should bitcoin scale up to handle all
>>>> the world's coffees?
>>>>
>>>>  This is hugely unrealistic.  700 tps is 100MB blocks, 14.4 GB/day --
>>>> just for a single feed.  If you include relaying to multiple nodes, plus
>>>> serving 500 million SPV clients en grosse, who has the capacity to run such
>>>> a node?  By the time we get to fee pressure, in your scenario, our network
>>>> node count is tiny and highly centralized.
>>>>
>>>>  3) In RE "fee pressure" -- Do you see the moral hazard to a
>>>> software-run system?  It is an intentional, human decision to flood the
>>>> market with supply, thereby altering the economics, forcing fees to remain
>>>> low in the hopes of achieving adoption.  I'm pro-bitcoin and obviously want
>>>> to see bitcoin adoption - but I don't want to sacrifice every decentralized
>>>> principle and become a central banker in order to get there.
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> One dashboard for servers and applications across Physical-Virtual-Cloud
>>>> Widest out-of-the-box monitoring support with 50+ applications
>>>> Performance metrics, stats and reports that give you Actionable Insights
>>>> Deep dive visibility with transaction tracing using APM Insight.
>>>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>>>> _______________________________________________
>>>> Bitcoin-development mailing list
>>>> Bitcoin-development@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>>
>>>>
>>>
>>>
>>> --
>>> PGP: B6AC 822C 451D 6304 6A28  49E9 7DB7 011C D53B 5647
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> One dashboard for servers and applications across Physical-Virtual-Cloud
>> Widest out-of-the-box monitoring support with 50+ applications
>> Performance metrics, stats and reports that give you Actionable Insights
>> Deep dive visibility with transaction tracing using APM Insight.
>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>


-- 
PGP: B6AC 822C 451D 6304 6A28  49E9 7DB7 011C D53B 5647

--089e0158b066655fd70515a4ecbc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>The nice thing about 1 MB is that you can store ALL b=
itcoin transactions relevant to your lifetime (~100 years) on one 5 TB hard=
 drive (1*6*24*365*100=3D5256000). Any regular person can run a full node a=
nd store this 5 TB hard drive easily at their home. With 10 MB blocks you n=
eed a 50 TB drive just for your bitcoin transactions! This is not doable fo=
r most regular people due to space and monetary constraints. Being able to =
review all transactions relevant to your lifetime is one of the key importa=
nt properties of Bitcoin. How else can people audit the financial transacti=
ons of companies and governments that are using the Bitcoin blockchain? How=
 else can we achieve this level of transparency that is essential to keepin=
g corrupt governments/companies in check? How else can we keep track of our=
 own personal transactions without relying on others to keep track of them =
for us? As time passes, storage technology may increase, but so may human l=
ife expectancy. So yes, in this sense, 1 MB just may be the magic number.<b=
r><br></div>Assuming that we have a perfectly functional off-chain transact=
ion system, what do we actually gain by going from 1 MB to 1000 MB (my appr=
oximate limit for regular users having enough processing power)? If there i=
s no clear and substantial gain, then it is foolish to venture into this te=
rritory, i.e. KEEP IT AT 1 MB! For example Angel said he wants to see compu=
ters transacting with computers at super speeds. Why do you need to do this=
 on the main chain? You will lose all the transparency of the current syste=
m, an essential feature.<br><div><br></div></div><div class=3D"gmail_extra"=
><br><div class=3D"gmail_quote">On Fri, May 8, 2015 at 10:36 PM, Angel Leon=
 <span dir=3D"ltr">&lt;<a href=3D"mailto:gubatron@gmail.com" target=3D"_bla=
nk">gubatron@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:1=
ex"><div dir=3D"ltr">I believe 100MB is still very conservative, I think th=
at&#39;s barely 666 tps.<div><br>I also find it not very creative that peop=
le are imagining these limits for 10 billion people using bitcoin, I think =
bitcoin&#39;s potential is realized with computers transacting with compute=
rs, which can eat those 666 tps in a single scoup (what if bittorrent devel=
opers got creative with seeding, or someone created a decentralized paid it=
unes on top of bitcoin, or the openbazaar developers actually pulled a dece=
ntralized amazon with no off-chain transaction since they want the thing to=
 be fully decentralized, bitcoin would collapse right away)<br><br>I truly =
hope people see past regular people running nodes at home, that&#39;s never=
 going to happen. This should be about the miner&#39;s networking, storage =
and cpu capacity. They will have gigabit access, they will have shitload of=
 storage, and they already have plenty of processing power, all of which ar=
e only going to get cheaper.<br><br>In order to have the success we all dre=
am we&#39;ll need gigabit blocks. Let&#39;s hope adoption remains slow.</di=
v></div><div class=3D"gmail_extra"><br clear=3D"all"><div><div><a href=3D"h=
ttp://twitter.com/gubatron" target=3D"_blank">http://twitter.com/gubatron</=
a><br></div></div><div><div class=3D"h5">
<br><div class=3D"gmail_quote">On Fri, May 8, 2015 at 1:51 PM, Alan Reiner =
<span dir=3D"ltr">&lt;<a href=3D"mailto:etotheipi@gmail.com" target=3D"_bla=
nk">etotheipi@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"><p dir=3D"ltr">Actually I believe that side chains and off-main-chain =
transactions will be a critical part for the overall scalability of the net=
work.=C2=A0 I was actually trying to make the point that (insert some huge =
block size here) will be needed to even accommodate the reduced traffic.=C2=
=A0 </p>
<p dir=3D"ltr">I believe that it is definitely over 20MB. If it was determi=
ned to be 100 MB ten years from now, that wouldn&#39;t surprise me.</p>
<p dir=3D"ltr">Sent from my overpriced smartphone</p><div><div>
<div class=3D"gmail_quote">On May 8, 2015 1:17 PM, &quot;Andrew&quot; &lt;<=
a href=3D"mailto:onelineproof@gmail.com" target=3D"_blank">onelineproof@gma=
il.com</a>&gt; wrote:<br type=3D"attribution"><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_q=
uote">On Fri, May 8, 2015 at 2:59 PM, Alan Reiner <span dir=3D"ltr">&lt;<a =
href=3D"mailto:etotheipi@gmail.com" target=3D"_blank">etotheipi@gmail.com</=
a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
 =20
   =20
 =20
  <div>
    <br>
    This isn&#39;t about &quot;everyone&#39;s coffee&quot;.=C2=A0 This is a=
bout an absolute
    minimum amount of participation by people who wish to use the
    network.=C2=A0=C2=A0 If our goal is really for bitcoin to really be a g=
lobal,
    open transaction network that makes money fluid, then 7tps is
    already a failure.=C2=A0 If even 5% of the world (350M people) was usin=
g
    the network for 1 tx per month (perhaps to open payment channels, or
    shift money between side chains), we&#39;ll be above 100 tps.=C2=A0 And=
 that
    doesn&#39;t include all the non-individuals (organizations) that want t=
o
    use it. <br></div></blockquote><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><div bgcolor=3D"#FFFFFF" text=3D"#000000">
    <br>
    The goals of &quot;a global transaction network&quot; and &quot;everyon=
e must be
    able to run a full node with their $200 dell laptop&quot; are not
    compatible.=C2=A0 We need to accept that a global transaction system
    cannot be fully/constantly audited by everyone and their mother.=C2=A0
    The important feature of the network is that it is open and anyone
    *can* get the history and verify it.=C2=A0 But not everyone is required
    to.=C2=A0=C2=A0 Trying to promote a system wher000e the history can be =
forever
    handled by a low-end PC is already falling out of reach, even with
    our miniscule 7 tps.=C2=A0 Clinging to that goal needlessly limits the
    capability for the network to scale to be a useful global payments
    system <br></div></blockquote><div><br><div>These are good points and g=
ot me thinking (but I think you&#39;re=20
wrong). If we really want each of the 10 billion people soon using=20
bitcoin once per month, that will require 500MB blocks. That&#39;s about 2=
=20
TB per month. And if you relay it to 4 peers, it&#39;s 10 TB per month.=20
Which I suppose is doable for a home desktop, so you can just run a=20
pruned full node with all transactions from the past month. But how do=20
you sync all those transactions if you&#39;ve never done this before or it&=
#39;s
 been a while since you did? I think it currently takes at least 3 hours
 to fully sync 30 GB of transactions. So 2 TB will take 8 days, then you
 take a bit more time to sync the days that passed while you were=20
syncing. So that&#39;s doable, but at a certain point, like 10 TB per month=
=20
(still only 5 transactions per month per person), you will need 41 days=20
to sync that month, so you will never catch up. So I think in order to=20
keep the very important property of anyone being able to start clean and
 verify the thing, then we need to think of bitcoin as a system that=20
does transactions for a large number of users at once in one=20
transaction, and not a system where each person will make a ~monthly=20
transaction on. We need to therefore rely on sidechains, treechains,=20
lightning channels, etc...<br><br></div>I&#39;m not a bitcoin wizard=20
and this is just my second post on this mailing list, so I may be=20
missing something. So please someone, correct me if I&#39;m wrong. <br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor=3D"#FFFFFF=
" text=3D"#000000">
    <br>
    <br>
    <br>
    <div>On 05/07/2015 03:54 PM, Jeff Garzik
      wrote:<br>
    </div>
    <blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div class=3D"gmail_extra">
          <div class=3D"gmail_quote"><span>On Thu, May 7, 2015 at 3:31 PM, =
Alan
            Reiner <span dir=3D"ltr">&lt;<a href=3D"mailto:etotheipi@gmail.=
com" target=3D"_blank">etotheipi@gmail.com</a>&gt;</span>
            wrote:<br>
            <div>=C2=A0</div>
            <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
              <div bgcolor=3D"#FFFFFF" text=3D"#000000"> (2) Leveraging fee
                pressure at 1MB to solve the problem is actually really
                a bad idea.=C2=A0 It&#39;s really bad while Bitcoin is stil=
l
                growing, and relying on fee pressure at 1 MB severely
                impacts attractiveness and adoption potential of Bitcoin
                (due to high fees and unreliability).=C2=A0 But more
                importantly, it ignores the fact that for a 7 tps is
                pathetic for a global transaction system.=C2=A0 It is a
                couple orders of magnitude too low for any meaningful
                commercial activity to occur.=C2=A0 If we continue with a c=
ap
                of 7 tps forever, Bitcoin <b>will</b> fail.=C2=A0 Or at
                best, it will fail to be useful for the vast majority of
                the world (which probably leads to failure).=C2=A0 We
                shouldn&#39;t be talking about fee pressure until we hit 70=
0
                tps, which is probably still too low.=C2=A0 <br>
              </div>
            </blockquote>
            </span><div>=C2=A0[...]<br>
              <br>
            </div>
            <div>1) Agree that 7 tps is too low<br>
              <br>
            </div>
            <div>2) Where do you want to go?=C2=A0 Should bitcoin scale up =
to
              handle all the world&#39;s coffees?=C2=A0 <br>
            </div>
            <div><br>
            </div>
            <div>This is hugely unrealistic.=C2=A0 700 tps is 100MB blocks,
              14.4 GB/day -- just for a single feed.=C2=A0 If you include
              relaying to multiple nodes, plus serving 500 million SPV
              clients en grosse, who has the capacity to run such a
              node?=C2=A0 By the time we get to fee pressure, in your
              scenario, our network node count is tiny and highly
              centralized.<br>
              <br>
            </div>
            3) In RE &quot;fee pressure&quot; -- Do you see the moral hazar=
d to a
            software-run system?=C2=A0 It is an intentional, human decision
            to flood the market with supply, thereby altering the
            economics, forcing fees to remain low in the hopes of
            achieving adoption.=C2=A0 I&#39;m pro-bitcoin and obviously wan=
t to
            see bitcoin adoption - but I don&#39;t want to sacrifice every
            decentralized principle and become a central banker in order
            to get there.<br>
          </div>
          <br>
        </div>
      </div>
    </blockquote>
    <br>
  </div>

<br>-----------------------------------------------------------------------=
-------<br>
One dashboard for servers and applications across Physical-Virtual-Cloud<br=
>
Widest out-of-the-box monitoring support with 50+ applications<br>
Performance metrics, stats and reports that give you Actionable Insights<br=
>
Deep dive visibility with transaction tracing using APM Insight.<br>
<a href=3D"http://ad.doubleclick.net/ddm/clk/290420510;117567292;y" target=
=3D"_blank">http://ad.doubleclick.net/ddm/clk/290420510;117567292;y</a><br>=
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla=
nk">Bitcoin-development@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div><br><br clear=3D"all"><br>-- <br><div>PGP: B6AC 822C=
 451D 6304 6A28 =C2=A049E9 7DB7 011C D53B 5647</div>
</div></div>
</blockquote></div>
</div></div><br>-----------------------------------------------------------=
-------------------<br>
One dashboard for servers and applications across Physical-Virtual-Cloud<br=
>
Widest out-of-the-box monitoring support with 50+ applications<br>
Performance metrics, stats and reports that give you Actionable Insights<br=
>
Deep dive visibility with transaction tracing using APM Insight.<br>
<a href=3D"http://ad.doubleclick.net/ddm/clk/290420510;117567292;y" target=
=3D"_blank">http://ad.doubleclick.net/ddm/clk/290420510;117567292;y</a><br>=
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla=
nk">Bitcoin-development@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div><br></div></div></div>
</blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"gmail_sig=
nature">PGP: B6AC 822C 451D 6304 6A28 =C2=A049E9 7DB7 011C D53B 5647</div>
</div>

--089e0158b066655fd70515a4ecbc--