It's short for "pay to public key" -- the original bitcoin address type was this style, the simplest payment style.

Now-a-days there are lots of alternative payment styles. A semi complete list is here: https://en.bitcoin.it/wiki/List_of_address_prefixes

The common ones you see these days are p2pkh and p2wpkh. Eventually the taproot variants will take over as the most common.

Thanks man!

The spec is like 98% done but things tend to come up about the spec that need changing as it gets implemented. For example should we use the existing funding_locked message or have a custom splice_locked. Eclair has a 65kB message limit so we need to add a way to split commit_sig into 65kB chunks. Originally we weren’t worried about the order tx_signature was sent between nodes but it became apparent it did matter over time and the lowest sats should sign first. That also meant commit_sig needed to have a matching order.

So ya know, things like that have been popping up. Smaller in comparison to the whole spec but still all important.

Implementation wise it’s basically functionally done, with a few odds and ends to implement. Instead of finishing the odds and ends though I’m switching over to building unit tests which will give me a clear road map off all the odds & ends.

Taro’s not something I’m that interested in personally.

Having not looked into it too deeply it does look pretty quarantined away from the main protocol for what that’s worth.

It’s a poem! Wow thanks man 🙏

❤️

I think they’ll probably do all three depending on their needs!

A lot of lightning nodes keep a reserve of onchain funds ready to use for a new channel they might need later.

Splicing allows them to keep that reserve in Lightning and move it around freely.

The UX of it kind of depends on the front end you use like say RTL.

Definitely a double meat steak taco

Probably that bitcoinization will bring back the prosperity America experienced during the gilded age of the 1880s and 1890s.

A lot of people think hard money will cause some kind of recession before bringing prosperity but I suspect it will bring prosperity quite rapidly.

I thought about contributing to LND but Core Lightning felt like a better fit.

Ironically last year I thought splicing was already done 🤣. What had been done was the spec being completed.

When I realized no one was actually implementing it yet I got excited to do it. The feature just kind of makes logical sense to add. It’s simple conceptually but gets complex as you get into the weeds.

I’m not aware of a product manager over at Blockstream 🤷‍♂️

The testing / releasing process is pretty thorough. Other Lightning devs read all the code you’ve written, work to understand it, and review it completely.

At the same time automated tests will create thousands of lightning nodes on an internal test network and purposely use them abusively. If any of these tests fail than it doesn’t get in.

Once through that it will be released as an experimental feature seeking node operators to use and test it in the wild. After staying there for probably quite a while, it would be officially released.

The docs describe how to use it and that’s kind of it. At that point the only way for people to know to use it is digging through the docs or outreach telling people they can.

I suspect the larger nodes are already paying attention though and will eagerly adopt these things without needing any coaxing.

Hm that’s an interesting question and kind of hard to speculate on. Before LDK came along I didn’t think an enterprise-first style implementation would exist and now we have one of those with phantom nodes and other cool scale based features.

I think pretty highly of the existing Lightning devs out there. If they won’t add a particular feature I suspect there would probably be a good reason for not doing it.

In the near term it does feel like there is just a ton to be done and too few to do it all. But perhaps one day lightning will ossify and we’ll look be able to look back and say oh hey it’s done.

I don’t see a day like that coming anytime soon though.

One area Lightning devs aren’t working on is automated channel management and rebalancing and I do suspect that area will see some pretty awesome innovation over time. If that progress well, and I suspect it will, we’ll eventually have one button lightning node deployments that just do everything for you automatically.

Thanks man!

Day to day it’s a lot of reading and writing code. Splicing is a bit of A doozy. It affects so many other parts of code base I often find myself jumping around having to understand more and more of all that’s going on compared to a more insular feature.

Compared to previous work it’s definitely a lot lot harder. There’s two main reasons for that a think:

I got started by… just getting started I guess lol. I spent a few months just reading the code base and trying to fix little things here and there as I went. @niftynei was very generous and continually helped me work through parts that were complex to understand. As a lightning dev veteran she has a lot of deep knowledge on it all.

In the end they’re all open source projects and anyone can contribute. And how cool is it to work on Lightning? I think it’s pretty great to be able to anyway 🤣.

I think the process is the right level of difficulty at the moment.

At its core the protocol is really defined by what features nodes have & enable, negotiated between two of them.

The spec process doesn’t really have control over that, it’s more of a coordination effort that provides a place for the Lightning developers to both establish interoperability and also get vital feedback from each other.

Since we’re coding money itself that feedback process is great for revealing potential problems early on that one person may be more equipped to understand than another.

It also functions as a blue print for future Lightning implementations and I think that’s important in its own right.

For routing nodes splicing enables some cool liquidity management options.

By resizing channels you can move extra onchain funds into a valuable channel as well as move funds out of a less valuable channel.

You can even do both at the same time, moving funds between channels and there’s essentially no limit on the number of channels you can do this to at once.

And it’s all in the most efficient method possible (a single transaction) without relying on any central coordinator.