Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 446EC7AA for ; Wed, 12 Aug 2015 01:20:19 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D420F1B8 for ; Wed, 12 Aug 2015 01:20:18 +0000 (UTC) Received: by pabyb7 with SMTP id yb7so2393802pab.0 for ; Tue, 11 Aug 2015 18:20:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=91hHnStd8I3Pe8lyDqvo8h3WCOF3dHxObaRIifOESyI=; b=ZxpbasMso2Uhr1XbGqMMpQszJhPNydOifVMnPwFOsl4/fwghB4yJIMIeM5GZXqiq8A b6VDPMK1eyqtYqnxCtnmV/ZYU3JlkN4a11lenLjVLqboTjcbRkHGs7VXC+lVcDQWWfhr xOYvnRR00nW25Pkx1cTyv7JJBJcD4MLlnL4aGPiMBBpm4yl961o8fdaCCNzW3b+1kr89 6rw9F0myE0bcdUcKglsU1AKlUV6Wql7mC5NWtxmGnKPTL6vi6D2kQAKdAqwICJOKBaSl 3j0WebuKc5JSljc1jaAGWqqq8T2zvfORaBTMDmR8OAnz4EvJNY0MkG8hYE/HdMiJHnWB 5Z2A== X-Gm-Message-State: ALoCoQmrkR+f4vGAKexeN0iRMoQzBNb5K1lpC08c/KahejTdcarifdHPSFqrZuf1lGUAtWAhR8+e X-Received: by 10.68.218.136 with SMTP id pg8mr62347026pbc.169.1439342418595; Tue, 11 Aug 2015 18:20:18 -0700 (PDT) Received: from [10.0.1.13] (c-73-225-134-208.hsd1.wa.comcast.net. [73.225.134.208]) by smtp.googlemail.com with ESMTPSA id y2sm4195364pdp.0.2015.08.11.18.20.17 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Aug 2015 18:20:18 -0700 (PDT) Message-ID: <55CA9ED2.2060903@voskuil.org> Date: Tue, 11 Aug 2015 18:18:10 -0700 From: Eric Voskuil User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Michael Naber , Pieter Wuille References: <8181630.GdAj0CPZYc@coldstorage> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit 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: Wed, 12 Aug 2015 01:20:19 -0000 Hi Michael, > One of the key characteristics toward that is Bitcoin being > inexpensive to transact. What you seem to be missing is *why* bitcoin is better money. Have you considered why is it comparatively inexpensive to transact in a medium that is based on such a highly inefficient technology? You might want to consider that these two considerations are not independent. The reduced cost of transacting (and carrying) Bitcoin is a direct consequence of its trustless nature. Any compromise in that nature will eliminate that advantage, and therefore Bitcoin. Bitcoin is designed to solve only one problem that other systems do not. To accomplish this it makes significant compromises in other areas. The benefit of this solution is that it cannot be effectively controlled by the state. As a result, all of the associated overhead is eliminated. Hence the net cost benefit despite high technical costs. So this is a case where you should be careful what you wish for. e On 08/11/2015 02:18 PM, 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?