Originally I think I was hosting 12 contracts and then each time I close and open the application, the indication of the # of contracts keeps going up by that number. But I think the hosting of those original contracts is still valid. Not sure if this answers your question.
I have just updated the blog post to reflect a change to the API - 'minimumXXX' is now 'minXXX'. These commands were changed when we upgraded to v1.0.0, but the blog post was never updated to reflect that.
minuploadbandwidthprice, minstorageprice, and mindownloadbandwidthprice are now the correct settings.
I was wondering where this kind of commentary was last year when the hollow men made all the noise. To me, it is obvious that a hard fork is not worth discussing.
By all means, a hard fork is an attack. Your afterthought is very important because a fork can hardly replace Bitcoin.
By any standards the legal consequence can only be,
§0 Bitcoin = treaty
§1 Bitcoin can not be changed (beyond changes allowed within the treaty)
If you where to replace it you would be in breach of the treaty. Thus the replacement is void.
I see one loophole left that could allow a fork to succeed Bitcoin. This would require that Bitcoin (see §0) is declared retroactive invalid (e.g. culpa in contrahendo doctrine, 'Schwebende Unwirksamkeit').
This would need an agreement between all participants.
I disagree, thus, not all participants agree, thus it is void. - Period.
Interestingly, I wonder if the Hague Conventions (or Geneva additions) apply mutatis mutandis. Otherwise the stronger will inevitably triumph.
PS: Those who would trade in their Bitcoin for temporary space on the Blockchain deserve neither.