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

[ZmnSCPxj via Lightning-dev]

Good morning Robert,


> > This shows the issue: what they measured was *the number of rat tails 
> > shown*, not *the reduction of rats in the city*, and so they got shown a 
> > lot of rat tails (at the expense of actively increasing the number of rats 
> > in the city, since they were now being grown in rat farms).
> >
> > Similarly, I could attack the SBN by having a cheap RaspPi (or maybe 
> > Arduino) continuously attesting its uptime, but not actually running any 
> > Lightning node software, so that paths through my pathetic RaspPi "node" 
> > will always fail.
> > With enough cheap RaspPis and some HODLed funds in 2-of-2s (where both 
> > pubkeys are mine anyway), I can ensure that most of SBN is composed of my 
> > "nodes" and make it worthless.
>
> I guess it wasn't explicit in my proposal, but the intention is for SBN nodes 
> to be LN nodes. Thus, in order to be accepted into SBN, your node would have 
> to run the LN software. Is there a way to set up an LN node, connect to other 
> nodes, and then not allow routing of payments through your node? If so, then 
> I don't believe SBN would be any more in danger of this scenario than vanilla 
> LN. 

Anyone who can update the software can easily create a faked node that appears 
to have completely legit channels to one or more real nodes.
Basically, I would just write a little bit of signing code using the node 
secret of a real node I control, put up a UTXO somewhere with a new ephemeral 
key I control plus the node id of my real node, and voila I can have a 
non-working "channel" that attests to a non-working "node" on the LN, and I can 
make that non-working "node" attest its uptime over SBN using a cheap 5mBTC 
RaspPi.
I can make the "channel" UTXO almost as secure as my hardware-wallet-locked 
funds by making the non-working "node" id be a key from my hardware wallet, and 
then this fund is no more than me HODLing BTC onchain with my hardware wallet 
(channels are 2-of-2 so even if my real node is compromised and its private key 
stolen, the funds in my non-working "channel" are still protected by my 
hardware wallet key).
I can easily run a few real nodes, over Tor .onion services, on a single 
low-end server, and then have them attest to non-working "channels" attesting 
to a few non-working "nodes" on the LN, and then run a simple SBN 
self-attestation daemon on the RaspPi to attest the faked "nodes" on the SBN.
Since the SBN is intended to interconnect to the LN, the real nodes do not need 
to have a lot of capitalization themselves or be on the SBN, so for example I 
could have one or two real node on the SBN and a few throwaway real nodes with 
little capitalization, interconnected with channels to the faked node.

I might do this, for example, if Roger Ver suddenly offers me a few hundred BTC 
(not BCH, sorry) to attack the SBN and reduce its UX to not much better than 
the LN.

>
> > Against this, we can observe that the blockchain layer itself is ultimately 
> > protected by the economics of mining.
> > Thus, the blockchain security cannot be better than economically-infeasible 
> > security, and Lightning, as it is anchored to the blockchain, also cannot 
> > get better than economically-infeasible security.
> > If attesting its own uptime is expensive enough, then every additional node 
> > that I fake is going to be an additional expense, and it may become 
> > impractical for me to take over the entire SBN unless I work honestly and 
> > actually forward payments and earn fees from it (in much the same way that 
> > a miner could always just mine empty blocks and make the blockchain layer 
> > worthless, but it is impractical for them to do so since they would earn 
> > less compared to a miner who honestly adds new transactions to the blocks 
> > and thereby earn fees from those).
>
> Yes, it would be expensive both in server costs and in cost-of-capital locked 
> up in nodes. I believe incentives are aligned correctly.

Yes, but it might not be enough --- we want SBN attestation itself to be a 
cost, and thus SBN might want to charge higher than current feerates for 
premium reliable service.


> > Further, adding more OTS-like servers may still allow a minority OTS-server 
> > to effectively censor hated furries like you.
> > Remember, we now require that SBN-nodes have 99% uptime by showing 99 
> > proof-of-uptime entries in the last 100 blocks.
> > If I have enough OTS-servers to comprise at least 2% of all OTS-servers, 
> > then I can force you, you furry, to have at most 98% uptime recorded 
> > onchain, thus effectively censoring you from the SBN.
> > This might be helped by adding some salting of some kind, and having 
> > OTS-server protocol to accept any blinded commitments that will only be 
> > opened after they are actually committed onchain, though.
>
> I like the sound of blinded commitments. Any suggestions for where to read up 
> on this approach? 

Generally when we say "commitment" that is a cryptographic 

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

[Robert Allen]

