Handling high gas prices

[Galen Wolfe-Pauly]

We've sometimes speculated about the price of a planet, and we've seen the market attempt to set the price, but we didn't anticipate it costing >$50 in gas fees just to get a planet spawned. 

Clearly, this is a pretty serious problem. We've been discussing it internally for the past few days, and I thought it was probably time to open the conversation up a bit and start talking with others in the community. 

We've been working hard to get the system (Arvo, Vere and Landscape) stable and reliable enough that we can welcome more people onto the network smoothly. We usually think about how we're going to do this in terms of bottlenecks we actually control — as in, making it easier to boot a node, improving the interface and making the system more reliable. 

High gas fees on Ethereum aren't directly under our control, but there are things we can do to work around them. 

Given our desire, in the near term, to let more people actually *use* Urbit from day to day we've been discussing roughly two categories of work: (A) what can we do in the near to medium term to make it possible for new people to use Urbit and (B) what we'd like to do in the long term to make sure the system is as robust as possible.

Both A and B are significant enough in terms of the discussion they merit that I think it could make sense to split them into separate threads. For now, we'll start with A: what we're planning to do as soon as possible.

A1 - 

The first thing we're going to start doing is pre-spawning planets. We want to have a surplus of planets on-hand for people interested in trying out Urbit, so we're working to figure out the most efficient way to get txs through with the lowest possible gas cost. 

One approach could be to simply submit with a really low gas limit and wait a few days, another can be to watch ethgasstation.info for dips in the gas price and submit during those windows. We may end up doing some of both.

Doing this means we're spawning to wallets that we control, then handing those to newcomers. This is obviously far from ideal in terms of custody. But it gives us a way to bring new people on the network for the time being. If they decide they want to secure their planets, they can rekey later. We're still working out the details of how this is going to work, but I'd be happy to share what we're up to if anyone else is trying to onboard friends and is up for paying the initial gas costs.

A2 - 

The second thing we're thinking about doing involves changing some of the logic for how Urbit authenticates planets. The basic idea is that we'd like new users of the network to be able to authenticate with an attestation from a star that isn't necessarily registered on-chain. Then, using that same attestation, a planet should be able to complete the spawn process at a later date.

I was originally approaching this from a slightly different angle, but Philip and Mark were able to refine it into something plausible. I'll let Philip chime in with his own proposal with the details. I think it's promising, as it doesn't require significant changes to the contracts and can be executed relatively quickly. 

If others have proposals on the 'A' front — feel free to chime in. We'd also be happy to get feedback on what we're thinking about here. 

As for the longer-term discussion, I'd suggest we start a separate thread when someone feels inspired to put together a comprehensive proposal or at least 'lay of the land' summary. There's a lot to discuss.

[Christopher King]

Glad to see you bring this up, Galen. It's something I've been thinking a lot about too. These gas prices are insane.

