Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id E059488B for ; Tue, 11 Aug 2015 21:34:48 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5AA91109 for ; Tue, 11 Aug 2015 21:34:48 +0000 (UTC) Received: from mail-io0-f178.google.com ([209.85.223.178]) by mrelay.perfora.net (mreueus001) with ESMTPSA (Nemesis) id 0M8PFU-1YcPh72LdS-00vxkK for ; Tue, 11 Aug 2015 23:34:47 +0200 Received: by iodt126 with SMTP id t126so1454697iod.2 for ; Tue, 11 Aug 2015 14:34:46 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.148.8 with SMTP id w8mr35696226iod.116.1439328886915; Tue, 11 Aug 2015 14:34:46 -0700 (PDT) Received: by 10.50.104.198 with HTTP; Tue, 11 Aug 2015 14:34:46 -0700 (PDT) In-Reply-To: References: <8181630.GdAj0CPZYc@coldstorage> Date: Tue, 11 Aug 2015 22:34:46 +0100 Message-ID: From: Adam Back To: Angel Leon Content-Type: text/plain; charset=UTF-8 X-Provags-ID: V03:K0:Y0nhG1yUWYNPiNyoQf6lLCyFV31cKx5G0dB2GoAJBgD9NnBhcFM +z+3HPXR56ARTmfKudDaeIrfMQAvkdlWxrqp/St6d33JX5WAoKnqCKXq6uS5ajD4oICQoYf 09TSolMSz411tF0guvrabLy2UQ2WuWy/FfFrvFaaTQA3VXxFcWCsKTzrrmOAc/s/RZ4aJEs G65DVmJIKk9AT/4SQDQQA== X-UI-Out-Filterresults: notjunk:1;V01:K0:6HatTcH8wF4=:Q2uxbUoOn2PybWzFEhpZwk eqIVzIyOAza9USfxgZkp+K/CPUwtmxh4/2vqk5pU5DB92dMdTZMvoH8KUY2VeyQxkJ5N2Rkxp FTHjGB/gtHQ0OiRdUOkfAP/kFBdRy2DucEZsivljLy5QaJZygRM7JaeuzCYoRi9a29ILHzT1b u11YsJwTFZ+M3AtO/wQBZeUIaYuDP3OPqz6K78bXPWTbYjMnZ/sHFec4Q638afBphFBWIxHOa j+g8JN/wYDLkKlVVZRrST13c610G0NQgXBHsACZEIzcLfy3ch8Mo0oSperwV8nrxxDQkGLTYF Zfe3KaBPF7FYEzAO/ePdq4jg0BM1QokfX8vs6P2sxqUywLRGWIfI7XDN1CR6BnbzDdPnyv3n4 dPRqIOLuZlJQ3G+0D+Sm/2orzNK9MA1tlYALJeFmyyyj3yUSQMXSDHxo1/pyFDHj6hkvQQZOF t91ipxMCNAkFbwfzF14UUITdmZyzL0ST/LWrx+dQNkhbxOzhd1Ec/dGzxnWaUjGSp9VGNc9FL BUmUG0GlY904Z97ZxyBX9Y+He99sMtJOZfPcFj4zxVj6PbouD5hM6zDdjpBRyrEY4v7/wFuCX OKzzO4SQgQDGol7NXUA9IBi57YhSwoo3tsDwEfSViNPb6QNOsMm3KT3FCmiuP7jUBbSFivbXJ G0ur6hv0fBp7Q2ey1ZktcNKxSOoo31mFHBAts6efzk5jxJ13CnnV3Pb+rtNz0OR9Nw39NAKHm ceS4HORrwetK7HdX 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 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 21:34:49 -0000 So if they dont care about decentralisation, they'll be happy using cheaper off-chain systems, right? Adam On 11 August 2015 at 22:30, Angel Leon wrote: > tell that to people in poor countries, or even in first world countries. The > competitive thing here is a deal breaker for a lot of people who have no > clue/don't care for decentralization, they just want to send money from A to > B, like email. > > http://twitter.com/gubatron > > On Tue, Aug 11, 2015 at 5:23 PM, Adam Back via bitcoin-dev > wrote: >> >> I dont think Bitcoin being cheaper is the main characteristic of >> Bitcoin. I think the interesting thing is trustlessness - being able >> to transact without relying on third parties. >> >> Adam >> >> >> On 11 August 2015 at 22:18, Michael Naber via bitcoin-dev >> wrote: >> > The only reason why Bitcoin has grown the way it has, and in fact the >> > only >> > reason why we're all even here on this mailing list talking about this, >> > is >> > because Bitcoin is growing, since it's "better money than other money". >> > One >> > of the key characteristics toward that is Bitcoin being inexpensive to >> > transact. If that characteristic is no longer true, then Bitcoin isn't >> > going >> > to grow, and in fact Bitcoin itself will be replaced by better money >> > that is >> > less expensive to transfer. >> > >> > So the importance of this issue cannot be overstated -- it's compete or >> > die >> > for Bitcoin -- because people want to transact with global consensus at >> > high >> > volume, and because technology exists to service that want, then it's >> > going >> > to be met. This is basic rules of demand and supply. I don't necessarily >> > disagree with your position on only wanting to support uncontroversial >> > commits, but I think it's important to get consensus on the criticality >> > of >> > the block size issue: do you agree, disagree, or not take a side, and >> > why? >> > >> > >> > On Tue, Aug 11, 2015 at 2:51 PM, Pieter Wuille >> > wrote: >> >> >> >> On Tue, Aug 11, 2015 at 9:37 PM, Michael Naber via bitcoin-dev >> >> wrote: >> >>> >> >>> Hitting the limit in and of itself is not necessarily a bad thing. The >> >>> question at hand is whether we should constrain that limit below what >> >>> technology is capable of delivering. I'm arguing that not only we >> >>> should >> >>> not, but that we could not even if we wanted to, since competition >> >>> will >> >>> deliver capacity for global consensus whether it's in Bitcoin or in >> >>> some >> >>> other product / fork. >> >> >> >> >> >> The question is not what the technology can deliver. The question is >> >> what >> >> price we're willing to pay for that. It is not a boolean "at this size, >> >> things break, and below it, they work". A small constant factor >> >> increase >> >> will unlikely break anything in the short term, but it will come with >> >> higher >> >> centralization pressure of various forms. There is discussion about >> >> whether >> >> these centralization pressures are significant, but citing that it's >> >> artificially constrained under the limit is IMHO a misrepresentation. >> >> It is >> >> constrained to aim for a certain balance between utility and risk, and >> >> neither extreme is interesting, while possibly still "working". >> >> >> >> Consensus rules are what keeps the system together. You can't simply >> >> switch to new rules on your own, because the rest of the system will >> >> end up >> >> ignoring you. These rules are there for a reason. You and I may agree >> >> about >> >> whether the 21M limit is necessary, and disagree about whether we need >> >> a >> >> block size limit, but we should be extremely careful with change. My >> >> position as Bitcoin Core developer is that we should merge consensus >> >> changes >> >> only when they are uncontroversial. Even when you believe a more >> >> invasive >> >> change is worth it, others may disagree, and the risk from disagreement >> >> is >> >> likely larger than the effect of a small block size increase by itself: >> >> the >> >> risk that suddenly every transaction can be spent twice (once on each >> >> side >> >> of the fork), the very thing that the block chain was designed to >> >> prevent. >> >> >> >> My personal opinion is that we should aim to do a block size increase >> >> for >> >> the right reasons. I don't think fear of rising fees or unreliability >> >> should >> >> be an issue: if fees are being paid, it means someone is willing to pay >> >> them. If people are doing transactions despite being unreliable, there >> >> must >> >> be a use for them. That may mean that some use cases don't fit anymore, >> >> but >> >> that is already the case. >> >> >> >> -- >> >> Pieter >> >> >> > >> > >> > _______________________________________________ >> > bitcoin-dev mailing list >> > bitcoin-dev@lists.linuxfoundation.org >> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > >