F2Pool「魚池」🐟

[brg444]

why is that link unclickable?
[/quote]

http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011869.html

[cypherdoc]

why is that link unclickable?

http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011869.html
[/quote]

that link proves my pt.  SW is not a good scaling solution. 

[brg444]

why is that link unclickable?

http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011869.html

that link proves my pt.  SW is not a good scaling solution. 
[/quote]

It provides effectively the same increase as a 2MB increase without the hassle of a hard fork.

It is live on testnet.

It avoids significant economic damages to the ecosystem brought about by uncertainty of a clearly contentious hard fork.

[cypherdoc]

why is that link unclickable?

http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011869.html

that link proves my pt.  SW is not a good scaling solution.  

It provides effectively the same increase as a 2MB increase without the hassle of a hard fork.

It is live on testnet.

It avoids significant economic damages to the ecosystem brought about by uncertainty of a clearly contentious hard fork.
[/quote]

Just a quick clarification on SegWit and block size.

Based on current transaction type distribution in an average mined block, SegWit will give you a 1.6/1.7 MB block "size" if and only if 100% of the network upgraded (x4 gain reacheable only for 3-3 multisig txs).

Just take into consideration a likely / optimistic scenario:

- SegWit deployed on May 2016
- 2 month after deployment SoftFork activation will be triggered (95% miners adoption)
- 50% network (all kind of full nodes) upgrade after a year.

if all of the above are satisfied SegWit will bring max block size to 1.35 on Jun/Jul 2017.

https://bitco.in/forum/threads/gold-collapsing-bitcoin-up.16/page-251#post-9463

[sickpig]

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. 

you could find reassuring that chypherdoc number are supported even by the official "Capacity Increase Faq", see:

https://bitcoin.org/en/bitcoin-core/capacity-increases-faq#segwit-size

for the sake of clarity:

According to some calculations performed by Anthony Towns, a block filled with standard single-signature P2PKH transactions would be about 1.6MB and a block filled with 2-of-2 multisignature transactions would be about 2.0MB.

to that add that you could ave 4MB virtual block size only if a block is completely filled by 3-of-3 txs.

Based on such actual data and the avg block txs compositions SegWit will give s scaling factor of ~1.75x once the soft-fork will be adopted by 100% of the network.

This is a possible scenario:

- SegWit deployed on april/may 2016
- Soft-Fork triggers in Jun/July 2016
- 50% of adoption after one year

if all the above are valid that means that you will have 1.35MB  vitual max block size by june/july 2017.



 

[brg444]

- SegWit deployed on May 2016
- 2 month after deployment SoftFork activation will be triggered (95% miners adoption)
- 50% network (all kind of full nodes) upgrade after a year.

if all of the above are satisfied SegWit will bring max block size to 1.35 on Jun/Jul 2017. [/i]

https://bitco.in/forum/threads/gold-collapsing-bitcoin-up.16/page-251#post-9463

There is clear economic incentives for all nodes involved with significant volumes of transactions to upgrade (less fees paid in agreggate). The adoption metric is not to be evaluated on a per-node basis.

As far as these large wallet providers are concerned the roll out could be immediate following the release of Seg Wit.

So the scenario above is far from "optimistic"

[cypherdoc]

this from Sergio Lerner, prominent Bitcoin core dev. from BitcoinClassic Slack Channel:


sergiodemianlerner 5:29 PM Regarding SegWit, I don't know if you have actually looked at the code but the amount of code changed, including consensus code, is huge. (maybe ~500 lines). I think such change has never been attempted in the history of Bitcoin. We cannot just say lightly that a couple of weeks after the 2mb hard-fork we're going to deploy segwit. That code needs months of review. Also I'm against the complexity of segwit as a soft-fork (probably requires 200 additional lines of code of consensus critical code). Segwit almost prevents consensus-compatible re-implementations of Bitcoin in other languages.

[Zarathustra]

- SegWit deployed on May 2016
- 2 month after deployment SoftFork activation will be triggered (95% miners adoption)
- 50% network (all kind of full nodes) upgrade after a year.