As far as part A, I am putting the finishing touches on a platform that will provide a turnkey, one-click service for purchasing an Urbit planet and getting it hosted. An additional roadblock that you didn't mention is opening the doors to non-developers who have heard about Urbit and are curious but don't have the expertise (or don't want the hassle) of running their own ship on a cloud provider. It's as simple as submitting a Stripe payment, waiting a few minutes for the ship to spawn and boot up, and then clicking a link that takes you to Landscape.

I try to avoid firm dates when possible, but the core functionality is done and I'm just at the stage of writing unit/integration tests for the code, so I'm intending to push hard over the extended weekend and hopefully get this out next week. A signal boost via official Tlon channels would be greatly appreciated when the time comes. I would be more than happy for the user testing from Tlon folks if you'd like to gain confidence before endorsing something. Mark from Tlon has partial familiarity with what I'm doing, as he has been providing occasional advice on interacting with the Ethereum blockchain.

I planned on waiting to announce this when it was ready to receive customers, but since this is related to Galen's post I figured I'd go ahead and throw it out there.

[Mike Gogulski]

Would it be possible to extend Azimuth with a spawnMultiple function that takes an array of (point, target) tuples? Spending $50 on a spawn tx wouldn't be such a big deal if I could being launching 100 planets at a time.

--
To unsubscribe from this group and stop receiving emails from it, send an email to dev+uns...@urbit.org.

[Mark]

> Spending $50 on a spawn tx wouldn't be such a big deal if I could being launching 100 planets at a time.

Spawning 100 planets in a single transaction is just going to make the transaction 100x as expensive, because of how these fees are calculated.

The tldr is that in Ethereum transactions, you pay for compute and storage with gas. During spawn, we initialize a bunch of data fields for the planet, changing them from zeroes to real values. This costs storage, and so it costs gas... and so it's expensive. Doing this for ten planets takes ten times as much storage. Disregarding a tiny bit of overhead, bulk transactions would just linearly scale in cost.

—
~palfun-foslup
https://urbit.org

[Basile Genève]

Thanks for kicking this off, Galen.

I've been talking about this a lot with ~rovnys over the course of the week, and wrote a proposal this morning that I'll post here.

I don't want to do a long preface, but there are a few principles that are informing my perspective:

- Verification games/L2 smart contracts are *really freaking hard* to get right. At least 2 orders of magnitude harder than the equivalent contract deployed to the Eth mainnet.

- Any crypto/asset system with moving parts and multiple interacting systems needs to be understandable for ~a bright 5th grader, or it will become intractable. (Not the crypto primitives, but the system architecture). Parts of my own proposal probably need to be pared down on those grounds.

- If Vitalik or whoever has proposed X Layer 2 system as doable but it hasn't been implemented yet, assume it would take 1.5-5 years to implement safely, if it's even possible.

- The gas issue for planets is real and pressing: we'll need to take on some technical debt to solve it, but that should be repaid quickly. This applies to a piecemeal version of my proposal, as well as to others I've seen floating around.

- Avoid decentralization theater: galaxies carry real load in Urbit, and even Azimuth on Eth is only authoritative inasmuch as galaxies all agree on it as a source of truth. An Urbit PKI shouldn't rely *only* on galaxies, but it should acknowledge and leverage their autonomy and real decision-making power.

OK enough caveats, без предусловия, сей же час:

https://gist.github.com/timlucmiptev/4630ab6f9c5d0b5bbfe8e36fdb7ad8a2

I don't have an ego in this, fine to scrap as necessary. I just want planets to work again. I also think it's worth considering very hacky/bandaid solutions as long as they're not built upon further afterwards.

[Mark]

Woah, that's a solid-looking proposal, ~timluc. Thanks for sharing! I may respond in more detail later (and I certainly invite others to do the same!), but for now I'll just gently agree with "probably need to be pared down on those grounds".

I wanted to share some points that came up in tlon-internal chat, to help clarify the situation and what kind of thinking goes on about this. Not all of us fully agree on these things, so don't take this as gospel!

tldr: using pre-spawned/custody'd planets dramatically improve the user experience without taking away sovereignty from those who care.

From Galen's opening email:

> Doing this means we're spawning to wallets that we control, then handing those to newcomers. This is obviously far from ideal in terms of custody. But it gives us a way to bring new people on the network for the time being. If they decide they want to secure their planets, they can rekey later.

It's no real secret that Tlon has been working on becoming an Urbit hosting provider. Reasonably, hosting providers might want to shy away from doing key custody, because it detracts from the "100% sovereign" Urbit vision, and can be a big liability.

Realize though, that Urbit key custody has always been one of the business models on the table, for people wanting to provide services in this space. Would you trust your grandmother with her own private keys? Would she _care_ about managing those herself?
For the bulk of "normal users", having someone (or some entity) take care of their keys for them is simply too convenient. It dramatically reduces the risk-cost of "what if I lose my keys", to the point where it's like a car: losing your car keys doesn't mean losing access to your car, as long as you can still prove it's yours.

You might already see how this is a good fit for hosting. You're already trusting the host with your running ship. Trusting them with the keys that own that ship is only a small step beyond that, and makes the whole process much more convenient.

Of course, the way we'll be setting this up (and I hope other hosting providers will too) will allow users on-demand access to their keys. If they fall into the digital sovereignty rabbit hole and realize they no longer want to trust their service provider, they can just get out. Take the keys, sign a one-time $50 transaction, and "upgrade" your planet to a fully sovereign one. Imagine if Coinbase let you do this...

—
~palfun-foslup
https://urbit.org

[Philip Monk]

I'll respond to a few things here, and then I'll propose something in a follow-up on this thread.

> we didn't anticipate it costing >$50 in gas fees just to get a planet spawned.

To be fair, we did expect that the Azimuth contracts as built would cause this eventually, but we were hoping it would take long enough that we would have upgraded our scalability by then.  Of course, gas prices may fall significantly in the short term, in which case we could delay again, but we'll have to deal with this issue eventually.

> Disregarding a tiny bit of overhead, bulk transactions would just linearly scale in cost.

This is correct, I'd estimate about 10-20% gains by doing bulk transactions.  It's worth noting part of the reason we gain less by builk txs than others is that NFTs require storage for each item.

> - Any crypto/asset system with moving parts and multiple interacting systems needs to be understandable for ~a bright 5th grader, or it will become intractable. (Not the crypto primitives, but the system architecture). Parts of my own proposal probably need to be pared down on those grounds.

This is incredibly important; it's probably the most important condition.

> - Verification games/L2 smart contracts are *really freaking hard* to get right. At least 2 orders of magnitude harder than the equivalent contract deployed to the Eth mainnet.

I agree with this, in the general case.  The only verification games I'm comfortable with are those which are incredibly simple.  For example, the ones in optimistic rollups are noninteractive and almost trivial -- just run the actual contract, with merkle proofs of the necessary data.  But even this is at the limit of acceptable complexity IMO.

> - Avoid decentralization theater: galaxies carry real load in Urbit, and even Azimuth on Eth is only authoritative inasmuch as galaxies all agree on it as a source of truth. An Urbit PKI shouldn't rely *only* on galaxies, but it should acknowledge and leverage their autonomy and real decision-making power.

I agree in a sense, but I also think, all else equal, it would be good for galaxies to give up more power over identity.  Right now the galaxies can vote to mechanically change the rules of the Ecliptic contract, including to delete a ship.  While this is better than a system where they have to explicitly do work to support a ship (as in your design, where ~zod must include their txs and galaxies must vote in favor of such blocks), it would be better if their power were more restricted.

It's worth noting explicitly there's a distinction between those decisions which involve actual work and those which involve consensus.  For packet routing and software updates, a star need only find a single willing galaxy to do the work.  But questions of ownership rely on consensus.  I have little issue with galaxies taking on more responsibility of the first kind but not the second.

In particular, I'm uncomfortable with the reliance on ~zod in your proposal.  ~zod has never been special above other galaxies, except that other galaxies choose to sync their %home from ~zod.  Giving ~zod control over what order txs happen is a whole other level.

How do you intend galaxy voting to happen?  Just signing the block and broadcasting that on Ames?  Does this require a majority of galaxies to be online at all times?

Since any galaxy vote depends on knowing the keys of a galaxy, I assume we'd keep galaxies completely on the main chain.  That info is small enough that we can plan for that data to always be available on layer 1.

> ~zod has one additional round to post a rebuttal, after which the challenge ends.

What possible rebuttal could there be?

> If the transaction is still not included in the native chain, he posts a withdrawal request, along with an anti-spam bond. 4. ~zod then has X Eth blocks to post a Merkle proof of the transaction posted in a later checkpointed state. If he cannot, his bond is slashed and awarded to the censored user. If he can, then ~zod receives the user's anti-spam bond.

I like the idea of a transaction injector to get around censorship concerns.  I don't understand this completely though, how can we distinguish between "~zod is censoring the user" and "user never told ~zod about the tx"?

Overall, my biggest concern is complexity.  While the mechanisms you describe aren't *too* complicated, they're not obviously correct.  Perhaps there are ways to make them so, though.

On Fri, Sep 04, 2020 at 12:05 PM, Mark <ma...@tlon.io> wrote:

Woah, that's a solid-looking proposal, ~timluc. Thanks for sharing! I may respond in more detail later (and I certainly invite others to do the same!), but for now I'll just gently agree with "probably need to be pared down on those grounds".

I wanted to share some points that came up in tlon-internal chat, to help clarify the situation and what kind of thinking goes on about this. Not all of us fully agree on these things, so don't take this as gospel!

tldr: using pre-spawned/custody'd planets dramatically improve the user experience without taking away sovereignty from those who care.

From Galen's opening email:

Doing this means we're spawning to wallets that we control, then handing those to newcomers. This is obviously far from ideal in terms of custody. But it gives us a way to bring new people on the network for the time being. If they decide they want to secure their planets, they can rekey later.

It's no real secret that Tlon has been working on becoming an Urbit hosting provider. Reasonably, hosting providers might want to shy away from doing key custody, because it detracts from the "100% sovereign" Urbit vision, and can be a big liability.

Realize though, that Urbit key custody has always been one of the business models on the table, for people wanting to provide services in this space. Would you trust your grandmother with her own private keys? Would she _care_ about managing those herself? For the bulk of "normal users", having someone (or some entity) take care of their keys for them is simply too convenient. It dramatically reduces the risk-cost of "what if I lose my keys", to the point where it's like a car: losing your car keys doesn't mean losing access to your car, as long as you can still prove it's yours.

You might already see how this is a good fit for hosting. You're already trusting the host with your running ship. Trusting them with the keys that own that ship is only a small step beyond that, and makes the whole process much more convenient.

Of course, the way we'll be setting this up (and I hope other hosting providers will too) will allow users on-demand access to their keys. If they fall into the digital sovereignty rabbit hole and realize they no longer want to trust their service provider, they can just get out. Take the keys, sign a one-time $50 transaction, and "upgrade" your planet to a fully sovereign one. Imagine if Coinbase let you do this...

—
~palfun-foslup
https://urbit.org

[Basile Genève]

~palfun, just to follow up on paring down:

I'd be very very inclined to ditch the fraud proofs and bonding mechanism, and keep:

- high vote threshold to increase data availability

- one galaxy acting as leader to make state easier ("~zod" is a placeholder here for that). Basically choose consistency and availability of CAP

- Eth checkpoints (Eth or BTC checkpointing or similar is non-negotiable in any scheme imo)

- Eth-based "transaction injector" to remove the threat of censorship

That reduces you to one mildly tricky Eth contract (the censorship one, which could be plugged in 1-2 years down the line as an upgrade).

IOU and on-Eth planet upgrade schemes are the most promising I've seen for the immediate gas issue *iff* they are treated as bandaids. The complexity of locating the state in multiple places explodes otherwise, and there are also a lot of moving parts.

Finally, we should keep in mind that no matter how awesome our autistic castles in the air are, at the end of the day the core PKI software will likely become a major source of inertia on its own (for the better), and its defaults will likely be a lot sticker than people think.  Nudging those defaults in the right direction is one of the best ways to get long-term results, as long as the rest doesn't have gaping holes.

[David Kerschner]

Honestly, I find the idea of key custody revolting. _However_ it is
pragmatic. A few things should be pointed out about the "pre-spawning"
planets proposal.

1) Key custody is a service that people want and that is really what we
are talking about. This is a service to avoid the problems we are
currently encountering due to insane gas prices. This is not necessarily
a forever solution. However, it's likely that even in the glorious urbit
based pki future that some people will not want the hassle of handling
keys. I certainly don't, though I will continue to handle my own
keys. This management is enough of a pain in the ass to turn people off
of the idea of booting a planet. Not to name names.

