From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 612A242A for ; Thu, 23 Jul 2015 23:42:45 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3D82C1CE for ; Thu, 23 Jul 2015 23:42:43 +0000 (UTC) Received: by wibud3 with SMTP id ud3so44449163wib.1 for ; Thu, 23 Jul 2015 16:42:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=w7rgPlJdvfpRMuKlW+7Q0p3jrvLMkJjejeR2FDEkcSU=; b=aq/dDo/BDvFHVs643UFEMpTicGjncy8J77kmvyEvOVNIdWuhULyKXoGzX3E+0sj2Sj /b5eVi4svhQXL4AxTLo3RYSVUFOYYoG8YNInpP2WKjgzR6H9MJEd3XyHN7Iv/9njF+zA UCT0esrPpJIATo3j3xjZqup5+dq18s/22iAJW0ACw4KrWYjdEU6LW1PEdkjENhsZ2MPR gVFWVha48on6T9CzxH9xL9ZMxlS3Q+yLNm8DjfsQemsdxJyJ2yMLILwblDfVFJrmkmXk Z+Jdh+35sx/Ig1FsQQAxSeMcATDpR+G7pg8J0ytyF0NOp/yZNJv4qQLC44X/vNCj7IHX fDCg== X-Gm-Message-State: ALoCoQnCvRu0ACfynQbKItYOuAanVYmEIkVwF4HN+554mxKLwmpYHEFjhUrayF3NqUWGJ5ZlnE9m MIME-Version: 1.0 X-Received: by 10.180.84.230 with SMTP id c6mr1430465wiz.32.1437694962798; Thu, 23 Jul 2015 16:42:42 -0700 (PDT) Received: by 10.194.136.209 with HTTP; Thu, 23 Jul 2015 16:42:42 -0700 (PDT) In-Reply-To: References: <55B113AF.40500@thinlink.com> <6F436293-9E2B-461C-B105-FC4CF9EBFC69@gmail.com> Date: Thu, 23 Jul 2015 16:42:42 -0700 Message-ID: From: Benedict Chan To: Eric Lombrozo Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: bitcoin-dev@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] Bitcoin Core and hard forks X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 23:42:45 -0000 On Thu, Jul 23, 2015 at 1:52 PM, Eric Lombrozo via bitcoin-dev wrote: > On Thu, Jul 23, 2015 at 3:14 PM, Eric Lombrozo wrot= e: >> >> Mainstream usage of cryptocurrency will be enabled primarily by direct >> party-to-party contract negotiation=E2=80=A6with the use of the blockcha= in primarily >> as a dispute resolution mechanism. The block size isn=E2=80=99t about sc= aling but >> about supply and demand of finite resources. As demand for block space >> increases, we can address it either by increasing computational resource= s >> (block size) or by increasing fees. But to do the former we need a way t= o >> offset the increase in cost by making sure that those who contribute sai= d >> resources have incentive to do so.=E2=80=99 > > > I should also point out, improvements in hardware and network infrastruct= ure > can also reduce costs=E2=80=A6and we could very well have a model where r= esource > requirements can be increased as technology improves. However, currently, > the computational cost of validation is clearly growing far more quickly > than the cost of computational resources is going down. There are > 7,000,000,000 people in the world. Payment networks in the developed worl= d > already regularly handle thousands of transactions a second. Even with > highly optimized block propagation, pruning, and signature validation, we= =E2=80=99re > still many orders shy of being able to satisfy demand. To achieve mainstr= eam > adoption, we=E2=80=99ll have to pass through a period of quasi-exponentia= l growth in > userbase (until the market saturates=E2=80=A6or until the network resourc= es run > out). Unless we=E2=80=99re able to achieve a validation complexity of O(p= olylog n) > or better, it=E2=80=99s not a matter of having a negative attitude about = the > prospects=E2=80=A6it=E2=80=99s just math. Whether we have 2MB or 20MB or = 100MB blocks (even > assuming the above mentioned optimizations and that the computational > resources exist and are willing to handle it) we will not be able to sati= sfy > demand if we insist on requiring global validation for all transactions. > Scaling the network will come in the form of a combination of many optimizations. Just because we do not know for sure how to eventually serve 7 billion people does not mean we should make decisions on global validation that impact our ability to serve the current set of users. Also, blocking a change because it's "more important to address issues such as..." other improvements will further slow down the discussion. I believe an increase will not prevent the development of other improvements that we need - in contrast, the sooner we can get over the limit (which, as you agree, needs to be changed at some point), the sooner we can get back to work. > > On Jul 23, 2015, at 1:26 PM, Jorge Tim=C3=B3n wrote: > > On Thu, Jul 23, 2015 at 9:52 PM, Jameson Lopp via bitcoin-dev > wrote: > > Running a node certainly has real-world costs that shouldn't be ignored. > There are plenty of advocates who argue that Bitcoin should strive to kee= p > it feasible for the average user to run their own node (as opposed to > Satoshi's vision of beefy servers in data centers.) My impression is that > even most of these advocates agree that it will be acceptable to eventual= ly > increase block sizes as resources become faster and cheaper because it wo= n't > be 'pricing out' the average user from running their own node. If this is > the case, it seems to me that we have a problem given that there is no > established baseline for the acceptable performance / hardware cost > requirements to run a node. I'd really like to see further clarification > from these advocates around the acceptable cost of running a node and how= we > can measure the global reduction in hardware and bandwidth costs in order= to > establish a baseline that we can use to justify additional resource usage= by > nodes. > > > Although I don't have a concrete proposals myself, I agree that > without having any common notion of what the "minimal target hardware" > looks like, it is very difficult to discuss other things that depend > on that. > If there's data that shows that a 100 usd raspberry pi with a 1 MB > connection in say, India (I actually have no idea about internet > speeds there) size X is a viable full node, then I don't think anybody > can reasonably oppose to rising the block size to X, and such a > hardfork can perfectly be uncontroversial. > I'm exaggerating ultra-low specifications, but it's just an example to > illustrate your point. > There was a thread about formalizing such "minimum hardware > requirements", but I think the discussion simply finished there: > - Let's do this > - Yeah, let's do it > - +1, let's have concrete values, I generally agree. > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >