Oh good! I'm glad I won't be the only one with an english-only nostr client lmao
I do think i18n is very important, but when you're a one-man shop, you gotta prioritize aggressively.
If you have near unanimity from users, sure.
degens are the ordinals, runes, shitcoiners etc
Tiffany really appreciates technical Bitcoin discussion!
UASF is really only useful in exactly one situation: miners misbehaving.
Regardless, the "degens in the driver seat" is repulsive to anyone I think.
> groom the public for further attacks on Bitcoin.
In what fashion?
can't get tired of this 😂
https://cdn.satellite.earth/68311c3b0ee7f76d85c0c3472ae47cf38eff9dbe90562120c86346b7f04584ef.mp4
The articles markdown, right? I'm probably one of very few, but I'd prefer to draft and edit markdown myself in vim, and just paste it into highlighter (preferably with preview since I don't know the precise markdown flavor).
Is that possible in highlighter? I don't see how to do that with the rich text editor for articles, at least.
Good Lord they're bragging about being "only" 25k minimized. Web developers MUST BE STOPPED.
🤔 🤔 🤔 🤔
That's part of it, the trust model with drivechains is basically that 51% of miners can steal coins from the drivechains. But this is an opt-in risk so I don't mind it so much (doesn't affect non-drivechain users)
The other part, that I worry more about, is that drivechains can end up becoming shitty block size increases. The problem is if the drivechain is important and successful, the miner may end up incentivized to monitor the drivechain, which gives big miners with more resources a financial advantage, this contributes (an undefined amount) to mining centralization, which is the enemy of bitcoin's continued survival.
Is it a big enough problem that we should block all proposals that enable it? I dunno, but I'm not willing to bet bitcoin's future that we know the answer, any time soon.
Whereas there are several very safe and well understood upgrades (like CTV) that don't introduce risks like this.
No the risk is that it enables drivechains. It was such a bold claim I didn't want to make it myself but Rearden confirmed what I suspected. Shinobi thinks so too.
If you're familiar with taproot, a taproot output is
tweak(internal_pubkey, fancy_hash(taptree)) (the result of this is also a pubkey)
When you spend with the taptree (script path) your witness (spending info) includes that `internal_pubkey` which takes up 32 bytes. It's a very important part of validating a script spend, but it's also kind of 32 wasted bytes.
OP_INTERNALKEY just pushes those 32 bytes of pubkey onto the stack so you can use it in your script. (32:1 compression ratio for a public key used in your scripts!)
It's not always usable, but it often is, nice, significant space savings.
I have a feeling we won't get a soft fork for new OP Codes for at least another 5 yrs.
And that's ok.
sad, CTV has been ready for years now and is very conservative and safe. (plus it gives us simple vaults!)
All recursive covenants are like that, the risks are MEV related mostly, otherwise we may as well just do CAT and say fuck incentives.
OP_CTV + OP_CHECKSIGFROMSTACK + OP_INTERNALKEY
A very productive, probably safe improvement that allows lightning symmetry and all sorts of other great things (mostly coming from OP_CTV alone)
OP_CHECKSIGFROMSTACK is the only potentially dangerous opcode in that, CTV and INTERNALKEY are both very, very safe.
VAULT carries a script segment forward across transactions, that's a pretty big risk. According to Rearden:
> Both CCV and VAULT give rise to hashrate escrow type recursive contracts, which may be a reason to be cautious about adding them to bitcoin script.
> Both CCV and VAULT give rise to hashrate escrow type recursive contracts, which may be a reason to be cautious about adding them to bitcoin script.