Bitcoin Forum

There is a silver lining on the horizon - BIP 100 from Mr Garzik. Looks like a good compromise to me.

BIP 100:

Protocol changes proposed: http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf

        -Hard fork, to
        -Remove static 1MB block size limit.
        -Simultaneously, add a new floating block size limit, set to 1MB.
        -The historical 32MB limit remains.
        -Schedule the hard fork on testnet for September 1, 2015.
        -Schedule the hard fork on bitcoin main chain for January 11, 2016.
        -Changing the 1MB limit is accomplished in a manner similar to BIP 34, a one­way lock­in upgrade with a 12,000 block (3 month) threshold by 90% of the blocks.
        -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.



i would be happy if such thing would be adopted...and after that - Bitcoin to da Space  ;) !  

yes this is acceptable. seems like a middle ground, miners could up the limit to 2MB in a few months, and a year later if w'ere filling blocks 2MB big again they would just up the limit, no debating just the network justifying itself.

hopefully miners are aware of this option and start voting for it.

Strange that you guys didn't notice BIP 100 well before BIP 101 (as I am pretty sure that it had appeared weeks before).

Anyway - now perhaps send your newfound information to the bunch of CEOs that have all backed BIP 101 to see if they will also back BIP 100.

all that really matters is hashrate.

True - but if some of the major pool operators are not aware of BIP 100 then that would be a shame (it seems none of those CEOs were aware of it).

Let me ask you something directly then (no, this is not an ad hominem attempt). Why did you initially ignore both BIP 100 and 102 when I (along with a few others) were telling you guys to read about both of them?
BIP100 has been around for quite some time and I've talked about it in multiple threads.

Yes they are.

---

---

