Gold collapsing. Bitcoin UP.

Dusty

Active Member
Mar 14, 2016
362
1,172
I agree with @solex here: the EDA is really, really damaging BCH and it should be get rid of asap (the "premine" argument is quite correct). Such a short notice for an HF is not good but at a certain time someone has to take the lead and make a decision.
I give Amaury the benefit of doubt this time due to the circumstances and also because thanks to him we finally got rid of years of talk about the blocksize debate and took action.
But a different, more open and slow, approach must be taken for the next HF, and if this will not change I'll move my position toward the one of Erik.
 

Erik Beijnoff

New Member
May 30, 2017
16
52
Agreed, the EDA is damaging. I've been one of the bigger critics of it.

What concerns me is that network changes are imposed where the driving force isn't concern of network health, but instead what can only be seen as network degrading forces and underhand tactics. As long as Séchet continues to have influence over Cash, these tactics will continue from his side. As now proven beyond a reasonable doubt. This is quite damaging and not the premises under which I bought into the system. Had I been aware that this situation existed from the start, I'd never shifted towards BCC.
 
Last edited:

singularity

Member
Aug 17, 2016
50
132
I think these kind of problems can all be fixed using the BFP process.
https://bitco.in/forum/threads/bitcoin-fork-proposal-bfp-process.3049/#post-46110

Then everyone gets as much influence as they deserve but we still get to make progress.
  • Unanimous consensus is no longer necessary.
  • Development teams are able to offer up different proposals and the miners can decide which proposal is best.
  • Miners are able to decide to make no change at all.
  • The network remains in 100% consensus at all times other than in situations of extreme idealogical disagreement.
  • Process can be implemented immediately.
  • Process is loose enough that it can be applied to any upgrade that requires consensus.
  • Does not conflict with other improvement proposal processes, such as BUIP.
  • Provide confidence for network participants that community leaders (i.e. developers, miners and businesses) will support a process that aims to use free market principles but still keep the network in 100% consensus at all times.
 

awemany

Well-Known Member
Aug 19, 2015
1,387
5,054
Hey singularity,

I guess you are singularity87 on reddit? Haven't seen you here, at least not in a long while...

I really like your proposal. I thought I posted something similar to the bitcoin-ml about some kind of gentleman's agreement between dev groups and the miners making a choice, but I can't find it and that likely means I just dreamed of posting something :D

I might have formulated a couple things differently, but there's no reason to bikeshed. I do very much like the simple majority 51% threshold - as Bitcoin is designed.

Though one thing that you should put in there IMO is some kind of upgrade periods, e.g. half a year or so for larger upgrades, 3 months for a smaller tweak that doesn't need attention by most etc.

I see BCH still only as insurance and I also would really like to something like this to be adopted by most folks after the 2x fork, so maybe you should also present it as an option for main chain Bitcoin.

There's also one additional feedback mechanism that might be very worthwhile to draft out: The miners might collectively vote on some kind of deadline for proposals on a particular topic by some kind of median scheme or so - so that the devs who do a first, quick shot at solving a problem and produce some code will be on a fair and level playing field against some who will take some more time to figure stuff out and code something up which might be better, but needs a little bit more simmering on the stove.

This would be psychologically very helpful IMO, because I think to a large extend Core ruled in the past by putting something out there, e.g. SegWit and then say: "Eat it up, it is finished already.".

If the miners would have collectively said: Well, we like to have a malleability fix, but only implemented in August 2017 - and would have said that a couple years ago - I think a lot more solutions to that problem would have appeared.

The whole "Core is without alternatives" rhetorics and psycho tactics would be rendered impossible by this, also in the future and for any other team.
 

singularity

Member
Aug 17, 2016
50
132
I guess you are singularity87 on reddit?
Yep.

Though one thing that you should put in there IMO is some kind of upgrade periods, e.g. half a year or so for larger upgrades, 3 months for a smaller tweak that doesn't need attention by most etc.
I did think about this. I decided it was best to leave this up to the people making the proposals because I wanted to make this process as unrestrictive as possible. The more restrictions that are required, the less likely it is that the process will be used. I would hope that different dev teams could at least agree on a schedule for signalling and lock-in. If they can't even agree on that then I don't think there is any hope in this process being adopted.

