Remove the Infrastructure Funding Plan from 15 May 2020 upgrade #453
Conversation
There was a problem hiding this comment.
I also think this should be removed. Even the main miners who originally supported it have stated it should not activate.
Also note that BCHD has no intention of adding the new BIP-9 signaling or IFP support in our node. All other changes for May are being worked on, and we would like to be considered a compatible client...
|
I wish you guys would devote the same amount of energy to helping actually write and review the specs. For example, the SigCheck spec is currently inaccurate, and does not correspond to what is implemented. None of you reviewed or helped out writing any of the specs for the last few upgrades, and now you come out with the pitchforks when it's done in a way you don't like. |
This is a lie, I reviewed the OP_REVERSEBYTES spec. |
|
ACK. |
You realize I actually proposed to crowdfund the money and give them to Amaury so that IFP is not needed and none of this would have happened, right? Also I offered 50BCH immediately, which are now going to Bitcoin Cash Node, because you didn't want it. Your argument is invalid. |
What is inaccurate about that spec?
Not true, I also reviewed the OP_REVERSEBYTES spec. And I gave the SigChecks one a good read through, and asked another developer for his opinion on it. |
|
Coming back, I hope we can all focus again on the issue at hand. The IFP has lost miner support, it never really had much community support. The logical step is to merge this PR and revert the IFP out of the spec, then re-engage with the community to find a good way forward. |
|
I disagree with @ftrader , I think there should instead be additional information that establishes Amaury Séchet as the sole and rightful owner of the Bitcoin Cash blockchain, its coin distribution method and all value created on the cryptocurrency network, it is an important part of Bitcoin Cash spec. Writing in such information will ease registration with FinCEN and pave the way to a number of useful innovations, as well as prevent annoying disagreements against his absolute, eternal power from arising in the future. Unfortunately I cannot pen such a PR due to not having relevant information available, but it is definitely something that needs to be done sooner rather than later. |
My simple request is to focus on this PR which is about reverting the IFP code change. Considerations about what happens to a coin that includes the IFP are probably best addressed in another Issue. This proposed change (remove IFP) has, so far, 4 approvals, one of which is by a a "sanctioned" reviewer with write access to this spec repository. (sickpig) If we got no dissenting reviews, when can we expect this simple reversion to be performed? |
Let me see if I understand your point correctly. So taking into account that:
You are lamenting the fact the devs that have 0 saying in the process would had to divert all their time to reviewing the spec with just 1 day of notice. May I say that I found this expectation of yours.... unexpected. That said it would be great if you will open an issue that underline the inaccuracies in the current draft, so that other clients could be aware of that in implementing this feature. I hope that I'm not asking too much, but I'm pretty sure I'm not since those inaccuracies have to be fixed already in the current ABC code base. |
OK, yeah, I'll take that back. You did help review the REVERSEBYTES spec, and a few other people did also. And some other in this thread also helped review some specs in the past. So I'll take back that comment. |
There was a problem hiding this comment.
I've been thinking about what is the "right thing" to do in this situation.
Whether or not this PR makes sense will be determined by whether one thinks that a specification should be descriptive, or prescriptive. It seems that the objections are basically arguing that the IFP is unpopular, and therefore should not be endorsed by writing it into the spec. this is the "prescriptive" view.
Another view is that the purpose of the specification is to inform people about what is actually implemented in the code, ie a descriptive function. Given that the IFP is implemented in Bitcoin ABC, which is used by almost all miners, it makes sense to include it in the spec if we want to actually describe what rules are in effect.
FWIW I agree with the comments that the spec should have been written earlier. Ideally it's good if the spec is written early on, and then perhaps modified as it is implemented in the software, which can reveal problems with the spec, or better ways of doing things. So in this model, the spec starts out being somewhat prescriptive, but ends up being descriptive in the end.
Given that the Bitcoin ABC code is now written and released, and that it is the node being used by pretty much all BCH miners / mining pools, I think it's important that the specification give people as full information as possible of its actual behavior. For this reason, this PR should be rejected.
|
@Mengerian that criterion of yours where it "is the node being used by pretty much all BCH miners/mining pools" is objectively wrong at the time of writing: Most use ABC 0.20.x, which contains no such code. |
I certainly think any Bitcoin Cash specification can only hope to be descriptive, but it should aim to reflect as accurately as possible (it can even describe the ways various requirements are viewed differently across implementations). |
It's true, I never contributed anything to ABC directly. Bit I'm not objecting to the way it's done, but to what is done. This change is not only a change to ABC, but also to BCH. I feel like I'm presented with facts (the IFP implemented in ABC, a major change to the consensus rules) and then maybe even blamed for supporting a potential split when that is the only option I have to avoid the IFP. |
|
I noticed I was removed from bitcoincashorg organization on github on March 3 by some administrator of the org. It was not correlated to any action of mine (my last GH action prior to raising this PR was on Feb 22). Can someone explain to me why I was removed from this repository which is nominally the location of the common Bitcoin Cash specification? @Mengerian @deadalnix @jasonbcox who removed me from the Bitcoin Cash org, and why? |
really? care to explain further rather than give a simple 1-line blanket statement? I'd really like to know what exact economic theory you are using as well as the assumptions you are making with this statement |
Here's my position on the topic https://shablag.com/article/bitcoin-cash-development-funding/ |
|
Excerpt from your article:
There's no proof provided for this to be the case. You highlight Blockstream and Liquid Network as an example that proves your point, conveniently ignoring other major companies that have sold both services and product (??Consensys??). Essentially, all of your arguments in this article stems from the idea that no developer working on the core protocol can possibly make an honest profit selling products and/or services. Are you really sure that this is the case? |
I'm not ignoring anything. You're comparing oranges to basketballs.
You tell me. Which part of the core node software is able to be reliably monetized besides block validation? The IFP is in fact what you're asking for -- unless you're expecting people to do double duty by creating a paid product and then also donating their time to develop the node software. |
So ... my point about companies that contribute to protocol as well as providing product/service has been completely ignored ... as well as an explicitly working example of a company doing just that
Or ... you know ... people can choose to invest their time and money elsewhere. Like how the Ethereum folks decided to create their own blockchain ecosystem, separate from Bitcoin. This line of thinking relies on faulty premise that people won't abandon BCH for something better |
So ... my point about companies that contribute to protocol as well as providing product/service has been completely ignored ... as well as an explicitly working example of a company doing just that
Fact is, you still have not provided any economic analysis of why a protocol-controlled fund is to be implemented. Can you provide any forecast (with data) of any form of growth / development / maturity / community expansion that would result from this? I haven't seen anything yet. |
I didn't ignore you. I worked on ABC for a year and a half. Mix in corporate money and you get prioritization of questionable functionality. ABC turned down numerous offers for funding because they came with strings attached that would be bad for the ecosystem overall due to misaligned incentives. I'd be significantly more wealthy right now if I had less scruples.
My line of thinking does not depend on people not leaving BCH. In fact, I think the people who are most vocally against this should go create their own blockchain ecosystem.
"It is economically sound in that it aligns the incentives of developers with that of the network." Any company providing a return on investment with a product other than the blockchain itself will be pushing for, and prioritizing, work that is beneficial to their product. This is not rocket science. If you want the network to perform best, tie the incentives of developers directly to the success of the coinbase issuance. Any other source will have incentives which are misdirected -- howeverso slightly -- from the goal of making the use of the blockchain itself expand. |
|
I see my points are ignored again. I'm not asking for your personal experience of mis-aligned incentives with companies. I'm asking whether the idea in principle works in general. Which you either misunderstood repeatedly, or just ignored. Can you at the very least address my example of Consensys, and how a company like that selling their own blockchain product/services while contributing to the protocol development does not fit your criteria? Are you saying that the work Consensys did for the Ethereum ecosystem came from "mis-aligned incentives"? |
I'm sorry I'm not communicating in a way you can understand.
Indeed, that's what I'm saying. Furthermore, they're a hypemachine and a giant scam. I can't take you seriously anymore. I won't be responding to you again. |
It seems like this commenter should find employment at the Electric Coin Company where this line of thinking is welcome, instead of attempting to hijack an existing network. |
|
@imaginaryusername or a lieutenant for the US Navy |
.. and anyone who finished off the semester and got an A will know this funding mechanism is a poison pill for BCH. FTFY. |
I would like to get someone to respond on this, is it too much to ask? I feel it is important for me to understand the process behind current administration of the Bitcoin Cash org. |
|
So instead, various technical itches were scratched while the ecosystem was actively damaged, and now ABC seeks a permanent source of unqualified funding to continue that way. |
|
Disgusting and deceptive behaviour from Mengerian in refusing this PR. A Bitcoin ABC agent who is using his position of influence within the bitcoincash.org project to enforce his personal opinions rather than those of the community in general. You are no different than theymos. |
|
This conversation is turning very unproductive, so I'm locking it. |
The funding part of the recently merged PR #444 did not have consensus and was added something like 18 days after feature freeze.
This violates established procedure to not include changes for which there is strong lack of consensus (in fact, there is very vocal disagreement from large parts of the community about the IFP and its implementation in an existing client).