Bitcoin Forum

Three major pools have started tagging their block's coinbase signatures with BIP100 to indicate their support. F2pool, the biggest bitcoin pool, has started supporting BIP100 and all their mined blocks the last 24 hours are tagged to indicate support towards the proposal. But F2pool wasn't the first pool to start showing their support towards the proposal. On August 23 kano.is also started supporting the proposal (http://kano.is) and was followed by bitclub.

---

I would consider today a breakthrough for the block size debate. ~25% of the total hashrate has started showing support towards this newly introduced proposal. While Slush pool is the only pool bringing out bip101 blocks, bringing the total on bip101 supporting blocks mined to 5, only over the last day the top pool has contributed more blocks than that. Of course, the largest pool is more influential, but that's not the only reason to believe that BIP100 is doing better. BIP100 is also supported by more pools and the miners in those pools seem to fully stand behind this decision.

---

What's your take on this? Will BIP100 receive more acceptance? Could it overtake BIP101 to become the accepted solution?
Read about BIP100 here:
http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf

---

Update: You can use blocktrail's Pool Distribution statistics to see for yourself. Numbers above should be outdated.

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

By going over it fairly rapidly, it look like the new block size would be voted by the miners. Honestly i think this is a great counter offer to the shifty XT core fork.

If only what i read get implemented i think we should consider it. Unless it get bundled with other crap like XT did.

One thing that's peculiar about the ones signing "BIP100" is that BIP100 actually proposes (loosely, admittedly - and the details have a mathematical incompleteness without explanation) a voting mechanism using "/BVsizeinbytes/" where the exact size is specified in their vote.

So it almost seems more like an anti-vote ("we specifically don't want BIP101") than a vote for a particular size.

I am kind of on page with your take on it.

To me going from 1mb to 8mb  is too much.

This  proposal seems to allow for us to vote in 2mb or 3mb or anything up to 32mb.

I really push for 2mb just to see what happens.  Not radical change but some change.

Something I found interesting is that the XT code fork and some adoption has motivated people to come up with other schemes as well.  Some not so well thought out, others like Meni's (proposed long before the code fork, though) being well thought out but with some unknown characteristics.  Then there's some others that give a new take on voting by making it costly to increase the block size by making use of the block hash; https://gist.github.com/btcdrak/1c3a323100a912b605b5

The resulting brainstorming and coding efforts are fascinating :)

I think were on the same page. I think radical change is not needed.   Something such as XT really is radical and I think lowering prices.

I think we need to go to up a bit but not sure on exact amount.   I do want them to do it enough we are not doing this again in 6 months or even a year.  But hopefully still not a radical change.

we dont need to go up!  :)

maybe around halving to pump it to 2mb ;)

even under spam attack, the block is under 800kb

https://blockchain.info/charts/avg-block-size?timespan=all&showDataPoints=false&daysAverageString=1&show_header=true&scale=0&address=

we need to show we can go upwards in a controlled organized method not a stampede of lemmings rushing up a hill only to fall off a cliff into the sea of despair.

1 upped to 2  for 12 months just to see what happens is far better then 1 to 20 or 1 to 8

After 12 months we can decide if 3 or 4 is needed. Or wait 12 more months.

Well the thing is, BIP100 is a mechanism for going up if and when we need to, up to a maximum of 32MB which gives us likely a decade of breathing room before needing to be revisited. It is not a block size choice in and of itself. As far as the mining community goes it's the most popular one for us, since it actually hands the block size choice to miners...

I like it. A controlled paced upward movement from 1 to 2 to 4 to 6 is far better then a big jump.

BTCChina have started signing the coinbase of their mined blocks with BIP100

https://i.imgur.com/Pk7uMc3.png?1

Thus far, looks like all BIP100 block flagging pools are doing so on the pool operators' choice rather than offering miners the vote.
Saying that, the biggest BIP101 flagging pool (slush) only has 3PH mining BIP101 flagged blocks and the rest (~20PH) opting for the status quo, so no surprise there that BIP100 surpassed the lifetime BIP101 blocks in a day.

