Hi John,
Thanks for the proposal, few feedback after a first look.
> If Bitcoin and Lightning are to become widely-used, they will have to be
> adopted by casual users who want to send and receive bitcoin, but > who do
> not want to go to any effort in order to provide the infrastructure for
Hi!
I've read the start of the paper on my vacation, and am still
digesting it. But even so far, it presents some delightful
possibilities.
As with some other proposals, it's worth noting that the cost of
enforcement is dramatically increased. It's no longer one or two txs,
it's 10+.
Hi all,
We've tagged the first release of CLBOSS [1]
that is now compliant with modern CLN versions.
This was primarily a "bring back to life" effort. Special
thanks to Ken who took the initiative to revive the
work on this project.
[1] https://github.com/ZmnSCPxj/clboss/releases/tag/v0.13
On Fri, Sep 08, 2023 at 06:54:46PM +, jlspc via Lightning-dev wrote:
> TL;DR
> =
I haven't really digested this, but I think there's a trust vs
capital-efficiency tradeoff here that's worth extracting.
Suppose you have a single UTXO, that's claimable by "B" at time T+L,
but at time T
Runes today are often bound to the BOLT8 nodeid, giving both (otherwise
you need to protect your rune from being read).
I like this model *but* it requires two-way comms for setup (the HSM
tells the node its id, the node gives the HSM the rune).
Fortunately, it's trivial to support runes as an
