rusty @[email protected]

Last time here was 2 years ago. Let's try again! I'll be posting :Lightning: content, aiming for daily...

But once it's done, we get to do what Lisa really wanted, which is the WILL_FUND_FOR_FOOD option, where nodes advertize liquidity. This was recently done in a centralized proprietary manner by Lightning Labs, so it'd be nice to have this soon!

Finally, the same negotiation protocol can be used for splicing funds in or out of channels. The lack of this feature has been increasingly painful, particularly since c-lightning chose not to implement multiple channels to the same peer, in anticipation!

This works: your peers don't even know about each other and yet you can all construct a tx together. You can also use that tx to do other coin moves, completely unrelated.

One issue is that spy nodes can start a channel open, find out your UTXOs, and abort. There's a protocol Coinjoin uses here called PoDLE, which Lisa implemented, but it's non-trivial. Lloyd Fournier has some promising suggestions, but those still need work.

Another Opus we're working on in c-lightning is dual-funding, so let's talk about that! This is Lisa's work, but I've been following along, and pushing to make it more general.

Today, you connect to a lightning node and open a channel, and you put all the funds in. This is simple, but it'd be better if you could both co-operate to construct a tx, especially if you could do it with multiple peers at once. This requires a generic coop construction protocol, which was fun to write...

So, is my account really suspended? Got mail that said so...

Greg Maxwell laying out some truth: https://www.reddit.com/r/Bitcoin/comments/kwzslf/comment/gj7d7bn

Of course, currency conversion requires trust. But wallets *already do this*, and they should always check that the invoice reflects what the user authorized.

Anyway, there a few places it's thin (fetchinvoice only tries once, then gives up!) and the spec needs another implementation. But I hope you can see why I'm excited about this!

When I fetchinvoice this, I get a new field:

fetchinvoice lno1... 0 rusty-donation2
-> "invoice": "lni1...",
"changes": {
"msat": "13331910msat"
},
"next_period": {
"counter": 1,
"starttime": ...
}

Now, you can see the amount has changed: it's in msat. At this point my wallet checks that, and if I'm happy:

lightning-cli pay lni1... label=rusty-donation2
-> paid.

(label here ties this together, so if I try to req invoice #2 it'll check I paid #1).

1. lightning-cli plugin start ~/plugins/currencyrate/currencyrate.py
2. lightning-cli -k offer amount=5USD description="$5 weekly donation to Rusty" recurrence=1week
-> lno1qgsyxjtl6luzd9t3pr62xr7eemp6awnejusgf6gw45q75vcfqqqqqqqxqd24x3qgqgqlgzseypmk2ettd3ujqer0deshg6t0dcs8gmeq2f6hxarergpqzpc7yqdrg7x5sxuju0pgsypzsffgnrzlpkp0cng875sscne56j4626mknuzqkjksg95n6nw30ju78yvt46uqa54x8704v6xl3kdef4ddgue7acvx8ww99m7zxgkf70h34qug3676exhpuu5rdw3aaqc83hsy3l7353q

The idea is that your wallet would get your approval to pay this repeatedly, then call into this again (with counter=1 and same label) next time a payment is due.

OK, that gives me 5000 sats we week. But who does that, pre-hyperbitcoinization? Let's try harder, using the currencyrate plugin (which I just noticed hasn't been merged into https://github.com/lightningd/plugins/pull/181 because my Python sucks)...

When I fetchinvoice this, from my other node, it tells me I need a recurrence counter and label:

1. lightning-cli fetchinvoice offer=lno1... recurrence_counter=0 recurrence_label="Rustydonation"
-> {
"invoice": "lni1...",
"changes": {},
"next_period": {
"counter": 1,
"starttime": 1611204924,
"endtime": 1611809723,
"paywindow_start": 1610600124,
"paywindow_end": 1611809723
}
}

This gives me when the next pay period us, and exactly when I can pay it.

So let's make another offer:

1. lightning-cli offer amount=5000sat description="5000sat weekly donation to Rusty" recurrence=1week
-> lno1qgsyxjtl6luzd9t3pr62xr7eemp6awnejusgf6gw45q75vcfqqqqqqqgqdxyksq2yq6nqvpswdshggrhv4jkkmreypjx7mnpw35k7m3qw3hjq5n4wd68jxszqyr3ugq6x3udfqde9c7z3qgz9qjj3xx97rvzl3xs0afpp38nf49t544hd8cyq302fknxr7l6d4wnrku6kljwpjtpckwa9j8r49nguncytk8v48yjnakwu89670v8vazelkv46j74cpqjawep2mdchfdekazunl903khs

OK, I'm happy with that invoice (I can also decode it and verify manually, the changes output here is just c-lightning being helpful):

3. lightning-cli --testnet pay lni1....
-> (would succeed but I'm waiting for channel confirms on testnet!).

OK, that's cute: we can all reuse that same offer. But it's not very revolutionary, TBH.

.. OK, node is up.

It's a fresh node, so I sent some sats to it, and connected it to my testnet node.

1. lightning-cli --testnet fetchinvoice lno1...
-> "msatoshi required"
(the offer doesn't specify an amount, since it's for donations).
2. lightning-cli --testnet fetchinvoice lno1... 1000sat
-> "invoice": "lni1...",
"changes": {
"msat": "1000000msat"
}

Note: this is BOLT12 invoice, which is different from the old BOLT11 invoice. The only change from the offer is: the amount.

That's live now, so I can pay it, using two steps (cli, I know)

Actually, there will be a pause here as I spin up another testnet node!

So, here's a (testnet) donation offer: lno1qgsyxjtl6luzd9t3pr62xr7eemp6awnejusgf6gw45q75vcfqqqqqqq2r92y2565fez4ggzydahxzarfdahzqar0ypf82um50y2q7nn0wssyymr0vd4hxarjv4sk683qrg6834yphyhrc2ypqg5z22ycchcdst7y6pl4yyxy7dx54wjkka5lqsrkpdkn0f23zrzflur54mv7spp23vmuf9phspxxll2chwum8pmald9dvxkyculv3m7ftyyl97krg75l3wrst9nzenp74c2nady60ydtq

So I snuck a runtime option to enable offers into the coming #clightning release. This lets you play with the BOLT12 spec as it develops. There's no GUI front end yet, though, but you can create and redeem offers if you enable it.

It uses the onion message draft, which is also not finalized, so you need to connect to nodes which support that. Which means mine, RSN...

I've started discussions with the Australian Tax Office (ATO) on how they will treat the Taproot SF if there is a "chain-split" (their terminology). After the bcash debacle I determined that they needed expert input earlier in the process.

I can't give tax advice, but two things seem fairly clear: if there's no fork, theres no tax implications. If there's a long-lived "classic" fork then Bitcoin is a new asset, the fork is the original, and beware!

But short forks? :shrug: Awaiting answers...

One lightning thing I'm excited about is dual-funding: especially because it enables a decentralized market in liquidity provision. If course this has taken way longer than everyone hoped, partially because new good ideas keep getting added (looking at you, Lloyd Fournier!).

But the implementation and spec are both coming along nicely: 2021 should see this happen!

Last time here was 2 years ago. Let's try again! I'll be posting :Lightning: content, aiming for daily...