In May 2019, there may be another protocol upgrade for Bitcoin Cash. As is good practice, the specification for it is being drafted already. Ideas are being tossed around and perhaps already some code has been written.
I’ve seen people claim us developers are evil. We’re power hungry. Amateurs disguising ourselves as experts and we’re breaking Bitcoin!
While I certainly don’t perceive myself that way, I nonetheless want to try an experiment.
We going to challenge the specification being written! I am going to maintain a separate specification from the one being drafted and you are going to help me write it.
How this is going to work:
We are going to assume that there is an upgrade in May. We need a specification. If we can’t produce anything, then an empty specification is fine too.
I will publish a series of articles, called "Let's talk spec", briefly explaining proposals and I will attempt to do it in layman’s terms. I will toss in a few pros and cons.
I may weight in my opinion in the article. That will be my author’s prerogative. I may not want weigh in and often I have not arrived at an opinion.
It is your responsibility to understand the issue presented. You must also think through it yourself. Don’t parrot a leader figure. Don’t be a NPC.
Finally, the tough part, from the comments I’m going to try to derive at some kind of consensus. I don’t know a good way to do that, but this is an experiment and it’s worth a shot. If it turns out I concluded wrong, we can revisit the same issue in a new article.
Who am I
I’m a Bitcoin (Cash) developer. I embrace simple, reliable and low-cost transactions. I want Bitcoin to be just as awesome as when I first discovered it. My first code contribution to Bitcoin was in 2015 to Bitcoin XT.
I started to contribute code because I saw the direction the scaling debate was taking back then. I decided to contribute the best way I can – with code. To me action speaks louder than word. When Mike and Gavin challenged Core – with code, I wanted to support them.
Guidelines on how to best communicate with an engineer:
- Be brief and to the point (no TL;DR please)
- We like data and facts In fact, if you produce good empirical data, you are awesome. If you do the math, you are awesome.
- If you want to discuss an issue, present the issue, not a solution. (“I need a quick way to access images”, not “You need to add an image button right here”)
- Don’t expect us to be good at communication. Assume we mean well.
- There is no winning an argument by saying the most or getting the last say.