Limenka - mission and design principles

0. the name

limenka is the serbo-croatian word for an aluminium can.

• limen (latin): the threshold, the edge, the border. limenka lives at the edge - never integrated inside, always on the other side of the border of approved currencies.
• the can: aluminium cans are money at the edge of society. collected on the street, they feed the homeless. a can retains value after its contents are gone.
• the metal: until the late 19th century, aluminium was more valuable than gold. the capstone of the washington monument obelisk is cast aluminium - chosen as a display of wealth because the metal was then rarer than gold. the hall-heroult process made it cheap and industrial, and it still retains monetary value despite wide industrial use.
• limenki: the plural, for the coins. one limenka, many limenki - the way you say dollars.

the name is the mission: a currency that stays at the edge, that remains valuable through use, that is never absorbed into the interior.

1. the auditability principle

limenka is based on bitcoin. it inherits pseudonymity by default - utxos are traceable. this is deliberate, not a defect:

• the fixed supply is the primary value proposition
• the auditability of that supply is the guarantee that backs it
• every privacy feature must preserve the auditability guarantee

contrast with monero: monero's name declares mandatory privacy, enforced fungibility of physical coins. limenka's name declares the edge. privacy in limenka is layered and optional; auditability is never negotiable.

2. the edge principle

• always on the other side of the border of approved currencies, never integrated inside
• no dependence on, integration with, or absorption by incumbent financial systems
• a currency that lives at the edge is not a currency that waits for permission

3. exchange policy

• atomic swaps only
• no centralised exchanges, no decentralised exchanges - both are third-party custody with different dresses
• bilateral, peer to peer, hold your keys or hold nothing
• a peer that cannot refuse is not a peer, it is a resource being extracted

4. fungibility strategy

fungibility is achieved in layers, never forced.

4.1 lightning first

• the primary route to fungibility is cheap, fast layer-2 settlement
• channels must survive unstable connections: dormant without force-close on either side, routing practical on flaky links. many of the defaults that make routing brittle are not necessary defaults
• block space scales with channel demand: when channel count exceeds block space, block size grows by factors of two. automation of this is future work
• the hard problem is not block space - it is getting people to run channels that route. that side is a separate project (fixing lightning), after moxie is finished and the moxie port is complete, based on btcd and integrating the optimizations and features of limenka (including gui, wallet, and the server only versus desktop versiions, and the separate cli)

4.2 confidential transactions

• bulletproof range proofs: amounts hidden, sums auditable
• the auditability guarantee is unbroken - the fixed supply remains verifiable while individual amounts hide
• coinbase outputs are never confidential

4.3 in-band onion-routed propagation

• full monero-like fungibility requires unbinding identity from the utxo during propagation
• sphinx-style onion routing for transaction propagation, built into the protocol, in band - a mixnet that is part of the chain, not bolted on from an untrustworthy external network such as tor
• transactions are onion routed in propagation; the identity is unbound from the utxo; after one or two layers of movement a CT utxo is properly fungible and private
• the mixnet can be lower latency than conventional designs - it carries transaction broadcast, not full traffic
• this is the answer to the monero complaints: monero-grade privacy acquired by use, without the mandatory-privacy tradeoff that monero made
• privacy is acquired by use, never forced

5. how features are devised

every proposed feature is judged against five questions:

1. does it keep limenka on the edge? - anything that moves it inside the border of approved currencies is rejected
2. does it preserve auditability? - the fixed supply must remain verifiable under every privacy feature
3. is it in band? - privacy infrastructure lives in the protocol; no trust in external networks
4. is it optional? - privacy is layered and chosen, not mandatory
5. is it bilateral? - exchange is between peers via atomic swaps; third-party custody is rejected

6. roadmap

1. finish moxie
2. port limenka fully to go - btcd based, built to feature parity with the c++ version
3. fix lightning - dormant channels, flaky-link routing, the routing liquidity problem
4. automate block size growth by channel demand