BIP100 surpasses BIP101 in one day with 10% of the last 24hr blocks

[alani123]

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'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.

[1713957066]

1713957066

[1713957066]

1713957066

[1713957066]

1713957066

[1713957066]

1713957066

[alh]

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'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?

[alani123]

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

[alani123]

Bitfury also in support of BIP100

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

[marvykkio]

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.

[VirosaGITS]

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.

[Searing]

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.

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

[TheRealSteve]

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.

[Finksy]

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

[wlefever]

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

Nah, it seems like just changing the ports to bitcoin.cz:3301 if you would like to vote for BIP101.

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

[Mikestang]

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

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.

[-ck]

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.

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.

[VirosaGITS]

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.

[alani123]

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

Nah, it seems like just changing the ports to bitcoin.cz:3301 if you would like to vote for BIP101.

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

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

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

[Finksy]

Anyone else notice the size of the last block?

974.74 kb  & 2,320 transactions.

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

[Searing]

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.

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

[VirosaGITS]

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.

[Searing]

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?

[VirosaGITS]

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.

[alani123]

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?

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.