2) You don't have to use one. If you or your friend you want to get on
to the network isn't comfortable having a planet that on a wallet
someone else has they can rekey or even just buy a planet from someone
else who isn't pre-spawning.

3) Tlon does not own all the planets. Even if we wanted to, we could not
pre-spawn every planet on the network. I myself have stars that will not
have pre-spawned planets and I'm sure the majority of other people do as
well. The vast majority of planets will never have this potential
problem of key custody.

Digital sovereignty is a core pillar of the urbit philosophy. We remain
committed to this and this is a short term Tlon solution to a current
problem. You can imagine a world where the urbit foundation would do
this as well, offer key custody services to help offset the costs of
their work.

I have no good way to end this email.

--
~rapfyr-diglyt
https://urbit.org

[Philip Monk]

I've attached a proposal which is easy to implement and made of building blocks we already use.  It scales extremely well for onboarding people by trading off immediate sovereignty for "eventual sovereignty".

Perhaps the most important insight is that there's a spectrum of solutions that may be appropriate for different people.  We acknowledge this already -- moons and comets are each handled different than planets/stars/galaxies because they have different tradeoffs.  But this is true further up the chain as well.

For high-value assets, interoperability with the rest of the Ethereum ecosystem is important.  For low-value but personally important assets (such as planets), it's less important that they interoperate with the Ethereum ecosystem but still important that they be sovereign.  But for a new user, it's not even important that they be immediately sovereign since they haven't invested themselves into this identity; instead, it's important that they be cheap to get and use, and that they can eventually emancipate them at will.

So, I propose we define several possible sources of truth, and each ship can move between them at will.  This also provides a useful framework for adding other scaling solutions in the future, since we will surely want an option that is cheaper than layer 1 but immediately sovereign.  My favorite option there right now is optimistic rollups, but I want to discuss this first.

On Fri, Sep 04, 2020 at 12:25 PM, David Kerschner <da...@tlon.io> wrote:

Honestly, I find the idea of key custody revolting. _However_ it is pragmatic. A few things should be pointed out about the "pre-spawning" planets proposal.

1) Key custody is a service that people want and that is really what we are talking about. This is a service to avoid the problems we are currently encountering due to insane gas prices. This is not necessarily a forever solution. However, it's likely that even in the glorious urbit based pki future that some people will not want the hassle of handling keys. I certainly don't, though I will continue to handle my own keys. This management is enough of a pain in the ass to turn people off of the idea of booting a planet. Not to name names.

2) You don't have to use one. If you or your friend you want to get on to the network isn't comfortable having a planet that on a wallet someone else has they can rekey or even just buy a planet from someone else who isn't pre-spawning.

3) Tlon does not own all the planets. Even if we wanted to, we could not pre-spawn every planet on the network. I myself have stars that will not have pre-spawned planets and I'm sure the majority of other people do as well. The vast majority of planets will never have this potential problem of key custody.

Digital sovereignty is a core pillar of the urbit philosophy. We remain committed to this and this is a short term Tlon solution to a current problem. You can imagine a world where the urbit foundation would do this as well, offer key custody services to help offset the costs of their work.

I have no good way to end this email.

Mark <mark@tlon.io> writes:

Woah, that's a solid-looking proposal, ~timluc. Thanks for sharing! I may respond in more detail later (and I certainly invite others to do the same!), but for now I'll just gently agree with "probably need to be pared down on those grounds".

I wanted to share some points that came up in tlon-internal chat, to help clarify the situation and what kind of thinking goes on about this. Not all of us fully agree on these things, so don't take this as gospel!

tldr: using pre-spawned/custody'd planets dramatically improve the user experience without taking away sovereignty from those who care.

From Galen's opening email:

Doing this means we're spawning to wallets that we control, then handing those to newcomers. This is obviously far from ideal in terms of custody. But it gives us a way to bring new people on the network for the time being. If they decide they want to secure their planets, they can rekey later.

It's no real secret that Tlon has been working on becoming an Urbit hosting provider. Reasonably, hosting providers might want to shy away from doing key custody, because it detracts from the "100% sovereign" Urbit vision, and can be a big liability.

Realize though, that Urbit key custody has always been one of the business models on the table, for people wanting to provide services in this space. Would you trust your grandmother with her own private keys? Would she _care_ about managing those herself? For the bulk of "normal users", having someone (or some entity) take care of their keys for them is simply too convenient. It dramatically reduces the risk-cost of "what if I lose my keys", to the point where it's like a car: losing your car keys doesn't mean losing access to your car, as long as you can still prove it's yours.

You might already see how this is a good fit for hosting. You're already trusting the host with your running ship. Trusting them with the keys that own that ship is only a small step beyond that, and makes the whole process much more convenient.

Of course, the way we'll be setting this up (and I hope other hosting providers will too) will allow users on-demand access to their keys. If they fall into the digital sovereignty rabbit hole and realize they no longer want to trust their service provider, they can just get out. Take the keys, sign a one-time $50 transaction, and "upgrade" your planet to a fully sovereign one. Imagine if Coinbase let you do this...

—
~palfun-foslup
https://urbit.org

--
~rapfyr-diglyt
https://urbit.org

[Basile Genève]

Philip, good to see your perspective, and I think you and I are actually fairly close. Quick clarifications and then I'll save the rest for tomorrow and see what else comes in here:

>  ~zod has one additional round to post a rebuttal, after which the challenge ends.

What possible rebuttal could there be?

The claim was that the user wants to post a transaction that he thinks is being censored. The rebuttal is simply a Merkle proof that shows that transaction inside a checkpointed block. At that point the user has achieved his goal of transferring that asset, and the process is complete.

I regret using the name ~zod in my examples: it was purely intended as a placeholder name.  You could easily do an Urbit native scheme with a different leader, or rotating leaders, and that may be desirable. However, if ~zod can be forced to take all transactions, and revoked as leader if it consistently misbehaves, the value of a single source of truth (with its data mirrored) seems likely to outweigh the additional complications.

[Ted Blackman]

Apologies for the length of this email. While some of the reasoning here refers to long-term issues, I suspect the complexity of an initial production system using a pared-down version of ~timluc's design might be comparable to other proposals for short-term solutions, so I think it's relevant for this discussion.

I'd like to clarify an aspect of ~timluc's self-hosted design: most transactions just need a signature from the "orderer" galaxy to be considered valid; only events requiring explicit consensus among galaxies need a majority of galaxies to sign. These would be:

- votes to update the contract itself, which would probably require a 2/3 supermajority

- votes to switch to a different galaxy as the orderer

- sale of the orderer's stars, which prevents the orderer from attempting a double-spend

So it's not the case that galaxies would need to opt in to each transaction. They'd need to opt out by switching the orderer, basically. I think the orderer is best considered as the "leader" in a distributed state replication system among all the galaxies, like raft, paxos, or tendermint. Later we might automate leader election, but we can reduce complexity significantly by leaving that as a manual vote for now, and I'm not sure we'll ever need to automate it.

My overall position here is that the galactic senate has responsibility over guarding the integrity of the PKI. The best we can do is make sure we get all the hard requirements obviously correct (globally consistent, totally ordered state updates; cryptographic authentication and validation; data availability; no single

point of failure; interop with other chains) and make sure the incentives are aligned so the network is resilient against failures in softer requirements (transaction latency, throughput, and cost; censorship resistance; balance of power; usability).

