[bitcoin-dev] Block size following technological growth

[bitcoin-dev] Block size following technological growth

[Pieter Wuille]

[-- Attachment #1: Type: text/plain, Size: 325 bytes --]

Hello all,

here is a proposal for long-term scalability I've been working on:
https://gist.github.com/sipa/c65665fc360ca7a176a6

Some things are not included yet, such as a testnet whose size runs ahead
of the main chain, and the inclusion of Gavin's more accurate sigop
checking after the hard fork.

Comments?

-- 
Pieter

[-- Attachment #2: Type: text/html, Size: 498 bytes --]

Re: [bitcoin-dev] Block size following technological growth

[Greg Sanders]

[-- Attachment #1: Type: text/plain, Size: 733 bytes --]

What, if any, methods would be used for miners to communicate their
upgrade?

Greg

On Thu, Jul 30, 2015 at 10:25 AM, Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hello all,
>
> here is a proposal for long-term scalability I've been working on:
> https://gist.github.com/sipa/c65665fc360ca7a176a6
>
> Some things are not included yet, such as a testnet whose size runs ahead
> of the main chain, and the inclusion of Gavin's more accurate sigop
> checking after the hard fork.
>
> Comments?
>
> --
> Pieter
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 1571 bytes --]

Re: [bitcoin-dev] Block size following technological growth

[Jorge Timón]

1) Unlike previous blocksize hardfork proposals, this uses median time
instead of block.nTime for activation. I like that more but my
preference is still using height for everything. But that discussion
is not specific to this proposal, so it's better if we discuss that
for all of them here:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009731.html

2) I think uncontroversial hardforks should also take miner
confirmation into account, just like uncontroversial softforks do. We
cannot make sure other users have upgraded before activating the
chain, but we can know whether miners have upgraded or not. Having
that tool available, why not use it. Of course other hardforks may not
care about miners' upgrade state. For example "anti-miner hardforks,
see https://github.com/jtimon/bips/blob/bip-forks/bip-forks.org#asic-reset-hardfork
But again, this is common to all uncontroversial hardforks, so it
would probably better to discussed it in
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008936.html
(gmaxwell assigned to bip99 to my bip draft).

3) As commented to you privately, I don't like to make any assumptions
about technological advancements (much less on economical growth). I
don't expect many people to agree with me here (I guess I've seen too
many "peak oil" [or more generally, peak energy production] plus I've
read Nietzsche's "On the utility and liability of history for life"
[1]; so considering morals, technology or economics as "monotonic
functions" in history is simply a ridiculous notion to me), but it's
undeniable that internet connections have improved overall around the
world in the last 6 years. I think we should wait for the
technological improvements to happen and then adapt the blocksize
accordingly. I know, that's not a "definitive solution", we will need
to change it from time to time and this is somewhat ugly.
But even if I'm the only one that considers a "technological
de-growth" possible, I don't think is wise to rely on pseudo-laws like
Moore's or Nielsen’s so-called "laws".
Stealing a quote from another thread:

"Prediction is difficult, especially about the future." - Niels Bohr

