Topic: BIP 100 and BIP 101 = i like both... (Read 3374 times)

They've recently signed a document showing support for BIP101. However, Bitpay explicitly stated that they want BIP101 in Core.

If the miners happen to agree on a single BIP, I'm sure that the 'industry' will quickly follow.

Thats great. Lets end this useless dispute for now. If majority agrees upon BIP 100 for now, then we can focus on creating and implementing future changes without all this hot fuss.
And then bitcoin can be the rescue tool for approaching economic crisis, because as of now it seems that bitcoin is sinking because internal war and stock exchanges collapse.

Anybody know what massive bitcoin service providers like Bitpay & blockchain.info are set to support & who they side with Core devs or XT?

On one hand, there must be a hard limit approximating network's technical ability to consistently converge on a single chain, on the other hand, it would seem appropriate for miners to decide on the current soft limit.

Miners manipulating the soft limit should present no danger to the network's ability to operate. However, touching the hard limit without the overwhelming consensus of all full nodes must be prohibited. The hard limit also defines the potential size of the network, thus (mis-)placing it way above current technical capabilities of the average home connection will significantly reduce the amount of nodes participating in consensus (if limit is reached prematurely).

I'm uncertain that 32Mb limit is safe enough to not create significant turbulence in the network's operation, if reached within the next 2-4 years. We are not necessarily talking about Chinese miners here as those are bandwidth limited already, but rather about potential rogue miners that might be interested in taking advantage of the situation.

If you're concerned about miners' ability to manipulate the soft limit, you should advocate for lower static hard limit to counter that, but instead you seem to be disappointed by its re-introduction in BIP100, which sounds contradictory. Please clarify.

I'm not really sure how easy this would be to manipulate.

From the proposal:
- Limit increase or decrease may not exceed 2x in any one step.
- Miners vote by encoding ‘BV’+BlockSizeRequestValue into coinbase scriptSig, e.g. “/BV8000000/” to vote for 8M. Votes are evaluated by dropping bottom 20% and top 20%, and then the most common floor (minimum) is chosen.

From what I understand it's the pools, not the miners themselves, which will be doing the voting upon block submissions.  The highest pool right now I think only has about 25% of the total hashrate (f2pool at ~70PH, right?)

You would need to own 80% of the hashrate to vote for a change.  Right now I know of no one who could bring online another 300PH of mining power, I think it's fairly impossible to do something like that.

And, even if you could, you could raise or lower it no more than 2x the current rate, once every 83 days.  Starting at 1MB today, you could conceivably get it to 16MB block sizing by the beginning of August 2016.  I hardly call that any area for concern which couldn't be rooted out well before then.

I'm sorry to say, but I'm not wrong.  I run large infrastructure for a living, and I know very well the difference between what is stated capability, and what will actually be achievable.  I can assure you that the number they state (56k) is a theoretical limit based upon extrapolation of numbers from baseline stress testing done in a staging environment.  If you research how they did their stress testing, it was not on their own equipment, but done in a third-party facility with a replicated environment that is not a full-on replica.  It's also all low-latency local networking within a datacenter facility, not higher latency interconnected fiber which is subject to routing and other issues when you are communicating between datacenters.

So, yes, it's a theoretical limit.  It may be a fairly accurate limit (chances are it's not), but it's still theoretical as their network has never pushed that many transactions in real life.  They've only ever hit 1/4 of that in a real live peak situation.

In case BIP100 gains enough momentum and wins the race,
I would put its proclaimed static 32Mb limit in place of the current 1Mb cap explicitly (to be extra sure) instead of relying on some legacy network message limitations which may no longer fully apply to current (and future) block propagation mechanisms (blocks split across multiple messages, etc).

If that can be guaranteed to be implemented reliably, I would likely support BIP100 without much further hesitation, though I haven't studied it with enough scrutiny to know for certain that there aren't any holes there.

This white paper is over 5 years old can we stop quoting it like it's actually relevant to the reality and new technical challenges we've observed over the years?

