Circulex: designing a people-friendly payment system
Support the designer of circulex, a work-in-progress system that aims to enable payments to anyone, anywhere, via chains of human trust.
Wellington
I'm designing circulex, a system that should make it possible to make cheap, fast, private payments across any currencies and any borders. The system is based on circular exchanges that flow around chains of human trust — hence the name circulex.
The design of the system will be open and free for anyone to read; and anyone with the skills will be able to build their own apps that work with other people's apps, together forming a network that anyone can join. In fact, you can already read the incomplete draft of the specification at https://circulex.nz
I'm trying to make it as hard as possible for any one person, company, or authoritarian government to control or spy on payments. And that includes me! I don't expect (or want) to have a privileged position in the network when it's up and running; I'm doing this for the public good.
But I do still need to eat. I've been working on this for a while without any significant income, but that can't go on forever. So I'm asking generous people to make a contribution, so that I can continue to concentrate on this, instead of having to spend my time and energy getting an income from another source.
I've set the fundraising target at a level that I think will keep my household going for a year, which is how long I've set this campaign to last. We live frugally, and we're lucky enough to live rent-free, so this is a lot less money than a lot of households need!
Use of funds
The money will be paid to Tim Makarios, and used at his and his wife's discretion. At present, their main expenses relate to food and housing, followed by other common household expenses, such as electricity, an internet connection, and clothing.
Other page links
Latest update
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.
Latest donations
Thank you very much for this generous donation!
Thanks so much for this generous donation!
Who's involved?