There's also one additional feedback mechanism that might be very worthwhile to draft out: The miners might collectively vote on some kind of deadline for proposals on a particular topic by some kind of median scheme or so - so that the devs who do a first, quick shot at solving a problem and produce some code will be on a fair and level playing field against some who will take some more time to figure stuff out and code something up which might be better, but needs a little bit more simmering on the stove.
This is an interesting point and definitely worth discussing. I think it could be made moot though by other teams communicating clearly to the community and miners that they are also working on competing proposals, and that they should hold off on signalling.

The whole "Core is without alternatives" rhetorics and psycho tactics would be rendered impossible by this, also in the future and for any other team.
I completely agree, and this is the exact purpose of this process.

Thanks for your insight.
 
Last edited:

Tomothy

Active Member
Mar 14, 2016
130
317
Agreed, the EDA is damaging. I've been one of the bigger critics of it.

What concerns me is the realisation that network changes are imposed where the driving force isn't concern of network health, but instead what can only be seen as network degrading forces and underhand tactics.
I think it is inaccurate to say that those involved are not concerned about the health of the network. We know miner is losing money mining bitcoin cash, this is because current Eda is broken. We know other miners don't want to lose money. So this needs to be fixed. There was a huge outcry over turbo blocks about needing to fix this. I think it's safe to say that we all agree that current operation of bch is suboptimal. So. It needs to be fixed. By fixing it I think this shows care of the network. We are fixing something broken.

So at this juncture I think we should unify and support this hot fix. And let's call it a hot fix because there's a lot unknown. Assuming this hot fix goes off without a hitch, it shows the ability of bch to identify an issue and fix it quickly. If this is the action plan moving forward hard forks will become second nature. Will on bitcoin mailing list talked about this. How we should embrace hardfork to avoid stagnation.

We are at the cusp of a cultural revolution. Bch is a brand new project so we should hold on tight and see what happens. I think the biggest issue you Erik and myself agree on is that community involvement and communication was less than desirable. That doing something like singularity proposal or something should help avoid issues like this in the future. Obviously the difficulty is avoiding having a dictator. Yet, maybe it's good we have someone acting like a Satoshi. For now I've got my pitchfork and torches but I'll wait before throwing any stones.

(I am concerned about long term mining profitability and removal of 2016 block calculation. This does seem to support manufacturers over miners.)
 

Tomothy

Active Member
Mar 14, 2016
130
317
@adamstgbit afaict no decision had been made in the mailing list. There was simply continued debate with regards to which daa was the best and what should be implemented. I think if this discussion took place weeks ago it would be different. However, there was no sense of urgency until the date was set. The date was set because there hadn't really been any discussion presumably because it wasn't viewed as a concern. Kindof a chicken and egg argument lol.
 
  • Like
Reactions: adamstgbit

jbreher

Active Member
Dec 31, 2015
166
526
I'll grant deadalnix the benefit of the doubt, and assume he truly believes this is the optimal route forward for the largset set of participants. However, I still think it is the wrong solution, and pretty well dickheaded besides.

But hey - Bitcoin is permissionless. He controls ABC, he made an ABC decision. Fair enough.

But this does not need to be the Bitcoin Cash decision. And indeed, ABC will live with the consequences. For one, I will register my displeasure int he only way I have available to me in a permissionless system. I will move off of ABC as my client.

I kind of hope others will join me. If ABC suddenly is rendered the runt of the litter, that will send a message to all developers that they will need to cooperate better or be punished in the marketplace.

Incidentally, I am not sure that the EDA is anything that actually needed fixing. And we are introducing new untested incentives by changing it. But whatevs.

Lastly, in no freeking way was the EDA-induced 'turbo rounds' a premine. A premine is universally understood to be where insiders get to mine at the birth of a coin, and outsiders are locked out by inviolable policy. Indeed, the turbo rounds were exactly the converse, where _more_ miners are involved during that time then at baseline. Let's not go all hyperbolic on the language, shall we?
 

Tom Zander

Active Member
Jun 2, 2016
208
455
I think these kind of problems can all be fixed using the BFP process.
https://bitco.in/forum/threads/bitcoin-fork-proposal-bfp-process.3049/#post-46110
My story;

Even back in February I pushed Jeff for a mailinglist, and we got one (co-moderated by many). I have since been pushing people to use it for communicating about their plans for network changes. Protocol changes etc.

The problem is that Amaury refuses to use the list. When I confronted him he got angry and stated that discussions were not needed. What is equally worrying is that he directs all code changes to his private site instead of somewhere industry interested people might actually see it. As Justus Ranvier said, where is the specification?

