Thursday, 10 April, Year 6 d.Tr. | Author: Mircea Popescu

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.i

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 scriptsii
  2. The introduction of a counter prefix, to be included for all orders.
      This would allow narrower control on the client side of signed ordersiii and also would allow stronger timestamping of ordersiv.

      This would also break backwards compatibility. Client scripts currently working on MPEx would work no longer. Perhaps more importantly, particular edge usecases may become intractablev.

In closing, let me point out that the RFC process is not exactly a vote, but moreover an opportunity for good arguments to be madevi. 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 venuesvii 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! []
Category: MPEx
Comments feed : RSS 2.0. Leave your own comment below, or send a trackback.

11 Responses

  1. 2 does not seem to actually break the use described in footnote 5, as long as one creates a stat after every order and creates the safeguard pushing after each stat. Unless the key becomes somehow lost in between the order and the stat, at any point either one or the other set of safeguards should be valid. Obviously the script would need to number them correctly but this is trivial. From what I understand stats are good practice anyway.

  2. Mircea Popescu`s avatar
    Mircea Popescu 
    Thursday, 10 April 2014

    This is a good point, inasmuch as the only change possible is an increment and the only one capable of causing the count to change is the client, it should not prevent the client from implementing the described safeguard.

    This leaves open the question of what MPEx behaviour should be if it receives a message with a count larger than current+1 (obviously is the count is less than or equal the message is to be discarded) : should it be discarded ? Should it be accepted and the count ignored (ie, if the count is 5 and you send a 7, MPEx just pretends it saw a 6) ? Should it be accepted and the count accepted (ie, MPEx jumps from 5 to 7, there's no 6) ?

  3. I suppose jurov will be pleased.

    As for myself, I only have one comment: what about a MPEx instance for testnet?

  4. Count greater than (counter + 1) should be accepted and the mpex count increased to match. If mpex only increased its count by one, then I can send the same order an arbitrary # of times as long as I use a big count.

    If mpex only accepted orders with (counter + 1) then I would be forced to do a stat before an order, and could not use an intuitive and easy counter (unix time).

  5. Mircea Popescu`s avatar
    Mircea Popescu 
    Thursday, 10 April 2014

    Yes, but if MPEx increases the counter to match you end up with this problem wherein if MPEx claims it saw 7 after 5 and therefore rejected any ulterior 6s whereas the customer claims the 6 was sent after 5 and then 7 you have an intractable conflict.

    Whereas if you sign orders which are higher than count+1, you knowingly undertake the risk that the order could be in principle repeated a finite number of times (equal to the extra count space you left).

  6. I should sleep on this, but at first glance this is rather unpleasant.

    I have strived for coinbr users to be able to place orders independently without locking each other out, but the mandatory counter prefix means this must be thrown out and orders queued, inevitably leading to large latencies at events such as BitBet IPO was. Oh, and since we're talking about latency, you're here pretty much throwing out of the window the MPEx's advantage to receive orders via irc/pastebin/email. User will either have to wait for mpex reply to arrive, and then place next order, or pray for his orders arrive to mpex in right order.

    Just by the way, from my DBA stints I know implementing reliable and continuous counters is PITA, requires locking the world and thus tends to be a drag on whole system. I hope you won't regret it in future.

    I'm really surprised you consider the backup as per footnote (v) just an unimportant and fringe use case, especially considering Cardano !? Currently the Cardano fits here nicely, when it gets zapped and GPG keys destroyed, just dig out the papers with prepared PUSHes. After this gets implemented, one has to generate PUSH commands every time anew and there will be time windows during which no PUSH is valid. Again, in case when there is no low latency way to reach mpex, this window can become unbearable.

  7. Mircea Popescu`s avatar
    Mircea Popescu 
    Friday, 11 April 2014

    Well if the broker unanimity is that this sucks it ain't happening.

  8. Oh. The point 1 is actually fine and good improvement. I had issues only with the second one, mandatory counter prefix for all commands.

  9. I’m really surprised you consider the backup as per footnote (v) just an unimportant and fringe use case

    Why? Maintaining backups of your private key and maintaining backups of your signed push transactions boil down to the same thing. Easier to just keep your key safe.

  10. @anon Cardano will not allow backup of private keys. Also it's not the same thing, storing signed PUSHes do no need such stringent security as storing gpg private key. You can even give them to someone else to execute them if required.

  11. Mircea Popescu`s avatar
    Mircea Popescu 
    Saturday, 12 April 2014

    Well yeah but they kinda work together.

Add your cents! »
    If this is your first comment, it will wait to be approved. This usually takes a few hours. Subsequent comments are not delayed.