On Thu, Jul 30, 2015 at 2:29 PM, Gavin via bitcoin-dev <[email protected]> wrote: > I would like (and have been asking) those people to take the time to quantify > those costs and write up those risks in a careful way.
I agree that having a "minimal hardware requirements" specification would greatly help with this discussions. > I believe the costs and risks of 8MB blocks are minimal, and that the > benefits of supporting more transaction FAR outweigh those costs and risks, > but it is hard to have a rational conversation about that when even simple > questions like 'what is s reasonable cost to run a full node' are met with > silence. These tests by Rusty (strong advocate of IBLT and working on it) seem to indicate otherwise: http://rusty.ozlabs.org/?p=509 On Thu, Jul 30, 2015 at 2:50 PM, Pieter Wuille via bitcoin-dev <[email protected]> wrote: > I think the risks of trying to make a controversial change to the network > FAR outweighs the benefits of a small constant factor that "kicks the can > down the road". I think the risks of a controversial deployment in consensus rules changes, outweigh by far potential benefits of ANY consensus forks, no matter how amazing the potential benefits may seem. Bitcoin may not survive a controversial hardfork or go 3 years back in adoption, nobody knows. > Let's scale the block size gradually over time, according to technological > growth. I agree. Unfortunately, technological and economic growth is very hard to predict. On Thu, Jul 30, 2015 at 3:33 PM, Venzen Khaosan <[email protected]> wrote: > 2. Bitcoin is much more than a payment network. A lot of the > non-payment features are, arguably, what gives Bitcoin most of its > value. Yet, the payment functionality is a major design feature and > all agree that it should scale - subject to axiom 1. I just explained why I disagree with this point. Bitcoin fees depend on transaction sizes rather than amounts moved. Even ignoring script-based signatures and all the other advantages in Bitcoin, that fact alone makes it extremely competitive with "traditional systems" for many use cases (say, sending 1000 usd from the US to México). I agree overall with your other points. Extremely cheap and instant transactions can be provided by lightning, but cannot be provided by Bitcoin in-chain alone in the long term (it can't even provide instant irreversible transactions). > Since I've maintained your interest up to the final sentence, I say: > as an insurance against a capacity crisis before layer 2 is deployed, > why not implement bip100's 2MB blocksize proposals in a testnet? Of all blocksize proposals, bip102 (the one with the single doubling to 2MB) is the one I dislike less because it doesn't make any assumptions about future technological or economic growth (I loved your Bohr cite). But it still has something that I dislike from all proposals: the numbers just seem pulled out of a hat. But I already created that testnet you propose (and std::numeric_limits<uint64_t>::max() -1 more testnets for other sizes) in https://github.com/bitcoin/bitcoin/pull/6382 You can run it with the following runtime options: -chain=sizetest -blocksize=2000000 Unfortunately, nobody seems interested in running some tests for several sizes before proposing a concrete size. As far as I know, nobody has used that branch to test different sizes. _______________________________________________ bitcoin-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
