It's always an uphill battle keeping docs up to date! nostr:note1jgx352m4l7m25upqp23rqytk0tu2gly5qke8ggt83l98v0sqlhksvday0t

I know a lot is going on right now, but I finally made some time last weekend to simulate and compare some sponsoring solutions and a possible TXHASH stacking algorithm. Findings look interesting!

https://delvingbitcoin.org/t/jit-fees-with-txhash-comparing-options-for-sponsorring-and-stacking/1760

Maybe read the BIP first? It's explicitly saying that the BTC symbol stays for the 100 million base units. So it proposes 1 sat = 1 bitcoin and 1 BTC = 1 million bitcoin.

Read your shit before you start spewing opinions please.

IMO there's two parts to this. First is that CTV is relatively way more mature. Been around for a while and hasn't changed much since. So it can be adopted fast. TXHASH still has quite some room for bike-shedding.

Second is complexity. While TXHASH is way more flexible it's also an order of magnitude more complex, mostly code-wise. Needs quite some caching etc, so the code is far from trivial.

That being said, it seems that TXHASH together with CSFS enables APO in a more secure way (than CTV) and with APO, txid stability is already far less important. Which also means that indigenous fees could be a thing maybe.

We are the same 🥹🥹 nostr:note14y6sargz7fec8649qqynuzekekrqkd78xf7m39cqzftn6yfzunaqyma0mh

Initially we thought probably not. There is a high on-chain cost associated with it, and you have to run LN infrastructure. But it might be possible if you do very infrequent rounds.

But we're currently not optimizing for that.

Noted! 🙏🙌

Unless I'm getting it wrong, but it seems you're not using a framework in that project?

You're criticizing a 2yo project with a 1000 starts and recommending your last week's toy project instead? 😅 Sounds like that's in the nostr spirit 😁

If you can write crypto that implements the same API, rust-secp has tooling to provide your own C lib if it meets the API.

I am super thankful for the drawing you made! 🥰 nostr:note1df3jv7w79z9mfxn788jd32g67wkfqsdwrjkp0arhexjnzvzj4zfqzwkm84

It's instant if you mine to a random address. It's not instant if you have to do sqlite writes. I guess bdb was faster.

'100 block' 'to an address'. With the "generatetoaddress" RPC.

While y'all are checking the bitcoin price, I've got some wisdom for you developers:

Bitcoin Core's wallet seems to be crazy slow.

It takes my beefy machine 4.5 seconds to generate 100 blocks to an address in the wallet.

It takes <0.01 sec to generate to a random address.

Laat I've used it was still horrible. It would randomly start pulling in stuff shaking around the time-line every time I opened it.

It technically can't remember where I left off.

I've always been sad about some missed SI opportunities. Who has to come up with "tons", f.e., while we have the perfectly good megagram? People even go as far as applying SI prefixes to the ton, using "kiloton" instead of gigagram.

Exactly. It's atomicity with an unconfirmed tx. Luckily they're optimistic and hopefully will rarely see the light of chain.

Do you have the intention to contribute to the ark-protocol.org website?

There's ark-protocol.org that I have had really good feedback on. It describes how things work in general.

There's many facets. For one, we can do a pretty cool protocol without any covenant. Then, simple covenants like CTV or TXHASH make it a lot more powerful. But then eventually, something more powerful like MATT can probably boost it to way beyond (single tx multi-user exits fe), but that's research still and not in implementation whatsoever.

I've been noticing more and more websites and services block people using a VPN. It annoys me a lot. nixos.wiki for example block all VPN traffic.

Now it seems you can't watch YouTube videos without logging in anymore.

The internet is literally getting worse and worse every year. https://nostrcheck.me/media/a9e42a0ca6e4b1208088b68a4fd6407481b12060f915a0fecb4c8874557e3749/456467399e462010705c01ed16b1d7d462ce79122db0309bbac24b13fe91246d.webp