@singularity I think the idea you post is nice, but I want it to be stronger. Less dependent on good-will. Because exactly that has been missing.

I also think the problem stems from the private communication with miners. The miners accept or reject changes, so you can see them like the voting part of the government (lower house or whatever its called in your country's democratic system). This was shortcutting the system..

What we saw was a decision for a hard fork with all the details ready made, agreed by miners and within 24 hours reported by a large number of professional sites, sealing the deal. This obviously was the result of massive private communication and coordination. It was well-planned with a timing that makes is hard to impossible to reverse.

On top of that, the ABC guys wrote a press release that clearly is intended to make it seem that they are the stewards and specification writers of BCH. No spec anywhere other than in their press release!

The problem I observe is not that one team didn't want to talk to other teams. The problem is that miners decided on a technical spec before that was made public.

As I said, there is likely a lot of overlap in your proposal with this thinking. Sorry for being very verbose.

I think the main goal is not so much that we make the developers sign something (though I'm fine signing your doc), its more that we need most miners to agree they will not sideline process like this again.

Adding to the proposal; we would benefit from a structure and a timeline (minimum time for review etc) where protocol changes are made public for not just miners but also developers to comment on it. Maybe a week for comments and another 3 days until the miners votes have to be in.

Naturally, after this stunt I have strong doubts that this will work. Miners and Amaury will just do the same thing and we are left standing with our d*k in our hands and software that is incompatible with what the miners are doing. But, he, got to try, right?
 

Dusty

Active Member
Mar 14, 2016
362
1,172
Incidentally, I am not sure that the EDA is anything that actually needed fixing.
Really?
Actually the user experience is terrible with moments where txs are confirmed in seconds/minutes and some other times in hours.
The bitcoin cash chain has around 8.000 more blocks and around 100.000 more coins mined.
Everybody (including me) is worried about that problem and I can understand why Amaury wants it fixed asap.

Also, and more importantly, there are moments where the chain goes on only thanks to benevolent miners: if all the miners would be 100% rational the chain could stop abruptly.

@jbreher, I can agree with the rest you wrote, though.
 

Tom Zander

Active Member
Jun 2, 2016
208
455
I am concerned about long term mining profitability and removal of 2016 block calculation. This does seem to support manufacturers over miners.
One of the things I've been missing is the reason for all this. Yes, the EDA is broken (I wrote a lot about that on yours), but what requirements were used to choose a different algo. If we look at this great overview of the history;
we realize that there was disagreement about exactly that between Neil and Amaury.
 
  • Like
Reactions: Dusty

jbreher

Active Member
Dec 31, 2015
166
526
Really?
Actually the user experience is terrible with moments where txs are confirmed in seconds/minutes and some other times in hours.
Really. While the Bitcoin Cash UX is suboptimal, I am unaware of any transaction that has taken more than two blocks (i.e., less than one day) to clear. Bitcoin Segwit? Can't make that claim.

I rather expected this to work itself out after some time.

Indeed, I'm not so sure this is not a panicked reaction induced by Dragon Den ridicule.

Further, we're tweaking further things which will have long term repercussions. There will be a price paid some day.
 

Mengerian

Moderator
Staff member
Aug 29, 2015
536
2,597
I just posted BUIP068 to provide authorization for BU funding the next "The Future of Bitcoin" conference.

The tentative plan is to hold the conference in Tokyo, Japan, 23-25 March 2018.

Following the success of the previous conference in Arnhem this past June, we hope to make this next one even better! Hope to see you there!
 

Mengerian

Moderator
Staff member
Aug 29, 2015
536
2,597
@singularity It's certainly worth considering.

The problem is that there are many factors influencing the choice of date. For example we don't want to conflict with the conference in Curacao March 2nd (http://fc18.ifca.ai/bitcoin/index.html). And we want to be there in cherry blossom season. There may have been other reasons also that I'm forgetting.

But I will see what the others think, it would make sense for people who want to attend the creditor meeting and the conference to schedule them close together.
 

singularity

Member
Aug 17, 2016
50
132
Cherry blossom season in Japan is truly stunning, so that is a very good choice on that. Last year it was estimated to be from 21st March onwards.

Anyway, just a suggestion. I was planning to go to the creditors meeting so I might be able to stretch it to the end of March as well.
 
Last edited:
  • Like
Reactions: Windowly