I also think in general, it's very difficult to predict what our problems at scale will be and solve them now. I don't think the problems we'll have with four billion people on the network will bear much resemblance to the problems we have now with a few thousand. A simple solution that's under our (the Urbit network's) control and can evolve into a complex solution over a long period of time is our best bet long-term.

The way I see it, there are three major ways the galaxies could try to exert power over the network adversarially:

1) unilateral censorship by the orderer (e.g. ignoring requests from ~marnus to spawn a planet)

2) coordinated censorship by a majority of galaxies (they all decide to ignore ~marnus)

3) expropriation of property (galaxies decide to change the rules and reset ~marnus's public key)

We'll look at these in reverse order.

In order to expropriate property, galaxies would need to either violate or change the rules of the PKI ledger. Galaxies could always decide to change the rules to allow that, no matter what cryptographic arrangement we pick. The overall network design is intended to allow this but disincentivize a power grab by the galaxies -- if galaxies try to change the rules in a way that the stars disapprove of, the stars could always decide to mutiny: ignore the galaxies and create a replacement governance body.

Moreover, the galaxies are that set of people who are designated to change the rules when needed. This governance structure is minimal, but it exists so that there's a Schelling point for how events that can't be handled cryptographically will be handled socially -- hopefully preventing the Eth/EthClassic chaos.

So we actually want the galaxies to be able to change the rules; we want the rules to minimize the situations under which they will need to do so, but it's always a possibility.

The second case is that a majority of galaxies conspire to censor a transaction. This breaks down into two cases: informal and formal. Informal group censorship would occur if the galaxies privately decided to ignore ~marnus but try to hide it. Formal group censorship means they change the rules to ignore ~marnus officially.

So, formal group censorship is basically a special case of changing the rules, which, again, could always happen.

Staying on Ethereum might make informal group censorship more difficult to pull off. I'm not sure what we would do cryptographically in a self-hosted system to make this an impossibility, but I'm also not convinced it's a bad enough problem to invalidate a design.

If the informal group censorship is popular among stars (the stars are in on it), then I suspect it's difficult to prevent it cryptographically -- if the rules prevent censorship but the stars and galaxies want it done, the galaxies could change the rules without getting pressure from the stars, or they could all just decide to deviate from the cryptographically agreed-upon state.

If this censorship is unpopular among stars, they will likely pressure the offending galaxies to recant by threatening either escape to favorable galaxies, or mutiny as described earlier. So I think this is an unstable equilibrium that a properly functioning network would resolve using either the balance of power between stars and galaxies or by becoming formal group censorship.

The final case is unilateral censorship by the orderer galaxy. In this case, the orderer tries to ignore ~marnus's proposed transaction without broad support. This is what the transaction injector is designed to handle. The orderer would place a deposit on Ethereum that it would lose if someone requests a transaction and the orderer doesn't fulfill it within a certain amount of time, probably a day or two.

Frankly, I'm not convinced we even need that. As long as other nodes could submit transaction requests to the orderer on ~marnus's behalf (which they should definitely be able to do), it would be pretty easy to sniff out that the orderer is exhibiting favoritism. This would then become a social problem among the galaxies, who would probably switch to a different orderer and publicize their displeasure with the old orderer -- which should in turn encourage the old orderer's stars to escape, causing significant financial losses to the old orderer.

But it might still be worth it to have the transaction injector as extra protection against this form of censorship, at least eventually.

—

~rovnys-ricfer

https://urbit.org

[Philip Monk]

An important point is that the requisite simplicity is not simply about the mechanisms but about the soundness.  "They will likely pressure the offending galaxies" is not a sound claim.

> In order to expropriate property, galaxies would need to either violate or change the rules of the PKI ledger. Galaxies could always decide to change the rules to allow that, no matter what cryptographic arrangement we pick.

I mean, no.  For example, right now the galaxies could vote in an Ecliptic which can't be upgraded.

> So we actually want the galaxies to be able to change the rules; we want the rules to minimize the situations under which they will need to do so, but it's always a possibility.

I disagree with that as well, in the long run.  As you say, there's always a social backstop -- what the kids call a "user-activated fork".  And galaxies would exert a lot of influence in such a case.  But it's not critical that they have formal control as well, it is simply expedient.

Further, I don't think the perfect ~zod exists.  What galaxy can take the responsibility of supporting all users?  None.  The problem with centralization is not simply that the center may be compromised -- no center can exist which won't ultimately censor some transactions (to satisfy the law if nothing else).

Finally, I expect ~zod's bond and the general integrity of the system is vulnerable to a denial of service attack.  Suppose an attacker signs so many transactions that ~zod can't keep up?  Then any that ~zod drops on the floor can be censorship-challenged on-chain and the attacker can take ~zod's bond.

[Clint Ehrlich]

Hey Guys,

I thought an outside perspective might be useful. I'm not an Urbit dev, but I have some expertise in designing fault-tolerant consensus protocols (it's what I do right now for NSF), so that aspect of the discussion falls pretty squarely into my wheelhouse. 

First, I think it's critical to maintain the distinction between the A and B goals that Galen identified in the opening post. In my view, both ~timluc's proposal and the pushback against it blur those goals. 

Social consensus (i.e., governance by informally coordinated hard fork) is not the optimal arrangement for Urbit in its mature form, since the network aims to become civilizational infrastructure. But if it's prohibitively expensive in the present to spawn planets or stars, then the network will never gain traction, and the mature form won't be reached. In general, trading near-term censorship resistance for cheap and reliable spawning and transfer of ships at this early juncture seems like a prudent choice. 

The concept of "censorship resistance" from cryptocurrency doesn't map well to Urbit, precisely because most computation occurs off chain. It would be nice for anyone and everyone to be able to obtain a ship without KYC/AML, but if the world's governments stopped that from happening, it wouldn't be the end of the project. Unlike Bitcoin, censorship-resistant transfer of assets is not Urbit's raison d'etre, so that desidirata can be compromised temporarily without jeopardizing the project's value proposition to users.

Second, given that perspective, I think it would be fine to put ~zod in charge of ordering transactions, even without the complexity of a bond and verification game. But I'm not sure it's really necessary. 

The number of galaxies fits nicely on the upper end of how many validators it's practical to have running a modern, deterministic BFT algorithm like Tendermint. (And, if the overhead from that turned out to be a little high, it would be easy to just split your name space in half, creating an A and B shard that could be validated by separate sets of galaxies.) Since galaxies are already supposed to be continuously online to service the network, maintaining liveness shouldn't be a problem, and censoring transactions would require 1/3 of the galaxies to conspire. 

Implementing Tendermint inside Urbit would be a bit of a PITA, but you probably don't want to do that anyway, since the security of your codebase hasn't been fully vetted. So why not just use the Cosmos SDK to spin up your own blockchain using Golang, with the entire set of Galaxies as validators? I believe that it supports Solidity, so you'd be able to easily port all of the contracts you have deployed right now on Ethereum.

- Clint 

[Basile Genève]

Philip, I see where you are coming from now, especially wrt the role of galaxies, which you and rovnys clearly see in fairly different ways.

(Clint's post hit after I started writing this reply, so I'll put a reply to it at the end.)

Basically you want a PKI to be:

- pluggable (the current star/galaxy use of Azimuth amounts to a parameter set in the core software for where to look for the contracts). rovnys is correct that Urbit entities can, in theory, just look at whatever PKI they want. However, in practice, the working defaults win, and more importantly, this system keeps stakeholders from having to flex the decision-making muscle often or at all, which would tend to preserve the initial status quo.

- outside of star/galaxy control beyond the discrete choice of "where will my software look for the PKI". This allows plausible deniability in the face of government orders in a particular jurisdiction.

- on a system that is much larger than Urbit and fairly unrelated to it, with a wide diversity of transactions, since this makes censorship hard/unlikely.

