I dunno, this is the landing page for MY fediverse instance

I'm doing my part by requesting kitchen sink features!

I don't reject covenants, I reject *recursive* covenants for the reasons explained in the email (not me, someone far more intelligent):

> Generally, it is accepted that recursive covenants, together with the

ability to update loop variables, is sufficiently powerful to be

considered Turing-complete.

> ...

> I point out here that Drivechains is implementable on a Turing-complete

language.

> And we have already rejected Drivechains, for the following reason:

>

> 1. Sidechain validators and mainchain miners have a strong incentive to merge their businesses.

> 2. Mainchain miners end up validating and commiting to sidechain blocks.

> 3. Ergo, sidechains on Drivechains become a block size increase.

Should have mentioned that it doesn't *by itself* enable recursive covenants (at least to my knowledge), but it can be combined with others (such as the proposed OP_TLUV opcode in the email thread) to implement them.

I'll really miss your insightful commentary and compelling arguments

OP_CAT enables recursive covenants https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019976.html

Reject CATs as-is.

CTV alone doesn't enable lightning symmetry (as far as I know) but the proposed LNHANCE upgrade combines CTV, CSFS (checksigfromstack) and IK (innerkey) to enable lightning symmetry.

CTV as proposed, as far as I'm concerned carries essentially no risk. It's functionally equivalent to presigned transactions, slightly more space efficient, and without the risk of mishandling keys or key leakage.

Of these, I understand the implications of CSFS the least, so I'm not sure if there are any risks, people I trust somewhat say there's no risk. Still, I prefer to understand as much as my pea brain allows. Regardless, I believe it's necessary to enable ln-symmetry with CTV.

IK is nothing but a very neat little space optimization for taproot, so it has no risks that I'm aware of.

As far as I'm concerned CTV and TXHASH are functionally equivalent. The difference is really TXHASH is trying to specify all possible behavior ahead of time but disables it for now, and CTV specifies one very specific, well understood behavior right now, but allows upgrades over time.

Preferring TXHASH over CTV basically means pushing back covenants at least 2 years, for no benefit that I can see, since CTV can always be upgraded to support new features.

zero interaction whatsoever on my occasional development posts. I get that it's technical, but isn't most of nostr?

man, same

I tried out running coracle with somebody else's npub, really neat feature, but now I want to remove them from the "switch accounts" dialogue, am I just missing it?

???

Luke's approximately right about ordinals and you're right he can't stop them.

wait what?

regtest is pretty neat, I'm disappointed I didn't invest time into learning about it until now.

I don't like that electrsd will download binaries for you though...

I use nos2x: https://chromewebstore.google.com/detail/nos2x/kpgefcfmnafjgpblomihpgmejjdanjjp

There are similar plugins for firefox (but I can't recommend one). I think alby works too.

well well well! very cool!

Man, the preview showed nothing but "Some disturbing and irrefutable evidence of a back door being put into Bitcoin Core has come to light in recent days" and I wasn't able to log into twitter (I keep it off my phone for my own sanity). That had me concerned until I finally got to read it lol

Found https://bip119.com/ which is very much in the spirit of what I'm suggesting, but it doesn't attempt to summarize, condense, or elaborate on its own, it's mainly a compilation of resources (which is a great first step!)

Of course, I don't understand your point though.

I'm not suggesting the lightning payment directly pay fees for that timestamp. Peter would accumulate lightning sats received in this way and periodically loop-out into his opentimestamps wallet, which would then help pay for opentimestamps on-chain transactions in the future.

What about accepting lightning for *that*? "Want this timestamp confirmed faster? Send me some sats on lightning."