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
_______________________________________________
Lightning-dev mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