On Tue, Mar 10, 2020 at 5:11 AM ZmnSCPxj  wrote:

> Good morning Robert,
>
> > How did you know that I'm a closet furry?! ;) I'm shaking in my
> onesie right now...
>
> It was so obvious, my furdar was picking up your furriness just from
> parsing the individual bytes arising from your email server.


> > 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).
>
> Unfortunately for the poor fool who came up with that proposal, it suffers
> from "what you measure is what you get".
> Specifically, it measures node uptime, but not node correct behavior, and
> it is node correct behavior (i.e. making an effort to actually forward)
> that you want; what this proposal does is measure node uptime, which
> *correlates with* but *is not exactly identical to* node correct behavior.
>
> I find that most furries are more able to understand this with a fable, so
> let me present the issue of "what you measure is what you get" in fable
> form.
>
> Once upon a time, the government of London, seeking to reduce the rat
> problem of the city, decided to delegate the problem to the private sector,
> by offering to pay an amount for every rat tail provided by the citizenry.
> At first this seemed to work well, but eventually the rat infestation came
> back with a vengeance, even as the coffers of the city government were
> continuously emptied by the rat-tail program.
> Eventually an extensive investigation by the government officials
> uncovered the existence of *rat farms*, where private individuals grew rats
> (and where well-fed healthy rats sometimes escaped from, leading to worse
> rat infestations than before) for their lucrative tails.
>

I was familiar with this story. Also a great reminder of the dangers of
government "solutions" in general.


>
> This shows the issue: what they measured was *the number of rat tails
> shown*, not *the reduction of rats in the city*, and so they got shown a
> lot of rat tails (at the expense of actively increasing the number of rats
> in the city, since they were now being grown in rat farms).
>
> Similarly, I could attack the SBN by having a cheap RaspPi (or maybe
> Arduino) continuously attesting its uptime, but not actually running any
> Lightning node software, so that paths through my pathetic RaspPi "node"
> will always fail.
> With enough cheap RaspPis and some HODLed funds in 2-of-2s (where both
> pubkeys are mine anyway), I can ensure that most of SBN is composed of my
> "nodes" and make it worthless.
>

I guess it wasn't explicit in my proposal, but the intention is for SBN
nodes to be LN nodes. Thus, in order to be accepted into SBN, your node
would have to run the LN software. Is there a way to set up an LN node,
connect to other nodes, and then not allow routing of payments through your
node? If so, then I don't believe SBN would be any more in danger of this
scenario than vanilla LN.


> Against this, we can observe that the blockchain layer itself is
> ultimately protected by the economics of mining.
> Thus, the blockchain security cannot be better than
> economically-infeasible security, 

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

[ZmnSCPxj via Lightning-dev]

Good morning Robert,

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

It was so obvious, my furdar was picking up your furriness just from parsing 
the individual bytes arising from your email server.

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

Unfortunately for the poor fool who came up with that proposal, it suffers from 
"what you measure is what you get".
Specifically, it measures node uptime, but not node correct behavior, and it is 
node correct behavior (i.e. making an effort to actually forward) that you 
want; what this proposal does is measure node uptime, which *correlates with* 
but *is not exactly identical to* node correct behavior.

I find that most furries are more able to understand this with a fable, so let 
me present the issue of "what you measure is what you get" in fable form.

Once upon a time, the government of London, seeking to reduce the rat problem 
of the city, decided to delegate the problem to the private sector, by offering 
to pay an amount for every rat tail provided by the citizenry.
At first this seemed to work well, but eventually the rat infestation came back 
with a vengeance, even as the coffers of the city government were continuously 
emptied by the rat-tail program.
Eventually an extensive investigation by the government officials uncovered the 
existence of *rat farms*, where private individuals grew rats (and where 
well-fed healthy rats sometimes escaped from, leading to worse rat infestations 
than before) for their lucrative tails.

This shows the issue: what they measured was *the number of rat tails shown*, 
not *the reduction of rats in the city*, and so they got shown a lot of rat 
tails (at the expense of actively increasing the number of rats in the city, 
since they were now being grown in rat farms).

Similarly, I could attack the SBN by having a cheap RaspPi (or maybe Arduino) 
continuously attesting its uptime, but not actually running any Lightning node 
software, so that paths through my pathetic RaspPi "node" will always fail.
With enough cheap RaspPis and some HODLed funds in 2-of-2s (where both pubkeys 
are mine anyway), I can ensure that most of SBN is composed of my "nodes" and 
make it worthless.

