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 C39F3B5A for ; Sun, 5 Jul 2015 19:55:49 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-la0-f52.google.com (mail-la0-f52.google.com [209.85.215.52]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0CCBA1C8 for ; Sun, 5 Jul 2015 19:55:49 +0000 (UTC) Received: by lagx9 with SMTP id x9so132334523lag.1 for ; Sun, 05 Jul 2015 12:55:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=zPixkD4eWykL13ew7nBxLtmcs+2oL8aa4jBVuwcjtYM=; b=nWNWBptGdl5A8fmSDPoPhVhwQneYQqa9Aepdm4XAAesSVNFmMvZj+MFQuAGCKyCBqI tKkKqm0JWaCt+3y1UYa7ONz44Z2h1Nhdq6sxq+dSfvHLCjAjz/SciqgJTuM+ZVulbON7 NGCHKXSHhlpZXCiNYN3anKI+LcrDfLxcdaxOSC1sKhOEkCr5K7PJbVkiiOGiIXgle/2P t4AsyaqhOMAHNGZc7i/Aa9dM/easGn45c53HBqGFWpv+OLasSYzyLu3UK0s2PhUpzwyj NwWFeTCOwz/X3nzW49li3hDDrlrZ2wG5lUMURRHhcZ+7ZlERAFktzbWhAiU7k8WjNw4R OYew== MIME-Version: 1.0 X-Received: by 10.152.28.194 with SMTP id d2mr46445839lah.122.1436126147436; Sun, 05 Jul 2015 12:55:47 -0700 (PDT) Received: by 10.112.53.5 with HTTP; Sun, 5 Jul 2015 12:55:47 -0700 (PDT) Received: by 10.112.53.5 with HTTP; Sun, 5 Jul 2015 12:55:47 -0700 (PDT) In-Reply-To: References: Date: Sun, 5 Jul 2015 12:55:47 -0700 Message-ID: From: Eric Lombrozo To: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary=089e0160b420dee7a1051a262cc0 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,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 Subject: Re: [bitcoin-dev] Thoughts on Forks, Scalability, and other Bitcoin inconveniences. 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: Sun, 05 Jul 2015 19:55:49 -0000 --089e0160b420dee7a1051a262cc0 Content-Type: text/plain; charset=UTF-8 I should clarify that by "most use cases" I'm not envisioning a bunch of cryptogeeks [us, or at least myself and a few of us] happily buying up hard disks, waiting hours, days, weeks to spawn up new full nodes. I'm envisioning a world where every person has access to this technology and finds it practical, convenient, and safe ti use. - Eric Lombrozo On Jul 5, 2015 11:50 AM, "Eric Lombrozo" wrote: > Blockchain validation has become too expensive to properly secure the > network as per our original security model. The level of validation > required to comply with our security model has become completely > impractical for most use cases. Block space is still cheap only because of > block reward subsidy (which decreases exponentially with time). The > economics are already completely jacked - larger blocks will only worsen > this disparity. > > The only practical way for the network to function at present (and what > has essentially ended up happening, if often tacitly) is by introducing > trust, in validators, miners, relayers, explorer websites, online wallets, > etc...which in and of itself wouldn't be the end of the world were it not > for the fact that the raison d'etre of bitcoin is trustlessness - and the > security model is very much based on this idea. Because of this, there's > been a tendency to deny that bitcoin cannot presently scale without trust. > This is horrible because our entire security model has gone out the > window...and has been replaced with something that isn't specified at all! > > We don't really know the boundaries of our model, as the fork a couple of > days ago demonstrated. Right now we're basically trusting a few devs and > some mining pool operators that until now have been willing to cooperate > for the benefit of the network. It is dangerous to assume this will > continue perpetually. Even assuming the best intentions, an incident might > occur that this cooperation cannot easily repair. > > We need to either solve the validation cost/bottleneck issue...or we need > to construct a new security model that takes these trust assumptions into > account. > > - Eric Lombrozo > --089e0160b420dee7a1051a262cc0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I should clarify that by "most use cases" I'm = not envisioning a bunch of cryptogeeks [us, or at least myself and a few of= us] happily buying up hard disks, waiting hours, days, weeks to spawn up n= ew full nodes. I'm envisioning a world where every person has access to= this technology and finds it practical, convenient, and safe ti use.

- Eric Lombrozo

On Jul 5, 2015 11:50 AM, "Eric Lombrozo&quo= t; <elombrozo@gmail.com> w= rote:

Blockchain validation has become too expensive to properly secure the netw= ork as per our original security model. The level of validation required to= comply with our security model has become completely impractical for most = use cases. Block space is still cheap only because of block reward subsidy = (which decreases exponentially with time). The economics are already comple= tely jacked - larger blocks will only worsen this disparity.

The only practical way for the network to function at presen= t (and what has essentially ended up happening, if often tacitly) is by int= roducing trust, in validators, miners, relayers, explorer websites, online = wallets, etc...which in and of itself wouldn't be the end of the world = were it not for the fact that the raison d'etre of bitcoin is trustless= ness - and the security model is very much based on this idea. Because of t= his, there's been a tendency to deny that bitcoin cannot presently scal= e without trust. This is horrible because our entire security model has gon= e out the window...and has been replaced with something that isn't spec= ified at all!

We don't really know the boundaries of our model, as the= fork a couple of days ago demonstrated. Right now we're basically trus= ting a few devs and some mining pool operators that until now have been wil= ling to cooperate for the benefit of the network. It is dangerous to assume= this will continue perpetually. Even assuming the best intentions, an inci= dent might occur that this cooperation cannot easily repair.

We need to either solve the validation cost/bottleneck issue= ...or we need to construct a new security model that takes these trust assu= mptions into account.

- Eric Lombrozo

--089e0160b420dee7a1051a262cc0--