BIP 100 support:
DiscusFish / F2Pool  (https://www.blocktrail.com/BTC/pool/discusfish)
Kano CKPool (https://www.blocktrail.com/BTC/pool/kano)
BitClub Network (https://www.blocktrail.com/BTC/pool/bitclubnetwork)

---

---

i noticed it but it seemed like there could be no consensus about BIP 100 or BIP 101.

XT is an emergency solution for me.

What is the emergency?

That Gavin and Mike are impatient to sack the Bitcoin Core devs and go work for big business?

(I am being rather overly cynical of course - but I really don't see that there is any emergency)

Again - I'll just point out that during the "stress testing" spam attacks I had no problem at all sending BTC txs with zero fees (so those trying to suggest we should panic about solving a problem in getting txs through are just full of shit).

because it wasn't well pushed. and at first it seemed overly complex for nothing, at first it seemed an agreement would be made when the BIP went from 20MB down to 8MB. but with so much disagreement, this idea of letting the network form the agreement is looking good.

So it comes down again not to being technically better but being more "pushed" which is the bullying style tactic that was taken by Gavin and Mike.

Personally I don't like bullies - so I back BIP 100 on principle (even though its author doesn't think much of me).

This whole XT thing actually reminds me of when Gavin tried to kick out Luke-Jr (calling him "poisonous" from memory which was back when BIP 16 and 17 were the issue).

I wouldn't say I am a fan of Luke-Jr myself but I disagree with these sort of "social manipulation" style tactics which is basically how I see the current situation.

it would be hard to push something that isn't technically good.

but when it comes down to it all the damn BIPs would do the trick, its just a matter of picking favorites now, so ya its all about pushing for it, a good way to push something would be to claim it's technically  the best solution, and prove it.

The problem is that the issue isn't actually a technical one except perhaps that of scaling (which when we are talking about the future is full of unknowns).

I think that BIP 100 is a more intelligent approach as it allows the miners (the only people that really matter in regards to block sizes) to vote between themselves as to when an increase should occur (rather than just relying upon a theory that bandwidth will increase much like processing power).

In regards to the bandwidth increasing theory I would invite people to just look at Australia - they were going to implement "fibre to the home" for the NBN rollout initially but under a change of government are now no longer doing this (reducing the bandwidth considerably). So bandwidth really doesn't work like processing power as it is "political" (so anyone making a theory that bandwidth increases will work just like processing power is living in a Utopian world).

also, LiteCoinGuy turning around appears to have turned the market! well done LiteCoinGuy  ;D

I was looking for the text of BIP 100 and 102 when I noticed that (what I think is the official) github (https://github.com/bitcoin/bips) only has BIP 101.
OP links to BIP 100, so that one's solved.  Where can I find the text for 102?

So far, having looked only at the outlines, I like 100 better than 101.

BIP102 is just an alternative for everything else, something like a emergency solution proposed by Jeff.
Here are the two links:
Documentation (https://github.com/jgarzik/bips/blob/2015_2mb_blocksize/bip-0102.mediawiki)
Github (https://github.com/bitcoin/bitcoin/pull/6451)

BIP100 looks like a compromise but I still prefer BIP101. It gives much more capacity.

As it came first (of all the BIPs to do with blocksize) exactly how is it a compromise (i.e. it can't be a compromise to the other BIPs so what is it a compromise to)?

Having increases just being automatic based upon a non-scientific theory about the increase of bandwidth doesn't seem like a better idea to me.

Getting the miners to vote on it at least makes sure you don't have any big troubles (if they are struggling to handle the bandwidth then they would vote not to increase until they had good enough hardware and connectivity to do so).

Everyone seems to forget that the exponential rate of BIP 101 can be adjusted with a soft fork.

So vote for a hard fork to later introduce a soft fork vs. just one hard fork.

Hmm... I think I prefer BIP 100 in that regard (the less forks the better).

FTFY.

---

---

Exactly. I've been saying this quite often. What Gavin proposed is not sustainable.  I think that if another pool starts showing support for BIP100 that we might be probably heading into that direction (since BIP 100 has already more than 20%).

but BIP 100 auto adjusts

everyone vote BIP 100 and be done with this madness

I am not sure to understand one point of BIP100
Can the 32 mb be removed? It is not so clear to me in his text (no native english ... )

I agree, 32MB limit? come on are we gonna have another fork debate down the road?

NO, it cant, You need another hard fork

This is a kick the can down the road solution.

Fucking speechless that ppl want to choose this.

Oh.... they assumed these "CEOs" dont vote for BIP100 because they dont know about it..... come on. Please. They have millions dollards interest in bitcoin while these folks are nothing but in their underwear behind a screen, being armchair experts.

32MB limit is a hard limit on ANY network msg

it will have to be removed when we need blocks bigger then 32MB

its going to be like the block size limit debate only with 3 Gavin like forks from hell! mahahaha

we're going to need a better way to achieve consensus  (https://bitcointalk.org/index.php?topic=1160035.msg12220517#msg12220517)

Am I mistaken or BIP100 has a blocksize hard cap at 32 mb while BIP101 goes up to 8 gb?

And when the 32 mb will be reached we'll have this debate all over again? Fuck no.

So we are seriously concerned now that 32 MB is going to become an issue in the next year or two so we should be thinking GBs per block?

If the point was to have all the world's txs on Bitcoin then it seems odd that only the part of the world that has the very best internet will be able to use it in a few years.

Thus - we want GB blocks that the developing world can't handle - therefore we don't want the developing world to use BTC.

Bring on the alts then I say.

Yes read my post. Fork, fork fork fork.... is what they want.

all we really want is a kick the can down the road solution anyway.

if scaling bitcoin = no block size limit ( or massive GB limit ) , fine then we are moving in the right direction slowly and cautiously, i see nothing wrong with that...

I like the idea of BIP100 except for the 32meg limit. It would be much better if we do not have to go through all of this again in a few years from now. I like BIP101 because it is a more permanent solution. If BIP100 did not have the 32meg limit I would absolutely support that instead.

Very smart argument there

Since when bitcoin users = bitcoin nodes?

Its very clear from Satoshi that he doesnt even expect users to run nodes.

Current network: 6800 nodes ,

Most users only use thin wallets.

32MB allows for like 50X increase in traffic, it would be years away. and when it came down to it poeple would sell their bitcoin and you'd know what to do.

right which is why MAYBE GB limits would be OK but we are way to far away from that to make any reasonable choice about it now.

right now BIP 100 would have us set for years.

This is the misinformation that I keep talking about. You think that BIP101 is a permanent solution. 8 GB blocks are not a permanent solution. If Bitcoin achieves its supposed goals, then 8 GB will be a inefficient temporary solution.
A 32 MB limit gives enough room for other solutions to be developed and implemented (they're much more efficient).

Where did you come up with a 50X increase in traffic with a 32x increase in the block size limit?

I do not understand the point of letting miners vote AND limiting them.
Miners are not kids in the supermarket. And if they are, why give them more power in the first place...

This I must say, is a great take on the current situation of where bitcoin lies. Why not adopt some elements of different BIPs instead of choosing only one for the fork? If this happens, the potential upgrade could maximize the most out of the current code and we may not even need to see forks happening around quite often.

Btw, haven't seen a link for BIP 102 yet. Anyone here have it?

i figure we aren't quite at the very limit yet, all blocks are <900KB avg block size is like 500KB ish and network is running fine

so ~50X

If you end up pushing the developing countries into a situation where they have no miners at all (so all just running SPV clients) then I wonder how much they'll end up actually trusting Bitcoin (as that is something controlled by those with high speed internet in the rich developed countries).

one battle at a time 32MB is another limit that makes perfect sense right now.

The same logic can also be applied with the 8 GB blocks...  and at least it is a much longer term solution.

they don't have FED printing press and they trust dollars don't they?

for years ,..... how many? and then what?

Blocksize limit isnt the solution to ANY problem you think a large limit may cause. Its not. Even at 1MB, not many ppl are willing to run nodes at home. Even at 1MB, miners can still do selfish mining attack. Even at 1MB, miners still dont fill blocks if doing so increase their orphan rate.

There should be a better way to governing. Let the economic incentives do its thing again. We dont have solution for this yet. But using blocksize limit isnt one.

I wouldn't give miners that much freedom with regards to the block size limit.
A group of well-connected profit-driven miners would have little consideration for full nodes' capacity to handle the increased traffic.
They (miners), in fact, might not even notice the drop in the number of full nodes, while playing with increased block sizes.

A static flat cap gives end users running full nodes a way to stay in the game and to limit the voting power given to the miners.
Static limit is really hard to abuse from that perspective.

Huh - what on earth do you mean?

You do understand that a "full node" that is not mining has "no stake in the game" don't you?

You either keep running a full node or you don't (according to how much bandwidth you have) but no-one is going to care one way or the other (it is basically irrelevant whether or not you run a full node if you are not mining).

Right now, miners cannot produce blocks larger than 1Mb (thanks to full nodes' consensus not to accept them). Even if it is economically viable for miners to increase the limit, they can't. I suggest we jump from 1Mb to 8Mb hard cap and re-evaluate in about 4 years based on the data we collect.

Okay - yes I get what you mean now.

I think that there might have been a BIP to do just that also.

But understand that as less and less people run full nodes the miners will actually end up more in control (eventually I think all consensus will be decided by the miners only as there is no economic incentive for non-miners to run full nodes).

This is the nirvana fallacy. Just because we can not scale Bitcoin efficiently it does mean we should not scale Bitcoin at all. I am starting to see that there is a big difference when you look at this problem from a political and economics perspective, compared to when you look at this problem from a technical perspective. From a purely technical perspective you are correct. However from a political and economics perspective 8 GB is a huge step up from 1 MEG, and does make a huge difference in terms of adoption and the survival of Bitcoin in the long term. I do think this maybe should be the last hard fork we ever do for Bitcoin since consensus will most likely be even more difficult to reach in the future.

https://www.youtube.com/watch?v=YaaknMDbQGc (https://www.youtube.com/watch?v=YaaknMDbQGc)

https://bitcointalk.org/index.php?topic=1164464.msg12267335#msg12267335 (https://bitcointalk.org/index.php?topic=1164464.msg12267335#msg12267335)

Miners determine the longest chain, full nodes determine the valid chain.
The longest valid chain is called Bitcoin, so both miners and full nodes have a say in what Bitcoin is.

Statically capped Bitcoin with gradually increasing soft limits is Bitcoin we all recognize and value.
Hope that stays.

Miners also determine the valid chain because they also run full nodes. CIYAM stated it.

Miners normally constitute a small minority in the network of full nodes. It is the rest of the network (non-mining nodes) that prevents miners from forging the definition of "valid" chain. Thus letting miners alone decide on the block size limit gives them unprecedented ability to wipe out the rest of the network and redefine what "valid" chain is.

Anything beyond 2020 is a best effort guess

In regards to this whole blocksize debate I think one further thing needs to be stated and that is "what are the Chinese miners going to do?".

The Chinese miners account for more than 50% of the hashpower so in effect it is really up to them what will happen (as much as that probably galls all westerners).

My guess is that they'll remain silent about the issue but will decide one way or the other and we'll find out about that early next year (so all the grandstanding going on now will actually amount to nothing).

(by "miners" I am meaning "mining pools" of course)

you are wrong - i was always a big block guy not an XT guy per se.  ;)

http://up.picr.de/22922819qv.jpg

but if we find no consensus, XT is still my way  :P

No, hash power is not the one that decide where bitcoin will go, consensus is

Imagine that Chinese government took over most of the mining farms in china and controlled 70% of network hash power, made their fork and created client bitcoin BJ (BJ stands for BeiJing), with their party leader deciding the future coin generation scheme. What will happen?

No one will use their fork, no merchant will accept that client, coins on that chain would worth nothing, those hash power working on that chain would just be wasted electricity

The censorship resistance is not achieved through physical hash power(In this case you can't fight against BJ coin fork since it has majority of hash power), but through a consensus. Anything that brake this consensus is automatically excluded out of the current bitcoin ecosystem. Of course those hash power could harm the network if they attack, but the damage is limited: Anyone who hold his coin will not be affected by the attack

You might have missed my earlier post - but if the requirements (such as bandwidth) for running a full-node become too much then no-one is going to run one other than a miner.

Thus the consensus will be according to the miners as the SPV nodes (everyone else) will simply accept that.

So a vote for "huge blocks" is basically a vote to reduce the consensus decision to a very small group of miners.

True.

In a system that values consensus, like Bitcoin, it would be natural for participants to exercise achieving it consistently on a regular basis.
I suggest we re-evaluate the grounds that Bitcoin is standing on (with a possibility of a hard fork to rectify known issues) every 4 years.
The "halving celebration" needs to be well deserved by having to achieve consensus on how Bitcoin's going to move forward.

Raising the hard cap would be one of those issues on the table.


Chinese miners alone won't be able to replace the 6000 full nodes that exist in the network today, but they can collectively agree to implement a soft limit on block size in case a more aggressive approach gains momentum. From what I've heard, the move from 20Mb to 8Mb was pushed by Chinese miners due to poor connectivity in the region.

Maybe you guys "just don't get it" but I no longer run a "full node" because I live in China and the bandwidth doesn't work (so I would think that pretty much no-one in China runs a full node on a home-grade internet connection).

Although I am only using "home internet' I am sure that others in China would also have problems trying to run full nodes due to the controls of the internet here (so you are simply not going to see any Chinese nodes able to handle GB blocks with any reasonable speed).

so what?

i live in canada with gr8 internet and haven't ran a full node in years. why should i? miners run full nodes.

decentralized != 100% evenly distributed / accessible

Then the decision (about block size) is 100% up to the miners not up to the "other nodes" as was being suggested by others (my earlier point).

pretty much.

even if there was 1000X more node than miners it would still be up to them

So - my other point is that >50% of the power comes from China and not one of the major China CEO's signed that document (about BIP 101).

Therefore my guess is that BIP 101 is not going to succeed (as the Chinese will just quietly kill it).

china has gr8 influence and rightfully so, ya.

XT is cooked, and not just because  Chinese don't like it NO ONE likes it.

the CEO's were pressured  into writing by XT. all i'd take away from their letter is that they see there is a need for SOME change and are willing to back the most popular implementation of that solution, they thought XT was going to be popular, i guess.

If you have a consensus, you don't need to vote. If you vote, you have not reach a consensus. It is consensus that matters. Suppose that 75% miners are confiscated by chinese government and fork into a BJ chain, that would still not make it bitcoin, but an altcoin

People tends to rely on authorities, when they find that human are unreliable, they turn to bitcoin, thinking that machine will be reliable. But they forget that machines are also operated by human. So rely on machine is just rely on the person that maintain the machine, even worse. They have to learn to rely on their own judgement, not blindly listening to anyone else

Funnily enough it is not China that is wanting to fork Bitcoin but Gavin and Mike (the US and the UK).

As usual - the Chinese are never the ones to "start a fight". Instead they'll just sit back and decide how to best profit (as they always do).

they will soon realize they can best profit by putting all there hashes on BIP100 and then everyones going to LOVE BIP100 with 99% hashing power backing it, BAM we fork it seamlessly leaving 0.1% (Gavin and Mike's hashing power) mine XT. the war is over prematurely investors see bitcoin nolong hangs in the balance, they buy coins from chain and everything is back to normal.

its not rocket since chain, VOTE.

You just missed one rather important thing.

Chinese love to gamble.

So they will not make their position known until the last possible moment (they view this whole block size thing as a way to get rich quick). :)

market turn stalled, well done LiteCoinGuy  >:(  ( ;D)

i bet they induced the crash yesterday, they have a  plan for all this and are not scared to buy while everyone else folds under pressure they accumulate. mischievous little chinese are going to soon be the economic marjoy in BTC as well.

This is exactly what BIP100 gives them.  By the mining pool voting with the blocks it produces, the majority can pick what the blocksize limit is.  If the majority of Chinese pools don't want to go above 8MB, then they keep their voting at 8MB or under, and it's the top 80% of votes that judge the blocksize.

BIP100 is the perfect compromise for the current situation.  

First, it introduces a dynamic ability to adjust the size up to a 32MB maximum, which will be able to scale the network for at least the majorly forseeable future - that's potentially 224 Tps.  You have to remember that Satoshi's original limit was 33MB, which this falls inline with.  

Second, it keeps the blocksize down to a manageable size, which will prolong the lifetime of a full node on the network.  An 8GB blocksize limit with XT?  And you still clamor for decentralization, whining about the number of nodes declining?  That large of a blocksize will accelerate the centralization of nodes, as only those who have top-tier datacenter hosting will be able to run a full node due to the bandwith limits.  Hard drive sizes matter not, but with an 8GB block it would take over 6500 seconds to pass that block info on a 100Mbit network connection.  It would take over 650 seconds (longer than the 10-minute block threshold) on a Gigabit network connection.  That is completely unrealistic.

In order to surpass Visa (150 million transactions per day), we would only need a 256MB block size.  That's a far cry from needing an 8GB blocksize.
In order to surpass PayPal (10 million transactions per day), we would only need a 16MB block size.  That's a far cry from needing an 8GB blocksize.

Nodes need miners, and miners need nodes.  Each of them play a critical part in the network - without the nodes to protect the network, it fails, and without the miners to mine transactions to be protected, there's also no network.

In order to keep the miners going there needs to be enough transaction volume and fees to sustain them once the block rewards can't.  This proposal allows the market to dictate the blocksize, so that there's enough pressure in the blocks to have higher fees, but also enough block size to allow for those cheaper transactions to go through.  The proposal allows for expansion when there's enough transaction volume to warrant it, and contraction when it doesn't, so that miners will be able to maintain incentive to keep the network alive.

Since a lot of hash-power is concentrated in China,
it's appropriate that the majority of full nodes will then come from the rest of the world to help define what Bitcoin is.
That's the balance I see.


What if China fixes their connectivity problems in the future?
We will then have the highest mining capacity and decent connectivity all in one place with a mechanism that allows miners to push the block size limit high enough to dominate the blockchain completely. Hard cap allows to observe network dynamics, while staying on the safe side and adjust the limit when the need arises, while at the same time exercising achieving consensus on what the next limit should be.

Ah so you've made that conclusion using the amount of transactions being processeed today (not the maximum possible). Well, then you're probably right (as far as a estimation can be right).

---

---

Please stop spreading the nonsense that was implanted in your heads by Hearn. Nobody ever said anything about not scaling at all, thus your fallacy assumption is invalid. Some people are saying that we should not be looking into ways to scale upwards (as it is very inefficient). We have two options (hugely simplified):

• scale now with a very inefficient method (and risky)
• wait for R&D to scale with a very efficient method

Many do not realize the problems that anything untested can cause. A doubling every two years is completely unrealistic and is going to cause a lot of trouble, especially for developing lands.

---

---

Your calculations are not correct. I don't know where you are getting this from. Are you assuming that currently the network is doing 7 tps? Well it is not. Currently the network is doing ~3 tps, or a maximum of ~259k transactions per day (very low if we were to scale globally soon). To handle 10 million transactions per day we would need ~38MB blocks. To handle 150 million transactions we would need ~579MB blocks.

In other words, this proposal is one of the better ones (if not the best one that we're aware of, so far).

---

---

Fix? Problems? There are no problems. They've built the system (i.e. Great Firewall). If you think that the censorship in China is going to go away soon, think again.

First off, its the pools that vote, not the miners directly.  Which, if you aren't aware of already, the majority is currently in China and they're fine with going to 8MB today even with the crappy Infrastructure.

Second, there is a hard cap - 32MB - which has adjustable increments within it to handle active market pressure.  Which is a very reasonable cap, getting us to roughly 20 million transactions per day.  It will allow Bitcoin to surpass PayPal, and handle 1/8th the Visa transactions.

A vote for XT would do more towards fueling your fears than this proposal does.

The theoretical max of a 1MB blocksize is 7 Tps (https://en.bitcoin.it/wiki/Scalability#Scalability_targets).  The network is currently doing 3, but blocks are not currently maxed out (https://blockchain.info/charts/avg-block-size).

Therefore, if we base the calculations on the theoretical max of 7Tps / 1MB, then 32MB = 224Tps in theory.  This puts us at a theoretical max of 19,353,600 transactions per day.  Let's just call it 19 mil.

If Visa is doing on average 150 million per day (http://usa.visa.com/merchants/industry-solutions/retail-visa-acceptance.jsp), then 150/19 = 7.895.  Multiply that out and you get 252.6MB as your theoretical blocksize to match/surpass Visa.

This is not how that works. Read this thread. (https://bitcointalk.org/index.php?topic=946236.0) The network can not handle 7 tps, that's a myth. Even though my calculation was done pretty quickly and without doing (extensive) research it is much more correct than yours.
Also don't say "surpass Visa". To surpass their network, we would need to be able to process more than 56 000 transactions per seconds (which is their current maximum).

Chinese pools are likely not running on a "home internet" connection, that's why they have evaluated that 8Mb is probably ok for them. But the ability to run a full node at home for the rest of the network would be a must if we want a healthy network of nodes. Fortunately, in Europe, US, and other developed countries home connections are capable of handling 8Mb blocks, though some users might suffer from this temporarily before the tech catches up.

Regarding, 32Mb limit. I'm not sure if it comes from the original network message limitation in Bitcoin or is a new addition related to BIP100. It was explained somewhere on this forum, that the block no longer has to fit in one network message (due to headers first implementation), so that original 32Mb limit may no longer apply. But better call the experts on this.

All in all, BIP100 seems fairly balanced to me, so I wouldn't be opposed to it, just thought that a 8Mb static cap was easier to implement without bugs and safer from perspective of manipulation attempts by the miners.

I like BIP100 also, I would be happy with either BIP100 or BIP101 implemented on Core.

+1


same exact feeling, but BIP100 should be fine, and it's not as extreme so we can all agree to it more easily

I am relatively new to this discussion, but seems that everybody (or almost) supports a raise in the block size, either by BIP 100, 101 or XT.

Some people say it is not needed to raise block limit yet, but still support a raise. I have seen considerably less people supporting that maintaining the block size to 1MB is the way to go so ...

Wouldn´t be better to make some preasure on the developers to do the raise instead of fighting about the XT vs. Core thing?

Mining pools are really starting to show support of BIP 100 in the coinbase blocksize vote (https://www.blocktrail.com/BTC).

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

Yes looks like BIP100 is gaining some traction fast!

"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

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

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 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!

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

Edit:


https://i.imgur.com/1ixqIW1.png (https://i.imgur.com/1ixqIW1.png)

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

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.   :P

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.

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. ;)

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

True, that is why I also support BIP100

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.

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?

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.

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.

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.

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.

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

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.

They've recently signed a document showing support for BIP101. (http://blog.blockchain.com/2015/08/24/industry-endorses-bigger-blocks-and-bip101/) However, Bitpay explicitly stated that they want BIP101 in Core.  (https://medium.com/@spair/increasing-the-block-size-limit-85ff236fc516)

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