lightning-tools VS bolts

I have also designed my own script that attempts to measure what I call "low fee routing diversity" and score and rank potential channel peers according to how they improve that metric: https://github.com/ajpwahqgbi/lightning-tools/tree/master/channel-analysis/node-recommender .

It's definitely possible to prevent other nodes from opening channels with your node. See my plugin here. Preventing connections might be possible; at least you could monitor listpeers and automatically disconnect them.

I wrote a collection of scripts (designed for C-Lightning) to analyze earnings. See in particular get_period_pnl.py: https://github.com/ajpwahqgbi/lightning-tools/tree/master/fee-analysis

Anyway long paths or high-degree polygons are increasingly less useful. I think it's more interesting to ask something like, "How connected are the most connected parts of the LN?". For that, I have done some analysis.

My node has excellent low-fee connectivity across the LN. PM me if you're interested in opening a channel to my node. Otherwise I recommend Wallet of Satoshi or their alternate node.

You might be interested in my node recommender script which does exactly that.

Once you have at least one channel you can try doing some graph analysis on the LN to find channel peers that improve your metrics. That has worked well for me.

I made this C-Lightning plugin to do exactly that. Warning: still needs testing :).

You watch your forwarding history logs, e.g. lightning-cli listforwards for C-Lightning. You can also automate the analysis and get nice pretty-printed reports of payment volume, fees earned, etc.

True although I'm not talking about Ethereum smart contracts, I'm talking about Bitcoin ones which are very limited and not Turing complete. The lightning smart contract is like 20 lines and has been live since 2018, I feel the probability of the contract getting hacked is very low(famous last words!) https://github.com/lightning/bolts/blob/master/03-transactio...

LN is a protocol for sending signed txns around, keeping track of balances locally, and broadcasting channel open/close/justice txns. All the rules are outlined in the foundational BOLTs https://github.com/lightning/bolts/blob/master/00-introduction.md

BOLT12 offers an attempt to achieve some of the core functionality that LNURL provides without requiring the use of a web server. An offer encodes the data necessary to reach a node to request an invoice to make a payment, either a node_id, or a blinded path (the last few hops in an onion route, pre-computed and encrypted) to that node using onion messages. It also can encode a minimum amount for a payment, the currency being paid in, an expiry time and minimum/maximum quantity numbers (for purchasing multiple items).

In practice, I do not know if this is possible. I am quite unfamiliar with Bitcoin OpCode scripting and if the revocation tree of the channel state (which is just an unpublished Bitcoin contract) is expressive enough to allow inputting an arbitrary address to recieve the attacker's funds. I am attempting to use this documentation as a clue to whether or not, and how this might be possible: https://github.com/lightning/bolts/blob/master/03-transactions.md.

No they can't, that's the whole point of onion routing. The next hop doesn't know if the packet started with you or if you're just another node in the payment path.

Reference: https://github.com/lightning/bolts/blob/master/04-onion-rout...

There is a discussion to add to the lightning BOLT specification for 'inbound fees' which essentially enables a 'rebate' for using a particular channel to route through your node.

Basis Of Lightning Technology BOLT specificiations

tbh i have a text file with definitions of many of these because I constantly confuse them, most of which were pulled from using search at https://github.com/lightning/bolts and similar