F2Pool「魚池」🐟

[macbook-air]

Policy change announcement: We support the hard fork effort to increase the max block size to 2MB. Seg-wit may be deployed together in this hard fork if it can be ready in time, or it can be merged later. Non-controversial features in the hard fork wishlist, if it does not delay the hard fork process, can be deployed at the same time. The hard fork should be implemented in Core, eventually. “Bitcoin” Classic, which despite was born on the same day that XT dies, is an attempt that could make the hard fork happen sooner. We welcome Classic. We are going to cease support for FSS-RBF after upgrading to version 0.12, some time in the next few weeks. We may not implement the opt-in RBF feature. We believe that we should do everything we can do to make 0-conf transactions as secure as possible. We do not believe the concept of fee market.

[kano]

Policy change announcement: We support the hard fork effort to increase the max block size to 2MB. Seg-wit may be deployed together in this hard fork if it can be ready in time, or it can be merged later. Non-controversial features in the hard fork wishlist, if it does not delay the hard fork process, can be deployed at the same time. The hard fork should be implemented in Core, eventually. “Bitcoin” Classic, which despite was born on the same day that XT dies, is an attempt that could make the hard fork happen sooner. We welcome Classic. We are going to cease support for FSS-RBF after upgrading to version 0.12, some time in the next few weeks. We may not implement the opt-in RBF feature. We believe that we should do everything we can do to make 0-conf transactions as secure as possible. We do not believe the concept of fee market.

Get someone who knows English well to translate this for you.

Your wording implies you are going to try to force everyone to accept a hard fork - which of course you are not in charge of bitcoin so making such a statement would be foolish.

If instead you mean the standard miner voting for a change using the core rules, then that of course is appropriate.

[p3yot33at3r]

Policy change announcement: We support the hard fork effort to increase the max block size to 2MB. Seg-wit may be deployed together in this hard fork if it can be ready in time, or it can be merged later. Non-controversial features in the hard fork wishlist, if it does not delay the hard fork process, can be deployed at the same time. The hard fork should be implemented in Core, eventually. “Bitcoin” Classic, which despite was born on the same day that XT dies, is an attempt that could make the hard fork happen sooner. We welcome Classic. We are going to cease support for FSS-RBF after upgrading to version 0.12, some time in the next few weeks. We may not implement the opt-in RBF feature. We believe that we should do everything we can do to make 0-conf transactions as secure as possible. We do not believe the concept of fee market.

Get someone who knows English well to translate this for you.

Your wording implies you are going to try to force everyone to accept a hard fork - which of course you are not in charge of bitcoin so making such a statement would be foolish.

If instead you mean the standard miner voting for a change using the core rules, then that of course is appropriate.

Ditto - the way it's worded makes it sound like some kind of aggressive Bitcoin takeover bid......or is it? 

[macbook-air]

Policy change announcement: We support the hard fork effort to increase the max block size to 2MB. Seg-wit may be deployed together in this hard fork if it can be ready in time, or it can be merged later. Non-controversial features in the hard fork wishlist, if it does not delay the hard fork process, can be deployed at the same time. The hard fork should be implemented in Core, eventually. “Bitcoin” Classic, which despite was born on the same day that XT dies, is an attempt that could make the hard fork happen sooner. We welcome Classic. We are going to cease support for FSS-RBF after upgrading to version 0.12, some time in the next few weeks. We may not implement the opt-in RBF feature. We believe that we should do everything we can do to make 0-conf transactions as secure as possible. We do not believe the concept of fee market.

Get someone who knows English well to translate this for you.

Your wording implies you are going to try to force everyone to accept a hard fork - which of course you are not in charge of bitcoin so making such a statement would be foolish.

If instead you mean the standard miner voting for a change using the core rules, then that of course is appropriate.

Instead of bashing me continuously, should you please consider to do something useful to end the debate? I want the stupid debate to come to an end.

[CodeShark]