if all of the above are satisfied SegWit will bring max block size to 1.35 on Jun/Jul 2017. [/i]

https://bitco.in/forum/threads/gold-collapsing-bitcoin-up.16/page-251#post-9463

There is clear economic incentives for all nodes involved with significant volumes of transactions to upgrade (less fees paid in agreggate). The adoption metric is not to be evaluated on a per-node basis.

As far as these large wallet providers are concerned the roll out could be immediate following the release of Seg Wit.

So the scenario above is far from "optimistic"

That non-consensual ('soft' fork) scaling 'solution' is a joke in the year of the halving. That's why the miners are finally acting.

[cypherdoc]

looks pretty good to me:

[windpath]

looks pretty good to me:

Well said. Looking forward to both a 2MB hard cap and segwit!

[cypherdoc]

i kinda liked this one from Aquentin on Reddit this morning:

"I am not sure why you are obsessed with core, why you wish to ask them for permission and why you are even begging them when core does not exist anymore. There is no core without two of the most seniour developers - Gavin and Jeff. Core is a was and what is now called core is a completely different team with a vision that is fully opposed to keeping bitcoin open and accessible to all or easy to use.

The current core team instead wishes to create walled gardens through LN bringing in middle men with their gateways and checkins taking away fees from miners and taking away the easy usability from users all for the pleasure of users paying them a fee.

Moreover, the company currently in control of core has the same business model as R3. They plan to create private blockchains - like liquid - and sell them for a fee to banks, businesses, companies, or even consumers. That is their business model is to create bitranets - similiar to intranets - to compete with the open ledger that is bitcoin. As the interests of open bitcoin and bitranet often are in competition, a team offering such bitranets and in control of bitcoin will necessarily wish to make the open ledger less competitive.

Ergo RBF which kills 0conf transactions while in their liquid bitranet they boast about 0confs as a feature - ergo keeping the open chain from scaling so that the bitranets win by default, etc.

TL;dr There is no core any longer. What was core is now divided into classic and core. Your choice therefore is between a team which abides by the wishes of users, listens to them, shares satoshi's vision and more importantly shares the vision of keeping bitcoin open and accessible to all, a world wide ledger that can be used for smart contracts and a million other things - or you can choose core which is killing 0conf transactions, refuses to listen to users and is controlled by a company that is in direct competition with bitcoin's interest of being open and accessible to all.

The users have made their choice - so have the most seniour developers. The miners signed 8mb in blood so to speak, then asked for bip100 - and core simply ignored you. Now you keep begging them and keep asking for permission... not sure when you'll figure out that not only do they not care about you, but they publicly state that you do not matter at all, yet you keep begging them and asking for permission..."

https://www.reddit.com/r/btc/comments/414qxh/49_of_bitcoin_mining_pools_support_bitcoin/cz0ceao

[cypherdoc]

and TBH, Core doesn't even have Greg anymore.

[brg444]

To all regular posters here I apologize for having attracted the trolls.

[cypherdoc]

To all regular posters here I apologize for having attracted the trolls.

show them who the real troll is brg444.  go ahead and ad hom and dox me again, like you usually do.  everybody already knows my real identity and that i don't have any financial conflicts in this blocksize issue.  i argue from my heart and for the good of Bitcoin.  you, otoh, continue to hide behind your anonymity and censored forums.  given that we're this deep and long into the debate, and given your propensity for trolling, ad hom, and overall viciousness, you should be required to reveal exactly who you are so that we all can evaluate whether you have a financial conflict of interest or not.  anyone who has argued so vigorously and unreasonably as you over this last year needs to show their cards.

how about it?

[molecular]

To all regular posters here I apologize for having attracted the trolls.

lol

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

Since this thread is about F2Pool and not about people's opinions of bitcoin dev politics ...
(I'd not be surprised if someone didn't delete all the past 2 pages )

I'll repost the question that is directed at F2Pool

Again:
"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?"

Edit: and the reason why this is also a valid question is that F2Pool has already once in the past done a 51% control change on an alt-coin ...

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

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.

Since this thread is about F2Pool and not about people's opinions of bitcoin dev politics ...
(I'd not be surprised if someone didn't delete all the past 2 pages )

