47
48

Avoid F2Pool: They are incompetent ,reckless and greedy! (self.Bitcoin)

coinx-ltc が 投稿

Peter Todd (not a Bitcoin Core Dev, works for Viacoin) talked F2Pool (Chun Wang) into implementing his RBF patch. A few hours later Chun realises want a terrible idea that was and switches to FSS RBF (safe version of RBF).

This behaviour was more than eye opening how greedy they are and how little their understanding of Bitcoin is.

  1. First of all RBF is a terrible idea that is only supported by Peter Todd. All merchants would have to wait for at least 1 confirmation. Say goodbye to using Bitcoin in the real world. Chung even admitted how bad RBF is: "I know how bad the full RBF is. We are going to switch to FSS RBF in a few hours. Sorry."

  2. He didn't announce the implementation of RBF befor activating it. This could have led to thousands of successful double spends against Bitcoin payment provider and caused their insolvency-> irreparable image loss for Bitcoin.

Summary: F2Pool implemented a terrible patch that could have caused the loss of millions $ for a few extra bucks (<100$) on their side. Then they realised that they didn't fully understood the patch they implemented and reverted it as fast as they could.

From my point of view even more reckless behaviour than what Mark did with MtGox.

http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08422.html

EDIT:

F2Pool didn't announce it before because they didn't really understood how their behaviour could led to a massive amount of double spends (poor understanding of Bitcoin). Peter Todd didn't because he was pissed that all the big players ignored his shitty RBF idea:

I've had repeated discussions with services vulnerable to double-spends; they have been made well aware of the risk they're taking.

There was no risk till F2Pool implemented RBF (only by implementing it, there is a need for it).

RBF: Replace-by-means that you can resend a transaction with higher fees and different outputs (double spending the previous transaction).

FSS RBF: First-seen-safe Replace-by-fee means that you can't change the outputs (useful is your fee wasn't high enough).

全 41 件のコメント
並べ替え:
ベスト
トップ新着論争中古い順Q&A

[–]jstolfi 11ポイント12ポイント  (31子コメント)

And the "new devs" then complain that Gavin and Mike are being "dictatorial" by discussing their proposal with all the major players and then proposing it in public...

[–]NicolasDorier 6ポイント7ポイント  (15子コメント)

RBF is not a change of consensus, you can't compare it with the block size debate.

If some part of the network don't accept RBF, then there is no consequence at all, it will not create a new currency.

[–]jstolfi 2ポイント3ポイント  (10子コメント)

The word "consensus" is being used (and misused) for three vastly different things.

  • The network is always trying to reach and maintain a consensus about what is "the" bitcoin blockchain and which transactions are waiting to be mined.

  • The behavior of the network is determined by a complicated consensus of clients, nodes, and miners, who manifest their opinion (or lack thereof) by configuring their hardware, running specific versions of the software (possibly with private modifications), fixing parameters, organizing their files, etc..

  • Changes to the protocol and the reference implementation had better be deployed only after there is a consensus among the bitcoiners, especially the major players like miners, exchanges, payment processors, big investors, software developers (not just the core ones), etc.

Clearly Blockstream is abusing their position as the maintainers of the official version of the core software to push for major changes (including the replacement of bitcoin's stated goal, the opening sentence of Satoshi's paper) without trying to get a consensus of the community first. They are upset because Mike and Gavin sought such consensus and went public with the block increase plan, bypassing the core devs.

[–]NicolasDorier 0ポイント1ポイント  (2子コメント)

What I am saying is that not everyone is required to run RBF because other people are running it. Having half the network using RBF and half another algorithm do not create two currencies nor will result in lawsuits because service providers chose the wrong choice for their users in hindsight.

Change in the consensus in dev term means any code change to the code in the libconsensus library. Block size is a change to this library while RBF is not. The consequence of one is to create two currencies, the consequence of the other have no impact at all, except an increase in successful double spent, triggered because the skill to make a successful one is decreased.

Btw, I do not support Gavin and Mike, even if I want the block size increase, Blockstream have nothing to do with my rational about it.

[–]jstolfi -1ポイント0ポイント  (1子コメント)

Change in the consensus in dev term means any code change to the code in the libconsensus library.

OK.

Block size is a change to this library while RBF is not. The consequence of one is to create two currencies, the consequence of the other have no impact at all, except an increase in successful double spent, triggered because the skill to make a successful one is decreased.

