[Lightning-dev] Superbolt Proposal - a professionally run LN subset delivering superior UX

[ZmnSCPxj]

Good morning Robert,

Unfortunately, this proposal is basically a proposal to split the network into a central network of specially-chosen nodes surrounded by second-class and third-class nodes that are utterly dependent on the central network, which I personally find disturbing.

Of course, it may be that this is already where the network is heading, which is sad.
Gravity exists, and is difficult to resist against; yet as long as I remain standing on my own two legs (since I am human, I possess two legs), I resist gravity.

In any case, other than that, here are some more thoughts:

> it may be beneficial to have a maximum node capitalization limit.

This is trivially worked around by running multiple virtual nodes, say on the same machine but behind different Tor .onion addresses.
Then any benefit you get would be a mirage.
If you go through with this, I suggest that such limits not be imposed anyway, as it is trivial to get around them.

Disallowing Tor .onion addresses would be bad as well: it should be allowed that some high-liquidity nodes have their privacy protected if needed.

> 5.  Attestation: Any LN node which claims to meet the requirements to be included in SBN would be rated by a randomized subset of the SBN network and the inquiring node would receive cryptographically signed attestation that the node is either valid or invalid.

How would you bootstrap this SBN?
Who are the first members of the SBN, and why should they let, say, furries join the SBN by attesting to them?
If the first members all hate furries (and everybody hates furries, after all, why do you think the Cats movie bombed?) then even a random subset of those first SBN members will not attest to any furries, because furries are ew.

Note that we already have attestation to the liquidity of a node, by having the node publish its channels, since channels are attested on the blockchain, whose blocks are attested economically (i.e. a sufficiently rich furry can always create channels on the blockchain, because censorship-resistant).
What is missing is a censorship-resistant attestation of the ***uptime*** of a node.

Now of course, a furry might manage to get through by at least first hiding the fact that it is a furry, but once discovered, a "randomly-selected" subset of the SBN would then counter-attest that the furry is actually only 98.9% up, revoking its membership from the SBN.
This gets worse if the furry was using its open public IP rather than sensibly using a Tor .onion address (which means that, for the protection of furry and non-furry alike, we must support Tor .onion addresses for SBN members).

Which brings up the next topic: how does the "random selection" work?
It might be doable to use entropy from the onchain block IDs, assuming miners are not willing to increase the difficulty of their work further by biasing their blocks against those furries (which all miners also hate, because everybody hates furries).
But that means there has to be some authoritative set of SBN members (from which a deterministic algorithm would choose a subset), and there would need to be consensus on what that set of SBN members ***is*** as well, and how to keep around this data of who all the SBN members are, and so on.
This starts to look like a tiny federated / proof-of-stake blockchain, which we would like to avoid because blockchains have bad scaling, though I suppose this might be acceptable if the only transactions are removal and adding of SBN members.
What would the block rate be, and who are the genesis SBN members (and are any of them furries)?
How bad will this get a decade from now, and how many will be using SPV for this set-of-SBN-members federated blockchain?

> 2.  Ignoring the 48% of unreachable nodes, payment success rate is 66% on the first payment attempt. With multiple retries for the payment, success rates reach about 80%. This means that even for nodes which are available and reachable, 20% of payments are not able to complete. This is not good.

I note that, as I understood the presentation, the data-gathering model was that every node had an equal chance of being the payee.

However, we should note that not every public node expects to be a payee at all times, and that for nodes with a brisk business on Lightning, their success chances are, as I understand it, higher.
Thus the actual experience is better than the dire numbers suggested in the presentation.
Of course, I have no numbers or data to present here.

In general, if you are expecting a payment over Lightning, you will generally arrange to make this as smooth as possible, and will ensure you have incoming liquidity, that your node was actually up during the time you expect a payment, and so on (you have a strong incentive to do so, because you like money); whereas the model used was that everybody gets a  payment (that they cannot claim because the payment hash was a random number) and not everyone has their nodes online all the time with incoming liquidity in all channels with peers that are also alive.
Thus, I expect the actual experience to be higher: in short, the data from cdecker establishes a lower bound on the expected user experience, not an upper bound, because it just randomly took everyone as a possible target.

--

So let me counterpropose that:

* What we are missing is a censorship-free way to attest to uptime.
* Liquidity is visible onchain.
* You are already going to need a blockchain anyway to anchor your funds.

So:

* Nodes that want to declare themselves as members of SBN sign the current block.
  * These nodes put their signatures in OpenTimeStamps for the *next* block.
  * When somebody asks "what is your uptime???" they show the signatures they have that are attested on OpenTimeStamps.
    * The asker will disbelieve them unless the set of signatures attested on OpenTimeStamps is large enough.
      For example, it could require that the node, to be believed as a member of SBN, to show 99 signatures within the last 100 blocks as having been attested on OpenTimeStamps.
* To be accepted as an SBN member, your node needs only to give these proofs to anyone who asks:
  * Proof that it has liquidity --- which it already does by the current gossip system.
  * Proof that it has high uptime --- by the above mechanism.

This assumes OpenTimeStamps does not hate furries, or that you can hide your furry-ness from OpenTimeStamps.
I believe it is possible to hide furry-ness: my understanding is that it is commitments, and not their openings, that is received by the OpenTimeStamps server.
Thus, an SBN wannabe self-attests: they publish their onlineness to OpenTimeStamps, they do not ask somebody "please tell everyone else that I am not a furry".

As well, we can replace OpenTimeStamps with some other attestation mechanism that publishes attestations, at cost, onchain, though we should be careful to design one with very low onchain footprint.
Using OpenTimeStamps may make the OpenTimeStamps server an attractive target for attacks, and distributing this risk is needed.


Regards,
ZmnSCPxj