Policy change announcement: We support the hard fork effort to increase the max block size to 2MB. Seg-wit may be deployed together in this hard fork if it can be ready in time, or it can be merged later. Non-controversial features in the hard fork wishlist, if it does not delay the hard fork process, can be deployed at the same time. The hard fork should be implemented in Core, eventually. “Bitcoin” Classic, which despite was born on the same day that XT dies, is an attempt that could make the hard fork happen sooner. We welcome Classic. We are going to cease support for FSS-RBF after upgrading to version 0.12, some time in the next few weeks. We may not implement the opt-in RBF feature. We believe that we should do everything we can do to make 0-conf transactions as secure as possible. We do not believe the concept of fee market.

Get someone who knows English well to translate this for you.

Your wording implies you are going to try to force everyone to accept a hard fork - which of course you are not in charge of bitcoin so making such a statement would be foolish.

If instead you mean the standard miner voting for a change using the core rules, then that of course is appropriate.

Instead of bashing me continuously, should you please consider to do something useful to end the debate? I want the stupid debate to come to an end.

In Hong Kong you were directly introduced to some of the world's foremost experts and most knowledgeable people in this technology - and these experts were asked to make a decision. The overwhelming majority of them did make a decision (https://bitcoincore.org/en/2015/12/21/capacity-increase/). Then some other people who lack the knowledge, experience, and credentials decided to fork the github repo, do a rebrand, and try to sell it as a competitor.

Don't fall for this trap...the debate is over.

[windpath]

Policy change announcement: We support the hard fork effort to increase the max block size to 2MB. Seg-wit may be deployed together in this hard fork if it can be ready in time, or it can be merged later. Non-controversial features in the hard fork wishlist, if it does not delay the hard fork process, can be deployed at the same time. The hard fork should be implemented in Core, eventually. “Bitcoin” Classic, which despite was born on the same day that XT dies, is an attempt that could make the hard fork happen sooner. We welcome Classic. We are going to cease support for FSS-RBF after upgrading to version 0.12, some time in the next few weeks. We may not implement the opt-in RBF feature. We believe that we should do everything we can do to make 0-conf transactions as secure as possible. We do not believe the concept of fee market.

Thank you for taking action.

[cypherdoc]

Policy change announcement: We support the hard fork effort to increase the max block size to 2MB. Seg-wit may be deployed together in this hard fork if it can be ready in time, or it can be merged later. Non-controversial features in the hard fork wishlist, if it does not delay the hard fork process, can be deployed at the same time. The hard fork should be implemented in Core, eventually. “Bitcoin” Classic, which despite was born on the same day that XT dies, is an attempt that could make the hard fork happen sooner. We welcome Classic. We are going to cease support for FSS-RBF after upgrading to version 0.12, some time in the next few weeks. We may not implement the opt-in RBF feature. We believe that we should do everything we can do to make 0-conf transactions as secure as possible. We do not believe the concept of fee market.

Classic is doing everything it can to please you and minimize your risk with it's hard fork to 2MB.  and they have Gavin and Jeff onboard.  SW & RBF will facilitate LN payment channels that compete with your tx fees that you will come to rely on as block reward diminishes.  you will feel this pain come July with the halving.  SW, at it's theoretical maximum, will force you to transmit 4MB worth of data for only a 1.75MB maximum gain in tx's and associated fees.  how does that help you vs a simple blocksize increase to 4MB worth of pure tx's and fees?

[kano]

Policy change announcement: We support the hard fork effort to increase the max block size to 2MB. Seg-wit may be deployed together in this hard fork if it can be ready in time, or it can be merged later. Non-controversial features in the hard fork wishlist, if it does not delay the hard fork process, can be deployed at the same time. The hard fork should be implemented in Core, eventually. “Bitcoin” Classic, which despite was born on the same day that XT dies, is an attempt that could make the hard fork happen sooner. We welcome Classic. We are going to cease support for FSS-RBF after upgrading to version 0.12, some time in the next few weeks. We may not implement the opt-in RBF feature. We believe that we should do everything we can do to make 0-conf transactions as secure as possible. We do not believe the concept of fee market.