What is the url of the chart you displayed with Coinbase Blocksize Vote please? The only reference I have right now is http://bitcoinstats.com/network/votes/

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

Thanks! Just added to the article Bitcoin XT ELI5 (https://bitcoinnewsmagazine.com/bitcoin-xt-eli5/) to help others understand how dangerous Bitcoin XT is.

Reading over the BIP100 proposal I can see it overtaking BIP101 as the accepted solution simply because its more flexible in addressing the problems at hand than BIP101.
A reasonable proposal will be met with a stronger consensus than one mired with issues in my opinion.

Boycott Slush!

Well, they provide miners with an option to use their hashpower to mine blocks in support of BIP101. It's not obligatory for people using the pool to also support BIP101. You could just not support BIP101 but keep mining in slush at the same time but that's your decision to make.

ok,  I hope BIP101 is not the default.

I mine at Slush, and my simplistic understanding is that the "usual/default" port of 3333, that's been used for years, is the BIP100 port. If you want the BIP101 blocks, then you use a different port (3334 I think). This whole BIP101/XT thing has been a complete fiasco in my opinion.

I think a more accurate headline for this thread would have been "BIP101 struggles to get 10% acceptance".

Just my BTC.001 of a BIP100 block (I hope).  :)

They give their miners an option to vote for BIP101. Here (https://www.facebook.com/MiningBitcoinCz/photos/a.338761539543272.77635.281453778607382/847072952045459/)'s the announcement they made. Those that mine on the regular URLs mine regular blocks, meaning they don't take part on supporting a certain proposal.

Thanks for the Facebook pointer. You comment suggests that there are actually 3 choices:

- Abstain from expressing an opinion (i.e. the current 3333 URL)
- Vote for BIP100 (What port?)
- Vote for for BIP101 (Port 3301 from Facebook)

I would think it's also valuable to mention this on the pool website, but I found nothing there.

Anybody else confused?

I don't think slush offers an option to vote for BIP100. All those URLs in the fb post must be for BIP101 voting. 

Bitfury also in support of BIP100

https://www.blocktrail.com/BTC/pool/bitfury

sorry, I do not understand what is increasing the blockade?It earns more?He earns less?It brings benefits to the miner's house? basically I just realized that passes by 1M to 8M, but what is it do not understand it, if someone can explain it in simple words. thank you. :'( :'( :'(

It allow more TX to fit in one block. It is not required at the moment, but it would be nice to have it increased a little bit soon. But at the same time it bring less competitions for transactions to fit in, thus the TX fee would probably go down.

You and me both what is this now 3 proposals on the table? Yeah it is starting to look like the Yugoslavia.......frigging civil war factions....all this talk of discord ...this could get real messy
with no way to consensus...too many players from what I can tell  

But by all means better minds then myself what is the current situation (in small words) would be appreciated by all here I'm sure. (or at least me and the guy above quoted)

(stupid core devs we should just sponsor a 'slap fight' between them to duke it out ..prob would last 3 min in they would poop out after getting winded...and wa la consensus!) :)

There's actually quite a few more proposals as long as you also count the ones that haven't decided to slap a BIP onto themselves (note that a BIP number is supposed to get assigned after a short review) then there have been various proposals.

Here's one from 2010, for example: https://bitcointalk.org/index.php?topic=1865

And here's another one that's more recent that, like the 2010 thread, deals with an average of previous 2016 blocks: https://www.reddit.com/r/bitcoinxt/comments/3iifp6/variable_block_size_proposal/

So you can see that there's a lot of ideas floating around as 'proposals' that are rehashes of earlier ideas, and many of them are without merit, would require major changes to the Bitcoin protocol (for example, there's currently no method to let nodes 'vote' automatically other than by existing - and that can easily be spoofed, as evident in xtnodes.com's graphs and reddit discussions), or have fatal economic flaws.

At the moment there's only 3 with any official sort of traction:

• status quo - this doesn't require any change on the side of nodes or miners and essentially maintains the status quo; what we have now.
• BIP100 - this is a proposal by Jeff Garzik that has recently seen miners 'vote' for it by way of signing their coinbase transaction's (the transaction that pays the miners' the current BTC 25 + fees) scriptSig with the string "BIP100" - though I also count the ones that sign it with "/BVsizeinbytes/".  You can ready about BIP100 in Jeff Garzik's proposal: gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf .  This has not yet been formalized or implemented in any code.  That's why these 'votes' are not really votes for BIP100 so much as a "we want change, but BIP101 is not it, we prefer BIP100 in lieu of something we'd like even better".
• BIP101 - the proposal by Mike Hearn and Gavin Andresen - has seen some miner support as well by voting using the block version.   Unlike the BIP100 'votes', these votes do count for something for everybody else who is running a node with BIP101 implemented - be that XT or a Core build with the 'only big blocks' patch.  You can read more about BIP101 in https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki .

I'm not going to go into details of the pros/cons of these options.  For one thing, I'm not an economic scholar, so I wouldn't even know where to begin in terms of what would be better for the economy of Bitcoin for the various parties involved.  I don't adhere to the "bigger blocks is better because we can fit more transactions" any more than the "smaller blocks is better because there will be a more healthy fee economy" simplicity.  Read the proposals, google around, check out people's opinions (and keep in mind that many are polarized, especially since recent reddit events have caused some people to favor one over the other not on the merits of the proposal, but on who moderates which thread), and try to make up your own mind.

However, in terms of "the current situation", you can have a look at which miners 'support' which proposal through e.g.:
https://www.blocktrail.com/BTC
https://data.bitcoinity.org/bitcoin/block_size_votes/
( Note: These charts also show something labeled "8MB".  This includes the "/BVsizeinbytes/" where 'sizeinbytes' == 8000000, as well as some miners' coinbase scriptSig reading "8M/" and other variants.  The latter is not specified in any proposal. )

And nodes showing e.g. adoption of XT - but keep in mind the ability to spoof and the bit about them not having any voting power other than existing (and thus being able to relay blocks that match the proposal they back) - through e.g.:
http://xtnodes.com/
https://getaddr.bitnodes.io/dashboard/#user-agents

Further, you would have to google or check reddit (a fairly decent source of information) to see which services support one proposal over another.  Eight online services have at least pledged support for BIP101: http://blog.blockchain.com/wp-content/uploads/2015/08/Industry-Block-Size-letter-All-Signed.pdf

One small sidenote, but that shouldn't be dismissed, is that BIP101 and XT should not be conflated.  BIP101 specifically deals with the block size (voting it into action and the details of how the block size is adjusted) and can be implemented in any client.  XT is such a client implementing BIP101, but also implements various other changes.  Similarly, I could release a client (say Bitcoin Stu) that implements BIP101 but also changes the PoW model; it probably wouldn't be very popular, but as long as people would focus on the BIP101 part, I just might get away with it.  XT isn't nefarious like that, but this to demonstrate if you care at all about what goes on under the hood of a client (including Core and others) - and you should - make sure you read all the changes when new clients/versions are released.

TRS, thank you for that concise, neutral breakdown.  It is much appreciated

Nah, it seems like just changing the ports to bitcoin.cz:3301 if you would like to vote for BIP101 (https://mining.bitcoin.cz/help/#!/get-started/getting_started).

Mine are on the standard port, but IDK if that means I'm voting for BIP100, or just a boring non voter lol.

Is BIP100 an "ultimate solution" to the block size debate, or will developers continue to work on other solutions in the mean time?  It seems to me like the best solution has yet to be developed.

I do like that BIP100 lets the miners decide rather than 2 developers all by themselves, and it gets my vote for the best solution at this moment.  Hopefully this will be our near-term future, XT will go away, and price will start climbing back up.  This much turmoil next year when the halving approaches could be disastrous.

It's a sane solution for likely the next decade as we are virtually guaranteed in that time frame to not need more than 32MB blocks to handle the transaction growth load over that time. It may well be that we will never need >32MB blocks depending on the way bitcoin is used in the future (sidechains et al.) and choosing a system that forces block size support to get bigger and bigger is preempting the future which no one can do, and opens up bitcoin to other potential attack vectors with unmanageable block sizes being pushed out while the nodes are ill equipped to handle it. Is it an ultimate solution? Of course not - we shouldn't try to crystal ball that far into the future and not be afraid to revisit it and mould the system to adapt according to its needs rather than predict the needs. BIP 100 isn't even a guarantee that we'll move to 8MB blocks since it can be implemented with us staying at 1MB blocks if the majority vote it (though the biggest pools all seem to want 8MB).

The reality is that once there is code to support BIP100 then the pools seem ready to adopt it and it really doesn't matter what the rest of the community has to say with further rhetoric and indecision since the network is determined by mining and not further dialogue - that's not to say the dialogue was unnecessary in the first place.

But BIP100 is a good thing to have handy. I doubt the network will get to 80% for BIP100 unless we come to a point where the network is saturated and people lose money somehow. That's probably the only thing that will push people together to get consensus.

As long as people make their money or make more money by staying at 1mB. I don't think the BIP100 or anything else will happen.

You are a 'boring non voter', Slush's regular URL mines regular blocks. :p

https://www.blocktrail.com/BTC/pool/slush

Anyone else notice the size of the last block?

974.74 kb  & 2,320 transactions.

https://blockchain.info/block/00000000000000000971eaf8d7ad55052ae8a109f2e723a77dec911c0cadb850

Yeah you very well could be correct imho. The core devs are so concerned about code changes of any kind messing up the cash cow of btc imho.
The bitcoin xt guys want to be the 2 kings to control the speed and upgrade of bitcoin core..ie full speed ahead ..not sure that is a good way to go on coding either
and the bp100 idea ..which has to try to win thru the above FUD as an "idea" legit as it very well may be..not sure just saying

like herding cats :)

Haha indeed. Hearding cat. Thats more or less doable, its more getting them together by throwing food at one spot. And food here is cash.

Well now that bip 100 seems to be going strong (over 50%) will the Bitcoin CORE devs get on board on the process the big miners want to do on
blocksize? (go up for blocksize but go slow)

or am I missing some future 'childish behavior' that I'm unaware of by the bitcoin devs (all of them) as a group?

I don't know, don't they just need to delay the jump for them to get maximum alleged profit on that blockstream thing? Regardless, them having a core version that support block size increase "soon" or on hand give them the best control again. So whatever their reasons is, they are set.

First of all, bip100 isn't coded yet. It'll certainly take some time until the proposal is implemented into a full client. We don't even know if the proposal will be implemented as is since there are issues that might be address during development. It's very likely that pools voting for BIP100 are just showing their dislike towards BIP101 considering BIP100 a more modest solution for the blocksize issue.

If you want BTC.001 of a BIP100 block - then you can leave your vote here: http://bitcoinocracy.com/arguments/bip101-is-better-than-bip100 (just click "Doubt" and sign the message with bitcoin address that holds BTC.001).

I doubt that Bitcoin future should be decided by miners (http://bitcoinocracy.com/arguments/bitcoin-future-should-be-decided-by-miners), I think all bitcoin users should have a vote.

There's two ways to interpret that site:
A. By signees - i.e. each 'vote' is counted as such.  Problem: I can send small funds to 1,000 addresses and cast 1,000 votes.
which is why instead they went with:
B. By amounts - i.e. if you signed with an address holding BTC10, then your vote will weigh 100x as heavily as somebody who signs with an address holding BTC0.1.  Problem: Cool, rich people influence votes more than the poor ( just like the real world ;) )

They acknowledge as much in their site description: "determine the truth backed by real monetary value".  So yes, you get 'a' vote, somebody poorer than you gets a lesser vote, and somebody richer than you gets a greater vote.  See also some of the other arguments at that site :)