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

Robert Allen robertwilliamallen at gmail.com
Tue Mar 10 01:52:14 UTC 2020


Hello ZmnSCPxj,

How did you know that I'm a closet furry?! ;) I'm shaking in my
onesie right now...

It is definitely not my goal to split the network up but rather to provide
some guide rails to help ensure usability and decentralization. I also
agree 100% that Tor nodes are a must for LN.

In terms of maximum node size for SBN, I do feel that it would be
beneficial to the decentralization of the network to have that in place (if
it worked as intended) but also understand the scenario you outline where
many nodes could be spun up on the same machine. Perhaps a better (and
actually enforceable) approach would be to require that all RNs commit 0.5
BTC per channel (1 BTC total per channel) with a minimum of 4 channels. So,
a larger node could have many more than 4 channels assuming each channel
meets the liquidity requirement. This wouldn't help to further
decentralization but would at least ensure uniform channel liquidity. It
seems that just as the one computer one vote idea with BTC didn't pan out,
there is a similar problem here that may be insurmountable.

Your suggestion for self-attestation using OpenTimeStamps is really
brilliant and elegant. I don't see any reason why this shouldn't work. I do
think it would be better to extend the minimum number of self-attestations
to perhaps 7 days worth of blocks (so that a node cannot easily
join/exit/rejoin SBN). I'm also wondering if it would make sense to add
OpenTimeStamps servers to all SBN nodes and then use some kind of random
election function such that for each block all attestations would be sent
to the elected server and published to BTC (thus ensuring the lowest
possible fee vs. using a redundant approach with multiple OTS servers). If
the election is sufficiently random, it would seem to be very difficult to
coordinate an attack where a furry's attestation would be excluded from a
block for more than some very small number (well bellow putting them in
danger of being excluded from the network for insufficient uptime).

I reworked the proposal with the OpenTimeStamps approach and published it
on GitHub <https://github.com/robertwilliamallen/superbolt>. ZmnSCPxj and
anyone else who finds this proposal to be interesting is invited to come
and add their ideas to the mix.

I also see some similarities to this proposal and Lightning Service
Providers (LSPs) as written about by Roy Sheinfeld here:
https://medium.com/breez-technology/introducing-lightning-service-providers-fe9fb1665d5f.
Don't know if he's in this group, but would really enjoy connecting with
him to discuss if he is.

Best,
Robert

On Mon, Mar 2, 2020 at 9:07 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:

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

-- 
Best,

Robert Allen
Executive Producer
Bitcoin and Friends
btcandfriends.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200309/33d45be9/attachment-0001.html>


More information about the Lightning-dev mailing list