Back to page

Circulex: designing a people-friendly payment system - Updates - Givealittle

  • ASN.1 definitions drafted     15 May 2019

    In my first update, I mentioned that I was considering solving the encoding problem by writing ASN.1 definitions for the protocol, and using one of its encoding schemes. Since then, I've been working on writing such definitions, and I've now finished a first draft of them, which you can read at https://code.freespoken.nz/diffusion/1/browse/master/asn.1/

    As I suspected it might, ASN.1 has made it easier to specify precisely what data should be used as the input to cryptographic hash and signature functions, without forcing instances to store any of the exact strings of data that they send each other.

    ASN.1 has also made it a bit easier to make changes to the protocol without having to rewrite my English prose until I've made a final decision on those changes. But I do now need to do that, so that the PDF specification matches the ASN.1 code. This is the next thing I plan to do.

    One thing that ASN.1 did make me think a little harder about was how to allow for permissionless extensibility of the protocol. With JSON, whose objects use strings as keys, I was hoping that people could experiment with, say, demurrage, by using the string "demurrage" as a key in a JSON object. This would be unlikely to clash with someone else's experiment using the key "dividend", for example.

    But most of ASN.1's encoding schemes don't use strings that way; they use numerical tags, instead. This would make an experiment with dividends using the next available tag (3) much more likely to clash with someone else's experiment with demurrage that also used tag 3.

    My current draft deals with this by reserving tag 0 for experimental uses in certain places where I anticipate people might want to extend the protocol. The idea is that they can use tag 0 while it's experimental, with the understanding that if their experiment later gets standardized, that standardization can involve the allocation of a permanent tag that doesn't clash with anyone else's. This does require a little bit of global coordination, but it shouldn't be too onerous if all you have to do is tell IANA that you want a tag allocated, and give them a link to the document where you specify your standard.

    After all that, I still haven't quite decided on the encoding scheme for circulex, but I think the question has been whittled down to whether I write "DER" or "COER" at the relevant point in the specification.

      0 comments  |  Login to leave a comment

  • Plumbing     28 February 2019
    Main image

    While most of the money that's been given here has been spoken for by food, I thought it might be interesting to share something else we've used some of the donated money for: plumbing.

    A few days ago, the pipe taking water from our wall into our toilet cistern started dripping. Tightening the connection didn't seem to help, though eventually the drip seemed to start coming from a slightly different part of the pipe, suggesting, to my untrained self, that the pipe was at fault, rather than the thing in the cistern that it was connected to.

    So today, we went and bought another flexible pipe — the right shape, unlike what was there when we arrived — and thankfully, the task was simple enough for me to complete myself (with my lovely wife cutting lengths of plumber's tape for me). We've had to have plumbers in before, and I wasn't looking forward to having to pay again what they normally charge.

    Thanks to your donations, and others, we can still afford to eat; and God willing, if we have any more unexpected expenses, they, too, won't amount to more than about $17.89.

      0 comments  |  Login to leave a comment

  • New section on how circulex will work     14 February 2019

    I've been making a bit of progress on the specification document. You can read the most recent version at https://circulex.nz/assets/pdf/circulex-specification-incomplete-draft.pdf

    The biggest change is the appearance of a new section explaining how circulex will work. The introduction already gave a bit of an overview of how it works, but the rest of the document plunged the reader fairly quickly into the fine details. Now there's a new section 2, bridging the gap.

    I figure this will be useful for at least two kinds of people:

    * people who are curious to understand a bit more about how circulex works, without having to understand every detail, and

    * people who want a mental model of how it works, so that when they read about each detail, they'll know how it fits into the whole system.

    What next? Next, I'm planning to work on technical details again, so you can stop reading here if you aren't interested in those. The current draft specifies a somewhat strange mixture of JSON and artisanal hand-crafted byte-strings. On a friend's recommendation, I'm considering specifying the data structures in ASN.1 and using one of its canonical encoding schemes (such as DER). There are other options, and I haven't made a final decision yet, but I think this is my favourite candidate at the moment.

      0 comments  |  Login to leave a comment