Get someone who knows English well to translate this for you.

Your wording implies you are going to try to force everyone to accept a hard fork - which of course you are not in charge of bitcoin so making such a statement would be foolish.

If instead you mean the standard miner voting for a change using the core rules, then that of course is appropriate.

Instead of bashing me continuously, should you please consider to do something useful to end the debate? I want the stupid debate to come to an end.

You've still not answered the question.
Pretty simple question actually.

This easier to understand?
"Are you trying to control bitcoin and force your decisions on everyone else, or are you using the standard miner voting for a change using the core rules?"

--

Going to 2MB seems rather pointless with a hard fork since, if it is necessary, then we'll need another one again not far down the road.
I would have thought someone was gonna be smart, and pick a more useful number, or code a miner voting method to adjust it so as to avoid simply putting the issue off to the near future yet again ...

However, my pool will gain from this change.
My pool can process block changes faster than any non SPV pool.
My pool averages much larger block sizes than any other pools (other than CKPool solo)
This change will simply mean we'll make larger blocks and get more txn fees.
It will also mean you will get more orphans.

[windpath]

Again, thank you for making a choice to support larger blocks, don't be bullied and manipulated.

[brg444]

SW, at it's theoretical maximum, will force you to transmit 4MB worth of data for only a 1.75MB maximum gain in tx's and associated fees.  how does that help you vs a simple blocksize increase to 4MB worth of pure tx's and fees?

This is a complete lie and misfabrication.

macbook-air please, if you are wang chun, do consult with the Core devs.

Segwit is the most responsible way to end this dead lock for now and will provide for ample time and headroom to optimize the propagation problems so that a 2MB hard fork may go through with absolute network consensus down the road.

There is still clear dissent amongst users about a contentious hard fork and while miners may agree it would create a bad precedent for you to force this on the community. 

[windpath]

SW, at it's theoretical maximum, will force you to transmit 4MB worth of data for only a 1.75MB maximum gain in tx's and associated fees.  how does that help you vs a simple blocksize increase to 4MB worth of pure tx's and fees?

This is a complete lie and misfabrication.

macbook-air please, if you are wang chun, do consult with the Core devs.

Segwit is the most responsible way to end this dead lock for now and will provide for ample time and headroom to optimize the propagation problems so that a 2MB hard fork may go through with absolute network consensus down the road.

There is still clear dissent amongst users about a contentious hard fork and while miners may agree it would create a bad precedent for you to force this on the community. 

Segwit is great, but clearly it has not ended the deadlock. 2MB now followed by core roadmap is an amicable compromise.

[brg444]

SW, at it's theoretical maximum, will force you to transmit 4MB worth of data for only a 1.75MB maximum gain in tx's and associated fees.  how does that help you vs a simple blocksize increase to 4MB worth of pure tx's and fees?

This is a complete lie and misfabrication.

macbook-air please, if you are wang chun, do consult with the Core devs.

Segwit is the most responsible way to end this dead lock for now and will provide for ample time and headroom to optimize the propagation problems so that a 2MB hard fork may go through with absolute network consensus down the road.

There is still clear dissent amongst users about a contentious hard fork and while miners may agree it would create a bad precedent for you to force this on the community.  

Segwit is great, but clearly it has not ended the deadlock. 2MB now followed by core roadmap is an amicable compromise.

It has not because people have largely misunderstood it and promoted false information around it.

Creating urgency under the pretense of a "crisis" is NOT an amicable compromise, especially with the way the Core developers are being alineated from the process.

A soft fork rollout of segwit can happen much faster than a hard fork and provide immediate increase in the throughput provided major wallet providers get on board.

It is absolutely necessary that miners reconsider their position since clearly there has been a lack of communication as to the benefits of seg wit and its minimal downside vs. the socio-economic mess that would ensue following a precipitated hard fork.

[windpath]

