pull down to refresh

I think they're most likely to be used as an attack vector and there's risk to them inadvertently not agreeing on consensus rules. If Core fails to fulfill its obligation one day, then they will need to be replaced. Obviously, it would take some time for that transition to occur and it will be a bit hairy, but ultimately, you'd want Core 2.0 to take over.

Have you read Voskuil's Cryptoeconomics or followed much of his work on the libbitcoin node implementation?

reply

I have not, but libbitcoin rugged people, so that's enough of a reason for me to dismiss Voskuil and his stuff.

reply

I'd disagree with the characterization that libbitcoin rugged people. I think it was a case of Voskuil being stubborn and people using testing instructions as a guide for production software. But i don't really have a pony in the race.

I've learned a lot about Bitcoin from Voskuil. And of all the alternative implementations, I'd say libbitcoin is the most interesting.

There's also something called Hornet Node being developed by Toby Sharp. As much as I agree with the idea that I want my node and wallet software to have the absolute maximum of eyes on it and review, I don't see how we continue very long with only one primary implementation.

reply

Okay, that's fair.

Some other issues are you have to cannibalize engineering resources to review the other implementations, so I'd rather have all of those resources looking at just the one. And even if we reach a point where there's an abundance, if two implementations disagree on the state of the chain, which one is correct?

reply
110 sats \ 1 reply \ @Scoresby 12 Jul

yes, the "which one is correct" problem is real. I don't really know the answer to it, but I've always had a bit of a knee jerk reaction against a single dominant implementation.

One counterargument is that every single version of Core is really a separate implementation and we could just as easily have a problem where a new version disagrees with a previous version and we won't know which one is correct.

Personally, i think I'm willing to risk the messy situation in order to have options.

As to cannibalizing engineering resources: there are quite a number of very good developers who don't work with Core (for various reasons), and in the case of a dominant implementation, it's not surprising that there are interpersonal conflicts (we are all human). The problem is it's hard to do any effective work without someone or some group being in charge.

I've also appreciate Jon Atack's commentary lately. He strikes me as someone who is a solid engineer, but who has found it difficult to work with the main Core repo. I don't mean to imply that Core engineers have done anything wrong, but rather that it's difficult to expect all people who want to work on Bitcoin to get along with the leadership of a single project.

reply

I think the version that didn't create the conflict would be the real Bitcoin, all else equal. Core would figure out what went wrong with a much lower likelihood of a competition developing over which one is the legitimate one.

Yeah, I'm not suggesting anyone who works on Bitcoin would be a Core contributor, but to get another one or two implementations with enough eyes on it to be comparable to Core would require a lot more people.

I'm not familiar with Atack. I just found his Twitter handle though. I'll give him a look.

reply