Re: [bitcoin-dev] Fees and the block-finding process

[Venzen Khaosan <venzen@mail.bihthai.net>]

-----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 <adam@cypherspace.org 
> <mailto:adam@cypherspace.org>> 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 <gubatron@gmail.com 
> <mailto:gubatron@gmail.com>> 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 
>> <bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> 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 
>>> <bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> 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
> <pieter.wuille@gmail.com <mailto:pieter.wuille@gmail.com>>
>>>> wrote:
>>>>> 
>>>>> On Tue, Aug 11, 2015 at 9:37 PM, Michael Naber via
>>>>> bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> 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
> <mailto:bitcoin-dev@lists.linuxfoundation.org>
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>>>> 
>>> 
>>> _______________________________________________ bitcoin-dev
>>> mailing list bitcoin-dev@lists.linuxfoundation.org
> <mailto: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-----