Partially stable channels

[ajtowns]

Hi! This is neat!

Have you considered allowing for partially stable channels? That is, rather than "The channel balance is 1 BTC, SR has $10000, SP has 1BTC - $10000" as your target, allow it to generalise to also support: "SR has 0.5 BTC plus $10000, SP has 1 BTC minus $10000" ?

That way you could allow a peer to manage their BTC exposure "My current balance is 0.5 BTC plus $10000 (actually 0.6963 BTC), but I'd like to buy $500 worth of BTC, so please change that to be 0.5098 BTC and $9500 (which is still 0.6963 BTC)".

The nice thing about stable channels (from the SR's point of view) is that all your channel transactions (incoming and outgoing payments) can be denominated in fiat currency until the channel is closed, which means you don't need to analyse every transaction for capital gains tax etc: if you receive a 0.01BTC payment, that really does act as a $509.46 payment, the channel balance in BTC just serving as immediately accessible collateral.

[toneloc]

Good day,

That is, rather than "The channel balance is 1 BTC, SR has $10000, SP has 1BTC - $10000" as your target, allow it to generalise to also support: "SR has 0.5 BTC plus $10000, SP has 1 BTC minus $10000" ?

Ah yes, this functionality will be welcome. Well, I think we could that by add something like a "Positions" class:

class Position:
    symbol: str
    quantity: int

Would have to modify check_stables function to make sure that net settlement ensures that all positions are met on both sides.

Sending the "I would like to purchase $500 of bitcoin" or "offer" message could happen either off-band or as custom LN messages.

That way you could allow a peer to manage their BTC exposure ... all your channel transactions ... can be denominated in fiat currency until the channel is closed

Yeah, the overall idea is to let users customize their BTC exposure in an easy and self-custodial way.

It would be really great if we can give users a tax-simple solution. It needs a lot of thought. Because there are a lot of tax jurisdictions, and for some users each settlement transaction may need to be treated as a separate tax lot.

[toneloc]

I think this feature would be more simply satisfied by adding in a parameter nonstable_btc_amt

When we do our calculations, we simply subtract the nonstable_btc_amt_msat from the amount that is supposed to be kept stable in dollar terms.

Hope that variable name makes sense ... it's the amount of Bitcoin we are not keeping stable.

I am working on this here, branch non-stable-btc https://github.com/toneloc/stable-channels/compare/non-stable-btc?expand=1

[ajtowns]

(I would have gone with "native" amount rather than "nonstable" I guess, but sounds good)

[toneloc]

Yeah, I like "native" better! Couldn't think of a way to phrase it.

[toneloc]

Implemented this partial stability here for CLN - https://github.com/toneloc/stable-channels/blob/main/stablechannels.py

Also did it for LND but haven't tested too much - https://github.com/toneloc/stable-channels/blob/main/lnd.py

And I am working on CLN again now

Now at each checkpoint the code gets the Stable Receiver's sats balance, then subtracts the sats that have been designated as "native-btc" and compares that result against the expected_msats per the latest price.

Below is an example of an updated start stable channels plugin command. Here we are keeping user stable and $95 and 7913 sats (around $5).

lightning-cli plugin subcommand=start stable-dollar-amount=95 native-btc-amount=7913 plugin=/home/clightning/stablechannels.py channel id=b37a51423e67a1f6733a78bb654535b2b81c427435600b0756bb65e21bdd411a is-stable-receiver=True counterparty=026b9c2a005b182ff5b2a7002a03d6ea9d005d18ed2eb3113852d679b3ec3832c2 lightning-rpc-path=/home/clightning/.lightning/regtest/lightning-rpc

Right now, I don't have a way for one counterparty to tell the other counterparty about any potential change.

Not sure how to do that. This would be kinda like a trading interface. Might need to get more use to see if that is desirable.