So your only focus is on full nodes. So where's the research of how expensive nodes are and how many nodes would be lost if an upgrade to 2MB would happen? How big of a loss would be acceptable? Ideally how many nodes should exist in the network for it to be sufficiently decentralized? How much bandwidth is needed? How long can we expect our storage to last?

There is no credible research done, there are no numbers, yet even the smallest size increase is blocked.

It's also blocked by the same people who have previously supported even larger increases. What made them change their minds? Sure isn't any new research.

But the fundamental issue is that not everyone need to run a full node as long as you can connect to sufficiently many nodes yourself. There's simply no point in engaging in full node fetishism where everyone need to run one where the worst internet connection hamstrings the entire network. Most people run SPV wallets today anyway and the important nodes are the ones run by businesses and wallet services.

> So where's the research of how expensive nodes are and how many nodes would be lost if an upgrade to 2MB would happen? How big of a loss would be acceptable? Ideally how many nodes should exist in the network for it to be sufficiently decentralized? How much bandwidth is needed? How long can we expect our storage to last?

> There is no credible research done

That's precisely my point. Contributors have shown that full nodes are necessary to preserve the security of the network (see the links I posted), but the proposal of S2X was executed without ever engaging on a discussion to answer the very questions you are asking now.

They are good questions, and we should discuss them and we should answer them. But Jeff Garzik and the 5 other CEOs did not attempt to do this research and instead steamrolled ahead with btc1/s2x.

The damage the 1MB limit has done and is doing to Bitcoin is far more than possibly a couple of lost nodes would mean after an upgrade to 2MB.

This has been a problem for years. For example Gavin thought 16MB would be perfectly safe. There's research being done now examining 1GB blocks and how that would affect propagation time. A lousy 2MB is honestly laughable.

Doing nothing isn't the pragmatic or sane approach, it's the insane one.

In one post your criticism is that there is a lack of research, and I agree. But now you're making unsubstantiated claims again... the damage done to bitcoin? All meaningful metrics from BitPay's transaction volume [0] to on chain USD volume [1] to the price [2] shows that Bitcoin is doing fine and does not need saving. Public data shows that even though a fee market is developing, Bitcoin is still rising quickly in use and value.

As for the 1GB block research you're talking about, it was literally presented 5 days ago. S2X proposal started in May and the fork was planned for next week. The way we want this secure digital money thing to work is that proposals that are controversial or that may affect security are researched and the research is reviewed over many months or years.

I know you want to take the quick approach and just LOWER FEES NOW, but we know -- from experience -- that a cowboy attitude with blockchains makes it trivial to lose a lot of money [3].

[0] https://blog.bitpay.com/bitpay-growth-2017/

[1] https://blockchain.info/charts/estimated-transaction-volume-...

[2] https://coinmarketcap.com/currencies/bitcoin/#charts

[3] https://www.cnbc.com/2017/11/08/accidental-bug-may-have-froz...

> But now you're making unsubstantiated claims again... the damage done to bitcoin?

How about comparing Bitcoin's percentage of total market capitalization [0] which crashed from ~80% down to ~40% when the blocks became full? The last month has regained that quite a bit but you could speculate it's because the promise of long overdue on chain capacity increase.

> I know you want to take the quick approach and just LOWER FEES NOW

It's been years since the limit should have been increased. Yet here we are with no on chain scaling for Bitcoin even remotely close to reality.

> that a cowboy attitude with blockchains makes it trivial to lose a lot of money

You're really comparing apples and oranges if you compare raising the block size with Ethereum's poorly designed smart contracts.

[0] https://coinmarketcap.com/charts/

That there is no credible research done should be an argument against untested proposals for change, not against status quo.

It is overwhelmingly clear that cryptocurrencies in general is in an early phase and that more research is needed on the subject. Especially since it seems like we'll be running these systems on an even larger scale in the future. It does however seem like more energy is spent spreading soundbites on Twitter than anything that has even a vague resemblance to the scientific method.

Full blocks is a change to how Bitcoin has been run. The limit was always meant to be raised as it was introduced as a spam protection. The full blocks policy has not had any research backing it at all.

No, it's really not. It was there from the beginning. Satoshi himself put it in place, years before blocks got even close to that size. When other people wanted to lift the limit he argued against it. He clearly did not deem it important enough to even research what limit was appropriate.

There's also the fact that Satoshi put a pretty agreesive schedule for the deflationary aspect of Bitcoin. Fees were designed to gradually take over as the miner's reward. You and I may or may not agree with that policy, or the schedule it follows, but it is a policy that was designed in from the beginning.

You're confusing the limit with full blocks. For all good it did the limit could just as well not have existed since blocks never reached it.

Furthermore Bitcoin used a soft limit which miners themselves increased. This is now no longer possible.

Satoshi introduced the limit as spam protection and he also explained how it could be phased in using a hard fork (although the term was coined at a later date).

I quote:

It can be phased in, like:

if (blocknumber > 115000) maxblocksize = largerlimit

It can start being in versions way ahead, so by the time it reaches that block number and goes into effect, the older versions that don't have it are already obsolete.

When we're near the cutoff block number, I can put an alert to old versions to make sure they know they have to upgrade.