Against this, we can observe that the blockchain layer itself is ultimately 
protected by the economics of mining.
Thus, the blockchain security cannot be better than economically-infeasible 
security, and Lightning, as it is anchored to the blockchain, also cannot get 
better than economically-infeasible security.
If attesting its own uptime is expensive enough, then every additional node 
that I fake is going to be an additional expense, and it may become impractical 
for me to take over the entire SBN unless I work honestly and actually forward 
payments and earn fees from it (in much the same way that a miner could always 
just mine empty blocks and make the blockchain layer worthless, but it is 
impractical for them to do so since they would earn less compared to a miner 
who honestly adds 

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

[Robert Allen]

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

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

[ZmnSCPxj via Lightning-dev]

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 

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

[Robert Allen]

Superbolt Proposal

*Introduction*

Currently, the LN user experience is far from retail ready.
Inbound/outbound channel liquidity issues and node dropouts mean that many
payment attempts will not succeed.

I have spent some time thinking through these issues and believe a BOLT
specification which would enforce a stricter set of rules for nodes to
follow and which would ensure sufficient liquidity, uptime and channel
rebalancing automation would move the needle greatly in the direction of a
UX which could go mainstream. If LN is currently resulting in many “gutter
balls,” Superbolt would be like bowling with bumpers. This BOLT would be
optional for LN nodes to use or not depending on whether they wish to
participate in the Superbolt network directly.

*The Problem*

In Christian Decker’s talk

at The Lightning Conference (Berlin, October 2019) he presented some
frustrating statistics from a study he conducted to test payment routing
success/failure on Lightning Network (LN) using payment probes. Some of the
salient points:


   1.

   48% of payment probes failed to find a payment path to the targeted
   node. This is likely because either the node itself was offline or a
   connecting node along the path was offline.
   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.
   3.

   Stuck payments (initiated but not completed) because a node died along
   the path occurred at approximately 0.19%.


It should go without saying that a payment network which works less than
50% of the time presents a user experience which will never catch on with
the vast majority of the total addressable market. If you are flipping a
coin every time you attempt to use a payment method, you will quickly
abandon this method for one which works reliably.

To make matters worse, I believe Christian was attempting to route
micropayments for his testing of the network, so the above numbers may
actually be optimistic when you factor in attempting to route larger
payments (even just a few hundred dollars worth of BTC). For example, a
route may be found for the desired payment but if there is insufficient
liquidity on one of those hops (either due to insufficient channel capacity
or because of inbound/outbound liquidity issues), then the payment will
fail.

In summary, there are two fundamental problems with LN as it is currently
functioning:

   1.

   Connectivity: Node uptime and connectivity to the broader network are
   both insufficient to guarantee payment success.
   2.

   Throughput: Node channel capacity is frequently insufficient due to low
   total capacity and/or inbound/outbound liquidity snags.


*Proposal*

I am proposing an LN BOLT, called Superbolt Network (SBN). Conceptually,
this might be analogous to an “electrical grid” for LN. SBN would enforce
and/or automate the following:


   1.

   Liquidity: Distinct and uniform LN node classes with commensurate total
   node and per channel liquidity requirements. To begin, two node classes are
   proposed.
   1.

  Routing Node (RN) - 4 BTC total node capacity, 4 x 1 BTC channels
  (0.5 BTC per side) to other RNs, 8 x 0.5 BTC (0.25 BTC per side) channels
  to ANs. 3 of 4 RN connections should be with shared peers (i.e.
A => B => C
  => A) while the 4th connection should be with an RN without
shared peers to
  ensure the network is sufficiently connected.
  2.

  Access Node (AN) - 1 BTC total node capacity, 2 x 0.5 BTC channels
  (0.25 BTC per side) to RNs. 10 x 0.1 BTC channels (0.05 BTC per side) to
  regular LN wallets/individual users/etc. RNs should be peers to allow off
  chain rebalancing via circular payments.
  3.

  Please note: Additional node classes (larger or smaller) may be
  beneficial to network performance. However, to maintain sufficient
  decentralization, it may be beneficial to have a maximum node
  capitalization limit.
  2.

   Uptime: Nodes would be required to maintain uptime to the network of at
   least 99% availability. Nodes which fall below this requirement for a
   determined period of time would be ostracised by the rest of the network
   and perhaps eventually excised completely from SBN. I believe we could use
   chanfitness  from lnd
   v0.9.0-beta
   
   and add some logic to check for fitness and then some scripting to
   automatically route around bad nodes.
   3.

   Channel balancing: To ensure that channels do not become stuck from
   inbound/outbound liquidity snags, the protocol would include some scripting
   to automate