this should be the top comment.

Darth, are you the author? or did you copy from somewhere?

Great, either way.

36,000 bb in treasuries debt. 148bb in tether.

not exactly a rounding error but also not exactly a lot.

"Why are so many of Bitcoin’s loudest supporters the people I least want to be aligned with?

Trump. Bukele. Putin. Musk, Ken Sim."

Cause you're a moron?

If trump and bukele liked fresh air and babies, are you going to want to live like an incel in a basement?

Anyway if your enemy likes bitcoin that makes it all the more urgent that you get bitcoin before they do.

Hitler liked gold, lol.

IDK, maybe he's not wrong.

But maybe the branding problem is if you are selling to idiots you got to lie and say what idiots want to hear.

Bitcoin doesn't lie. I'm going to say that that's not actually a problem.

Why is it any more centralizing than any other thype of pool?

If it enables miners to more easily derisk their operations from price and hashrate fluctuations, they can concentrate on what they do best

MINE BLOCKS FOR CHEAP

and grow hashrate faster. Which is decentralizing.

What'm I missing?

No, he's right that spam is bad but he's wrong that we can do better than OP_RETURN as least evil sane thing.

a deep and useful comment.

more color

"many of the idiotic 'data storage' things are either intentionally or inadvertently exploiting the fact that behaving abusively about public resources gets them a ton of free attention."

"Fundamentally Bitcoin has already 'solved' the abusive resource use by limiting the total resource usage. I'll be the first to agree that the solution is far from perfect, but the alternative of chasing down the abuse, judging it, blocking it, etc. can easily be much worse and doubly so when it gives them a lot of free press and validation as "important enough to censor" -- a benefit that some parties might even be intentionally behaving abusively to secure."

from Greg Maxwell / null c ( OG dev-bitcoin )

here I agree with you.

more people should run other clients.

but it has leaders.

this isn't a feature of Bitcoin. it's a feature of primate mammals.

IMHO incoherent and misleading. also neglects to link the thread which is at

I add that towards the end of the current existing thread I think Pieter Wiulle speaks with authority, like a leader.

Another useful distinction is self infra versus delegated infra.

IE, a "bandaid wallet" like phoenix is self custody but delegated infra.

#382503 "How to Build the Ultimate Bandaid Wallet"

Nice chart!

except I would say

"delegated custody" instead of "custodial" "self custody, self infra" instead of "self hosted" "self custody, delegated infra" instead of "bandaid wallet"

I would also note that a somewhat analogous situation exists for L1 wallets where, eg, electrum spv wallet is "self custody, delegated infra"

You need to trust your infra provider even with something like electrum. IE, they can't fake work in blocks but they can withhold blocks so it seems like a payment never confirms, they can also choose which block to provide if there is a split.

Wonderful feature of bitcoin though is it makes it as safe to delegate infra as possible, from an engineering tradeoff view. IE, never completely as safe as self infra, but pretty much safe enough in most circumstances even when dealing with big transfers worth millions of dollars.

To add color to this, I think many in the room thought that the pull request you were commenting on

https://github.com/bitcoin/bitcoin/pull/31989 ( BIP-119 (OP_CHECKTEMPLATEVERIFY) (regtest only) #31989 )

should itself have not been permitted. For the same reasons as your comments on it.