- a Schelling point to facilitate network effects for peer discovery, but not something that requires galaxies/stars to spend resources to maintain.

If this is roughly your position, then I'm leaning towards agreeing with you in broad principle. I think that even though ~rovnys is correct that any Urbit can arbitrarily choose the PKI it sees as definitive, software defaults have a LOT of inertia in practice.  So having those defaults be pluggable and 3rd party has real benefits.

There are 3 big questions I see from that point:

1. Should this be on Eth? If the main property is hard-to-influence-3rd-party-ness, is there another system with better cost properties?

2. PKI lookup rule seems to be: first check Azimuth, then consult X. In your proposed scheme, X is basically "ask the star/galaxy". What are other possible and clean values for X?

3. Migration pain--there are a lot of reasons that the Eth-based system you describe could eventually be found wanting. Do we take on way too much pain at that point because of the difficulty of tracking Eth ownership when migrating to a new chain?

reply to Clint

Clint, your proposal handles 2 of the questions that I outlined (Eth and migration), and proposes substituting "galaxy-run Tendermint" for Azimuth+X.

Also, using only a subset of galaxies as validators in that scheme would allow galaxies to have fewer resource requirements. I think the main barrier would be the degree to which Urbit trusts its own validators as opposed to Eth's.

[Clint Ehrlich]

Yes, the main barrier to my proposal is definitely the extent to which Urbit users can be expected to trust galaxies vs. ETH validators.

I think that, given the power that galaxies already have, it's not unreasonable to rely on them to reach consensus about the PKI. I'm skeptical that there is a significant fraction of users who would object to arrangement – i.e., who would be willing to use Urbit if Azimuth is hosted on Ethereum, but who wouldn't be willing to trust Azimuth if it were hosted on "Urbit Chain" maintained by galaxies using Tendermint.

If that's really a big concern (and, again, I'm skeptical) a "choose your own adventure" approach similar to what Philip suggested could be used. The algorithm for determining the key for a ship could be modified to:

- If the ship has been spawned on Ethereum Azimuth, check Ethereum Azimuth 

- Otherwise, check Urbit-Chain Azimuth

I suspect that, given the cost savings, the overwhelming majority of users would prefer to use Urbit-Chain Azimuth, so I'm not sure whether the added complexity of continuing to support Ethereum would be worthwhile. However, if composability with third-party contracts or applications running on Ethereum is important, this could offer a "best of both worlds" approach. 

[Basile Genève]

Yeah, I'm withdrawing my earlier proposal, since I think yours is better. At the least, I think it's a better "X" in "Azimuth+X", and also provides a clear trial period and upgrade path.

Since there seems to be preference for keeping some assets on Ethereum short-term, and possible indefinite appetite for keeping galaxies/stars there, it might make sense to have a phase-out point by which the PKI will stop consulting Ethereum for planet identity, and then have a later cutoff point for a binary vote on transitioning stars/galaxies to Urbit.

I like the idea of optimistic rollups, but they're unproven as yet, since you need to implement the verification game for BLS rollup sigs. If they end up working well, that would potentially be a good reason to leave stars/galaxies on Eth indefinitely.

[Clint Ehrlich]

I should flag one shortcoming of the "choose your own adventure" implementation.  If the ships kept on ETH are different than the ones being tracked on a different solution (e.g., Galaxies and Stars on ETH, Planets on Urbit Chain) then there's still a single source of truth. But if the PKI information for a single class of ship can exist on either ETH Azimuth or X (where X is e.g., a version of Azimuth on Urbit Chain), then there's a real problem with double spending. The owner of a planet could sell someone the Urbit Chain version, then effectively invalidate that TX by spawning the planet on ETH. The risk of people getting ripped off that way may make that structure inadvisable. 

I suggested Tendermint because the Cosmos SDK represents a really nice piece of tooling for spinning up custom chains, but it may not be the optimal algorithm. Messaging overhead increases exponentially, so at 256 validators it's possible that the throughput would be too low, even for your use case. HotStuff is a similar algorithm that has linear growth in messaging overhead; it achieves that by trading asynchronous security for a partial synchrony requirement. In practice, that's probably fine: it's what Facebook uses for Libra, IIRC. The other solution, as I mentioned, would be to do sharding. To avoid the need to reconcile shards (i.e., no joint points) the shard assignment of every ship would be permanently determined by its initial galaxy (e.g., ships from ~zod to galaxy 128 on shard A, ships from galaxy 129 to 255 on shard B). That way, escape from the initial galaxy would not affect shard assignment for validation purposes. 

Lastly, it's worth remembering that the structure of the PKI doesn't just have technical implications but also potentially some legal ones in the U.S. under the Howey test. That is also something I have some expertise in: I'm a lawyer and some of my unfinished PhD work was on how Howey applies to digital assets. I am not counsel to Tlon, and this shouldn't be taken as formal legal advice, but I strongly doubt that switching from ETH validators to validation by galaxies using a BFT algorithm probably would affect whether ships are securities. Given the number of galaxies that Tlon controls, it could theoretically be argued that the transition would reduce the amount of decentralization on the network, which isn't a helpful fact. But, in practice, Tlon seems to have made bona fide efforts to spread out ownership of galaxies, such that reliance on the set of galaxies would not be substantively equivalent to reliance on Tlon as a centralized network administrator. I think courts and the SEC would be particularly loath to apply the Howey test harshly when an attempt at maximal decentralization (via ETH) was made, and any subsequent reduction in decentralization was performed for legitimate technical reasons (limited block space on ETH), rather than as an attempt to claw back control of the network. 

[Jon "Poprox" Paprocki]

One further possible constraint to optimize for if we end up changing how keys are handled to combat the gas problem - eventually we will want to switch to quantum-secure keys. This probably will not itself be difficult to implement, but it means we'll likely end up with one of two scenarios: the keys are very large (>1 MB) but messages encrypted with it are not much longer than the message, or the keys are small and messages encrypted/signed with it are very large.

That being said, I don't think Azimuth keys _need_ to be quantum secure for a long time, simply because the risk is in computing the private key and then stealing the point. This is as opposed to e.g. Ames traffic, where someone can just scrape traffic and sit on it for ~10-20 years and then unencrypt it all, so it's important to make Ames quantum secure sooner*. So this constraint doesn't necessarily need to come into play until the encryption apocalypse comes into sight, but since ideally any change will be the last such one, that solution being able to accommodate the switch to post-quantum encryption would be ideal. In practice, I think that just means to keep the eventual above dynamic (small key large message vs large key small message) in mind and whether that could create another future crisis.

*Unless Azimuth keys are used to derive your Ames keys? I don't actually know, but

--

—

~datnut-pollen

https://urbit.org

[Kenny Rowe]

It should also be considered that whatever PKI solution is arrived at it's not a purely technical matter. These are assets, and assets need markets.

Are Galaxies also willing and able to host markets?
Are there exchanges (CEX or DEX) that support Cosmos based assets already? 

What kind of liquidity might be available?

~sicdev-pilnup

[Philip Monk]

Apologies for the length of this email and for the points I've omitted.  Feel free to re-raise anything you would like me to address.

Clint, thanks for your perspective, it clarified some things for me.

> The concept of "censorship resistance" from cryptocurrency doesn't map well to Urbit, precisely because most computation occurs off chain.

This is true, and I should point out that when I talk about censorship resistance with respect to Azimuth, I mean specifically censorship of identity transfers, breach notifications, and escapes.  An important part of Urbit's identity system is comets, which allow you to use the rest of Urbit without any globally-registered identity.  So our worst case is that everything devolves to comets, which is essentially what most projects do anyway.