SW, at it's theoretical maximum, will force you to transmit 4MB worth of data for only a 1.75MB maximum gain in tx's and associated fees.  how does that help you vs a simple blocksize increase to 4MB worth of pure tx's and fees?

This is a complete lie and misfabrication.

macbook-air please, if you are wang chun, do consult with the Core devs.

Segwit is the most responsible way to end this dead lock for now and will provide for ample time and headroom to optimize the propagation problems so that a 2MB hard fork may go through with absolute network consensus down the road.

There is still clear dissent amongst users about a contentious hard fork and while miners may agree it would create a bad precedent for you to force this on the community.  

Segwit is great, but clearly it has not ended the deadlock. 2MB now followed by core roadmap is an amicable compromise.

It has not because people have largely misunderstood it and promoted false information around it.

Creating urgency under the pretense of a "crisis" is NOT an amicable compromise, especially with the way the Core developers are being alineated from the process.

A soft fork rollout of segwit can happen much faster than a hard fork and provide immediate increase in the throughput provided major wallet providers get on board.

It is absolutely necessary that miners reconsider their position since clearly there has been a lack of communication as to the benefits of seg wit and its minimal downside vs. the socio-economic mess that would ensue following a precipitated hard fork.

Core alienated themselves from the process by refusing to compromise, segwit while awesome is a highly complex change requiring not only nodes, but every service and software that parses the blockchain to upgrade their proprietary software... It may not be as fast to roll out as you predict...

[brg444]

Core alienated themselves from the process by refusing to compromise, segwit while awesome is a highly complex change requiring not only nodes, but every service and software that parses the blockchain to upgrade their proprietary software... It may not be as fast to roll out as you predict...

Sound engineering is not made under populist pressure. There urgency of the situation is fabricated and there are no compromise to be made except maybe to indicate an intent to hard fork down the road.

The SegWit testnet is live meaning everyone can start learning and getting their platform to support it once it's ready for release.

Bitcoin Classic proposes to hard fork the network in a mere 3 months with a FOUR WEEKS grace periods for nodes.

This is plainly irresponsible and there certainly are NO justification to force through such a precipitated roll out.

We risk losing a significant fraction of the network nodes which will cause great damage to the decentralization of Bitcoin.

Moreover such consensus change should not happen without 95% miner support. Otherwise it should be considered an attack by the majority miners and an abuse of their position.

If, the network is to go through a hard fork then please have it happen in an orderly fashion so as to not cast Bitcoin in a bad light once again.

[cypherdoc]

SW, at it's theoretical maximum, will force you to transmit 4MB worth of data for only a 1.75MB maximum gain in tx's and associated fees.  how does that help you vs a simple blocksize increase to 4MB worth of pure tx's and fees?

This is a complete lie and misfabrication.

macbook-air please, if you are wang chun, do consult with the Core devs.

Segwit is the most responsible way to end this dead lock for now and will provide for ample time and headroom to optimize the propagation problems so that a 2MB hard fork may go through with absolute network consensus down the road.

There is still clear dissent amongst users about a contentious hard fork and while miners may agree it would create a bad precedent for you to force this on the community. 

please point out the technical error.

[BldSwtTrs]

SW, at it's theoretical maximum, will force you to transmit 4MB worth of data for only a 1.75MB maximum gain in tx's and associated fees.  how does that help you vs a simple blocksize increase to 4MB worth of pure tx's and fees?

This is a complete lie and misfabrication.

macbook-air please, if you are wang chun, do consult with the Core devs.

Segwit is the most responsible way to end this dead lock for now and will provide for ample time and headroom to optimize the propagation problems so that a 2MB hard fork may go through with absolute network consensus down the road.

There is still clear dissent amongst users about a contentious hard fork and while miners may agree it would create a bad precedent for you to force this on the community.  

If Core folks agree that a contentious hard fork might be bad for Bitcoin, then why not comply to the will of the ecosystem and tell every body to stop using Core and switch to Classic without making Core run alongside Classic.

It would be classy, responsible and coherent. What a beautiful precedent this would become!