I understand the conceptual difference, especially for programmers, but I don't it as that important from the external point of view. A hard fork would be a non-event if carried out properly, whereas making RBF the default policy of the reference implementation would be disastrous if it kills BitPay and forces the sender of a transaction to wait for its confirmation before disconnecting from the network.

(By "carried out properly" I mean: so that the fork date is known by all players in avance, transactions are strictly segregated after the fork, everybody has minimally reliable knowledge about the consequences and current popularity of each choice, etc.. As the deadline looms closer, the community should switch en masse to the majority side, for self-interest. After the fork, if the minority chain is still limping along, the majority should actively kill it.)

[–]jstolfi -1ポイント0ポイント  (0子コメント)

Btw, I do not support Gavin and Mike, even if I want the block size increase

I have no admiration for Gavin either (mainly for his continuing support of the Blockchain Foundation), and I did not know of Mike's existence a month ago. But they seem to understand the consequences of the alternatives much better than the "new devs", for one thing.

[–]110101002 -1ポイント0ポイント  (6子コメント)

Changes to the protocol and the reference implementation had better be deployed only after there is a consensus among the bitcoiners, especially the major players like miners, exchanges, payment processors, big investors, software developers (not just the core ones), etc.

I'm confused, are you not complaining about F2Pool anymore, or are you saying any change in the miners transaction acceptance policy, even as simple as not taking lower fee transactions needs approval from investors, exchanges, their competing miners, etc?

You're working on a lot of trust there, you can't expect miners to follow your demands, you have to expect them to follow economic incentives.

Your post goes over consensus, but doesn't really explain much about consensus (you touch on it in the first bullet but the rest is just explaining software and human behavior). Bitcoin is the first distributed consensus system, what people are talking about when they speak of consensus is very specific and a miners transaction priority rules aren't a component of that.

[–]jstolfi 0ポイント1ポイント  (5子コメント)

I'm confused, are you not complaining about F2Pool anymore

F2Pool can hardly be blamed, they probably did not understand the full implications of unsafe RBF. (They may have liked the idea of a "fee war" that RBF would aggarvate.) Peter Todd knew the implications and always wanted them.

are you saying any change in the miners transaction acceptance policy, even as simple as not taking lower fee transactions needs approval from investors, exchanges, their competing miners, etc?

As others have pointed out, any node and any miner could implement RBF on their own, since queue management policies do not affect the validity of the blockchain. That freedom is arguably a flaw of the protocol.

In theory, no one need to consult anyone else before changing free software that they maintain. It should be the user's problem to make sure that the software he is running is good for his purposes; and the system should be resistant to damage by misbehaving players, as long as there is a key number of well-meaning nodes and a majority of the mining power is in the hands of well-meaning people.

In practice, maintainers of a widely used free software have a moral responsibility towards their users and society. For bitcoin in particular, the core developers should not make changes to the core software that are likely to affect many users in a perceptible way -- independently of whether the change would lead to a hard fork, a soft fork, or no fork at all.

For example, the formal validity of the chain would not be affected if the core version of the client software sent the private keys of some accounts to a central site, or if the core version of the node software just dropped every transaction whose hash ended with the bits '001'. These changes would not affect the validity of chain blocks; but, even so, the core devs should seek consensus of the community before adding them to the core

Your post goes over consensus, but doesn't really explain much about consensus (you touch on it in the first bullet but the rest is just explaining software and human behavior). Bitcoin is the first distributed consensus system

Methinks you are assuming "consensus" has the first bullet meaning while everybody is using the word in the third meaning.