However, even though I can imagine Urbit without planets, it would be a much worse system.  Permanent identities are one of the things big companies provide that incur the most lock-in.  The primary value of a site like Twitter is your identity.  One of the reasons Twitter doesn't crack down when someone they banned creates a new account is because it rarely matters -- their identity and their follower list is gone.  And transferring an identity from one platform to another (say, Twitter to YouTube) is usually impossible; the best you can do is try to jump-start a new community.

So yes, Urbit is a lot more than Azimuth!  But Azimuth in its current form has a lot of really nice properties and one really bad one (scaling).

> The number of galaxies fits nicely on the upper end of how many validators it's practical to have running a modern, deterministic BFT algorithm like Tendermint.

Cosmos is an interesting idea.  I've been learning more about it and will continue to do so.  It seems you can plug in your own state machine, so I could imagine writing the contracts in Nock.  Solidity's advantages are that it exists and we have vetted contracts for it.  These are very important advantages!

> Since galaxies are already supposed to be continuously online to service the network, maintaining liveness shouldn't be a problem,

Currently most galaxies are not online.  We could possibly get most of them online with some effort, for example if Tlon offered to host them for free.

> I think that, given the power that galaxies already have, it's not unreasonable to rely on them to reach consensus about the PKI. I'm skeptical that there is a significant fraction of users who would object to arrangement – i.e., who would be willing to use Urbit if Azimuth is hosted on Ethereum, but who wouldn't be willing to trust Azimuth if it were hosted on "Urbit Chain" maintained by galaxies using Tendermint.

A very important point is that nearly everything galaxies and stars do now only requires that you find *one* of them willing to service you.  This is very different than requiring a third of galaxies to actively service you.

Additionally, active servicing/passive censorship vs passive observing/active censorship is an important distinction.  There's a reason economists don't care about the trolley problem but philosophers do.  And for censorship, we shouldn't assume a narrow economic perspective will prevail.  Censorship will generally happen for either moral or legal reasons (or economic reasons caused by these), and both of those *do* care about the difference between passive and active participation precisely because they're downstream of philosophy and not economics.

In standard proof of work, if any miner is willing to include a tx, then it becomes a part of the canonical chain.  It's true that if >50% of miners decide not only to ignore certain txs but also to ignore any blocks that include those txs, then they can reorg that tx away.  But this is active censorship; if they build on someone else's block they are simply observing that it happened, not facilitating it.

It may be that the advantages of Tendermint outweigh this.  But I would be very interested in an option that preserves the property that only a single galaxy/star need actively service you.  Optimistic rollups are an option for this, and they're about 100x better at scaling than what we have now, but that may not be sufficient.

> Basically you want a PKI to be:

> ...

> - outside of star/galaxy control beyond the discrete choice of "where will my software look for the PKI". This allows plausible deniability in the face of government orders in a particular jurisdiction.

Yes, ideally.  I'll note this doesn't simply allow "plausible" deniability but "actual" deniability.  I know everyone here lives by a different moral code, but I would have a hard time actively servicing some genuinely evil people.  I believe the benefits of free speech outweigh the risk that evil people may use the system, so I believe it's important to design the system such that ~nobody can stop someone from using the network.  This means the system needs to be designed such that it doesn't require me to actively service everyone on the network.

A note about the above paragraph: my moral reservations are my own and I don't speak for the Tlon corporation on such matters, but also this would be the wrong forum to argue that I *shouldn't* have such reservations.  I'd be happy to discuss that aspect more on Urbit, but for the purposes of this discussion it's only important to agree that what I laid out is one of the plausible ways that censorship is likely to occur.

> 2. PKI lookup rule seems to be: first check Azimuth, then consult X. In your proposed scheme, X is basically "ask the star/galaxy". What are other possible and clean values for X?

Other than than Clint's proposal of a Tenderminted-based galaxy-mediated chain (which could also exist in isolation), I'm still investigating, but optimistic rollups seem clean and straightforward.  I actually think we're a reasonable candidate for ZK rollups too, but I don't know them very well.

