From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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> <554BA032.4040405@bluematt.me> <554BBDA2.7040508@gmail.com> <554CCF56.3000604@gmail.com> Date: Fri, 8 May 2015 17:17:49 +0000 X-Google-Sender-Auth: geglQvI1sbnJs5wKOH9KzYFi9II Message-ID: From: Andrew To: Alan Reiner 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 Subject: Re: [Bitcoin-development] Block Size Increase X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 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


On Fri, May 8, 2015 at 2:59 PM, Alan Reiner <etotheipi@gmail.com= > wrote:
=20 =20 =20

This isn't about "everyone's coffee".=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'll be above 100 tps.=C2=A0 And= that doesn't include all the non-individuals (organizations) that want t= o use it.

The goals of "a global transaction network" and "everyon= e must be able to run a full node with their $200 dell laptop" 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

These are good points and g= ot me thinking (but I think you'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's about 2= =20 TB per month. And if you relay it to 4 peers, it'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'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'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...

I'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'm wrong.



On 05/07/2015 03:54 PM, Jeff Garzik wrote:
On Thu, May 7, 2015 a= t 3:31 PM, Alan Reiner <etotheipi@gmail.com> wrote:
=C2=A0
(2) Leveraging fee pressure at 1MB to solve the problem is actually really a bad idea.=C2=A0 It'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 will 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't be talking about fee pressure until we hit 70= 0 tps, which is probably still too low.=C2=A0
=C2=A0[...]

1) Agree that 7 tps is too low

2) Where do you want to go?=C2=A0 Should bitcoin scale up = to handle all the world's coffees?=C2=A0

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.

3) In RE "fee pressure" -- 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'm pro-bitcoin and obviously wan= t 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-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment




--
PGP: B6AC 822C 451D 6304 6A28 =C2=A049E9 7DB7 011C D53B 5647
--047d7bdcaaa427b60505159535c5--