I'll repost the question that is directed at F2Pool

Again:
"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?"

Edit: and the reason why this is also a valid question is that F2Pool has already once in the past done a 51% control change on an alt-coin ...

While not directed at me, I'll reply anyway...

Your choice of words, Kano, is inappropriate for what they are announcing.

Particularly the words "control" and "force" are completely out of place.

It's more an announcement of "support" for a "community" "choice".

If F2Pool could "control" or "force" the bitcoin community to do anything I think we'd have much bigger problems. Further I'd argue that you specifically chose those words to exploit a cultural and language difference, and it is both manipulative and slimy...

[kano]

...
While not directed at me, I'll reply anyway...

Your choice of words, Kano, is inappropriate for what they are announcing.

Particularly the words "control" and "force" are completely out of place.

It's more an announcement of "support" for a "community" "choice".

If F2Pool could "control" or "force" the bitcoin community to do anything I think we'd have much bigger problems. Further I'd argue that you specifically chose those words to exploit a cultural and language difference, and it is both manipulative and slimy...

1) Go fuck yourself

2) I already stated that he needed to get someone with better English to clarify his meaning.

3) He didn't bother to.

4) As I stated above, F2Pool has already done this to an altcoin - force a change without getting agreement.

[windpath]

.....

4) As I stated above, F2Pool has already done this to an altcoin - force a change without getting agreement.

As we have addressed 2 & 3, I'll take 1 & 4.

1. 😳

4. This is not an altcoin, this is Bitcoin.

[d57heinz]

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.

Since this thread is about F2Pool and not about people's opinions of bitcoin dev politics ...
(I'd not be surprised if someone didn't delete all the past 2 pages )

I'll repost the question that is directed at F2Pool

Again:
"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?"

Edit: and the reason why this is also a valid question is that F2Pool has already once in the past done a 51% control change on an alt-coin ...

After reading this post..

"Posted by Ma_Ya
I too would like to respond briefly to both of your questions.
(1) In theory they should be able to easily deal with sizes as large as 100MB. Blocks of this size could be transmitted in minutes with even a standard home connection and this time is significantly reduced for miners who maintain specialized high-speed connections. Ultimately there is no firewall blocking transmission between pools in China and in any case the sum of China’s hashing power is already over 51%.
(2) If you understood the principles of mining and what I said before, you wouldn’t ask this question. First of all, China’s mining pools are not in any rush to broadcast the nonce of a successfully mined block to nodes across the globe. It only needs to be received by several of the larger pools in China. This is because once it is received by several large pools in China, you’ve already reached more than half [of available hashing power], which is the same as achieving global consensus. When you look at it like this, Chinese miners should actually want there to be interference from the GFW to hinder Western pools. Also, you mentioned setting up a node outside of China and reconstituting [blocks] there, but in reality you wouldn’t save much time that way. Think about it: what is the big difference between transmitting 1MB or 2MB and a few KB? It's probably around nothing more than one second. 10 minutes and 1 second - that’s a factor of 600:1 which is trivial when you take into account the randomness of mining itself. Furthermore your proposition is only advantageous for Western pools and provides no benefit to Chinese pools."

Kano i'm not sure they are worried at all about getting the blocks out to us.. Like i said it will be advantageous for larger blocks as they can be working on new ones long before we will even see it. let alone the time it will take us to verify and pass along.   I realise that your pool is setup as optimal as one can get it but its not large enough to rail back to back blocks like the chinese farms can. So what happens when they start their own fork again because we cant process the new blocks fast enough. It will be like they are the only ones hashing as we will all be working on old blocks then the diff will start doing some funny things! as well as the time to find blocks will go crazy as well..

i too am worried they are trying to take it over. larger blocks will only help to facilitate this.. Just for the record im for increasing the block size and seeing bitcoin grow.. just  i think there is some technological hurdles that have to be addressed prior to increase of siZe

here is the article

https://www.reddit.com/r/btc/comments/41dizq/the_rbtc_china_dispatch_episode_3_block_size/

Best regards
d57heinz