[inca]

SW, at it's theoretical maximum, will force you to transmit 4MB worth of data for only a 1.75MB maximum gain in tx's and associated fees.  how does that help you vs a simple blocksize increase to 4MB worth of pure tx's and fees?

This is a complete lie and misfabrication.

macbook-air please, if you are wang chun, do consult with the Core devs.

Segwit is the most responsible way to end this dead lock for now and will provide for ample time and headroom to optimize the propagation problems so that a 2MB hard fork may go through with absolute network consensus down the road.

There is still clear dissent amongst users about a contentious hard fork and while miners may agree it would create a bad precedent for you to force this on the community. 

please point out the technical error.

Crickets!

[Zarathustra]

SW, at it's theoretical maximum, will force you to transmit 4MB worth of data for only a 1.75MB maximum gain in tx's and associated fees.  how does that help you vs a simple blocksize increase to 4MB worth of pure tx's and fees?

macbook-air please, if you are wang chun, do consult with the Core devs.

LOL. The game is over for Blockstream Core, brg. More than 70 percent support the hardfork already. The sooner you capitulate the better for your health.

[brg444]

SW, at it's theoretical maximum, will force you to transmit 4MB worth of data for only a 1.75MB maximum gain in tx's and associated fees.  how does that help you vs a simple blocksize increase to 4MB worth of pure tx's and fees?

This is a complete lie and misfabrication.

macbook-air please, if you are wang chun, do consult with the Core devs.

Segwit is the most responsible way to end this dead lock for now and will provide for ample time and headroom to optimize the propagation problems so that a 2MB hard fork may go through with absolute network consensus down the road.

There is still clear dissent amongst users about a contentious hard fork and while miners may agree it would create a bad precedent for you to force this on the community.  

please point out the technical error.

First not one miner is forced to mine anything whatsoever.

They will pick whatever transactions they wish and will be incentivized to pick Seg Witness tx since they will come with more fees per bytes.

As for the 4MB you present it in a disingenuous way that propose the maximum gains necessarily translates to a 4MB block.

Here's how it actually works:

That would be 1.6MB and 2MB of total actual data if you hit the limits with real transactions, so it's more like a 1.8x increase for real transactions afaics, even with substantial use of multisig addresses.

The 4MB consensus limit could only be hit by having a single trivial transaction using as little base data as possible, then a single huge 4MB witness. So people trying to abuse the system have 4x the blocksize for 1 block's worth of fees, while people using it as intended only get 1.6x or 2x the blocksize... That seems kinda backwards.

[cypherdoc]

SW, at it's theoretical maximum, will force you to transmit 4MB worth of data for only a 1.75MB maximum gain in tx's and associated fees.  how does that help you vs a simple blocksize increase to 4MB worth of pure tx's and fees?

This is a complete lie and misfabrication.

macbook-air please, if you are wang chun, do consult with the Core devs.

Segwit is the most responsible way to end this dead lock for now and will provide for ample time and headroom to optimize the propagation problems so that a 2MB hard fork may go through with absolute network consensus down the road.

There is still clear dissent amongst users about a contentious hard fork and while miners may agree it would create a bad precedent for you to force this on the community. 

please point out the technical error.

First not one miner is forced to mine anything whatsoever. They will pick whatever transactions they wish and will be incentivized to pick Seg Witness tx since they will come with more fees per bytes.

As for the 4MB you present it in a disingenuous way that propose the maximum gains necessarily translates to a 4MB block.

Here's how it actually works:

That would be 1.6MB and 2MB of total actual data if you hit the limits with real transactions, so it's more like a 1.8x increase for real transactions afaics, even with substantial use of multisig addresses.

The 4MB consensus limit could only be hit by having a single trivial transaction using as little base data as possible, then a single huge 4MB witness. So people trying to abuse the system have 4x the blocksize for 1 block's worth of fees, while people using it as intended only get 1.6x or 2x the blocksize... That seems kinda backwards.

why is that link unclickable?