"Slots" Proposal (kv db for miner pubkeys and more)

[mcelrath]

I propose a key-value database (kv db) for the purpose of tracking communications pubkeys for participating miners. This db is separate from the UTXO set of shares.

Braidpool needs to keep track of ways to communicate to miners, both IP addresses and encryption keys (I'm assuming ECIES). This is non-financial data but necessary for the system to work. There are numerous things in the proposal that require private communication between a pair of miners. For example, imagine a new miner joins the network and quickly mines a Bitcoin block. He would now be part of the quorum required to sign the FROST output paying everyone. He now needs the pubkeys and IP addresses of all other miners in the quorum. Now for this specific example, this information is committed to in the beads and can be reconstructed by downloading the history for the current and previous epoch. (At an epoch transition we must include signers from the previous epoch or we would have no signers)

Now this can be just an internal data structure, kept by Braidpool nodes and filled by requesting the bead history. We could also commit to its state via a compact hash, allowing new miners to download and validate this kv table more compactly, without history.

Or we can open it up. OpenTimestamps and Mainstay are valuable projects that allow third parties to commit to data in a non-identifiable and identifiable way, respectively. Committing to an identifier (Mainstay) instead of the data itself (OpenTimestamps) allows for instance parties negotiating a contract to iterate through several versions while always being able to validate it. It allows proof of ownership of off-chain data like inscriptions or art without actually including the data. We can further commit to the entire table in bitcoin blocks we mine, making it easy to validate without being a braidpool peer.

Assuming the data in the kv database is a pubkey, it also allows transfer of ownership of that data, if we create Braidpool (share chain) txs that allow changing of this database. In the primary use case of miners, this would allow miners to rotate their communications key without changing their custody/asset key. It's important to keep these separate so that miners can keep their assets offline and not use the same key for both communication and asset storage. In the case of non-braidpool data, it enables transfer of ownership and changing of the committed data (contract negotiation).