So I would prefer a more limited solution like bip102 (even though I
would prefer to have some simulations leading to  a concrete value
(even if it's bigger) rather than using 2MB's arbitrary number.

Those are my 3 cents.

[1] https://philohist.files.wordpress.com/2008/01/nietzsche-uses-history.pdf

On Thu, Jul 30, 2015 at 4:25 PM, Pieter Wuille via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hello all,
>
> here is a proposal for long-term scalability I've been working on:
> https://gist.github.com/sipa/c65665fc360ca7a176a6
>
> Some things are not included yet, such as a testnet whose size runs ahead of
> the main chain, and the inclusion of Gavin's more accurate sigop checking
> after the hard fork.
>
> Comments?
>
> --
> Pieter
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

Re: [bitcoin-dev] Block size following technological growth

[Jameson Lopp]

[-- Attachment #1: Type: text/plain, Size: 5455 bytes --]

I find it to be an admirable goal to try to keep node operation costs low
and accessible to the average user. On the other hand, if we are able to
keep the resource requirements of nodes at the level of, say, whatever the
latest Raspberry Pi model on a residential Internet connection can handle,
I'm not sure how helpful it will be if the demand for inclusion in blocks
results in transaction fees prices out more users. Stated differently, if
the cost or contention of using the network rises to the point of excluding
the average user from making transactions, then they probably aren't going
to care that they can run a node at trivial cost.

If we're approaching the block size from a resource usage standpoint, it
seems to me that someone is going to be excluded one way or another. Not
raising the block size will exclude some users from sending transactions
while raising the block size will exclude some users from running nodes.
The latter seems preferable to me because more users will grow the
ecosystem, which should increase the value of the ecosystem, which should
increase the cost that entities are willing to pay to run nodes.

I see two primary points of view / objectives clashing in this debate:

1) Decentralization and stability even if it retards growth of the ecosystem
2) Push the system's load as far as we are comfortable in order to
accommodate the growth it is experiencing

It's clear to me that Core developers have a responsibility to maintain a
stable platform for the ecosystem. I think it's less clear that they have a
responsibility to grow it or ask node operators to expend more resources in
order to support more users. As an operator of several nodes, I can
anecdotally state that I find their resource usage to be trivial and I
welcome more load.

- Jameson

On Thu, Jul 30, 2015 at 11:12 AM, Jorge Timón <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 1) Unlike previous blocksize hardfork proposals, this uses median time
> instead of block.nTime for activation. I like that more but my
> preference is still using height for everything. But that discussion
> is not specific to this proposal, so it's better if we discuss that
> for all of them here:
>
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009731.html
>
> 2) I think uncontroversial hardforks should also take miner
> confirmation into account, just like uncontroversial softforks do. We
> cannot make sure other users have upgraded before activating the
> chain, but we can know whether miners have upgraded or not. Having
> that tool available, why not use it. Of course other hardforks may not
> care about miners' upgrade state. For example "anti-miner hardforks,
> see
> https://github.com/jtimon/bips/blob/bip-forks/bip-forks.org#asic-reset-hardfork
> But again, this is common to all uncontroversial hardforks, so it
> would probably better to discussed it in
>
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008936.html
> (gmaxwell assigned to bip99 to my bip draft).
>
> 3) As commented to you privately, I don't like to make any assumptions
> about technological advancements (much less on economical growth). I
> don't expect many people to agree with me here (I guess I've seen too
> many "peak oil" [or more generally, peak energy production] plus I've
> read Nietzsche's "On the utility and liability of history for life"
> [1]; so considering morals, technology or economics as "monotonic
> functions" in history is simply a ridiculous notion to me), but it's
> undeniable that internet connections have improved overall around the
> world in the last 6 years. I think we should wait for the
> technological improvements to happen and then adapt the blocksize
> accordingly. I know, that's not a "definitive solution", we will need
> to change it from time to time and this is somewhat ugly.
> But even if I'm the only one that considers a "technological
> de-growth" possible, I don't think is wise to rely on pseudo-laws like
> Moore's or Nielsen’s so-called "laws".
> Stealing a quote from another thread:
>
> "Prediction is difficult, especially about the future." - Niels Bohr
>
> So I would prefer a more limited solution like bip102 (even though I
> would prefer to have some simulations leading to  a concrete value
> (even if it's bigger) rather than using 2MB's arbitrary number.
>
> Those are my 3 cents.
>
> [1]
> https://philohist.files.wordpress.com/2008/01/nietzsche-uses-history.pdf
>
> On Thu, Jul 30, 2015 at 4:25 PM, Pieter Wuille via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > Hello all,
> >
> > here is a proposal for long-term scalability I've been working on:
> > https://gist.github.com/sipa/c65665fc360ca7a176a6
> >
> > Some things are not included yet, such as a testnet whose size runs
> ahead of
> > the main chain, and the inclusion of Gavin's more accurate sigop checking
> > after the hard fork.
> >
> > Comments?
> >
> > --
> > 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
>

[-- Attachment #2: Type: text/html, Size: 7308 bytes --]

Re: [bitcoin-dev] Block size following technological growth

[Bryan Bishop]

[-- Attachment #1: Type: text/plain, Size: 949 bytes --]

On Thu, Jul 30, 2015 at 11:23 AM, Jameson Lopp via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Stated differently, if the cost or contention of using the network rises
> to the point of excluding the average user from making transactions, then
> they probably aren't going to care that they can run a node at trivial cost.


That's an interesting claim; so suppose you're living in a future where
transactions are summarizing millions or billions of other daily
transactions, possibly with merkle hashes. You think that because a user
can't individually broadcast his own personal transaction, that the user
would not be interested in verifying the presence of a summarizing
transaction in the blockchain? I'm just curious if you could elaborate on
this effect. Why would I need to see my individual transactions on the
network, but not see aggregate transactions that include my own?

- Bryan
http://heybryan.org/
1 512 203 0507

[-- Attachment #2: Type: text/html, Size: 1379 bytes --]

Re: [bitcoin-dev] Block size following technological growth

[Jameson Lopp]

[-- Attachment #1: Type: text/plain, Size: 1824 bytes --]

I fully expect that new layers will someday allow us to facilitate higher
transaction volumes, though I'm concerned about the current state of the
network and the fact that there are no concrete timelines for the rollout
of aforementioned high volume networks.

As for reasoning behind why users will still need to settle on-chain even
with the existence of high volume networks, see these posts:

http://sourceforge.net/p/bitcoin/mailman/message/34119233/

http://sourceforge.net/p/bitcoin/mailman/message/34113067/

Point being, the scalability proposals that are currently being developed
are not magic bullets and still require the occasional on-chain settlement.
Larger blocks will be necessary with or without the actual scalability
enhancements.

- Jameson

On Thu, Jul 30, 2015 at 12:36 PM, Bryan Bishop <kanzure@gmail.com> wrote:

> On Thu, Jul 30, 2015 at 11:23 AM, Jameson Lopp via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Stated differently, if the cost or contention of using the network rises
>> to the point of excluding the average user from making transactions, then
>> they probably aren't going to care that they can run a node at trivial cost.
>
>
> That's an interesting claim; so suppose you're living in a future where
> transactions are summarizing millions or billions of other daily
> transactions, possibly with merkle hashes. You think that because a user
> can't individually broadcast his own personal transaction, that the user
> would not be interested in verifying the presence of a summarizing
> transaction in the blockchain? I'm just curious if you could elaborate on
> this effect. Why would I need to see my individual transactions on the
> network, but not see aggregate transactions that include my own?
>
> - Bryan
> http://heybryan.org/
> 1 512 203 0507
>

[-- Attachment #2: Type: text/html, Size: 2863 bytes --]

Re: [bitcoin-dev] Block size following technological growth

[Venzen Khaosan]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On 07/30/2015 10:12 PM, Jorge Timón via bitcoin-dev wrote:
[snip]
> But even if I'm the only one that considers a "technological 
> de-growth" possible, I don't think is wise to rely on pseudo-laws
> like Moore's or Nielsen’s so-called "laws". Stealing a quote from
> another thread:

You raise a good point: "de-growth"

Assuming linear (or exponential) growth without sympathetic
contraction at some time in the future would make our future selves
look back and smile at the youthful exuberance.

The pseudo-laws you mention (Moore's etc) do not cater for contraction
and, you're right, scaling UP plans should also wisely make provision
for scaling DOWN, for when the need arises.
> 
> So I would prefer a more limited solution like bip102 (even though
> I would prefer to have some simulations leading to  a concrete
> value (even if it's bigger) rather than using 2MB's arbitrary
> number.

I just had a look your existing Size N testnet code
https://github.com/bitcoin/bitcoin/pull/6382
and i'll set up a node over the weekend and post its address in that
PR's conversation. Do you or anyone else already have a node running?
what blocksize?
> 
> Those are my 3 cents.
> 
> [1]
> https://philohist.files.wordpress.com/2008/01/nietzsche-uses-history.pdf

Thanks,
> 
will broaden my horizon soon!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVulKBAAoJEGwAhlQc8H1mUSAH/Rmlek3uitGyIritwyDO4Kf7
BfynlztWmPbnWl7aFYQCS+aIPgS+BvQWIiA0dTI633yj071DWEvcGDzhtcVrk0KT
//Ty8bp8yqsJRdd+SWgnqUzSmB6TI31F3ssxjDfSZhKiy8YF4+pKqjerQmBqlgLY
sKts3md8N8qWV5Onjd7ea+7SoFjhJ6GOm2UFgxO27LCeDH5Ax5fG4MsolNg3MBTT
5y7Hfo1YeFXRwRRSy5uCSSR0afBb8Wauqi/EnSYDuMe5HBcLztc7icXa6oLTlvBC
sfYswasmLRbvHLs4Vy51g75+k60QBjgFKtVlPXJXGN2trbcedF0UbDmenxGqJaI=
=rJPX
-----END PGP SIGNATURE-----

Re: [bitcoin-dev] Block size following technological growth

[Jorge Timón]

On Thu, Jul 30, 2015 at 6:36 PM, Venzen Khaosan <venzen@mail.bihthai.net> wrote:
> I just had a look your existing Size N testnet code
> https://github.com/bitcoin/bitcoin/pull/6382
> and i'll set up a node over the weekend and post its address in that
> PR's conversation. Do you or anyone else already have a node running?
> what blocksize?

Great! No, I'm not running any node right now at any size.
Take into account that it's not a regular testnet (ie like testnet3),
it's a regtest-like testnet to make mining and simulations cheap.
That also means that anybody can trivially create reorgs, so it is
expected to be used in a controlled environment (you can control which
node creates a new block and when).

Re: [bitcoin-dev] Block size following technological growth

[Jorge Timón]

Gavin, Pieter, Mark, Gary, can we move the median time discussion to
its own thread?
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009731.html

I really don't want to fill this thread with that discussion.

On Thu, Jul 30, 2015 at 7:51 PM, Jorge Timón <jtimon@jtimon.cc> wrote:
> On Thu, Jul 30, 2015 at 6:36 PM, Venzen Khaosan <venzen@mail.bihthai.net> wrote:
>> I just had a look your existing Size N testnet code
>> https://github.com/bitcoin/bitcoin/pull/6382
>> and i'll set up a node over the weekend and post its address in that
>> PR's conversation. Do you or anyone else already have a node running?
>> what blocksize?
>
> Great! No, I'm not running any node right now at any size.
> Take into account that it's not a regular testnet (ie like testnet3),
> it's a regtest-like testnet to make mining and simulations cheap.
> That also means that anybody can trivially create reorgs, so it is
> expected to be used in a controlled environment (you can control which
> node creates a new block and when).

Re: [bitcoin-dev] Block size following technological growth

[Gary Mulder]

[-- Attachment #1: Type: text/plain, Size: 1231 bytes --]

On 30 July 2015 at 16:12, Jorge Timón <bitcoin-dev@lists.linuxfoundation.org
> wrote:

> 1) Unlike previous blocksize hardfork proposals, this uses median time
> instead of block.nTime for activation. I like that more but my
> preference is still using height for everything. But that discussion
> is not specific to this proposal, so it's better if we discuss that
> for all of them here:
>
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009731.html


Note that a "median" is a special case of a 50% percentile. If you desire
to apply a more stringent criteria you can use the 75th or even 90th
percentile.

https://en.wikipedia.org/wiki/Percentile

Perhaps if a statistician (i.e. not me) could be found to offer her
services, she could become a resource for helping selecting the most
appropriate statistical algorithms on request (and implemented Integer math
as per Gavin, from memory), considering the consequences of learning
post-fork that a "bad statistical model" was chosen.

e.g. an exponentially weighted moving average is usually much less volatile
and harder to manipulate than a simple moving average, but still can
"respond" to short term drivers.

Regards,
Gary

[-- Attachment #2: Type: text/html, Size: 2512 bytes --]

Re: [bitcoin-dev] Block size following technological growth

[Mark Friedenbach]

[-- Attachment #1: Type: text/plain, Size: 2120 bytes --]

The median is used here because that is the consensus rule -- a block
cannot have a timestamp older than the median time of the last 11 blocks.
By linking the changeover to this rule we avoid perverse incentives about
miners lying in their timestamps, or the threshold being crossed, then
reverted, then crossed again, etc.

Maybe a different percentile would have been a better choice, but that ship
sailed in 2009. The rule is what it is right now, and we benefit the most
from using the same rule as consensus for the threshold.
On Jul 30, 2015 9:57 AM, "Gary Mulder via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On 30 July 2015 at 16:12, Jorge Timón <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> 1) Unlike previous blocksize hardfork proposals, this uses median time
>> instead of block.nTime for activation. I like that more but my
>> preference is still using height for everything. But that discussion
>> is not specific to this proposal, so it's better if we discuss that
>> for all of them here:
>>
>> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009731.html
>
>
> Note that a "median" is a special case of a 50% percentile. If you desire
> to apply a more stringent criteria you can use the 75th or even 90th
> percentile.
>
> https://en.wikipedia.org/wiki/Percentile
>
> Perhaps if a statistician (i.e. not me) could be found to offer her
> services, she could become a resource for helping selecting the most
> appropriate statistical algorithms on request (and implemented Integer math
> as per Gavin, from memory), considering the consequences of learning
> post-fork that a "bad statistical model" was chosen.
>
> e.g. an exponentially weighted moving average is usually much less
> volatile and harder to manipulate than a simple moving average, but still
> can "respond" to short term drivers.
>
> Regards,
> Gary
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 3797 bytes --]

Re: [bitcoin-dev] Block size following technological growth

[Gavin Andresen]

[-- Attachment #1: Type: text/plain, Size: 1169 bytes --]

On Thu, Jul 30, 2015 at 10:25 AM, Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Some things are not included yet, such as a testnet whose size runs ahead
> of the main chain, and the inclusion of Gavin's more accurate sigop
> checking after the hard fork.
>
> Comments?
>

First, THANK YOU for making a concrete proposal!

Specific comments:

So we'd get to 2MB blocks in the year 2021. I think that is much too
conservative, and the most likely effect of being that conservative is that
the main blockchain becomes a settlement network, affordable only for
large-value transactions.

I don't think your proposal strikes the right balance between
centralization of payments (a future where only people running payment
hubs, big merchants, exchanges, and wallet providers settle on the
blockchain) and centralization of mining.



I'll comment on using median time generally in Jorge's thread, but why does
monotonically increasing matter for max block size? I can't think of a
reason why a max block size of X bytes in block N followed by a max size of
X-something bytes in block N+1 would cause any problems.

-- 
--
Gavin Andresen

[-- Attachment #2: Type: text/html, Size: 1799 bytes --]

Re: [bitcoin-dev] Block size following technological growth

[Suhas Daftuar]

[-- Attachment #1: Type: text/plain, Size: 1072 bytes --]

On Thu, Jul 30, 2015 at 12:20 PM, Gavin Andresen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> So we'd get to 2MB blocks in the year 2021. I think that is much too
> conservative, and the most likely effect of being that conservative is that
> the main blockchain becomes a settlement network, affordable only for
> large-value transactions.
>

While that may be true I think that's okay -- if it turns out that this is
too conservative, and we succeed in scaling the system so that it's
non-controversial to increase these limits later via another hard fork, we
would still be free to do so.

It seems to me that everyone who has been arguing recently to increase the
block size limit ought to find this proposal to be a strict improvement
over where we are now, and this proposal seems like it's reasonably likely
to be non-controversial enough to be worth proposing as a hard fork in
Bitcoin Core -- thank you Pieter for putting this together.

For my part, I'd give this a concept ACK, pending hearing further thoughts
from others.

Suhas Daftuar

[-- Attachment #2: Type: text/html, Size: 1576 bytes --]

Re: [bitcoin-dev] Block size following technological growth

[Adam Back]

That's what is nice about proposals, they are constructive and help
move the conversation forward!

On 30 July 2015 at 18:20, Gavin Andresen via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> Specific comments:
>
> So we'd get to 2MB blocks in the year 2021. I think that is much too
> conservative, and the most likely effect of being that conservative is that
> the main blockchain becomes a settlement network, affordable only for
> large-value transactions.

But, if we agree that 17%/year is consistent with network
improvements, by arguing this is too conservative, does that not mean
you are actually going beyond suggesting throughput increases to
benefit from bandwidth improvements, and explicitly arguing to
borrowing from Bitcoin's already very weak decentralisation to create
more throughput?  (Or arguing to subsidise transaction fees if
borrowing so deeply that excess capacity pushes beyond demand).

I think the logical implication of this would be that we should be
first focussing on improving decentralisation, to make security room
to reclaim extra throughput.

(To be clear there are concrete things that can be done and actually
are being done to improve decentralisation via ecosystem education and
mining protocol improvements, but it's safer to wait a few months and
see if those things take effect well).

Secondly in this assumption are you considering that lightning will
likely be online for many years by 2021 and the situation will be
hugely different?

I think an incremental and conservative approach is safer.  People can
probably get a lightning prototype running about as fast as a
hard-fork could be safely rolled out.

I do think it is normal to be conservative with security and with $4b
of other peoples money.  It's no longer an experimental system to
consider fail fast experiments on.

> I don't think your proposal strikes the right balance between centralization
> of payments (a future where only people running payment hubs, big merchants,
> exchanges, and wallet providers settle on the blockchain) and centralization
> of mining.

What criteria should we be using in your opinion to balance?  I think
throughput increases trading off decentralisation would be more
reasonable if decentralisation wasnt in very bad shape.

Adam

Re: [bitcoin-dev] Block size following technological growth

[Pieter Wuille]

[-- Attachment #1: Type: text/plain, Size: 2897 bytes --]

On Jul 30, 2015 6:20 PM, "Gavin Andresen" <gavinandresen@gmail.com> wrote:
>
> On Thu, Jul 30, 2015 at 10:25 AM, Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> Some things are not included yet, such as a testnet whose size runs
ahead of the main chain, and the inclusion of Gavin's more accurate sigop
checking after the hard fork.
>>
>> Comments?
>
>
> First, THANK YOU for making a concrete proposal!

You're welcome.

> Specific comments:
>
> So we'd get to 2MB blocks in the year 2021. I think that is much too
conservative, and the most likely effect of being that conservative is that
the main blockchain becomes a settlement network, affordable only for
large-value transactions.

If there is demand for high-value settlements in Bitcoin, and this results
in a functioning economy where fees support the security of a transparent
network, I think that would be a much better outcome than what we have now.

> I don't think your proposal strikes the right balance between
centralization of payments (a future where only people running payment
hubs, big merchants, exchanges, and wallet providers settle on the
blockchain) and centralization of mining.

Well, centralization of mining is already terrible. I see no reason why we
should encourage making it worse. On the other hand, sure, not every
transaction fits on the blockchain. That is already the case, and will
remain the case with 2 MB or 8 MB or 100 MB blocks. Some use cases fit, and
others won't. We need to accept that, and all previous proposals I've seen
don't seem to do that.

Maybe the only ones that will fit are large settlements between layer-2
services, and maybe it will be something entirely different. But at least
we don't need to compromise the security of the main layer, or promise the
ecosystem unrealistic growth of space for on-chain transactions.

If Bitcoin needs to support a large scale, it already failed.

> I'll comment on using median time generally in Jorge's thread, but why
does monotonically increasing matter for max block size? I can't think of a
reason why a max block size of X bytes in block N followed by a max size of
X-something bytes in block N+1 would cause any problems.

I don't think it matters much, but it offers slightly easier transition for
the mempool (something Jorge convinced me of), and validation can benefit
from a single variable that can be set in a chain to indicate a switchover
happened, without needing to recalculate it every time.

I assume you're asking this because using raw nTime means you can check
what limits a p2p message should obey to by looking at just the first
bytes. I don't think this matters: your p2p protocol should deal with
whatever limits the system requires anyway. An attacker can take a valid
message of far in the chain, change a few bytes, and spam you with it at
zero extra effort anyway.

-- 
Pieter

[-- Attachment #2: Type: text/html, Size: 3409 bytes --]

Re: [bitcoin-dev] Block size following technological growth

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 5176 bytes --]

I agree with Gavin - whilst it's great that a Blockstream employee has
finally made a realistic proposal (i.e. not "let's all use Lightning") -
this BIP is virtually the same as keeping the 1mb cap.

> Well, centralization of mining is already terrible. I see no reason why we
> should encourage making it worse.
>
Centralization of mining has been a continual gripe since Slush first
invented pooled mining. There has never been a time after that when people
weren't talking about the centralisation of mining, and back then blocks
were ~10kb.

I see constant assertions that node count, mining centralisation,
developers not using Bitcoin Core in their own businesses etc is all to do
with block sizes. But nobody has shown that. Nobody has even laid the
groundwork for that. Verifying blocks takes milliseconds and downloading
them takes seconds everywhere except, apparently, China: this resource
usage is trivial.

Yet developers, miners and users even outside of China routinely delegate
validation to others. Often for quite understandable technical reasons that
have nothing to do with block sizes.

So I see no reason why arbitrarily capping the block size will move the
needle on these metrics. Trying to arrest the growth of Bitcoin for
everyone won't suddenly make Bitcoin-Qt a competitive wallet, or make
service devs migrate away from chain.com, or make merchants stop using
BitPay.

We need to accept that, and all previous proposals I've seen don't seem to
> do that.
>
I think that's a bit unfair: BIP 101 keeps a cap. Even with 8mb+growth
you're right, some use cases will be priced out. I initiated the
micropayment channels project (along with Matt, tip of the hat)
specifically to optimise a certain class of transactions. Even with 8mb+
blocks, there will still be a need for micropayment channels, centralised
exchange platforms and other forms of off chain transaction.

If Bitcoin needs to support a large scale, it already failed.
>
It hasn't even been tried.

The desperately sad thing about all of this is that there's going to be a
fork, and yet I think most of us agree on most things.  But we don't agree
on this.

Bitcoin can support a large scale and it must, for all sorts of reasons.
Amongst others:

   1. Currencies have network effects. A currency that has few users is
   simply not competitive with currencies that have many. There's no such
   thing as a settlement currency for high value transactions only, as
   evidenced by the ever-dropping importance of gold.


   2. A decentralised currency that the vast majority can't use doesn't
   change the amount of centralisation in the world. Most people will still
   end up using banks, with all the normal problems. You cannot solve a
   problem by creating a theoretically pure solution that's out of reach of
   ordinary people: just ask academic cryptographers!


   3. Growth is a part of the social contract. It always has been.

   The best quote Gregory can find to suggest Satoshi wanted small blocks
   is a one sentence hypothetical example about what *might* happen if
   Bitcoin users became "tyrannical" as a result of non-financial transactions
   being stuffed in the block chain. That position makes sense because his
   scaling arguments assuming payment-network-sized traffic and throwing DNS
   systems or whatever into the mix could invalidate those arguments, in the
   absence of merged mining. But Satoshi did invent merged mining, and so
   there's no need for Bitcoin users to get "tyrannical": his original
   arguments still hold.


   4. All the plans for some kind of ultra-throttled Bitcoin network used
   for infrequent transactions neglect to ask where the infrastructure for
   that will come from. The network of exchanges, payment processors and
   startups that are paying people to build infrastructure are all based on
   the assumption that the market will grow significantly. It's a gamble at
   best because Bitcoin's success is not guaranteed, but if the block chain
   cannot grow it's a gamble that is guaranteed to be lost.

   So why should anyone go through the massive hassle of setting up
   exchanges, without the lure of large future profits?


   5. Bitcoin needs users, lots of them, for its political survival. There
   are many people out there who would like to see digital cash disappear, or
   be regulated out of existence. They will argue for that in front of
   governments and courts .... some already are. And if they're going to lose
   those arguments, the political and economic damage of getting rid of
   Bitcoin must be large enough to make people think twice. That means it
   needs supporters, it needs innovative services, it needs companies, and it
   needs legal users making legal payments: as many of them as possible.

   If Bitcoin is a tiny, obscure currency used by drug dealers and a
   handful of crypto-at-any-cost geeks, the cost of simply banning it outright
   will seem trivial and the hammer will drop. There won't be a large scale
   payment network OR a high-value settlement network. And then the world is
   really screwed, because nobody will get a second chance for a very long
   time.

[-- Attachment #2: Type: text/html, Size: 6012 bytes --]

Re: [bitcoin-dev] Block size following technological growth

[Venzen Khaosan]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mike Hearn, I might be a nobody to you, but you know i talk with
skill,  so let me tell this Friday...


On 07/31/2015 05:16 PM, Mike Hearn via bitcoin-dev wrote:
> I agree with Gavin
You would, of course.

> Bitcoin can support a large scale and it must, for all sorts of 
> reasons. Amongst others:
> 
> 1. Currencies have network effects. A currency that has few users 
> is simply not competitive with currencies that have many. There's 
> no such thing as a settlement currency for high value transactions 
> only, as evidenced by the ever-dropping importance of gold.

References are imperative if you want to appeal to intelligence in
this list. Studies. Impirical evidence. The above sounds like a a
mainstream precis of how money works - an over-simplistic precis. It's
more complex than that. Besides, all we know for a fact is that
currencies come and go. That's not me being down on Bitcoin - that is
the historical record.

> 
> 2. A decentralised currency that the vast majority can't use 
> doesn't change the amount of centralisation in the world. Most 
> people will still end up using banks, with all the normal
> problems. You cannot solve a problem by creating a theoretically
> pure solution that's out of reach of ordinary people: just ask
> academic cryptographers!

Conjecture. And assumption. Banks might not accept most people
forever. Or banks' credibility might not survive the next credit
contraction, for example.

> 
> 3. Growth is a part of the social contract. It always has been.
> 
Half the story. Casual observation shows that growth and contraction
alternate at every level of existence. Just because the present
fiat-era credit expansion has lasted 40 years does not mean that the
economy will keep expanding forever.

> The best quote Gregory can find to suggest Satoshi wanted small 
> blocks is a one sentence hypothetical example about what /might/
[snip]

yes, anyway, Greg Maxwell was justified in bringing you down a few
notches from your "I am Satoshi's rep on earth" history revision, you
were spinning there.


> 4. All the plans for some kind of ultra-throttled Bitcoin network 
> used

[snip]

> The network of exchanges, payment processors and startups that are 
> paying people to build infrastructure are all based on _the 
> assumption_ that the market will grow significantly.
The assumption (my emphasis). You've seen that movie Pulp Fiction:
"Assume makes an "ass" of "U" and "me". Business + assumption =
gambling and potential loss of funds.

The ass-U-me cannot be laid at the doorstep of those developers who
prioritize security, decentralization and conservative, tested
progress of scaling.

> So why should anyone go through the massive hassle of setting up 
> exchanges, without the lure of large future profits?
> 
Their SWOT analysis includes risks from the banking sector, too. Plus
competition from other exchanges. A sapling 0.x Bitcoin community is
not responsible for nannying anyone's lucrative business model at the
expense of security. How would that make the developers look in
relation to their duty of custody of the protocol? To this and future
generations: Not Good.
> 
> 5. Bitcoin needs users, lots of them, for its political survival. 
> There are many people out there who would like to see digital cash 
> disappear, or be regulated out of existence.
Nonsense, and again that assumption about "how things work" you like
to high horse so. Bitcoin's political survival is guaranteed by its
censorship resistance and its array of innovative and unique utility
functions. What's more, the caliber of developer working on Bitcoin is
not just pulled out of a hat and harnessed for an arbitrary altcoin.
Sometimes the fire of moral incentive overrides monetary reward.

The Fed, Nasdaq, IBM, and every other company whose trusted authority
is being threatened by this flagship are developing blockchains in a
hurry. How is that "many people out there who would like to see
digital cash disappear"? Why would you even type such a blatant falsehood?

> If Bitcoin is a tiny, obscure currency used by drug dealers and a 
> handful of crypto-at-any-cost geeks, the cost of simply banning it 
> outright will seem trivial and the hammer will drop. There won't be
> a large scale payment network OR a high-value settlement network.
> And then the world is really screwed, because nobody will get a
> second chance for a very long time.
> 
That is a low estimation of Bitcoin. Your framing does not honor
Bitcoin or the hard work - your _own_ hard work - on this project.

If you noticed, there has been an increase in technical discussion in
this list in recent days - with the goal of comparing and testing the
various blocksize proposals.

Mike Hearn, I am sorry to say that your pronouncements sound like jazz
- - but jazz without rhythm.


"So what?" - Miles Davis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVu199AAoJEGwAhlQc8H1mkCMH/iWnFDXAGc5GEjLi81dRLUnz
3UfciwOiby8r+7pvyDsuMYR/9RQZv2RlFoMFjUBkJxwvdUh3eXY5tsQ6F209O+gk
QleFaTKCZLVuZg5UBbwBttGfK3MmejueGWNhExYnlbm6yXpBa2jt0i5n0tr++zVw
RN+zAejOy2OEBjs7jkodgVdy7kfCXsfsn/DKGdSO7nE9m5q0ocuUFBLEf/PJErBw
NncLSDhd2SfVz3Q7L9UrGqKIgQTJT1nR9kJmSPCasIRoLWJzfNemH6RL3XcmiACn
xIQBN19FPnKLv1OY3GlFLlmIlq0mu6MeidJsPl80yyI2h4SciCp39T1Ah/tCnf4=
=2uWe
-----END PGP SIGNATURE-----

Re: [bitcoin-dev] Block size following technological growth

[Jorge Timón]

On Fri, Jul 31, 2015 at 12:16 PM, Mike Hearn via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>> Well, centralization of mining is already terrible. I see no reason why we
>> should encourage making it worse.
>
> I see constant assertions that node count, mining centralisation, developers
> not using Bitcoin Core in their own businesses etc is all to do with block
> sizes. But nobody has shown that. Nobody has even laid the groundwork for
> that. Verifying blocks takes milliseconds and downloading them takes seconds
> everywhere except, apparently, China: this resource usage is trivial.

He is not saying that. Whatever the reasons for centralization are, it
is obvious that increasing the size won't help.
In the best case, it will only make it slightly worse. How big of a
"slightly worse" are we willing to risk to increase the size is the
open question.

> So I see no reason why arbitrarily capping the block size will move the
> needle on these metrics. Trying to arrest the growth of Bitcoin for everyone
> won't suddenly make Bitcoin-Qt a competitive wallet, or make service devs
> migrate away from chain.com, or make merchants stop using BitPay.

As far as I know, people just want to change an arbitrary number for
another arbitrary number.
But this arbitrary cap is a cap to centralization, not a tool to make
Bitcoin-Qt more important or to attack concrete Bitcoin companies like
you seem to think.
If you don't think the blocksize cap helps limiting centralization and
you think it would be fine to completely remove it, then it would be
better for the conversation that you said that directly instead of
supporting other arbitrary caps like 8GB (bip101).

I think it would be nice to have some sort of simulation to calculate
a "centralization heuristic" for different possible blocksize values
so we can compare these arbitrary numbers somehow. Even if the first
definition of this "centralization heuristic" is stupid, it would be
better than keep rolling dices and heatedly defend one result over
another.
To reiterate, If you don't think the blocksize cap helps limiting
centralization, please, say so.
If we can't agree on what the limit is for, we will never be able to
agree on whether 1MB (current situation) or 8GB (bip101) is the most
appropriate value to have at a given point in time.

>> We need to accept that, and all previous proposals I've seen don't seem to
>> do that.
>
> I think that's a bit unfair: BIP 101 keeps a cap. Even with 8mb+growth
> you're right, some use cases will be priced out. I initiated the
> micropayment channels project (along with Matt, tip of the hat) specifically
> to optimise a certain class of transactions. Even with 8mb+ blocks, there
> will still be a need for micropayment channels, centralised exchange
> platforms and other forms of off chain transaction.

Lightning is nothing more than a better design for trustless payment
channels, but it's really good that you agree that if we want to scale
not everything can be broadcast in-chain.

>> If Bitcoin needs to support a large scale, it already failed.
>
> It hasn't even been tried.

What he means is that if Bitcoin needs to support a scale that is only
feasible with high degrees of centralization (say, supporting 1 M tx/s
right now), then it has already failed in its decentralization goals.
In fact, with only a few miners, I'm not sure regulators will still
agree Bitcoin transactions are irreversible...
But you are right, we haven't tried to destroy bitcoin by removing the
only available consensus tool to limit centralization yet.
I don't want to try, do you?

> A decentralised currency that the vast majority can't use doesn't change the
> amount of centralisation in the world. Most people will still end up using
> banks, with all the normal problems. You cannot solve a problem by creating
> a theoretically pure solution that's out of reach of ordinary people: just
> ask academic cryptographers!

Let's go to "most people use bitcoin" first and then think about "many
people ONLY use Bitcoin" later, please.
I believe everybody here thinks that the more people are able to use
Bitcoin, the better.
But that doesn't

> All the plans for some kind of ultra-throttled Bitcoin network used for
> infrequent transactions neglect to ask where the infrastructure for that
> will come from. The network of exchanges, payment processors and startups
> that are paying people to build infrastructure are all based on the
> assumption that the market will grow significantly. It's a gamble at best
> because Bitcoin's success is not guaranteed, but if the block chain cannot
> grow it's a gamble that is guaranteed to be lost.

Risking destroying Bitcoin through centralization to be able to keep
free transactions for longer it's a very risky gamble.
Doing so explicitly against the will of some of the users by promoting
schism hardfork, and thus risking to economically destroy both Bitcoin
and Bitcoin_new_size (different currencies) in the process is also a
very risky gamble.
So may want to give some example of responsibility yourself to make
these calls to responsibility more credible.
You certainly cannot know what "all the payment processors and
startups plans" are based on, and spreading conspiracy theories about
the evil secret plans of Blockstream (or any other Bitcoin company)
doesn't help in keeping this discussion civilized, contaminates
bitcoin development in general and unhealthily polarizes the whole
Bitcoin ecosystem. Also, I believe is doing a disservice to your
reputation among technical people, but since you don't seem worried
about that, why should I be?

> So why should anyone go through the massive hassle of setting up exchanges,
> without the lure of large future profits?

Are you suggesting that bitcoin consensus rules should be designed to
maximize the profits of Bitcoin exchanges?
I assume not, but I'm really having troubles trying to read the
question with another meaning.
Can you rephrase this, please?

Re: [bitcoin-dev] Block size following technological growth

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 2571 bytes --]

Hey Jorge,

He is not saying that. Whatever the reasons for centralization are, it
> is obvious that increasing the size won't help.
>

It's not obvious. Quite possibly bigger blocks == more users == more nodes
and more miners.

To repeat: it's not obvious to me at all that everything wrong with Bitcoin
can be solved by shrinking blocks. I don't think that's going to suddenly
make everything magically more decentralised.

The 8mb cap isn't quite arbitrary. It was picked through negotiation with
different stakeholders, in particular, Chinese miners. But it should be
high enough to ensure organic growth is not constrained, which is good
enough.

I think it would be nice to have some sort of simulation to calculate
> a "centralization heuristic" for different possible blocksize values
> so we can compare these arbitrary numbers somehow.


Centralization is not a single floating point value that is controlled by
block size. It's a multi-faceted and complex problem. You cannot "destroy
Bitcoin through centralization" by adjusting a single constant in the
source code.

To say once more: block size won't make much difference to how many
merchants rely on payment processors because they aren't using them due to
block processing overheads anyway. So trying to calculate such a formula
won't work. Ditto for end users on phones, ditto for developers who want
JSON/REST access to an indexed block chain, or hosted wallet services, or
miners who want to reduce variance.

None of these factors have anything to do with traffic levels.

What people like you are Pieter are doing is making a single number a kind
of proxy for all fears and concerns about the trend towards outsourcing in
the Bitcoin community. Everything gets compressed down to one number you
feel you can control, whether it is relevant or not.

> So why should anyone go through the massive hassle of setting up
> exchanges,
> > without the lure of large future profits?
>
> Are you suggesting that bitcoin consensus rules should be designed
> to maximize the profits of Bitcoin exchanges?
>

That isn't what I said at all Jorge. Let me try again.

Setting up an exchange is a lot of risky and expensive work. The motivation
is profit, and profits are higher when there are more users to sell to.
This is business 101.

If you remove the potential for future profit, you remove the motivation to
create the services that we now enjoy and take for granted. Because if you
think Bitcoin can be useful without exchanges then let me tell you, I was
around when there were none. Bitcoin was useless.

[-- Attachment #2: Type: text/html, Size: 3384 bytes --]

Re: [bitcoin-dev] Block size following technological growth

[Marcel Jamin]

[-- Attachment #1: Type: text/plain, Size: 3824 bytes --]

> Quite possibly bigger blocks == more users == more nodes and more miners.

I agree and would say that this is the only prediction of bitcoin's future
we can be absolutely sure of: more users equals more decentralization as
long as the cost of running a node is not prohibitively high.

It's incredibly cheap today and won't be too high with any of the current
proposals for the time being. If the "laws" of Nielsen & co suddenly don't
apply anymore, we can always react to that with another hardfork reducing
the rate of growth. Hardforks are way easier if the network is in danger
and the necessary change is obvious and non-controversial (e.g. "reduce
blocksize limit growth").

As long as hobbyists can participate in running the network and it's
affordable for everyone to transact on it, bitcoin will grow and its
decentralization with it, however you measure it.

2015-07-31 14:15 GMT+02:00 Mike Hearn via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org>:

> Hey Jorge,
>
> He is not saying that. Whatever the reasons for centralization are, it
>> is obvious that increasing the size won't help.
>>
>
> It's not obvious. Quite possibly bigger blocks == more users == more nodes
> and more miners.
>
> To repeat: it's not obvious to me at all that everything wrong with
> Bitcoin can be solved by shrinking blocks. I don't think that's going to
> suddenly make everything magically more decentralised.
>
> The 8mb cap isn't quite arbitrary. It was picked through negotiation with
> different stakeholders, in particular, Chinese miners. But it should be
> high enough to ensure organic growth is not constrained, which is good
> enough.
>
> I think it would be nice to have some sort of simulation to calculate
>> a "centralization heuristic" for different possible blocksize values
>> so we can compare these arbitrary numbers somehow.
>
>
> Centralization is not a single floating point value that is controlled by
> block size. It's a multi-faceted and complex problem. You cannot "destroy
> Bitcoin through centralization" by adjusting a single constant in the
> source code.
>
> To say once more: block size won't make much difference to how many
> merchants rely on payment processors because they aren't using them due to
> block processing overheads anyway. So trying to calculate such a formula
> won't work. Ditto for end users on phones, ditto for developers who want
> JSON/REST access to an indexed block chain, or hosted wallet services, or
> miners who want to reduce variance.
>
> None of these factors have anything to do with traffic levels.
>
> What people like you are Pieter are doing is making a single number a kind
> of proxy for all fears and concerns about the trend towards outsourcing in
> the Bitcoin community. Everything gets compressed down to one number you
> feel you can control, whether it is relevant or not.
>
> > So why should anyone go through the massive hassle of setting up
>> exchanges,
>> > without the lure of large future profits?
>>
>> Are you suggesting that bitcoin consensus rules should be designed
>> to maximize the profits of Bitcoin exchanges?
>>
>
> That isn't what I said at all Jorge. Let me try again.
>
> Setting up an exchange is a lot of risky and expensive work. The
> motivation is profit, and profits are higher when there are more users to
> sell to. This is business 101.
>
> If you remove the potential for future profit, you remove the motivation
> to create the services that we now enjoy and take for granted. Because if
> you think Bitcoin can be useful without exchanges then let me tell you, I
> was around when there were none. Bitcoin was useless.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 5462 bytes --]

Re: [bitcoin-dev] Block size following technological growth

[Jorge Timón]

On Fri, Jul 31, 2015 at 2:15 PM, Mike Hearn <hearn@vinumeris.com> wrote:
> Hey Jorge,
>
>> He is not saying that. Whatever the reasons for centralization are, it
>> is obvious that increasing the size won't help.
>
>
> It's not obvious. Quite possibly bigger blocks == more users == more nodes
> and more miners.

How more users or more nodes can bring more miners, or more
importantly, improve mining decentralization?

> To repeat: it's not obvious to me at all that everything wrong with Bitcoin
> can be solved by shrinking blocks. I don't think that's going to suddenly
> make everything magically more decentralised.

I don't think anybody is defending that position so you can stop refuting it.

> The 8mb cap isn't quite arbitrary. It was picked through negotiation with
> different stakeholders, in particular, Chinese miners. But it should be high
> enough to ensure organic growth is not constrained, which is good enough.

Well, negatiations don't make the number less arbitrary. As far as I
know, the sequence of events was this:

1) Gavin proposes 20MB to 20GB
2) Some chinese miners say they can securely handle at most 8 MB.
3) Gavin proposes 8 MB to 8 GB

In any case, history is irrelevant for this point: if party 1 proposes
arbitrary value A and party 2 proposes arbitrary value B, any
"compromise" value between those 2 is still an arbitrary value. For
example, A + ((B-A)/2) is still an arbitrary value.

I'm sorry, but until there's a simulation that I can run with
different sizes' testchains (for example using #6382) to somehow
compare them, I will consider any value arbitrary. A "I run this with
blocksize=X and nothing seems to have broken" doesn't help here.
We need to compare, and a criterion to compare.

>> I think it would be nice to have some sort of simulation to calculate
>> a "centralization heuristic" for different possible blocksize values
>> so we can compare these arbitrary numbers somehow.
>
>
> Centralization is not a single floating point value that is controlled by
> block size. It's a multi-faceted and complex problem. You cannot "destroy
> Bitcoin through centralization" by adjusting a single constant in the source
> code.

Agreed on the first sentence, I'm just saying that the influence of
the blocksize in that function is monotonic: with bigger sizes, equal
or worse mining centralization.
About the second sentence, yes, I could destroy Bitcoin by changing
one single constant if I could somehow force users to adopt my version
of the software. I'm sure I can actually find several examples if
necessary. "Through centralization" is harder, but say we chose
std::numeric_limits<int64_t>::max() as the maximum block size (in
practice, entirely removing the block size limit), then the consensus
rules don't have any rule to limit mining centralization.
Sacrificing that tool, and doing so this early on could certainly turn
Bitcoin into an effectively centralized system, destroying Bitcoin (or
at least the "p2p currency" part of it, which is the most interesting
one for many Bitcoin users including me).
So, once it's clear that nobody is saying that centralization depends
ONLY on the block size, can you tell us please if you think it's
useful for limiting mining centralization or not?
If you think the blocksize consensus limit does nothing to limit
centralization then there's no tradeoff to consider and you should be
consequently advocating for full removal of the limit rather than
changes towards bigger arbitrary values.
Otherwise you may want to explain why you think 8 GB is enough of a
limit to impede further centralization.

> To say once more: block size won't make much difference to how many
> merchants rely on payment processors because they aren't using them due to
> block processing overheads anyway. So trying to calculate such a formula
> won't work. Ditto for end users on phones, ditto for developers who want
> JSON/REST access to an indexed block chain, or hosted wallet services, or
> miners who want to reduce variance.

Sorry, I don't know about Pieter, but I was mostly talking about
mining centralization, certainly not about payment services.

> What people like you are Pieter are doing is making a single number a kind
> of proxy for all fears and concerns about the trend towards outsourcing in
> the Bitcoin community. Everything gets compressed down to one number you
> feel you can control, whether it is relevant or not.

No, that's not what we are doing.
It's good that you talk about your fears but, please, let other people
talk about theirs on their own.

>> > So why should anyone go through the massive hassle of setting up
>> > exchanges,
>> > without the lure of large future profits?
>>
>> Are you suggesting that bitcoin consensus rules should be designed to
>> maximize the profits of Bitcoin exchanges?
>
>
> That isn't what I said at all Jorge. Let me try again.
>
> Setting up an exchange is a lot of risky and expensive work. The motivation
> is profit, and profits are higher when there are more users to sell to. This
> is business 101.

I can imagine a non-for-profit exchange but there's no point in
finding edge cases: no general disagreement here.

> If you remove the potential for future profit, you remove the motivation to
> create the services that we now enjoy and take for granted. Because if you
> think Bitcoin can be useful without exchanges then let me tell you, I was
> around when there were none. Bitcoin was useless.

My first post on the bitcoin forums (and vague hardfork proposal, I
started reading in December 2010) was January 21, 2011 (vs yours Dec
14th 2010, as Greg pointed out in the other thread). I bought my first
bitcoins (and also sold most of them shortly after, stupid me) using
some web that used paypal and was closed down not too long after that.
At first I couldn't participate in exchanges because I had no Liberty
Reserve account...
Look, I'm sure there's many stories about how we met Bitcoin that we
can share having a beer in a bar or something. But probably most of
the subscribers to this list don't really care, and if they care they
can ask us privately, or you can create a new thread (probably better
in bitcointalk or somewhere else than here): they are completely
irrelevant in this technical discussion.

So, back on-topic: do I agree that exchanges are extremely important
for the Bitcoin ecosystem?
Yes, of course I do.
But that doesn't mean that their "potential for future profit" should
be a primary concern when deciding consensus rules changes that affect
ALL users.
But even before that, I disagree with the premise that "not rising the
consensus blocksize as soon as possible" will ruin the exchanges or
"remove their potential for future profit".

Re: [bitcoin-dev] Block size following technological growth

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 3796 bytes --]

>
> How more users or more nodes can bring more miners, or more importantly,
> improve mining decentralization?
>

Because the bigger the ecosystem is the more interest there is in taking
part?

I mean, I guess I don't know how to answer your question. When Bitcoin was
new it had almost no users and almost no miners. Now there are millions of
users and factories producing ASICs just for Bitcoin. Surely the
correlation is obvious?

I'm sorry, but until there's a simulation that I can run with different
> sizes' testchains (for example using #6382) to somehow compare them, I will
> consider any value arbitrary.
>

Gavin did run simulations. 20mb isn't arbitrary, the process behind it was
well documented here:

http://gavinandresen.ninja/does-more-transactions-necessarily-mean-more-centralized

*I chose 20MB as a reasonable block size to target because 170 gigabytes
per month comfortably fits into the typical 250-300 gigabytes per month
data cap– so you can run a full node from home on a “pretty good” broadband
plan.*
Did you think 20mb was picked randomly?


> Agreed on the first sentence, I'm just saying that the influence of
> the blocksize in that function is monotonic: with bigger sizes, equal
> or worse mining centralization.
>

I have a hard time agreeing with this because I've seen Bitcoin go from
blocks that were often empty to blocks that are often full, and in this
time the number of miners and hash power on the network has gone up a huge
amount too.

You can argue that a miner doesn't count if they pool mine. But if a miner
mines on a pool that uses exactly the same software and settings as the
miner would have done anyway, then it makes no difference. Miners can
switch between pools to find one that works the way they like, so whilst
less pooling or more decentralised pools would be nice (e.g.
getblocktemplate), and I've written about how to push it forward before, I
still say there are many more miners than in the past.

If I had to pick between two changes to improve mining decentralisation:

1) Lower block size
2) Finishing, documenting, and making the UX really slick for a
getblocktemplate based decentralised mining pool

then I'd pick (2) in a heartbeat. I think it'd be a lot more effective.


> you should be consequently advocating for full removal of the limit rather
> than changes towards bigger arbitrary values.
>

I did toy with that idea a while ago. Of course there can not really be no
limit at all because the code assumes blocks fit into RAM/swap, and nodes
would just end up ignoring blocks they couldn't download in time anyway.
There is obviously a physical limit somewhere.

But it is easier to find common ground with others by compromising. Is 8mb
better than no limit? I don't know and I don't care much:  I think Bitcoin
adoption is a slow, hard process and we'll be lucky to increase average
usage 8x over the next couple of years. So if 8mb+ is better for others,
that's OK by me.



> Sorry, I don't know about Pieter, but I was mostly talking about
> mining centralization, certainly not about payment services.
>

OK. I write these emails for other readers too :) In the past for instance,
developers who run services without running their own nodes has come up.

Re: exchange profit. You can pick some other useful service provider if you
like. Payment processors or cold storage providers or the TREZOR
manufacturers or whoever.

My point is you can't have a tiny high-value-transactions only currency AND
all the useful infrastructure that the Bitcoin community is making. It's a
contradiction. And without the infrastructure bitcoin ceases to be
interesting even to people who are willing to pay huge sums to use it.

[-- Attachment #2: Type: text/html, Size: 5180 bytes --]

Re: [bitcoin-dev] Block size following technological growth

[Venzen Khaosan]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On 07/31/2015 09:58 PM, Mike Hearn via bitcoin-dev wrote:
> How more users or more nodes can bring more miners, or more
> importantly, improve mining decentralization?
> 
> 
> Because the bigger the ecosystem is the more interest there is in
> taking part?

The logic just flows from one to the other does it? So because Islam
is the biggest religious ecosystem in the world now you and me are
just burning to take part?

By your logic, most people in Asia would horde (or want to pay using)
Chinese Yuan, only they don't. The Yuan and the Yen are the dominant
currencies of large transaction settlement in the region, but try to
use it on the street and you're met with puzzled bemusement, Mike Hearn.

Bitcoin is not suitable as a currency for pervasive dominance, and
ideals of pushing it into every heart and mind around the globe is no
different from religious zealotry.

Bitcoin has its place and we're only at the beginning of a gradual
evolution. How can I say that? Because I'm looking across the rice
paddy to where my neighbors have not adopted the innovation of the
lightbulb, and burn candles for light and cook with gas. And they're
not an anomaly around here or in Asia, Africa and South America.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVu5QvAAoJEGwAhlQc8H1m1DQH/i54c+ZBnk9tZK+0PfC2G0rT
taLpqvmXGOHPaSqkfHOLjLOm9LxGAw3TZpFIkFSuSuiSlwDfii2VIlKsbYSCEbBe
twCaZuNqam4r+61755ADrvPziPx3Tr2GXN7Zc635prN9uGoGCu58xxc7Iy8sTsrf
vB430ZN5RhagpFG5LCqN4QmDGQlK+ceYh53jLQ5HpNP/8UsOJjGXdnZfb4V24EFW
0NPAWdmWVFVpEPxqbsmAGjzOPVdocSQuRTekOQHJ7e5XNmHaD3YGHI+hwBDKzcD+
tUuFh7v4C684172PwandfJGAtUJMeavdh+IA21fze3+trrcTOVOZMHr+HEfmWGs=
=AToN
-----END PGP SIGNATURE-----

Re: [bitcoin-dev] Block size following technological growth

[Elliot Olds]

[-- Attachment #1: Type: text/plain, Size: 1340 bytes --]

On Fri, Jul 31, 2015 at 7:58 AM, Mike Hearn via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> But it is easier to find common ground with others by compromising. Is 8mb
> better than no limit? I don't know and I don't care much:
>

People seeing statements like this might imagine that if you knew a change
from 1MB blocks to 1GB blocks would ensure fees were 10 cents for the next
two years instead of 30 cents over the next two years, you'd want to roll
out 1GB blocks. Would you? Where is your cutoff? How large would you be
willing to make the block size in exchange for moving fees from 30 cents to
10 cents for the next two years? How about $3 to 10 cents? $30 to 10 cents?

How do you think Greg/Pieter/Wlad/Adam/Jorge would answer those questions?
I find it very hard to guess, but I think knowing how people would make
that specific tradeoff could be helpful in either starting a more
productive discussion, or at least realizing how far apart people are in
their weighing of the risks of large blocks vs. the benefits of low fees.

Obviously the assumption that we have this two year stability period is
unrealistic, but the hypothetical tells us how much of the disagreement
comes from "if we increase the block size to lower fees, the low fees won't
last" vs. "the low fees aren't worth it even if they last."

[-- Attachment #2: Type: text/html, Size: 2041 bytes --]

Re: [bitcoin-dev] Block size following technological growth

[Jorge Timón]

On Fri, Jul 31, 2015 at 4:58 PM, Mike Hearn <hearn@vinumeris.com> wrote:
>> How more users or more nodes can bring more miners, or more importantly,
>> improve mining decentralization?
>
>
> Because the bigger the ecosystem is the more interest there is in taking
> part?

As explained by Venzen, this is a non-sequitur.

> I mean, I guess I don't know how to answer your question.

I don't know the answer either, that's fine. It's the opposite
question that I've been insistently repeating and you've been
(consciously or not) consistently evading.
But that's also fine because I believe you finally answer it a few lines below.

> When Bitcoin was
> new it had almost no users and almost no miners. Now there are millions of
> users and factories producing ASICs just for Bitcoin.

The emergence of a btc price enabled the emergence of professional
miners, which in turn enabled the emergence of sha256d-specialized
hardware production companies.
Nothing surprising there.
By no means it consitutes an example of how a bigger consensus sizes
can cause less mining centralization.

> Surely the correlation is obvious?

Correlation does not imply causation. I will better leave it at that...

>> I'm sorry, but until there's a simulation that I can run with different
>> sizes' testchains (for example using #6382) to somehow compare them, I will
>> consider any value arbitrary.
>
>
> Gavin did run simulations. 20mb isn't arbitrary, the process behind it was
> well documented here:
>
> http://gavinandresen.ninja/does-more-transactions-necessarily-mean-more-centralized
>
> I chose 20MB as a reasonable block size to target because 170 gigabytes per
> month comfortably fits into the typical 250-300 gigabytes per month data
> cap– so you can run a full node from home on a “pretty good” broadband plan.
>
> Did you think 20mb was picked randomly?

No, I think 20 MB was chosen very optimistically, considering 3rd
party services rates (not the same service as self-hosting) in the
so-called "first world". And then 20 MB goes to 20 GB, again with
optimistic and by no means scientific expectations.

But where the number comes from it's not really what I'm demaning,
what I want is some criterion that can tell you that a given size
would be "too centralized" but another one isn't.
I haven't read any analysis on why 8GB is a better option than 7GB and
9GB for a given criterion (nor one declaring 20 GB a winner over 19 GB
or 21 GB).
A simulation test passing 20 GB but not 21 GB would make it far less arbitrary.

>> Agreed on the first sentence, I'm just saying that the influence of
>> the blocksize in that function is monotonic: with bigger sizes, equal
>> or worse mining centralization.
>
>
> I have a hard time agreeing with this because I've seen Bitcoin go from
> blocks that were often empty to blocks that are often full, and in this time
> the number of miners and hash power on the network has gone up a huge amount
> too.

I'm of course talking about consensus maximum blocksize, not about
actual blocksize.
Yes, again, when mining becomes profitable, economic actors tend to
appear and get those profits.
But don't confuse total hashrate improvements with an "increase in the
number of miners" or with mining decentralization.

> You can argue that a miner doesn't count if they pool mine. But if a miner
> mines on a pool that uses exactly the same software and settings as the
> miner would have done anyway, then it makes no difference. Miners can switch
> between pools to find one that works the way they like, so whilst less
> pooling or more decentralised pools would be nice (e.g. getblocktemplate),
> and I've written about how to push it forward before, I still say there are
> many more miners than in the past.
>
> If I had to pick between two changes to improve mining decentralisation:
>
> 1) Lower block size

Finally, I think you finally answered my repetitive question here.
If I say "Mike Hearn understands that the consensus block size maximum
rule is a tool for limitting mining centralization" I'm not putting
words in your mouth, right?
I think many users advocating for an increase in the consensus limit
don't understand this, which is extremely unfortunate for the debate.

> 2) Finishing, documenting, and making the UX really slick for a
> getblocktemplate based decentralised mining pool
>
> then I'd pick (2) in a heartbeat. I think it'd be a lot more effective.

Great! Maybe after 2 mining centralization improves so much that we're
confortable not only not lowering it but rather increasing it.

>> you should be consequently advocating for full removal of the limit rather
>> than changes towards bigger arbitrary values.
>
>
> I did toy with that idea a while ago. Of course there can not really be no
> limit at all because the code assumes blocks fit into RAM/swap, and nodes
> would just end up ignoring blocks they couldn't download in time anyway.
> There is obviously a physical limit somewhere.

Did the fact that you "understand that the consensus block size
maximum rule is a tool for limitting mining centralization" influenced
your rejection of that idea at all?

> But it is easier to find common ground with others by compromising. Is 8mb
> better than no limit? I don't know and I don't care much:  I think Bitcoin
> adoption is a slow, hard process and we'll be lucky to increase average
> usage 8x over the next couple of years. So if 8mb+ is better for others,
> that's OK by me.

The only way that "not caring much whther we have a consensus limit or
not" and "understand that the consensus block size maximum rule is a
tool for limitting mining centralization" at the same time is by not
caring about mining centralization at all.
Is that your position?

If you don't care about having a limit but you don't want to limit
transaction volume, then ++current_size will ALWAYs be your
"compromise position" and no blocksize increase will ever be enough
until the limit is completely removed.
Is that your position?

> Re: exchange profit. You can pick some other useful service provider if you
> like. Payment processors or cold storage providers or the TREZOR
> manufacturers or whoever.

Yes, and I believe the same points stand.

> My point is you can't have a tiny high-value-transactions only currency AND
> all the useful infrastructure that the Bitcoin community is making. It's a
> contradiction. And without the infrastructure bitcoin ceases to be
> interesting even to people who are willing to pay huge sums to use it.

You keep talking about "high-value-transactions-only" like if
non-urgent transaction fees rising from zero to, say, 1 satoshi, would
automatically result in that "high-value-transactions-only" Bitcoin.
Please, stop talking as if someone was proposing a
"high-value-transactions-only" Bitcoin. That may happen but nobody
really knows. If it happens it may not be bad thing necessarily (ie
bitcoin microtransactions can still happen using trustless payment
channels and x is still cheaper than x% for any transacted value
higher than 100) but that's really not what we're talking about here
so it seems distraction that can only help further polirizing this
discussion.

What we're talking about here is that hitting the limit would
(hopefully) make miners start caring about fees. Enough that they stop
being irrational about free transactions. If both things happen,
non-urgent transaction fees will likely rise (as said, above zero).

You think that would be a catastrophe for adoption and I disagree.
But (as Pieter has repeatedly explained) for any size there will be
use cases that will be eventually priced out.
So when rising this consensus limit, not increasing centralization
should be the priority and the potential impact in market fees a much
more secondary concern.
Do you agree with this?

I'm sure there are many intermediate positions between "caring more
about mining centralization than market fees when deciding about a
consensus rule that limits mining centralization" and "not caring
about mining centralization at all".
I really don't want to put words in your mouth, but I honestly don't
know what your position is.
I don't really know how else can I ask the same question: you don't
care the consensus maximum blocksize rule being here at all or not
(you just said that).
Is it because you don't think it limits mining centralization or
because you don't care about limiting mining centralization with
consensus rules at all?

Re: [bitcoin-dev] Block size following technological growth

[Hector Chu]

[-- Attachment #1: Type: text/plain, Size: 10086 bytes --]

Mike's position is that he wants the block size limit
to eventually be removed. That is of course an extreme view. Meanwhile,
your view that the block size should be artificially constrained below the
organic growth curve (in a way that will penalize a majority of existing
and future users) lies at the other extreme. The majority position lies
somewhere in between (i.e. a one-time increase to 8MB). This is the
position that ultimately matters.

If the block size is increased to 8MB and things get demonstrably a whole
lot worse, then you will have a solid leg to stand on. In that case we can
always do another hard fork later to reduce the block size back to
something smaller, and henceforth the block size will never be touched
again.

On 4 August 2015 at 11:35, Jorge Timón <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Fri, Jul 31, 2015 at 4:58 PM, Mike Hearn <hearn@vinumeris.com> wrote:
> >> How more users or more nodes can bring more miners, or more importantly,
> >> improve mining decentralization?
> >
> >
> > Because the bigger the ecosystem is the more interest there is in taking
> > part?
>
> As explained by Venzen, this is a non-sequitur.
>
> > I mean, I guess I don't know how to answer your question.
>
> I don't know the answer either, that's fine. It's the opposite
> question that I've been insistently repeating and you've been
> (consciously or not) consistently evading.
> But that's also fine because I believe you finally answer it a few lines
> below.
>
> > When Bitcoin was
> > new it had almost no users and almost no miners. Now there are millions
> of
> > users and factories producing ASICs just for Bitcoin.
>
> The emergence of a btc price enabled the emergence of professional
> miners, which in turn enabled the emergence of sha256d-specialized
> hardware production companies.
> Nothing surprising there.
> By no means it consitutes an example of how a bigger consensus sizes
> can cause less mining centralization.
>
> > Surely the correlation is obvious?
>
> Correlation does not imply causation. I will better leave it at that...
>
> >> I'm sorry, but until there's a simulation that I can run with different
> >> sizes' testchains (for example using #6382) to somehow compare them, I
> will
> >> consider any value arbitrary.
> >
> >
> > Gavin did run simulations. 20mb isn't arbitrary, the process behind it
> was
> > well documented here:
> >
> >
> http://gavinandresen.ninja/does-more-transactions-necessarily-mean-more-centralized
> >
> > I chose 20MB as a reasonable block size to target because 170 gigabytes
> per
> > month comfortably fits into the typical 250-300 gigabytes per month data
> > cap– so you can run a full node from home on a “pretty good” broadband
> plan.
> >
> > Did you think 20mb was picked randomly?
>
> No, I think 20 MB was chosen very optimistically, considering 3rd
> party services rates (not the same service as self-hosting) in the
> so-called "first world". And then 20 MB goes to 20 GB, again with
> optimistic and by no means scientific expectations.
>
> But where the number comes from it's not really what I'm demaning,
> what I want is some criterion that can tell you that a given size
> would be "too centralized" but another one isn't.
> I haven't read any analysis on why 8GB is a better option than 7GB and
> 9GB for a given criterion (nor one declaring 20 GB a winner over 19 GB
> or 21 GB).
> A simulation test passing 20 GB but not 21 GB would make it far less
> arbitrary.
>
> >> Agreed on the first sentence, I'm just saying that the influence of
> >> the blocksize in that function is monotonic: with bigger sizes, equal
> >> or worse mining centralization.
> >
> >
> > I have a hard time agreeing with this because I've seen Bitcoin go from
> > blocks that were often empty to blocks that are often full, and in this
> time
> > the number of miners and hash power on the network has gone up a huge
> amount
> > too.
>
> I'm of course talking about consensus maximum blocksize, not about
> actual blocksize.
> Yes, again, when mining becomes profitable, economic actors tend to
> appear and get those profits.
> But don't confuse total hashrate improvements with an "increase in the
> number of miners" or with mining decentralization.
>
> > You can argue that a miner doesn't count if they pool mine. But if a
> miner
> > mines on a pool that uses exactly the same software and settings as the
> > miner would have done anyway, then it makes no difference. Miners can
> switch
> > between pools to find one that works the way they like, so whilst less
> > pooling or more decentralised pools would be nice (e.g.
> getblocktemplate),
> > and I've written about how to push it forward before, I still say there
> are
> > many more miners than in the past.
> >
> > If I had to pick between two changes to improve mining decentralisation:
> >
> > 1) Lower block size
>
> Finally, I think you finally answered my repetitive question here.
> If I say "Mike Hearn understands that the consensus block size maximum
> rule is a tool for limitting mining centralization" I'm not putting
> words in your mouth, right?
> I think many users advocating for an increase in the consensus limit
> don't understand this, which is extremely unfortunate for the debate.
>
> > 2) Finishing, documenting, and making the UX really slick for a
> > getblocktemplate based decentralised mining pool
> >
> > then I'd pick (2) in a heartbeat. I think it'd be a lot more effective.
>
> Great! Maybe after 2 mining centralization improves so much that we're
> confortable not only not lowering it but rather increasing it.
>
> >> you should be consequently advocating for full removal of the limit
> rather
> >> than changes towards bigger arbitrary values.
> >
> >
> > I did toy with that idea a while ago. Of course there can not really be
> no
> > limit at all because the code assumes blocks fit into RAM/swap, and nodes
> > would just end up ignoring blocks they couldn't download in time anyway.
> > There is obviously a physical limit somewhere.
>
> Did the fact that you "understand that the consensus block size
> maximum rule is a tool for limitting mining centralization" influenced
> your rejection of that idea at all?
>
> > But it is easier to find common ground with others by compromising. Is
> 8mb
> > better than no limit? I don't know and I don't care much:  I think
> Bitcoin
> > adoption is a slow, hard process and we'll be lucky to increase average
> > usage 8x over the next couple of years. So if 8mb+ is better for others,
> > that's OK by me.
>
> The only way that "not caring much whther we have a consensus limit or
> not" and "understand that the consensus block size maximum rule is a
> tool for limitting mining centralization" at the same time is by not
> caring about mining centralization at all.
> Is that your position?
>
> If you don't care about having a limit but you don't want to limit
> transaction volume, then ++current_size will ALWAYs be your
> "compromise position" and no blocksize increase will ever be enough
> until the limit is completely removed.
> Is that your position?
>
> > Re: exchange profit. You can pick some other useful service provider if
> you
> > like. Payment processors or cold storage providers or the TREZOR
> > manufacturers or whoever.
>
> Yes, and I believe the same points stand.
>
> > My point is you can't have a tiny high-value-transactions only currency
> AND
> > all the useful infrastructure that the Bitcoin community is making. It's
> a
> > contradiction. And without the infrastructure bitcoin ceases to be
> > interesting even to people who are willing to pay huge sums to use it.
>
> You keep talking about "high-value-transactions-only" like if
> non-urgent transaction fees rising from zero to, say, 1 satoshi, would
> automatically result in that "high-value-transactions-only" Bitcoin.
> Please, stop talking as if someone was proposing a
> "high-value-transactions-only" Bitcoin. That may happen but nobody
> really knows. If it happens it may not be bad thing necessarily (ie
> bitcoin microtransactions can still happen using trustless payment
> channels and x is still cheaper than x% for any transacted value
> higher than 100) but that's really not what we're talking about here
> so it seems distraction that can only help further polirizing this
> discussion.
>
> What we're talking about here is that hitting the limit would
> (hopefully) make miners start caring about fees. Enough that they stop
> being irrational about free transactions. If both things happen,
> non-urgent transaction fees will likely rise (as said, above zero).
>
> You think that would be a catastrophe for adoption and I disagree.
> But (as Pieter has repeatedly explained) for any size there will be
> use cases that will be eventually priced out.
> So when rising this consensus limit, not increasing centralization
> should be the priority and the potential impact in market fees a much
> more secondary concern.
> Do you agree with this?
>
> I'm sure there are many intermediate positions between "caring more
> about mining centralization than market fees when deciding about a
> consensus rule that limits mining centralization" and "not caring
> about mining centralization at all".
> I really don't want to put words in your mouth, but I honestly don't
> know what your position is.
> I don't really know how else can I ask the same question: you don't
> care the consensus maximum blocksize rule being here at all or not
> (you just said that).
> Is it because you don't think it limits mining centralization or
> because you don't care about limiting mining centralization with
> consensus rules at all?
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 11959 bytes --]

Re: [bitcoin-dev] Block size following technological growth

[Pieter Wuille]

[-- Attachment #1: Type: text/plain, Size: 11600 bytes --]

I would say that things already demonstrately got terrible. The mining
landscape is very centralized, with apparently a majority depending on
agreements to trust each other's announced blocks without validation. Full
node count is at its historically lowest value in years, and outsourcing of
full validation keeps growing.

I believe that if the above would have happened overnight, people would
have cried wolf. But somehow it happened slow enough, and "things kept
working".

I don't think that this is a good criterion. Bitcoin can "work" with
gigabyte blocks today, if everyone uses the same few blockchain validation
services, the same few online wallets, and mining is done by a cartel that
only allows joining after signing a contract so they can sue you if you
create an invalid block. Do you think people will then agree that "things
got demonstratebly worse"?

Don't turn Bitcoin into something uninteresting, please.

-- 
Pieter
On Aug 4, 2015 1:04 PM, "Hector Chu via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Mike's position is that he wants the block size limit
> to eventually be removed. That is of course an extreme view. Meanwhile,
> your view that the block size should be artificially constrained below the
> organic growth curve (in a way that will penalize a majority of existing
> and future users) lies at the other extreme. The majority position lies
> somewhere in between (i.e. a one-time increase to 8MB). This is the
> position that ultimately matters.
>
> If the block size is increased to 8MB and things get demonstrably a whole
> lot worse, then you will have a solid leg to stand on. In that case we can
> always do another hard fork later to reduce the block size back to
> something smaller, and henceforth the block size will never be touched
> again.
>
> On 4 August 2015 at 11:35, Jorge Timón <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> On Fri, Jul 31, 2015 at 4:58 PM, Mike Hearn <hearn@vinumeris.com> wrote:
>> >> How more users or more nodes can bring more miners, or more
>> importantly,
>> >> improve mining decentralization?
>> >
>> >
>> > Because the bigger the ecosystem is the more interest there is in taking
>> > part?
>>
>> As explained by Venzen, this is a non-sequitur.
>>
>> > I mean, I guess I don't know how to answer your question.
>>
>> I don't know the answer either, that's fine. It's the opposite
>> question that I've been insistently repeating and you've been
>> (consciously or not) consistently evading.
>> But that's also fine because I believe you finally answer it a few lines
>> below.
>>
>> > When Bitcoin was
>> > new it had almost no users and almost no miners. Now there are millions
>> of
>> > users and factories producing ASICs just for Bitcoin.
>>
>> The emergence of a btc price enabled the emergence of professional
>> miners, which in turn enabled the emergence of sha256d-specialized
>> hardware production companies.
>> Nothing surprising there.
>> By no means it consitutes an example of how a bigger consensus sizes
>> can cause less mining centralization.
>>
>> > Surely the correlation is obvious?
>>
>> Correlation does not imply causation. I will better leave it at that...
>>
>> >> I'm sorry, but until there's a simulation that I can run with different
>> >> sizes' testchains (for example using #6382) to somehow compare them, I
>> will
>> >> consider any value arbitrary.
>> >
>> >
>> > Gavin did run simulations. 20mb isn't arbitrary, the process behind it
>> was
>> > well documented here:
>> >
>> >
>> http://gavinandresen.ninja/does-more-transactions-necessarily-mean-more-centralized
>> >
>> > I chose 20MB as a reasonable block size to target because 170 gigabytes
>> per
>> > month comfortably fits into the typical 250-300 gigabytes per month data
>> > cap– so you can run a full node from home on a “pretty good” broadband
>> plan.
>> >
>> > Did you think 20mb was picked randomly?
>>
>> No, I think 20 MB was chosen very optimistically, considering 3rd
>> party services rates (not the same service as self-hosting) in the
>> so-called "first world". And then 20 MB goes to 20 GB, again with
>> optimistic and by no means scientific expectations.
>>
>> But where the number comes from it's not really what I'm demaning,
>> what I want is some criterion that can tell you that a given size
>> would be "too centralized" but another one isn't.
>> I haven't read any analysis on why 8GB is a better option than 7GB and
>> 9GB for a given criterion (nor one declaring 20 GB a winner over 19 GB
>> or 21 GB).
>> A simulation test passing 20 GB but not 21 GB would make it far less
>> arbitrary.
>>
>> >> Agreed on the first sentence, I'm just saying that the influence of
>> >> the blocksize in that function is monotonic: with bigger sizes, equal
>> >> or worse mining centralization.
>> >
>> >
>> > I have a hard time agreeing with this because I've seen Bitcoin go from
>> > blocks that were often empty to blocks that are often full, and in this
>> time
>> > the number of miners and hash power on the network has gone up a huge
>> amount
>> > too.
>>
>> I'm of course talking about consensus maximum blocksize, not about
>> actual blocksize.
>> Yes, again, when mining becomes profitable, economic actors tend to
>> appear and get those profits.
>> But don't confuse total hashrate improvements with an "increase in the
>> number of miners" or with mining decentralization.
>>
>> > You can argue that a miner doesn't count if they pool mine. But if a
>> miner
>> > mines on a pool that uses exactly the same software and settings as the
>> > miner would have done anyway, then it makes no difference. Miners can
>> switch
>> > between pools to find one that works the way they like, so whilst less
>> > pooling or more decentralised pools would be nice (e.g.
>> getblocktemplate),
>> > and I've written about how to push it forward before, I still say there
>> are
>> > many more miners than in the past.
>> >
>> > If I had to pick between two changes to improve mining decentralisation:
>> >
>> > 1) Lower block size
>>
>> Finally, I think you finally answered my repetitive question here.
>> If I say "Mike Hearn understands that the consensus block size maximum
>> rule is a tool for limitting mining centralization" I'm not putting
>> words in your mouth, right?
>> I think many users advocating for an increase in the consensus limit
>> don't understand this, which is extremely unfortunate for the debate.
>>
>> > 2) Finishing, documenting, and making the UX really slick for a
>> > getblocktemplate based decentralised mining pool
>> >
>> > then I'd pick (2) in a heartbeat. I think it'd be a lot more effective.
>>
>> Great! Maybe after 2 mining centralization improves so much that we're
>> confortable not only not lowering it but rather increasing it.
>>
>> >> you should be consequently advocating for full removal of the limit
>> rather
>> >> than changes towards bigger arbitrary values.
>> >
>> >
>> > I did toy with that idea a while ago. Of course there can not really be
>> no
>> > limit at all because the code assumes blocks fit into RAM/swap, and
>> nodes
>> > would just end up ignoring blocks they couldn't download in time anyway.
>> > There is obviously a physical limit somewhere.
>>
>> Did the fact that you "understand that the consensus block size
>> maximum rule is a tool for limitting mining centralization" influenced
>> your rejection of that idea at all?
>>
>> > But it is easier to find common ground with others by compromising. Is
>> 8mb
>> > better than no limit? I don't know and I don't care much:  I think
>> Bitcoin
>> > adoption is a slow, hard process and we'll be lucky to increase average
>> > usage 8x over the next couple of years. So if 8mb+ is better for others,
>> > that's OK by me.
>>
>> The only way that "not caring much whther we have a consensus limit or
>> not" and "understand that the consensus block size maximum rule is a
>> tool for limitting mining centralization" at the same time is by not
>> caring about mining centralization at all.
>> Is that your position?
>>
>> If you don't care about having a limit but you don't want to limit
>> transaction volume, then ++current_size will ALWAYs be your
>> "compromise position" and no blocksize increase will ever be enough
>> until the limit is completely removed.
>> Is that your position?
>>
>> > Re: exchange profit. You can pick some other useful service provider if
>> you
>> > like. Payment processors or cold storage providers or the TREZOR
>> > manufacturers or whoever.
>>
>> Yes, and I believe the same points stand.
>>
>> > My point is you can't have a tiny high-value-transactions only currency
>> AND
>> > all the useful infrastructure that the Bitcoin community is making.
>> It's a
>> > contradiction. And without the infrastructure bitcoin ceases to be
>> > interesting even to people who are willing to pay huge sums to use it.
>>
>> You keep talking about "high-value-transactions-only" like if
>> non-urgent transaction fees rising from zero to, say, 1 satoshi, would
>> automatically result in that "high-value-transactions-only" Bitcoin.
>> Please, stop talking as if someone was proposing a
>> "high-value-transactions-only" Bitcoin. That may happen but nobody
>> really knows. If it happens it may not be bad thing necessarily (ie
>> bitcoin microtransactions can still happen using trustless payment
>> channels and x is still cheaper than x% for any transacted value
>> higher than 100) but that's really not what we're talking about here
>> so it seems distraction that can only help further polirizing this
>> discussion.
>>
>> What we're talking about here is that hitting the limit would
>> (hopefully) make miners start caring about fees. Enough that they stop
>> being irrational about free transactions. If both things happen,
>> non-urgent transaction fees will likely rise (as said, above zero).
>>
>> You think that would be a catastrophe for adoption and I disagree.
>> But (as Pieter has repeatedly explained) for any size there will be
>> use cases that will be eventually priced out.
>> So when rising this consensus limit, not increasing centralization
>> should be the priority and the potential impact in market fees a much
>> more secondary concern.
>> Do you agree with this?
>>
>> I'm sure there are many intermediate positions between "caring more
>> about mining centralization than market fees when deciding about a
>> consensus rule that limits mining centralization" and "not caring
>> about mining centralization at all".
>> I really don't want to put words in your mouth, but I honestly don't
>> know what your position is.
>> I don't really know how else can I ask the same question: you don't
>> care the consensus maximum blocksize rule being here at all or not
>> (you just said that).
>> Is it because you don't think it limits mining centralization or
>> because you don't care about limiting mining centralization with
>> consensus rules at all?
>> _______________________________________________
>> 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
>
>

[-- Attachment #2: Type: text/html, Size: 13653 bytes --]

Re: [bitcoin-dev] Block size following technological growth

[Hector Chu]

[-- Attachment #1: Type: text/plain, Size: 12375 bytes --]

Things apparently aren't bad enough to prevent the majority from clamoring
for larger blocks.

If the majority agreed that things had got worse till this point, and that
this was to be blamed on the block size, they would be campaigning for the
other direction. Even yourselves aren't asking for a reduction in the block
size, as you know full well that you would be laughed out.

On 4 August 2015 at 12:27, Pieter Wuille <pieter.wuille@gmail.com> wrote:

> I would say that things already demonstrately got terrible. The mining
> landscape is very centralized, with apparently a majority depending on
> agreements to trust each other's announced blocks without validation. Full
> node count is at its historically lowest value in years, and outsourcing of
> full validation keeps growing.
>
> I believe that if the above would have happened overnight, people would
> have cried wolf. But somehow it happened slow enough, and "things kept
> working".
>
> I don't think that this is a good criterion. Bitcoin can "work" with
> gigabyte blocks today, if everyone uses the same few blockchain validation
> services, the same few online wallets, and mining is done by a cartel that
> only allows joining after signing a contract so they can sue you if you
> create an invalid block. Do you think people will then agree that "things
> got demonstratebly worse"?
>
> Don't turn Bitcoin into something uninteresting, please.
>
> --
> Pieter
> On Aug 4, 2015 1:04 PM, "Hector Chu via bitcoin-dev" <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Mike's position is that he wants the block size limit
>> to eventually be removed. That is of course an extreme view. Meanwhile,
>> your view that the block size should be artificially constrained below the
>> organic growth curve (in a way that will penalize a majority of existing
>> and future users) lies at the other extreme. The majority position lies
>> somewhere in between (i.e. a one-time increase to 8MB). This is the
>> position that ultimately matters.
>>
>> If the block size is increased to 8MB and things get demonstrably a whole
>> lot worse, then you will have a solid leg to stand on. In that case we can
>> always do another hard fork later to reduce the block size back to
>> something smaller, and henceforth the block size will never be touched
>> again.
>>
>> On 4 August 2015 at 11:35, Jorge Timón <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> On Fri, Jul 31, 2015 at 4:58 PM, Mike Hearn <hearn@vinumeris.com> wrote:
>>> >> How more users or more nodes can bring more miners, or more
>>> importantly,
>>> >> improve mining decentralization?
>>> >
>>> >
>>> > Because the bigger the ecosystem is the more interest there is in
>>> taking
>>> > part?
>>>
>>> As explained by Venzen, this is a non-sequitur.
>>>
>>> > I mean, I guess I don't know how to answer your question.
>>>
>>> I don't know the answer either, that's fine. It's the opposite
>>> question that I've been insistently repeating and you've been
>>> (consciously or not) consistently evading.
>>> But that's also fine because I believe you finally answer it a few lines
>>> below.
>>>
>>> > When Bitcoin was
>>> > new it had almost no users and almost no miners. Now there are
>>> millions of
>>> > users and factories producing ASICs just for Bitcoin.
>>>
>>> The emergence of a btc price enabled the emergence of professional
>>> miners, which in turn enabled the emergence of sha256d-specialized
>>> hardware production companies.
>>> Nothing surprising there.
>>> By no means it consitutes an example of how a bigger consensus sizes
>>> can cause less mining centralization.
>>>
>>> > Surely the correlation is obvious?
>>>
>>> Correlation does not imply causation. I will better leave it at that...
>>>
>>> >> I'm sorry, but until there's a simulation that I can run with
>>> different
>>> >> sizes' testchains (for example using #6382) to somehow compare them,
>>> I will
>>> >> consider any value arbitrary.
>>> >
>>> >
>>> > Gavin did run simulations. 20mb isn't arbitrary, the process behind it
>>> was
>>> > well documented here:
>>> >
>>> >
>>> http://gavinandresen.ninja/does-more-transactions-necessarily-mean-more-centralized
>>> >
>>> > I chose 20MB as a reasonable block size to target because 170
>>> gigabytes per
>>> > month comfortably fits into the typical 250-300 gigabytes per month
>>> data
>>> > cap– so you can run a full node from home on a “pretty good” broadband
>>> plan.
>>> >
>>> > Did you think 20mb was picked randomly?
>>>
>>> No, I think 20 MB was chosen very optimistically, considering 3rd
>>> party services rates (not the same service as self-hosting) in the
>>> so-called "first world". And then 20 MB goes to 20 GB, again with
>>> optimistic and by no means scientific expectations.
>>>
>>> But where the number comes from it's not really what I'm demaning,
>>> what I want is some criterion that can tell you that a given size
>>> would be "too centralized" but another one isn't.
>>> I haven't read any analysis on why 8GB is a better option than 7GB and
>>> 9GB for a given criterion (nor one declaring 20 GB a winner over 19 GB
>>> or 21 GB).
>>> A simulation test passing 20 GB but not 21 GB would make it far less
>>> arbitrary.
>>>
>>> >> Agreed on the first sentence, I'm just saying that the influence of
>>> >> the blocksize in that function is monotonic: with bigger sizes, equal
>>> >> or worse mining centralization.
>>> >
>>> >
>>> > I have a hard time agreeing with this because I've seen Bitcoin go from
>>> > blocks that were often empty to blocks that are often full, and in
>>> this time
>>> > the number of miners and hash power on the network has gone up a huge
>>> amount
>>> > too.
>>>
>>> I'm of course talking about consensus maximum blocksize, not about
>>> actual blocksize.
>>> Yes, again, when mining becomes profitable, economic actors tend to
>>> appear and get those profits.
>>> But don't confuse total hashrate improvements with an "increase in the
>>> number of miners" or with mining decentralization.
>>>
>>> > You can argue that a miner doesn't count if they pool mine. But if a
>>> miner
>>> > mines on a pool that uses exactly the same software and settings as the
>>> > miner would have done anyway, then it makes no difference. Miners can
>>> switch
>>> > between pools to find one that works the way they like, so whilst less
>>> > pooling or more decentralised pools would be nice (e.g.
>>> getblocktemplate),
>>> > and I've written about how to push it forward before, I still say
>>> there are
>>> > many more miners than in the past.
>>> >
>>> > If I had to pick between two changes to improve mining
>>> decentralisation:
>>> >
>>> > 1) Lower block size
>>>
>>> Finally, I think you finally answered my repetitive question here.
>>> If I say "Mike Hearn understands that the consensus block size maximum
>>> rule is a tool for limitting mining centralization" I'm not putting
>>> words in your mouth, right?
>>> I think many users advocating for an increase in the consensus limit
>>> don't understand this, which is extremely unfortunate for the debate.
>>>
>>> > 2) Finishing, documenting, and making the UX really slick for a
>>> > getblocktemplate based decentralised mining pool
>>> >
>>> > then I'd pick (2) in a heartbeat. I think it'd be a lot more effective.
>>>
>>> Great! Maybe after 2 mining centralization improves so much that we're
>>> confortable not only not lowering it but rather increasing it.
>>>
>>> >> you should be consequently advocating for full removal of the limit
>>> rather
>>> >> than changes towards bigger arbitrary values.
>>> >
>>> >
>>> > I did toy with that idea a while ago. Of course there can not really
>>> be no
>>> > limit at all because the code assumes blocks fit into RAM/swap, and
>>> nodes
>>> > would just end up ignoring blocks they couldn't download in time
>>> anyway.
>>> > There is obviously a physical limit somewhere.
>>>
>>> Did the fact that you "understand that the consensus block size
>>> maximum rule is a tool for limitting mining centralization" influenced
>>> your rejection of that idea at all?
>>>
>>> > But it is easier to find common ground with others by compromising. Is
>>> 8mb
>>> > better than no limit? I don't know and I don't care much:  I think
>>> Bitcoin
>>> > adoption is a slow, hard process and we'll be lucky to increase average
>>> > usage 8x over the next couple of years. So if 8mb+ is better for
>>> others,
>>> > that's OK by me.
>>>
>>> The only way that "not caring much whther we have a consensus limit or
>>> not" and "understand that the consensus block size maximum rule is a
>>> tool for limitting mining centralization" at the same time is by not
>>> caring about mining centralization at all.
>>> Is that your position?
>>>
>>> If you don't care about having a limit but you don't want to limit
>>> transaction volume, then ++current_size will ALWAYs be your
>>> "compromise position" and no blocksize increase will ever be enough
>>> until the limit is completely removed.
>>> Is that your position?
>>>
>>> > Re: exchange profit. You can pick some other useful service provider
>>> if you
>>> > like. Payment processors or cold storage providers or the TREZOR
>>> > manufacturers or whoever.
>>>
>>> Yes, and I believe the same points stand.
>>>
>>> > My point is you can't have a tiny high-value-transactions only
>>> currency AND
>>> > all the useful infrastructure that the Bitcoin community is making.
>>> It's a
>>> > contradiction. And without the infrastructure bitcoin ceases to be
>>> > interesting even to people who are willing to pay huge sums to use it.
>>>
>>> You keep talking about "high-value-transactions-only" like if
>>> non-urgent transaction fees rising from zero to, say, 1 satoshi, would
>>> automatically result in that "high-value-transactions-only" Bitcoin.
>>> Please, stop talking as if someone was proposing a
>>> "high-value-transactions-only" Bitcoin. That may happen but nobody
>>> really knows. If it happens it may not be bad thing necessarily (ie
>>> bitcoin microtransactions can still happen using trustless payment
>>> channels and x is still cheaper than x% for any transacted value
>>> higher than 100) but that's really not what we're talking about here
>>> so it seems distraction that can only help further polirizing this
>>> discussion.
>>>
>>> What we're talking about here is that hitting the limit would
>>> (hopefully) make miners start caring about fees. Enough that they stop
>>> being irrational about free transactions. If both things happen,
>>> non-urgent transaction fees will likely rise (as said, above zero).
>>>
>>> You think that would be a catastrophe for adoption and I disagree.
>>> But (as Pieter has repeatedly explained) for any size there will be
>>> use cases that will be eventually priced out.
>>> So when rising this consensus limit, not increasing centralization
>>> should be the priority and the potential impact in market fees a much
>>> more secondary concern.
>>> Do you agree with this?
>>>
>>> I'm sure there are many intermediate positions between "caring more
>>> about mining centralization than market fees when deciding about a
>>> consensus rule that limits mining centralization" and "not caring
>>> about mining centralization at all".
>>> I really don't want to put words in your mouth, but I honestly don't
>>> know what your position is.
>>> I don't really know how else can I ask the same question: you don't
>>> care the consensus maximum blocksize rule being here at all or not
>>> (you just said that).
>>> Is it because you don't think it limits mining centralization or
>>> because you don't care about limiting mining centralization with
>>> consensus rules at all?
>>> _______________________________________________
>>> 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
>>
>>

[-- Attachment #2: Type: text/html, Size: 14576 bytes --]

Re: [bitcoin-dev] Block size following technological growth

[Venzen Khaosan]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On 08/04/2015 06:34 PM, Hector Chu via bitcoin-dev wrote:
> Things apparently aren't bad enough to prevent the majority from 
> clamoring for larger blocks.
> 
> If the majority agreed that things had got worse till this point, 
> and that this was to be blamed on the block size, they would be 
> campaigning for the other direction. Even yourselves aren't asking 
> for a reduction in the block size, as you know full well that you 
> would be laughed out.
> 

Hector, if you could provide data that convinces why 8MB is better
than 6.18MB or 1MB then we'd get out of the realm of opinion and
pointless rhetoric that threatens to keep this debate in a quagmire.
We'd have actual figures to work with and projections to go by.

But fetching "majority" agreement (where from?) does not cut it for
setting Bitcoin on a future path. If we go by that then we'd soon be
giving coinbase rewards to users for being "loyal supporters" because,
as a majority, they think that's what they'd like to see.

If a proposal is demonstrably, and provably, a good idea - and a
developer consensus agrees - then it should go to testing, and
eventually, code. Other than that it's just conjecture and words
without a research paper and data.

In the final analysis, do we want Bitcoin to be steered by an
uninformed and fickle majority, or do we want to use this list as a
forum to present research proposals containing repeatable, verifiable
facts? A progressive process of convincing those most familiar with
Bitcoin's code and operation so they may implement Good Ideas during
the next century and after is surely preferable to Vote-my-code-Coin. :)


> On 4 August 2015 at 12:27, Pieter Wuille <pieter.wuille@gmail.com 
> <mailto:pieter.wuille@gmail.com>> wrote:
> 
> I would say that things already demonstrately got terrible. The 
> mining landscape is very centralized, with apparently a majority 
> depending on agreements to trust each other's announced blocks 
> without validation. Full node count is at its historically lowest 
> value in years, and outsourcing of full validation keeps growing.
> 
> I believe that if the above would have happened overnight, people 
> would have cried wolf. But somehow it happened slow enough, and 
> "things kept working".
> 
> I don't think that this is a good criterion. Bitcoin can "work" 
> with gigabyte blocks today, if everyone uses the same few 
> blockchain validation services, the same few online wallets, and 
> mining is done by a cartel that only allows joining after signing
> a contract so they can sue you if you create an invalid block. Do
> you think people will then agree that "things got demonstratebly 
> worse"?
> 
> Don't turn Bitcoin into something uninteresting, please.
> 
> -- Pieter
> 
> On Aug 4, 2015 1:04 PM, "Hector Chu via bitcoin-dev" 
> <bitcoin-dev@lists.linuxfoundation.org 
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
> 
> Mike's position is that he wants the block size limit to
> eventually be removed. That is of course an extreme view.
> Meanwhile, your view that the block size should be artificially
> constrained below the organic growth curve (in a way that will
> penalize a majority of existing and future users) lies at the other
> extreme. The majority position lies somewhere in between (i.e. a
> one-time increase to 8MB). This is the position that ultimately
> matters.
> 
> If the block size is increased to 8MB and things get demonstrably
> a whole lot worse, then you will have a solid leg to stand on. In 
> that case we can always do another hard fork later to reduce the 
> block size back to something smaller, and henceforth the block
> size will never be touched again.
> 
> On 4 August 2015 at 11:35, Jorge Timón 
> <bitcoin-dev@lists.linuxfoundation.org 
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
> 
> On Fri, Jul 31, 2015 at 4:58 PM, Mike Hearn <hearn@vinumeris.com 
> <mailto:hearn@vinumeris.com>> wrote:
>>> How more users or more nodes can bring more miners, or more 
>>> importantly, improve mining decentralization?
>> 
>> 
>> Because the bigger the ecosystem is the more interest there is
>> in taking part?
> 
> As explained by Venzen, this is a non-sequitur.
> 
>> I mean, I guess I don't know how to answer your question.
> 
> I don't know the answer either, that's fine. It's the opposite 
> question that I've been insistently repeating and you've been 
> (consciously or not) consistently evading. But that's also fine 
> because I believe you finally answer it a few lines below.
> 
>> When Bitcoin was new it had almost no users and almost no
>> miners. Now there are millions of users and factories producing
>> ASICs just for Bitcoin.
> 
> The emergence of a btc price enabled the emergence of professional
>  miners, which in turn enabled the emergence of sha256d-specialized
>  hardware production companies. Nothing surprising there. By no 
> means it consitutes an example of how a bigger consensus sizes can 
> cause less mining centralization.
> 
>> Surely the correlation is obvious?
> 
> Correlation does not imply causation. I will better leave it at 
> that...
> 
>>> I'm sorry, but until there's a simulation that I can run with 
>>> different sizes' testchains (for example using #6382) to 
>>> somehow compare them, I will consider any value arbitrary.
>> 
>> 
>> Gavin did run simulations. 20mb isn't arbitrary, the process 
>> behind it was well documented here:
>> 
>> http://gavinandresen.ninja/does-more-transactions-necessarily-mean-more-centralized
>
>>
>> 
> 
>> I chose 20MB as a reasonable block size to target because 170 
>> gigabytes per month comfortably fits into the typical 250-300 
>> gigabytes per month data cap– so you can run a full node from 
>> home on a “pretty good” broadband plan.
>> 
>> Did you think 20mb was picked randomly?
> 
> No, I think 20 MB was chosen very optimistically, considering 3rd 
> party services rates (not the same service as self-hosting) in the
>  so-called "first world". And then 20 MB goes to 20 GB, again with
>  optimistic and by no means scientific expectations.
> 
> But where the number comes from it's not really what I'm demaning,
>  what I want is some criterion that can tell you that a given size
>  would be "too centralized" but another one isn't. I haven't read 
> any analysis on why 8GB is a better option than 7GB and 9GB for a 
> given criterion (nor one declaring 20 GB a winner over 19 GB or 21 
> GB). A simulation test passing 20 GB but not 21 GB would make it 
> far less arbitrary.
> 
>>> Agreed on the first sentence, I'm just saying that the 
>>> influence of the blocksize in that function is monotonic: with 
>>> bigger sizes, equal or worse mining centralization.
>> 
>> 
>> I have a hard time agreeing with this because I've seen Bitcoin 
>> go from blocks that were often empty to blocks that are often 
>> full, and in this time the number of miners and hash power on
>> the network has gone up a huge amount too.
> 
> I'm of course talking about consensus maximum blocksize, not about
>  actual blocksize. Yes, again, when mining becomes profitable, 
> economic actors tend to appear and get those profits. But don't 
> confuse total hashrate improvements with an "increase in the
> number of miners" or with mining decentralization.
> 
>> You can argue that a miner doesn't count if they pool mine. But 
>> if a miner mines on a pool that uses exactly the same software 
>> and settings as the miner would have done anyway, then it makes 
>> no difference. Miners can switch between pools to find one that 
>> works the way they like, so whilst less pooling or more 
>> decentralised pools would be nice (e.g. getblocktemplate), and 
>> I've written about how to push it forward before, I still say 
>> there are many more miners than in the past.
>> 
>> If I had to pick between two changes to improve mining 
>> decentralisation:
>> 
>> 1) Lower block size
> 
> Finally, I think you finally answered my repetitive question here.
>  If I say "Mike Hearn understands that the consensus block size 
> maximum rule is a tool for limitting mining centralization" I'm not
> putting words in your mouth, right? I think many users advocating
> for an increase in the consensus limit don't understand this, which
> is extremely unfortunate for the debate.
> 
>> 2) Finishing, documenting, and making the UX really slick for a 
>> getblocktemplate based decentralised mining pool
>> 
>> then I'd pick (2) in a heartbeat. I think it'd be a lot more 
>> effective.
> 
> Great! Maybe after 2 mining centralization improves so much that 
> we're confortable not only not lowering it but rather increasing 
> it.
> 
>>> you should be consequently advocating for full removal of the 
>>> limit rather than changes towards bigger arbitrary values.
>> 
>> 
>> I did toy with that idea a while ago. Of course there can not 
>> really be no limit at all because the code assumes blocks fit 
>> into RAM/swap, and nodes would just end up ignoring blocks they 
>> couldn't download in time anyway. There is obviously a physical 
>> limit somewhere.
> 
> Did the fact that you "understand that the consensus block size 
> maximum rule is a tool for limitting mining centralization" 
> influenced your rejection of that idea at all?
> 
>> But it is easier to find common ground with others by 
>> compromising. Is 8mb better than no limit? I don't know and I 
>> don't care much:  I think Bitcoin adoption is a slow, hard 
>> process and we'll be lucky to increase average usage 8x over the 
>> next couple of years. So if 8mb+ is better for others, that's OK 
>> by me.
> 
> The only way that "not caring much whther we have a consensus
> limit or not" and "understand that the consensus block size maximum
> rule is a tool for limitting mining centralization" at the same
> time is by not caring about mining centralization at all. Is that
> your position?
> 
> If you don't care about having a limit but you don't want to limit
>  transaction volume, then ++current_size will ALWAYs be your 
> "compromise position" and no blocksize increase will ever be enough
> until the limit is completely removed. Is that your position?
> 
>> Re: exchange profit. You can pick some other useful service 
>> provider if you like. Payment processors or cold storage 
>> providers or the TREZOR manufacturers or whoever.
> 
> Yes, and I believe the same points stand.
> 
>> My point is you can't have a tiny high-value-transactions only 
>> currency AND all the useful infrastructure that the Bitcoin 
>> community is making. It's a contradiction. And without the 
>> infrastructure bitcoin ceases to be interesting even to people 
>> who are willing to pay huge sums to use it.
> 
> You keep talking about "high-value-transactions-only" like if 
> non-urgent transaction fees rising from zero to, say, 1 satoshi, 
> would automatically result in that "high-value-transactions-only" 
> Bitcoin. Please, stop talking as if someone was proposing a 
> "high-value-transactions-only" Bitcoin. That may happen but nobody
>  really knows. If it happens it may not be bad thing necessarily 
> (ie bitcoin microtransactions can still happen using trustless 
> payment channels and x is still cheaper than x% for any transacted 
> value higher than 100) but that's really not what we're talking 
> about here so it seems distraction that can only help further 
> polirizing this discussion.
> 
> What we're talking about here is that hitting the limit would 
> (hopefully) make miners start caring about fees. Enough that they 
> stop being irrational about free transactions. If both things 
> happen, non-urgent transaction fees will likely rise (as said, 
> above zero).
> 
> You think that would be a catastrophe for adoption and I disagree.
>  But (as Pieter has repeatedly explained) for any size there will 
> be use cases that will be eventually priced out. So when rising 
> this consensus limit, not increasing centralization should be the 
> priority and the potential impact in market fees a much more 
> secondary concern. Do you agree with this?
> 
> I'm sure there are many intermediate positions between "caring more
> about mining centralization than market fees when deciding about a
> consensus rule that limits mining centralization" and "not caring
> about mining centralization at all". I really don't want to put
> words in your mouth, but I honestly don't know what your position
> is. I don't really know how else can I ask the same question: you
> don't care the consensus maximum blocksize rule being here at all
> or not (you just said that). Is it because you don't think it
> limits mining centralization or because you don't care about
> limiting mining centralization with consensus rules at all? 
> _______________________________________________ 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

iQEcBAEBAgAGBQJVwKvEAAoJEGwAhlQc8H1m2g4H/i3jcap3C1mt5hG964EWlF42
MC6/P23MWI6o5AO7Ugz6m35IDO+ZfegY3VlAmAaq0KSwKEoZSWV/FIPQPpVOCGeP
CdIGw4M+Q//kRBaxNEnfC3gM7IYHRFfOEwZtVsda5vriem+Yjb4Fk+YoXyONI2j1
0GqmPAIJ5+eA1H/t541/lUDHVzLyymlsWX34MIjX1BWnKQaap+eaMHucu+DrcRHd
GltkKrqRQ/Hngv7PtaQGTPjUHrQglHISl6BMXNMbmxoEHg2RfrRwifiJGnDmEty6
l/Yve6slLtaQA+SIyAun79SUU5+QJOOWDxU2PlXQTRldx+0YQJ60L0GanQ5CHc8=
=EarG
-----END PGP SIGNATURE-----

Re: [bitcoin-dev] Block size following technological growth

[Jorge Timón]

On Tue, Aug 4, 2015 at 1:34 PM, Hector Chu <hectorchu@gmail.com> wrote:
> Things apparently aren't bad enough to prevent the majority from clamoring
> for larger blocks.

Nobody is preventing anyone from claiming anything. Some developers
are encouraging users to ask for bigger blocks.
Others don't want to impose consensus rule changes against the will of
the users (even if they're 10% of the users).
Still, "Things apparently aren't bad enough" is just your opinion.

> If the majority agreed that things had got worse till this point, and that
> this was to be blamed on the block size, they would be campaigning for the
> other direction. Even yourselves aren't asking for a reduction in the block
> size, as you know full well that you would be laughed out.

1) I don't care what the so-called "majority" thinks: I don't want to
impose consensus rule changes against the will of a reasonable
minority.
2) It doesn't matter who is to blame about the current centralization:
the fact remains that the blocksize maximum is the only** consensus
rule to limit mining centralization.
3) In fact I think Luke Dashjr proposed to reduced it to 400 KB, but I
would ask the same thing: please create a simulation in which the
change is better (or at least no much worse) than the current rules by
ANY metric.

Please read the point 2 with special attention because it's not the
first time I say this in this thread.

** There's also the maximum block sigops consensus rule to limit
mining centralization.

Re: [bitcoin-dev] Block size following technological growth

[Hector Chu]

[-- Attachment #1: Type: text/plain, Size: 406 bytes --]

On 4 August 2015 at 14:13, Jorge Timón <jtimon@jtimon.cc> wrote:

> 2) It doesn't matter who is to blame about the current centralization:
> the fact remains that the blocksize maximum is the only** consensus
> rule to limit mining centralization.
>

Repeating a claim ad-nauseum doesn't make it necessarily true. A block size
limit won't prevent miners in the future from buying each other out.

[-- Attachment #2: Type: text/html, Size: 747 bytes --]

Re: [bitcoin-dev] Block size following technological growth

[Venzen Khaosan]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On 08/04/2015 08:28 PM, Hector Chu via bitcoin-dev wrote:
> On 4 August 2015 at 14:13, Jorge Timón <jtimon@jtimon.cc 
> <mailto:jtimon@jtimon.cc>> wrote:
> 
> 2) It doesn't matter who is to blame about the current
> centralization: the fact remains that the blocksize maximum is the
> only** consensus rule to limit mining centralization.
> 
> 
> Repeating a claim ad-nauseum doesn't make it necessarily true. A
> block size limit won't prevent miners in the future from buying
> each other out.
> 

It plays both ways, the technical list requires a proof of concept and
simulation upon which to base judgment going forward, else we'll just
be talking out our backsides (like certain people) without making any
progress.

The tools for simulation exist: Jorge Timon created a variable
blocksize regtest PR here:
https://github.com/bitcoin/bitcoin/pull/6382

No-one needs to postulate what different blocksizes imply  - anyone
can run a simulation and demonstrate what they're talking about.

> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev@lists.linuxfoundation.org 
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVwMFEAAoJEGwAhlQc8H1mo/EH/2USw5YUL/7sgFAsjpXdpcS+
9XZ0M0AK4PNSo36GBBhjaF9rRa76FtK6Vt9nLe+7lgYmeHSkcQ65OLKfP47hCnsz
9XfVR0n7nv+0TqHQKPcjm+WNBoVndKRHGEwNQoQw//bAmO4LOcmQCMXAkk9RfaKm
4olay0nUmAFNqh/7wVOunOUFMJNIRpy/neAlFYxRAHBIJLcc0KQNiLqAHbzwPDZq
e9kLjtIusWwLUCgHFvox01bIEOx+VYIxzjMVRz1MNGyRGwDweg7zk54WA48nYwmx
70Ggdde9kiLytPDwB2ey/IRE4mv/4KS2zivJy36XAsjPExTNeGKxGeGfBqXNwSI=
=aya4
-----END PGP SIGNATURE-----

Re: [bitcoin-dev] Block size following technological growth

[Jorge Timón]

On Tue, Aug 4, 2015 at 3:28 PM, Hector Chu <hectorchu@gmail.com> wrote:
> On 4 August 2015 at 14:13, Jorge Timón <jtimon@jtimon.cc> wrote:
>>
>> 2) It doesn't matter who is to blame about the current centralization:
>> the fact remains that the blocksize maximum is the only** consensus
>> rule to limit mining centralization.
>
>
> Repeating a claim ad-nauseum doesn't make it necessarily true. A block size
> limit won't prevent miners in the future from buying each other out.

But reading it 10 times may help you understand the claim, you will
never find out until you try.
"Miners buying each other out" is not the only way in which mining
centralization can get even worse.
A Blocksize limit may not be able to prevent such a scenario, but it's
still the only consensus tool to limit mining centralization.
If you want to prove that claim wrong you need to find a
counter-example of another consensus rule that somehow limits mining
centralization.
You could also prove that this rule doesn't help with mining
centralization at all. But that's much more difficult and if you just
claim it (and consequently advocate for the complete removal of the
consensus rule) we will have already advanced a lot.
But you denying that the limits serves limiting mining centralization
and at the same time advocating for keeping a limit at all doesn't
seem very consistent.
If you don't want that rule to limit mining centralization pressures,
what do you want it for?

Re: [bitcoin-dev] Block size following technological growth

[Gavin Andresen]

[-- Attachment #1: Type: text/plain, Size: 2903 bytes --]

On Tue, Aug 4, 2015 at 7:27 AM, Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I would say that things already demonstrately got terrible. The mining
> landscape is very centralized, with apparently a majority depending on
> agreements to trust each other's announced blocks without validation.
>
And that is a problem... why?

As far as I can tell, nobody besides miners running old and/or buggy
software lost money due to outsourced mining validation (please correct me
if I'm wrong-- I'm looking forward to Greg's post-mortem). The operators of
bitcoin.org seem to have freaked out and pushed the panic button (with dire
warnings of not trusting transactions until 20 confirmations), but theymos
was well known for using an old, patched version of Core for
blockexplorer.com so maybe that's not surprising.

As Bitcoin grows, pieces of the ecosystem will specialize. Satoshi's
original code did everything: hashing, block assembly, wallet, consensus,
network. That is changing, and that is OK.

I understand there are parts of the ecosystem you'd rather not see
specialized, like transaction selection / block assembly or validation. I
see it as a natural maturation. The only danger I see is if some unnatural
barriers to competition spring up.

> Full node count is at its historically lowest value in years, and
outsourcing of full validation keeps growing.

Both side effects of increasing specialization, in my opinion. Many
companies quite reasonably would rather hire somebody who specializes in
running nodes, keeping keys secure, etc rather than develop that expertise
themselves.

Again, not a problem UNLESS some unnatural barriers to competition spring
up.


> I believe that if the above would have happened overnight, people would
> have cried wolf. But somehow it happened slow enough, and "things kept
> working".
>
> I don't think that this is a good criterion. Bitcoin can "work" with
> gigabyte blocks today, if everyone uses the same few blockchain validation
> services, the same few online wallets, and mining is done by a cartel that
> only allows joining after signing a contract so they can sue you if you
> create an invalid block. Do you think people will then agree that "things
> got demonstratebly worse"?
>
> Don't turn Bitcoin into something uninteresting, please.
>
> Why is what you, personally, find interesting relevant?

I understand you want to build an extremely decentralized system, where
everybody participating trusts nothing except the genesis block hash.

I think it is more interesting to build a system that works for hundreds of
millions of people, with no central point of control and the opportunity
for ANYBODY to participate at any level. Permission-less innovation is what
I find interesting.

And I think the current "demonstrably terrible" Bitcoin system is still
INCREDIBLY interesting.

-- 
--
Gavin Andresen

[-- Attachment #2: Type: text/html, Size: 3973 bytes --]

Re: [bitcoin-dev] Block size following technological growth

[Pieter Wuille]

[-- Attachment #1: Type: text/plain, Size: 3099 bytes --]

On Tue, Aug 4, 2015 at 3:12 PM, Gavin Andresen <gavinandresen@gmail.com>
wrote:

> On Tue, Aug 4, 2015 at 7:27 AM, Pieter Wuille via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> I would say that things already demonstrately got terrible. The mining
>> landscape is very centralized, with apparently a majority depending on
>> agreements to trust each other's announced blocks without validation.
>>
> And that is a problem... why?
>

If miners need to form alliances of trusting each other's blocks without
validation to overcome the inefficiencies of slow block propagation, I
think we have a system that is in direct conflict with the word
"permissionless" that you use later.


> As Bitcoin grows, pieces of the ecosystem will specialize. Satoshi's
> original code did everything: hashing, block assembly, wallet, consensus,
> network. That is changing, and that is OK.
>

Specialization is perfectly fine.
>
> I believe that if the above would have happened overnight, people would
> have cried wolf. But somehow it happened slow enough, and "things kept
> working".
>
> I don't think that this is a good criterion. Bitcoin can "work" with
> gigabyte blocks today, if everyone uses the same few blockchain validation
> services, the same few online wallets, and mining is done by a cartel that
> only allows joining after signing a contract so they can sue you if you
> create an invalid block. Do you think people will then agree that "things
> got demonstratebly worse"?
>
> Don't turn Bitcoin into something uninteresting, please.
>
Why is what you, personally, find interesting relevant?
>

I find it interesting to build a system that has potential to bring about
innovation.

I understand you want to build an extremely decentralized system, where
> everybody participating trusts nothing except the genesis block hash.
>

That is not true, I'm sorry if that is the impression I gave.

I see centralization and scalability as a trade-off, and for better or for
worse, the block chain only offers one trade-off. I want to see technology
built on top that introduces lower levels of trust than typical fully
centralized systems, while offering increased convenience, speed,
reliability, and scale. I just don't think that all of that can happen on
the lowest layer without hurting everything built on top. We need different
trade-offs, and the blockchain is just one, but a very fundamental one.

I think it is more interesting to build a system that works for hundreds of
> millions of people, with no central point of control and the opportunity
> for ANYBODY to participate at any level. Permission-less innovation is what
> I find interesting.
>

That sounds amazing, but do you think that Bitcoin, as it exists today, can
scale to hundreds of millions of users, while retaining any glimpse of
permission-lessness and decentralization? I think we need low-trust
off-chain systems and other innovations to make that happen.


> And I think the current "demonstrably terrible" Bitcoin system is still
> INCREDIBLY interesting.
>

I'm happy for you, then.

-- 
Pieter

[-- Attachment #2: Type: text/html, Size: 5097 bytes --]

Re: [bitcoin-dev] Block size following technological growth

[Venzen Khaosan]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On 08/04/2015 08:12 PM, Gavin Andresen via bitcoin-dev wrote:
> On Tue, Aug 4, 2015 at 7:27 AM, Pieter Wuille via bitcoin-dev 
> <bitcoin-dev@lists.linuxfoundation.org 
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
> 
> I would say that things already demonstrately got terrible. The 
> mining landscape is very centralized, with apparently a majority 
> depending on agreements to trust each other's announced blocks 
> without validation.
> 
> And that is a problem... why?
> 
> As far as I can tell,

[snip]


It's a big problem. What are you dismissing it for?

With Bitcoin in fledgling 0.x version state this is neither desirable
nor encouraging.

Development did not freeze at some time in the past and now we see how
the userbase reacts. Miners, btw, are arguibly still a class of user
as long as they are guaranteed coinbase.

When they start making and proving themselves useful in a free
floating fee market absent coinbase subsidy, we can revisit this
topic, with the benefit of hindsight.

> As Bitcoin grows, pieces of the ecosystem will specialize.
> Satoshi's original code did everything: hashing, block assembly,
> wallet, consensus, network. That is changing, and that is OK.

[snip]

> 
> And I think the current "demonstrably terrible" Bitcoin system is
> still INCREDIBLY interesting.
> 
Pieter never said it wasn't interesting, so this emphatic statement is
strange - like someone is trying to convince an audience - but
anyway... as you, a veritable spring-chicken by your actions and
words, said the other day: having graduated in '88 you're "old" and
speak from experience. Don't come with that jive, bossy man - bring
facts and testing to the technical list.

My finance readers, in one camp, and Bitcoin investors, in the other,
want to see the XT 8MB hard-fork testing data that you mentioned for
BIP100.

"Being ignorant is not so much a shame, as being unwilling to learn."
- - Benjamin Franklin

> -- -- Gavin Andresen
> 

Venzen Khaosan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVwMyOAAoJEGwAhlQc8H1mho4IAKEHVxE4lAs3aIoLXa2fxLP8
3q7MhfM5vIW9QAM7rjz8YzheMg3Wj2CNfZPuUV7YDTVrLZPrIN/aMY6CIftr7GUS
pjMI9nnwezFwYX5oyRU+gW51AMFhvexV6ITZYpiLRtWHgK1FZtXWMG13eO/6Jb5U
Wjflub7suMDvg+ST2PplhQf7fFmnPHrLZg3ISDqK+hvgw20geW1rXC/wCChlewfd
DqSt9fxqs+NIvbIzS2TgLTkIcHlbKNeI5AeqbaFoaIQtvYALD3Ojt2I/qoCJU1za
rB8Il7UK0B5uf6xxgErGcYAHzjVpR6Zhsdzo6MiBF1j4ClfNPEQAlG49YjrRXpI=
=4nai
-----END PGP SIGNATURE-----

[bitcoin-dev] Fwd: Re: Block size following technological growth

[Venzen Khaosan]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

correction:

My finance readers, in one camp, and Bitcoin investors, in the other,
want to see the XT 8MB hard-fork testing data that you mentioned for
BIP101 (not 100).


- -------- Forwarded Message --------
Subject: Re: [bitcoin-dev] Block size following technological growth
Date: Tue, 04 Aug 2015 21:30:40 +0700
From: Venzen Khaosan via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org>
Reply-To: venzen@mail.bihthai.net
Organization: Bihthai Bai Mai
To: Gavin Andresen <gavinandresen@gmail.com>, Bitcoin Dev
<bitcoin-dev@lists.linuxfoundation.org>



On 08/04/2015 08:12 PM, Gavin Andresen via bitcoin-dev wrote:
> On Tue, Aug 4, 2015 at 7:27 AM, Pieter Wuille via bitcoin-dev 
> <bitcoin-dev@lists.linuxfoundation.org 
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
> 
> I would say that things already demonstrately got terrible. The 
> mining landscape is very centralized, with apparently a majority 
> depending on agreements to trust each other's announced blocks 
> without validation.
> 
> And that is a problem... why?
> 
> As far as I can tell,

[snip]


It's a big problem. What are you dismissing it for?

With Bitcoin in fledgling 0.x version state this is neither desirable
nor encouraging.

Development did not freeze at some time in the past and now we see how
the userbase reacts. Miners, btw, are arguibly still a class of user
as long as they are guaranteed coinbase.

When they start making and proving themselves useful in a free
floating fee market absent coinbase subsidy, we can revisit this
topic, with the benefit of hindsight.

> As Bitcoin grows, pieces of the ecosystem will specialize. 
> Satoshi's original code did everything: hashing, block assembly, 
> wallet, consensus, network. That is changing, and that is OK.

[snip]

> 
> And I think the current "demonstrably terrible" Bitcoin system is 
> still INCREDIBLY interesting.
> 
Pieter never said it wasn't interesting, so this emphatic statement is
strange - like someone is trying to convince an audience - but
anyway... as you, a veritable spring-chicken by your actions and
words, said the other day: having graduated in '88 you're "old" and
speak from experience. Don't come with that jive, bossy man - bring
facts and testing to the technical list.

My finance readers, in one camp, and Bitcoin investors, in the other,
want to see the XT 8MB hard-fork testing data that you mentioned for
BIP100.

"Being ignorant is not so much a shame, as being unwilling to learn."
- - Benjamin Franklin

> -- -- Gavin Andresen
> 

Venzen Khaosan
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVwM93AAoJEGwAhlQc8H1mwcEH/RwxpWyvjlWBrPok5GNRed+/
8O46a4G1T6+Y2+yKWDFQTqG0D2oFEqunHW1A+e7UYABrhijbr1Xwpv0Y//VSuY3p
TnRXPj3+q3j4BdB607y5i0jCo61G4IrXaCUEHpBMzrD5T7SMDC1a31FLgAjx9WDM
etKmT9doWn9aiWzxAl/q8SEY4M04RLyS5kijs95M9YMGp1KVw2jNDfJM37EhPDu2
qDUMQEvcq0qTPCeHn6tCaXC0rWzIpylE6Xaso3VMepmbdzf0Dea92asBmmE0ygsW
Tcfx95UWW+Bb/h2JEO3TCjKpLCwdfiWP/2eXIMKkcdSJIVf/yE32gIxzqPx5ogU=
=BwgG
-----END PGP SIGNATURE-----

Re: [bitcoin-dev] Block size following technological growth

[Alex Morcos]

[-- Attachment #1: Type: text/plain, Size: 2197 bytes --]

On Tue, Aug 4, 2015 at 9:12 AM, Gavin Andresen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Tue, Aug 4, 2015 at 7:27 AM, Pieter Wuille via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> I would say that things already demonstrately got terrible. The mining
>> landscape is very centralized, with apparently a majority depending on
>> agreements to trust each other's announced blocks without validation.
>>
> And that is a problem... why?
>
> As far as I can tell, nobody besides miners running old and/or buggy
> software lost money due to outsourced mining validation (please correct me
> if I'm wrong-- I'm looking forward to Greg's post-mortem). The operators of
> bitcoin.org seem to have freaked out and pushed the panic button (with
> dire warnings of not trusting transactions until 20 confirmations), but
> theymos was well known for using an old, patched version of Core for
> blockexplorer.com so maybe that's not surprising.
>
>
I'm also looking forward to Greg's post-mortem, because I had a completely
different takeaway from the BIP66 mini-forks.  My view is that despite the
extremely cautious and conservative planning for the completely
uncontentious fork, the damage could and would have been very significant
if it had not been for several core devs manually monitoring, intervening
and problem solving for other network participants.  I don't believe thats
the way the system should work.  Participants in the Bitcoin community have
come to rely on the devs for just making sure everything works for them.
That's not sustainable.  The system needs to be made fundamentally more
secure if its going to succeed, not depend on the good will of any
particular parties, otherwise it certainly will no longer be permissionless.

The BIP66 fork was urgently required to fix an undisclosed consensus bug,
unanimously agreed on and without technical objection, and it was still
fraught with problems.  That's the most clear cut example of when we should
have a fork.  A change to a consensus limit that a significant proportion
of the community disagrees with for economic or technical reasons or both
should be raising a sea of red flags.

[-- Attachment #2: Type: text/html, Size: 3086 bytes --]

Re: [bitcoin-dev] Block size following technological growth

[Gareth Williams]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512



On 4 August 2015 11:12:36 PM AEST, Gavin Andresen via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>On Tue, Aug 4, 2015 at 7:27 AM, Pieter Wuille via bitcoin-dev <
>bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> I would say that things already demonstrately got terrible. The
>mining
>> landscape is very centralized, with apparently a majority depending
>on
>> agreements to trust each other's announced blocks without validation.
>>
>And that is a problem... why?

With all due respect Gavin, large-block advocates appear to hold the position that:
* pushing individual economic actors away from running full nodes is a natural and unproblematic consequence of block size increase, as they're expected to rely on SPV
You now also appear to hold the position that:
* pushing miners to SPV mining is unproblematic

Have I misunderstood? Is one of these not an expected outcome of large blocks? I can understand the validity of either argument alone -- the assertion that we can trust miners to validate and just trust most-POW ourselves, /or/ the assertion that lack of miner validation is safe under certain circumstances. But together?

Who do you expect to actually validate large blocks if not miners, and what do you expect their incentive to do so to be?

-----BEGIN PGP SIGNATURE-----
Version: APG v1.1.1

iQFABAEBCgAqBQJVwcYAIxxHYXJldGggV2lsbGlhbXMgPGdhY3J1eEBnbWFpbC5j
b20+AAoJEEY5w2E3jkVEEWQH/Aty47q71H/ZcMMX/6qcTpOumI9h/buUfsvYA2H+
J6Al5S8JvCy3/0yMFCLmqolHoxOdWu5jwtUf/w2fepgA1RJyZItFo1EG9cJB0Cpz
JgM+2s4L/F3l4+Gea2ddjhvE5JqGS0Qh3EWaR/xy1bouq0FZjtDendmK7vFRj/oS
Gowm+g5EFBiT1XwCQQXJc9k0RxzDpPQ0ouSOXWdPUuxfQAjPyX89eQBeQzgVDtEf
zVfROZVHQuBu85rKTd32TdCNLQ0oEhAYmwgdtmJyLLgieeqHmNbaikBaVDEOvixn
S+fmnfD8CVeeXo5zKdlLZXazc5geRx97H4NMBMjTyjPzR5k=
=WG0I
-----END PGP SIGNATURE-----

Re: [bitcoin-dev] Block size following technological growth

[Jorge Timón]

On Tue, Aug 4, 2015 at 1:04 PM, Hector Chu <hectorchu@gmail.com> wrote:
> Mike's position is that he wants the block size limit to eventually be
> removed. That is of course an extreme view.

I prefer to wait and let him talk by himself.

> Meanwhile, your view that the
> block size should be artificially constrained below the organic growth curve
> (in a way that will penalize a majority of existing and future users) lies
> at the other extreme.

That is not my position. Again, I don't know what the right blocksize
for the short term is (I don't think anybody does).
But I know that the maximum block size limit consensus rule (no more
artificial than any other consensus rule, like, say, the one that
prohibits double-spends) serves to limit mining centralization.
Therefore how the change can affect mining centralization must be the
main concern, instead of (also artificial) projections about usage
growth (no matter how organic their curves look).
Also I don't think "hitting the limit" must be necessarily harmful and
if it is, I don't understand why hitting it at 1MB will be more
harmful than hitting it at 2MB, 8MB or 8GB.

> The majority position lies somewhere in between (i.e.
> a one-time increase to 8MB). This is the position that ultimately matters.

I don't know where you get your "majority" from or what it even means
(majority of users, majority of the coins, of miners?)
But there's something I'm missing something there...why my position
doesn't matter if it's not a majority?
How is what the the majority has been told it's best an objective argument?

> If the block size is increased to 8MB and things get demonstrably a whole
> lot worse, then you will have a solid leg to stand on. In that case we can
> always do another hard fork later to reduce the block size back to something
> smaller, and henceforth the block size will never be touched again.

Yes.
And if we can "break things" in simulations first before we "break
things" in production, maybe we don't need the later hardfork to "fix
things" (if it's still possible to fix them without completely
restarting the ASIC market).
The fact is that we don't have a single simulation that can tell you
"too centralized/shouldn't affect mining centralization much" for a
given block size.
So if you say 8, I must ask, why not 9?
Why 9 MB is not safe for mining centralization but 8 MB is?

There is NO criterion based on mining centralization to decide between
2 sizes in favor of the small one.
It seems like the rationale it's always "the bigger the better" and
the only limitation is what a few people concerned with mining
centralization (while they still have time to discuss this) are
willing to accept. If that's the case, then there won't be effectively
any limit in the long term and Bitcoin will probably fail in its
decentralization goals.
I think its the proponents of a blocksize change who should propose
such a criterion and now they have the tools to simulate different
block sizes.

I want us to simulate many blocksizes before rushing into a decision
(specially because I disagree that taking a decision there is urgent
in the first place).

Re: [bitcoin-dev] Block size following technological growth

[Hector Chu]

[-- Attachment #1: Type: text/plain, Size: 2827 bytes --]

On 4 August 2015 at 12:59, Jorge Timón <jtimon@jtimon.cc> wrote:

> That is not my position. Again, I don't know what the right blocksize
> for the short term is (I don't think anybody does).
>

You have no position (i.e. neutral). In other words, keeping the existing
limit.


> Therefore how the change can affect mining centralization must be the
> main concern, instead of (also artificial) projections about usage
> growth (no matter how organic their curves look).
>

The degree of mining decentralization is only one of many concerns. Users'
main concern is timely confirmation of low-fee transactions. Miners'
concern is the amount of profit they make.


> Also I don't think "hitting the limit" must be necessarily harmful and
> if it is, I don't understand why hitting it at 1MB will be more
> harmful than hitting it at 2MB, 8MB or 8GB.
>

The limit won't even get to be hit, because all the users that get thrown
out of Bitcoin will have moved over to a system supporting a larger block
size.

I don't know where you get your "majority" from or what it even means
> (majority of users, majority of the coins, of miners?)
>

The majority which the miners are beholden to is the economic majority.
https://en.bitcoin.it/wiki/Economic_majority


> But there's something I'm missing something there...why my position
> doesn't matter if it's not a majority?
>

Your position is only one of many and it does not carry excess weight to
the others. Individually it won't matter, because you can't control the
implementation that other people run.


> How is what the the majority has been told it's best an objective argument?
>

Don't fight the market. The way the system is designed, the miners will
follow along with what the economic majority have decided.

So if you say 8, I must ask, why not 9?
> Why 9 MB is not safe for mining centralization but 8 MB is?
>

8MB has simply been the focal point for this debate. 9MB is also safe if
8MB is, but I suppose the opponents will be even less happy with 9 than
with 8, and we don't want to unnecessarily increase the conflict.

It seems like the rationale it's always "the bigger the better" and
> the only limitation is what a few people concerned with mining
> centralization (while they still have time to discuss this) are
> willing to accept. If that's the case, then there won't be effectively
> any limit in the long term and Bitcoin will probably fail in its
> decentralization goals.
>

A one-time increase to 8MB is safer than a dynamically growing limit over
time for exactly this reason. Admittedly whenever the next debate to
increase the block size over 8MB happens it will be even more painful and
non-obvious, but that is the safety check to prevent unbounded block size
increase.

[-- Attachment #2: Type: text/html, Size: 4348 bytes --]

Re: [bitcoin-dev] Block size following technological growth

[Venzen Khaosan]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On 08/04/2015 07:19 PM, Hector Chu via bitcoin-dev wrote:
> On 4 August 2015 at 12:59, Jorge Timón <jtimon@jtimon.cc 
> <mailto:jtimon@jtimon.cc>> wrote:

> So if you say 8, I must ask, why not 9? Why 9 MB is not safe for 
> mining centralization but 8 MB is?
> 
> 
> 8MB has simply been the focal point for this debate. 9MB is also 
> safe if 8MB is, but I suppose the opponents will be even less
> happy with 9 than with 8, and we don't want to unnecessarily
> increase the conflict.
> 

Jorge will answer for himself, but you know that saying "9MB is also
safe if 8MB is" blows your position.

Do you, or me, or XT know that 8MB is "safe"? You say 9MB must then
also be "safe" - there has been no fact for me to grasp and from which
to tell a Bitcoin trading whale group: "here's the bottom line: this
is what it means and these are the implications." They hold
significant amounts of bitcoin and want to see a plan, and a strategy
based on facts. I can assure you, they're not going to XT, it lacks
both a strategy and the seasoned developers present here.

> It seems like the rationale it's always "the bigger the better" and
> the only limitation is what a few people concerned with mining 
> centralization (while they still have time to discuss this) are 
> willing to accept. If that's the case, then there won't be 
> effectively any limit in the long term and Bitcoin will probably 
> fail in its decentralization goals.
> 
> 
> A one-time increase to 8MB is safer than a dynamically growing 
> limit over time for exactly this reason. Admittedly whenever the 
> next debate to increase the block size over 8MB happens it will be 
> even more painful and non-obvious, but that is the safety check to 
> prevent unbounded block size increase.

You're articulate and you raise valid issues, but your judgment of
"safer" is not based on anything you or this list can refer to as a
comparator.

It seems you want 8MB for some ideological reason but if you examine
your motive and compare it to the facts, you'll find that many people
in this list are ultimately correct in saying that:

Whatever blocksize is set to, demand will soon fill it.

This is the nature of resource supply inflation - some business plan
will spot the opportunity and exploit it, colonize it and then we deal
with that, with some big-girls'-blouses exclaiming: "if we don't give
them what they want they're all going to leave to XT or ZT!"

Even though XT and ZT perfectly fulfill the needs of certain ambitious
businesses, the creators would rather see it happen on Core's
blockchain. Else why do they still come posit arguments here?

Fortunately, unlike the principle that applies in finance capital,
Bitcoin capacity supply doesn't have be increased on demand (not
without rigorous testing and evaluation) plus there is no maxim here
that "the customer is always right". The maxim is "be your own bank" -
during some periods it might be a slow bank but it _will_ remain
decentralized and it _will_ remain your own - not compromised to some
big business or mining cartel.

We want to compromise to science and reason, not profit motive or
democratic lobbying, right?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVwL80AAoJEGwAhlQc8H1mTVsH/3mdA4XrrRaBx7m/SckufNUu
OWJF/TPuEb0e3/A+OKNvYJgGtkZ9+8pQe2hQK2F1NxFG8QbbIPFXb4PYIiEnU8by
LMMNuDFfZXq0MEyTXXHgNj+XBSR74QKceXD4KM3jVeuieXE2KXGOyeiUD7Tjx0Gv
fyNAM4rhxmipGFu9kmnI6Bm25I4FBzif+ARQSWNmdZQn2bPkFrK0/Q4s/CyXngbb
S/DiPJ7XZrBJ2ogQycVmA4QesOyz30FpQ+QMt5nFUWma3LpLoYEBPtJd8rsG773i
acqSrOXxgfcGtNfbBU0xeTO/FOO4tXtbDVHBTKCBLZ5MgmBOYcm6OTLAwpeHlYY=
=WhnR
-----END PGP SIGNATURE-----

Re: [bitcoin-dev] Block size following technological growth

[Jorge Timón]

On Tue, Aug 4, 2015 at 2:19 PM, Hector Chu <hectorchu@gmail.com> wrote:
> On 4 August 2015 at 12:59, Jorge Timón <jtimon@jtimon.cc> wrote:
>>
>> That is not my position. Again, I don't know what the right blocksize
>> for the short term is (I don't think anybody does).
>
> You have no position (i.e. neutral). In other words, keeping the existing
> limit.

No, I think 1 MB is just as arbitrary as any other size proposed.
All I want is for consensus change proponents to try harder to
convince other users (including me)

>> Therefore how the change can affect mining centralization must be the
>> main concern, instead of (also artificial) projections about usage
>> growth (no matter how organic their curves look).
>
>
> The degree of mining decentralization is only one of many concerns. Users'
> main concern is timely confirmation of low-fee transactions. Miners' concern
> is the amount of profit they make.

No, if the changed rule only serves to limit centralization, then how
that limitation to centralization is affected should be the first
thing to consider.
If miners' concern was only the amount of profit they make they
wouldn't mine free transactions already.
You cannot possibly know what all users' are concern about, so I will
just ignore any further claim in that direction.
Talk for yourself: your arguments won't be more reasonable just
because you claim that all users think like you do.

>> Also I don't think "hitting the limit" must be necessarily harmful and
>> if it is, I don't understand why hitting it at 1MB will be more
>> harmful than hitting it at 2MB, 8MB or 8GB.
>
>
> The limit won't even get to be hit, because all the users that get thrown
> out of Bitcoin will have moved over to a system supporting a larger block
> size.

I disagree with this wild prediction as well.

>> I don't know where you get your "majority" from or what it even means
>> (majority of users, majority of the coins, of miners?)
>
>
> The majority which the miners are beholden to is the economic majority.
> https://en.bitcoin.it/wiki/Economic_majority

And I assume the way that vaguely defined "economic majority"
communicates with you through a crystal ball or something

>> But there's something I'm missing something there...why my position
>> doesn't matter if it's not a majority?
>
>
> Your position is only one of many and it does not carry excess weight to the
> others. Individually it won't matter, because you can't control the
> implementation that other people run.

No more, but not less either.
Nobody can't control the implementation that I (or other people
concerned with centralization) run either.

>> How is what the the majority has been told it's best an objective
>> argument?
>
>
> Don't fight the market. The way the system is designed, the miners will
> follow along with what the economic majority have decided.

How is allowing fees from rising above zero "fighting the market"?
The system is currently designed with a 1 MB limit. I don't think
that's sacred or anything, but I really don't feel like I'm fighting
"the market" or "the way the system is designed".
In any case, what do "the market" and "the way the system is designed"
have to do with what the majority have been told it's best (which you
seem to think should be a source of truth for some reason I'm still
missing)?

>> So if you say 8, I must ask, why not 9?
>> Why 9 MB is not safe for mining centralization but 8 MB is?
>
>
> 8MB has simply been the focal point for this debate. 9MB is also safe if 8MB
> is, but I suppose the opponents will be even less happy with 9 than with 8,
> and we don't want to unnecessarily increase the conflict.

Why 9 MB is safe but 10 MB isn't?
The "conflict" won't be resolved by evading hard questions...

>> It seems like the rationale it's always "the bigger the better" and
>> the only limitation is what a few people concerned with mining
>> centralization (while they still have time to discuss this) are
>> willing to accept. If that's the case, then there won't be effectively
>> any limit in the long term and Bitcoin will probably fail in its
>> decentralization goals.
>
>
> A one-time increase to 8MB is safer than a dynamically growing limit over
> time for exactly this reason. Admittedly whenever the next debate to
> increase the block size over 8MB happens it will be even more painful and
> non-obvious, but that is the safety check to prevent unbounded block size
> increase.

Will there ever be a debate that results in "further blocksize
increases at this point are very risky for mining centralization"?
How will we tell then? Can't we use the same criteria now?

Re: [bitcoin-dev] Block size following technological growth

[Elliot Olds]

[-- Attachment #1: Type: text/plain, Size: 3995 bytes --]

On Tue, Aug 4, 2015 at 4:59 AM, Jorge Timón <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Also I don't think "hitting the limit" must be necessarily harmful and
> if it is, I don't understand why hitting it at 1MB will be more
> harmful than hitting it at 2MB, 8MB or 8GB.


I don't think merely hitting the limit is bad. The level of tx fees in
equilibrium give some clue as to the level of harm being done. If fees are
at $5/tx at 1MB, it's about as bad as if fees are at $5/tx at 4MB.

There is NO criterion based on mining centralization to decide between
> 2 sizes in favor of the small one.
> It seems like the rationale it's always "the bigger the better" and
> the only limitation is what a few people concerned with mining
> centralization (while they still have time to discuss this) are
> willing to accept. If that's the case, then there won't be effectively
> any limit in the long term and Bitcoin will probably fail in its
> decentralization goals.
> I think its the proponents of a blocksize change who should propose
> such a criterion and now they have the tools to simulate different
> block sizes.
>

In the absence of harder data, it might be interesting to use these
simulations to graph centralization pressure as a function of bandwidth
cost over time (or other historical variables that affect centralization).
For instance, look at how high centralization pressure was in 2009
according to the simulations, given how cheap/available bandwidth was then,
compared to 2010, 2011, etc. Then we could figure out: given today's
bandwidth situation, what size blocks right now would give us the same
centralization pressure that we had in 2011, 2012, 2013, etc?

Of course this doesn't mean we should blindly assume that the level of
centralization pressure in 2012 was acceptable, and therefore any block
size increase that results in the same amount of pressure now should be
acceptable. But it might lead to a more productive discussion.


> I want us to simulate many blocksizes before rushing into a decision
> (specially because I disagree that taking a decision there is urgent
> in the first place).


IMO it is not urgent if the core devs are committed to reacting to a huge
spike in tx fees with a modest block size increase in a relatively short
time frame, if they judge the centralization risks of that increase to be
small. Greg Maxwell posted on reddit a while back something to the effect
of "the big block advocates are overstating the urgency of the block size
increase, because if there was actually a situation that required us to
increase block size, we could make the increase when it was actually
needed." I found that somewhat persuasive, but I am concerned that I
haven't seen any discussion of what the "let's wait for now" camp would
consider a valid reason to increase block size in the short term, and how
they'd make the tradeoff with tx fees or whatever else was necessitating
the increase.

Jorge, if a fee equilibrium developed at 1MB of $5/tx, and you somehow knew
with certainty that increasing to 4MB would result in a 20 cent/tx
equilibrium that would last for a year (otherwise fees would stay around $5
for that year), would you be in favor of an increase to 4MB?

For those familiar with the distinction between near/far mode thinking
popularized by Robin Hanson: focusing on concrete examples like this
encourages problem solving and consensus, and focusing on abstract
principles (like decentralization vs. usability in general) leads to people
toward using argument to signal their alliances and reduce the status of
their opponents. I think it'd be very helpful if more 1MB advocates
described what exactly would make them say "OK, in this situation a block
size increase is needed, we should do one quickly!", and also if
Gavin/Mike/Jeff described what hypothetical scenarios and/or test results
would make them want to stick with 1MB blocks for now.

[-- Attachment #2: Type: text/html, Size: 4860 bytes --]

Re: [bitcoin-dev] Block size following technological growth

[Jorge Timón]

On Wed, Aug 5, 2015 at 9:29 AM, Elliot Olds <elliot.olds@gmail.com> wrote:
> On Tue, Aug 4, 2015 at 4:59 AM, Jorge Timón
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> Also I don't think "hitting the limit" must be necessarily harmful and
>> if it is, I don't understand why hitting it at 1MB will be more
>> harmful than hitting it at 2MB, 8MB or 8GB.
>
>
> I don't think merely hitting the limit is bad. The level of tx fees in
> equilibrium give some clue as to the level of harm being done. If fees are
> at $5/tx at 1MB, it's about as bad as if fees are at $5/tx at 4MB.

This is a much more reasonable position. I wish this had been starting
point of this discussion instead of "the block size limit must be
increased as soon as possible or bitcoin will fail".
If the only fear about not increasing the block size fast enough is
that fees may rise, pieter wouldn't had to repeatedly explain that for
any reasonable block size some use case may fill the blocks rapidly.

>> There is NO criterion based on mining centralization to decide between
>> 2 sizes in favor of the small one.
>> It seems like the rationale it's always "the bigger the better" and
>> the only limitation is what a few people concerned with mining
>> centralization (while they still have time to discuss this) are
>> willing to accept. If that's the case, then there won't be effectively
>> any limit in the long term and Bitcoin will probably fail in its
>> decentralization goals.
>> I think its the proponents of a blocksize change who should propose
>> such a criterion and now they have the tools to simulate different
>> block sizes.
>
>
> In the absence of harder data, it might be interesting to use these
> simulations to graph centralization pressure as a function of bandwidth cost
> over time (or other historical variables that affect centralization). For
> instance, look at how high centralization pressure was in 2009 according to
> the simulations, given how cheap/available bandwidth was then, compared to
> 2010, 2011, etc. Then we could figure out: given today's bandwidth
> situation, what size blocks right now would give us the same centralization
> pressure that we had in 2011, 2012, 2013, etc?
>
> Of course this doesn't mean we should blindly assume that the level of
> centralization pressure in 2012 was acceptable, and therefore any block size
> increase that results in the same amount of pressure now should be
> acceptable. But it might lead to a more productive discussion.

This sounds good overall but I'm afraid you are oversimplifying some things.
Centralization pressure not only comes from global average bandwidth
costs and block propagation times is not the only concern.
Here's an extreme example: [1]
But anyway, yes, I agree, ANY metric would be better than nothing (the
current situation).

>> I want us to simulate many blocksizes before rushing into a decision
>> (specially because I disagree that taking a decision there is urgent
>> in the first place).
>
>
> IMO it is not urgent if the core devs are committed to reacting to a huge
> spike in tx fees with a modest block size increase in a relatively short
> time frame, if they judge the centralization risks of that increase to be
> small. Greg Maxwell posted on reddit a while back something to the effect of
> "the big block advocates are overstating the urgency of the block size
> increase, because if there was actually a situation that required us to
> increase block size, we could make the increase when it was actually
> needed." I found that somewhat persuasive, but I am concerned that I haven't
> seen any discussion of what the "let's wait for now" camp would consider a
> valid reason to increase block size in the short term, and how they'd make
> the tradeoff with tx fees or whatever else was necessitating the increase.

Given that for any non-absurdly-big size some transactions will
eventually be priced out, and that the consensus rule serves for
limiting mining centralization (and more indirectly centralization in
general) and not about trying to set a given average transaction fee,
I think the current level of mining centralization will always be more
relevant than the current fee level when discussing any change to the
consensus rule to limit centralization (at any point in time).
In other words, the question "can we change this without important
risks of destroying the decentralized properties of the system in the
short or long run?" should be always more important than "is there a
concerning rise in fees to motivate this change at all?".

> Jorge, if a fee equilibrium developed at 1MB of $5/tx, and you somehow knew
> with certainty that increasing to 4MB would result in a 20 cent/tx
> equilibrium that would last for a year (otherwise fees would stay around $5
> for that year), would you be in favor of an increase to 4MB?

As said, I would always consider the centralization risks first: I'd
rather have a $5/tx decentralized Bitcoin than a Bitcoin with free
transactions but effectively validated (when they validate blocks they
mine on top of) by around 10 miners, specially if only 3 of them could
easily collude to censor transactions [orphaning any block that
doesn't censor in the same manner]. Sadly I have no choice, the later
is what we have right now. And reducing the block size can't guarantee
that the situation will get better or even that fees could rise to
$5/tx (we just don't have that demand, not that it is a goal for
anyone). All I know is that increasing the block size *could*
(conditional, not necessarily, I don't know in which cases, I don't
think anybody does) make things even worse.

On the other hand, I could understand people getting worried if fees
where as high as $5/tx or even 20 cent/tx but we're very far away from
that case. How can low subsidies (a certainty) be "too far in the
future to worry about it" but $5/tx, 20 cent/tx or even 5 cent/tx an
urgent concern? For all I know, 5 cent/tx may not happen in the next
25 years: it may never happen. And if it happens, to me it will be a
symptom of Bitcoin success, even for others it means that Bitcoin has
become a "high value settlement network".
To the question

- At which minimum mining fee rate will you urge others to change the
consensus rules to increase the block size?

I'm very sorry, but my answer is:

- I honestly don't know, that may never happen.

What I can tell you is this: I will never be worried about "too high
fees" while the fees remain at 0 (null, zero, nothing, cero, nada,
zilch).
That's right, no matter what wallet's defaults chose for their users,
no matter what the minimum relay fee policy does to the "fee market"
and how much urgent transactions pay in fees; the fact remains that in
practice non-urgent transactions usually (when the raw transaction's
structure it's appropriate) don't have to pay fees.

I'm still missing an answer from the "big blocks size side" to the
following question (which I have insistently repeated with various
permutations):

If "not now" when will it be a good time to let fees rise above zero?
After the next subsidy halving? After 4 more subsidy halvings (ie
about 13 years from now, subsidy = 1.5625 btc/block )? After your
grandmother abandons her national currency and uses Bitcoin for
everything? Never?

ANY answer (maybe with the exception of the last one) would be less
worrying than silence.

> For those familiar with the distinction between near/far mode thinking
> popularized by Robin Hanson: focusing on concrete examples like this
> encourages problem solving and consensus, and focusing on abstract
> principles (like decentralization vs. usability in general) leads to people
> toward using argument to signal their alliances and reduce the status of
> their opponents.

I really appreciate your efforts to mediate in this dispute and I
honestly hope that my previous answer is useful as it is.

> I think it'd be very helpful if more 1MB advocates
> described what exactly would make them say "OK, in this situation a block
> size increase is needed, we should do one quickly!", and also if
> Gavin/Mike/Jeff described what hypothetical scenarios and/or test results
> would make them want to stick with 1MB blocks for now.

Just replace 1MB with ANY size.
But, yes, please, when will you consider a size to be too dangerous
for centralization?
Why 20 GB would have been safe but 21 GB wouldn't have been (or the
respective maximums and respective +1)?

Note that "Never, 20GB was just a number closer to infinity than 1MB
and I hoped that could had been voluntarily accepted by users. What I
really want is to completely remove this consensus rule forever." is a
perfectly valid answer. It just means that I will agree with people
that think this way as explained in [1] (yes, not even after
superluminal communication).

As an less relevant note, I feel extremely uncomfortable about being
included in the "1MB advocates" group. As I've tried to explain
several times, 1 is to me an arbitrary number like any other (at most,
the canonical arbitrary number), and so it is 1000000
(MAX_BLOCK_SIZE). I rarely like being grouped or labelled, but maybe
something more accurate like "not-recklessly-change-consensus-rules
advocates" would help.
There's nothing special about 1MB apart from being the current rule,
so I don't think the number is that much relevant to the discussion.
Grouping anyone that has raised any concern about rising the consensus
block size limit as "the 1MBers" is about as fair as grouping anyone
that has ever proposed a rise in the maximum size as "the 20GBers"
(specially when there's people that belong to both groups
simultaneously, like Pieter Wuille who started this thread, and whose
proposal we're supposed to be discussing).

[1] http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/009947.html

Re: [bitcoin-dev] Block size following technological growth

[Gavin Andresen]

[-- Attachment #1: Type: text/plain, Size: 1606 bytes --]

On Wed, Aug 5, 2015 at 9:26 PM, Jorge Timón <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> This is a much more reasonable position. I wish this had been starting
> point of this discussion instead of "the block size limit must be
> increased as soon as possible or bitcoin will fail".
>

It REALLY doesn't help the debate when you say patently false statements
like that.

My first blog post on this issue is here:
  http://gavinandresen.ninja/why-increasing-the-max-block-size-is-urgent

... and I NEVER say "Bitcoin will fail".  I say:

"If the number of transactions waiting gets large enough, the end result
will be an over-saturated network, busy doing nothing productive. I don’t
think that is likely– it is more likely people just stop using Bitcoin
because transaction confirmation becomes increasingly unreliable."

Mike sketched out the worst-case here:
  https://medium.com/@octskyward/crash-landing-f5cc19908e32

... and concludes:

"I believe there are no situations in which Bitcoin can enter an overload
situation and come out with its reputation and user base intact. Both would
suffer heavily and as Bitcoin is the founder of the cryptocurrency concept,
the idea itself would inevitably suffer some kind of negative
repercussions."


------------

So please stop with the over-the-top claims about what "the other side"
believe, there are enough of those (on both sides of the debate) on reddit.
I'd really like to focus on how to move forward, and how best to resolve
difficult questions like this in the future.

-- 
--
Gavin Andresen

[-- Attachment #2: Type: text/html, Size: 2676 bytes --]

Re: [bitcoin-dev] Block size following technological growth

[Pieter Wuille]

[-- Attachment #1: Type: text/plain, Size: 1902 bytes --]

On Thu, Aug 6, 2015 at 3:40 PM, Gavin Andresen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Wed, Aug 5, 2015 at 9:26 PM, Jorge Timón <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> This is a much more reasonable position. I wish this had been starting
>> point of this discussion instead of "the block size limit must be
>> increased as soon as possible or bitcoin will fail".
>>
>
> It REALLY doesn't help the debate when you say patently false statements
> like that.
>
> My first blog post on this issue is here:
>   http://gavinandresen.ninja/why-increasing-the-max-block-size-is-urgent
>
> ... and I NEVER say "Bitcoin will fail".  I say:
>
> "If the number of transactions waiting gets large enough, the end result
> will be an over-saturated network, busy doing nothing productive. I don’t
> think that is likely– it is more likely people just stop using Bitcoin
> because transaction confirmation becomes increasingly unreliable."
>

But you seem to consider that a bad thing. Maybe saying that you're
claiming that this equals Bitcoin failing is an exaggeration, but you do
believe that evolving towards an ecosystem where there is competition for
block space is a bad thing, right?

I don't agree that "Not everyone is able to use the block chain for every
use case" is the same thing as "People stop using Bitcoin". People are
already not using it for every use case.

Here is what my proposed BIP says: "No hard forking change that relaxes the
block size limit can be guaranteed to provide enough space for every
possible demand - or even any particular demand - unless strong
centralization of the mining ecosystem is expected. Because of that, the
development of a fee market and the evolution towards an ecosystem that is
able to cope with block space competition should be considered healthy."

-- 
Pieter

[-- Attachment #2: Type: text/html, Size: 2942 bytes --]

Re: [bitcoin-dev] Block size following technological growth

[Gavin Andresen]

[-- Attachment #1: Type: text/plain, Size: 495 bytes --]

On Thu, Aug 6, 2015 at 10:06 AM, Pieter Wuille <pieter.wuille@gmail.com>
wrote:

> But you seem to consider that a bad thing. Maybe saying that you're
> claiming that this equals Bitcoin failing is an exaggeration, but you do
> believe that evolving towards an ecosystem where there is competition for
> block space is a bad thing, right?
>

No, competition for block space is good.

What is bad is artificially limiting or centrally controlling the supply of
that space.

-- 
--
Gavin Andresen

[-- Attachment #2: Type: text/html, Size: 983 bytes --]

Re: [bitcoin-dev] Block size following technological growth

[Pieter Wuille]

[-- Attachment #1: Type: text/plain, Size: 1650 bytes --]

On Thu, Aug 6, 2015 at 4:21 PM, Gavin Andresen <gavinandresen@gmail.com>
wrote:

> On Thu, Aug 6, 2015 at 10:06 AM, Pieter Wuille <pieter.wuille@gmail.com>
> wrote:
>
>> But you seem to consider that a bad thing. Maybe saying that you're
>> claiming that this equals Bitcoin failing is an exaggeration, but you do
>> believe that evolving towards an ecosystem where there is competition for
>> block space is a bad thing, right?
>>
>
> No, competition for block space is good.
>

So if we would have 8 MB blocks, and there is a sudden influx of users (or
settlement systems, who serve much more users) who want to pay high fees
(let's say 20 transactions per second) making the block chain inaccessible
for low fee transactions, and unreliable for medium fee transactions (for
any value of low, medium, and high), would you be ok with that? If so, why
is 8 MB good but 1 MB not? To me, they're a small constant factor that does
not fundamentally improve the scale of the system. I dislike the outlook of
"being forever locked at the same scale" while technology evolves, so my
proposal tries to address that part. It intentionally does not try to
improve a small factor, because I don't think it is valuable.

What is bad is artificially limiting or centrally controlling the supply of
> that space.
>

It's exactly as centrally limited as the finite supply of BTC - by
consensus. You and I may agree that a finite supply is a good thing, and
may disagree about whether a consensus rule about the block size is a good
idea (and if so, at what level), but it's a choice we make as a community
about the rules of the system we want to use.

-- 
Pieter

[-- Attachment #2: Type: text/html, Size: 2628 bytes --]

[bitcoin-dev] Fwd: Block size following technological growth

[Gavin Andresen]

[-- Attachment #1: Type: text/plain, Size: 1474 bytes --]

On Thu, Aug 6, 2015 at 10:53 AM, Pieter Wuille <pieter.wuille@gmail.com>
wrote:

> So if we would have 8 MB blocks, and there is a sudden influx of users (or
> settlement systems, who serve much more users) who want to pay high fees
> (let's say 20 transactions per second) making the block chain inaccessible
> for low fee transactions, and unreliable for medium fee transactions (for
> any value of low, medium, and high), would you be ok with that?


Yes, that's fine. If the network cannot handle the transaction volume that
people want to pay for, then the marginal transactions are priced out. That
is true today (otherwise ChangeTip would be operating on-blockchain), and
will be true forever.


> If so, why is 8 MB good but 1 MB not? To me, they're a small constant
> factor that does not fundamentally improve the scale of the system.


"better is better" -- I applaud efforts to fundamentally improve the
scalability of the system, but I am an old, cranky, pragmatic engineer who
has seen that successful companies tackle problems that arise and are
willing to deploy not-so-perfect solutions if they help whatever short-term
problem they're facing.


> I dislike the outlook of "being forever locked at the same scale" while
> technology evolves, so my proposal tries to address that part. It
> intentionally does not try to improve a small factor, because I don't think
> it is valuable.


I think consensus is against you on that point.

-- 
--
Gavin Andresen

[-- Attachment #2: Type: text/html, Size: 2335 bytes --]

Re: [bitcoin-dev] Fwd: Block size following technological growth

[Pieter Wuille]

[-- Attachment #1: Type: text/plain, Size: 2693 bytes --]

On Thu, Aug 6, 2015 at 5:06 PM, Gavin Andresen <gavinandresen@gmail.com>
wrote:

> On Thu, Aug 6, 2015 at 10:53 AM, Pieter Wuille <pieter.wuille@gmail.com>
> wrote:
>
>> So if we would have 8 MB blocks, and there is a sudden influx of users
>> (or settlement systems, who serve much more users) who want to pay high
>> fees (let's say 20 transactions per second) making the block chain
>> inaccessible for low fee transactions, and unreliable for medium fee
>> transactions (for any value of low, medium, and high), would you be ok with
>> that?
>
>
> Yes, that's fine. If the network cannot handle the transaction volume that
> people want to pay for, then the marginal transactions are priced out. That
> is true today (otherwise ChangeTip would be operating on-blockchain), and
> will be true forever.
>

The network can "handle" any size. I believe that if a majority of miners
forms SPV mining agreements, then they are no longer affected by the block
size, and benefit from making their blocks slow to validate for others (as
long as the fee is negligable compared to the subsidy). I'll try to find
the time to implement that in my simulator. Some hardware for full nodes
will always be able to validate and index the chain, so nobody needs to run
a pesky full node anymore and they can just use a web API to validate
payments.

Being able the "handle" a particular rate is not a boolean question. It's a
question of how much security, centralization, and risk for systemic error
we're willing to tolerate. These are not things you can just observe, so
let's keep talking about the risks, and find a solution that we agree on.


>
>> If so, why is 8 MB good but 1 MB not? To me, they're a small constant
>> factor that does not fundamentally improve the scale of the system.
>
>
> "better is better" -- I applaud efforts to fundamentally improve the
> scalability of the system, but I am an old, cranky, pragmatic engineer who
> has seen that successful companies tackle problems that arise and are
> willing to deploy not-so-perfect solutions if they help whatever short-term
> problem they're facing.
>

I don't believe there is a short-term problem. If there is one now, there
will be one too at 8 MB blocks (or whatever actual size blocks are
produced).


>
>
>> I dislike the outlook of "being forever locked at the same scale" while
>> technology evolves, so my proposal tries to address that part. It
>> intentionally does not try to improve a small factor, because I don't think
>> it is valuable.
>
>
> I think consensus is against you on that point.
>

Maybe. But I believe that it is essential to not take unnecessary risks,
and find a non-controversial solution.

-- 
Pieter

[-- Attachment #2: Type: text/html, Size: 4250 bytes --]

Re: [bitcoin-dev] Fwd: Block size following technological growth

[Michael Naber]

[-- Attachment #1: Type: text/plain, Size: 3345 bytes --]

How many nodes are necessary to ensure sufficient network reliability? Ten,
a hundred, a thousand? At what point do we hit the point of diminishing
returns, where adding extra nodes starts to have negligible impact on the
overall reliability of the system?





On Thu, Aug 6, 2015 at 10:26 AM, Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Thu, Aug 6, 2015 at 5:06 PM, Gavin Andresen <gavinandresen@gmail.com>
> wrote:
>
>> On Thu, Aug 6, 2015 at 10:53 AM, Pieter Wuille <pieter.wuille@gmail.com>
>> wrote:
>>
>>> So if we would have 8 MB blocks, and there is a sudden influx of users
>>> (or settlement systems, who serve much more users) who want to pay high
>>> fees (let's say 20 transactions per second) making the block chain
>>> inaccessible for low fee transactions, and unreliable for medium fee
>>> transactions (for any value of low, medium, and high), would you be ok with
>>> that?
>>
>>
>> Yes, that's fine. If the network cannot handle the transaction volume
>> that people want to pay for, then the marginal transactions are priced out.
>> That is true today (otherwise ChangeTip would be operating on-blockchain),
>> and will be true forever.
>>
>
> The network can "handle" any size. I believe that if a majority of miners
> forms SPV mining agreements, then they are no longer affected by the block
> size, and benefit from making their blocks slow to validate for others (as
> long as the fee is negligable compared to the subsidy). I'll try to find
> the time to implement that in my simulator. Some hardware for full nodes
> will always be able to validate and index the chain, so nobody needs to run
> a pesky full node anymore and they can just use a web API to validate
> payments.
>
> Being able the "handle" a particular rate is not a boolean question. It's
> a question of how much security, centralization, and risk for systemic
> error we're willing to tolerate. These are not things you can just observe,
> so let's keep talking about the risks, and find a solution that we agree on.
>
>
>>
>>> If so, why is 8 MB good but 1 MB not? To me, they're a small constant
>>> factor that does not fundamentally improve the scale of the system.
>>
>>
>> "better is better" -- I applaud efforts to fundamentally improve the
>> scalability of the system, but I am an old, cranky, pragmatic engineer who
>> has seen that successful companies tackle problems that arise and are
>> willing to deploy not-so-perfect solutions if they help whatever short-term
>> problem they're facing.
>>
>
> I don't believe there is a short-term problem. If there is one now, there
> will be one too at 8 MB blocks (or whatever actual size blocks are
> produced).
>
>
>>
>>
>>> I dislike the outlook of "being forever locked at the same scale" while
>>> technology evolves, so my proposal tries to address that part. It
>>> intentionally does not try to improve a small factor, because I don't think
>>> it is valuable.
>>
>>
>> I think consensus is against you on that point.
>>
>
> Maybe. But I believe that it is essential to not take unnecessary risks,
> and find a non-controversial solution.
>
> --
> Pieter
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 5557 bytes --]

Re: [bitcoin-dev] Fwd: Block size following technological growth

[Pieter Wuille]

[-- Attachment #1: Type: text/plain, Size: 1182 bytes --]

On Thu, Aug 6, 2015 at 8:43 PM, Michael Naber <mickeybob@gmail.com> wrote:

> How many nodes are necessary to ensure sufficient network reliability?
> Ten, a hundred, a thousand? At what point do we hit the point of
> diminishing returns, where adding extra nodes starts to have negligible
> impact on the overall reliability of the system?
>

It's not about reliability. There are plenty of nodes currently for
synchronization and other network functions.

It's about reduction of trust. Running a full node and using it verify your
transactions is how you get personal assurance that everyone on the network
is following the rules. And if you don't do so yourself, the knowledge that
others are using full nodes and relying on them is valuable. Someone just
running 1000 nodes in a data center and not using them for anything does
not do anything for this, it's adding network capacity without use.

That doesn't mean that the full node count (or the reachable full node
count even) are meaningless numbers. They are an indication of how hard it
is (for various reasons) to run/use a full node, and thus provide feedback.
But they are not the goal, just an indicator.

-- 
Pieter

[-- Attachment #2: Type: text/html, Size: 1588 bytes --]

Re: [bitcoin-dev] Fwd: Block size following technological growth

[Thomas Zander]

On Thursday 6. August 2015 20.52.28 Pieter Wuille via bitcoin-dev wrote:
> It's about reduction of trust. Running a full node and using it verify your
> transactions is how you get personal assurance that everyone on the network
> is following the rules. And if you don't do so yourself, the knowledge that
> others are using full nodes and relying on them is valuable. Someone just
> running 1000 nodes in a data center and not using them for anything does
> not do anything for this, it's adding network capacity without use.
> 
> That doesn't mean that the full node count (or the reachable full node
> count even) are meaningless numbers. They are an indication of how hard it
> is (for various reasons) to run/use a full node, and thus provide feedback.
> But they are not the goal, just an indicator.

You make a logical fallacy;

I would agree that nodes are there for people to stop trusting someone that 
they have no trust-relationship with.

But your conclusion that low node count is an indication that its hard to run 
one discards your own point.  You forget the point that running a node is only 
needed if you don't know anyone you can trust to run it for you.  I'm pretty 
darn sure that this will have a bigger effect on nodecount than how hard it 
is.
Or, in other words, without a need to run a node you can't judge the 
difficulty of why there aren't more running.


From another mail;
On Thursday 6. August 2015 17.26.11 Pieter Wuille via bitcoin-dev wrote:
> Maybe. But I believe that it is essential to not take unnecessary risks,
> and find a non-controversial solution.

This is a very political answer; it doesn't actually say anything since 
'unnecessary' is a personal judgment. Everyone will agree with you, but that 
doesn't mean anything.

-- 
Tom Zander

Re: [bitcoin-dev] Fwd: Block size following technological growth

[Pieter Wuille]

[-- Attachment #1: Type: text/plain, Size: 1271 bytes --]

On Fri, Aug 7, 2015 at 6:06 PM, Thomas Zander via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> You make a logical fallacy;
>
> I would agree that nodes are there for people to stop trusting someone that
> they have no trust-relationship with.
>

Yay, trust!


> But your conclusion that low node count is an indication that its hard to
> run
> one discards your own point.  You forget the point that running a node is
> only
> needed if you don't know anyone you can trust to run it for you.  I'm
> pretty
> darn sure that this will have a bigger effect on nodecount than how hard it
> is.
>

I never said it is the only factor that influences node count.

Or, in other words, without a need to run a node you can't judge the
> difficulty of why there aren't more running.
>

If the incentives for running a node don't weight up against the
cost/difficulty using a full node yourself for a majority of people in the
ecosystem, I would argue that there is a problem. As Bitcoin's fundamental
improvement over other systems is the lack of need for trust, I believe
that with increased adoption should also come an increased (in absolute
terms) incentive for people to use a full node. I'm seeing the opposite
trend, and that is worrying IMHO.

-- 
Pieter

[-- Attachment #2: Type: text/html, Size: 1981 bytes --]

Re: [bitcoin-dev] Fwd: Block size following technological growth

[Thomas Zander]

On Friday 7. August 2015 18.30.28 Pieter Wuille wrote:
> On Fri, Aug 7, 2015 at 6:06 PM, Thomas Zander via bitcoin-dev <
> > But your conclusion that low node count is an indication that its hard
> > to run one discards your own point.  You forget the point that running
> > a node is only needed if you don't know anyone you can trust to run it
> > for you.  I'm  pretty darn sure that this will have a bigger effect on
> > nodecount than how hard it is.
> 
> I never said it is the only factor that influences node count.

You wrote;
>  They are an indication of how hard [node count] is (for various 
>  reasons) to run/use a full node, and thus provide feedback.

You clearly indicated that node count is an indicator of how hard it is to run 
a node.
Thats like saying something is too expensive because we don't sell enough. It 
forgets to ask the question of need. Do people want it.

Like in our case the need to run a node in the first place.


> If the incentives for running a node don't weight up against the
> cost/difficulty using a full node yourself for a majority of people in the
> ecosystem, I would argue that there is a problem. As Bitcoin's fundamental
> improvement over other systems is the lack of need for trust, I believe
> that with increased adoption should also come an increased (in absolute
> terms) incentive for people to use a full node. I'm seeing the opposite
> trend, and that is worrying IMHO.

And you do the same thing again; you dismiss the need factor.

Most merchants have no need for a node, most miners don't even want to run one 
anymore. Users don't make a significant amount of payments to care.

Any conclusions with regards to difficulty of running a node based on max-
blocksize is speculation without numbers; the only numbers you have is 
historical node count, and they don't mean shit because the need has not 
grown.
For instance, merchants are told to trust someone like bitpay.


Historical node-count says nothing. Anyone using it for the blocksize debate 
is speculating without basis.
-- 
Thomas Zander

Re: [bitcoin-dev] Fwd: Block size following technological growth

[Pieter Wuille]

[-- Attachment #1: Type: text/plain, Size: 1179 bytes --]

On Fri, Aug 7, 2015 at 7:00 PM, Thomas Zander via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> > If the incentives for running a node don't weight up against the
> > cost/difficulty using a full node yourself for a majority of people in
> the
> > ecosystem, I would argue that there is a problem. As Bitcoin's
> fundamental
> > improvement over other systems is the lack of need for trust, I believe
> > that with increased adoption should also come an increased (in absolute
> > terms) incentive for people to use a full node. I'm seeing the opposite
> > trend, and that is worrying IMHO.
>
> And you do the same thing again; you dismiss the need factor.
>

Of course there is a need. It's the primary mechanism that keeps Bitcoin
secure and immune from malicious influence.

Of course not everyone needs to run a node. But that leaves the
responsibility on us - the community - to help the situation by not making
it too hard to run a node. And I see the block size as the primary way
through which we do that.

If the impact of the system goes us, so should the - joint - incentives to
keep it secure. And I think we're (slowly) failing at that.

-- 
Pieter

[-- Attachment #2: Type: text/html, Size: 1664 bytes --]

Re: [bitcoin-dev] Fwd: Block size following technological growth

[Thomas Zander]

On Friday 7. August 2015 19.09.30 Pieter Wuille wrote:
> > And you do the same thing again; you dismiss the need factor.
> 
> Of course there is a need. It's the primary mechanism that keeps Bitcoin
> secure and immune from malicious influence.

I see a pretty big problem if this really is your insight, the need an 
individual has for running a node is a completely different concept than the 
need for nodes to exist.  And, really, you are describing miners, not nodes.

good thing is that you seem to agree with me as your continue with;

> Of course not everyone needs to run a node. 

Thats the 'need' I was talking about.
As we concluded in our previous email, the need to run a node is inversely 
proportional to the ability (or willingness) to trust others.
And lets face it, practically everyone trusts others with their money today.


> But that leaves the
> responsibility on us - the community - to help the situation by not making
> it too hard to run a node. And I see the block size as the primary way
> through which we do that.

That won't really have any influence, economics 101 says that it doesn't work 
that way.  Lowering the cost on a product won't make it sell more without the 
people wanting or needing the product.

> If the impact of the system goes u[p], so should the - joint - incentives to
> keep it secure. And I think we're (slowly) failing at that.

That is your opinion. At least, I don't see that conclusion supported by 
evidence.
I'll defer to Gavins emails that countered this point better.

-- 
Thomas Zander

Re: [bitcoin-dev] Fwd: Block size following technological growth

[Adam Back]

On 7 August 2015 at 22:35, Thomas Zander via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> the need an individual has for running a node is a completely different concept than the
> need for nodes to exist.  And, really, you are describing miners, not nodes.

It's not as simple as trusting miners, Bitcoin security needs some
reasonable portion of economic interest to be validating their receipt
of coins against a full node they run.

I do it myself because I dont want to lose money, as do many power
users.  Most bitcoin ecosystem companies do it.  You dont have to run
it all the time, just sync it when you want to check your own coin
receipt with higher assurance.

> As we concluded in our previous email, the need to run a node is inversely
> proportional to the ability (or willingness) to trust others.

Even if you are willing to trust others, trusting miners or random
full nodes would be unsafe if not for the reasonable portion of
economic interest validating their own received coins.  That holds
miners honest, otherwise they could more easily present fake
information to SPV users.

> And lets face it, practically everyone trusts others with their money today.

Bitcoin's very reason for existence is to avoid that need.  For people
fully happy to trust others with their money, Bitcoin may not be as
interesting to them.

>> If the impact of the system goes u[p], so should the - joint - incentives to
>> keep it secure. And I think we're (slowly) failing at that.
>
> That is your opinion.

What Pieter said is an accurate summary and non-controversial.

Adam

Re: [bitcoin-dev] Fwd: Block size following technological growth

[Dave Scotese]

[-- Attachment #1: Type: text/plain, Size: 3719 bytes --]

Bitcoin is an irreversible payment system.  When you pay someone using its
main selling point, which is removing the need for physical presence, you
are trusting that person.  Bitcoin doesn't obviate trust.  It obviates
authority.  Centralization of trust is what creates the authority that we
all recognize as bad for our species.  It does this by making the
authority's use of coercion acceptable.

Bitcoin removes the need for authority, not trust.  It replaces trust in a
single body with trust in a majority.  We want that majority to be healthy
and varied (as opposed to largely co-opted by some authority). The
replacement has two effects.  1) It is very difficult for any single body
to become the (coercive) authority that everyone has to trust (like central
banks). 2) It is very easy for a person to find a different single body to
trust if they don't like the one they are trusting now - or even stop
trusting one body and trust the majority instead, relying on #1 for
protection, and taking on the responsibility of running a full node.

The philosophical foundation of a thing is ultimately the basis of its
value, so I thought it useful to point out the distinction between
authority and trust in the bitcoin ecosystem.  I welcome disagreements with
my philosophical position, as that is how I learn.

Dave.

On Fri, Aug 7, 2015 at 3:53 PM, Adam Back via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On 7 August 2015 at 22:35, Thomas Zander via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > the need an individual has for running a node is a completely different
> concept than the
> > need for nodes to exist.  And, really, you are describing miners, not
> nodes.
>
> It's not as simple as trusting miners, Bitcoin security needs some
> reasonable portion of economic interest to be validating their receipt
> of coins against a full node they run.
>
> I do it myself because I dont want to lose money, as do many power
> users.  Most bitcoin ecosystem companies do it.  You dont have to run
> it all the time, just sync it when you want to check your own coin
> receipt with higher assurance.
>
> > As we concluded in our previous email, the need to run a node is
> inversely
> > proportional to the ability (or willingness) to trust others.
>
> Even if you are willing to trust others, trusting miners or random
> full nodes would be unsafe if not for the reasonable portion of
> economic interest validating their own received coins.  That holds
> miners honest, otherwise they could more easily present fake
> information to SPV users.
>
> > And lets face it, practically everyone trusts others with their money
> today.
>
> Bitcoin's very reason for existence is to avoid that need.  For people
> fully happy to trust others with their money, Bitcoin may not be as
> interesting to them.
>
> >> If the impact of the system goes u[p], so should the - joint -
> incentives to
> >> keep it secure. And I think we're (slowly) failing at that.
> >
> > That is your opinion.
>
> What Pieter said is an accurate summary and non-controversial.
>
> Adam
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>



-- 
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto

[-- Attachment #2: Type: text/html, Size: 4865 bytes --]

Re: [bitcoin-dev] Fwd: Block size following technological growth

[Gavin Andresen]

[-- Attachment #1: Type: text/plain, Size: 1627 bytes --]

On Fri, Aug 7, 2015 at 12:30 PM, Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> If the incentives for running a node don't weight up against the
> cost/difficulty using a full node yourself for a majority of people in the
> ecosystem, I would argue that there is a problem. As Bitcoin's fundamental
> improvement over other systems is the lack of need for trust, I believe
> that with increased adoption should also come an increased (in absolute
> terms) incentive for people to use a full node. I'm seeing the opposite
> trend, and that is worrying IMHO.


Are you saying that unless the majority of people in the ecosystem decide
to trust nothing but the genesis block hash (decide to run a full node)
there is a problem?

If so, then we do have a fundamental difference of opinion, but I've
misunderstood how you think about trust/centralization/convenience
tradeoffs in the past.

I believe people in the Bitcoin ecosystem will choose different tradeoffs,
and I believe that is OK-- people should be free to make those tradeoffs.

And given that the majority of people in the ecosystem were deciding that
using a centralized service or an SPV-level-security wallet was better even
two or three years ago when blocks were tiny (I'd have to go back and dig
up number-of-full-nodes and number-of-active-wallets at the big web-wallet
providers, but I bet there were an order of magnitude more people using
centralized services than running full nodes even back then), I firmly
believe that block size has very little to do with the decision to run a
full node or not.


-- 
--
Gavin Andresen

[-- Attachment #2: Type: text/html, Size: 2240 bytes --]

Re: [bitcoin-dev] Fwd: Block size following technological growth

[Jameson Lopp]

[-- Attachment #1: Type: text/plain, Size: 3224 bytes --]

Anecdotally I've seen two primary reasons posed for not running a node:

1) For enthusiasts who want to altruistically run a node at home, it's
usually a bandwidth / quality of service problem. There are tools to help
work around this, but most users aren't sysadmins and would prefer a simple
configuration option in bitcoind and a slider / selector in the QT client
to throttle the total bandwidth usage. This issue has been open for years:
https://github.com/bitcoin/bitcoin/issues/273 - if you want to make it
easier for enthusiasts to run nodes, I'd start there.

2) For businesses, it's not so much an issue with the resources of
installing / running / maintaining a node, it's an issue with the lack of
indexing options offered by bitcoind. Thus the business will also need to
run their own indexing solution - an out-of-the-box solution such as
Insight or Toshi might work, but for more custom indexing you have to roll
your own software - this is where it actually becomes expensive.

Depending upon the query volume / latency needs of the business, it may not
make sense to bother administering bitcoind instances, the indexing
software, and its databases - using a third party API will probably be more
efficient.

- Jameson

On Fri, Aug 7, 2015 at 1:50 PM, Gavin Andresen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> On Fri, Aug 7, 2015 at 12:30 PM, Pieter Wuille via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> If the incentives for running a node don't weight up against the
>> cost/difficulty using a full node yourself for a majority of people in the
>> ecosystem, I would argue that there is a problem. As Bitcoin's fundamental
>> improvement over other systems is the lack of need for trust, I believe
>> that with increased adoption should also come an increased (in absolute
>> terms) incentive for people to use a full node. I'm seeing the opposite
>> trend, and that is worrying IMHO.
>
>
> Are you saying that unless the majority of people in the ecosystem decide
> to trust nothing but the genesis block hash (decide to run a full node)
> there is a problem?
>
> If so, then we do have a fundamental difference of opinion, but I've
> misunderstood how you think about trust/centralization/convenience
> tradeoffs in the past.
>
> I believe people in the Bitcoin ecosystem will choose different tradeoffs,
> and I believe that is OK-- people should be free to make those tradeoffs.
>
> And given that the majority of people in the ecosystem were deciding that
> using a centralized service or an SPV-level-security wallet was better even
> two or three years ago when blocks were tiny (I'd have to go back and dig
> up number-of-full-nodes and number-of-active-wallets at the big web-wallet
> providers, but I bet there were an order of magnitude more people using
> centralized services than running full nodes even back then), I firmly
> believe that block size has very little to do with the decision to run a
> full node or not.
>
>
> --
> --
> Gavin Andresen
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 4482 bytes --]

Re: [bitcoin-dev] Fwd: Block size following technological growth

[Pieter Wuille]

[-- Attachment #1: Type: text/plain, Size: 3067 bytes --]

On Aug 7, 2015 7:50 PM, "Gavin Andresen" <gavinandresen@gmail.com> wrote:
>
>
> On Fri, Aug 7, 2015 at 12:30 PM, Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> If the incentives for running a node don't weight up against the
cost/difficulty using a full node yourself for a majority of people in the
ecosystem, I would argue that there is a problem. As Bitcoin's fundamental
improvement over other systems is the lack of need for trust, I believe
that with increased adoption should also come an increased (in absolute
terms) incentive for people to use a full node. I'm seeing the opposite
trend, and that is worrying IMHO.
>
>
> Are you saying that unless the majority of people in the ecosystem decide
to trust nothing but the genesis block hash (decide to run a full node)
there is a problem?

I shouldn't have said majority, sorry. But I do believe that as the odds at
stake in the system go up, so should those who take an interest in
verifying. That doesn't seem to be the case, and is a problem, where that
is a result of the block chain size or not.

> If so, then we do have a fundamental difference of opinion, but I've
misunderstood how you think about trust/centralization/convenience
tradeoffs in the past.
>
> I believe people in the Bitcoin ecosystem will choose different
tradeoffs, and I believe that is OK-- people should be free to make those
tradeoffs.

I agree. Though I believe that the blockchain itself cannot offer many
tradeoffs, and by trying to make it scale we hurt the whole system. The
place to introduce tradeoffs is in layers on top - there you can build
systems with various levels of trust without hurting others.

> And given that the majority of people in the ecosystem were deciding that
using a centralized service or an SPV-level-security wallet was better even
two or three years ago when blocks were tiny (I'd have to go back and dig
up number-of-full-nodes and number-of-active-wallets at the big web-wallet
providers, but I bet there were an order of magnitude more people using
centralized services than running full nodes even back then).

That's inevitable, I'm sure.

> I firmly believe that block size has very little to do with the decision
to run a full node or not.

Within certain limits, maybe not. Within certain limits, maybe it also does
not incentivize trusted miner setups like SPV mining (which hurt the
security of SPV nodes tremendously).

But if the reason for increasing is because you fear a change of economics,
then it means you prefer not dealing with that change. I believe you prefer
not dealing with it ever, and would rather have a system where as much as
possible happens on-chain, even when we unknowingly go beyond those limits.
I think we don't do the ecosystem a service by promising that such a future
is possible without compromises.

So, I think the block size should follow technological evolution, and not
reenforce the belief that the block size should follow demand. There will
always be demand, and we should learn to deal with it.

-- 
Pieter

[-- Attachment #2: Type: text/html, Size: 3532 bytes --]

Re: [bitcoin-dev] Fwd: Block size following technological growth

[Thomas Zander]

On Friday 7. August 2015 20.10.48 Pieter Wuille wrote:
> On Aug 7, 2015 7:50 PM, "Gavin Andresen" <gavinandresen@gmail.com> wrote:
> > I believe people in the Bitcoin ecosystem will choose different
> > tradeoffs, and I believe that is OK-- people should be free to make those
> > tradeoffs.
> 
> I agree. Though I believe that the blockchain itself cannot offer many
> tradeoffs, and by trying to make it scale we hurt the whole system. The
> place to introduce tradeoffs is in layers on top - there you can build
> systems with various levels of trust without hurting others.

Pieter, you either misunderstood or misquoted Gavin here.
The tradeoffs Gavin talks about are about trusting your own node or using a 
centralized system (as the two extremes in a spectrum).

Your answer talks about something completely different. Not sure how your 
answer fits in this conversation, although, you do seem to use these 
misunderstandings often to push your own position in a way that to the naive 
reader it sounds like others agree with you.  Please try to be more concise 
and on-topic.

-- 
Thomas Zander

Re: [bitcoin-dev] Fwd: Block size following technological growth

[Thomas Zander]

On Friday 7. August 2015 20.10.48 Pieter Wuille wrote:
> But if the reason for increasing is because you fear a change of economics,
> then it means you prefer not dealing with that change. 

Let me quote yourself;

On Thursday 6. August 2015 17.26.11 Pieter Wuille via bitcoin-dev wrote:
> I believe that it is essential to not take unnecessary risks,
> and find a non-controversial solution.

You want to change the basic economics of Bitcoin itself.
If anything is "unnecessary risks", that would be a clear contender.

-- 
Thomas Zander

Re: [bitcoin-dev] Block size following technological growth

[Tom Harding]

On 8/6/2015 7:53 AM, Pieter Wuille via bitcoin-dev wrote:
>
> So if we would have 8 MB blocks, and there is a sudden influx of users
> (or settlement systems, who serve much more users) who want to pay
> high fees (let's say 20 transactions per second) making the block
> chain inaccessible for low fee transactions, and unreliable for medium
> fee transactions (for any value of low, medium, and high), would you
> be ok with that?

Gavin has answered this question in the clearest way possible -- in
tested C++ code, which increases capacity only on a precise schedule for
20 years, then stops increasing.

Re: [bitcoin-dev] Block size following technological growth

[Peter Todd]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256



On 6 August 2015 10:21:54 GMT-04:00, Gavin Andresen via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>On Thu, Aug 6, 2015 at 10:06 AM, Pieter Wuille
><pieter.wuille@gmail.com>
>wrote:
>
>> But you seem to consider that a bad thing. Maybe saying that you're
>> claiming that this equals Bitcoin failing is an exaggeration, but you
>do
>> believe that evolving towards an ecosystem where there is competition
>for
>> block space is a bad thing, right?
>>
>
>No, competition for block space is good.
>
>What is bad is artificially limiting or centrally controlling the
>supply of
>that space.

Incidentally, why is that competition good? What specific design goal is that competition achieving?

-----BEGIN PGP SIGNATURE-----

iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJVw9fn
AAoJEMCF8hzn9Lnc47AH/idUy2rGlUCBTTU/jDpNjMy5VGYYRawx50lrnGBufvIJ
8ZbFleI+gbnFCaJiaPF9ZN0mTjFWv7YcFzlwoPam11UfhEYI2Cl1aGha+R7g/18t
+1256i4Ykg0uEqrX9ITpYyzoBsVMaqsaOGBbJbUUtHoD1V1GCYBYi5JAl1msGjH/
2o+/Gh7gBB1Ll6SPtgeM1cCudRXA7PJr3WTjkLy8oGKY7lmVsPUfQ7h3OBJMTwa5
B+i1KTpSWdWyciWk0a3z7cxNfaajd7Pj3jZYoeCzKJdZja7lnB7FzUnaPE3y0wse
Bby6w48R4VeYsVhM+GolvRDVVSQN9XNfRSiRjuMW4Eg=
=wzhz
-----END PGP SIGNATURE-----

Re: [bitcoin-dev] Block size following technological growth

[Jorge Timón]

On Thu, Aug 6, 2015 at 3:40 PM, Gavin Andresen <gavinandresen@gmail.com> wrote:
> On Wed, Aug 5, 2015 at 9:26 PM, Jorge Timón
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> This is a much more reasonable position. I wish this had been starting
>> point of this discussion instead of "the block size limit must be
>> increased as soon as possible or bitcoin will fail".
>
>
> It REALLY doesn't help the debate when you say patently false statements
> like that.

I'm pretty sure that I can quote Mike Hearn with a sentence extremely
similar to that in this forum or in some of his blog posts (not in
https://medium.com/@octskyward/crash-landing-f5cc19908e32 at a first
glance...).
But yeah, what people said in the past is not very important: people
change their minds (they even acknowledge their mistake some times).
What interests me more it's what people think now.

I don't want to put words in your mouth and you are more than welcome
to correct what I think you think with what you really think.
All I'm trying to do is framing your fears properly.
If I say "all fears related to not raising the block size limit in the
short term can be summarized as a fear of fees rising in the short
term".
Am I correct? Am I missing some other argument?
Of course, problems that need to be solved regardless of the block
size (like an unbounded mempool) should not be considered for this
discussion.

> My first blog post on this issue is here:
>   http://gavinandresen.ninja/why-increasing-the-max-block-size-is-urgent
>
> ... and I NEVER say "Bitcoin will fail".  I say:
>
> "If the number of transactions waiting gets large enough, the end result
> will be an over-saturated network, busy doing nothing productive. I don’t
> think that is likely– it is more likely people just stop using Bitcoin
> because transaction confirmation becomes increasingly unreliable."

If you pay high enough fees your transactions will be likely mined in
the next block.
So this seems to be reducible to the "fees rising" concern unless I am
missing something.

> So please stop with the over-the-top claims about what "the other side"
> believe, there are enough of those (on both sides of the debate) on reddit.
> I'd really like to focus on how to move forward, and how best to resolve
> difficult questions like this in the future.

I think I would have a much better understanding of what "the other
side" thinks if I ever got an answer to a couple of very simple
questions I have been repeating ad nausea:

1) If "not now" when will it be a good time to let fees rise above zero?

2) When will you consider a size to be too dangerous for centralization?
In other words, why 20 GB would have been safe but 21 GB wouldn't have
been (or the respective maximums and respective +1 for each block
increase proposal)?

On Thu, Aug 6, 2015 at 4:21 PM, Gavin Andresen <gavinandresen@gmail.com> wrote:
> What is bad is artificially limiting or centrally controlling the supply of
> that space.

3) Does this mean that you would be in favor of completely removing
the consensus rule that limits mining centralization by imposing an
artificial (like any other consensus rule) block size maximum?

I've been insistently repeating this question too.
Admittedly, it would be a great disappointment if your answer to this
question is "yes": that can only mean that either you don't understand
how the consensus rule limits mining centralization or that you don't
care about mining centralization at all.

If you really want things to move forward, please, prove it by
answering these questions so that we don't have to imagine what the
answers are (because what we imagine is probably much worse than your
actual answers).
I'm more than willing to stop trying to imagine what "big block
advocates" think, but I need your answers from the "big block
advocates".

Asking repeatedly doesn't seem to be effective. So I will answer the
questions myself in the worse possible way I think a "big block
advocate" could answer them.
Feel free to replace my stupid answers with your own:

----------------------- (FICTION ANSWERS [given the lack of real answers])

3) Does this mean that you would be in favor of completely removing
the consensus rule that limits mining centralization by imposing an
artificial (like any other consensus rule) block size maximum?

Yes, I would remove the rule because I don't care about mining centralization.

2) When will you consider a size to be too dangerous for centralization?
In other words, why 20 GB would have been safe but 21 GB wouldn't have
been (or the respective maximums and respective +1 for each block
increase proposal)?

Never, as said I don't care about mining centralization.
I thought users and Bitcoin companies would agree with a 20 GB limit
hardfork with proper lobbying, but I certainly prefer 21 GB.
From 1 MB to infinity, the bigger the better, always.

1) If "not now" when will it be a good time to let fees rise above zero?

Never. Fees are just an excuse, the real goal is making Bitcoin centralized.

------------------------

I'm quite confident that you will have better answers than those.
Please, let me know what you think.

Re: [bitcoin-dev] Block size following technological growth

[Gavin Andresen]

[-- Attachment #1: Type: text/plain, Size: 965 bytes --]

On Thu, Aug 6, 2015 at 11:25 AM, Jorge Timón <jtimon@jtimon.cc> wrote:

> 1) If "not now" when will it be a good time to let fees rise above zero?
>

Fees are already above zero. See
http://gavinandresen.ninja/the-myth-of-not-full-blocks


> 2) When will you consider a size to be too dangerous for centralization?
> In other words, why 20 GB would have been safe but 21 GB wouldn't have
> been (or the respective maximums and respective +1 for each block
> increase proposal)?
>

http://gavinandresen.ninja/does-more-transactions-necessarily-mean-more-centralized

3) Does this mean that you would be in favor of completely removing
> the consensus rule that limits mining centralization by imposing an
> artificial (like any other consensus rule) block size maximum?
>

I don't believe that the maximum block size has much at all to do with
mining centralization, so I don't accept the premise of the question.

-- 
--
Gavin Andresen

[-- Attachment #2: Type: text/html, Size: 1984 bytes --]

Re: [bitcoin-dev] Block size following technological growth

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 1331 bytes --]

Whilst 1mb to 8mb might seem irrelevant from a pure computer science
perspective payment demand is not really infinite, at least not if by
"payment" we mean something resembling how current Bitcoin users use the
network.

If we define "payment" to mean the kind of thing that Bitcoin users and
enthusiasts have been doing up until now, then suddenly 1mb to 8mb makes a
ton of sense and doesn't really seem that small: we'd have to increase
usage by nearly an order of magnitude before it becomes an issue again!

If we think of Bitcoin as a business that serves customers, growing our
user base by an order of magnitude would be a great and celebration worthy
achievement! Not at all a small constant factor :)

And keeping the current user base happy and buying things is extremely
interesting, both to me and Gavin. Without users Bitcoin is nothing at all.
Not a settlement network, not anything.

It's actually going to be quite hard to grow that much. As the white paper
says, "the system works well enough for most transactions". And despite a
lot of effort by many people, killer apps that use Bitcoin's unique
features are still hit and miss. Perhaps Streamium, Lighthouse, ChangeTip,
some distributed exchange or something else will stimulate huge new demand
for transactions in future ..... but if so we're not there yet.

[-- Attachment #2: Type: text/html, Size: 1723 bytes --]

Re: [bitcoin-dev] Block size following technological growth

[Jorge Timón]

First of all, thank you very much for answering the questions, and
apologies for not having formulated them properly (fortunately that's
not an irreparable mistake).

On Thu, Aug 6, 2015 at 6:03 PM, Gavin Andresen <gavinandresen@gmail.com> wrote:
> On Thu, Aug 6, 2015 at 11:25 AM, Jorge Timón <jtimon@jtimon.cc> wrote:
>>
>> 1) If "not now" when will it be a good time to let fees rise above zero?
>
>
> Fees are already above zero. See
> http://gavinandresen.ninja/the-myth-of-not-full-blocks

When we talk about "fees" we're talking about different things. I
should have been more specific.
Average fees are greatly influenced by wallet and policy defaults, and
they also include extra fees that are included for fast confirmation.
I'm not talking about fast confirmation transactions, but about
non-urgent transactions.

What is the market minimum fee for miners to mine a transaction?

That's currently zero.
If you don't want to directly look at what blocks contain, we can also
use a fee estimator and define a "non-urgent period", say 1 week worth
of blocks (1008 blocks).
The chart in your link doesn't include a 1008 blocks line, but the 15
blocks (about 2.5 hours) line seems to already show zero fees:

http://img.svbtle.com/p4x3s7fn52sz9a.png

So I reformulate the question:

1) If "not now", when will it be a good time to let the "market
minimum fee for miners to mine a transaction" rise above zero?

>> 2) When will you consider a size to be too dangerous for centralization?
>> In other words, why 20 GB would have been safe but 21 GB wouldn't have
>> been (or the respective maximums and respective +1 for each block
>> increase proposal)?
>
>
> http://gavinandresen.ninja/does-more-transactions-necessarily-mean-more-centralized

This just shows where the 20 GB come from, not why you would reject 21 GB.
Let me rephrase.

2) Do you have any criterion (automatic or not) that can result in you
saying "no, this is too much" for any proposed size?
Since you don't think the consensus block size maximum limits mining
centralization (as you later say), it must be based on something else.
In any case, if you lack a criterion that's fine as well: it's never
too late to have one.
Would you agree that blocksize increase proposals should have such a
criterion/test?

>> 3) Does this mean that you would be in favor of completely removing
>> the consensus rule that limits mining centralization by imposing an
>> artificial (like any other consensus rule) block size maximum?
>
>
> I don't believe that the maximum block size has much at all to do with
> mining centralization, so I don't accept the premise of the question.

Ok, this is an enormous step forward in the discussion, thank you.
In my opinion all discussions will be sterile while we can't even
agree on what are the positive effects of the consensus rule that
supposedly needs to be changed.

It's not that you don't care about centralization, it's that you don't
believe that a consensus block size maximum limits centralization at
all.
This means that if I can convince you that the consensus block size
maximum does in fact limit centralization in any way, you may change
your views about the whole blocksize consensus rule change, you may
even take back or change your own proposal.
But let's leave that aside that for now.

Regardless of the history of the consensus rule (which I couldn't care
less about), I believe the only function that the maximum block size
rule currently serves is limiting centralization.
Since you deny that function, do you think the (artificial) consensus
rule is currently serving any other purpose that I'm missing?

If the answer is something along the lines of "not really, it's just
technical debt", then I think you should be honest and consequent, and
directly advocate for the complete removal of the consensus rule.

I really think conversations can't really advance until we clarify the
different positions about the discussed consensus rule current
purpose.

Re: [bitcoin-dev] Block size following technological growth

[Gavin Andresen]

[-- Attachment #1: Type: text/plain, Size: 2256 bytes --]

On Thu, Aug 6, 2015 at 1:15 PM, Jorge Timón <jtimon@jtimon.cc> wrote:

> So I reformulate the question:
>
> 1) If "not now", when will it be a good time to let the "market
> minimum fee for miners to mine a transaction" rise above zero?


Two answers:

1. If you are willing to wait an infinite amount of time, I think the
minimum fee will always be zero or very close to zero, so I think it's a
silly question.

2. The "market minimum fee" should be determined by the market. It should
not be up to us to decide "when is a good time."


> 2) Do you have any criterion (automatic or not) that can result in you
> saying "no, this is too much" for any proposed size?
>

Sure, if keeping up with transaction volume requires a cluster of computers
or more than "pretty good" broadband bandwidth I think that's too far.
That's where original 20MB limit comes from, otherwise I'd have proposed a
much higher limit.


> Would you agree that blocksize increase proposals should have such a
> criterion/test?


Although I've been very clear with my criterion, no, I don't think all
blocksize increase proposals should have to justify "why this size" or "why
this rate of increase." Part of my frustration with this whole debate is
we're talking about a sanity-check upper-limit; as long as it doesn't open
up some terrible new DoS possibility I don't think it really matters much
what the exact number is.



> Regardless of the history of the consensus rule (which I couldn't care
> less about), I believe the only function that the maximum block size
> rule currently serves is limiting centralization.
> Since you deny that function, do you think the (artificial) consensus
> rule is currently serving any other purpose that I'm missing?
>

It prevents trivial denial-of-service attacks (e.g. I promise to send you a
1 Terabyte block, then fill up your memory or disk...).

And please read what I wrote: I said that the block limit has LITTLE effect
on MINING centralization.  Not "no effect on any type of centralization."

If the limit was removed entirely, it is certainly possible we'd end up
with very few organizations (and perhaps zero individuals) running full
nodes.

-- 
--
Gavin Andresen

[-- Attachment #2: Type: text/html, Size: 3354 bytes --]

Re: [bitcoin-dev] Block size following technological growth

[Pieter Wuille]

[-- Attachment #1: Type: text/plain, Size: 1227 bytes --]

On Aug 6, 2015 9:42 PM, "Gavin Andresen via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
2. The "market minimum fee" should be determined by the market. It should
not be up to us to decide "when is a good time."

I partially agree. The community should decide what risks it is willing to
take, and set limits accordingly. Let the market decide how that space is
best used.

>
>>
>> Would you agree that blocksize increase proposals should have such a
>> criterion/test?
>
>
> Although I've been very clear with my criterion, no, I don't think all
blocksize increase proposals should have to justify "why this size" or "why
this rate of increase." Part of my frustration with this whole debate is
we're talking about a sanity-check upper-limit; as long as it doesn't open
up some terrible new DoS possibility I don't think it really matters much
what the exact number is.

It is only a DoS protection limit if you want to rely on trusting miners. I
prefer a system where I don't have to do that.

But I agree the numbers don't matter much, for a different reason: the
market will fill up whatever space is available, and we'll have the same
discussion when the new limit doesn't seem enough anymore.

-- 
Pieter

[-- Attachment #2: Type: text/html, Size: 1565 bytes --]

Re: [bitcoin-dev] Block size following technological growth

[Jorge Timón]

Really, thanks again for replying and not getting mad when I get your
thoughts wrong.
I believe that I've learned more about your position on the subject
today than in months of discussion and blogs (that's not a critique to
your blog post, it's just that they didn't answer to some questions
that I personally needed responded).

On Thu, Aug 6, 2015 at 9:42 PM, Gavin Andresen <gavinandresen@gmail.com> wrote:
> On Thu, Aug 6, 2015 at 1:15 PM, Jorge Timón <jtimon@jtimon.cc> wrote:
>>
>> So I reformulate the question:
>>
>> 1) If "not now", when will it be a good time to let the "market
>> minimum fee for miners to mine a transaction" rise above zero?
>
>
> Two answers:
>
> 1. If you are willing to wait an infinite amount of time, I think the
> minimum fee will always be zero or very close to zero, so I think it's a
> silly question.

I'm very happy to have made the stupid question then. It has revealed
another big difference in the fundamental assumptions we're using.

My assumption is that for any reasonable size, free transactions will
eventually disappear (assuming Bitcoin doesn't "fail" for some other
reason).
Maybe I'm being too optimistic about the demand side of the market in
the long term.

In contrast, your assumption seems to be (and please correct me on
anything I get wrong) that...

"The limit will always be big enough so that free transactions are
mined forever. Therefore fees just allow users to prioritize their
urgent transactions and relay policies to protect their nodes against
DoS attacks.
Well, obviously, they also serve to pay for mining in a low-subsidy
future, but even with the presence of free transactions, fees will be
enough to cover mining costs, or a new mechanisms will be developed to
make a low-total-reward blockchain safe or expensive proof of work
will be replaced or complemented with something else that's cheaper.
The main point is that fees are not a mechanism to decide what gets
priced out of the blockchain, because advancements in technology will
always give as enough room for free transactions."
- jtimon putting words in Gavin's mouth, with the only intention to
understand him better.

I'm using "free transactions" even though you said "zero or very close to zero".
To you, "zero or very close to zero" may be the same thing, but to me
zero and very close to zero are like...different galaxies.
To me, entering the "very close to zero galaxy" is a huge step in the
development of the fee market.
I've been always assuming that moving from zero to 1 satoshi was
precisely what "big block advocates" wanted to avoid.
What they meant by "Bitcoin is going to become a high-value only
network" and similar things.
Knowing that for "big block advocates" zero and "very close to zero"
are equally acceptable changes things.

> 2. The "market minimum fee" should be determined by the market. It should
> not be up to us to decide "when is a good time."

I completely agree, but the block size limit is a consensus rule that
doesn't adapt to the market. The market will adapt to whatever limit
is chosen by the consensus rules.

>> 2) Do you have any criterion (automatic or not) that can result in you
>> saying "no, this is too much" for any proposed size?
>
>
> Sure, if keeping up with transaction volume requires a cluster of computers
> or more than "pretty good" broadband bandwidth I think that's too far.
> That's where original 20MB limit comes from, otherwise I'd have proposed a
> much higher limit.
>
>> Would you agree that blocksize increase proposals should have such a
>> criterion/test?
>
>
> Although I've been very clear with my criterion, no, I don't think all
> blocksize increase proposals should have to justify "why this size" or "why
> this rate of increase."

I would really like a more formal criterion, ideally automatic (like
any other test, the parameters can be modified as technology
advances).
But fair enough, even though your criterion is too vague or not
future-proof enough, I guess it is still a criterion.
It seems that this is a matter of disagreements and ideal ways of
doing things and not really a disagreement on fundamental assumptions.
So it seems this question wasn't so interesting after all.

> Part of my frustration with this whole debate is
> we're talking about a sanity-check upper-limit; as long as it doesn't open
> up some terrible new DoS possibility I don't think it really matters much
> what the exact number is.

That's what you think you are discussing, but I (and probably some
other people) think we are discussing something entirely different.
Because we have a fundamentally different assumption on what the block
size limit is about.
I really hope that identifying these "fundamental assumption
discrepancies" (FAD from now own) will help us avoid circular
discussions so that everything is less frustrating and more productive
for everyone.

>> Regardless of the history of the consensus rule (which I couldn't care
>> less about), I believe the only function that the maximum block size
>> rule currently serves is limiting centralization.
>> Since you deny that function, do you think the (artificial) consensus
>> rule is currently serving any other purpose that I'm missing?
>
>
> It prevents trivial denial-of-service attacks (e.g. I promise to send you a
> 1 Terabyte block, then fill up your memory or disk...).

This could be prevented in some other ways. If this is the only
concern, it doesn't need to be a consensus rule.

> And please read what I wrote: I said that the block limit has LITTLE effect
> on MINING centralization.  Not "no effect on any type of centralization."
>
> If the limit was removed entirely, it is certainly possible we'd end up with
> very few organizations (and perhaps zero individuals) running full nodes.

Sorry, another try:

You think the maximum block size rule serves to limit centralization
by limiting how hard it is to run a full node.
I agree with that, but I would add something more and you wouldn't:

The maximum block size consensus rule limits how hard it is to be a
competitive miner.

In other words, you think the last statement is false or incorrect.

Meta: I think we should try to collect and list more of this "FADs"
(we have at least 2 of them already). If you think it can be useful,
I'm more than happy to repeat this process in the opposite direction:
you make the questions and I give the answers, you write what you
think I think and I correct you in iterations. Probably we should
finish with you correcting what I think you think first. I am really
excited about understanding your point of view better.

Stupid humor (hopefully not out of context and not offensive): I'm
happy to discover that what I thought it was FUD was just FAD.
More seriously, I'm really happy for your interest in understanding
and being understood.
Let's worry about where do we think differently first and about who is
right on each point later.
In the end, only the conclusions on each point will matter and not who
claimed the final conclusions (in the points where we find them) first
(if we get to final common conclusions on that point at all).

Re: [bitcoin-dev] Block size following technological growth

[Elliot Olds]

[-- Attachment #1: Type: text/plain, Size: 12964 bytes --]

On Wed, Aug 5, 2015 at 6:26 PM, Jorge Timón <jtimon@jtimon.cc> wrote:
>
>
> Given that for any non-absurdly-big size some transactions will
> eventually be priced out, and that the consensus rule serves for
> limiting mining centralization (and more indirectly centralization in
> general) and not about trying to set a given average transaction fee,
> I think the current level of mining centralization will always be more
> relevant than the current fee level when discussing any change to the
> consensus rule to limit centralization (at any point in time).
> In other words, the question "can we change this without important
> risks of destroying the decentralized properties of the system in the
> short or long run?" should be always more important than "is there a
> concerning rise in fees to motivate this change at all?".
>

I agree with you that decentralization is the most important feature of
Bitcoin, but I also think we need to think probabilistically and concretely
about when risks to decentralization are worthwhile.

Decentralization is not infinitely valuable in relation to low fees, just
like being alive is not infinitely valuable in relation to having money.
For instance, people will generally not accept a 100% probability of death
in exchange for any amount of money. However anyone who understands
probability and has the preferences of a normal person would play a game
where they accept a one in a billion chance of instant death to win one
billion dollars if they don't die.

Similarly we shouldn't accept a 100% probability of Bitcoin being
controlled by a single entity for any guarantee of cheap tx fees no matter
how low they are, but there should be some minuscule risk of
decentralization that we'd be willing to accept (like raising the block
size to 1.01 MB) if it somehow allowed us to dramatically increase
usability. (Imagine something like the Lightning Network but even better
was developed, but it could only work with 1.01 MB blocks).



> > Jorge, if a fee equilibrium developed at 1MB of $5/tx, and you somehow
> knew
> > with certainty that increasing to 4MB would result in a 20 cent/tx
> > equilibrium that would last for a year (otherwise fees would stay around
> $5
> > for that year), would you be in favor of an increase to 4MB?
>
> As said, I would always consider the centralization risks first: I'd
> rather have a $5/tx decentralized Bitcoin than a Bitcoin with free
> transactions but effectively validated (when they validate blocks they
> mine on top of) by around 10 miners, specially if only 3 of them could
> easily collude to censor transactions [orphaning any block that
> doesn't censor in the same manner]. Sadly I have no choice, the later
> is what we have right now. And reducing the block size can't guarantee
> that the situation will get better or even that fees could rise to
> $5/tx (we just don't have that demand, not that it is a goal for
> anyone). All I know is that increasing the block size *could*
> (conditional, not necessarily, I don't know in which cases, I don't
> think anybody does) make things even worse.
>

I agree that we don't have good data about what exactly a 4 MB increase
would do. It sounds like you think the risks are too great / uncertain to
move from 1 MB to 4 MB blocks in the situation I described. I'm not clear
though on which specific risks you'd be most worried about at 4 MB, and if
there are any risks that you think don't matter at 4 MB but that you would
be worried about at higher block size levels. I also don't know if we have
similar ideas about the benefits of low tx fees. If we discussed exactly
how we were evaluating this scenario, maybe we'd discover that something I
thought was a huge benefit of low tx fees is actually not that compelling,
or maybe we'd discover that our entire disagreement boiled down to our
estimate of one specific risk.

For the record, I think these are the main harms of $5 tx fees, along with
the main risks I see from moving to 4 MB:

Fees of $5/tx would:
(a) Prevent a lot of people who could otherwise benefit from Bitcoin's
decentralization from having an opportunity to reap those benefits.
Especially people in poor countries with corrupt governments who could get
immediate benefit from it now.
(b) Prevent developers from experimenting with new Bitcoin use-cases, which
might eventually lead to helpful services.
(c) Prevent regular people from using Bitcoin and experimenting with it and
getting involved, because they think it's unusable for txns under many
hundreds of dollars in value, so it doesn't interest them. Not having the
public on our side could make us more vulnerable to regulators.

Changing the block size to 4 MB would:
(1) Probably reduce the number of full nodes by around 5%. Most of the drop
in full nodes over the past few years is probably due to Bitcoin Core being
used by fewer regular users for convenience reasons, but the extra HD space
required and extra bandwidth would probably make some existing people
running full nodes stop.
(2) Not hinder low bandwidth miners significantly, because of the relay
network.
(3) Not introduce any tx verification issues, because processors are fast
and tx processing is ridiculously cheap and we'd need way more than 4 MB of
txs for it to be a bottleneck.

So (1) is the only risk that gives me any significant concern, but I don't
think that the number of full nodes now is at a dangerous level.

Anyway, the point isn't for you and I to actually discuss this particular
hypothetical in more detail (although I would be curious to see similar
lists from you). I haven't studied the risks enough to actually put this
forth to the list as a good argument for what to do in this situation. My
main point is that being very specific and concrete both about our thought
process and about the hypothetical situation results in much better
discussions.

There's one more piece of information that I can give you which will help
you understand my position much better, and also force me to think really
carefully about this. It's the point at which I would switch to the other
side of the argument (either by varying the tx fee, or the block size). If
tx fees would only rise to 60 cents or lower if we stayed at 1 MB, then I
would be against a move to 4 MB. Or, keeping the hypothetical 1 MB fee at
$5, I think moving to 12 MB or higher is the point at which I'd switch over
to being a 1 MB advocate. Getting that same info from you tells me exactly
how you weigh the risks in a way that just listing the factors can't. In
this specific hypothetical scenario, what is the lowest block size increase
that you'd accept? It can be extremely low, like 1.01 MB. If you tell me
that you'd rather have $5 tx fees for the next year instead of changing the
block size to 1.01 MB, I would be really surprised.

Gavin is the only other person who I've seen who has defined at what block
size he'd switch to the other side (maybe not with a concrete number, but
with a rough range: the block size such that a normal person with a pretty
good connection couldn't run a full node).


> On the other hand, I could understand people getting worried if fees
> where as high as $5/tx or even 20 cent/tx but we're very far away from
> that case. How can low subsidies (a certainty) be "too far in the
> future to worry about it" but $5/tx, 20 cent/tx or even 5 cent/tx an
> urgent concern?


I would say that in this case we know high tx fees could happen very soon
because there is a clear mechanism. Bitcoin just needs to become more
popular quickly for any number of reasons. Suppose the infrastructure for
remittances starts falling into place within the next two months, and
suddenly immigrants are clamoring to use Bitcoin to send money back to
their home countries. This could result in $5 tx fees very soon (not that I
think it's likely). Many of these immigrants would still use Bitcoin
because it's still better than the alternative for remittances, which would
price out a lot of people currently using Bitcoin for other reasons. As far
as I know, there is no plausible way that subsidies could plummet in
anywhere near that time frame, aside from the price of Bitcoin completely
collapsing. But if that happens in the near term (specifically, with very
low tx volume) a fee market won't help.


> For all I know, 5 cent/tx may not happen in the next
> 25 years: it may never happen. And if it happens, to me it will be a
> symptom of Bitcoin success, even for others it means that Bitcoin has
> become a "high value settlement network".
>

I would be extremely happy if Bitcoin could somehow sustain itself in the
long run with 5 cent tx fees. I'm optimistic about Lightning to handle the
cases where people need even cheaper txns.



> I'm still missing an answer from the "big blocks size side" to the
> following question (which I have insistently repeated with various
> permutations):
>
> If "not now" when will it be a good time to let fees rise above zero?
> After the next subsidy halving? After 4 more subsidy halvings (ie
> about 13 years from now, subsidy = 1.5625 btc/block )? After your
> grandmother abandons her national currency and uses Bitcoin for
> everything? Never?
>
> ANY answer (maybe with the exception of the last one) would be less
> worrying than silence.
>

Before I answer, here's my reasoning about why we don't need to worry about
a fee market now:

There is nothing particularly special about a fee market in Bitcoin. We
know how markets work, and we have no reason to suspect a fee market in
Bitcoin will have any new properties of markets that we can't foresee. When
demand becomes higher, there will be some equilibrium level of fee that
people have to pay to give a certain probability of inclusion within a
certain number of blocks. There will likely be some level of fee where if
you don't pay it, your tx will never be confirmed.

We have seen something like this working at various points in Bitcoin's
history. Look at the recent "stress tests." To get your tx confirmed in a
reasonable time frame, you had to bump your fee a little higher than the
txns from whoever was flooding the network. If you did, everything worked
fine. If you didn't, your tx didn't confirm (until the test ended, maybe?).
So there's nothing complicated here. It doesn't require a decade long
preparation to prove to ourselves that a fee market will work.

Unless in the future mining is funded mostly by charity (I think there's
only a 25% chance of that happening), we will need a fee market eventually.
I'd be fine if one developed now. I think 10 cents per txn right now
wouldn't be too bad, aside from the following reason. What concerns me
about insisting on a fee market right now is that usage is so small and the
block size is so limited that if demand increases just a little bit, fees
could skyrocket. It's not the 10 cent fees that would worry me, but what
they say about the potential for a huge spike. Fees could become $10 per tx
or higher very quickly. Yes, that would show that big organizations find
Bitcoin useful which is nice, but it'd also put decentralized money out of
reach of many other people. While Bitcoin still has a lot of growth ahead
of it, it's better to not set up roadblocks (for reasons other than
preserving decentralization) in front of that growth which will make things
very painful if that growth happens more suddenly than we expect.

I think the best argument for having a fee market right now is that if we
move to such a market suddenly in the future, wallets won't have time to
make the user experience good, and full nodes might not be written in such
a way that they gracefully handle a bunch of txns that might never confirm.
I don't think the required software changes are that complex though, so it
seems unnecessary to start adding friction for users now for something that
might be an issue in 10+ years.

So to answer your question: about two years before we think Bitcoin will
need to rely heavily on txn fees for security, I'd be in favor of adjusting
block size so that it resulted in enough total fees / security. Until that
point, we should care a lot about Bitcoin being widely used so that when we
do need a fee market, it's more like lots of people paying 5 cents per tx
instead of fewer people paying $10/tx. I think the former situation is much
more likely to sustainable, and we're more likely to get there if we
encourage low fee use cases now.

You've been arguing that 0 fee transactions will have to disappear someday,
but this isn't necessarily true. As long as enough people care about having
their txns confirm relatively quickly, there's no reason to make sure that
people who pay 0 fees never have their txns confirmed.

[-- Attachment #2: Type: text/html, Size: 14639 bytes --]

Re: [bitcoin-dev] Block size following technological growth

[Jorge Timón]

On Fri, Aug 7, 2015 at 1:09 AM, Elliot Olds <elliot.olds@gmail.com> wrote:
> On Wed, Aug 5, 2015 at 6:26 PM, Jorge Timón <jtimon@jtimon.cc> wrote:
> I agree with you that decentralization is the most important feature of
> Bitcoin, but I also think we need to think probabilistically and concretely
> about when risks to decentralization are worthwhile.
>
> Decentralization is not infinitely valuable in relation to low fees, just
> like being alive is not infinitely valuable in relation to having money.
> [...]
> Similarly we shouldn't accept a 100% probability of Bitcoin being controlled
> by a single entity for any guarantee of cheap tx fees no matter how low they
> are, but there should be some minuscule risk of decentralization that we'd
> be willing to accept (like raising the block size to 1.01 MB) if it somehow
> allowed us to dramatically increase usability. (Imagine something like the
> Lightning Network but even better was developed, but it could only work with
> 1.01 MB blocks).

Agreed. I would just like that there was an attempt to automatically
estimate those risks before taking those risks.
Some function we're trying to optimize with simulations (based on
#6382 ) to find an ideal (according to that imperfect metric) maximum
consensus block size.
Maybe the function/simulations just take some minimum hardware
specifications and returns an block size, I don't know.

> I agree that we don't have good data about what exactly a 4 MB increase
> would do. It sounds like you think the risks are too great / uncertain to
> move from 1 MB to 4 MB blocks in the situation I described. I'm not clear
> though on which specific risks you'd be most worried about at 4 MB, and if
> there are any risks that you think don't matter at 4 MB but that you would
> be worried about at higher block size levels. I also don't know if we have
> similar ideas about the benefits of low tx fees. If we discussed exactly how
> we were evaluating this scenario, maybe we'd discover that something I
> thought was a huge benefit of low tx fees is actually not that compelling,
> or maybe we'd discover that our entire disagreement boiled down to our
> estimate of one specific risk.

The most important thing to understand in this discussion is that it
is about a trade-off between lower fees (more maximum tx volume) and
mining (and general) centralization.
I don't know what the costs and gains curves are here (for 4MB, 1 MB
or any other number, and I don't think anybody does).
But if we can't even agree on what the advantages and disadvantages of
increasing the consensus block size maximum, it is very hard that we
can agree on a universally acceptable point or range in this trade-off
rect.

> For the record, I think these are the main harms of $5 tx fees, along with
> the main risks I see from moving to 4 MB:
>
> Fees of $5/tx would:
> (a) Prevent a lot of people who could otherwise benefit from Bitcoin's
> decentralization from having an opportunity to reap those benefits.
> Especially people in poor countries with corrupt governments who could get
> immediate benefit from it now.
> (b) Prevent developers from experimenting with new Bitcoin use-cases, which
> might eventually lead to helpful services.
> (c) Prevent regular people from using Bitcoin and experimenting with it and
> getting involved, because they think it's unusable for txns under many
> hundreds of dollars in value, so it doesn't interest them. Not having the
> public on our side could make us more vulnerable to regulators.

This is all probably right, but IMO we're very far away from $5/tx.
My main point about fees is that minimum mining fees rising above zero
(theri current level) is not necessarily a bad thing or an urgent
concern.
On the other hand, we have much more data about current mining
centralization, which should be very relevant information when
discussing a block size increase.

> Changing the block size to 4 MB would:
> (1) Probably reduce the number of full nodes by around 5%. Most of the drop
> in full nodes over the past few years is probably due to Bitcoin Core being
> used by fewer regular users for convenience reasons, but the extra HD space
> required and extra bandwidth would probably make some existing people
> running full nodes stop.

As Pieter has explained repeatedly, a big block count is not a goal in
itself, just a metric.
And if you ask me, I don't think it's all that interesting as a
metric. For all I know there could be a lot more full nodes being run
that for whatever reason are not seen by people collecting this data.
The block size maximum consensus rule limits mining centralization,
not just full node centralization. Gavin, for example, disagrees with
this.
Fortunately I believe at least 2 mathematical proofs can be produced
to demonstrate Gavin and those who think like him are wrong.

> (2) Not hinder low bandwidth miners significantly, because of the relay
> network.

I believe that even with the relay network, and even assuming all
miners are connected using something like IBLT, a mathematical proof
can be constructed to demonstrate that bigger block sizes can prevent
the worse connected miners from being profitable.
It is important to note that the worse connected miners aren't
necessarily those with less bandwidth: maybe you have the best
bandwidth but you are poorly connected to the majority of the hashrate
(for example, because the majority of the hashrate is within the same
country but that country is not very well connected to the rest of the
world).

> (3) Not introduce any tx verification issues, because processors are fast
> and tx processing is ridiculously cheap and we'd need way more than 4 MB of
> txs for it to be a bottleneck.

We're certainly far away from this being a concern in practice.
But I'm working on a mathematical proof that at some scale CPU
requirements could become a discriminating factor making the smallest
mining operations unprofitable.

> So (1) is the only risk that gives me any significant concern, but I don't
> think that the number of full nodes now is at a dangerous level.

I don't think there's such a thing as a "dangerous full node count level".
It's just data that can be useful to build centralization metrics.
Probably hashrate distribution by pool is much more interesting (and
if you ask me that looks really bad right now without increasing the
block size consensus maximum).

> Anyway, the point isn't for you and I to actually discuss this particular
> hypothetical in more detail (although I would be curious to see similar
> lists from you). I haven't studied the risks enough to actually put this
> forth to the list as a good argument for what to do in this situation. My
> main point is that being very specific and concrete both about our thought
> process and about the hypothetical situation results in much better
> discussions.

I agree.

> There's one more piece of information that I can give you which will help
> you understand my position much better, and also force me to think really
> carefully about this. It's the point at which I would switch to the other
> side of the argument (either by varying the tx fee, or the block size). If
> tx fees would only rise to 60 cents or lower if we stayed at 1 MB, then I
> would be against a move to 4 MB. Or, keeping the hypothetical 1 MB fee at
> $5, I think moving to 12 MB or higher is the point at which I'd switch over
> to being a 1 MB advocate. Getting that same info from you tells me exactly
> how you weigh the risks in a way that just listing the factors can't. In
> this specific hypothetical scenario, what is the lowest block size increase
> that you'd accept? It can be extremely low, like 1.01 MB. If you tell me
> that you'd rather have $5 tx fees for the next year instead of changing the
> block size to 1.01 MB, I would be really surprised.

Great. I don't think that minimum mining fees will rise above 1 usd
cent/tx anytime soon even if we maintain the limit of 1MB.
Maybe that's why I'm not worried at all about "hitting the limit".
But I'm sorry, I don't have those concrete numbers because it is a
trade-off I don't think we've studied in enough detail.
Well, I can also say I wouldn't be worried at all about moving to,
say, 1.01 MB (because the difference in centralization pressure should
be minimal) and I would just take it as a "let's proof hardforks are
possible" change similar to the one proposed in bip99.

> Gavin is the only other person who I've seen who has defined at what block
> size he'd switch to the other side (maybe not with a concrete number, but
> with a rough range: the block size such that a normal person with a pretty
> good connection couldn't run a full node).

That would be interesting to read and I have totally missed it.
Do you have a link?

> I would say that in this case we know high tx fees could happen very soon
> because there is a clear mechanism. Bitcoin just needs to become more
> popular quickly for any number of reasons. Suppose the infrastructure for
> remittances starts falling into place within the next two months, and
> suddenly immigrants are clamoring to use Bitcoin to send money back to their
> home countries. This could result in $5 tx fees very soon (not that I think
> it's likely). Many of these immigrants would still use Bitcoin because it's
> still better than the alternative for remittances, which would price out a
> lot of people currently using Bitcoin for other reasons. As far as I know,
> there is no plausible way that subsidies could plummet in anywhere near that
> time frame, aside from the price of Bitcoin completely collapsing.

And for any size something similar could happen with some use case.
But this is a great example of a situation where I would understand
people panicking and clamoring to change the consensus rule as soon as
possible.
Even with much lower fees, say 1 usd/tx.
I think it would be a great problem to have and admittedly I'm not
worried about having it in the short term.
And if it happened overnight we could always deploy an emergency hardfork.

> But if
> that happens in the near term (specifically, with very low tx volume) a fee
> market won't help.

I think it's helping by determining who is to be served first, and
that is those who benefit more from Bitcoin (and are therefore willing
to pay higher costs for using it), in this case, people doing
international remittances.

> I would be extremely happy if Bitcoin could somehow sustain itself in the
> long run with 5 cent tx fees. I'm optimistic about Lightning to handle the
> cases where people need even cheaper txns.

Agreed.

>> I'm still missing an answer from the "big blocks size side" to the
>> following question (which I have insistently repeated with various
>> permutations):
>>
>> If "not now" when will it be a good time to let fees rise above zero?
>> After the next subsidy halving? After 4 more subsidy halvings (ie
>> about 13 years from now, subsidy = 1.5625 btc/block )? After your
>> grandmother abandons her national currency and uses Bitcoin for
>> everything? Never?
>>
>> ANY answer (maybe with the exception of the last one) would be less
>> worrying than silence.
>
>
> Before I answer, here's my reasoning about why we don't need to worry about
> a fee market now:
>
> There is nothing particularly special about a fee market in Bitcoin. We know
> how markets work, and we have no reason to suspect a fee market in Bitcoin
> will have any new properties of markets that we can't foresee. When demand
> becomes higher, there will be some equilibrium level of fee that people have
> to pay to give a certain probability of inclusion within a certain number of
> blocks. There will likely be some level of fee where if you don't pay it,
> your tx will never be confirmed.

This is what I mean by "market minimum fee".

> We have seen something like this working at various points in Bitcoin's
> history. Look at the recent "stress tests." To get your tx confirmed in a
> reasonable time frame, you had to bump your fee a little higher than the
> txns from whoever was flooding the network. If you did, everything worked
> fine. If you didn't, your tx didn't confirm (until the test ended, maybe?).
> So there's nothing complicated here. It doesn't require a decade long
> preparation to prove to ourselves that a fee market will work.

I think the code that miners use to select which transactions to
include first needs a lot of work.
As said miners are subsidizing free transactions, increasing their own
costs for nothing in exchange.
Also, yes, there is something special about this market: it is
supposed to pay for most of the global hashrate in the not-so-far
future.
If we take too long to start moving away from total seigniorage
subsidy dependence, it may be too late when we do.

> Unless in the future mining is funded mostly by charity (I think there's
> only a 25% chance of that happening), we will need a fee market eventually.
> I'd be fine if one developed now. I think 10 cents per txn right now
> wouldn't be too bad, aside from the following reason. What concerns me about
> insisting on a fee market right now is that usage is so small and the block
> size is so limited that if demand increases just a little bit, fees could
> skyrocket. It's not the 10 cent fees that would worry me, but what they say
> about the potential for a huge spike. Fees could become $10 per tx or higher
> very quickly. Yes, that would show that big organizations find Bitcoin
> useful which is nice, but it'd also put decentralized money out of reach of
> many other people. While Bitcoin still has a lot of growth ahead of it, it's
> better to not set up roadblocks (for reasons other than preserving
> decentralization) in front of that growth which will make things very
> painful if that growth happens more suddenly than we expect.
>
> I think the best argument for having a fee market right now is that if we
> move to such a market suddenly in the future, wallets won't have time to
> make the user experience good, and full nodes might not be written in such a
> way that they gracefully handle a bunch of txns that might never confirm. I
> don't think the required software changes are that complex though, so it
> seems unnecessary to start adding friction for users now for something that
> might be an issue in 10+ years.

I think you are underestimating the software costs.
And you not only have to adapt the software that we have now, but also
the software that hasn't been written yet and will be written assuming
free transactions and an underdeveloped market.
Also you are over-estimating the costs: you could hit the limit but
then rise the block size maximum as soon as you reach, say 0.00001
usd/tx.
Even if minimum fees go again to zero after rising the block size
maximum, the software improvements will remain there.

> So to answer your question: about two years before we think Bitcoin will
> need to rely heavily on txn fees for security, I'd be in favor of adjusting
> block size so that it resulted in enough total fees / security.

And when do you think "Bitcoin will need to rely heavily on txn fees
for security"?
How many more halvings is that?

> You've been arguing that 0 fee transactions will have to disappear someday,
> but this isn't necessarily true. As long as enough people care about having
> their txns confirm relatively quickly, there's no reason to make sure that
> people who pay 0 fees never have their txns confirmed.

That's not what I've been arguing, I've just being saying that I would
be completely ok with minimum fees rising above zero (say, to 1
satoshi/tx) tomorrow.
I don't think that's necessarily a bad thing (in fact, it has some
advantages) and certainly not something we should fear to the point of
rushing hardforks to avoid it.

Re: [bitcoin-dev] Block size following technological growth

[Elliot Olds]

[-- Attachment #1: Type: text/plain, Size: 12000 bytes --]

On Mon, Aug 10, 2015 at 12:28 PM, Jorge Timón <jtimon@jtimon.cc> wrote:

> I would just like that there was an attempt to automatically
> estimate those risks before taking those risks.
>

I agree.


> My main point about fees is that minimum mining fees rising above zero
> (theri current level) is not necessarily a bad thing or an urgent
> concern.
>

Yes, it only gets bad when fees become "high."

I'll skip over the discussion of the pros/cons I listed since that mostly
appeared for illustrative purposes and I don't have a strong disagreement
with anything you said.


> Great. I don't think that minimum mining fees will rise above 1 usd
> cent/tx anytime soon even if we maintain the limit of 1MB.
> Maybe that's why I'm not worried at all about "hitting the limit".
>

My sense is that the people arguing for a hard fork now tend to envision
"hitting the limit" as tx fees being fairly high, and those arguing against
a hard fork envision tx fees staying low when 1 MB blocks start to get
full. Which of those occurs depends on how quickly and in what manner
Bitcoin gains popularity. Even if I thought there's an 95% chance that
there would be no sudden jump in Bitcoin tx demand, I would want to have
some rough plan in place for that other 5% when some previously difficult
use case becomes viable and demand spikes. Do those arguing for the "wait
and see" approach not think that a quick increase in demand is even likely
enough to warrant discussing what we'd do in that case? Greg Maxwell
mentioned doubling the max block size if there was ever a standing backlog (
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/007880.html
-- I think fee level is a better metric than size of tx backlog), but I
haven't seen other devs comment on it.


> But I'm sorry, I don't have those concrete numbers because it is a
> trade-off I don't think we've studied in enough detail.
>

The question is about what you'd do in the absence of those details that
you don't have. Imagine that fees spiked to $5/tx tomorrow. You have some
model of the situation that allows you to say that 1.01 MB is something
you'd support, and that's the model that I'm trying to understand. The
answers I gave are not ones I'm confident about. I'm sure if I studied this
for a week they'd change. I sense that devs are reluctant to answer this
question because it could be taken out of context or held against them
later. Or maybe they just don't like saying things that they don't have a
high level of confidence about on principle. IMO this reluctance
contributes to a lack of understanding of each other's positions. We all
have these imperfect models in our heads that we're basing our
disagreements on, but we won't show each other these models.


> > Gavin is the only other person who I've seen who has defined at what
> block
> > size he'd switch to the other side (maybe not with a concrete number, but
> > with a rough range: the block size such that a normal person with a
> pretty
> > good connection couldn't run a full node).
>
> That would be interesting to read and I have totally missed it.
> Do you have a link?


Sorry, I see how what I wrote was misleading. You've seen the email I'm
referring to. I was talking about when he defined the criteria he used
qualitatively and suggested that's how he arrived at 20 MB:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/009971.html.
I think he talks about it in a little more detail elsewhere. I inferred
from that that he wouldn't support 40 MB or 80 MB, but that may be wrong.

I should also have given credit to Pieter, as he even more explicitly
specified a level where he'd turn into a hard fork advocate, via his own
hard fork proposal. Neither of these statements specifies exactly where the
switch-over point is, but they're the closest I've seen.


> > I would say that in this case we know high tx fees could happen very soon
> > because there is a clear mechanism. Bitcoin just needs to become more
> > popular quickly for any number of reasons. Suppose the infrastructure for
> > remittances starts falling into place within the next two months, and
> > suddenly immigrants are clamoring to use Bitcoin to send money back to
> their
> > home countries. This could result in $5 tx fees very soon (not that I
> think
> > it's likely). Many of these immigrants would still use Bitcoin because
> it's
> > still better than the alternative for remittances, which would price out
> a
> > lot of people currently using Bitcoin for other reasons. As far as I
> know,
> > there is no plausible way that subsidies could plummet in anywhere near
> that
> > time frame, aside from the price of Bitcoin completely collapsing.
>
> And for any size something similar could happen with some use case.
> But this is a great example of a situation where I would understand
> people panicking and clamoring to change the consensus rule as soon as
> possible.
> Even with much lower fees, say 1 usd/tx.
> I think it would be a great problem to have and admittedly I'm not
> worried about having it in the short term.
> And if it happened overnight we could always deploy an emergency hardfork.
>

Don't you think the devs should have some rough plan that they discuss
ahead of time about what to do in the situation of high fees? Even if it
happened gradually -- suppose fees crept to 20 cents, then 50 cents, then
75 over the next year -- I don't think I've ever seen a discussion of how
that should be handled, and what sort of fees people regard as high enough
to justify considering a hard fork.

I think it would prevent many people from supporting an urgent hard fork if
they knew how the core devs would handle that situation (assuming there was
some willingness to increase the block size if fees got too high).


> > We have seen something like this working at various points in Bitcoin's
> > history. Look at the recent "stress tests." To get your tx confirmed in a
> > reasonable time frame, you had to bump your fee a little higher than the
> > txns from whoever was flooding the network. If you did, everything worked
> > fine. If you didn't, your tx didn't confirm (until the test ended,
> maybe?).
> > So there's nothing complicated here. It doesn't require a decade long
> > preparation to prove to ourselves that a fee market will work.
>
> [...]
> Also, yes, there is something special about this market: it is
> supposed to pay for most of the global hashrate in the not-so-far
> future.
> If we take too long to start moving away from total seigniorage
> subsidy dependence, it may be too late when we do.
>

I see that 'special' feature of this market as more strongly supporting the
need to encourage fast adoption.

Let's say block rewards are $7000 per block, and we think this gives a good
level of security (as Bitcoin grows, we'll probably want a lot more).

Suppose a 1MB block can hold 2000 txns. Then to pay for the same level of
security we have right now with only tx fees, assuming 1 MB blocks, the
average tx fee would have to be $3.50. Now suppose blocks are 100 MB in the
future. The average tx fee is then only 3.5 cents. I think the former
situation will not actually work, and the only way that Bitcoin can survive
is to eventually get into something more like the later situation. Let me
know if you want me to delve into why. I'll just note that even Lightning
doesn't work well when tx fees are that high, because channels need to be
opened and closed pretty often and if my counterparty is uncooperative, his
making me pay $3.50 starts to actually hurt.

So if we accept that, we need to end up in a situation where we eventually
have lots of people making on-blockchain txns, and paying relatively small
fees. Encouraging lots of use and experimentation of Bitcoin between now
and then seems pretty important for reaching that goal.

We're in a race with the block reward halving schedule, to see if we can
get usage high enough to pay for security (while maintaining enough
decentralization) before all of the security burden falls on transactions.
If there aren't enough transactions at that time, the burden will be too
high (or security will be too low) and people will find other solutions.

We seem to disagree about how hard it'll be to change wallet and node
software to cope with a fee market. As I've said I don't see very small
nonzero fees (for instance one tenth of a cent) as a problem though. So if
a solution that traded off usage and decentralization in a way that I
agreed with could be modified to ensure a fee market developed soon with
very low fees, I'd still support it.





>
> > Unless in the future mining is funded mostly by charity (I think there's
> > only a 25% chance of that happening), we will need a fee market
> eventually.
> > I'd be fine if one developed now. I think 10 cents per txn right now
> > wouldn't be too bad, aside from the following reason. What concerns me
> about
> > insisting on a fee market right now is that usage is so small and the
> block
> > size is so limited that if demand increases just a little bit, fees could
> > skyrocket. It's not the 10 cent fees that would worry me, but what they
> say
> > about the potential for a huge spike. Fees could become $10 per tx or
> higher
> > very quickly. Yes, that would show that big organizations find Bitcoin
> > useful which is nice, but it'd also put decentralized money out of reach
> of
> > many other people. While Bitcoin still has a lot of growth ahead of it,
> it's
> > better to not set up roadblocks (for reasons other than preserving
> > decentralization) in front of that growth which will make things very
> > painful if that growth happens more suddenly than we expect.
> >
> > I think the best argument for having a fee market right now is that if we
> > move to such a market suddenly in the future, wallets won't have time to
> > make the user experience good, and full nodes might not be written in
> such a
> > way that they gracefully handle a bunch of txns that might never
> confirm. I
> > don't think the required software changes are that complex though, so it
> > seems unnecessary to start adding friction for users now for something
> that
> > might be an issue in 10+ years.
>
> I think you are underestimating the software costs.
> And you not only have to adapt the software that we have now, but also
> the software that hasn't been written yet and will be written assuming
> free transactions and an underdeveloped market.
> Also you are over-estimating the costs: you could hit the limit but
> then rise the block size maximum as soon as you reach, say 0.00001
> usd/tx.
> Even if minimum fees go again to zero after rising the block size
> maximum, the software improvements will remain there.
>
> > So to answer your question: about two years before we think Bitcoin will
> > need to rely heavily on txn fees for security, I'd be in favor of
> adjusting
> > block size so that it resulted in enough total fees / security.
>
> And when do you think "Bitcoin will need to rely heavily on txn fees
> for security"?
> How many more halvings is that?
>
> > You've been arguing that 0 fee transactions will have to disappear
> someday,
> > but this isn't necessarily true. As long as enough people care about
> having
> > their txns confirm relatively quickly, there's no reason to make sure
> that
> > people who pay 0 fees never have their txns confirmed.
>
> That's not what I've been arguing, I've just being saying that I would
> be completely ok with minimum fees rising above zero (say, to 1
> satoshi/tx) tomorrow.
> I don't think that's necessarily a bad thing (in fact, it has some
> advantages) and certainly not something we should fear to the point of
> rushing hardforks to avoid it.
>

[-- Attachment #2: Type: text/html, Size: 14427 bytes --]

[bitcoin-dev] What Lightning Is

[Tom Harding]

On 8/4/2015 4:27 AM, Pieter Wuille via bitcoin-dev wrote:

> Don't turn Bitcoin into something uninteresting, please.

Consider how Bob will receive money using the Lightning Network.

Bob receives a payment by applying a contract to his local payment
channel, increasing the amount payable to him when the channel is closed.

There are two possible sources of funding for Bob's increased claim. 
They can appear alone, or in combination:


Funding Source (1)
A deposit from Bob's payment hub

Bob can receive funds, if his payment hub has made a deposit to the
channel.  Another name for this is "credit".

This credit has no default risk: Bob cannot just take payment hub's
deposit. But neither can Bob receive money, unless payment hub has
advanced it to the channel (or (2) below applies).  Nothing requires the
payment hub to do this.

This is a 3rd-party dependency totally absent with plain old bitcoin.   
It will come with a fee and, in an important way, it is worse than the
current banking system.  If a bank will not even open an account for Bob
today, why would a payment hub lock up hard bitcoin to allow Bob to be
paid through a Poon-Dryja channel?


Funding Source (2)
Bob's previous spends

If Bob has previously spent from the channel, decreasing his claim on
its funds (which he could have deposited himself), that claim can be
re-increased.

To avoid needing credit (1), Bob has an incentive to consolidate
spending and income in the same payment channel, just as with today's
banks.  This is at odds with the idea that Bob will have accounts with
many payment hubs.  It is an incentive for centralization.


With Lightning Network, Bob will need a powerful middleman to send and
receive money effectively.  *That* is uninteresting to me.

Re: [bitcoin-dev] What Lightning Is

[Mark Friedenbach]

[-- Attachment #1: Type: text/plain, Size: 2649 bytes --]

Tom, you appear to be misunderstanding how lightning network and
micropayment hub-and-spoke models in general work.

> But neither can Bob receive money, unless payment hub has
advanced it to the channel (or (2) below applies).  Nothing requires the
payment hub to do this.

On the contrary the funds were advanced by the hub on the creation of the
channel. There is no credit involved. if the funds aren't already available
for Bob to immediately claim his balance, the payment doesn't go through in
the first place.

On Sun, Aug 9, 2015 at 11:46 AM, Tom Harding via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On 8/4/2015 4:27 AM, Pieter Wuille via bitcoin-dev wrote:
>
> > Don't turn Bitcoin into something uninteresting, please.
>
> Consider how Bob will receive money using the Lightning Network.
>
> Bob receives a payment by applying a contract to his local payment
> channel, increasing the amount payable to him when the channel is closed.
>
> There are two possible sources of funding for Bob's increased claim.
> They can appear alone, or in combination:
>
>
> Funding Source (1)
> A deposit from Bob's payment hub
>
> Bob can receive funds, if his payment hub has made a deposit to the
> channel.  Another name for this is "credit".
>
> This credit has no default risk: Bob cannot just take payment hub's
> deposit. But neither can Bob receive money, unless payment hub has
> advanced it to the channel (or (2) below applies).  Nothing requires the
> payment hub to do this.
>
> This is a 3rd-party dependency totally absent with plain old bitcoin.
> It will come with a fee and, in an important way, it is worse than the
> current banking system.  If a bank will not even open an account for Bob
> today, why would a payment hub lock up hard bitcoin to allow Bob to be
> paid through a Poon-Dryja channel?
>
>
> Funding Source (2)
> Bob's previous spends
>
> If Bob has previously spent from the channel, decreasing his claim on
> its funds (which he could have deposited himself), that claim can be
> re-increased.
>
> To avoid needing credit (1), Bob has an incentive to consolidate
> spending and income in the same payment channel, just as with today's
> banks.  This is at odds with the idea that Bob will have accounts with
> many payment hubs.  It is an incentive for centralization.
>
>
> With Lightning Network, Bob will need a powerful middleman to send and
> receive money effectively.  *That* is uninteresting to me.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 3392 bytes --]

Re: [bitcoin-dev] What Lightning Is

[Hector Chu]

[-- Attachment #1: Type: text/plain, Size: 3397 bytes --]

In the Lightning network it is assumed that the balances can always be
settled on the blockchain if any of the parties along the channel has a
problem. What if the fee on the settlement transactions is not high enough
to enter the blockchain? You can't do replace-by-fee after the fact. Do the
fees always have to assume worst case scenarios on the Bitcoin fee market?

On 9 August 2015 at 19:54, Mark Friedenbach via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Tom, you appear to be misunderstanding how lightning network and
> micropayment hub-and-spoke models in general work.
>
> > But neither can Bob receive money, unless payment hub has
> advanced it to the channel (or (2) below applies).  Nothing requires the
> payment hub to do this.
>
> On the contrary the funds were advanced by the hub on the creation of the
> channel. There is no credit involved. if the funds aren't already available
> for Bob to immediately claim his balance, the payment doesn't go through in
> the first place.
>
> On Sun, Aug 9, 2015 at 11:46 AM, Tom Harding via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> On 8/4/2015 4:27 AM, Pieter Wuille via bitcoin-dev wrote:
>>
>> > Don't turn Bitcoin into something uninteresting, please.
>>
>> Consider how Bob will receive money using the Lightning Network.
>>
>> Bob receives a payment by applying a contract to his local payment
>> channel, increasing the amount payable to him when the channel is closed.
>>
>> There are two possible sources of funding for Bob's increased claim.
>> They can appear alone, or in combination:
>>
>>
>> Funding Source (1)
>> A deposit from Bob's payment hub
>>
>> Bob can receive funds, if his payment hub has made a deposit to the
>> channel.  Another name for this is "credit".
>>
>> This credit has no default risk: Bob cannot just take payment hub's
>> deposit. But neither can Bob receive money, unless payment hub has
>> advanced it to the channel (or (2) below applies).  Nothing requires the
>> payment hub to do this.
>>
>> This is a 3rd-party dependency totally absent with plain old bitcoin.
>> It will come with a fee and, in an important way, it is worse than the
>> current banking system.  If a bank will not even open an account for Bob
>> today, why would a payment hub lock up hard bitcoin to allow Bob to be
>> paid through a Poon-Dryja channel?
>>
>>
>> Funding Source (2)
>> Bob's previous spends
>>
>> If Bob has previously spent from the channel, decreasing his claim on
>> its funds (which he could have deposited himself), that claim can be
>> re-increased.
>>
>> To avoid needing credit (1), Bob has an incentive to consolidate
>> spending and income in the same payment channel, just as with today's
>> banks.  This is at odds with the idea that Bob will have accounts with
>> many payment hubs.  It is an incentive for centralization.
>>
>>
>> With Lightning Network, Bob will need a powerful middleman to send and
>> receive money effectively.  *That* is uninteresting to me.
>>
>>
>> _______________________________________________
>> 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
>
>

[-- Attachment #2: Type: text/html, Size: 4643 bytes --]

Re: [bitcoin-dev] What Lightning Is

[Hector Chu]

[-- Attachment #1: Type: text/plain, Size: 4336 bytes --]

Thanks Mark.
Ok next obvious question (apologies for all of these but it seems you are
the authority on Lightning here). Is the Lightning system limited in the
number of hops there can be in the payment channel? I am looking at the
initial Lightning slides presented in February and it looks like the
locktime decrements by 1-day along each hop. So the more hops there are the
longer my bitcoins are potentially locked up for?

On 9 August 2015 at 21:18, Mark Friedenbach <mark@friedenbach.org> wrote:

> Child pays for parent, and potentially future sighash modes implemented in
> the checksig2 operator lightning needs anyway which enable adding inputs to
> provide additional fee.
> On Aug 9, 2015 1:15 PM, "Hector Chu" <hectorchu@gmail.com> wrote:
>
>> In the Lightning network it is assumed that the balances can always be
>> settled on the blockchain if any of the parties along the channel has a
>> problem. What if the fee on the settlement transactions is not high enough
>> to enter the blockchain? You can't do replace-by-fee after the fact. Do the
>> fees always have to assume worst case scenarios on the Bitcoin fee market?
>>
>> On 9 August 2015 at 19:54, Mark Friedenbach via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> Tom, you appear to be misunderstanding how lightning network and
>>> micropayment hub-and-spoke models in general work.
>>>
>>> > But neither can Bob receive money, unless payment hub has
>>> advanced it to the channel (or (2) below applies).  Nothing requires the
>>> payment hub to do this.
>>>
>>> On the contrary the funds were advanced by the hub on the creation of
>>> the channel. There is no credit involved. if the funds aren't already
>>> available for Bob to immediately claim his balance, the payment doesn't go
>>> through in the first place.
>>>
>>> On Sun, Aug 9, 2015 at 11:46 AM, Tom Harding via bitcoin-dev <
>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>
>>>> On 8/4/2015 4:27 AM, Pieter Wuille via bitcoin-dev wrote:
>>>>
>>>> > Don't turn Bitcoin into something uninteresting, please.
>>>>
>>>> Consider how Bob will receive money using the Lightning Network.
>>>>
>>>> Bob receives a payment by applying a contract to his local payment
>>>> channel, increasing the amount payable to him when the channel is
>>>> closed.
>>>>
>>>> There are two possible sources of funding for Bob's increased claim.
>>>> They can appear alone, or in combination:
>>>>
>>>>
>>>> Funding Source (1)
>>>> A deposit from Bob's payment hub
>>>>
>>>> Bob can receive funds, if his payment hub has made a deposit to the
>>>> channel.  Another name for this is "credit".
>>>>
>>>> This credit has no default risk: Bob cannot just take payment hub's
>>>> deposit. But neither can Bob receive money, unless payment hub has
>>>> advanced it to the channel (or (2) below applies).  Nothing requires the
>>>> payment hub to do this.
>>>>
>>>> This is a 3rd-party dependency totally absent with plain old bitcoin.
>>>> It will come with a fee and, in an important way, it is worse than the
>>>> current banking system.  If a bank will not even open an account for Bob
>>>> today, why would a payment hub lock up hard bitcoin to allow Bob to be
>>>> paid through a Poon-Dryja channel?
>>>>
>>>>
>>>> Funding Source (2)
>>>> Bob's previous spends
>>>>
>>>> If Bob has previously spent from the channel, decreasing his claim on
>>>> its funds (which he could have deposited himself), that claim can be
>>>> re-increased.
>>>>
>>>> To avoid needing credit (1), Bob has an incentive to consolidate
>>>> spending and income in the same payment channel, just as with today's
>>>> banks.  This is at odds with the idea that Bob will have accounts with
>>>> many payment hubs.  It is an incentive for centralization.
>>>>
>>>>
>>>> With Lightning Network, Bob will need a powerful middleman to send and
>>>> receive money effectively.  *That* is uninteresting to me.
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>>
>>

[-- Attachment #2: Type: text/html, Size: 5982 bytes --]

Re: [bitcoin-dev] What Lightning Is

[Joseph Poon]

Hi Hector,

On Sun, Aug 09, 2015 at 09:48:41PM +0100, Hector Chu via bitcoin-dev wrote:
> Is the Lightning system limited in the number of hops there can be in
> the payment channel? I am looking at the initial Lightning slides
> presented in February and it looks like the locktime decrements by
> 1-day along each hop. So the more hops there are the longer my
> bitcoins are potentially locked up for?

The hops are limited to the time-value which the sender wishes to pay
and the minimum acceptable timeout between each hop. It should be
relatively cheap if you game it out, though (I don't forsee me opening a
1 BTC channel and being able to make $5 per month...)

1-day is used as a convenience. However, the time between hops should be
somewhat long, as the intermediate steps can be extended further when
you want to offload the HTLCs to others who have a channel open with
both counterparties. E.g. Alice sends a payment to Dave through Bob and
Carol. Bob has a channel with Carol and has an HTLC with it, but that
channel seems to be used a lot. Erin has a relationship to both Bob and
Carol, she can offload the payment so that the payment actually goes to
A->B->E->C->D. B<->C is now completely clear.

> > On Aug 9, 2015 1:15 PM, "Hector Chu" <hectorchu@gmail.com> wrote:
> >> In the Lightning network it is assumed that the balances can always
> >> be settled on the blockchain if any of the parties along the
> >> channel has a problem. What if the fee on the settlement
> >> transactions is not high enough to enter the blockchain? You can't
> >> do replace-by-fee after the fact. Do the fees always have to assume
> >> worst case scenarios on the Bitcoin fee market?

How do you send coins if you wanted to send funds below the current
IsStandard value? It should be no different. If your wallet can't send
funds below the IsStandard value on-chain today, then I don't think it
should be able to to in the future, right? If you send funds *at* the
minimum IsStandard value today, you're probably paying really high fees,
this is a problem that exists today.

-- 
Joseph Poon

Re: [bitcoin-dev] What Lightning Is

[odinn]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

If I understand this correctly, Lightning only requires transaction
malleability to be fixed to be able to work ~ I believe that was going
to happen in a release of (bitcoind), but I'm not sure if that is
correct on timing ( note also, this wiki seems to be out of date on
infos about bitcoind https://en.bitcoin.it/wiki/Bitcoind )

I have also heard it said that bitcoin should support relative
locktime opcodes so that long-lived micropayment channels would be
able to be created, such that there would be Lightning functionality
beyond the basic microhop channels (which would be short-lived in
nature at the basic level).

This would be nice, but it seems like such discussions would take a
while to get done as basic development issues right now aren't even
wrapping up (e.g. blocksize debate related stuff.)  Note that I've
been in favor of going ahead with Cameron Garnham's dynamic softfork
proposal right now, which can be seen at http://is.gd/DiFuRr - testing
it out, seeing how that works, and at the same time making
preparations for moving forward with Garzik's BIP 100 (which could be
tailored or refined based on additional data gathered, without being
turned into a controversial fork (e.g. needs to make sure to avoid
inclusion of XT, for example).  Garnham's proposal and Garzik's
proposal are not mutually exclusive, imho, and I don't see why the
matter can't simply be resolved, it seems to be just an endless pile
of argumentation that will go on forever and ever.  This needs to,
like, stop.

Also, it strikes me that unless and until certain changes can be made
in bitcoin that would reduce fees and cost to transact, solutions such
as Lightning are going to fill the gap whether or not you want them
to; users have a choice in the market, and as the billions of unbanked
are gradually excluded from straight bitcoin, people will seek other
services which offer them lesser fees to transact, or they will seek
other coins which offer them lesser cost to transact.  It is, after
all, an open market.  I have made this point before elsewhere albeit
with more emphasis (and data to back up my point):
( On Github at Pull Request #6201: http://is.gd/8bW0zq )

In making and successfully defending such points on Github, the
following conclusions were drawn:
As the cost to transact goes higher and higher based on this
observable trend (due to all the factors mentioned in the thread on
github), then people who are affected by these rising costs to
transact will do one of three things with respect to bitcoin (and
virtual currencies generally):
1) Ignore bitcoin (an unlikely possibility, but it is one that would
occur),
2) adopt alts which are more inclined to allow people to perform
microtransactions,
3) and/or use bitcoin increasingly off-chain, which is likely to come
with its own set of problems for the network.

Regarding donation or microdonation use cases, To keep it all
on-chain, wallets can be designed to accumulate donation micro-amounts
according to donation settings of a user (in voluntary donation use
cases such as in ABIS -- http://abis.io ) as an internal accounting
feature, for example, and when enough donation value is accumulated,
it can be sent to the recipient by piggybacking on one of the user's
daily transactions.  This is one method doing so in a manner which is
on-chain; depending on the cryptocurrency under consideration, the
feasibility of doing this in a wallet will be greater or lesser.

- -O


On 08/09/2015 01:14 PM, Hector Chu via bitcoin-dev wrote:
> In the Lightning network it is assumed that the balances can always
> be settled on the blockchain if any of the parties along the
> channel has a problem. What if the fee on the settlement
> transactions is not high enough to enter the blockchain? You can't
> do replace-by-fee after the fact. Do the fees always have to assume
> worst case scenarios on the Bitcoin fee market?
> 
> On 9 August 2015 at 19:54, Mark Friedenbach via bitcoin-dev 
> <bitcoin-dev@lists.linuxfoundation.org 
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
> 
> Tom, you appear to be misunderstanding how lightning network and 
> micropayment hub-and-spoke models in general work.
> 
>> But neither can Bob receive money, unless payment hub has
> advanced it to the channel (or (2) below applies).  Nothing
> requires the payment hub to do this.
> 
> On the contrary the funds were advanced by the hub on the creation 
> of the channel. There is no credit involved. if the funds aren't 
> already available for Bob to immediately claim his balance, the 
> payment doesn't go through in the first place.
> 
> On Sun, Aug 9, 2015 at 11:46 AM, Tom Harding via bitcoin-dev 
> <bitcoin-dev@lists.linuxfoundation.org 
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
> 
> On 8/4/2015 4:27 AM, Pieter Wuille via bitcoin-dev wrote:
> 
>> Don't turn Bitcoin into something uninteresting, please.
> 
> Consider how Bob will receive money using the Lightning Network.
> 
> Bob receives a payment by applying a contract to his local payment 
> channel, increasing the amount payable to him when the channel is
> closed.
> 
> There are two possible sources of funding for Bob's increased
> claim. They can appear alone, or in combination:
> 
> 
> Funding Source (1) A deposit from Bob's payment hub
> 
> Bob can receive funds, if his payment hub has made a deposit to
> the channel.  Another name for this is "credit".
> 
> This credit has no default risk: Bob cannot just take payment
> hub's deposit. But neither can Bob receive money, unless payment
> hub has advanced it to the channel (or (2) below applies).
> Nothing requires the payment hub to do this.
> 
> This is a 3rd-party dependency totally absent with plain old 
> bitcoin. It will come with a fee and, in an important way, it is
> worse than the current banking system.  If a bank will not even
> open an account for Bob today, why would a payment hub lock up hard
> bitcoin to allow Bob to be paid through a Poon-Dryja channel?
> 
> 
> Funding Source (2) Bob's previous spends
> 
> If Bob has previously spent from the channel, decreasing his claim
> on its funds (which he could have deposited himself), that claim
> can be re-increased.
> 
> To avoid needing credit (1), Bob has an incentive to consolidate 
> spending and income in the same payment channel, just as with 
> today's banks.  This is at odds with the idea that Bob will have 
> accounts with many payment hubs.  It is an incentive for
> centralization.
> 
> 
> With Lightning Network, Bob will need a powerful middleman to send
> and receive money effectively.  *That* is uninteresting to me.
> 
> 
> _______________________________________________ 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
> 

- -- 
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVyNlfAAoJEGxwq/inSG8CTvgH/3b4wyoU+hQtQ7Ewk4n1UK/Q
gBezGVfv6v9D8uRU+8gR37gG6TpiG3VS37g47fkAbqTTUzY16qGRXMV8mi0FVz/3
8Hqz7rWZEllYfeYrV9MUoNftrFmjy1PucPgd95BYmWaHoZRxBwhr+YpkZS5lfEqK
p1byEdqXW04sc3UBdNlirYNOBJA0wOPgco45G2S3gFBh5XQZ9YCLB+x/IN8rW1mS
wQ3FrXRdEKfGMZ83xij1zOVpwi3bPJ5XrUzEV3sdGUdj6jWi0Pa05tRD+0qt7dpZ
oPq4p6aLj2z5/mwyiaW6T14CNY1Mp46tMgAv+BOJ/M3HA350isTGxG2X+73KeH0=
=xX4u
-----END PGP SIGNATURE-----

Re: [bitcoin-dev] What Lightning Is

[Pieter Wuille]

[-- Attachment #1: Type: text/plain, Size: 443 bytes --]

On Aug 10, 2015 7:03 PM, "odinn via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
Note that I've
> been in favor of going ahead with Cameron Garnham's dynamic softfork
> proposal right now, which can be seen at http://is.gd/DiFuRr

No offence, but I think that anyone who claims a block size limit change
can be done as a soft fork has some basic reading to do first.

Also, please keep this thread about Lightning.

-- 
Pieter

[-- Attachment #2: Type: text/html, Size: 656 bytes --]

Re: [bitcoin-dev] What Lightning Is

[odinn]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Replying because.

On 08/10/2015 10:14 AM, Pieter Wuille wrote:
> 
> On Aug 10, 2015 7:03 PM, "odinn via bitcoin-dev" 
> <bitcoin-dev@lists.linuxfoundation.org 
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote: Note that
> I've
>> been in favor of going ahead with Cameron Garnham's dynamic
>> softfork proposal right now, which can be seen at
>> http://is.gd/DiFuRr
> 
> No offence, but I think that anyone who claims a block size limit
> change can be done as a soft fork has some basic reading to do
> first.

Technically, my proposal has been thus:

"Note that I've
been in favor of going ahead with Cameron Garnham's dynamic softfork
proposal right now, which can be seen at http://is.gd/DiFuRr - testing
it out, seeing how that works, and at the same time making
preparations for moving forward with Garzik's BIP 100 (which could be
tailored or refined based on additional data gathered, without being
turned into a controversial fork"

To have quoted it only in part was unfair.

> 
> Also, please keep this thread about Lightning.

Agreed.

> 
> -- Pieter
> 

- -- 
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVyOMjAAoJEGxwq/inSG8CmAQIAI5XrAIa8VrkFYLtJ8s0CHqj
kZrMatH2oVGGaENVChVDU7u4SGnMQdiJF32QY5Olih3ia1rAx9n43tiyPyUp8y0S
iLudwFfyvmzSyRdoLnTRbDYkiNUnuy9lppZsL+AtQWCpMLxBIObs1NnzP7je4Qn2
a8lWklMf9mmlCyhyah7kJPdZzECwfpz2ARk68iUUAuqqLcFM2afmzcgLh2PuDRhU
6Hjw7crTXA5AhPSeNNz1az0cq5MTUv46SAr3mbAiMjFwz7tFWSWEGMTaTdQ/Igwe
JeMARTJuxY7QL1XHAmKgfHUEi6mmW2LiG0vm6xp8XnRfsUNfDVZ8IsmYky7kDLM=
=5Aay
-----END PGP SIGNATURE-----

Re: [bitcoin-dev] What Lightning Is

[Tom Harding]

[-- Attachment #1: Type: text/plain, Size: 572 bytes --]

On Aug 9, 2015 11:54 AM, "Mark Friedenbach" <mark@friedenbach.org> wrote:

> On the contrary the funds were advanced by the hub on the creation of the
channel. There is no credit involved.

That's a chuckle.

As I said, nothing requires the hub to advance anything, and if it does,
Bob can expect to pay for it.

We'll see whether hubs assess a fee for depositing funds, whether the fee
depends on the amount deposited, and whether it depends on the amount of
time it stays there.

I predict "all of the above." There is a name for these kinds of fees.  Can
you guess it?

[-- Attachment #2: Type: text/html, Size: 766 bytes --]

Re: [bitcoin-dev] What Lightning Is

[Chris Pacia]

[-- Attachment #1: Type: text/plain, Size: 1264 bytes --]

I'm glad Tom is bringing these points up. There seems to be an assumption
by many that LN will be automatically awesome by virtue of it being
technically feasible with having considered whether it is economically
feasible or desirable.

So much stock has been placed in LN as the solution to the block size
debate, yet it could turn out that it sucks in practice. Then what?
On Aug 9, 2015 5:27 PM, "Tom Harding via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Aug 9, 2015 11:54 AM, "Mark Friedenbach" <mark@friedenbach.org> wrote:
>
> > On the contrary the funds were advanced by the hub on the creation of
> the channel. There is no credit involved.
>
> That's a chuckle.
>
> As I said, nothing requires the hub to advance anything, and if it does,
> Bob can expect to pay for it.
>
> We'll see whether hubs assess a fee for depositing funds, whether the fee
> depends on the amount deposited, and whether it depends on the amount of
> time it stays there.
>
> I predict "all of the above." There is a name for these kinds of fees.
> Can you guess it?
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 1914 bytes --]

Re: [bitcoin-dev] What Lightning Is

[Hector Chu]

[-- Attachment #1: Type: text/plain, Size: 1863 bytes --]

Tom, my understanding is that the money that is debited from a payment hub
is simultaneously credited from either another payment hub or the person
making the payment, so that the net funds flow at a payment hub always sums
to zero. So no, there is no credit advanced by the payment hub to anyone.

Given Mark's previous answer of using CPFP and other tricks to pay for the
Bitcoin transaction fees, we can assume that Bitcoin fees do not play a
part in the payment channel balances.

So, the interesting question is what are the costs of running a payment
hub? The tx fees that a payment hub would have to pay to settle its Bitcoin
transactions would be passed on as a cost to the clients of the payment
hub. Also there is a cost to locking up funds in a payment channel (time
value of money). The lost interest or opportunity cost on those funds would
need to be paid for by its clients as well. And don't forget normal running
costs such as networking and electricity.

On 9 August 2015 at 22:27, Tom Harding via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Aug 9, 2015 11:54 AM, "Mark Friedenbach" <mark@friedenbach.org> wrote:
>
> > On the contrary the funds were advanced by the hub on the creation of
> the channel. There is no credit involved.
>
> That's a chuckle.
>
> As I said, nothing requires the hub to advance anything, and if it does,
> Bob can expect to pay for it.
>
> We'll see whether hubs assess a fee for depositing funds, whether the fee
> depends on the amount deposited, and whether it depends on the amount of
> time it stays there.
>
> I predict "all of the above." There is a name for these kinds of fees.
> Can you guess it?
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 2619 bytes --]

Re: [bitcoin-dev] What Lightning Is

[Patrick Strateman]

[-- Attachment #1: Type: text/plain, Size: 2695 bytes --]

The costs of operating a hub are as follows:

Time value of the funds the Hub has locked up in payment channels.
Enhanced risk of loss of control of private keys (the keys necessarily
need to be on an internet connected system).
Operating costs (I expect this will be minimal).

The hub can charge a fee for it's services to recoup these costs.

On 08/09/2015 02:45 PM, Hector Chu via bitcoin-dev wrote:
> Tom, my understanding is that the money that is debited from a payment
> hub is simultaneously credited from either another payment hub or the
> person making the payment, so that the net funds flow at a payment hub
> always sums to zero. So no, there is no credit advanced by the payment
> hub to anyone.
>
> Given Mark's previous answer of using CPFP and other tricks to pay for
> the Bitcoin transaction fees, we can assume that Bitcoin fees do not
> play a part in the payment channel balances.
>
> So, the interesting question is what are the costs of running a
> payment hub? The tx fees that a payment hub would have to pay to
> settle its Bitcoin transactions would be passed on as a cost to the
> clients of the payment hub. Also there is a cost to locking up funds
> in a payment channel (time value of money). The lost interest or
> opportunity cost on those funds would need to be paid for by its
> clients as well. And don't forget normal running costs such as
> networking and electricity.
>
> On 9 August 2015 at 22:27, Tom Harding via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>
>     On Aug 9, 2015 11:54 AM, "Mark Friedenbach" <mark@friedenbach.org
>     <mailto:mark@friedenbach.org>> wrote:
>
>     > On the contrary the funds were advanced by the hub on the creation of the channel. There is no credit
>     involved.
>
>     That's a chuckle. 
>
>     As I said, nothing requires the hub to advance anything, and if it
>     does, Bob can expect to pay for it.
>
>     We'll see whether hubs assess a fee for depositing funds, whether
>     the fee depends on the amount deposited, and whether it depends on
>     the amount of time it stays there.
>
>     I predict "all of the above." There is a name for these kinds of
>     fees.  Can you guess it?
>
>
>     _______________________________________________
>     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


[-- Attachment #2: Type: text/html, Size: 4708 bytes --]

Re: [bitcoin-dev] What Lightning Is

[Hector Chu]

[-- Attachment #1: Type: text/plain, Size: 3162 bytes --]

Ok good. We have established it to be a non-trivial cost.
Now, what is the growth complexity of the total cost of the network in
terms of number of connections each hub has to other hubs? And then,
consider a payment channel with many hops in it. The end-to-end users would
have to swallow all the costs of the hubs in the channel.

On 9 August 2015 at 22:57, Patrick Strateman via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> The costs of operating a hub are as follows:
>
> Time value of the funds the Hub has locked up in payment channels.
> Enhanced risk of loss of control of private keys (the keys necessarily
> need to be on an internet connected system).
> Operating costs (I expect this will be minimal).
>
> The hub can charge a fee for it's services to recoup these costs.
>
>
> On 08/09/2015 02:45 PM, Hector Chu via bitcoin-dev wrote:
>
> Tom, my understanding is that the money that is debited from a payment hub
> is simultaneously credited from either another payment hub or the person
> making the payment, so that the net funds flow at a payment hub always sums
> to zero. So no, there is no credit advanced by the payment hub to anyone.
>
> Given Mark's previous answer of using CPFP and other tricks to pay for the
> Bitcoin transaction fees, we can assume that Bitcoin fees do not play a
> part in the payment channel balances.
>
> So, the interesting question is what are the costs of running a payment
> hub? The tx fees that a payment hub would have to pay to settle its Bitcoin
> transactions would be passed on as a cost to the clients of the payment
> hub. Also there is a cost to locking up funds in a payment channel (time
> value of money). The lost interest or opportunity cost on those funds would
> need to be paid for by its clients as well. And don't forget normal running
> costs such as networking and electricity.
>
> On 9 August 2015 at 22:27, Tom Harding via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> On Aug 9, 2015 11:54 AM, "Mark Friedenbach" <mark@friedenbach.org> wrote:
>>
>> > On the contrary the funds were advanced by the hub on the creation of
>> the channel. There is no credit involved.
>>
>> That's a chuckle.
>>
>> As I said, nothing requires the hub to advance anything, and if it does,
>> Bob can expect to pay for it.
>>
>> We'll see whether hubs assess a fee for depositing funds, whether the fee
>> depends on the amount deposited, and whether it depends on the amount of
>> time it stays there.
>>
>> I predict "all of the above." There is a name for these kinds of fees.
>> Can you guess it?
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
>
> _______________________________________________
> bitcoin-dev mailing listbitcoin-dev@lists.linuxfoundation.orghttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 5521 bytes --]

Re: [bitcoin-dev] What Lightning Is

[Patrick Strateman]

[-- Attachment #1: Type: text/plain, Size: 4650 bytes --]

On the contrary those costs are clearly very low.

Both the time value of money and operating expenses will be trivial with
even a small volume of transactions.

The true cost of operating a hub is clearly in the enhanced risk of loss.

It's clear that risk of loss will be moderated by market forces.

The hubs which are better at securing their systems will reduce their
risk of loss and obtain a competitive advantage.

It's also important to note that the risk of loss is the same whether
the hub is doing 1 transaction/second or 1 million transactions/second.

At 1 transaction/second the cost (but not necessarily the fees) is going
to be quite high.

At 1 million transactions/second the cost is going to be very very low.

On 08/09/2015 03:03 PM, Hector Chu wrote:
> Ok good. We have established it to be a non-trivial cost.
> Now, what is the growth complexity of the total cost of the network in
> terms of number of connections each hub has to other hubs? And then,
> consider a payment channel with many hops in it. The end-to-end users
> would have to swallow all the costs of the hubs in the channel.
>
> On 9 August 2015 at 22:57, Patrick Strateman via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>
>     The costs of operating a hub are as follows:
>
>     Time value of the funds the Hub has locked up in payment channels.
>     Enhanced risk of loss of control of private keys (the keys
>     necessarily need to be on an internet connected system).
>     Operating costs (I expect this will be minimal).
>
>     The hub can charge a fee for it's services to recoup these costs.
>
>
>     On 08/09/2015 02:45 PM, Hector Chu via bitcoin-dev wrote:
>>     Tom, my understanding is that the money that is debited from a
>>     payment hub is simultaneously credited from either another
>>     payment hub or the person making the payment, so that the net
>>     funds flow at a payment hub always sums to zero. So no, there is
>>     no credit advanced by the payment hub to anyone.
>>
>>     Given Mark's previous answer of using CPFP and other tricks to
>>     pay for the Bitcoin transaction fees, we can assume that Bitcoin
>>     fees do not play a part in the payment channel balances.
>>
>>     So, the interesting question is what are the costs of running a
>>     payment hub? The tx fees that a payment hub would have to pay to
>>     settle its Bitcoin transactions would be passed on as a cost to
>>     the clients of the payment hub. Also there is a cost to locking
>>     up funds in a payment channel (time value of money). The lost
>>     interest or opportunity cost on those funds would need to be paid
>>     for by its clients as well. And don't forget normal running costs
>>     such as networking and electricity.
>>
>>     On 9 August 2015 at 22:27, Tom Harding via bitcoin-dev
>>     <bitcoin-dev@lists.linuxfoundation.org
>>     <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>>
>>         On Aug 9, 2015 11:54 AM, "Mark Friedenbach"
>>         <mark@friedenbach.org <mailto:mark@friedenbach.org>> wrote:
>>
>>         > On the contrary the funds were advanced by the hub on the creation of the channel.
>>         There is no credit involved.
>>
>>         That's a chuckle. 
>>
>>         As I said, nothing requires the hub to advance anything, and
>>         if it does, Bob can expect to pay for it.
>>
>>         We'll see whether hubs assess a fee for depositing funds,
>>         whether the fee depends on the amount deposited, and whether
>>         it depends on the amount of time it stays there.
>>
>>         I predict "all of the above." There is a name for these kinds
>>         of fees.  Can you guess it?
>>
>>
>>         _______________________________________________
>>         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
>     <mailto:bitcoin-dev@lists.linuxfoundation.org>
>     https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>


[-- Attachment #2: Type: text/html, Size: 8833 bytes --]

Re: [bitcoin-dev] What Lightning Is

[Tom Harding]

On 8/9/2015 2:45 PM, Hector Chu wrote:
> Tom, my understanding is that the money that is debited from a payment
> hub is simultaneously credited from either another payment hub or the
> person making the payment, so that the net funds flow at a payment hub
> always sums to zero.

That describes the steady-state dynamics.  I refer to the hub funding
required to initiate and maintain the ability to receive payments.

If Bob opens a channel at his hub, doesn't use it for spending, and
Alice sends 1 BTC to the channel, her payment can only be applied if the
hub has funded the channel with at least 1 BTC.

Yes, the hub receives an offsetting payment (from Alice, ultimately) in
another channel.  But to make this work, it must subject 1 BTC to shared
control with Bob and forfeit the use of that money for other purposes
(opportunity cost) while the channel is open.  The opportunity cost is
likened to gold lease rates in the LN paper.  I would be surprised if
the rates charged to consumers for BTC credit aren't much closer to
today's BTC borrowing rates.  We'll see.

Burying this cost in general fees might not work very well, because
different Bobs may want different maximum payment amounts, and channels
open for different lengths of time.

Re: [bitcoin-dev] What Lightning Is

[Patrick Strateman]

> I would be surprised if the rates charged to consumers for BTC credit
aren't much closer to today's BTC borrowing rates.

The borrowing rates you're talking about involve the risk of default.

In lightning the hubs funds are not at risk so long as they maintain
control of the private keys.

The rates charged by hubs will almost certainly be orders of magnitude
below the rates charged on the various p2p lending sites....

But that seems fairly obvious... did I miss something?

On 08/09/2015 06:52 PM, Tom Harding via bitcoin-dev wrote:
> On 8/9/2015 2:45 PM, Hector Chu wrote:
>> Tom, my understanding is that the money that is debited from a payment
>> hub is simultaneously credited from either another payment hub or the
>> person making the payment, so that the net funds flow at a payment hub
>> always sums to zero.
> 
> That describes the steady-state dynamics.  I refer to the hub funding
> required to initiate and maintain the ability to receive payments.
> 
> If Bob opens a channel at his hub, doesn't use it for spending, and
> Alice sends 1 BTC to the channel, her payment can only be applied if the
> hub has funded the channel with at least 1 BTC.
> 
> Yes, the hub receives an offsetting payment (from Alice, ultimately) in
> another channel.  But to make this work, it must subject 1 BTC to shared
> control with Bob and forfeit the use of that money for other purposes
> (opportunity cost) while the channel is open.  The opportunity cost is
> likened to gold lease rates in the LN paper.  I would be surprised if
> the rates charged to consumers for BTC credit aren't much closer to
> today's BTC borrowing rates.  We'll see.
> 
> Burying this cost in general fees might not work very well, because
> different Bobs may want different maximum payment amounts, and channels
> open for different lengths of time.
> 
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 

Re: [bitcoin-dev] What Lightning Is

[Patrick Strateman]

[-- Attachment #1: Type: text/plain, Size: 1366 bytes --]

I suspect there is some amount of confusion here on terms.

The hub is essentially swapping funds between payment channels.

The hub's entire business is centered around having payment channels
open with other hubs/users.

If the hub requires user funds to open these channels... then the users
have no reason to pay the hub anything in fees.

A hub that doesn't use it's own funds to open payment channels to other
hubs/merchants is useless.

On 08/09/2015 02:27 PM, Tom Harding via bitcoin-dev wrote:
>
> On Aug 9, 2015 11:54 AM, "Mark Friedenbach" <mark@friedenbach.org
> <mailto:mark@friedenbach.org>> wrote:
>
> > On the contrary the funds were advanced by the hub on the creation
> of the channel. There is no credit involved.
>
> That's a chuckle. 
>
> As I said, nothing requires the hub to advance anything, and if it
> does, Bob can expect to pay for it.
>
> We'll see whether hubs assess a fee for depositing funds, whether the
> fee depends on the amount deposited, and whether it depends on the
> amount of time it stays there.
>
> I predict "all of the above." There is a name for these kinds of
> fees.  Can you guess it?
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


[-- Attachment #2: Type: text/html, Size: 2299 bytes --]

Re: [bitcoin-dev] What Lightning Is

[Hector Chu]

[-- Attachment #1: Type: text/plain, Size: 1753 bytes --]

Right, you've stated a bunch of facts, but how does it answer my concerns
of the exploding cost of the network the more interconnected it it?

On 9 August 2015 at 23:06, Patrick Strateman via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I suspect there is some amount of confusion here on terms.
>
> The hub is essentially swapping funds between payment channels.
>
> The hub's entire business is centered around having payment channels open
> with other hubs/users.
>
> If the hub requires user funds to open these channels... then the users
> have no reason to pay the hub anything in fees.
>
> A hub that doesn't use it's own funds to open payment channels to other
> hubs/merchants is useless.
>
>
> On 08/09/2015 02:27 PM, Tom Harding via bitcoin-dev wrote:
>
> On Aug 9, 2015 11:54 AM, "Mark Friedenbach" <mark@friedenbach.org> wrote:
>
> > On the contrary the funds were advanced by the hub on the creation of
> the channel. There is no credit involved.
>
> That's a chuckle.
>
> As I said, nothing requires the hub to advance anything, and if it does,
> Bob can expect to pay for it.
>
> We'll see whether hubs assess a fee for depositing funds, whether the fee
> depends on the amount deposited, and whether it depends on the amount of
> time it stays there.
>
> I predict "all of the above." There is a name for these kinds of fees.
> Can you guess it?
>
>
> _______________________________________________
> bitcoin-dev mailing listbitcoin-dev@lists.linuxfoundation.orghttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 3115 bytes --]

Re: [bitcoin-dev] What Lightning Is

[Patrick Strateman]

[-- Attachment #1: Type: text/plain, Size: 2168 bytes --]

That was not in reply to you.

On 08/09/2015 03:09 PM, Hector Chu wrote:
> Right, you've stated a bunch of facts, but how does it answer my
> concerns of the exploding cost of the network the more interconnected
> it it?
>
> On 9 August 2015 at 23:06, Patrick Strateman via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>
>     I suspect there is some amount of confusion here on terms.
>
>     The hub is essentially swapping funds between payment channels.
>
>     The hub's entire business is centered around having payment
>     channels open with other hubs/users.
>
>     If the hub requires user funds to open these channels... then the
>     users have no reason to pay the hub anything in fees.
>
>     A hub that doesn't use it's own funds to open payment channels to
>     other hubs/merchants is useless.
>
>
>     On 08/09/2015 02:27 PM, Tom Harding via bitcoin-dev wrote:
>>
>>     On Aug 9, 2015 11:54 AM, "Mark Friedenbach" <mark@friedenbach.org
>>     <mailto:mark@friedenbach.org>> wrote:
>>
>>     > On the contrary the funds were advanced by the hub on the
>>     creation of the channel. There is no credit involved.
>>
>>     That's a chuckle. 
>>
>>     As I said, nothing requires the hub to advance anything, and if
>>     it does, Bob can expect to pay for it.
>>
>>     We'll see whether hubs assess a fee for depositing funds, whether
>>     the fee depends on the amount deposited, and whether it depends
>>     on the amount of time it stays there.
>>
>>     I predict "all of the above." There is a name for these kinds of
>>     fees.  Can you guess it?
>>
>>
>>
>>     _______________________________________________
>>     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
>
>


[-- Attachment #2: Type: text/html, Size: 4654 bytes --]

Re: [bitcoin-dev] What Lightning Is

[Hector Chu]

[-- Attachment #1: Type: text/plain, Size: 2295 bytes --]

Sorry about that Patrick. Gmail hides previous messages including sender
names. Regardless, no worries.

On 9 August 2015 at 23:27, Patrick Strateman via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> That was not in reply to you.
>
>
> On 08/09/2015 03:09 PM, Hector Chu wrote:
>
> Right, you've stated a bunch of facts, but how does it answer my concerns
> of the exploding cost of the network the more interconnected it it?
>
> On 9 August 2015 at 23:06, Patrick Strateman via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> I suspect there is some amount of confusion here on terms.
>>
>> The hub is essentially swapping funds between payment channels.
>>
>> The hub's entire business is centered around having payment channels open
>> with other hubs/users.
>>
>> If the hub requires user funds to open these channels... then the users
>> have no reason to pay the hub anything in fees.
>>
>> A hub that doesn't use it's own funds to open payment channels to other
>> hubs/merchants is useless.
>>
>>
>> On 08/09/2015 02:27 PM, Tom Harding via bitcoin-dev wrote:
>>
>> On Aug 9, 2015 11:54 AM, "Mark Friedenbach" <mark@friedenbach.org> wrote:
>>
>> > On the contrary the funds were advanced by the hub on the creation of
>> the channel. There is no credit involved.
>>
>> That's a chuckle.
>>
>> As I said, nothing requires the hub to advance anything, and if it does,
>> Bob can expect to pay for it.
>>
>> We'll see whether hubs assess a fee for depositing funds, whether the fee
>> depends on the amount deposited, and whether it depends on the amount of
>> time it stays there.
>>
>> I predict "all of the above." There is a name for these kinds of fees.
>> Can you guess it?
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing listbitcoin-dev@lists.linuxfoundation.orghttps://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
>
>

[-- Attachment #2: Type: text/html, Size: 5219 bytes --]

Re: [bitcoin-dev] What Lightning Is

[Gavin Andresen]

[-- Attachment #1: Type: text/plain, Size: 776 bytes --]

While we're on the subject of payment hubs / lightning network...

I'd love to see somebody write up a higher-level description of what the
user experience is like, what communication happens underneath, and what
new pieces of infrastructure need to get built to make it all work.

A use-case to start with:

A customer starts with eleven on-chain bitcoin. They want to pay for a nice
cup of tea. Walk me through what happens before/during/after the
transaction, assuming I have a  lightning-enabled wallet on my iPhone and
the tea shop has a lightning-enabled cash register.

Assume neither the customer nor the tea shop are technically sophisticated
-- assume the customer is using an SPV wallet and the tea shop is using a
service similar to Bitpay.

-- 
--
Gavin Andresen

[-- Attachment #2: Type: text/html, Size: 1033 bytes --]

Re: [bitcoin-dev] What Lightning Is

[Btc Drak]

[-- Attachment #1: Type: text/plain, Size: 228 bytes --]

I thought it's worth mentioning there is a specific Lightning Network
development mailing list at
http://lists.linuxfoundation.org/mailman/listinfo/lightning-dev and already
some pretty interesting explanations in the archives.

[-- Attachment #2: Type: text/html, Size: 332 bytes --]

Re: [bitcoin-dev] What Lightning Is

[Thomas Zander]

On Sunday 9. August 2015 23.51.50 Btc Drak via bitcoin-dev wrote:
> I thought it's worth mentioning there is a specific Lightning Network
> development mailing list at
> http://lists.linuxfoundation.org/mailman/listinfo/lightning-dev and already
> some pretty interesting explanations in the archives.

While that is interesting, and I'll surely check it out, I think this list 
should get a good idea of what the limitations are.

Where does it NOT make sense to use LN, where would it be better to put the 
transaction directly on the blockchain?

This is what I'd like to know.

Gavins usecase is useful, I'm also wondering about remittances and allowing 
international payments and global economy (company in Nairobi buys stock from 
company in Spain).
-- 
Thomas Zander

Re: [bitcoin-dev] What Lightning Is

[Patrick Strateman]

If a path cannot be built to the recipient through the lightning network
then a standard transaction should be used.

On 08/10/2015 01:27 AM, Thomas Zander via bitcoin-dev wrote:
> On Sunday 9. August 2015 23.51.50 Btc Drak via bitcoin-dev wrote:
>> I thought it's worth mentioning there is a specific Lightning Network
>> development mailing list at
>> http://lists.linuxfoundation.org/mailman/listinfo/lightning-dev and already
>> some pretty interesting explanations in the archives.
> While that is interesting, and I'll surely check it out, I think this list 
> should get a good idea of what the limitations are.
>
> Where does it NOT make sense to use LN, where would it be better to put the 
> transaction directly on the blockchain?
>
> This is what I'd like to know.
>
> Gavins usecase is useful, I'm also wondering about remittances and allowing 
> international payments and global economy (company in Nairobi buys stock from 
> company in Spain).

Re: [bitcoin-dev] What Lightning Is

[Joseph Poon]

Hi Gavin,

On Sun, Aug 09, 2015 at 06:44:08PM -0400, Gavin Andresen via bitcoin-dev wrote:
> I'd love to see somebody write up a higher-level description of what the
> user experience is like, what communication happens underneath, and what
> new pieces of infrastructure need to get built to make it all work.

I'm writing a (hopefully more accessible) summary on Lightning
currently. It might not go into too much detail with infrastructure, but
is a bit more UX focused.

> A customer starts with eleven on-chain bitcoin. They want to pay for a nice
> cup of tea. Walk me through what happens before/during/after the
> transaction, assuming I have a  lightning-enabled wallet on my iPhone and
> the tea shop has a lightning-enabled cash register.
> 
> Assume neither the customer nor the tea shop are technically sophisticated
> -- assume the customer is using an SPV wallet and the tea shop is using a
> service similar to Bitpay.

It's a bit of a tangent, but I see it as necessary that all Lightning
services/wallets support on-chain payments for a multitude of reasons,
including usability and long-term security/fungibility. For that reason,
the UX flow for payment after channels are established should not be
significantly different than Payment Protocol based payment flows (with
the only exception being a possible additional fee dialog box/alert when
the fees will be higher than expected/on-chain).

-- 
Joseph Poon

Re: [bitcoin-dev] What Lightning Is

[Anthony Towns]

On Sun, Aug 09, 2015 at 06:44:08PM -0400, Gavin Andresen via bitcoin-dev wrote:
> I'd love to see somebody write up a higher-level description of what the
> user experience is like, what communication happens underneath, and what
> new pieces of infrastructure need to get built to make it all work.
> 
> A use-case to start with:
> 
> A customer starts with eleven on-chain bitcoin. They want to pay for a nice
> cup of tea.

IMO:

 1. User swipes their phone over merchant's NFC device
    (or scans a QR code displayed by the register or whatever)

 2. Dialog pops up on phone:
     "Pay Infinitea $5.20? [yes] [no]"

 3. User presses [yes]

 4. Brief pause

 5. "Payment confirmed" appears on both user's phone and merchant's POS
    device

The backend bits that need to happen:

 1. Merchant passes on their identity and public key, an amount, and a
    hash for the payment.

 2. User's phone goes online to see if a route to the vendor can be
    worked out, and to work out what lightning network fees are needed.
    Also translates the bitcoins requested into the user's preferred
    currency so they don't have to do maths in their head.

 3. User's phone prepares a lightning transaction to the vendor, signed
    with the corresponding lightning channel keys, using the hash the
    merchant provided, and sends it through one of the channels the user
    already has open and funded (at >$5.20 worth of bitcoins).

 4. The transaction makes its way through the lightning network, and the
    confirmation makes its way back. It's not clear to me how long this
    realistically takes (either how many hops are likely, or how long
    a single hop will actually take; I assume it should be a couple
    of seconds).

 5. UIs at both ends update. User gets a nice cup of tea.

There's a few potential problems with this:

 - what if the merchant says "no you didn't pay me, your phone is lying,
   you're a liar, I hate you, no tea for you" despite your phone saying
   you paid?

     a) you could mitigate this by having the payments be incremental
        (here's 1c, 520 times) with both terminals visibly updating;
        but that would take up to 520x longer than sending a single
        transaction, and mightn't really be any better anyway

     b) you could also have the initial negotiation involve signing
        something that could be adjudicated independently later (hey,
        here's a QR code saying he owed me a tea, here's a QR code showing
        I paid for it, and here's a video of him saying "no tea for you").

     c) Or maybe you just bite the $5 and never shop there again; just
        as you would if you handed over $5.20 in cash and then they told
        you you hadn't paid them.

 - what if the transaction's unroutable? then you get a "service
   unavailable" notice on your phone and pay by other means -- blockchain,
   cash, etc. Same as if your credit card won't register. ditto if your
   phone can't get on the internet.

 - what if the fees are large? (eg, the coffee costs $5, and the fees are
   20c?)

     a) I think they'll actually be small -- even for a 10% pa interest
        rate denominated in bitcoin, the time-value of $5.20 in bitcoin
        for 7 days is just under 1c (.35%). If so, that's noise, and the
        user legitimately doesn't care. OTOH, it does get multiplied by
        number of hops, and maybe the user cares about $5.20 vs $5.26.

     b) Alternatively, the app could just indicate the fees ("Pay $5.20 +
        <1c in fees") and/or the user could have an explicit setting for
        fee info ("Only warn me when fees are greater than either 5c/1%")

     c) Or you could have some UI magic, so the vendor's POS device
        initially says "advertised price is $5.20, but I actually
        expect just $5.05, call the rest a discount", the phone says
        "fees are 5c, so I'll display "Pay just $5.10 for a $5.20 cup of
        coffee!". That's closer to how Visa/Mastercard do it and might
        be reasonable in many cases.

 - what happens if the user presses "yes" but the lightning transaction
   then fails? you don't want to wait for the 7 day timeout to know if
   you can have a cup of tea; and you don't want the payment to go through
   after you've paid for your tea in cash, drank it, and gone home.

     a) Maybe the lightning network hubs just reply early cancelling the
        transactions, and your phone can say "failed". You can't force
        them to do this, but maybe the incentives work out okay so that
        they'll want to anyway. (I think they will) If so, everything's
        fine. As far as the merchant's concerned, you may as well have
        just pressed "No".

     b) The vendor could issue a conditional refund, eg an on-blockchain
        transaction for the amount of the coffee from them to you,
        payable if you ever receive the hash token. (And if you don't,
        redeemable by them after a timeout). That doesn't work real well
        if the fee for a blockchain txn is more than the price of a cup
        of tea of course.

> Assume neither the customer nor the tea shop are technically sophisticated
> -- assume the customer is using an SPV wallet and the tea shop is using a
> service similar to Bitpay.

IMHO, most of the complexity isn't in doing the transaction, it's in
maintaining the channels. For example:

 - what if the tea shop has a sudden run of customers, and all their
   payment channels fill up?

 - how do you close the till at the end of the day (ie, put your
   earnings into a cold wallet so they can't be hacked as easily and
   clear your channel so you can accept more payments tomorrow?) Do you
   do this on the blockchain or do you have a different lightning
   network channel to your "bank account"?

 - inversely; if you do all your weekly shopping and impulse buys (tea,
   coffee, beer, meals, groceries, fuel, road tolls, ...) on lightning,
   how do you reset your channels once a day/week/fortnight/month with
   some money from your salary/savings, so they don't run out?

 - do refunds work, even after the original txn has finished? ("Oh,
   actually we're out of tea")

 - you have to watch the blockchain once a week or so in case your
   counterparty tries stealing your balance by replaying old states and
   hoping you don't notice

 - how do you keep the channel keys/secrets sufficiently available
   and secure?

 - how do you figure out who to make channels with in the first place,
   and if/when to change them?

 - what happens if your phone breaks, is stolen or gets lost; have you
   lost your channel secrets, and potentially all the coins in your
   balance?

 - etc.

(I don't think they're unsolvable or anything, though)

Cheers,
aj

Re: [bitcoin-dev] What Lightning Is

[Anthony Towns]

On Tue, Aug 11, 2015 at 05:02:40AM +0800, Anthony Towns wrote:
> On Sun, Aug 09, 2015 at 06:44:08PM -0400, Gavin Andresen via bitcoin-dev wrote:
> > I'd love to see somebody write up a higher-level description of what the
> > user experience is like, what communication happens underneath, and what
> > new pieces of infrastructure need to get built to make it all work.
> > 
> > A use-case to start with:
> > 
> > A customer starts with eleven on-chain bitcoin. They want to pay for a nice
> > cup of tea.

Sigh, kanzure on irc points out I misread this -- I read "on-channel"
not "on-chain".

In that case, I think the answer is "the customer doesn't pay for tea
via lightning". They have to setup a channel with someone first, and
to do that, they'll need a "sufficiently confirmed" anchor transaction,
and I don't think zero confirmations would be enough for that.

So:

 -1 "Oh, how did that guy pay for tea with his phone? That's cool!"
    "Scan the QR code, yeah, where the lightning logo is"
    "Cool, I'll try it tomorrow"

 0 go home, "open a lightning channel", sleep, look forward to getting
   tea tomorrow

For step 0, I guess it's:

 0.1 "Choose a hub to connect to" (could be randomly selected)
 0.2 "Choose an amount to fund the channel" (0.5 btc would be a lot)
 0.3 "Are you sure?"
 0.4 [wait briefly while counterparty signs]
 0.5 [wait for 10 confirmations?]

I don't think it's at all clear how 0.1 works in practice yet -- routing
has barely been spitballed, and without knowing how routing works, it's
hard to say who to connect to.

Hard to say how much to put in in step 0.2 too -- if it takes a while to
refresh funds in a channel (you have to do a blockchain txn eg), then
that you should put more in; if you have multiple channels for whatever
reason, maybe you can put less in each.

The "Are you sure?" might require some legal T&Cs in practice.

You need to have some realtime communication with your channel
counterpary when creating the anchor; but that should be fairly quick.
You also need to establish some random numbers and keys, but those could
be done in advance.

I think you (or your counterparty) will want to wait for a few
confirmations before your channel is actually usable. So I think it'll
take over an hour for a channel to be "open" in even the best case.

Cheers,
aj

Re: [bitcoin-dev] What Lightning Is

[Adam Back]

In terms of usage I think you'd more imagine a wallet that basically
parks Bitcoins onto channels at all times, so long as they are
routable there is no loss, and the scalability achieved thereby is
strongly advantageous, and there is even the potential for users to
earn fees by having their wallets participate in channel rebalancing
(where hubs pay users to rebalance channels - end up with the same net
position but move funds from one user-owned channel to another.)
Exchange deposit, withdrawal, payments, even in-exchange trades can
usefully happen in lightning for faster, cheaper more scalable
transactions.

Adam

Re: [bitcoin-dev] What Lightning Is

[Hector Chu]

[-- Attachment #1: Type: text/plain, Size: 1186 bytes --]

Lightning will never catch on as it basically demands that everyone who
uses it to become a speculator. Payment hubs and merchants will be at the
mercy of the bitcoin price while their funds stay locked up in payment
channels. This idea is a dead-end.

On 10 August 2015 at 22:43, Adam Back via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> In terms of usage I think you'd more imagine a wallet that basically
> parks Bitcoins onto channels at all times, so long as they are
> routable there is no loss, and the scalability achieved thereby is
> strongly advantageous, and there is even the potential for users to
> earn fees by having their wallets participate in channel rebalancing
> (where hubs pay users to rebalance channels - end up with the same net
> position but move funds from one user-owned channel to another.)
> Exchange deposit, withdrawal, payments, even in-exchange trades can
> usefully happen in lightning for faster, cheaper more scalable
> transactions.
>
> Adam
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 1765 bytes --]

Re: [bitcoin-dev] What Lightning Is

[Simon Liu]

There's also an interesting question posted over at Reddit - will
Lightning payment hubs be treated as money transmitters in the US?

https://www.reddit.com/r/bitcoin_uncensored/comments/3gjnmd/lightning_may_not_be_a_scaling_solution/

A payment hub operator working with brand name merchants like Disney and
Gap would most likely adopt any licensing and AML/KYC regulations.

Some folk might thus find themselves forced to use anonymous hubs with
strict routing requirements to avoid commercial hubs.  Given the reduced
number of available channels, this could drive up lightning network fees
for those folk.

Of course, two parties can avoid any intermediary by using a regular
on-chain transaction, but it might not be feasible if Bitcoin is
operating as a settlement network with high transaction fees.


On 08/11/2015 02:01 AM, Hector Chu via bitcoin-dev wrote:
> Lightning will never catch on as it basically demands that everyone who
> uses it to become a speculator. Payment hubs and merchants will be at
> the mercy of the bitcoin price while their funds stay locked up in
> payment channels. This idea is a dead-end.
> 
> On 10 August 2015 at 22:43, Adam Back via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
> 
>     In terms of usage I think you'd more imagine a wallet that basically
>     parks Bitcoins onto channels at all times, so long as they are
>     routable there is no loss, and the scalability achieved thereby is
>     strongly advantageous, and there is even the potential for users to
>     earn fees by having their wallets participate in channel rebalancing
>     (where hubs pay users to rebalance channels - end up with the same net
>     position but move funds from one user-owned channel to another.)
>     Exchange deposit, withdrawal, payments, even in-exchange trades can
>     usefully happen in lightning for faster, cheaper more scalable
>     transactions.
> 
>     Adam
>     _______________________________________________
>     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
> 

Re: [bitcoin-dev] Block size following technological growth

[Bryan Bishop]

[-- Attachment #1: Type: text/plain, Size: 1624 bytes --]

On Fri, Jul 31, 2015 at 7:15 AM, Mike Hearn via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> He is not saying that. Whatever the reasons for centralization are, it
>> is obvious that increasing the size won't help.
>>
>
> It's not obvious. Quite possibly bigger blocks == more users == more nodes
> and more miners.
>

Well, even in a centralized scheme you can have more users, more nodes and
more miners. Just having more does not mean that the system isn't
centralized, for example we can point to many centralized services such as
PayPal that have trillions of users.


> To repeat: it's not obvious to me at all that everything wrong with
> Bitcoin can be solved by shrinking blocks. I don't think that's going to
> suddenly make everything magically more decentralised.
>

Nobody claimed that moving to smaller blocks would "solve everything wrong
with Bitcoin".

You cannot "destroy Bitcoin through centralization" by adjusting a single
> constant in the source code.
>

Why not? That's exactly the sort of change that would be useful to do so,
in tandem with some forms of campaigning.


> The motivation is profit, and profits are higher when there are more users
> to sell to. This is business 101.
>

I am confused here; is that idea operating under an assumption (or rule)
like "we shouldn't count aggregate transactions as representing multiple
other transactions from other users" or something? I have seen this idea in
a few places, and it would be useful to get a fix on where it's coming
from. Does this belief extend to P2SH and multisig...?

- Bryan
http://heybryan.org/
1 512 203 0507

[-- Attachment #2: Type: text/html, Size: 3076 bytes --]

Re: [bitcoin-dev] Block size following technological growth

[Jorge Timón]

On Thu, Jul 30, 2015 at 6:20 PM, Gavin Andresen via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Thu, Jul 30, 2015 at 10:25 AM, Pieter Wuille via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> So we'd get to 2MB blocks in the year 2021. I think that is much too
> conservative

When considering "too conservative" options, let's not forget that,
say, scheduling 2MB for 2020 doesn't preclude us from deciding that
was too conservative and schedule, say 4MB for 2018 later. The first
hardfork would be "useless", but it would set a "minimum increase"
that would have been useful if the second one never happened.

> I'll comment on using median time generally in Jorge's thread, but why does
> monotonically increasing matter for max block size? I can't think of a
> reason why a max block size of X bytes in block N followed by a max size of
> X-something bytes in block N+1 would cause any problems.

To be clear, for this concrete case block.nTime would just work just
fine. I just want us to decide on one of the options and uniformly
recommend that options for all cases in BIP99 [just renamed the file,
https://github.com/jtimon/bips/blob/bip-forks/bip-0099.org ].
But, yes, please, let's discuss this in the other thread.

Re: [bitcoin-dev] Block size following technological growth

[Anthony Towns]

On Thu, Jul 30, 2015 at 12:20:30PM -0400, Gavin Andresen wrote:
> On Thu, Jul 30, 2015 at 10:25 AM, Pieter Wuille via bitcoin-dev
> > Some things are not included yet, such as a testnet whose size runs ahead
> > of the main chain, and the inclusion of Gavin's more accurate sigop
> > checking after the hard fork.
> First, THANK YOU for making a concrete proposal!
> So we'd get to 2MB blocks in the year 2021. I think that is much too
> conservative, and the most likely effect of being that conservative is that
> the main blockchain becomes a settlement network, affordable only for
> large-value transactions.

I haven't seen anyone do the (trivial) maths on this. Have I just
missed it? By my count:

 - blocks in 25 btc in rewards and about 0.5 btc in fees per block
 - at ~$300 USD per btc, that's ~$7,650 per block

 - current hashrate is ~400 PH/s; so ~240,000 PH/block works out
   to having to spend about 30PH per dollar earnt.
 - for comparison,
      https://products.butterflylabs.com/cloud-mining-contracts.html
    quotes $1.99 per GH/s for 12 months, which by my count is
      60*60*24*365 / 1.99 GH/$ = 15.8 PH per dollar spent
 - hashrate growth has slowed from about x4/quarter to x2/year:
     sep '13: ~1PH/s
     dec '13: ~4PH/s
     mar '14: ~20PH/s
     jun '14: ~80PH/s
     sep '14: ~200PH/s
     aug '15: ~400PH/s

 - so, as far as I understand it, miners don't make absurd profits compared
   to capital investment and running costs
 - presumably, then, miners will stop mining bitcoin if the revenue/block
   drops significantly at some point
 - less miners means a lower hashrate; a lower hashrate makes
   50% attacks easier, and that's a bad thing (especially if there's lots
   of pre-loved ASIC mining hardware available cheap on ebay or alibaba)

 - in about a year, the block reward halves, cutting out 12.5 btc or
   ~$3750 USD per block. without an increase in fees per block, miners
   will just get ~$3900 USD per block
 - the last time the reward for mining a block was under $4000 per block
   was around oct '13, with a hashrate of ~2PH/s

 - 13 btc in fees per block compared to .5 btc in fees per block is a
   25x increase; which could be either an increase in fee/txn or
   txns/block
 - with ~500 bytes/transaction, that's ~2000 transactions per MB
 - 13 btc in fees ($3900) per block means per transaction fees of
   about
     $2 for 1MB blocks
     $1 for 2MB blocks
     25c for 8MB blocks
     10c for 20MB blocks
   (assuming full blocks, 500 byte txns)

 - comparing that to credit card or paypal fees at ~2.5% that's:
    $2 -> minimum transaction  $80
    $1 -> minimum transaction  $40
    25c -> minimum transaction $10
    10c -> minimum transaction  $4

 - those numbers only depend on the USD/BTC exchange rate in so far as
   the more USD for a BTC, the more likely the block reward will pay
   for hashrate without transaction fees, even with the reward reduced
   to 12.5 btc/block. otherwise it's just USD/txn paying for USD/hashrate

 - the reference implementation fee of 0.1mBTC/kB equates to about
   3c per transaction (since it rounds up). Even 10c/transaction is more
   than a 3x increase on that.

What the above says to me is that even assuming everyone starts paying
fees, the lightning network works great, and so do sidechains and whatever
else, you /still/ want to up the volume of bitcoin txns by something like
an order of magnitude above what's currently allowed within a year or so.

Cheers,
aj

Re: [bitcoin-dev] Block size following technological growth

[Thomas Zander]

On Thursday 30. July 2015 16.25.02 Pieter Wuille via bitcoin-dev wrote:
> Hello all,
> 
> here is a proposal for long-term scalability I've been working on:
> https://gist.github.com/sipa/c65665fc360ca7a176a6
> 
> Some things are not included yet, such as a testnet whose size runs ahead
> of the main chain, and the inclusion of Gavin's more accurate sigop
> checking after the hard fork.
> 
> Comments?


Maybe this part could use a bit more rationale, it looks like its a sudden and 
unexplained.

>  No hard forking change that relaxes the block size limit can be guaranteed
>  to provide enough space for every possible demand - or even any particular
>  demand - unless strong centralization of the mining ecosystem is expected.
-- 
Thomas Zander