Core is working on a 2mb hardfork proposal, testing is in progress! Amazing news

[lerredit]

Core is working on a 2mb hardfork proposal, testing is in progress! Amazing news!

" 4) Some of us also agreed to work on another hardfork proposal including a 2 MB "no wallet changes necessary" block size bump, which we've been making progress on over the past year, including even after conclusion of the original agreement (there is currently a testnet for an incomplete version running)."

http://np.reddit.com/r/Bitcoin/comments/5gcg98/will_there_be_no_capacity_improvements_for_the/darfdyg/

[1715061385]

1715061385

[1715061385]

1715061385

[1715061385]

1715061385

[1715061385]

1715061385

[1715061385]

1715061385

[Searing]

Core is working on a 2mb hardfork proposal, testing is in progress! Amazing news!

" 4) Some of us also agreed to work on another hardfork proposal including a 2 MB "no wallet changes necessary" block size bump, which we've been making progress on over the past year, including even after conclusion of the original agreement (there is currently a testnet for an incomplete version running)."

http://np.reddit.com/r/Bitcoin/comments/5gcg98/will_there_be_no_capacity_improvements_for_the/darfdyg/

Perhaps I'm mistaken but this does not look as anything officially in the works via bitcoin core
at this time. Just yet another 'proposal' not to be acted on imho. Hope I'm incorrect. 

[lerredit]

Core is working on a 2mb hardfork proposal, testing is in progress! Amazing news!

" 4) Some of us also agreed to work on another hardfork proposal including a 2 MB "no wallet changes necessary" block size bump, which we've been making progress on over the past year, including even after conclusion of the original agreement (there is currently a testnet for an incomplete version running)."

http://np.reddit.com/r/Bitcoin/comments/5gcg98/will_there_be_no_capacity_improvements_for_the/darfdyg/

Perhaps I'm mistaken but this does not look as anything officially in the works via bitcoin core
at this time. Just yet another 'proposal' not to be acted on imho. Hope I'm incorrect. 

What he means by proposal probably is that he is just a coder. The miners decide what actually gets implemented.

[bitebits]

I am glad you posted this in the Speculation section.

[franky1]

(comments are based on the reddit post of OP)

blockstream paid devs gmaxwell and Wuille and luke JR are making a persistant growth altcoin based on bip103 (the intentional split) OR a one time 2mb

bip103:

The new chain created by those changed nodes will be rejected by old nodes, so this would effectively be a request to the ecosystem to migrate to a new and incompatible network. Doing this while controversy exists is dangerous to the network and the ecosystem.

bip103 is not a consensus upgrade of bitcoin mainnet where orphans take care of the minority.
bip103 is an intentional split by having a ban IP/useragent so that the bip103 implementations do not interact with the mainnet implementations.

DO NOT BE FOOLED

if blockstream paid devs are implementing 103, blockstream are still:
dividing the community!!
avoiding consensus, not releasing code that will work with the bitcoin mainnet,

SILLY CORPORATE A-holes

by suggesting its an incompatible network leads to the belief they want to keep the old rule alive too.. rather than just having one chain

bip 105:
is dynamic blocksize and uses consensus and the orphaning mechanism without devs needing to be the kings/deciding factor, where there will be ONE chain. but requires miners to push the difficulty up and it only activates if the majority vote for it by working on a highr diffculty. while those opposing it can happily undercut the votes by solving blocks at the lower difficulty.. (facepalm)

4th option:
as for the 4th option a one time 2mb adjustment. again that is just a one time spoonfed amount keeping the devs in control, requiring the community to get on their knees and plead for devs to make another adjustment later.

summary:

if only they learn to use consensus and let orphans take care of the minority(its a bitcoin feature built in) rather than intentional splits(not built in)

i do love how they try to shout that if allowed(majority nodes compatible) its deemed an incompatible new network these new nodes are pushed aside to.... strangely though, if the majority are there to even activate it.. then logic dictates its compatible and is the bitcoin network continuing on but with more buffer space to expand.

lets hope they do the right thing and not offer up an intentional (ip/useragent ban) split, like what ethereum was. and instead intend to use consensus and orphans the way it should be done to keep to one chain. and not have mechanisms that allow pools to be economically incentivised to veto it by not wanting to push the difficulty up just to incorporate more buffer

[Decoded]

Good to seem them trying to accommodate the larger crowd.

The thing i'm concerned about is the future. A 2MB hardfork is only a temporary fix, and are we going to do a hard fork every year or two? That's just stupid.

We need to find a way to fill our blocks not to the hard cap, but a more economic mini cap.

Maybe a soft cap based on how full the mempool is? I don't know.

[iamnotback]

And so as I told you: Bitcoin Price Watch; Breakout Time!

Looks like a serious breakout to ATHs is within months:

Core is working on a 2mb hardfork proposal, testing is in progress! Amazing news!

" 4) Some of us also agreed to work on another hardfork proposal including a 2 MB "no wallet changes necessary" block size bump, which we've been making progress on over the past year, including even after conclusion of the original agreement (there is currently a testnet for an incomplete version running)."

http://np.reddit.com/r/Bitcoin/comments/5gcg98/will_there_be_no_capacity_improvements_for_the/darfdyg/

