Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove the Infrastructure Funding Plan from 15 May 2020 upgrade #453

Closed

Conversation

ftrader
Copy link
Contributor

@ftrader ftrader commented Mar 4, 2020

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

sickpig
sickpig previously approved these changes Mar 4, 2020
BigBlockIfTrue
BigBlockIfTrue previously approved these changes Mar 4, 2020
Copy link
Contributor

@BigBlockIfTrue BigBlockIfTrue left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK, although I suggest one additional change (see review comments).

spec/2020-05-15-upgrade.md Outdated Show resolved Hide resolved
@ftrader ftrader dismissed stale reviews from BigBlockIfTrue and sickpig via 8985407 March 4, 2020 13:25
Copy link
Contributor

@BigBlockIfTrue BigBlockIfTrue left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK, thanks.

Copy link
Collaborator

@zquestz zquestz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@Mengerian
Copy link
Contributor

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.

@BigBlockIfTrue
Copy link
Contributor

None of you reviewed or helped out writing any of the specs for the last few upgrades

This is a lie, I reviewed the OP_REVERSEBYTES spec.

@ShadowOfHarbringer
Copy link

ACK.

@ShadowOfHarbringer
Copy link

ShadowOfHarbringer commented Mar 5, 2020

@Mengerian

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.

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.

@ftrader
Copy link
Contributor Author

ftrader commented Mar 5, 2020

For example, the SigCheck spec is currently inaccurate, and does not correspond to what is implemented.

What is inaccurate about that spec?

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.

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.

@ftrader
Copy link
Contributor Author

ftrader commented Mar 5, 2020

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.

@imaginaryusername
Copy link
Contributor

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.

@ftrader
Copy link
Contributor Author

ftrader commented Mar 5, 2020

I hope we can all focus again on the issue at hand.

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?

@sickpig
Copy link
Collaborator

sickpig commented Mar 5, 2020

For example, the SigCheck spec is currently inaccurate, and does not correspond to what is implemented.

@Mengerian

Let me see if I understand your point correctly. So taking into account that:

  • Add spec for 2020 May SigChecks upgrade #443 was opened ~4AM UTC on February 13th after I personally asked Mark multiple times about it. less then 2 days before the features freeze.

  • Changes spec'ed are neither simple, nor small.

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.

@Mengerian
Copy link
Contributor

This is a lie, I reviewed the OP_REVERSEBYTES spec.

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.

Copy link
Contributor

@Mengerian Mengerian left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@imaginaryusername
Copy link
Contributor

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

@ftrader
Copy link
Contributor Author

ftrader commented Mar 6, 2020

whether one thinks that a specification should be descriptive, or prescriptive

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

@molecular
Copy link

molecular commented Mar 6, 2020

@Mengerian

and now you come out with the pitchforks when it's done in a way you don't like.

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.

@ftrader
Copy link
Contributor Author

ftrader commented Mar 7, 2020

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).
The time of receipt of the automated notification email from Github is 3 Mar 2020 18:12:50 UTC.

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?

Copy link
Contributor

@schancel schancel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Absolutely not. Anyone who took half a semester of game theory knows that this funding mechanism is required.

@lightswarm124
Copy link

Absolutely not. Anyone who took half a semester of game theory knows that this funding mechanism is required.

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

@schancel
Copy link
Contributor

schancel commented Mar 8, 2020

Absolutely not. Anyone who took half a semester of game theory knows that this funding mechanism is required.

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/

@lightswarm124
Copy link

Excerpt from your article:

The first two of these ideas amount to saying that developers should work on the node software in addition to doing some other work. This doesn’t really solve the key issue at hand, and it misaligns the incentives of developers.

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?

@schancel
Copy link
Contributor

schancel commented Mar 8, 2020

conveniently ignoring other major companies that have sold both services and product (??Consensys??)

I'm not ignoring anything. You're comparing oranges to basketballs.

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?

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.

@lightswarm124
Copy link

conveniently ignoring other major companies that have sold both services and product (??Consensys??)

I'm not ignoring anything. You're comparing oranges to basketballs.

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

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.

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

@lightswarm124
Copy link

lightswarm124 commented Mar 8, 2020

conveniently ignoring other major companies that have sold both services and product (??Consensys??)

I'm not ignoring anything. You're comparing oranges to basketballs.

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

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.

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

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.

@schancel
Copy link
Contributor

schancel commented Mar 8, 2020

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

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.

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

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.

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.

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

@lightswarm124
Copy link

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

@schancel
Copy link
Contributor

schancel commented Mar 8, 2020

I see my points are ignored again.

I'm sorry I'm not communicating in a way you can understand.

Are you saying that the work Consensys did for the Ethereum ecosystem came from "mis-aligned incentives."

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.

@imaginaryusername
Copy link
Contributor

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.

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.

@lightswarm124
Copy link

@imaginaryusername or a lieutenant for the US Navy

@cculianu
Copy link
Contributor

cculianu commented Mar 8, 2020

Absolutely not. Anyone who took half a semester of game theory knows that this funding mechanism is required.

.. and anyone who finished off the semester and got an A will know this funding mechanism is a poison pill for BCH.

FTFY.

@ftrader
Copy link
Contributor Author

ftrader commented Mar 8, 2020

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?

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.

@schancel
Copy link
Contributor

schancel commented Mar 8, 2020

Absolutely not. Anyone who took half a semester of game theory knows that this funding mechanism is required.

.. and anyone who finished off the semester and got an A will know this funding mechanism is a poison pill for BCH.

FTFY.

image

@dgenr8
Copy link
Contributor

dgenr8 commented Mar 8, 2020

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.

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.

@howelzy
Copy link
Contributor

howelzy commented Mar 8, 2020

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.

@jasonbcox
Copy link
Collaborator

This conversation is turning very unproductive, so I'm locking it.

@jasonbcox jasonbcox closed this Mar 9, 2020
@bitcoincashorg bitcoincashorg locked and limited conversation to collaborators Mar 9, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet