* [bitcoin-dev] Block size following technological growth
@ 2015-07-30 14:25 Pieter Wuille
2015-07-30 15:04 ` Greg Sanders
` (3 more replies)
0 siblings, 4 replies; 111+ messages in thread
From: Pieter Wuille @ 2015-07-30 14:25 UTC (permalink / raw)
To: Bitcoin Dev
[-- 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 --]
^ permalink raw reply [flat|nested] 111+ messages in thread* Re: [bitcoin-dev] Block size following technological growth 2015-07-30 14:25 [bitcoin-dev] Block size following technological growth Pieter Wuille @ 2015-07-30 15:04 ` Greg Sanders 2015-07-30 15:12 ` Jorge Timón ` (2 subsequent siblings) 3 siblings, 0 replies; 111+ messages in thread From: Greg Sanders @ 2015-07-30 15:04 UTC (permalink / raw) To: Pieter Wuille; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Block size following technological growth 2015-07-30 14:25 [bitcoin-dev] Block size following technological growth Pieter Wuille 2015-07-30 15:04 ` Greg Sanders @ 2015-07-30 15:12 ` Jorge Timón 2015-07-30 16:23 ` Jameson Lopp ` (2 more replies) 2015-07-30 16:20 ` Gavin Andresen 2015-07-30 20:20 ` Thomas Zander 3 siblings, 3 replies; 111+ messages in thread From: Jorge Timón @ 2015-07-30 15:12 UTC (permalink / raw) To: Pieter Wuille; +Cc: Bitcoin Dev 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 > ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Block size following technological growth 2015-07-30 15:12 ` Jorge Timón @ 2015-07-30 16:23 ` Jameson Lopp 2015-07-30 16:36 ` Bryan Bishop 2015-07-30 16:36 ` Venzen Khaosan 2015-07-30 16:56 ` Gary Mulder 2 siblings, 1 reply; 111+ messages in thread From: Jameson Lopp @ 2015-07-30 16:23 UTC (permalink / raw) To: Jorge Timón; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Block size following technological growth 2015-07-30 16:23 ` Jameson Lopp @ 2015-07-30 16:36 ` Bryan Bishop 2015-07-30 16:43 ` Jameson Lopp 0 siblings, 1 reply; 111+ messages in thread From: Bryan Bishop @ 2015-07-30 16:36 UTC (permalink / raw) To: Jameson Lopp, Bryan Bishop, bitcoin-dev [-- 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 --] ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Block size following technological growth 2015-07-30 16:36 ` Bryan Bishop @ 2015-07-30 16:43 ` Jameson Lopp 0 siblings, 0 replies; 111+ messages in thread From: Jameson Lopp @ 2015-07-30 16:43 UTC (permalink / raw) To: Bryan Bishop; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Block size following technological growth 2015-07-30 15:12 ` Jorge Timón 2015-07-30 16:23 ` Jameson Lopp @ 2015-07-30 16:36 ` Venzen Khaosan 2015-07-30 17:51 ` Jorge Timón 2015-07-30 16:56 ` Gary Mulder 2 siblings, 1 reply; 111+ messages in thread From: Venzen Khaosan @ 2015-07-30 16:36 UTC (permalink / raw) To: Jorge Timón, Bitcoin Dev -----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----- ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Block size following technological growth 2015-07-30 16:36 ` Venzen Khaosan @ 2015-07-30 17:51 ` Jorge Timón 2015-07-30 18:00 ` Jorge Timón 0 siblings, 1 reply; 111+ messages in thread From: Jorge Timón @ 2015-07-30 17:51 UTC (permalink / raw) To: venzen; +Cc: Bitcoin Dev 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). ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Block size following technological growth 2015-07-30 17:51 ` Jorge Timón @ 2015-07-30 18:00 ` Jorge Timón 0 siblings, 0 replies; 111+ messages in thread From: Jorge Timón @ 2015-07-30 18:00 UTC (permalink / raw) To: venzen; +Cc: Bitcoin Dev 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). ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Block size following technological growth 2015-07-30 15:12 ` Jorge Timón 2015-07-30 16:23 ` Jameson Lopp 2015-07-30 16:36 ` Venzen Khaosan @ 2015-07-30 16:56 ` Gary Mulder 2015-07-30 17:13 ` Mark Friedenbach 2 siblings, 1 reply; 111+ messages in thread From: Gary Mulder @ 2015-07-30 16:56 UTC (permalink / raw) To: Jorge Timón; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Block size following technological growth 2015-07-30 16:56 ` Gary Mulder @ 2015-07-30 17:13 ` Mark Friedenbach 0 siblings, 0 replies; 111+ messages in thread From: Mark Friedenbach @ 2015-07-30 17:13 UTC (permalink / raw) To: Gary Mulder; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Block size following technological growth 2015-07-30 14:25 [bitcoin-dev] Block size following technological growth Pieter Wuille 2015-07-30 15:04 ` Greg Sanders 2015-07-30 15:12 ` Jorge Timón @ 2015-07-30 16:20 ` Gavin Andresen 2015-07-30 16:41 ` Suhas Daftuar ` (4 more replies) 2015-07-30 20:20 ` Thomas Zander 3 siblings, 5 replies; 111+ messages in thread From: Gavin Andresen @ 2015-07-30 16:20 UTC (permalink / raw) To: Pieter Wuille; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Block size following technological growth 2015-07-30 16:20 ` Gavin Andresen @ 2015-07-30 16:41 ` Suhas Daftuar 2015-07-30 16:48 ` Adam Back ` (3 subsequent siblings) 4 siblings, 0 replies; 111+ messages in thread From: Suhas Daftuar @ 2015-07-30 16:41 UTC (permalink / raw) To: Gavin Andresen; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Block size following technological growth 2015-07-30 16:20 ` Gavin Andresen 2015-07-30 16:41 ` Suhas Daftuar @ 2015-07-30 16:48 ` Adam Back 2015-07-30 16:49 ` Pieter Wuille ` (2 subsequent siblings) 4 siblings, 0 replies; 111+ messages in thread From: Adam Back @ 2015-07-30 16:48 UTC (permalink / raw) To: Gavin Andresen; +Cc: Bitcoin Dev 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 ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Block size following technological growth 2015-07-30 16:20 ` Gavin Andresen 2015-07-30 16:41 ` Suhas Daftuar 2015-07-30 16:48 ` Adam Back @ 2015-07-30 16:49 ` Pieter Wuille 2015-07-31 10:16 ` Mike Hearn 2015-07-30 17:46 ` Jorge Timón 2015-08-02 22:35 ` Anthony Towns 4 siblings, 1 reply; 111+ messages in thread From: Pieter Wuille @ 2015-07-30 16:49 UTC (permalink / raw) To: Gavin Andresen; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Block size following technological growth 2015-07-30 16:49 ` Pieter Wuille @ 2015-07-31 10:16 ` Mike Hearn 2015-07-31 11:43 ` Venzen Khaosan 2015-07-31 11:51 ` Jorge Timón 0 siblings, 2 replies; 111+ messages in thread From: Mike Hearn @ 2015-07-31 10:16 UTC (permalink / raw) To: Pieter Wuille; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Block size following technological growth 2015-07-31 10:16 ` Mike Hearn @ 2015-07-31 11:43 ` Venzen Khaosan 2015-07-31 11:51 ` Jorge Timón 1 sibling, 0 replies; 111+ messages in thread From: Venzen Khaosan @ 2015-07-31 11:43 UTC (permalink / raw) To: Bitcoin Dev -----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----- ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Block size following technological growth 2015-07-31 10:16 ` Mike Hearn 2015-07-31 11:43 ` Venzen Khaosan @ 2015-07-31 11:51 ` Jorge Timón 2015-07-31 12:15 ` Mike Hearn 1 sibling, 1 reply; 111+ messages in thread From: Jorge Timón @ 2015-07-31 11:51 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev 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? ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Block size following technological growth 2015-07-31 11:51 ` Jorge Timón @ 2015-07-31 12:15 ` Mike Hearn 2015-07-31 13:07 ` Marcel Jamin ` (2 more replies) 0 siblings, 3 replies; 111+ messages in thread From: Mike Hearn @ 2015-07-31 12:15 UTC (permalink / raw) To: Jorge Timón; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Block size following technological growth 2015-07-31 12:15 ` Mike Hearn @ 2015-07-31 13:07 ` Marcel Jamin 2015-07-31 14:33 ` Jorge Timón 2015-07-31 14:52 ` [bitcoin-dev] Block size following technological growth Bryan Bishop 2 siblings, 0 replies; 111+ messages in thread From: Marcel Jamin @ 2015-07-31 13:07 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Block size following technological growth 2015-07-31 12:15 ` Mike Hearn 2015-07-31 13:07 ` Marcel Jamin @ 2015-07-31 14:33 ` Jorge Timón 2015-07-31 14:58 ` Mike Hearn 2015-07-31 14:52 ` [bitcoin-dev] Block size following technological growth Bryan Bishop 2 siblings, 1 reply; 111+ messages in thread From: Jorge Timón @ 2015-07-31 14:33 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev 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". ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Block size following technological growth 2015-07-31 14:33 ` Jorge Timón @ 2015-07-31 14:58 ` Mike Hearn 2015-07-31 15:28 ` Venzen Khaosan ` (2 more replies) 0 siblings, 3 replies; 111+ messages in thread From: Mike Hearn @ 2015-07-31 14:58 UTC (permalink / raw) To: Jorge Timón; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Block size following technological growth 2015-07-31 14:58 ` Mike Hearn @ 2015-07-31 15:28 ` Venzen Khaosan 2015-07-31 20:09 ` Elliot Olds 2015-08-04 10:35 ` Jorge Timón 2 siblings, 0 replies; 111+ messages in thread From: Venzen Khaosan @ 2015-07-31 15:28 UTC (permalink / raw) To: Mike Hearn, Bitcoin Dev -----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----- ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Block size following technological growth 2015-07-31 14:58 ` Mike Hearn 2015-07-31 15:28 ` Venzen Khaosan @ 2015-07-31 20:09 ` Elliot Olds 2015-08-04 10:35 ` Jorge Timón 2 siblings, 0 replies; 111+ messages in thread From: Elliot Olds @ 2015-07-31 20:09 UTC (permalink / raw) To: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Block size following technological growth 2015-07-31 14:58 ` Mike Hearn 2015-07-31 15:28 ` Venzen Khaosan 2015-07-31 20:09 ` Elliot Olds @ 2015-08-04 10:35 ` Jorge Timón 2015-08-04 11:04 ` Hector Chu 2 siblings, 1 reply; 111+ messages in thread From: Jorge Timón @ 2015-08-04 10:35 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev 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? ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Block size following technological growth 2015-08-04 10:35 ` Jorge Timón @ 2015-08-04 11:04 ` Hector Chu 2015-08-04 11:27 ` Pieter Wuille ` (2 more replies) 0 siblings, 3 replies; 111+ messages in thread From: Hector Chu @ 2015-08-04 11:04 UTC (permalink / raw) To: Jorge Timón; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Block size following technological growth 2015-08-04 11:04 ` Hector Chu @ 2015-08-04 11:27 ` Pieter Wuille 2015-08-04 11:34 ` Hector Chu 2015-08-04 13:12 ` Gavin Andresen 2015-08-04 11:59 ` Jorge Timón 2015-08-09 18:46 ` [bitcoin-dev] What Lightning Is Tom Harding 2 siblings, 2 replies; 111+ messages in thread From: Pieter Wuille @ 2015-08-04 11:27 UTC (permalink / raw) To: Hector Chu; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Block size following technological growth 2015-08-04 11:27 ` Pieter Wuille @ 2015-08-04 11:34 ` Hector Chu 2015-08-04 12:10 ` Venzen Khaosan 2015-08-04 13:13 ` Jorge Timón 2015-08-04 13:12 ` Gavin Andresen 1 sibling, 2 replies; 111+ messages in thread From: Hector Chu @ 2015-08-04 11:34 UTC (permalink / raw) To: Pieter Wuille; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Block size following technological growth 2015-08-04 11:34 ` Hector Chu @ 2015-08-04 12:10 ` Venzen Khaosan 2015-08-04 13:13 ` Jorge Timón 1 sibling, 0 replies; 111+ messages in thread From: Venzen Khaosan @ 2015-08-04 12:10 UTC (permalink / raw) To: Hector Chu, Bitcoin Dev -----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----- ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Block size following technological growth 2015-08-04 11:34 ` Hector Chu 2015-08-04 12:10 ` Venzen Khaosan @ 2015-08-04 13:13 ` Jorge Timón 2015-08-04 13:28 ` Hector Chu 1 sibling, 1 reply; 111+ messages in thread From: Jorge Timón @ 2015-08-04 13:13 UTC (permalink / raw) To: Hector Chu; +Cc: Bitcoin Dev 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. ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Block size following technological growth 2015-08-04 13:13 ` Jorge Timón @ 2015-08-04 13:28 ` Hector Chu 2015-08-04 13:42 ` Venzen Khaosan 2015-08-04 17:59 ` Jorge Timón 0 siblings, 2 replies; 111+ messages in thread From: Hector Chu @ 2015-08-04 13:28 UTC (permalink / raw) To: Jorge Timón; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Block size following technological growth 2015-08-04 13:28 ` Hector Chu @ 2015-08-04 13:42 ` Venzen Khaosan 2015-08-04 17:59 ` Jorge Timón 1 sibling, 0 replies; 111+ messages in thread From: Venzen Khaosan @ 2015-08-04 13:42 UTC (permalink / raw) To: Hector Chu, Bitcoin Dev -----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----- ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Block size following technological growth 2015-08-04 13:28 ` Hector Chu 2015-08-04 13:42 ` Venzen Khaosan @ 2015-08-04 17:59 ` Jorge Timón 1 sibling, 0 replies; 111+ messages in thread From: Jorge Timón @ 2015-08-04 17:59 UTC (permalink / raw) To: Hector Chu; +Cc: Bitcoin Dev 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? ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Block size following technological growth 2015-08-04 11:27 ` Pieter Wuille 2015-08-04 11:34 ` Hector Chu @ 2015-08-04 13:12 ` Gavin Andresen 2015-08-04 13:54 ` Pieter Wuille ` (3 more replies) 1 sibling, 4 replies; 111+ messages in thread From: Gavin Andresen @ 2015-08-04 13:12 UTC (permalink / raw) To: Pieter Wuille; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Block size following technological growth 2015-08-04 13:12 ` Gavin Andresen @ 2015-08-04 13:54 ` Pieter Wuille 2015-08-04 14:30 ` Venzen Khaosan ` (2 subsequent siblings) 3 siblings, 0 replies; 111+ messages in thread From: Pieter Wuille @ 2015-08-04 13:54 UTC (permalink / raw) To: Gavin Andresen; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Block size following technological growth 2015-08-04 13:12 ` Gavin Andresen 2015-08-04 13:54 ` Pieter Wuille @ 2015-08-04 14:30 ` Venzen Khaosan 2015-08-04 14:43 ` [bitcoin-dev] Fwd: " Venzen Khaosan 2015-08-04 14:45 ` [bitcoin-dev] " Alex Morcos 2015-08-05 8:14 ` Gareth Williams 3 siblings, 1 reply; 111+ messages in thread From: Venzen Khaosan @ 2015-08-04 14:30 UTC (permalink / raw) To: Gavin Andresen, Bitcoin Dev -----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----- ^ permalink raw reply [flat|nested] 111+ messages in thread
* [bitcoin-dev] Fwd: Re: Block size following technological growth 2015-08-04 14:30 ` Venzen Khaosan @ 2015-08-04 14:43 ` Venzen Khaosan 0 siblings, 0 replies; 111+ messages in thread From: Venzen Khaosan @ 2015-08-04 14:43 UTC (permalink / raw) To: Gavin Andresen, Bitcoin Dev -----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----- ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Block size following technological growth 2015-08-04 13:12 ` Gavin Andresen 2015-08-04 13:54 ` Pieter Wuille 2015-08-04 14:30 ` Venzen Khaosan @ 2015-08-04 14:45 ` Alex Morcos 2015-08-05 8:14 ` Gareth Williams 3 siblings, 0 replies; 111+ messages in thread From: Alex Morcos @ 2015-08-04 14:45 UTC (permalink / raw) To: Gavin Andresen; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Block size following technological growth 2015-08-04 13:12 ` Gavin Andresen ` (2 preceding siblings ...) 2015-08-04 14:45 ` [bitcoin-dev] " Alex Morcos @ 2015-08-05 8:14 ` Gareth Williams 3 siblings, 0 replies; 111+ messages in thread From: Gareth Williams @ 2015-08-05 8:14 UTC (permalink / raw) To: Gavin Andresen, Gavin Andresen via bitcoin-dev, Pieter Wuille; +Cc: Bitcoin Dev -----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----- ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Block size following technological growth 2015-08-04 11:04 ` Hector Chu 2015-08-04 11:27 ` Pieter Wuille @ 2015-08-04 11:59 ` Jorge Timón 2015-08-04 12:19 ` Hector Chu 2015-08-05 7:29 ` Elliot Olds 2015-08-09 18:46 ` [bitcoin-dev] What Lightning Is Tom Harding 2 siblings, 2 replies; 111+ messages in thread From: Jorge Timón @ 2015-08-04 11:59 UTC (permalink / raw) To: Hector Chu; +Cc: Bitcoin Dev 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). ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Block size following technological growth 2015-08-04 11:59 ` Jorge Timón @ 2015-08-04 12:19 ` Hector Chu 2015-08-04 13:34 ` Venzen Khaosan 2015-08-04 13:37 ` Jorge Timón 2015-08-05 7:29 ` Elliot Olds 1 sibling, 2 replies; 111+ messages in thread From: Hector Chu @ 2015-08-04 12:19 UTC (permalink / raw) To: Jorge Timón; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Block size following technological growth 2015-08-04 12:19 ` Hector Chu @ 2015-08-04 13:34 ` Venzen Khaosan 2015-08-04 13:37 ` Jorge Timón 1 sibling, 0 replies; 111+ messages in thread From: Venzen Khaosan @ 2015-08-04 13:34 UTC (permalink / raw) To: Bitcoin Dev -----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----- ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Block size following technological growth 2015-08-04 12:19 ` Hector Chu 2015-08-04 13:34 ` Venzen Khaosan @ 2015-08-04 13:37 ` Jorge Timón 1 sibling, 0 replies; 111+ messages in thread From: Jorge Timón @ 2015-08-04 13:37 UTC (permalink / raw) To: Hector Chu; +Cc: Bitcoin Dev 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? ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Block size following technological growth 2015-08-04 11:59 ` Jorge Timón 2015-08-04 12:19 ` Hector Chu @ 2015-08-05 7:29 ` Elliot Olds 2015-08-06 1:26 ` Jorge Timón 1 sibling, 1 reply; 111+ messages in thread From: Elliot Olds @ 2015-08-05 7:29 UTC (permalink / raw) To: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Block size following technological growth 2015-08-05 7:29 ` Elliot Olds @ 2015-08-06 1:26 ` Jorge Timón 2015-08-06 13:40 ` Gavin Andresen 2015-08-06 23:09 ` Elliot Olds 0 siblings, 2 replies; 111+ messages in thread From: Jorge Timón @ 2015-08-06 1:26 UTC (permalink / raw) To: Elliot Olds; +Cc: Bitcoin Dev 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 ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Block size following technological growth 2015-08-06 1:26 ` Jorge Timón @ 2015-08-06 13:40 ` Gavin Andresen 2015-08-06 14:06 ` Pieter Wuille 2015-08-06 15:25 ` Jorge Timón 2015-08-06 23:09 ` Elliot Olds 1 sibling, 2 replies; 111+ messages in thread From: Gavin Andresen @ 2015-08-06 13:40 UTC (permalink / raw) To: Jorge Timón; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Block size following technological growth 2015-08-06 13:40 ` Gavin Andresen @ 2015-08-06 14:06 ` Pieter Wuille 2015-08-06 14:21 ` Gavin Andresen 2015-08-06 15:25 ` Jorge Timón 1 sibling, 1 reply; 111+ messages in thread From: Pieter Wuille @ 2015-08-06 14:06 UTC (permalink / raw) To: Gavin Andresen; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Block size following technological growth 2015-08-06 14:06 ` Pieter Wuille @ 2015-08-06 14:21 ` Gavin Andresen 2015-08-06 14:53 ` Pieter Wuille 2015-08-06 21:56 ` Peter Todd 0 siblings, 2 replies; 111+ messages in thread From: Gavin Andresen @ 2015-08-06 14:21 UTC (permalink / raw) To: Pieter Wuille; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Block size following technological growth 2015-08-06 14:21 ` Gavin Andresen @ 2015-08-06 14:53 ` Pieter Wuille [not found] ` <CABsx9T0B2bZrFHxYR_QNwBmxskQx31zt=QE5BJAYjcOo7wbo3A@mail.gmail.com> 2015-08-06 16:19 ` [bitcoin-dev] " Tom Harding 2015-08-06 21:56 ` Peter Todd 1 sibling, 2 replies; 111+ messages in thread From: Pieter Wuille @ 2015-08-06 14:53 UTC (permalink / raw) To: Gavin Andresen; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 111+ messages in thread
[parent not found: <CABsx9T0B2bZrFHxYR_QNwBmxskQx31zt=QE5BJAYjcOo7wbo3A@mail.gmail.com>]
* [bitcoin-dev] Fwd: Block size following technological growth [not found] ` <CABsx9T0B2bZrFHxYR_QNwBmxskQx31zt=QE5BJAYjcOo7wbo3A@mail.gmail.com> @ 2015-08-06 15:24 ` Gavin Andresen 2015-08-06 15:26 ` Pieter Wuille 0 siblings, 1 reply; 111+ messages in thread From: Gavin Andresen @ 2015-08-06 15:24 UTC (permalink / raw) To: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Fwd: Block size following technological growth 2015-08-06 15:24 ` [bitcoin-dev] Fwd: " Gavin Andresen @ 2015-08-06 15:26 ` Pieter Wuille 2015-08-06 18:43 ` Michael Naber 0 siblings, 1 reply; 111+ messages in thread From: Pieter Wuille @ 2015-08-06 15:26 UTC (permalink / raw) To: Gavin Andresen; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Fwd: Block size following technological growth 2015-08-06 15:26 ` Pieter Wuille @ 2015-08-06 18:43 ` Michael Naber 2015-08-06 18:52 ` Pieter Wuille 0 siblings, 1 reply; 111+ messages in thread From: Michael Naber @ 2015-08-06 18:43 UTC (permalink / raw) To: Pieter Wuille; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Fwd: Block size following technological growth 2015-08-06 18:43 ` Michael Naber @ 2015-08-06 18:52 ` Pieter Wuille 2015-08-07 16:06 ` Thomas Zander 0 siblings, 1 reply; 111+ messages in thread From: Pieter Wuille @ 2015-08-06 18:52 UTC (permalink / raw) To: Michael Naber; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Fwd: Block size following technological growth 2015-08-06 18:52 ` Pieter Wuille @ 2015-08-07 16:06 ` Thomas Zander 2015-08-07 16:30 ` Pieter Wuille 0 siblings, 1 reply; 111+ messages in thread From: Thomas Zander @ 2015-08-07 16:06 UTC (permalink / raw) To: Bitcoin Dev 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 ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Fwd: Block size following technological growth 2015-08-07 16:06 ` Thomas Zander @ 2015-08-07 16:30 ` Pieter Wuille 2015-08-07 17:00 ` Thomas Zander 2015-08-07 17:50 ` Gavin Andresen 0 siblings, 2 replies; 111+ messages in thread From: Pieter Wuille @ 2015-08-07 16:30 UTC (permalink / raw) To: Thomas Zander; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Fwd: Block size following technological growth 2015-08-07 16:30 ` Pieter Wuille @ 2015-08-07 17:00 ` Thomas Zander 2015-08-07 17:09 ` Pieter Wuille 2015-08-07 17:50 ` Gavin Andresen 1 sibling, 1 reply; 111+ messages in thread From: Thomas Zander @ 2015-08-07 17:00 UTC (permalink / raw) To: Bitcoin Dev 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 ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Fwd: Block size following technological growth 2015-08-07 17:00 ` Thomas Zander @ 2015-08-07 17:09 ` Pieter Wuille 2015-08-07 21:35 ` Thomas Zander 0 siblings, 1 reply; 111+ messages in thread From: Pieter Wuille @ 2015-08-07 17:09 UTC (permalink / raw) To: Thomas Zander; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Fwd: Block size following technological growth 2015-08-07 17:09 ` Pieter Wuille @ 2015-08-07 21:35 ` Thomas Zander 2015-08-07 22:53 ` Adam Back 0 siblings, 1 reply; 111+ messages in thread From: Thomas Zander @ 2015-08-07 21:35 UTC (permalink / raw) To: Bitcoin Dev 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 ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Fwd: Block size following technological growth 2015-08-07 21:35 ` Thomas Zander @ 2015-08-07 22:53 ` Adam Back 2015-08-08 16:54 ` Dave Scotese 0 siblings, 1 reply; 111+ messages in thread From: Adam Back @ 2015-08-07 22:53 UTC (permalink / raw) To: Thomas Zander; +Cc: Bitcoin Dev 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 ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Fwd: Block size following technological growth 2015-08-07 22:53 ` Adam Back @ 2015-08-08 16:54 ` Dave Scotese 0 siblings, 0 replies; 111+ messages in thread From: Dave Scotese @ 2015-08-08 16:54 UTC (permalink / raw) To: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Fwd: Block size following technological growth 2015-08-07 16:30 ` Pieter Wuille 2015-08-07 17:00 ` Thomas Zander @ 2015-08-07 17:50 ` Gavin Andresen 2015-08-07 18:05 ` Jameson Lopp 2015-08-07 18:10 ` Pieter Wuille 1 sibling, 2 replies; 111+ messages in thread From: Gavin Andresen @ 2015-08-07 17:50 UTC (permalink / raw) To: Pieter Wuille; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Fwd: Block size following technological growth 2015-08-07 17:50 ` Gavin Andresen @ 2015-08-07 18:05 ` Jameson Lopp 2015-08-07 18:10 ` Pieter Wuille 1 sibling, 0 replies; 111+ messages in thread From: Jameson Lopp @ 2015-08-07 18:05 UTC (permalink / raw) To: Gavin Andresen; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Fwd: Block size following technological growth 2015-08-07 17:50 ` Gavin Andresen 2015-08-07 18:05 ` Jameson Lopp @ 2015-08-07 18:10 ` Pieter Wuille 2015-08-07 21:43 ` Thomas Zander 2015-08-07 22:00 ` Thomas Zander 1 sibling, 2 replies; 111+ messages in thread From: Pieter Wuille @ 2015-08-07 18:10 UTC (permalink / raw) To: Gavin Andresen; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Fwd: Block size following technological growth 2015-08-07 18:10 ` Pieter Wuille @ 2015-08-07 21:43 ` Thomas Zander 2015-08-07 22:00 ` Thomas Zander 1 sibling, 0 replies; 111+ messages in thread From: Thomas Zander @ 2015-08-07 21:43 UTC (permalink / raw) To: Bitcoin Dev 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 ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Fwd: Block size following technological growth 2015-08-07 18:10 ` Pieter Wuille 2015-08-07 21:43 ` Thomas Zander @ 2015-08-07 22:00 ` Thomas Zander 1 sibling, 0 replies; 111+ messages in thread From: Thomas Zander @ 2015-08-07 22:00 UTC (permalink / raw) To: Bitcoin Dev 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 ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Block size following technological growth 2015-08-06 14:53 ` Pieter Wuille [not found] ` <CABsx9T0B2bZrFHxYR_QNwBmxskQx31zt=QE5BJAYjcOo7wbo3A@mail.gmail.com> @ 2015-08-06 16:19 ` Tom Harding 1 sibling, 0 replies; 111+ messages in thread From: Tom Harding @ 2015-08-06 16:19 UTC (permalink / raw) To: bitcoin-dev 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. ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Block size following technological growth 2015-08-06 14:21 ` Gavin Andresen 2015-08-06 14:53 ` Pieter Wuille @ 2015-08-06 21:56 ` Peter Todd 1 sibling, 0 replies; 111+ messages in thread From: Peter Todd @ 2015-08-06 21:56 UTC (permalink / raw) To: Gavin Andresen, Gavin Andresen via bitcoin-dev, Pieter Wuille; +Cc: Bitcoin Dev -----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----- ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Block size following technological growth 2015-08-06 13:40 ` Gavin Andresen 2015-08-06 14:06 ` Pieter Wuille @ 2015-08-06 15:25 ` Jorge Timón 2015-08-06 16:03 ` Gavin Andresen 1 sibling, 1 reply; 111+ messages in thread From: Jorge Timón @ 2015-08-06 15:25 UTC (permalink / raw) To: Gavin Andresen; +Cc: Bitcoin Dev 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. ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Block size following technological growth 2015-08-06 15:25 ` Jorge Timón @ 2015-08-06 16:03 ` Gavin Andresen 2015-08-06 16:11 ` Mike Hearn 2015-08-06 17:15 ` Jorge Timón 0 siblings, 2 replies; 111+ messages in thread From: Gavin Andresen @ 2015-08-06 16:03 UTC (permalink / raw) To: Jorge Timón; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Block size following technological growth 2015-08-06 16:03 ` Gavin Andresen @ 2015-08-06 16:11 ` Mike Hearn 2015-08-06 17:15 ` Jorge Timón 1 sibling, 0 replies; 111+ messages in thread From: Mike Hearn @ 2015-08-06 16:11 UTC (permalink / raw) To: Gavin Andresen; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Block size following technological growth 2015-08-06 16:03 ` Gavin Andresen 2015-08-06 16:11 ` Mike Hearn @ 2015-08-06 17:15 ` Jorge Timón 2015-08-06 19:42 ` Gavin Andresen 1 sibling, 1 reply; 111+ messages in thread From: Jorge Timón @ 2015-08-06 17:15 UTC (permalink / raw) To: Gavin Andresen; +Cc: Bitcoin Dev 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. ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Block size following technological growth 2015-08-06 17:15 ` Jorge Timón @ 2015-08-06 19:42 ` Gavin Andresen 2015-08-06 20:01 ` Pieter Wuille 2015-08-06 21:51 ` Jorge Timón 0 siblings, 2 replies; 111+ messages in thread From: Gavin Andresen @ 2015-08-06 19:42 UTC (permalink / raw) To: Jorge Timón; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Block size following technological growth 2015-08-06 19:42 ` Gavin Andresen @ 2015-08-06 20:01 ` Pieter Wuille 2015-08-06 21:51 ` Jorge Timón 1 sibling, 0 replies; 111+ messages in thread From: Pieter Wuille @ 2015-08-06 20:01 UTC (permalink / raw) To: Gavin Andresen; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Block size following technological growth 2015-08-06 19:42 ` Gavin Andresen 2015-08-06 20:01 ` Pieter Wuille @ 2015-08-06 21:51 ` Jorge Timón 1 sibling, 0 replies; 111+ messages in thread From: Jorge Timón @ 2015-08-06 21:51 UTC (permalink / raw) To: Gavin Andresen; +Cc: Bitcoin Dev 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). ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Block size following technological growth 2015-08-06 1:26 ` Jorge Timón 2015-08-06 13:40 ` Gavin Andresen @ 2015-08-06 23:09 ` Elliot Olds 2015-08-10 19:28 ` Jorge Timón 1 sibling, 1 reply; 111+ messages in thread From: Elliot Olds @ 2015-08-06 23:09 UTC (permalink / raw) To: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Block size following technological growth 2015-08-06 23:09 ` Elliot Olds @ 2015-08-10 19:28 ` Jorge Timón 2015-08-11 5:48 ` Elliot Olds 0 siblings, 1 reply; 111+ messages in thread From: Jorge Timón @ 2015-08-10 19:28 UTC (permalink / raw) To: Elliot Olds; +Cc: Bitcoin Dev 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. ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Block size following technological growth 2015-08-10 19:28 ` Jorge Timón @ 2015-08-11 5:48 ` Elliot Olds 0 siblings, 0 replies; 111+ messages in thread From: Elliot Olds @ 2015-08-11 5:48 UTC (permalink / raw) To: Bitcoin Dev; +Cc: timon [-- 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 --] ^ permalink raw reply [flat|nested] 111+ messages in thread
* [bitcoin-dev] What Lightning Is 2015-08-04 11:04 ` Hector Chu 2015-08-04 11:27 ` Pieter Wuille 2015-08-04 11:59 ` Jorge Timón @ 2015-08-09 18:46 ` Tom Harding 2015-08-09 18:54 ` Mark Friedenbach 2 siblings, 1 reply; 111+ messages in thread From: Tom Harding @ 2015-08-09 18:46 UTC (permalink / raw) To: Bitcoin Dev 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. ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] What Lightning Is 2015-08-09 18:46 ` [bitcoin-dev] What Lightning Is Tom Harding @ 2015-08-09 18:54 ` Mark Friedenbach 2015-08-09 20:14 ` Hector Chu 2015-08-09 21:27 ` Tom Harding 0 siblings, 2 replies; 111+ messages in thread From: Mark Friedenbach @ 2015-08-09 18:54 UTC (permalink / raw) To: Tom Harding; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] What Lightning Is 2015-08-09 18:54 ` Mark Friedenbach @ 2015-08-09 20:14 ` Hector Chu [not found] ` <CAOG=w-s9KsaPwveSpgdvsVTWUDV77YY7Em7NZGyxSQMMCccYSg@mail.gmail.com> 2015-08-10 17:03 ` odinn 2015-08-09 21:27 ` Tom Harding 1 sibling, 2 replies; 111+ messages in thread From: Hector Chu @ 2015-08-09 20:14 UTC (permalink / raw) To: Mark Friedenbach; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 111+ messages in thread
[parent not found: <CAOG=w-s9KsaPwveSpgdvsVTWUDV77YY7Em7NZGyxSQMMCccYSg@mail.gmail.com>]
* Re: [bitcoin-dev] What Lightning Is [not found] ` <CAOG=w-s9KsaPwveSpgdvsVTWUDV77YY7Em7NZGyxSQMMCccYSg@mail.gmail.com> @ 2015-08-09 20:48 ` Hector Chu 2015-08-10 4:48 ` Joseph Poon 0 siblings, 1 reply; 111+ messages in thread From: Hector Chu @ 2015-08-09 20:48 UTC (permalink / raw) To: Mark Friedenbach; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] What Lightning Is 2015-08-09 20:48 ` Hector Chu @ 2015-08-10 4:48 ` Joseph Poon 0 siblings, 0 replies; 111+ messages in thread From: Joseph Poon @ 2015-08-10 4:48 UTC (permalink / raw) To: Hector Chu; +Cc: Bitcoin Dev 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 ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] What Lightning Is 2015-08-09 20:14 ` Hector Chu [not found] ` <CAOG=w-s9KsaPwveSpgdvsVTWUDV77YY7Em7NZGyxSQMMCccYSg@mail.gmail.com> @ 2015-08-10 17:03 ` odinn 2015-08-10 17:14 ` Pieter Wuille 1 sibling, 1 reply; 111+ messages in thread From: odinn @ 2015-08-10 17:03 UTC (permalink / raw) To: Hector Chu, Mark Friedenbach; +Cc: Bitcoin Dev -----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----- ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] What Lightning Is 2015-08-10 17:03 ` odinn @ 2015-08-10 17:14 ` Pieter Wuille 2015-08-10 17:45 ` odinn 0 siblings, 1 reply; 111+ messages in thread From: Pieter Wuille @ 2015-08-10 17:14 UTC (permalink / raw) To: Colin Gallagher; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] What Lightning Is 2015-08-10 17:14 ` Pieter Wuille @ 2015-08-10 17:45 ` odinn 0 siblings, 0 replies; 111+ messages in thread From: odinn @ 2015-08-10 17:45 UTC (permalink / raw) To: Pieter Wuille; +Cc: Bitcoin Dev -----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----- ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] What Lightning Is 2015-08-09 18:54 ` Mark Friedenbach 2015-08-09 20:14 ` Hector Chu @ 2015-08-09 21:27 ` Tom Harding 2015-08-09 21:40 ` Chris Pacia ` (2 more replies) 1 sibling, 3 replies; 111+ messages in thread From: Tom Harding @ 2015-08-09 21:27 UTC (permalink / raw) To: Mark Friedenbach; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] What Lightning Is 2015-08-09 21:27 ` Tom Harding @ 2015-08-09 21:40 ` Chris Pacia 2015-08-09 21:45 ` Hector Chu 2015-08-09 22:06 ` Patrick Strateman 2 siblings, 0 replies; 111+ messages in thread From: Chris Pacia @ 2015-08-09 21:40 UTC (permalink / raw) To: Tom Harding; +Cc: bitcoin-dev [-- 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 --] ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] What Lightning Is 2015-08-09 21:27 ` Tom Harding 2015-08-09 21:40 ` Chris Pacia @ 2015-08-09 21:45 ` Hector Chu 2015-08-09 21:57 ` Patrick Strateman 2015-08-10 1:52 ` Tom Harding 2015-08-09 22:06 ` Patrick Strateman 2 siblings, 2 replies; 111+ messages in thread From: Hector Chu @ 2015-08-09 21:45 UTC (permalink / raw) To: Tom Harding; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] What Lightning Is 2015-08-09 21:45 ` Hector Chu @ 2015-08-09 21:57 ` Patrick Strateman 2015-08-09 22:03 ` Hector Chu 2015-08-10 1:52 ` Tom Harding 1 sibling, 1 reply; 111+ messages in thread From: Patrick Strateman @ 2015-08-09 21:57 UTC (permalink / raw) To: bitcoin-dev [-- 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 --] ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] What Lightning Is 2015-08-09 21:57 ` Patrick Strateman @ 2015-08-09 22:03 ` Hector Chu 2015-08-09 22:36 ` Patrick Strateman 0 siblings, 1 reply; 111+ messages in thread From: Hector Chu @ 2015-08-09 22:03 UTC (permalink / raw) To: Patrick Strateman; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] What Lightning Is 2015-08-09 22:03 ` Hector Chu @ 2015-08-09 22:36 ` Patrick Strateman 0 siblings, 0 replies; 111+ messages in thread From: Patrick Strateman @ 2015-08-09 22:36 UTC (permalink / raw) To: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] What Lightning Is 2015-08-09 21:45 ` Hector Chu 2015-08-09 21:57 ` Patrick Strateman @ 2015-08-10 1:52 ` Tom Harding 2015-08-10 3:31 ` Patrick Strateman 1 sibling, 1 reply; 111+ messages in thread From: Tom Harding @ 2015-08-10 1:52 UTC (permalink / raw) To: Bitcoin Dev 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. ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] What Lightning Is 2015-08-10 1:52 ` Tom Harding @ 2015-08-10 3:31 ` Patrick Strateman 0 siblings, 0 replies; 111+ messages in thread From: Patrick Strateman @ 2015-08-10 3:31 UTC (permalink / raw) To: bitcoin-dev > 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 > ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] What Lightning Is 2015-08-09 21:27 ` Tom Harding 2015-08-09 21:40 ` Chris Pacia 2015-08-09 21:45 ` Hector Chu @ 2015-08-09 22:06 ` Patrick Strateman 2015-08-09 22:09 ` Hector Chu 2 siblings, 1 reply; 111+ messages in thread From: Patrick Strateman @ 2015-08-09 22:06 UTC (permalink / raw) To: bitcoin-dev [-- 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 --] ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] What Lightning Is 2015-08-09 22:06 ` Patrick Strateman @ 2015-08-09 22:09 ` Hector Chu 2015-08-09 22:27 ` Patrick Strateman 2015-08-09 22:44 ` Gavin Andresen 0 siblings, 2 replies; 111+ messages in thread From: Hector Chu @ 2015-08-09 22:09 UTC (permalink / raw) To: Patrick Strateman; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] What Lightning Is 2015-08-09 22:09 ` Hector Chu @ 2015-08-09 22:27 ` Patrick Strateman 2015-08-09 22:30 ` Hector Chu 2015-08-09 22:44 ` Gavin Andresen 1 sibling, 1 reply; 111+ messages in thread From: Patrick Strateman @ 2015-08-09 22:27 UTC (permalink / raw) To: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] What Lightning Is 2015-08-09 22:27 ` Patrick Strateman @ 2015-08-09 22:30 ` Hector Chu 0 siblings, 0 replies; 111+ messages in thread From: Hector Chu @ 2015-08-09 22:30 UTC (permalink / raw) To: Patrick Strateman; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] What Lightning Is 2015-08-09 22:09 ` Hector Chu 2015-08-09 22:27 ` Patrick Strateman @ 2015-08-09 22:44 ` Gavin Andresen 2015-08-09 22:51 ` Btc Drak ` (2 more replies) 1 sibling, 3 replies; 111+ messages in thread From: Gavin Andresen @ 2015-08-09 22:44 UTC (permalink / raw) To: Hector Chu; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] What Lightning Is 2015-08-09 22:44 ` Gavin Andresen @ 2015-08-09 22:51 ` Btc Drak 2015-08-10 8:27 ` Thomas Zander 2015-08-10 4:39 ` Joseph Poon 2015-08-10 21:02 ` Anthony Towns 2 siblings, 1 reply; 111+ messages in thread From: Btc Drak @ 2015-08-09 22:51 UTC (permalink / raw) To: Gavin Andresen; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] What Lightning Is 2015-08-09 22:51 ` Btc Drak @ 2015-08-10 8:27 ` Thomas Zander 2015-08-10 8:36 ` Patrick Strateman 0 siblings, 1 reply; 111+ messages in thread From: Thomas Zander @ 2015-08-10 8:27 UTC (permalink / raw) To: Bitcoin Dev 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 ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] What Lightning Is 2015-08-10 8:27 ` Thomas Zander @ 2015-08-10 8:36 ` Patrick Strateman 0 siblings, 0 replies; 111+ messages in thread From: Patrick Strateman @ 2015-08-10 8:36 UTC (permalink / raw) To: bitcoin-dev 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). ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] What Lightning Is 2015-08-09 22:44 ` Gavin Andresen 2015-08-09 22:51 ` Btc Drak @ 2015-08-10 4:39 ` Joseph Poon 2015-08-10 21:02 ` Anthony Towns 2 siblings, 0 replies; 111+ messages in thread From: Joseph Poon @ 2015-08-10 4:39 UTC (permalink / raw) To: Gavin Andresen; +Cc: Bitcoin Dev 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 ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] What Lightning Is 2015-08-09 22:44 ` Gavin Andresen 2015-08-09 22:51 ` Btc Drak 2015-08-10 4:39 ` Joseph Poon @ 2015-08-10 21:02 ` Anthony Towns 2015-08-10 21:19 ` Anthony Towns 2 siblings, 1 reply; 111+ messages in thread From: Anthony Towns @ 2015-08-10 21:02 UTC (permalink / raw) To: Gavin Andresen; +Cc: Bitcoin Dev 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 ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] What Lightning Is 2015-08-10 21:02 ` Anthony Towns @ 2015-08-10 21:19 ` Anthony Towns 2015-08-10 21:43 ` Adam Back 0 siblings, 1 reply; 111+ messages in thread From: Anthony Towns @ 2015-08-10 21:19 UTC (permalink / raw) To: Gavin Andresen; +Cc: Bitcoin Dev 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 ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] What Lightning Is 2015-08-10 21:19 ` Anthony Towns @ 2015-08-10 21:43 ` Adam Back 2015-08-11 9:01 ` Hector Chu 0 siblings, 1 reply; 111+ messages in thread From: Adam Back @ 2015-08-10 21:43 UTC (permalink / raw) To: Anthony Towns; +Cc: Bitcoin Dev 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 ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] What Lightning Is 2015-08-10 21:43 ` Adam Back @ 2015-08-11 9:01 ` Hector Chu 2015-08-11 17:17 ` Simon Liu 0 siblings, 1 reply; 111+ messages in thread From: Hector Chu @ 2015-08-11 9:01 UTC (permalink / raw) To: Adam Back; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] What Lightning Is 2015-08-11 9:01 ` Hector Chu @ 2015-08-11 17:17 ` Simon Liu 0 siblings, 0 replies; 111+ messages in thread From: Simon Liu @ 2015-08-11 17:17 UTC (permalink / raw) To: Hector Chu, Adam Back; +Cc: Bitcoin Dev 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 > ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Block size following technological growth 2015-07-31 12:15 ` Mike Hearn 2015-07-31 13:07 ` Marcel Jamin 2015-07-31 14:33 ` Jorge Timón @ 2015-07-31 14:52 ` Bryan Bishop 2 siblings, 0 replies; 111+ messages in thread From: Bryan Bishop @ 2015-07-31 14:52 UTC (permalink / raw) To: Mike Hearn, Bryan Bishop; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Block size following technological growth 2015-07-30 16:20 ` Gavin Andresen ` (2 preceding siblings ...) 2015-07-30 16:49 ` Pieter Wuille @ 2015-07-30 17:46 ` Jorge Timón 2015-08-02 22:35 ` Anthony Towns 4 siblings, 0 replies; 111+ messages in thread From: Jorge Timón @ 2015-07-30 17:46 UTC (permalink / raw) To: Gavin Andresen; +Cc: Bitcoin Dev 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. ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Block size following technological growth 2015-07-30 16:20 ` Gavin Andresen ` (3 preceding siblings ...) 2015-07-30 17:46 ` Jorge Timón @ 2015-08-02 22:35 ` Anthony Towns 4 siblings, 0 replies; 111+ messages in thread From: Anthony Towns @ 2015-08-02 22:35 UTC (permalink / raw) To: Gavin Andresen, bitcoin-dev 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 ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [bitcoin-dev] Block size following technological growth 2015-07-30 14:25 [bitcoin-dev] Block size following technological growth Pieter Wuille ` (2 preceding siblings ...) 2015-07-30 16:20 ` Gavin Andresen @ 2015-07-30 20:20 ` Thomas Zander 3 siblings, 0 replies; 111+ messages in thread From: Thomas Zander @ 2015-07-30 20:20 UTC (permalink / raw) To: bitcoin-dev, Pieter Wuille 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 ^ permalink raw reply [flat|nested] 111+ messages in thread
end of thread, other threads:[~2015-08-11 17:18 UTC | newest]
Thread overview: 111+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-07-30 14:25 [bitcoin-dev] Block size following technological growth Pieter Wuille
2015-07-30 15:04 ` Greg Sanders
2015-07-30 15:12 ` Jorge Timón
2015-07-30 16:23 ` Jameson Lopp
2015-07-30 16:36 ` Bryan Bishop
2015-07-30 16:43 ` Jameson Lopp
2015-07-30 16:36 ` Venzen Khaosan
2015-07-30 17:51 ` Jorge Timón
2015-07-30 18:00 ` Jorge Timón
2015-07-30 16:56 ` Gary Mulder
2015-07-30 17:13 ` Mark Friedenbach
2015-07-30 16:20 ` Gavin Andresen
2015-07-30 16:41 ` Suhas Daftuar
2015-07-30 16:48 ` Adam Back
2015-07-30 16:49 ` Pieter Wuille
2015-07-31 10:16 ` Mike Hearn
2015-07-31 11:43 ` Venzen Khaosan
2015-07-31 11:51 ` Jorge Timón
2015-07-31 12:15 ` Mike Hearn
2015-07-31 13:07 ` Marcel Jamin
2015-07-31 14:33 ` Jorge Timón
2015-07-31 14:58 ` Mike Hearn
2015-07-31 15:28 ` Venzen Khaosan
2015-07-31 20:09 ` Elliot Olds
2015-08-04 10:35 ` Jorge Timón
2015-08-04 11:04 ` Hector Chu
2015-08-04 11:27 ` Pieter Wuille
2015-08-04 11:34 ` Hector Chu
2015-08-04 12:10 ` Venzen Khaosan
2015-08-04 13:13 ` Jorge Timón
2015-08-04 13:28 ` Hector Chu
2015-08-04 13:42 ` Venzen Khaosan
2015-08-04 17:59 ` Jorge Timón
2015-08-04 13:12 ` Gavin Andresen
2015-08-04 13:54 ` Pieter Wuille
2015-08-04 14:30 ` Venzen Khaosan
2015-08-04 14:43 ` [bitcoin-dev] Fwd: " Venzen Khaosan
2015-08-04 14:45 ` [bitcoin-dev] " Alex Morcos
2015-08-05 8:14 ` Gareth Williams
2015-08-04 11:59 ` Jorge Timón
2015-08-04 12:19 ` Hector Chu
2015-08-04 13:34 ` Venzen Khaosan
2015-08-04 13:37 ` Jorge Timón
2015-08-05 7:29 ` Elliot Olds
2015-08-06 1:26 ` Jorge Timón
2015-08-06 13:40 ` Gavin Andresen
2015-08-06 14:06 ` Pieter Wuille
2015-08-06 14:21 ` Gavin Andresen
2015-08-06 14:53 ` Pieter Wuille
[not found] ` <CABsx9T0B2bZrFHxYR_QNwBmxskQx31zt=QE5BJAYjcOo7wbo3A@mail.gmail.com>
2015-08-06 15:24 ` [bitcoin-dev] Fwd: " Gavin Andresen
2015-08-06 15:26 ` Pieter Wuille
2015-08-06 18:43 ` Michael Naber
2015-08-06 18:52 ` Pieter Wuille
2015-08-07 16:06 ` Thomas Zander
2015-08-07 16:30 ` Pieter Wuille
2015-08-07 17:00 ` Thomas Zander
2015-08-07 17:09 ` Pieter Wuille
2015-08-07 21:35 ` Thomas Zander
2015-08-07 22:53 ` Adam Back
2015-08-08 16:54 ` Dave Scotese
2015-08-07 17:50 ` Gavin Andresen
2015-08-07 18:05 ` Jameson Lopp
2015-08-07 18:10 ` Pieter Wuille
2015-08-07 21:43 ` Thomas Zander
2015-08-07 22:00 ` Thomas Zander
2015-08-06 16:19 ` [bitcoin-dev] " Tom Harding
2015-08-06 21:56 ` Peter Todd
2015-08-06 15:25 ` Jorge Timón
2015-08-06 16:03 ` Gavin Andresen
2015-08-06 16:11 ` Mike Hearn
2015-08-06 17:15 ` Jorge Timón
2015-08-06 19:42 ` Gavin Andresen
2015-08-06 20:01 ` Pieter Wuille
2015-08-06 21:51 ` Jorge Timón
2015-08-06 23:09 ` Elliot Olds
2015-08-10 19:28 ` Jorge Timón
2015-08-11 5:48 ` Elliot Olds
2015-08-09 18:46 ` [bitcoin-dev] What Lightning Is Tom Harding
2015-08-09 18:54 ` Mark Friedenbach
2015-08-09 20:14 ` Hector Chu
[not found] ` <CAOG=w-s9KsaPwveSpgdvsVTWUDV77YY7Em7NZGyxSQMMCccYSg@mail.gmail.com>
2015-08-09 20:48 ` Hector Chu
2015-08-10 4:48 ` Joseph Poon
2015-08-10 17:03 ` odinn
2015-08-10 17:14 ` Pieter Wuille
2015-08-10 17:45 ` odinn
2015-08-09 21:27 ` Tom Harding
2015-08-09 21:40 ` Chris Pacia
2015-08-09 21:45 ` Hector Chu
2015-08-09 21:57 ` Patrick Strateman
2015-08-09 22:03 ` Hector Chu
2015-08-09 22:36 ` Patrick Strateman
2015-08-10 1:52 ` Tom Harding
2015-08-10 3:31 ` Patrick Strateman
2015-08-09 22:06 ` Patrick Strateman
2015-08-09 22:09 ` Hector Chu
2015-08-09 22:27 ` Patrick Strateman
2015-08-09 22:30 ` Hector Chu
2015-08-09 22:44 ` Gavin Andresen
2015-08-09 22:51 ` Btc Drak
2015-08-10 8:27 ` Thomas Zander
2015-08-10 8:36 ` Patrick Strateman
2015-08-10 4:39 ` Joseph Poon
2015-08-10 21:02 ` Anthony Towns
2015-08-10 21:19 ` Anthony Towns
2015-08-10 21:43 ` Adam Back
2015-08-11 9:01 ` Hector Chu
2015-08-11 17:17 ` Simon Liu
2015-07-31 14:52 ` [bitcoin-dev] Block size following technological growth Bryan Bishop
2015-07-30 17:46 ` Jorge Timón
2015-08-02 22:35 ` Anthony Towns
2015-07-30 20:20 ` Thomas Zander
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox