MPEx.RFC.1

So I had some changes made to the way MPEx works. Unexpectedly, inexplainably and mindbogglingly ; and also in complete breach with both practice and tradition in Bitcoin space up to this point, I have not

• written out the code myself, preferably while drunk, directly on the production servers ;
• forced protocol level changes that make previous tools malfunction without telling anyone in advance.

How about that!

The code is written, and tested already, but MPEx does not work this way yet. Such luxuria allows me to establish (at least to some degree of confidence) that what I'm about to propose can actually be done and would work in practice, so I avoid the unpleasant edge case where we have a discussion, we agree on some steps forward and then a few weeks later either I say "you know what ? can't be done after all" or, even worse, simply don't say anything, jus'... nothing happens. Like you know, all the idiots.ⁱ

In this light, the proposed changes are as follows :

1. The introduction of an order counter for your orders, to be displayed in your STAT/STATJSON.
   This would allow you to directly verify that no extra orders have been introduced since you last talked to MPEx. If your bookkeeping shows your last order was 15`835 and MPEx STAT says your last order was 15`835 all is well. If not, there's a problem somewhere.
   
   This would also require a re-write of manuals and client-side scripts to take advantage of the new feature. It would not, however, break backwards compatibility, at least not for properly written scriptsⁱⁱ
2. The introduction of a counter prefix, to be included for all orders.
   This would allow narrower control on the client side of signed ordersⁱⁱⁱ and also would allow stronger timestamping of orders^iv.
   
   This would also break backwards compatibility. Client scripts currently working on MPEx would work no longer. Perhaps more importantly, particular edge usecases may become intractable^v.

In closing, let me point out that the RFC process is not exactly a vote, but moreover an opportunity for good arguments to be made^vi. This matter will stay open for a couple of months, and will be publicised during that interval, after which it will be closed in some manner and we take it from there.

Please contribute your comments below in the comments section rather than directing them at me in other public venues^vii so we can keep track of the discussion to some degree.

1. Let me restate the related point that everyone in Bitcoin, without exception, is doing corporate communication (which they mostly call PR, except there's scarcely a "public" yet) wrong. Please re-read the Strategic superiority article many, many, many times. [↩]
2. I suppose if someone were scrapping STAT rather than parsing STATJSON and doing a sufficiently inflexible job of it this'd render STAT reading inoperable. [↩]
3. Currently, as far as an order has been signed by the client, it can be introduced and will be accepted by MPEx at any future point, period. The only way to invalidate a signed order is by it having been seen by MPEx and thus executed (or discarded for some reason). [↩]
4. Because of inherited weakness from pgp's own timestamping, there is currently no reliable way to resolve time disputes : the client can very well present his own version (as included in the signed material), MPEx will present its own version (as reflected by when it has seen the order) and no further progress can be made (for which reason MPEx' determination is final). [↩]
5. Of particular interest here is the lost-key-safeguard as discussed multiple places including #bitcoin-assets. As it stands right now a sufficiently paranoid user could :
   • Generate and keep safe a spare gpg key ;
   • On each STAT call to MPEx, automatically generate PUSH orders for all held symbols, towards the spare key (in the case of symbols held in the book, CANCEL orders followed by PUSH orders).
   • Should his MPEx key ever become lost through whatever process, introduce the spare key as his key, introduce all the pushing and recover.

   Thus a potentially disastrous "lost my MPEx key and with it all my assets" reduces to a "lost my MPEx key now I have to pay for a new one". There's obviously no limit of chaining, in principle the spare key could have a spare key which in turn could have a spare key, and in a string of however many keys, unless ALL are lost, a sufficiently long succession of pushes would eventually result in a usable account. Alternatively, one could include the key of a trusted broker or two in his safety chain, and so should his MPEx key become compromised, he could just ask that broker to take push delivery and reallocate shares. Turns out MPEx' apparent simplicity actually belies a lot of depth, whodda thunk it. [↩]

6. The difference between practical and theoretical discussions is that in the case of the former, the participants are always qualified (ie, you don't get a vote unless you're a party to the discussion) and for better or worse, what they vote for is right and everything else wrong, irrespective of any rational considerations. Voting is not anything else nor was it ever anything else than a recourse ad baculum, the sovereign aristocrats of yore gathering together to see what they'd have to do in order to not have to crack each other's skulls open. Meanwhile in the case of the later the participants are not qualified, and they also have absolutely no authority (ie, no matter how many armored divisions you have, nobody cares, your word counts exactly as much as the Pope's). [↩]
7. And absolutely no private messages dear God! [↩]