I would also align with this opinion. Not just for CTV, but for any soft fork which for some fluffy (sorry I can't give the criteria) definition of consensus, is agreed as the path forward. The idea being that CTV just hasn't met this (fluffy) criteria to be forking the main repo, not even for regtest.

re "It’s unclear if Chaincode is just not doing politics to block advances on CTV, as they might be disagreeing with that consensus proposal and they wish to prevent progress by all means."

did you mean "just doing politics" ?

If so, I would agree, and I would also align with their politics, and I would also say they are trying to have a light touch commensurate to their power in the space but with an issue becoming so heated it's hard to find the appropriate level of "light" so to say.

"First and foremost, I do not like to use the word “politics” as it has a lot of cultural and historical connotation, and I’m always careful when I’m using such wording."

It's politics, rude and naked. I would compare a bitcoin softfork as something like an amendment to the US constitution, possibly even more difficult. Yes, there's going to be a lot of politics. And there's going to be a lot of amendments proposed that are not great for the US. And everyone is going to be accusing each other of black hatting.

To state my bias up front, if they are trying to slow down CTV, I align with chaincode. I am YAGNI on CTV.

However, everyone should play fair. However, if no one is playing fair, how can you play fair? That would appear to be the dilemma, in the eyes of those core devs (including those at chaincode) who control the politically important github account(s?).

I was at a bitdevs nyc meetup recently at the chaincode office, and I did feel a distinctly anti-CTV vibe. I'm not an expert, but I have followed the covenant wars enough to feel like more than just an interested bystander.

To keep this from getting too long, and also to respect chathan house rules, I will try to channel the vibe briefly.

The vibe WRT to the merits of CTV was something like "YAGNI, or at least you aren't going to need it yet." More germane to this kerfluffle, the vibe WRT to reviewing CTV on github was something like, "the bitcoin repo is not a place to politically debate the merits of CTV or any softfork. The ideal is that the github repo should be a place for technical review (bugs/errors on patches) only, having established political consensus in other channels." Delving bitcoin was mentioned, as in the rebuke you linked to.

"Github not an appropriate place to debate politics of softforks" may not be true historically, maybe not not even now. Maybe it's more of a work in progress and "we are trying to shift the communications so that..."

but I think "people in the room" would like it to be true now. I think there may also be people who for whatever agenda (maybe a bad one) want you blocked, and yeah that sucks if they are hiding. IDK if chaincode is "in control" of the github in question, my feeling is "probably to some extent but it's complicated." Whoever is running that account, one thing I think "people in the room" feel is, it's turning into a shitshow and it's putting undue stress on those who just want to do cool collected code review.

IE, I think the moderation policies are largely being driven by exhaustion and burnout, and not primarily driven by politics or anti ctv sentiment, although by and large chaincode DOES lean anti CTV but without being too obvious about it (to avoid getting sucked in to the war). Maybe you're collateral damage. Maybe it's targeted, someone doesn't like you. IDK.

Sorry you got your account blocked for the review. As someone who myself has been blocked a few times in various stupid internet troll wars (not that this is one of those, it's not, CTV is important) I encourage you to, in addition to registering the action in the appropriate channels, also use it to your advantage as a cooldown. If it's anger, anger must be channeled appropriately. If it's frustration, realize that those across the table from you are probably also frustrated.

This would probably be a different post if I wanted CTV. I would be more heated myself. I would be more worried about the future of bitcoin.

But even then, you just have to stay cool. Don't feed the trolls. Don't be a troll. Try to empathize and find common ground, even when things seem unfair.

Also you're not wrong. This is bitcoin and only the paranoid survive.

Thanks for surfacing this, and thanks for caring about CTV.

I agree that self custody is the better term, I always mention this when it comes up.

I usually say "bank custody" for the other one, but delegated custody works too.

The point is, someone always has custody. So "non custodial" is just stupid.

there's a narrative that this or that covenant opcode facilitates storage via vaults. and we already need this for whale vaults like coinbase, mstr, future bitcoin strategic reserve at fort knox if they ever get that going.

I say YAGNI to covenants for scaling reasons. In other threads on hacker news (often dialog with u/justin_shocknet) we argued the YAGNI case for covenants in scaling.

I also leaned YAGNI for covenants in vaults, but I hadn't really fleshed that out. I think reacting to coldcard's work here might be a good place to begin to do so.

I also think I saw in twitter (or somewhere) that coldcard themselves lean the other way (they like vault covenants) so I'd like to hear the other side from them if so.

Anyway here, coldcard here is pitching what can be achieved for security just using dedicated hardware and mainnet bitcoin.

most importanatly

"velocity and magnitude limits whitelisted destination addresses"

enforced at the hardware level of the signing device, iiuc.

covenants get us clawback for a limited time basically, enforced at the protocol level, iiuc.

So the debate is, do we really need clawback for a limited time, if we are already enforcing velocity and magnitude in the hardware, via a multisig setup?

Expiring clawbacks give you a security policy that doesn't rely on rate limits. IE, you can send the whole amount safely, is the idea. However, the receiver doesn't have the safety that you really sent it until the clawback expires. You could partially replicate the expiring clawback by rate limiting real withdrawals to coincide with the same time period. In both cases, in the case of a successful attack, the attacker can spend funds at the end of the time period. With the expiring clawback, the attacker either gets all the funds or none of the funds at the end of the expire period.
With the rate limit, the attacker gets funds up to the point that the attack is noticed and blocked. With the clawback, all funds can be rescued, but the "all or nothing" nature of it might lead to less vigillance, resulting in missing the clawback period. EG, the attacker also compromised the machine watchtowers or human sentries that are suppose to notice an attack happening. With rate limits, maybe there would be more vigilance to stop an attack in progress before all funds are drained.

The rate limits are also better for (legitimate) receivers, because they can plan on over what time period funds will be received, rather than having to wait a clawback time before any can be spent.

It's a bit tomato/tomahto for me.

Thoughts?

fair.

note trezor has "Bitcoin only" firmware option.

but probably doesn't get much use as not the default.

I'd also like trezor to be snobby and only support BTC. But I suppose then they'd have to raise prices.

Missing from this list is an important category, funded by hardware wallets.

For example, Trezor Suite is a software wallet designed for users of the trezor hardware wallet. It is funded by sales of the hardware.

I think ledger is another example of this, maybe there are others.