(BTW, I don't think bitcoin is "the first distributed consensus system". It is just the first one with certain properties.)

[–]110101002 1ポイント2ポイント  (4子コメント)

For example, the formal validity of the chain would not be affected if the core version of the client software sent the private keys of some accounts to a central site

Yes, but that is a security problem being created. All RBF does is makes some form of security through obscurity less "secure".

Methinks you are assuming "consensus" has the first bullet meaning while everybody is using the word in the third meaning.

When someone says "consensus change" with regards to bitcoin software they're either referring to the first one, or they don't have technical knowledge around Bitcoin.

[–]jstolfi 0ポイント1ポイント  (3子コメント)

Even so, if it has a significant impact on users, it should have been at least announced clearly to them. Ditto for several other patches that the core devs are doing to the core.

For example, consider the "fee market" that will be forced upon users when blocks fill up. The "safe" variant of RBF will both aggravate that market and provide a necessary tool to play in it, implying a totally non-trivial change in every software that issues transactions, that will make bitcoin use more complicated and time-consuming for all users. It was totally irresponsible of the devs to decide that such "fee market" must be imposed as soon as possible (by keeping blocks small) and implementing it in the core, without even telling the community about that plan.

And I am now really doubting their competence as well as their prudence, because I cannot see how the "fee market" can be anything but a disaster.

Someone quipped that "bitcoin is the tool that the Devil invented to teach economics to the nerds". Poor Devil must be very disappointed with his students...

[–]110101002 0ポイント1ポイント  (2子コメント)

Even so, if it has a significant impact on users, it should have been at least announced clearly to them.

Miners should be expected to act in self interest. They announced it clearly which is more benefit than they needed to give anyone. It should be assumed that miners already are accepting doublespends.

We don't need an announcement for every little change every individual miner makes, we should just do what has been advocated for years and not accept zero conf.

I repeat, THERE IS NO ZERO CONF SECURITY. A mining pool changing their policy OVERTLY is just them being nice, NEVER assume mining pools are acting in your economic interest. This same kind of reasoning led to a >1000BTC theft by GHash.

For example, consider the "fee market" that will be forced upon users when blocks fill up.

This isn't a very good example of something that is sprung on users by core devs. The fee market has been well announced and has existed for a long time.

It was totally irresponsible of the devs to decide that such "fee market" must be imposed as soon as possible (by keeping blocks small) and implementing it in the core, without even telling the community about that plan.

It wasn't the core devs plan, it was written explicitly in the software.

And I am now really doubting their competence as well as their prudence, because I cannot see how the "fee market" can be anything but a disaster.

A fee market has already worked before and really it's the only solution to long term Bitcoin viability.

[–]jstolfi 0ポイント1ポイント  (1子コメント)

A fee market has already worked before

When was that? So far, the conditions for it to exist have not existed, since the transaction rate has always been well below the network's capacity. (Even the recent stress tests were too unexpected and short-lived to get the market going.)

and really it's the only solution to long term Bitcoin viability.

Has there been any contestation of Mike Hearn's "crash landing" blogpost?

I had discussions with some bitcoiners who are impatient to see the "fee market" in action, and it seems that they only like the idea because they did not understand how it will (not) work.

The fee market will not solve the scalability problem of bitcoin. Fact is, bitcoin is not a viable design for a widely used payment system. What you mean is that saturation of the network will force its users to migrate to another system that can scale to PayPal size.

Blockstream apparently had some ideas about this system but it seems that they don't work. Even if they did, and had some advantage over Paypal, Visa, WU, etc. -- don't you feel that something os wrong with the claim "the only way to save bitcoin is to destroy it and build something completely different in its place"?

[–]110101002 0ポイント1ポイント  (0子コメント)

When was that?

In 2013 when the soft limit was reached. Hearn rallied for an increase and got his wish.

Even the recent stress tests were too unexpected and short-lived to get the market going

Funny enough they worked perfectly. The transactions with good fees were confirmed next block.

The fee market will not solve the scalability problem of bitcoin.

Nor will digital signatures, but both are important components of Bitcoin security.

Fact is, bitcoin is not a viable design for a widely used payment system. What you mean is that saturation of the network will force its users to migrate to another system that can scale to PayPal size.

The blockchain cannot scale to paypal size through simply increasing block size without becoming as centralized as paypal. We might as well develop actual scalability solutions.

"the only way to save bitcoin is to destroy it and build something completely different in its place"?

It's another layer, this argument doesn't make sense. Did HTTP destroy TCP? No it just built on top of it.

[–]smartfbrankings -4ポイント-3ポイント  (0子コメント)

BUT I WANT MY INSTANT COFFEES NOW!!!!!!!

[–]StubNuts -2ポイント-1ポイント  (0子コメント)

This. Transactions are never safe before being committed to a block and no one should be propagating any illusion that they are. Whether is through Peter's patch or someone else's pools have the right and ought to select variants of transactions for their fees.

[–]110101002 0ポイント1ポイント  (5子コメント)

Yeah, how dare he consult a client without our permissions! I bet Peter even gets haircuts without community consensus!

[–]petertoddPeter Todd - Bitcoin Expert -1ポイント0ポイント  (4子コメント)

Speaking of, I was just about to get one.

Should I?

Yes: 1MNDPdkAQHt1yKLjnPrGQGB5uNkhHQ79st

No: 19NtDsvhytFoDroPTW8YP72uiDP7AuCPF8

[–]maaku7Mark Friedenbach - Bitcoin Expert -5ポイント-4ポイント  (2子コメント)

Will you commit to never cutting your hair if 19NtDsvhytFoDroPTW8YP72uiDP7AuCPF8 > 1MNDPdkAQHt1yKLjnPrGQGB5uNkhHQ79st? ;)