Sorry, but this is wrong again. It's not their theoretical limit, but an actual limit as they've conducted tests. This limit has been growing over the years as they've been improving their technology.
The 7tps limit is just a old myth and was debunked (a good explanation can be found in that thread that I've linked).

I don't think that there will be one, at least not one on a scale as this one. BIP100 gives enough time for other solutions to come after which we will not be limited/relying solely on the block size limit.
Looks like support for BIP100 is growing as pools have started to switch from 8MB. If a few more switch it is very likely that we will proceed with BIP100.

---

---

I'll just make an update here:
Okay, I agree. However, we can't put it in the same bag as the '7 tps myth'. I would also like to correct you that they reach(ed) 1/3 (so, not 1/4) of that theoretical maximum during peak times.

True, that is why I also support BIP100

Indeed, but do we really want this debate again in 2-5 years though? Not me.

I would pay more attention to this before jumping to any conclusions too fast.
If the code to implement BIP100 is complex enough there is a chance of a slip up somewhere and the whole thing might go belly up.

The hard limit is important because it greatly reduces the incentive for rogue entities to start piling up the hashpower in order to manipulate the block size and push the majority of the full nodes out of capacity to operate and validate the blockchain. Just having a reliable hard limit has a psychological effect to not bother attacking, because the network cannot be destroyed through this mechanism alone (provided it is capable of operating at near full capacity).

Whether 32Mb is a good enough limit to prevent abuse by (potential rogue) miners for the next few years is debatable (8Mb seems safer). We must make absolutely certain, that the 32Mb cap still holds (it may not be true in more recent implementations as blocks can occupy more than one network message of 32Mb) before expressing full support for BIP100.


The 8Mb option is still holding up nicely. It might be more appealing to those who don't want to change Bitcoin too much.
Bitcoin with high enough hard limit and gradually increasing soft limits is the one we're all used to and the one that is proven to work.
The 8Mb option provides just that, only the numbers are different (hard cap: 8Mb, soft caps can be: 2Mb, 4Mb, 6Mb).

Run this for the next four years, collect the data, evaluate the number of full nodes, reach consensus on how to move forward, celebrate the halving, be happy! That's the recipe for success right there.

Ok, so thankfully that was explained in the first couple paragraphs, otherwise there's no way I'm reading a full 22-page thread right now.  I'll stand corrected on the actual speed.
I spent a whole 5 minutes on mine as well, but at least I'm not being an uppity snot about it.   

I stand by my word "surpass".  If you actually read the context of the sentence I mention their real daily transaction volume, not what their network is capable of.  If we exceed their number of average daily transactions, then we have surpassed their actual daily volume.  Our 7Tps theoretical limit is the same as their 56k Tps theoretical limit, although in practice they are not coming anywhere near that high number, nor are we coming close to ours.

Furthermore, since Visa's is a closed network it is not comparable to the Bitcoin network.  They need to have that high of a total capable Tps because each processing server they have is critical to that number.  If they lose a datacenter, their theoretical limit drops accordingly.  If a node or 100 nodes fall off the Bitcoin network, our Tps does not suffer.

It is not an BIP 100 addition. It was unlimited but p2p protocol limited maximum size to 32 MB.

Edit:




https://www.blocktrail.com/BTC/pools

This would be a great solution. I also see that majority here likes BIP 100. Lest hope this will be pushed and that this never-ending debate will finally end.

According to some reddit sources, already 35% of all miners are in favour of this change. Lets hope!

https://bitcoin.org/bitcoin.pdf

That may be irrelevant, but that was part of the initial the goal ...

BIP 100 is not so bad in the midterm (2-5 years), So that's a good start to me too.

This is a good place to look, it seems I can point my hash power to those pools that support BIP 100, currently btcchina and f2pool are supporting it

"surpass Visa" is the most irrelevant claim I have ever heard, it is like a cruiser that carries 3000 person are trying to challenge the speed of a F35 jet plane

Centralized clearing system like Visa or Mastercard can do several thousand transactions per second, because they do not move any money at all, all it did is adjusting the numbers of each account so that they match the transaction, and the numbers of all those accounts are located in the same database server with multi Gigabytes/second of data trasfer rate

In fact, any centralized bitcoin service like exchanges and online wallets can already achieve similar transaction speed like Visa. What bitcoin blockchain is doing is like bank's settlement network, and 2 banks only do ONE TRANSACTION PER DAY (not including weekends and holidays) to settle the difference between debit and credit against each other

Yes looks like BIP100 is gaining some traction fast!

Publishing Bitcoin XT on Aug 15 is putting pressure on the Core developers to reach consensus.