Lightning Network (testnet)

[phm87]

WORK IN PROGRESS - Dangerous !

TESTNET Development: OK
MAINET Development: in progress (please feel free to review/comment the logic, ideas and the code)

Using Lightning Network to pay miners instead of onchain (bitcoin) payments will reduce payment fees allowing to pay miners more frequently and for small amounts. This will reduce risk as funds will be paid more quickly.

Pool LN node/wallet will pay invoices of miners so only few channels will be created and funded properly. Pool operator maintains one pool LN wallet/node for all miners leading to reduce the number of potential problems. Onchain payments are used as fallback payment method or to pay the balance not paid using LN. If miners sends a stream of invoices, all balances can be paid on LN leading to reduce fees and avoid onchain transactions when possible.

Payments with LN can be used with several altcoins that implemented LN from bitcoin so it can be used with and without auto-exchange.
BTC, LTC, VTC, VIA, stellar lumens, Bitcoin private, Ravencoin, DCR
Nimiq, FTC, GRS, CHIPS, SYS, ...
https://bitcointalk.org/index.php?topic=1891745.0
https://bitcointalk.org/index.php?topic=1777136

To set up the Bitcoin and Lightning Network nodes, I used this tutorial:
https://andrewgriffithsonline.com/blog/180330-how-to-setup-a-lightning-node/
But it may be better to use lnd rather than c-lightning.

The implementation of LN into yiimp will be splitted into several versions of the code.

V0: Testnet (invoice into workername)
All visitors are able to send invoices to pay on testnet without restrictions using /site/ln
Pool operator should setup a BTC (or altcoin) node, a LN node, create and fund some channels prior to be able to pay invoices.
YAAMP_LN_NET should be set to TESTNET and YAAMP_LN_ENABLED set to true and YAAMP_LN_WORKERS to true or false. Setting YAAMP_LN_WORKERS to true allows the miners to send each invoice using the workername.
As each LN invoice should be passed by the webpage or with the workername by reconnecting the worker, this solution is inefficient, it is a proof-of-concept.

This development is finished and published to allow reviewing.

V1: Mainet

• move invoice INSERT into runLightning loop + adapt payment loop based on DB only + forbid to insert invoices if payments are going on
• SQL enhancement to select NEW invoices/workernames
• enhance LN string check
• add a help text for LN on index
• finish fees calculations
• display invoices on miner's personnal wallet page
• disable balance reduction if TESTNET but keep calculations for worker work

V2:

• rpc instead of direct calls
• add a hacker detector for LN (similar logic to "too many bad submits per second")
• fill automatically the LN BTC address, create channels and fund the channels

V3:

• stream of invoices (ccminer change needed + stratum)
• several workers to pay the same

V4:

