Quote from: killerstorm on November 23, 2013, 12:06:27 PM

Quote from: ripper234 on November 23, 2013, 06:20:01 AM

Alex, you have known me for enough time, I would expect you to rightfully assume I understand hardforks. In any case the answer is yes.

I don't think we need a feature freeze, we just need to think more carefully about the spec changes schedule.
Thanks for bringing this issue to our attention, I'll send it to our developers and J.R. for consideration.

Cryptocurrency is secure only under condition that there is a consensus among all clients. If you cannot guarantee that, that means that cryptocurrency you're developing isn't secure.

By "guarantee" I mean that you can prove that problem like that cannot happen under certain assumptions. Of course, bugs are possible, but you need to demonstrate that you're doing the best effort to prevent problems.

If you're piling on features instead of implementing secure update mechanism that means that security is a low priority for you.

I think this problem was brought up many time before, I don't see why it is news for you.

Hey Killerstorm,

This is essentially what we're doing, developing our clients to a consensus and locking in and updating the spec where there are areas of ambiguity. We're still very young so this is obviously a work in progress, but we have a very collaborative team that works together to ensure our respective projects are on the same page (state-wise) in their interpretation of the spec.

FYI from our internal discussions regarding hardforks:

Quote

Can anyone think of any scenarios where such an action would be required in an uncontrolled manner?

To me a hard fork implies at a certain block we decide to change something so fundamental it renders previous implementations unworkable - so our response would be entirely dependent on the situation at hand.

A perfect example of this was adding obfuscation to Class B - this would have been very different with backwards compatibility etc being built if there had been non-obfuscated transactions out in the wild, but since we thoroughly vetted it was just Tachikoma & my test transactions we could safely drop support without any impact and there was no change control variant needed.

This is one of the core reasons I've been quite restrictive with my releases of late, because I want to make sure we're all on the same page decoding/validation wise as changing something after the fact when its in the hands of users under real world usage would be a lot harder to manage.

Cheers
Zathras