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://bitcointalksearch.org/topic/block-size-limit-automatic-adjustment-1865And 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/BTChttps://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-agentsFurther, 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.pdfOne 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.
)