[–]bitsko 1ポイント2ポイント  (5子コメント)

Is there any truth to them and antpool intentionally mining empty blocks?

[–]samurai321 1ポイント2ポイント  (4子コメント)

it's unknown, that happens sometimes if they get a block within difficulty right after a new block is found.

[–]coinx-ltc[S] 0ポイント1ポイント  (3子コメント)

It is a strange coincidence that it has happened a couple of times to chinese pools. Since there are 1-2 tx per second it is quite unlikely that they didn't receive any transaction between the old and new block.

[–]samurai321 3ポイント4ポイント  (0子コメント)

i'm telling you they do this by default, just like miners can build huge blocks, they can build tiny ones, they just care about block hitting difficulty.

[–]riplin 3ポイント4ポイント  (1子コメント)

Some miners start mining on a new block only after having verified the header (and not the content) and verify the content in parallel to that. During that time they cannot include any transactions into their block other than their own coinbase tx. Once the previous block has been verified they can include transactions from the mempool.

[–]jwBTC 0ポイント1ポイント  (0子コメント)

THIS IS THE RIGHT ANSWER.

We have always had zero transactions blocks. They generally only happen because of this exact issue, you don't want to lose out on 25BTC because you waited another half minute to broadcast your own block waiting for all the housekeeping on the last block and your own mempool.

[–]lclc_ 1ポイント2ポイント  (1子コメント)

Peter Todd (not a Bitcoin Core Dev, works for Viacoin)

Cheap flame. To become a Bitcoin Core Dev you have to make a commit to Bitcoin Core (yes, Dev means developer).

Peter Todd is a Bitcoin Core Dev. And if you are value peoples opinion based on titles I can't take your opinion serious regarding Bitcoin topics since you are clearly a Litecoin fanboy.

[–]riplin -1ポイント0ポイント  (0子コメント)

Peter does not have commit access to the official Bitcoin Core depot. He's submitted pull requests but that does not make one a Core Dev.

[–]coinnoob 0ポイント1ポイント  (0子コメント)

First of all RBF is a terrible idea ... All merchants would have to wait for at least 1 confirmation.

what the actual fuck? the only terrible idea proposed here is the notion that merchants should NOT wait for confirmations. are you out of your mind? have you even read the satoshi whitepaper?

you can't just ignore the problem and pretend it doesn't exist. miners have the power to replace transactions at will. why would you even begin to assume they will always play nice when it is directly in their own interest to do the exact opposite?

the solution is to have all miners adhere to one transparent standard that is incentive aligned, which is exactly what this push to implement RBF is trying to achieve.

putting your hands over your ears and humming loudly isn't going to solve the problem of 0-confirm insecurity

[–]coinaday 0ポイント1ポイント  (0子コメント)

/me shrugs

It's acceptable on the protocol. It's not a fork. You may not like the behavior, but they're not doing anything wrong by doing it. 0-confirmation transactions are not on the blockchain. If merchants want to pretend they're irrevocable payments, then yes, they expose themselves to that transaction not ultimately going through.

Everyone's been so busy talking about how bitcoin is instant and we can ignore confirmations that they work themselves into this asinine position where we pretend like anyone who ever does anything to expose that bullshit is pilloried.

Like, you know, pointing out that if you actually need to get something confirmed faster you could use basically any altcoin ever. If you want a high-security confirmation, use bitcoin. If you want to use 0-confirmation bitcoin transactions, then be fucking aware they aren't confirmed. Those coins aren't spent until they're on the blockchain.

But yeah, go ahead and demonize them for doing a protocol-compatible change and reversing it shortly thereafter. Sure, it would have been better if they'd announced it first and gotten your personal permission. But to act like they are responsible for the fact that 0-confirmation transactions aren't, you know, confirmed is idiotic.