It's worth pointing out that we're very nearly an optimal application for Plasma, since every transaction has a clear owner (escaping is the only double-opt-in situation, but in case of exit you could just escape again -- it doesn't give up ownership).  However, I'm wary of Plasma's challenge process and liveness requirement, and mass exit doesn't seem very feasible for a system like ours.

> I should flag one shortcoming of the "choose your own adventure" implementation.  If the ships kept on ETH are different than the ones being tracked on a different solution (e.g., Galaxies and Stars on ETH, Planets on Urbit Chain) then there's still a single source of truth. But if the PKI information for a single class of ship can exist on either ETH Azimuth or X (where X is e.g., a version of Azimuth on Urbit Chain), then there's a real problem with double spending. The owner of a planet could sell someone the Urbit Chain version, then effectively invalidate that TX by spawning the planet on ETH. The risk of people getting ripped off that way may make that structure inadvisable.

This is very true.  The rule in my initial proposal that only unspawned planets are not subject to the ETH contracts avoids this issue, but of course those planets aren't really owned by the recipient unless they register them on chain.  Someone suggested they be called "planetoids", which I rather like.  But since these are not sovereign and may be double-spent as you described (bitcoiners would call these "zero confirmation txs"), they wouldn't be something you could reasonably charge for, and they have a pretty narrow use.  It just happens their narrow use happens to coincide with a really common case -- people wanting to get into Urbit without paying $50 gas fees.  But this is very much a type A solution.

If we want to be able to go up and down the list, the transfers between chains have to be clear.  I believe you can do this by explicitly "sending" ownership from one chain to the next, but the details are highly dependent on which chains you're using and how you want them to relate.  It may be impossible to tell just by looking at the eth1 contract whether you own the ship — maybe it was never sent back from Urbit Chain?  But a standard eth1 contract *could* inspect the state of a rollup and vice versa.

> *Unless Azimuth keys are used to derive your Ames keys?

Your Azimuth *networking* keys are used to derive your Ames keys, but not your Azimuth ownership key.  Networking keys are usually derived from the same master key as the ownership key, but I don't think you'd be able to "walk up" an HD wallet like that (?).  Of course for Ames we really should do something like the double ratchet algorithm, which would provide forward secrecy *and* resolve this issue, I believ.

[Ted Blackman]

After this email, I have some more responses and a few more scenarios to describe (unilateral censorship attempts and poor orderer availability in a self-hosted system, and analysis of double-spends in the planet IOU system), but I'll put this out there for now as an example of how I'm thinking about this topic.

Philip, you mentioned that no matter what the ostensible rules are, a galaxy might always decide that a transaction is immoral and refuse to sign it.  This is an excellent point, and I agree wholeheartedly.  The Urbit network is a group of people.  That group of people will make decisions based on some combination of local law, personal ethics, self-interest, and sheer caprice.

The network is set up so that the galaxies are the people to look to when making decisions that affect the network as a whole.  Decisions about managing the PKI will inevitably fall primarily to the galaxies.  The galaxies might decide to censor or otherwise censure a planet, a star, a galaxy, or a whole subnet.  They could also fail to come to consensus, resulting in a fork.

Let's play out some scenarios in which galaxies want to censor someone.  This will help us think through the similarities and differences among proposed solutions for managing the PKI.

Scenario: ~nus goes nuts

The owner of ~nus has had a psychotic break due to overexcitement from arguing about Hoon's four-letter variable naming scheme.  Since then, he's been poaching cute endangered animals, spamming the network with denial of service attacks, providing spotty service to his stars, trying to propagate various Byzantine faults, proposing the appointment of his horse to the galactic senate, and cutting in line in the grocery store.  There's even a rumor that he murdered his neighbor in Belize.

The other galaxies have had enough.  The first thing they do is add ~nus to the list of addresses whose packets should be rate-limited to prevent the incessant DoS attacks.  They push this out to the network, so now the vast majority of stars and planets now ignore all packets from ~nus.  Only the few people who have manually disabled the network's standard spam protection app will see packets from ~nus now.

When the galaxies censure ~nus in this way, most of ~nus's stars quickly try to escape.  A few stars stay, either because they're secretly controlled by ~nus (a galaxy can always spawn a star to a private key it generated itself), or because they share ~nus's belief that the reptilians have taken over the earth, so they remain loyal to him.

If one of these stars has a change of heart later, it might be difficult for it to escape later, since it has tainted its reputation through association.  The price for these assets will likely be lower too, since this star doesn't have an established relationship with a galaxy in good esteem.

After a while, ~nus's owner goes broke.  Most of his stars have left, so his repeated revenue has been drastically reduced.  There's a good chance that in a lucid moment, he'll try sell the galaxy to cut his losses.  Unfortunately for him, but fortunately for the network, this galaxy is not worth as much as it was when its owner was acting in the best interests of the network.  Who wants to own a galaxy whose name is associated with such horrible acts?

Someone eventually buys ~nus for a low price and makes some effort to distance himself from its former owner.  He makes some donations to some wildlife preserves, stops spamming the network, and takes on a few stars pro bono for a while to demonstrate that the quality of service has improved.  After a while, the other galaxies feel confident that this is not only a new public key for ~nus, but a new person who owns it.  Nature is healing — habitat destruction slows now that ~nus's old owner can't fund it anymore, and this corner of the network has reestablished legitimacy.

But maybe that's too optimistic.  Let's consider the case where ~nus's owner is determined not to sell his hard-earned galaxy to some reptilian, no matter what.  Some ill-tempered stars and planets from all over the network join his "hunt all mammals to extinction" movement and amplify ~nus's denial of service attacks.

A few times, ~nus claims he's selling his galaxy, trying to pretend the new owner is less odious, but he actually just transfers it to some other address he owns.  A few people get snookered into buying some of ~nus's stars for a price that's higher than they can resell, since once they realize ~nus is still owned by the same person, they try to escape.

Then, raising the stakes, ~nus and his band of band of nihilist ne'er-do-wells in his subnet start trying to blackmail the other galaxies into voting his way.  Now the galaxies realize that they need to take more draconian measures to save the network.

The next step they can take is to remove ~nus's ability to vote.  Unfortunately, ~nus's owner is still trying to blackmail other galaxies, even though his node can no longer vote.  So the galaxies can escalate a few more steps, including forbidding ~nus from selling his assets (or maybe preventing sale other than to known-decent public keys), with the last resort being a forcible transfer of ~nus and its subnet.

At this level of conflict, a fork is probably inevitable.  ~nus and his subnet don't want to be shut down, but the rest of the network doesn't want them there.  The other galaxies decide to clear the PKI state of ~nus and his subnet, putting the addresses up for auction and sharing the revenue from the sale.  There's a good chance they'd allow ~nus's planets to escape without forcing a sale, since they might be removed enough from ~nus that they're not considered culpable or a burden to the network.

~nus and his minions deny the authority of these other galaxies and form a schismatic Urbit fork — maybe they appoint ~nus as antipope of Urbit Classic.  The two networks can't communicate unless some people decide to run bridge nodes, which would involve something like a NAT, which bears an odd resemblance to the current internet.

The other galaxies would likely be relatively satisfied with this solution, since from their perspective the network would be whole again.  Like all drastic action, is likely to cause potentially serious collateral damage.  It's not something they'd do lightly, which is good, because a fork would be traumatic for the network.  In a case like this, though, it might be the best course of action, and it's difficult to predict what these sorts of politics will be like at scale.

Thus concludes this scenario.  Note that nowhere in this description did I mention how the galaxies are storing the PKI, since as far as I can tell, that choice has almost no material effect on these dynamics.  Any cryptographic arrangement for managing the PKI is merely an attempted implementation of the will of the network, as represented by the galaxies as the Schelling point of decision-making.

If the galaxies had previously voted to freeze the Ecliptic contract, then when they want to expropriate ~nus, they'll launch a new modified contract and push out an OTA that switches everyone to that.  Maybe it's marginally more expensive than making a decision like that in a self-hosted system, but if a couple hundred galaxies pitch in, even with current gas prices I don't think it would be prohibitively expensive — or they could switch to a cheaper system, such as a self-hosted one.

—

~rovnys-ricfer

https://urbit.org

[Philip Monk]

This is rather clarifying.  I've been trying to propose a system which is resilient even when most of the network wants to censor someone, and your position is "censorship is good actually".

Specifically: no matter how crazy ~nut is being, the other galaxies *should not* sieze that galaxy.  They should ignore it as completely as they can -- which is pretty much completely.  Even in a Tendermint-like world, it's resilient to up to 85 nuts, and on Ames of course you can refuse to process packets from ~nut and their descendents.

I don't know if you buy the standard free speech argument, but it goes basically "you shouldn't expropriate someone's property just because they believe the world has been taken over by lizard people, because that means if a minority ever does stumble on an important truth, you'll censor them."  Again, this is the difference between finding *someone* to believe you vs convincing some *percentage* to vote for you.  The latter is vulnerable to all kinds of social diseases.

To bring this back to Urbit's prime directive ("software that will last forever"), something is only permanent if the owner can keep it forever under their own power.  Urbit aims for "subjective permanence" -- most things on Urbit can disappear if the owner throws them away or is careless in storing them.  The important thing is that they don't disappear if some external entity disappears or turns against them (a megacorp, for example).  The requirement that at least one galaxy/star decides to service you is a very small concession to reality -- the requirement that at least 1/3 (or 1/2 or 2/3) of galaxies decide to service you is much larger.  Consider the number of people banned by at least 1/3 of megacorps -- it's almost the same as the number of people banned by a single megacorp, but much larger than the number banned by *every* megacorp.  These are not independent decisions.

And of course, identity is within the purview of those things which should last forever.  Downloading your data from Twitter does not let you recreate your Twitter experience.

The Urbit identity system needs to be resilient against social whims.  The point is not to build a good society -- the point is to be neutral infrastructure which can be used to build a good society and not be interfered with.  The idea that this good society will always possess a majority of the galaxies is incurably optimistic.  The only practical way to build a good society is to let a thousand societies try to be good.

On Thu, Sep 10, 2020 at 10:57 AM, Ted Blackman <t...@tlon.io> wrote:

After this email, I have some more responses and a few more scenarios to describe (unilateral censorship attempts and poor orderer availability in a self-hosted system, and analysis of double-spends in the planet IOU system), but I'll put this out there for now as an example of how I'm thinking about this topic.

Philip, you mentioned that no matter what the ostensible rules are, a galaxy might always decide that a transaction is immoral and refuse to sign it.  This is an excellent point, and I agree wholeheartedly.  The Urbit network is a group of people.  That group of people will make decisions based on some combination of local law, personal ethics, self-interest, and sheer caprice.

The network is set up so that the galaxies are the people to look to when making decisions that affect the network as a whole.  Decisions about managing the PKI will inevitably fall primarily to the galaxies.  The galaxies might decide to censor or otherwise censure a planet, a star, a galaxy, or a whole subnet.  They could also fail to come to consensus, resulting in a fork.

Let's play out some scenarios in which galaxies want to censor someone.  This will help us think through the similarities and differences among proposed solutions for managing the PKI.

Scenario: ~nus goes nuts

The owner of ~nus has had a psychotic break due to overexcitement from arguing about Hoon's four-letter variable naming scheme.  Since then, he's been poaching cute endangered animals, spamming the network with denial of service attacks, providing spotty service to his stars, trying to propagate various Byzantine faults, proposing the appointment of his horse to the galactic senate, and cutting in line in the grocery store.  There's even a rumor that he murdered his neighbor in Belize.

The other galaxies have had enough.  The first thing they do is add ~nus to the list of addresses whose packets should be rate-limited to prevent the incessant DoS attacks.  They push this out to the network, so now the vast majority of stars and planets now ignore all packets from ~nus.  Only the few people who have manually disabled the network's standard spam protection app will see packets from ~nus now.

When the galaxies censure ~nus in this way, most of ~nus's stars quickly try to escape.  A few stars stay, either because they're secretly controlled by ~nus (a galaxy can always spawn a star to a private key it generated itself), or because they share ~nus's belief that the reptilians have taken over the earth, so they remain loyal to him.

If one of these stars has a change of heart later, it might be difficult for it to escape later, since it has tainted its reputation through association.  The price for these assets will likely be lower too, since this star doesn't have an established relationship with a galaxy in good esteem.

After a while, ~nus's owner goes broke.  Most of his stars have left, so his repeated revenue has been drastically reduced.  There's a good chance that in a lucid moment, he'll try sell the galaxy to cut his losses.  Unfortunately for him, but fortunately for the network, this galaxy is not worth as much as it was when its owner was acting in the best interests of the network.  Who wants to own a galaxy whose name is associated with such horrible acts?

Someone eventually buys ~nus for a low price and makes some effort to distance himself from its former owner.  He makes some donations to some wildlife preserves, stops spamming the network, and takes on a few stars pro bono for a while to demonstrate that the quality of service has improved.  After a while, the other galaxies feel confident that this is not only a new public key for ~nus, but a new person who owns it.  Nature is healing — habitat destruction slows now that ~nus's old owner can't fund it anymore, and this corner of the network has reestablished legitimacy.

But maybe that's too optimistic.  Let's consider the case where ~nus's owner is determined not to sell his hard-earned galaxy to some reptilian, no matter what.  Some ill-tempered stars and planets from all over the network join his "hunt all mammals to extinction" movement and amplify ~nus's denial of service attacks.

A few times, ~nus claims he's selling his galaxy, trying to pretend the new owner is less odious, but he actually just transfers it to some other address he owns.  A few people get snookered into buying some of ~nus's stars for a price that's higher than they can resell, since once they realize ~nus is still owned by the same person, they try to escape.

Then, raising the stakes, ~nus and his band of band of nihilist ne'er-do-wells in his subnet start trying to blackmail the other galaxies into voting his way.  Now the galaxies realize that they need to take more draconian measures to save the network.

The next step they can take is to remove ~nus's ability to vote.  Unfortunately, ~nus's owner is still trying to blackmail other galaxies, even though his node can no longer vote.  So the galaxies can escalate a few more steps, including forbidding ~nus from selling his assets (or maybe preventing sale other than to known-decent public keys), with the last resort being a forcible transfer of ~nus and its subnet.

At this level of conflict, a fork is probably inevitable.  ~nus and his subnet don't want to be shut down, but the rest of the network doesn't want them there.  The other galaxies decide to clear the PKI state of ~nus and his subnet, putting the addresses up for auction and sharing the revenue from the sale.  There's a good chance they'd allow ~nus's planets to escape without forcing a sale, since they might be removed enough from ~nus that they're not considered culpable or a burden to the network.

~nus and his minions deny the authority of these other galaxies and form a schismatic Urbit fork — maybe they appoint ~nus as antipope of Urbit Classic.  The two networks can't communicate unless some people decide to run bridge nodes, which would involve something like a NAT, which bears an odd resemblance to the current internet.

The other galaxies would likely be relatively satisfied with this solution, since from their perspective the network would be whole again.  Like all drastic action, is likely to cause potentially serious collateral damage.  It's not something they'd do lightly, which is good, because a fork would be traumatic for the network.  In a case like this, though, it might be the best course of action, and it's difficult to predict what these sorts of politics will be like at scale.

Thus concludes this scenario.  Note that nowhere in this description did I mention how the galaxies are storing the PKI, since as far as I can tell, that choice has almost no material effect on these dynamics.  Any cryptographic arrangement for managing the PKI is merely an attempted implementation of the will of the network, as represented by the galaxies as the Schelling point of decision-making.

If the galaxies had previously voted to freeze the Ecliptic contract, then when they want to expropriate ~nus, they'll launch a new modified contract and push out an OTA that switches everyone to that.  Maybe it's marginally more expensive than making a decision like that in a self-hosted system, but if a couple hundred galaxies pitch in, even with current gas prices I don't think it would be prohibitively expensive — or they could switch to a cheaper system, such as a self-hosted one.

—

~rovnys-ricfer

https://urbit.org

[Galen Wolfe-Pauly]

I concluded my initial message with 'there's a lot to discuss' — which is pretty clearly the case. 

I think the majority of what's being discussed here falls pretty squarely under what I was labelling 'B': " what we'd like to do in the long term to make sure the system is as robust as possible."

We have an imminent problem: which is to be able to onboard people on to the network that we have. The system is increasingly nice to use, and I want to be able to ask people to join me on the network. To do that, I've got to be able to spawn planets. 

I initially proposed that we fork this thread in order to discuss the long-term options — but instead I think the opposite is more appropriate. This discussion is worthwhile, but can be made less urgent if we can in fact come up with a 6 - 12 month interim solution. In discussing this with Philip over the past couple of days, I think the planetoid solution is really quite workable.

So: we'll start a second thread with a more concrete proposal for what that might look like and we can discuss its merits there. 

We can leave this thread for ongoing discussion of the problem space. It's as if we were once, twenty messages back, at the top of a rabbit hole and have since asked others to hold our beers. Anyway, I'll join you but keep it short:

My overall take on the prior discussion of alternative registry approaches is that much of it warrants further research (especially Tendermint). It'll take some time to dig into these other options, so I'll refrain from weighing in on any of those right away.

As for the question of censorship resistance, it does seem to me that the ethos of the system is to aim at long-lived, neutral infrastructure as much as possible. I'd much prefer to figure out how to work around ~nus at the ames level than to simply take his or her property, and I'd probably vote that way (to simply mitigate at the network level) if it came up. But it'd also depend a lot on the specific wildlife involved, the severity of the DoS, how much of a general asshole he or she is, etc.

It seems to me that there are two constraints on any system that we use for storing the PKI: (a) who gets to update the rules of the PKI and (b) how do we order the transactions that compute its final state. Today, (a) is simply 'the galaxies by majority' and (b) is 'we let the ethereum miners do it'. 

We want Urbit to last a long time, so we trust the senate of galaxies to be able to work together toward this end. You can look at it as a simple incentive: everyone will reap the most benefit from a stable, long-lasting network. Updating the PKI rules by majority strikes me as a perfectly fine system. 

The censorship question I'm more concerned with is (b). What system do we use for storing the ledger? Originally, we aimed to do this as a self-hosted system. With only a few nodes on the network, there are huge risks to this. Security and robustness are the most practical, but censorship by external entities is very likely with only a few nodes participating. The address space ledger should, I think, be *extremely* difficult to modify or shut down. How do you get a bunch of nodes to hold the same ordering of transactions? Well, we picked a solution that's reasonably robust for the time being — but I think we'll have to aim for similar robustness in our own system or any future system.

What I mean is: we need the PKI to be held by many, many nodes that are geographically distributed and operated by different people. Having them run separate builds that speak the same protocol would also be desirable. A system like this is more likely to resist attacks of all kinds. 

An Urbit PKI that's just stored by the galaxies seems easily broken by DoS or simply targeted attacks on each node. It's just not decentralized enough. But what is decentralized enough? I'm not exactly sure, but it's a major consideration when I entertain any alternative system for storing the PKI. It'll cost you $50 or whatever to spawn a planet today, but it's *very* difficult to revoke that transaction.