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 95CBF7E for ; Tue, 11 Aug 2015 11:19:21 +0000 (UTC) X-Greylist: delayed 00:06:39 by SQLgrey-1.7.6 Received: from mta03.svc.cra.dublin.eircom.net (mta03.svc.cra.dublin.eircom.net [159.134.118.145]) by smtp1.linuxfoundation.org (Postfix) with SMTP id C2BF41D0 for ; Tue, 11 Aug 2015 11:19:20 +0000 (UTC) Received: (qmail 6121 messnum 17190849 invoked from network[213.94.190.14/avas02.vendorsvc.cra.dublin.eircom.net]); 11 Aug 2015 11:12:40 -0000 Received: from avas02.vendorsvc.cra.dublin.eircom.net (213.94.190.14) by mta03.svc.cra.dublin.eircom.net (qp 6121) with SMTP; 11 Aug 2015 11:12:40 -0000 Received: from coldstorage.localnet ([83.71.193.244]) by avas02.vendorsvc.cra.dublin.eircom.net with Cloudmark Gateway id 3PCW1r00t5Gqgwr01PCfMD; Tue, 11 Aug 2015 12:12:39 +0100 From: Thomas Zander To: Bitcoin Dev Date: Tue, 11 Aug 2015 13:10:48 +0200 Message-ID: <1681438.F7ZY8xlbAj@coldstorage> User-Agent: KMail/4.14.1 (Linux/3.16.0-4-amd64; KDE/4.14.2; x86_64; ; ) In-Reply-To: References: <1623892.Xps1bl6nlD@coldstorage> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 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] Fees and the block-finding process 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: Tue, 11 Aug 2015 11:19:21 -0000 On Tuesday 11. August 2015 00.08.42 Mark Friedenbach wrote: > On Mon, Aug 10, 2015 at 11:31 PM, Thomas Zander via bitcoin-dev < > So why do I work on Bitcoin, [] It can't > be censored, it can't be shut down, and the rules cannot change from > underneath you. Fully agreed, and I like that a lot as well. > It may hopefully never be necessary to operate under such constraints, > except by freedom seeking individuals within existing totalitarian regimes. I think remembering the Internet architecture here is viable. There is a saying that censorship on the internet is seen as a defect and route around. Bitcoin follows the same concept, and arguable is even better at it since transactions don't have to be delivered to the network in real time. It can be shipped by carrier pigeon in the extreme case ;) Or though smileys over skype chat... > However the credible threat of doing so may be what keeps Bitcoin from > being repressed in the first place. Lose the capability to go underground, > and it will be pressured into regulation, eventually. I understand your point, its a good one. Here is my counter argument; countries (or states) that fail to legally get the bandwidth to do mining, are not an indicator for the success of Bitcoin. Tor will work fine with a full node (or gnunet, if you want), just make sure you take the transmission delays into account. And naturally, there is the point that actual end users don't need a full node. The system as a whole will work just fine for people in totalitarian regimes as long as 100% of the world doesn't reach that point. With various nodes in Sealand (near the UK) and miners in China, the system would still work for users in New York. > > Remember 8Gb/block still doesn't support VISA/Mastercard. > > No, it doesn't. And 8GB/block is ludicrously large -- it would absolutely, > without any doubt destroy the very nature of Bitcoin, turning it into a > fundamentally uninteresting reincarnation of the existing financial system. > And still be unable to compete with VISA/Mastercard. > > So why then the pressure to go down a route that WILL lead to failure by > your own metrics? Naturally, I was referring to the existing proposal that 8Gb blocks would be reached only in many years. Its a really long way away. And if you read my previous replies on this thread you can see a more substantial argument which I'll make brief here; I'm not suggesting we scale the blocksize to accomodate for the next 10 years of growth. Instead I'm suggesting that we use solutions like Lightning and sidechains and anything people can invent as soon as possible. But we need bigger blocks as well. Because not any single solution is the answer, we need a combination of multiple. There really is no reason to suspect we can't actually increase the blocksize in some months as the first thing we do. -- Thomas Zander