[Cryptography] Meet the New Owners (The Dangerous Blockchain)

[Ian g]

On 05/10/2026 04:46, Viktor S. Kristensen via cryptography wrote:
> Ian,
>
> Your post made me check our own work against "show me the contract". It was a useful and slightly uncomfortable exercise.


Excellent!


> The experimental chain I work on (SIGIL) did one thing right. Before launch we published a promise as plain text: no premine, the testnet is reset before mainnet, coins come only from mining. We hashed the exact words with BLAKE3 and timestamped them in Bitcoin with OpenTimestamps, because a young chain with a single block producer cannot credibly witness its own clock. The genesis code keeps the promise: zero coins at block zero.
>
> It also did the thing you describe. The code routes a fee from every block reward to a project wallet. That fee is mentioned in other documents, but not in the signed text. A holder who reads our one signed contract would not learn about it. The letter of the promise holds, and the reader is still short-changed. That is your un-enumerated failure, in our own house.
>
> What I intend to do before our mainnet launch, and I would value the list's view on the cryptographic part:
>
> 1. One mainnet charter in your format: prose plus parameter lines (max_supply, decimals, premine = 0, the fee in basis points, the halving interval), cleartext-signed and hashed.


Fwiw, the newer format is being documented in WIP here: 
https://github.com/iangfc/riccy NB this is somewhat inconsistent 
internally as certain issues haven't been resolved with the format. Feel 
free to grumble.

The reason I've gone for Markdown is that every programmer out there 
uses github, and it's the doco of choice there. Of the drivers that 
exist in this market, it's pretty much always the programmers that make 
the decisions. Longer rant elided.


> 2. The charter's hash goes into the genesis block header, so the chain's identity is bound to its contract. A different contract means a different chain.
>
> 3. A build test that parses the charter's parameter lines and fails the build if any constant in the node's code disagrees. The Ricardian design has the program read the contract; this adds the other direction, so the code cannot quietly drift away from what was signed.


OK, thinking about that. In a 'big chain' that might work. But many 
chains codebases are copied, so an element of parameterisation is 
useful. I spoke about this in "The Sum Of All Chains" way back when, 
there might be some interesting ideas within. 
https://financialcryptography.com/mt/archives/001556.html

An echo of this is the work to combine the Riccy with the Smart, and 
somehow lock the two as equivalent, whatever that means. That's a 
rabbithole I'll leave aside for today.


> 4. Every issued token carries the hash of its issuer's terms. No terms, no token.
>
> One small piece already works this way. Our dispute-resolution module seals the full terms of an order, not just its identifier, after we found a seal that covered an order's name but not its conditions.
>
> Two questions for the list. Is there a reason the second direction (contract checked against code at build time) is a bad idea that I am not seeing? And should a charter like this carry one signature, or a threshold of independent signers from the first day?


Some comments above. A threshold of independent signers is just a 
signature at the meta level, so that's really an implementation detail 
at the code level. At the feature level, I've certainly made room for 
many signatures but I have not defined them as threshold signatures. I'm 
not sure that's necessary at the lower level?

Having multiple signers to a single charter is very useful as a signing 
ceremony. The start of Zcash and EOS both had serious initiating 
ceremonies which would have been nicely improved if they'd signed their 
charter. IMHO.

iang