path: root/a3/3e8ec52885e3fd88a8ac6df9ac4a041d429399

Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <akaramaoun@gmail.com>) id 1YqluO-0001M7-AN
	for bitcoin-development@lists.sourceforge.net;
	Fri, 08 May 2015 17:17:56 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.213.173 as permitted sender)
	client-ip=209.85.213.173; envelope-from=akaramaoun@gmail.com;
	helo=mail-ig0-f173.google.com; 
Received: from mail-ig0-f173.google.com ([209.85.213.173])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1YqluM-00021B-Uo
	for bitcoin-development@lists.sourceforge.net;
	Fri, 08 May 2015 17:17:56 +0000
Received: by igbsb11 with SMTP id sb11so26973324igb.0
	for <bitcoin-development@lists.sourceforge.net>;
	Fri, 08 May 2015 10:17:49 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.50.77.48 with SMTP id p16mr5877789igw.31.1431105469656; Fri,
	08 May 2015 10:17:49 -0700 (PDT)
Sender: akaramaoun@gmail.com
Received: by 10.64.20.229 with HTTP; Fri, 8 May 2015 10:17:49 -0700 (PDT)
In-Reply-To: <554CCF56.3000604@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>
Date: Fri, 8 May 2015 17:17:49 +0000
X-Google-Sender-Auth: geglQvI1sbnJs5wKOH9KzYFi9II
Message-ID: <CAL8tG=kA7V5wuRB9ob9ue4XAwGpkhh_yO_-EWDkYstV0q4PR5A@mail.gmail.com>
From: Andrew <onelineproof@gmail.com>
To: Alan Reiner <etotheipi@gmail.com>
Content-Type: multipart/alternative; boundary=047d7bdcaaa427b60505159535c5
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: 1YqluM-00021B-Uo
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: Fri, 08 May 2015 17:17:56 -0000

--047d7bdcaaa427b60505159535c5
Content-Type: text/plain; charset=UTF-8

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

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Fri, May 8, 2015 at 2:59 PM, Alan Reiner <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:etotheipi@gmail.com" target=3D"_blank">etotheipi@gmail.com</a>=
&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px=
 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 class=3D"">On Thu, May 7, 2015 a=
t 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">Bitcoin-develo=
pment@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 class=3D"gmail=
_signature">PGP: B6AC 822C 451D 6304 6A28 =C2=A049E9 7DB7 011C D53B 5647</d=
iv>
</div></div>

--047d7bdcaaa427b60505159535c5--