Note they need the raise the upper limit of block size (while lowering the average block size with the one-time SegWit compression) in order to accommodate surge load and also one of the flaws of Lightning Networks is it can place very high surge load on the blockchain.

So although this isn't the fix for the long-term, it is a near-term solution to open the throttle on Bitcoin adoption.

[iamnotback]

It will help get rid of lots of the FUD going around. It will also put peoples minds at ease about all the conspiracy theories regarding blockstream.

Sorry no. Per my prior comment, the current action perfectly fits the Blockstream business plan:

http://btcmarketwatch.com/2015/08/the-blockstream-business-plan/
https://gist.github.com/shelby3/c786018a8bb2d8d837abce3a4cf4e799#541-segregated-witness
https://gist.github.com/shelby3/67111f328822a36beb4cad1a5220eb33

[jacafbiz]

I hope this is not a trojan horse  to Bitcoin Unlimited group to get their Segregated Witness baby pass. but if they are sincere with this then it is good news for Bitcoin community has a whole

[piotr_n]

Andresen is back on the team? 

No worries.
Considering his coding performance and how much miners don't seem to desire bigger blocks, my SSD should last for another couple of years.

[keyboard warrior]

Core is working on a 2mb hardfork proposal, testing is in progress! Amazing news

4) Some of us also agreed to work on another hardfork proposal including a 2 MB "no wallet changes necessary" block size bump, which we've been making progress on over the past year, including even after conclusion of the original agreement (there is currently a testnet for an incomplete version running).

http://np.reddit.com/r/Bitcoin/comments/5gcg98/will_there_be_no_capacity_improvements_for_the/darfdyg/

Is their block size bump code significantly different to Satoshi's block size bump code?

It can be phased in, like:

if (blocknumber > 115000)
    maxblocksize = largerlimit

It can start being in versions way ahead, so by the time it reaches that block number and goes into effect, the older versions that don't have it are already obsolete.

When we're near the cutoff block number, I can put an alert to old versions to make sure they know they have to upgrade.

[reee]

what % of block will be necessary to do the hard fork?

[ubitcoin]

The thing i'm concerned about is the future. A 2MB hardfork is only a temporary fix, and are we going to do a hard fork every year or two? That's just stupid.

No. This is not stupidity. There must be a very big requirement of managing equilibrium between bitcoin transaction fees and competition to pick transactions by miners.

A sudden large block size will lead to less competition among miners as one single miner will pick more number of transactions so people will start using very less transaction fees.

As long as block sizes are limited, people will use optimum transaction fees to make their transaction to be included competitively in upcoming blocks. From this miners will benefit and will show interest to continue their mining businesses.

[OROBTC]

...

Well, apparently something has to be done, or at some point my BTC (just sitting around in various places, smile,,,) has to be done, oe else whatever...  It seems that the BTC system is awfully close to running at capacity (IIUC, which of course I may not), and any growth will slow us down further.

If the "Big Miners" got together and raised fees (say, to BTC0.0005, or 0.05%, whatever) would that help?  Obviously micropayments would suffer.  But, I want an efficient system and am willing to pay a tiny bit more for that.

[yayayo]

Good to seem them trying to accommodate the larger crowd.

[...]

It's not at all clear, which is the larger crowd. The whole blocksize drama was initiated by an army of sockpuppets and shills of Hearn and Ver.

As far as I understood this could be a compromise with some of the Chinese mining pools, who demanded bigger blocks to make more profit. Hopefully I'm wrong and this rumor does not materialize. I'm not happy with a blocksize increase this early. It's premature, because SegWit has just been released for voting and fees are still too low to root out transaction spam. SegWit effectively doubles the amount of storage space, so there is no urgency to increase the blocksize.

A healthy fee market and network decentralization are far more important than capacity alone.

ya.ya.yo!

[franky1]

Good to seem them trying to accommodate the larger crowd.

[...]

It's not at all clear, which is the larger crowd. The whole blocksize drama was initiated by an army of sockpuppets and shills of Hearn and Ver.

As far as I understood this could be a compromise with some of the Chinese mining pools, who demanded bigger blocks to make more profit. Hopefully I'm wrong and this rumor does not materialize. I'm not happy with a blocksize increase this early. It's premature, because SegWit has just been released for voting and fees are still too low to root out transaction spam. SegWit effectively doubles the amount of storage space, so there is no urgency to increase the blocksize.

A healthy fee market and network decentralization are far more important than capacity alone.

ya.ya.yo!

you do know hearn is part of the blockstream army.. it was subdefuge.. blockstream and hearn are both in the bankers pockets.

as for ver.. sorry but 70-75% of hashrate has not said yes to segwit.. ver only accounts for 9% not 70%..
seems your the one trying to twist things. please atleast be honest. if you cant be honest atleast show stats.. dont just creatively speculate to twist things. segwit is at 25% not 91%.. so its not just ver saying no to segwit.

research harder, your rhetoric sounds like an echo of other peoples spoonfed propaganda. rather than independent insight/understanding

lastly even the segwit fanboys ALSO want more blocksize too, they just argue more about WHO will do it and less about HOW. its not a left or right debate. it should be a middleground where everyone gets what they want.