Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id A6EF37AA for ; Wed, 12 Aug 2015 06:10:45 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail.bihthai.net (unknown [5.255.87.165]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 97F6D155 for ; Wed, 12 Aug 2015 06:10:44 +0000 (UTC) Received: from [10.8.0.6] (unknown [10.8.0.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: venzen) by mail.bihthai.net (Postfix) with ESMTPSA id A052B2115B; Wed, 12 Aug 2015 08:12:41 +0200 (CEST) Message-ID: <55CAE35A.10100@mail.bihthai.net> Date: Wed, 12 Aug 2015 13:10:34 +0700 From: Venzen Khaosan Reply-To: venzen@mail.bihthai.net Organization: Bihthai Bai Mai User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Michael Naber , Bitcoin Dev References: <8181630.GdAj0CPZYc@coldstorage> In-Reply-To: OpenPGP: id=1CF07D66; url=pool.sks-keyservers.net Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no 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: Wed, 12 Aug 2015 06:10:45 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Your concern for adoption is valid yet there are a few assumptions in your discussion and they are a common thread in the current wave of "bigger blocksize" topics. 1) Supplying bigger blocks will meet the demand of more people: Anyone can transact via Bitcoin. By increasing blocksize and making more transactions possible at low fees, what's to stop a large corporation, bank or government from using the protocol as a cheap settlement mechanism. They don't have to fund or develop their own (well, Ecuador has, for this exact use-case) and perhaps the utility and capacity of the Bitcoin network means reliability and low fees (cheaper than a bank clearance, say) for their use-case. In the process they hog xMB of space in each block and discussion about a capacity limit continues in this list. Increased supply *will* be utilized - by all kinds of entities - not only the girl next-door and the unbanked proletariat. 2) Dissatisfied users will move to alt-coins so Bitcoin better be careful... The assumption here is that the best skills and most able minds are fairly evenly distributed amongst alt-coin dev teams. I doubt this is true and the notion underestimates the quality of developer that is attracted to Bitcoin Core to apply themselves to this project, often self-funded. There are few (if any) comparable cryptocurrencies or cc dev teams out there. Hence the Bitcoin market cap, the large stakeholder industry, and the established brand. 3) Bitcoin is better money. Yes, indeed. It's genius and revolution. Yet, it does not fit every use-case. I know people don't like it when I make this example, but it's the truth where I live, and by extension, in many places in the world: I live in rural Southeast Asia. Some houses have electricity and some don't: by choice, because rural lifestyle in the tropics does not always require you to have electricity. People charge their mobile phones at the community eating house every other day. The electricity supply is unreliable. I've had to rig a solar charging system to a UPS, but most people around here have no choice but to deal with intermittent power cuts. The local market has a diesel generator, so constant electricity, but if a power cut lasts for long enough the local cellular mast battery backup depletes and then there is no cellular connectivity - the only means of accessing the internet. Now, how does one expect this community to use or adopt cryptocurrency? They are mostly unbanked, get paid fiat wages at the end of the week and spend fiat on commodities, rent, food and entertainment like the rest of the world. But Bitcoin is not a "better money" in their case, and who knows for how long this condition will remain true. 4) TBD The notion that there be dragons at the capacity limit is unfounded and reactionary. We have to make the journey and find out what is, in fact, there at the edge - as many others have argued in the list. This is our opportunity to make scientific observation and discovery for the benefit of Bitcoin - while it is still in its early years and the capacity limit untested. Who knows? The outcome may be an informed decision to implement bigger blocks. Informed. Based not on fear and uncertainty but on empirical observation and facts. On 08/12/2015 04:39 AM, Michael Naber via bitcoin-dev wrote: > Sure, most people probably would be happy with cheaper off-chain > systems. There already are and will probably continue to be more > transactions happening off-chain partly for this very reason. > That's not the issue we're trying to address though: The main chain > is the lynch-pin to the whole system. We've got to do a good job > meeting demand that people have for wanting to utilize the > main-chain, or else we'll risk being replaced by some other > main-chain solution that does it better. > > On Tue, Aug 11, 2015 at 4:34 PM, Adam Back > wrote: > > 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 >> >> > > > > > _______________________________________________ bitcoin-dev mailing > list bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVyuNYAAoJEGwAhlQc8H1mUwgH/0//DMUJ7E5npMYLg5HA1cPa DM0o9L/Dwp5LN/Pn1gnCQr/57YyvcVYxCbI7QCAgwocz3WhL58DOPe+4XxKoqAz0 BoDp54rBEEWTv7E944LhyTHyhx4Fv4ZTSsGAoBOBQxcZL5Xn5zxwGoMQNBJAsB19 ypYwy3n6hlwYNblyIKVQNmpvN4bb1/KG3r7BarSUM+xBZ/wsTFT49nomFttn/nIo HW0jfLQ4qjFWEbXvI0vn96HHziH9ijE08bRbEtPyW/cmaznWh1sWuRbYwvmKTyPn g0f4iJW0xmEHo43grYutjNwayRFwdc1BEPho4HSTCpcJFOemrF7hCHXdgWsaVEM= =x1Hf -----END PGP SIGNATURE-----