Topic: F2Pool「魚池」🐟 - page 11. (Read 169420 times)

https://github.com/luke-jr/bitcoin/commit/8d3a84c242598ef3cdc733e99dddebfecdad84a6

Keccak?

this is the worst idea I've seen for BTC, switching algo as if it were some altcoin....

wow, core dev really does care about you.  or do they?:

https://np.reddit.com/r/Bitcoin/comments/41aocn/httpsbitcoinorgenbitcoincorecapacityincreases_why/cz0z9ym

https://github.com/bitcoinclassic/bitcoinclassic/pull/6

web and stratum are on different systems. unless you experience frequent reconnect or high rejects, it should not affect your mining revenue.

Where is the complete list of signers ? Cant find it "below" in the link...

Edit : seems that this is not what core is planning at all. It is what core should have decided.. (as by the title)

The problem with this is that the Core Devs don't actually support Adam Back's 2-4-8. Hell, not even all Blockstream employees support it. That entire part of the announcement that should have been is vapor-ware.

Hi guys, I have question about this pool, I have a problem to open a page to this this pool seems like the ping to this pool is loosing some times does it going to effect my miners if i connect to this pool ?

Sorry for my English.

Can we get this translated into Chinese for the benefit of f2pool, before they do something foolish and regrettable?

https://t.co/3IY2PKIjsX

The Scaling Announcement Bitcoin Core Should Have Made

By the Bitcoin Core Developers (a complete list of signers can be found below)

We’re here to talk about scaling and the roadmap we’ve set for Bitcoin Core.

As with any roadmap, we’ve heard your feedback and we want to continue to hear it, so please keep it coming.

We’ve had extensive conversations with all of you — from the miners to the wallets and exchanges to everyday community members — and want to make it clear that we’ve listened to everything you have to say with regards to the growth of the bitcoin blockchain and evolution of Bitcoin core.

We feel we have a fair grasp of what your needs are and are well-equipped to examine them against the constraints of the Bitcoin network and the software that powers it, and determine how best we can make everyone happy and ensure that the system is fully operational and is able to scale.

Part of this work means looking at a variety of increases to the Bitcoin block size and doing extensive analysis and testing to determine the effects that each of these increases would have.

As many of you may be aware, we have to be aware of two facts:

    Increasing the capacity of the bitcoin blockchain is critical. Bitcoin needs to grow and support more and more users, and each of these users needs to have access to relatively low transaction fees.
    Block size increases should not be taken lightly and it is imperative they be carefully tested beforehand. Block size increases impact many aspects of the Bitcoin network and do have the potential to reduce decentralization and network stability.

It is clear that both of these are largely in conflict with one another, and so they will have to be weighed against one another and a compromise will need to be reached.

Just because we have the need to support certain levels of usage, doesn’t mean we should dare to compromise either the stability of the system or the level of decentralization that makes Bitcoin so unique and powerful. And just because we have a fear of the effects of block size increases does not mean that we should fail to subject such increases to real world tests and do everything we can to increase the system-wide capacity.

Bitcoin will scale, but it will require a combination of efforts and it will be a gradual process. So we need to come together and agree on the tradeoffs we’re making and we need to be patient.

Last, we need to be civil and respectful of one another and make sure we all come together to push Bitcoin forward.

We’ve done some extensive real world testing on many global test beds, including Princeton University’s Planet Lab, the largest in the world. From this we’ve concluded that 8MB blocks are simply too large to be considered safe for the network at this point in time, considering the current global bandwidth levels.

So while many of us may want to shoot for the stars, we must agree that it is more important to ensure that the network remains healthy and strong.

At the same time, it is important that we push for an increase that is as big as we can safely handle, and we believe that Adam Back’s 2–4–8 proposal that scales the block size to 4MB after 2 years and then to 8MB after 4 years is the plan of action that is the most ambitious while still being safe.

In addition, it seems we can do even better in terms of performance by sticking with 2–4–8 but allowing non-fully-validating nodes to ignore approximately half of this data. This would be a big improvement that would alleviate the pressure that we’ll be putting nodes by scaling the block size. The improvement is being called Segregated Witness and involves separating signatures out from the main block and putting them into a Merkle tree that only fully-validating nodes have to see.

We want to roll this plan out slowly and carefully, and we believe the best course of action is to first roll out Segregated Witness so we can get a quick win on an approximately 2x data capacity increase. This would involve removing signatures from the main portion of blocks, which would double the number of transactions that can be fit into the current 1MB limit (this means the effective limit would be 2MB).

Next, we plan on shifting gears to prepare for the hard fork that would put Adam Back’s 2–4–8 proposal into place alongside Segregated Witness, where the limits would be scaled to account for the optimizations made by Segregated Witness (the limits would be approximate limits that would continue to include signature data).

Beyond this, in order to prepare for the two bumps over the next 4 years and ensure that orphan rates don’t increase, we’re working on integrating efficient relay techniques like the relay network and IBLT, so that most block data is disseminated throughout the network even before a block is found.

Further, we’ll be working hard on preparing for the hard fork that will need to come with the second increase. We’ve bought a bit of time considering that the cleverness of Segregated Witness will allow us to do the first doubling with just a soft fork, which will reduce risk in the short run. And of course, this hard fork should not be taken lightly as hard forks in general do pose a significant risk of network fracturing, which could result in a significant monetary loss for stakeholders.

In summary, this roadmap is meant to do the best possible job to address the growth needs felt by all Bitcoin stakeholders, while ensuring the stability and decentralization of the Bitcoin ecosystem.

We want to stress that Bitcoin Core is comprised of a group of volunteers that don’t always agree themselves and many discussions amongst us and Bitcoin stakeholders were required to get us all on the same page.

We have thought long and hard about this proposal and think it is the best of both worlds. But we still want to hear from you about this roadmap and get your input. We are committed to continuing to engaged fully and publicly with the wider community.

The future of Bitcoin is about all of us and we need to work together to push it forward.

Thank you,

The Bitcoin Core Developers

To put the debate to an end we need to support the core roadmap. It is more then good enough. Otherwise there will be a year of fighting, division and chaos with the attempted non-consensus hard-fork.

Community needs to unite behind the scaling roadmap to put this mess to an end.

The more support Gavin gets the more fuel is added to the fire. The price has been reflecting that. Each time he comes out with one of his 'announcements' division occurs and price crashes.

This is a dumb argument - one which you know much better than making. I know that you're fully aware that miners don't control consensus rules on their own. If they did a fork on their own the rest of the community would reject their blocks.

We are increasing the Namecoin payout to BTC × 8 to celebrate Laba Festival. You must fill the Namecoin payout address to receive the NMCs. You give up the bonus coins of the day if you do not fill your payout address before midnight UTC.

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

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

1. 😳

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

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.

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

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

lol

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?

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

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