[urbit] Re: [urbit/docs] Clarification of What is a Ship and How one comes about (#85)

[Curtis Yarvin]

To say that a public key implies a comet is slightly not-quite-right. A
key is not a ship. Possession of a keypair whose public key hashes to a
certain 128-bit number implies the right to create a comet whose address is
that number. But in theory, that comet could even rekey and transfer its
ownership to a new keypair -- I don't know *why* anyone would want to do
this, but it's technically quite possible.

At present the parent of all comets, at least for routing purposes, is
~zod, which is quite unsatisfactory in practice. With the new elliptic
curve crypto, creating a keypair is trivial and does not involve a slow
primality test, so we could have the parent be whatever galaxy matches the
low byte of the comet's address, or even whatever star matches the low
double-byte. Of course the comet creator would have to know which
stars/galaxies are actually active.

"Pre-mined" (which is just a pejorative in the Bitcoin world, a pejorative
that it's better to own than avoid) just means that the whole address space
<64 bits is transitively created by the developers of Urbit. IPv4 and the
DNS are premined in the same trivial sense. Comets are not in any sense
premined (or mined, though it would certainly be possible to put hashcash
into comets).

After spending sometime considering what it could possibly mean for the
address namespace to be "pre-mined" a wording I realize to be absent from
the docs, however still confusing.
If I'm correct, the urbit network requires each peer to retain 3 unique
bytes of data. A public key, a private key, and a ship. The public key is a
comet, effectively. It is used in combination with the private key to make
signatures on urbits. Ownership of a ship by a comet is confirmed
informally and then formally signed by a hardcoded entity, or appropriate
child thereof. Once the comet's planet is publically established, any
signatures corresponding to the elliptic-curve of the comet will be assumed
to belong to it's parent. Sovereignty implies that a planet not only speaks
for itself that it can not act on behalf of its parent even if it wanted to
(it wouldn't be trusted). Essentially every ship, sovereign or otherwise
requires a direct comet, in order to indicate a message directly from that
step in the hierarchy, without it that ship is mute and can only speak
through it's children.
Beyond this, a rogue comet unlike a rogue moon is sovereign in that it
speaks for no one and has no parent. Due to a private key being the
associated, not even an unsovereign comet can be transferred, because
regardless of what ship it belongs to it has no prefix and can easily be
mimic-ed by former owners. Essentially anyone who has a comet is sovereign,
however no one has any reason to trust or recognized them so their
influence is effectively moot and/or second-class, trustless. This also
lends a point to having a moon, since a moon can be transferred. Otherwise,
the difference in treatment between a moon and a comet would be fickle and
volitile.
I may be entirely wrong here, but I guess based on what seems like the
most scalable and useful course with the highest potential, so even if I am
wrong it may be worth comparing with the reality.
I post this as an issue, because again it's just not a very clear aspect
of Urbit and establishing some firm semantics here would be useful for
documenting it.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<https://github.com/urbit/docs/issues/85>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/AALyAYVw8kfniRANfQHFilT_VIPfJ-giks5qcA1DgaJpZM4JbRWw>
.