By

Note: if CHAIN_WALLET_AMOUNT_SATS is present another output will be added to send the amount to the internal wallet. This may be required in case the wallet is empty as in such case LND can not reserve sats for anchor commitments. However, to truly work, you need LND 0.14.2.

I thought LND 14.2 would be able to open a channel without setting CHAIN_WALLET_AMOUNT_SATS. What am I missing? Is there some setting to allow 0 internal wallet balance opens? Is that behavior even desirable or is the on-chain utxo better?

Running LND 14.2 (and 14.0, 14.3, 15.0) from lightning polar. Loptos works like a charm with CHAIN_WALLET_AMOUNT_SATS set sufficiently high.

Using lnd version: 0.14.2-beta commit=v0.14.2-beta Calling getInfo() returns thread 'main' panicked at 'failed to get info: Status { code: Unknown, message: "unmarshal v1: cannot parse field name", metadata: MetadataMap { headers: {"content-type": "application/grpc"} }, source: None }'

Any help would be appreciated. Thank you

Builds on top of https://github.com/chaincase-app/nolooking/pull/30 Squashed from original PR: https://github.com/DanGould/loin/pull/1

"/pj/schedule" creates a qr code in qr_codes, as <address>.png which is retrieved on the website and shown.

Not sure if we can do the styled QR code as easily as we could with the other library, we can try some CSS

The new version improves developer error reporting and reduces warnings in the generated code.

Cc @DanGould you may want to import this change into your fork. build/test/check with --features=configure_me_codegen/spanned during development to get nice error messages in case of malformed configuration specification.

Got a working example using Wasabi. In the process of getting everything set up, I updated some docs, updated some dependency versions, gitignore, and setup a template config file. Hope others will find this useful

calculate fees seems to work for a subset of possible transaction creations. What do the magic numbers mean? I'd like to add the ability to batch another arbitrary output. Nolooking also failed to meet min relayfee in an off by one error when sending from sparrow (https://github.com/chaincase-app/nolooking/issues/34)

https://github.com/Kixunil/loptos/blob/4390bb008bbd67b4428bbd46b6fe11dc109c4489/src/main.rs#L187-L195

With Taproot we can turn PayJoin-based opening into Stonewall-like transaction:

• Let the desired channel size be between min and max
• If the original transaction has a single change of change_value which is between min and max and the wallet already has reserve for anchors:
  • Add our UTXO(s) such that (paid_amount + added_utxos_value - change_value) / 2 is between min and max
  • Create three channels A, B, C; A, B having value (paid_amount + added_utxos_value - change_value) / 2, C with change_value; fourth output is the original change
• If change_value is out of range or (the wallet doesn't have reserve and change_value is larger or equal to required reserve)
  • Consider doing the same as above but instead of channel C create a non-channel UTXO
  • C has same value as it would following algorithm above
• If original transaction has no change
  • For payment values between up to 4*max open four channels simulating Stonewall (add our inputs if needed)
  • For payment values above 4*max open two channels with max value and split the rest into two UTXOs. This is a bit of a footgun, those UTXOs should not be joined.
• If the original transaction has two changes of equal value
  • Split the payment into two channels, add our inputs if required to meet min requirement
• If the original transaction has two changes of unequal value
  • Can we find UTXO(s) such that sum of the changes equals payment_value + added_utxo_value?
  • If yes do it and create two channels with values equal to change values
• If the transaction has two equal values x and one unequal value y
  • Can we open exactly one channel with the value y?
  • If not, can we open one or more channels of value x? (Looks like Wasabi CoinJoin, consider adding an output faking fee.)
• If the transaction has multiple outputs, some of them being equal to x
  • Same as above - last option
• If the transaction has a bunch of outputs none of them being equal
  • Probably not worth it trying to look like CJ. Try looking like an exchange withdraw instead - add outputs randomly.
• Failing to find suitable UTXOs
  • Consider creating two channels of the same value
  • Consider keeping reserve of same value as a single opened channel
• Failing steps above continue with the usual (current) flow which still has some privacy

Plus have some tool that simulates this for direct open from LND wallet. Note that not all edge cases are covered by the above

Each case should make sure there are at least two inputs. This trick assumes at most two channels will be announced, ideally none. Chain analysis still doesn't know whether any of the unannounced UTXOs is change or private channel. Shitty chain analysis that doesn't listen to LN gossip is confused more than those that do. At most two channels are with the same node (non-strict-forwarding public-private trick.)

Some of the tricks may be useful without Taproot (CoinJoin-like opening).

Examples:

• 1-2M sats requested size; 1.5M change, 5M payment, original TX has multiple inputs => one channel 1.5M, two 1.75M channels, 1.5M change
• 1-2M sats requested size; 1.5M change, 5M payment, original TX has a single input, we have 0.5M output => one channel 1.5M, two 2M channels, 1.5M change

Currently if any LND call fails we just blow up the entire thing. It'd be nicer to attempt to continue skipping the failed channel and if no more channles are scheduled then continue with just ordinary PayJoin.

https://github.com/Kixunil/loptos/blob/965aeda80a0e81b3250585020608e2e9ab533542/Cargo.toml#L17

rust-bitcoin has feature base64 adding the capability to create a PSBT from a base64 string and viceversa