Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 6A0CE905 for ; Fri, 31 Mar 2017 02:01:51 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-vk0-f45.google.com (mail-vk0-f45.google.com [209.85.213.45]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D5CCC20F for ; Fri, 31 Mar 2017 02:01:50 +0000 (UTC) Received: by mail-vk0-f45.google.com with SMTP id d188so75411227vka.0 for ; Thu, 30 Mar 2017 19:01:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fB0wB61hwOsMaQZXSc2aKYnaer7hIXOgEAxdof23MHc=; b=KZwD68Wv9rJTnkJqfTgtL97RvHLWoV5jjCzpVKoTYyn6mIO++Z6RzgbCSpSaC2WwBu vY8NnWgbapPRSgxAm99zZYaa7vBj4KIOmFtdQGQJdiKLW5DzFSz0FFFgs3WX/TyDCejX Q4mwjfK5iounYRmjMJn9gi22FonSx1MfB+rOHE2uDQfZ0gnL6HpCeSmW1Q1iKp5QliDS HzTbizfGRDa9VzkXz3/ScN9ABusqQk9PBaOZP/RPjTqLHmjuOYzyw+Re59sKNiHqXpcC iwU2PsfYLQ8mW8N6m1q7mgvAhZtXrNuc7Hv9lI8lMrXdeBo1CFFaPP2q5IgfvzrC9D/3 AHNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fB0wB61hwOsMaQZXSc2aKYnaer7hIXOgEAxdof23MHc=; b=tx9AvHDbRyBipig166vG9MdkZ1ZBIIvvJYnr/hKgRRjlKYFYF+8ORRuYF66pOb9EIy +tzOCxvzSHN1ZXMSb9CzvO/nuFIPMog0C4S90sA5MTFJk2z0lGyS1M0Nt8m9ssai7IXD p66qfrXWfpYFNfe0ZVUb/nGOkl2DVDzneJ/6GJIeSwj46QhTWKTUx8eDkgC3iIWCwViR GMgJYpSyNGYcX6odV20Jhp6aRAYmqH2qZ41Y0isEeEWZIHRCYFrNB02HIQk8DFcTisfm AR/ghlFRjFa6hpUydkZepB1+6g45OJB4SsoWJfLu3+vQTqjYZSQOM0uaZKfOPHdP/Ds/ u0Xg== X-Gm-Message-State: AFeK/H1koKzTqaXuZXWRFqQEty6WOe1RZbKcMt0ngg2LuUHqwll+9YArlzJunZHiq1zUgc5INcHMmUUBkWHPaw== X-Received: by 10.31.218.195 with SMTP id r186mr231252vkg.112.1490925709965; Thu, 30 Mar 2017 19:01:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.157.143 with HTTP; Thu, 30 Mar 2017 19:01:49 -0700 (PDT) In-Reply-To: <61B9AE0D-5A58-4A72-8834-8ED164ED627F@gmail.com> References: <61B9AE0D-5A58-4A72-8834-8ED164ED627F@gmail.com> From: Jared Lee Richardson Date: Thu, 30 Mar 2017 19:01:49 -0700 Message-ID: To: Vladimir Zaytsev Content-Type: multipart/alternative; boundary=94eb2c07adbc543f2a054bfd3105 X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Fri, 31 Mar 2017 02:31:10 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] High fees / centralization X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 02:01:51 -0000 --94eb2c07adbc543f2a054bfd3105 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable That would be blockchain sharding. Would be amazing if someone could figure out how to do it trustlessly. So far I'm not convinced it is possible to resolve the conflicts between the shards and commit transactions between shards. On Thu, Mar 30, 2017 at 6:39 PM, Vladimir Zaytsev < vladimir.zaytsev@gmail.com> wrote: > There must be a way to organize =E2=80=9Cbranches=E2=80=9D of smaller act= ivity to join > main tree after they grow. Outsider a bit, I see going circles here, but > not everything must be accepted in the chain. Good idea as it is, it=E2= =80=99s just > too early to record every sight=E2=80=A6. > > > > On Mar 30, 2017, at 5:52 PM, Jared Lee Richardson via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > > Further, we are very far from the point (in my appraisal) where fees > are high enough to block home users from using the network. > > This depends entirely on the usecase entirely. Most likely even without = a > blocksize increase, home purchases will be large enough to fit on the > blocksize in the forseeable future. Microtransactions(<$0.25) on the oth= er > hand aren't viable no matter what we try to do - There's just too much da= ta. > > Most likely, transaction fees above $1 per tx will become unappealing for > many consumers, and above $10 is likely to be niche-level. It is hard to > say with any certainty, but average credit card fees give us some > indications to work with - $1.2 on a $30 transaction, though paid by the > business and not the consumer. > > Without blocksize increases, fees higher than $1/tx are basically > inevitable, most likely before 2020. Running a node only costs $10/month > if that. If we were going to favor node operational costs that highly in > the weighting, we'd better have a pretty solid justification with > mathematical models or examples. > > > We should not throw away the core innovation of monetary sovereignty in > pursuit of supporting 0.1% of the world's daily transactions. > > If we can easily have both, why not have both? > > An altcoin with both will take Bitcoin's monetary sovereignty crown by > default. No crown, no usecases, no Bitcoin. > > > > --94eb2c07adbc543f2a054bfd3105 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
That would be blockchain sharding.

Would be amazing= if someone could figure out how to do it trustlessly.=C2=A0 So far I'm= not convinced it is possible to resolve the conflicts between the shards a= nd commit transactions between shards.

=
On Thu, Mar 30, 2017 at 6:39 PM, Vladimir Zaytse= v <vladimir.zaytsev@gmail.com> wrote:
There must be= a way to organize =E2=80=9Cbranches=E2=80=9D of smaller activity to join m= ain tree after they grow. Outsider a bit, I see going circles here, but not= everything must be accepted in the chain. Good idea as it is, it=E2=80=99s= just too early to record every sight=E2=80=A6.
=


On Mar 30,= 2017, at 5:52 PM, Jared Lee Richardson via bitcoin-dev <bitcoin-dev@lis= ts.linuxfoundation.org> wrote:

>=C2=A0Further, we are very far from the point (in my appr= aisal) where fees are high enough to block home users from using the networ= k.

This depends entirely on the usecase entirely.=C2=A0 Most= likely even without a blocksize increase, home purchases will be large eno= ugh to fit on the blocksize in the forseeable future.=C2=A0 Microtransactio= ns(<$0.25) on the other hand aren't viable no matter what we try to = do - There's just too much data.

Most likely, transaction fees above $1 per t= x will become unappealing for many consumers, and above $10 is likely to be= niche-level.=C2=A0 It is hard to say with any certainty, but average credi= t card fees give us some indications to work with - $1.2 on a $30 transacti= on, though paid by the business and not the consumer.

Without blocks= ize increases, fees higher than $1/tx are basically inevitable, most likely= before 2020.=C2=A0 Running a node only costs $10/month if that.=C2=A0 If w= e were going to favor node operational costs that highly in the weighting, = we'd better have a pretty solid justification with mathematical models = or examples.

>=C2=A0We should not throw away the core innovation of monetary s= overeignty in pursuit of supporting 0.1% of the world's daily transacti= ons.

If we can easily have both, why not have both?

An= altcoin with both will take Bitcoin's monetary sovereignty crown by de= fault.=C2=A0 No crown, no usecases, no Bitcoin.




--94eb2c07adbc543f2a054bfd3105--