Clarification of What is a Ship and How one comes about

[eaterjolly]

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.

[cgyarvin]

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).

[galenwp]

(We haven't really talked about it much publicly since it's still basically being tested — but https://urbit.org/fora is a good place for this kind of post too!)

[eaterjolly]

So a comet is technically the hash of a public key, but wouldn't it be simpler to make it the public key itself? This way there would be no feasible way to try and transfer it. I know it sounds like a nuance, but the consideration is made out to anticipating that a new user may understand the protocol (through access to source code alone) and see it as technically feasible however be ignorant that the network would see that as malicious.

I personnally foresee that the future will have much simpler baremetal programming and networking, so I feel it would be reasonably easier in the future to know what types of data urbit sends and when than to know how it goes about creating that data, at least for a novice. In a sense, it's kinda like a child experimenting with microwave settings, for some one more senior it might be easier to google the question or locate the instrustions, but that all requires resources not immediately available. So either they can actually studying the source code of the microwave (that just sounds rediculous, but assume it came with a usb plug in and runs on javascript or something with just-in-time compiling) or they can mash buttons and see what it does.

In these cases, I would figure that in the view of the child creating useful packets is the purpose of the code (that and receiving them, but for a first time user the later is less likely to happen). To study it, they would issue commands like they were mashing buttons and see what packets come out. If the child feels they need a packet the code won't provide, the instinct would be that this is a glitch and that it would be easy to just write one by hand than fix the code (a worse-is-better solution, what do ya know?). This would make a novice action or novice mistake, look malicious to the network.

It's probably better to assume we want messages to fit a standard where they look like the code is outputing each possible configuration of message optimally and there would be no reason to alter one for the sake of compensating for some kind of glitch.

[juped]

On Aug 3, 2016, at 12:01 PM, eaterjolly notifications@github.com wrote:

So a comet is technically the hash of a public key, but wouldn't it be simpler to make it the public key itself?

The obvious problem here is that the public keys are giant RSA keys. And even in crypto B, where they’re not, they’re still 512-bit keys.

But this is different from the will of a ship, which tells you its actual current key. Comets just have a special way to assert authority for their creation, which is self-signing rather than parent signing. Will updates are always signed by the previous will iteration.

[eaterjolly]

The obvious problem here is that the public keys are giant RSA keys.

I apologize, this is my ignorance on this matter showing. My experience with keys was been limited to light usage of gpg, and I had assumed the fingerprint was the public key and the rest was embedded meta-data.

That leads to the next question, why can't the fingerprint then be used. And, the answer which would be most expected would be that the fingerprint of an rsa key is it's hash..

If it isn't, then the question holds. If it is, then I resolve the crypto in our toolbox here is quite limited.

---

I also noticed it implied somewhere that moons can't be transferred. This is an interesting curiosity, but a totally different question, nonetheless.

[juped]

“key fingerprint” is a term of art meaning “fixed-length hash of a public key”.

On Aug 3, 2016, at 1:26 PM, eaterjolly notifications@github.com wrote:

The obvious problem here is that the public keys are giant RSA keys. I apologize, this is my ignorance on this matter showing. My experience with keys was been limited to light usage of gpg, and I had assumed the fingerprint was the public key and the rest was embedded meta-data.

That leads to the next question, why can't the fingerprint then be used. And, the answer which would be most expected would be that the fingerprint of an rsa key is it's hash..

If it isn't, then the question holds. If it is, then I resolve the crypto in our toolbox here is quite limited.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[eaterjolly]

I appreciate all the clarification here. Really the only thing perhaps that deserves more WP:DUEWEIGHT as they say in the wiki-world, would be that a ship is a name attached to a long rsa public key.

I imagine that information would eventually be a crucial distinction to anyone trying to explain how urbit works to a friend or wants to use a pre-existing key pair (if say they want to associate their urbit, with their bitcoin purchases).

[eaterjolly]

urbit/docs#86 I made a fork. One probably could do more to clarify besides just this small edit, but it's my proposal for a stop-gap measure atleast.

@galenwp Unfortunately, it doesn't seem to allow me to post as a comet and I lack a device with the 2gb ram required to run urbit atm, so there really wouldn't be much point in getting a planet. I am very much interested in the network system urbit uses, as I find the current DNS system prevalent to be economically unethical as well the ipns system in developement seems impractical with much a decentralization theater about it too. I very much interested in how peers authenticate and the roll of the hierarchy, because it seems like it would very effectively replace the need for ipns, if one could implement a system where a static versioned "will" could be checked against the urbit network for a newer version and therefore contain a newer ipfs address in its meta-data (possible?) satifying the mutability requirements of an ipns.

Hence why the two issues raised about the documentation regarding a clear lack of coverage over how the network works. I realize that's the heaviest area of development and however, while it has as much potential as nock itself, to maintain that potential requires caution. I says that says a lot about the integrity of the development team here, because, between all of the projects successfully developing better-is-better solutions for a web 3.0 ipfs and ethereum included, where all of them seem to very momentously be solving a single theoretical problem, all of them also seem to have attempted and failed at solving other theoretical problems (ethereum with swarm; ipfs with versioning). The team working on urbit have been distributing their momentum across 3 major theoretical problems, with no forsee-able stall (a human read-able assembly/bytecode; a computing environment simple and robust enough for a single individual to understand all functions within a reasonable period of study; a fair address space with an democratic/autocratic rather than strictly fiscal distribution of names/titles and deeds to namespaces).

Deeds to namespaces, is an interesting concept and I hope I'm not wrong on that aspect of wills that it could carry addresses and associated names in it's meta-data all cryptographically signed. It would make sense and seems congruent with the analogy to "land". This way a website could be just called wish, no dot-com or anything, so long as both the entire council of stars and the entire council of galaxies agreed to carry the name in the ~zod meta-data associated with the latest ipfs address agreed upon by both. This implies a democratic representation of humanities culture once fully decentralized. This is truly exciting to say the least! However more documentation is needed to provide more transparency going forward. The most wonderful part is a quite conscientuous fiscal support model (replacing the broken DNS system which rewards registrars more the more abuse in the name system exists (through escalating prices in place of judicial awarding of names) directly incentivising collusion and corruption) where they sell an opportunity to be a leader away. When the system is young and already full of corruption, a single honest novice is a shining glimmer of hope as bright as the sun no matter the level of mistakes and folly they commit. Literally anyone can assume the roll of leading a galaxy or a star, because so long as the majority are honest (or even a small minority) the people can eventually revolt (but with a corrupt DNS, they will be much easier to please than one might imagine). It's beautiful. The ruling elite already possess the culturally inspired burden of noblesse oblige; they are more likely to be ethically conscientuous due to their inherent lack of fear of what might happen should they not work (a lack of fear which gives them time to think about the morality of what they are doing) so selling for increasing prices the stars and galaxies is much more likely to produce honesty than distributing randomly, because one can assume if they have the spare time to understand urbit then they are likely underemploying themselves which means they are in a stage of life where they are trying to be philosophical which means they are more likely to be honest about what ever they are planning to do next. It is admittedly a gamble from my perspective, but it's a damn good gamble and a damned better one than any other option we have to take (as a human society). I don't think I would have been able to develope that clever of a strategy on my own had I been commissioned to. I mean, on it's own it's a simple hierarchy, what's so hard about that, right? But, look closer: the pre-fixing, the free comets (a failsoft mechanism to keep things running should a heartbleed vulnerability hit), the councils being hardcoded in a publically available source code which automatically updates accordingly (of course all this is reverse-able since the source is programmed in a specially designed language designed to be comprehended in as little time as possible), giving people the option to rebel any decision encouraging them not to and honestly explaining why a state of anarchy caused by their wouldn't be world ending but more of just a hassle for everyone. It's honest, it's ethical, it bites a just little like any truth about reality I've ever known.. what else is there to say? The only people who would be interested in buying a star or galaxy, would have to be really foolish or someone who thinks they can handle that kind of pressure.

tl;dr If I could, I would have made this part a fora post [and edited it a bit more]

[eaterjolly]

After my fork being merged, I consider this issue resolved. [For the most part.]