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.

nice acronym, BBC!

It occurred to me that another overlooked factor is future evolution of lightning node reputation, which is possible even with nymous nodes hiding behind tor.

I think routing nodes are unlikely to cheat because it violates their business model, like miners are unlikely to help double spend cheaters even if there is a short term benefit. These are human beings behind the servers, with morals (some without but still with reputation) and if the game theory INCLUDING human factors and psychology works, lightning will work. Just like bitcoin works, even if you could argue some cockamamie goldfinger attack scenario where miners should 51% attack bitcoin and profit with defi shorts if they were rational, but somehow they don't.

So the minimum safe capital to defend a channel under 99.999% probability conditions, may be much lower than a cold blooded mechanistic analysis that ignores human factors and reputation, might suggest.

Peter Todd's view of the basic math is laid out here:

I neglected to include the alex bosworth scaling commentary in the top post sorry, here it is:

The same thread contains a discussion of why I now distrust the ark push for a covenant softfork:

quoting peter todd

""On-Chain Fee Payment In Unilateral Withdraw Similar to Lightning, the economics of on-chain fee payment and the actual value of a V-UTXO after fees determine whether Ark usage meets our definition of an L2 via unilateral withdrawal, or fraud failing to benefit the ASP. We’ll discuss the specifics of this further when we discuss the txout tree design pattern.""

justin_shocknet: "I think its fair to say if someone with Peters grasp on the fundamentals has done a review of L2's, and can't conclude whether something is definitively an L2, then it's not an L2."

also, proud stacker news user

"I onboarded 12 people to self custody." "Great job!" "Thanks, cost me 3 years of my life."

want to orange pill someone? demand payment for something they want, in Bitcoin.

bad for business? oh well, quit being annoying and live your life.

this isn't snark. darknets orange pulled LOTS of pharmaceutical opioid addicts.

give things time, don't be annoying. best in class products eventually grow to fill their niche, Bitcoin is no exception.

I completely agree.