Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

#

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Jump to bottom

Readme benefits and proxy suggestion #29

Merged
merged 1 commit into from
Nov 4, 2022
Merged

Readme benefits and proxy suggestion #29

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
113 changes: 55 additions & 58 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,89 +1,86 @@
# L[ightningPayJ]oin: Automated External Lightning Channel Funding

This server leverages Pay-to-Endpoint to negotiate channel funding on your lightning node from an external wallet supporting BIP78. Previously, external funding could only be done by [signing PSBTs manually](https://github.com/lightningnetwork/lnd/blob/master/docs/psbt.md). A node running this software can open a new scheduled lightning channel upon payment receipt from e.g. BTCPayServer with a normal QR scan transfer flow.
Nolooking leverages Pay-to-Endpoint ([BIP78](https://github.com/bitcoin/bips/blob/master/bip-0078.mediawiki) PayJoin) to negotiate a channel open for your lightning node from any BIP78 [supporting wallet](https://en.bitcoin.it/wiki/PayJoin_adoption). Previously, custom PSBT channel funding could only be done by [signing PSBTs manually](https://github.com/lightningnetwork/lnd/blob/master/docs/psbt.md). A node running nolooking can open many new lightning channel with every inbound transaction, provided the payer supports BIP78. E.g. by using Sparrow wallet, BTCPayServer, or Wasabi; following the normal QR scan and payjoin payment flow. Read the article about [Lightning Powered PayJoin](https://chaincase.app/words/lightning-payjoin?ref=github) to hear how it can save your privacy, time, and money!

## ⚠️ WARNING: ULTRA-EXPERIMENTAL SOFTWARE

❗️ **This project is pre-alpha quality and lacks basic checks. It is NOT fully BIP78-compliant** ❗️

Any unexpecected node setup or message will likely cause permanent loss of funds.
Any unexpecected node version will likely cause permanent loss of funds.

For the love of god, do NOT use it on mainnet just yet!
If you don't want to wait long, help with reviews and PRs
## Usage

## Benefits
Requires:
* Rust version 1.48 or higher to compile
* LND v14.2 or higher

Read the article about [Lightning Powered PayJoin](https://chaincase.app/words/lightning-payjoin?ref=github).
* **Only works with a LND 0.14** - do **not** attempt to bypass the check - guaranteed loss of funds!

### Expected fee savings

The classic scenario of sending to LND wallet and then opening a channel involves two transactions.
With this software's PayJoin it involves just one transaction, saving 106 vB (68 vB input + 22 vB script pubkey + 8 vB output amount + 4 vB version + 4vB timelock).
Sending to a node and then opening 10 channels can turn 11 transactions into one, saving 1060 vB.
If someone were to pay you and you already scheduled to open channel openings, you would save too.
You will also save a shedload of time you would otherwise spend waiting for confirmations.
(There's `--spend-unconfirmed`, but that has its own drawbacks)
Install:
1. Build and install the binary with
```
cargo install --path .
```
2. Setup a reverse HTTP proxy with HTTPS forwarding to some port - e.g. 3000.
You can do this in a few lines using [local-ssl-proxy](https://www.storyblok.com/faq/setup-dev-server-https-proxy). Or use NGINX.
3. Create a configuration file `nolooking.conf` containing:
```
bind_port=3000
endpoint="https://localhost:3010"
lnd_address="https://localhost:10009"
lnd_cert_path="/home/dan/.lnd/tls.cert"
lnd_macaroon_path="/home/dan/.lnd/data/chain/bitcoin/mainnet/admin.macaroon"
```
- Lines starting with `lnd_` specify your connection to your bitcoin node.

### Expected privacy implications
- You will be able to view the nolooking site on `bind_port` and the payjoin endpoint will be `endpoint` (e.g. can be a domain).

If you open a channel with a usual LN wallet, common input heuristic makes a good assumption that the change belongs to the funder.
This tool breaks that assumption. It could now be a payer's change.
This tool may produce many changes. Because it breaks analytic assumptions regarding bitcoin transactions in general, many transactions on the network have a larger set of possible interpretations.
4. Run with `nolooking --conf nolooking.conf`
5. Visit Nolooking on [127.0.0.1](http://127.0.0.1:3000) and queue some bitcoin channels.
6. Generate the QR code, pay it or share it! Once a payjoin transaction has enough confirmations, your new lightning channels will be established and you can move your sats over the lightning nework!

Just as with any other PayJoin, it's unclear whether all inputs belong to the funder or some of them don't.

Sadly, I don't think the payer can safely open a channel from change(s) but I have some ideas how it could be achieved in the future.
If the channels were truly private it'd make analysis even more confusing (incorrectly assume it's one node).
## Expected fee savings

Post-Taproot-LN it will be impossible to distinguish CoinJoin from batch open of several same-sized private channels.
Actually, CoinJoin and batch opening of several same-sized private channels could be one transaction.
Good luck analyzing that!
In the traditional path for opening a lightning channel, you first must fund the LND wallet and then make a second transaction to fund the opening of the channel, a total of two transactions.
Nolooking however does this all in a single transaction, saving **106 vB** (68 vB input + 22 vB script pubkey + 8 vB output amount + 4 vB version + 4vB timelock).

### UX implications
If you wanted to fund a number of channels, say 10 channels, this would traditionally take 11 transactions. Nolooking can do this in a single transaction - saving 1060 vB.

All this is possible without nolooking by [manually exchanging PSBTs](https://github.com/lightningnetwork/lnd/blob/master/docs/psbt.md).
BIP78 turns that tedious back and forth into scanning/clicking one link followed by confirmation in the wallet.
In other words, your grandmother will be able to somewhat privately open a bunch of channels for you, if she has a BIP78-capable wallet.
You can also schedule channel opens, such that when someone goes to pay you lightning channel funding transactions piggyback along with their payment. Again not only saving fees and also saving you a shedload of time since you don't have to wait for confirmations in between each successive channel open.
(There's `--spend-unconfirmed`, but that has its own drawbacks)

## Limitations and future plans
## Expected privacy implications

* **MOST LIKELY UNSAFE** does not implement required BIP78 checks
* **Only works with a LND 0.14** - do **not** attempt to bypass the check - guaranteed loss of funds!
* To work with an *empty* LND wallet you need to use LND 0.14.2
* Funds in LND or other wallet are not used, so it's not true PayJoin, just abuses the protocol to coordinate PSBT.
* Unpolished UI
* No way to inteligently manipulate the amount
* No discount possible
* Invalid request can kill whole server
* `.unwraps()`s EVERYWHERE!
* I swear I knew about a few more but can't remember right now :D
If you open a lightning channel the usual way, common input heuristic makes a good assumption that the change from this funding transaction belongs to the funder.
The payjoin provided by nolooking breaks that assumption, where this change could now be the payer's change instead.

## Usage
Just as with any other PayJoin, it becomes unclear whether all inputs of a transaction belong to a single funder or whether there are indeed multiple parties funding the transaction.

Because this tool breaks analytic assumptions regarding bitcoin transactions in general, using it will add transactions to the network which have a large set of possible interpretations and thus better privacy.

0. You need Rust version 1.48 or higher to compile this.
1. You need LND v14.2 or higher
2. `cargo build [--features=test_paths]`. The test_paths feature will serve the `static/index.html` ui contained in this folder rather than one in `/usr/share/nolooking/static` in production.
3. Setup reverse HTTP proxy with HTTPS forwarding to some port - e.g. 3000.
You can do this in a few lines using [selfhost in Cryptoanarchy Debian Repository](https://github.com/debian-cryptoanarchy/cryptoanarchy-deb-repo-builder/blob/master/docs/user-level.md#selfhost). or [on MacOS](https://www.storyblok.com/faq/setup-dev-server-https-proxy)
4. create a configuration file based on `config_spec.toml`. This is mine based on a [polar](https://lightningpolar.com/) lightning network simulator setup. `CONFIGURATION_FILE=nolooking.conf`:
## Future research
Sadly, I don't think the payjoin sender can can also safely open a lightning channel using change from the transaction, but I have some ideas how it could be achieved in the future.

```configuration
# nolooking.conf
If lightning channels were truly private, then this tool could make chain analytics even more confusing since heurestics may incorrectly assume a transaction funds a single node instead of two or even several.

bind_port=3000
endpoint="https://localhost:3010"
lnd_address="https://localhost:10004"
lnd_cert_path="/Users/dan/.polar/networks/1/volumes/lnd/dave/tls.cert"
lnd_macaroon_path="/Users/dan/.polar/networks/1/volumes/lnd/dave/data/chain/bitcoin/regtest/admin.macaroon"
```
With Post-Taproot-LN it will be impossible to distinguish a CoinJoin from a batch open of several same-sized private channels. Actually, CoinJoin and batch opening of several same-sized private channels could be one transaction. Good luck analyzing that!

5. `cargo run --features=test_paths -- --conf CONFIGURATION_FILE_PATH FEE_RATE DEST_NODE_URI AMOUNT_IN_SATS [DEST_NODE_URI AMOUNT_IN_SATS ...] [CHAIN_WALLET_AMOUNT_SATS]`
6. Copy BIP21 from command line output and paste it into one of the supported wallets. I use [the payjoin crate client](https://github.com/Kixunil/payjoin/tree/master/payjoin-client) to make a payjoin right from regtest bitcoind.
7. Confirm the transaction and move some sats over the new channel
## UX implications

All of this is possible without nolooking by [manually exchanging PSBTs](https://github.com/lightningnetwork/lnd/blob/master/docs/psbt.md).
BIP78 turns that tedious back and forth into scanning/clicking one link, followed by confirmation in the wallet.
In other words, your grandmother will be able to somewhat privately open a bunch of channels for you, using her BIP78-capable wallet on her iPad.

## Limitations and future plans

Note: if `CHAIN_WALLET_AMOUNT_SATS` is present a single-sig output will be added to LND's internal wallet.
A minimum internal wallet balance of 10,000 reserve sats per channel up to 100,000 sats is required for anchor commitments. This [can be automated](https://github.com/Kixunil/loptos/issues/11) in the future.
* **UNSAFE** -- does not implement required BIP78 checks
* **Only works with a LND 0.14** - do **not** attempt to bypass the check - guaranteed loss of funds!
* To work with an *empty* LND wallet you need to use LND 0.14.2
* Funds in LND or other wallet are not used, so it's not true PayJoin.
* Invalid request can kill the whole server
* `.unwraps()`s EVERYWHERE!

## License

Expand Down