• pay invoices of high amount with a short expiry period (Possible to use miner's existing balance safely if the stream of invoices if secured enough)

Security:

LN introduces new potential problems:

1. Wrong invoices (missing characters, additional spaces, wrong enconding, invoice without amount, expired invoice)
   1.1 In the V1 of the implementation, as the workername is used to let the miner send the LN invoice, the string will follow the same restrictions of the workername. In addition, if there is an additional space or a wrong character, it won't be taken into account as an invoice and it will be taken into account as a normal workername.
   https://github.com/tpruvot/yiimp/blob/next/stratum/client.cpp#L225

1.2 Some checks should be implemented to verify that the invoice is not expired.
1.3 A default LN payment value can be defined to be able to pay invoices without an amount (e.g. 1000 sat).

2. Fake invoices (invoice sent for another miner)
   A malicious miner could send an invoice trying to be paid on the balance of another miner.
   In the V1 of the implementation, an accounting per worker and submission of the invoice using the workername will prevent such an attack.
   In the V3 of the implementation, a stream of invoice is sent by ccminer to yiimp stratum. If accounting per worker is kept and that the stream of invoices is secured, the attack won't be possible.

3. Several disconnections/reconnections of a worker
   Yiimp stratum have already some features for this.

4. heavy load if "DDoS" of good/wrong/fake invoices
   Logic and code enhancement can reduce this problem. Future log analysis will help.
   The hacker detector forseen in V2 will address this problem more efficiently.

5. LN fees :
   As the aim is to be able to pay all LN invoices, the fees related to the "route information" provided should be taken into account:
   https://github.com/lightningnetwork/lightning-rfc/blob/master/11-payment-encoding.md#on-mainnet-with-fallback-address-1rustyrx2oai4eyydpqgwvel62bbgqn9t-with-extra-routing-info-to-go-via-nodes-029e03a901b85534ff1e92c43c74431f7ce72046060fcf7a95c37e148f78c77255-then-039e03a901b85534ff1e92c43c74431f7ce72046060fcf7a95c37e148f78c77255

In particular, a malicious miner could set up several LN nodes with high routing fees and generate an invoice from a LN wallet that is reachable only via the miner's nodes. When the invoice with extra routing info is paid, the miner would receive his payment and collect the high routing fees introduced by his malicious LN nodes. The LN network itself is able to prevent this kind of cases in a normal situation: all other nodes would be incentived to create channels with the miner's wallet to bypass the malicious nodes. The concurrence between LN nodes to route payment and receive the routing fees.

When paying an invoice with LN, there are some limits/checks on fees:
"The 'maxfeepercent' limits the money paid in fees, and defaults to 0.5.
The maxfeepercent' is a percentage of the amount that is to be paid. The exemptfeeoption can be used for tiny payments which would be dominated by the fee leveraged by forwarding nodes. Settingexemptfeeallows themaxfeepercentcheck to be skipped on fees that are smaller thanexemptfee`
(default: 5000 millsatoshi)."
https://github.com/ElementsProject/lightning/blob/master/doc/lightning-pay.7.txt#L22

The malicious miner with control over some LN nodes as described here above would be incentived to send invoices with an amount below the 'exemptfee' of 5 satoshis. So in this implementation, the minimum amount of each invoice could be set to 6 satoshis.
ElementsProject/lightning#1765

But based on tests on testnet, for some huge LN nodes that receive payments, fees are too high. So, if the payments fees are still paid by the pool, the minimum amount can be set to 100 but in some situations, 1000 satoshis can be a better choice. We'll keep 1000 sat (0.06€ in september 2018).

Question: are the extra routing info mandatory to follow ?
=> This question was raised in the LND Slack, see (Q1)

Whatever the extra routing info are mandatory or not (to follow), the 'maxfeepercent' will make this attack not possible or not profitable.
As it is not possible to know if a LN node used for routing is malicious (high fees and forced topology) or not, a standard limitation on the sum of routing fees would be sufficient. It is not possible to forbid miners to set up LN nodes to obtain the routing fees.

(Q1)
Hi,
I'd like to know if it is mandatory to use the routing nodes provided in an invoice as "extra routing info to go via nodes x y z". If someone sets up several LN nodes and force the topology to be sure that payments to his wallet will be routed through his nodes, can he get routing fees ? How to prevent such a case ?
Thank you

https://github.com/lightningnetwork/lightning-rfc/blob/master/11-payment-encoding.md#on-mainnet-with-fallback-address-1rustyrx2oai4eyydpqgwvel62bbgqn9t-with-extra-routing-info-to-go-via-nodes-029e03a901b85534ff1e92c43c74431f7ce72046060fcf7a95c37e148f78c77255-then-039e03a901b85534ff1e92c43c74431f7ce72046060fcf7a95c37e148f78c77255

moli:
@phm87 routing fees are very low, more likely he's losing money than making any

vegard:
we're starting to see routing fee limits, too. it's likely your node will just reject doing the payment if no suitable route is found. And too high fee makes it unsuitable.

moli:
i think the competition to earn Lightning fees when the network matures will be fun to watch, i don't think spammers will win
because the worst scenario is users would just have their channels opened directly to their targets (ie, who they want to pay) and bypass spammers

The increased security risks of Lightning
Requirement to be online when receiving a payment: As explained above, before receiving a payment, the recipient needs to sign a reclaim transaction so that the sender knows they can reclaim their funds in the event of hostile channel closure or a refusal to sign. Therefore, to receive money requires a hot wallet, meaning that private keys are potentially exposed if a security incident occurs.
Requirement to monitor the channel: Lightning Network participants or watchtowers may be required to actively monitor the payment channels. This could place a burden on users or watchtowers and potentially reduces the security of funds inside a channel relative to Bitcoin stored on-chain. There is a risk of missing a reclaim-transaction deadline, either due to a failure to appropriately monitor the channel or perhaps because of on-chain network congestion.
Miners could censor channel-closing transactions: 51% of the hashrate may have the ability to steal funds from Lightning users by censoring a channel-closure transaction, in which the miner is the other party. Although the potential consequences of this type of attack are already devastating without Lightning, the Lightning Network potentially offers hostile miners a slightly larger attack surface.
While each of these three factors alone may not be significant, the need to potentially expose one’s private keys to the Internet when receiving payments, the risk of a hostile channel closure, and the risk of miners censoring channel-redemption transactions combined result in significantly inferior security — although all these risks can be managed to some extent.

There is a risk that lazy or poorly informed users keep too much money in a channel and funds are lost or stolen due to one of these failure scenarios. There is also the risk that price volatility results in users keeping more funds in payment channels than they would otherwise have intended.

Extract from https://blog.bitmex.com/the-lightning-network/

Usual potential problems should also be taken into account:

1. SQL Injection (bolt11 string, description field of the invoice, LN Receiver's name)
   1.1 the bolt11 string cannot be used to make injections as the checks of the workername are still applied
   1.2 TODO: the description of the invoice should be more filtered
   1.3 the LN Receiver's name is currently not retrieved and saved automatically. If it is performed, a filtering should be performed to prevent injections

2. XSS hacks
   The filters decribed here above can be insufficient for "HTML hacks" when special characters are escaped in HTML or else to perform injections. No existing field in any form was modified. A new field was added into a new webpage /site/ln.php for testing purposes (admin only for mainet but you can open it for your visitors on testnet). Some checks to prevent XSS hacks were added to this new field.

3. Dangerous commands to forbid (similar to dumpprivkey, backupwallet)
   Nothing found into the doc:
   https://github.com/ElementsProject/lightning/tree/master/doc

[phm87]

Code comparison more clean:
next...phm87:LN

As discussed with Elbandi2,

• a rebase of branch should be performed
• lightning-cli exec calls should be replaced by curl rpc calls (LND have rpc calls and it may be possible to use rpc calls with c-lightning if using lightning charge or using https://github.com/alecalve/c-lightning-http-rpc/blob/master/README.md or similar).

[phm87]

As discussed with Olocrom on CryptoFR Slack, implement Lightning Network within mining pools can be a huge advantage in the long term (reduce fees to pay miners, risk reduction as payments are processed more quickly) and a nice feature could be to let each miner send a stream of invoices that the pool pay according to the miner's hashrate. Using the webpages to allow each miner to send invoices can be handy but it can create several security issues as side effect.

The stream of invoices can be implemented in yiimp and ccminer to let ccminer send invoices. To avoid that a malicious miner spends the funds of another miner, the stream of invoices should be paid restricted to the worker balance (and the miner's balance), i.e. only hashrate of the worker will be taken into account to pay the invoice (or the stream of invoices).

When pools'onchain payments occurs, the remaining of balances are paid onchain (if above the minimum payout). If miners send enough invoices, the value transmitted over LN will be above the value transmitted onchain.

The pool established and funded the LN channels (not automated). This will reduce the number of bitcoin onchain transactions and this will avoid that each miner creates a LN wallet (or node) and opens channels with small fundings.

Remark: the invoices that miners send can be invoices to pay anything (a service or themselves) so it is not mandatory for miners to have a LN wallet/node.

[phm87]

As the V0 Testnet implementation is finished, tested fine on powalt.net and code pushed into github, I asked Revasz to test the V0 implementation on testnet:
Revasz#21

I'm not sure if explanations provided to install it are sufficient.

[phm87]

[phm87]

[phm87]

A new functionnality was added to LND allowing to send an amount without an invoice from the receiver:
lightningnetwork/lnd#2455

This feature is a major enhancement to let pools pay miners without receiving invoice (and risk to be DDoS of fake invoices). This feature should be added to the specification of LN to let other implementations add the feature. c-lightning was used in this demo/test in this PR#292

About the problem/limitation that both sender and receiver must be online to send/receive an amount, yiimp is designed to execute again failed payments so miner will receive their earnings sooner or later. But about LN itself, if the miner is offline, there is a potential risk that channels can be attacked but this risk is small because the attacker won't know if miner have a watchtower. A watchtower is another LN node (linked cryptographically with the miner LN node) that check that no channels are attacked and it will get all funds of attacker if an attack if detected. Watchtowers will take a small fee for their work. One idea would be that each yiimp pool can be a watchtower of channels with other pools.

There is neutrino (LN client on mobile with enhanced protocol for low bandwidth and low data transfert) that is interesting to mitigate this problem:
https://github.com/lightninglabs/neutrino (still on testnet)