But wait you said member. Why not any user?

Yeah. An interesting detail, crossed my mind too! Unless they switched to El Gamal but I very much doubt it.

Yeah not working atm sorry

An ignored part of the current quantum computer fud^H^H debate, because it's a counterfactual: back in 2015-17 a lot of people got very excited about a proposal from Greg Maxwell to do "confidential transactions" on bitcoin. I was very much in the group of people both fascinated and excited about the prospect and went very deep down the rabbit hole on it, learning a lot about cryptography along the way. But the energy to even suggest a fork to include it slowly dissipated; my own personal reason for rejecting it was *not* the obvious "the range proofs are too large" (see: Bulletproofs, work that was heavily inspired by that scaling problem, though it ended up being far more significant w.r.t. "folding"). It was "pedersen commitments are only computationally binding" [1], to put it another way an EC break means we get unbounded, invisible inflation. At the time it was fun to predict that Zcash had this failure mode and indeed it was borne out (look up their history if you don't know). It felt weird justifying this to people sometimes: "I don't want a bitcoin where amounts are not visible because the total might not add up" sounds Luddite ... I remember being asked on a panel by Giulia Fanti "are you scared that P=NP or something?" ... it was not felt to be a quite logical thing to worry about this, since we rely on EC in Bitcoin anyway ... and if we trust EC, the math of homomorphic commitments *guarantees* it adds up! But a computational bound on that is not OK. i.e. i don't want *any* computer to be able to break it! not just normal computers! - and that's exactly where a quantum computer comes in. I am FAR more worried about breaking bitcoin's fixed supply than about a million old P2PK coins getting stolen. Stealing is not minting. [1] A counterpoint is that ElGamal commitments exist, at the cost of even more space. But hey, it's still less space, by a huge margin, than current post quantum signature schemes! Something worth considering? #cryptography #bitcoin

Pretty sure it's deliberate. Despite quite a few people (especially users!) complaining about it.

Linux desktop stuff is such a mystery to me. This honestly seems batshit insane, but in GTK3, it appears that if you use a FilePicker, something like (Rust here but w/e): rfd::FileDialog::new().set_directory(&my_specific_dir).pick_folder() ... it refuses to open the file picker in your specified directory. It just flat out ignores you, and *always* opens the dialog in its "Recent Items". So not complaining about a default (though it's a terrible one honestly), but the baffling decision to just ignore the developer's setting. I would love to find any justification of this anywhere, but I can't. This "documentation" ( https://docs.gtk.org/gtk3/method.FileChooser.set_current_folder.html ) just points at a non-existent other documentation section to justify why you shouldn't use the function (Not "deprecated" but "warning, you'd better not use this function, but we won't tell you why!"). The code itself basically defaults to recent items, and that can *only* be overwritten with a GTK setting, outside of the developer's control, and here's the best bit: if you somehow get your user to override it, they can *only* change the location the FilePicker opens in, to $HOME! Your directory setting will still get ignored! Btw this restriction did not exist in the previous GTK version; they actively added it as an improvement. #linux

That's exactly what Lightning excels at.

To generate, no. To restore, technically maybe no, in that *if* your wallet allows a direct connection to your own bitcoin node running on the same computer, it can perform the restoration function by just talking to that running node. However this won't be a full restoration as if there is no live internet connection, your node will not have the most recent blocks. So realistically, restoring needs an internet connection. Generating a wallet 100% does not, which is important for high security setups. Also check the concept of a "watch-only wallet" for an interesting and useful finesse. Of course a lot of convenient lower security wallets will not be careful about these details. If you are not using your own node, certain tradeoffs are inevitable.

Afaik for QR ZKP tech you have STARKs and that's about it. Because they're hash based (which ofc doesn't quite mean 'impervious to quantum algos' but more or less does mean that in practice, as currently understood). As for the actual proposal here re:bip32 and proofs, it feels a bit wrong to me but I'd have to think it through.

You're 100% right but there's a crucial to understand change in what banks are today vs 150 years ago: they are no longer businesses serving their customers, they are agents of state power (their actual customer is the state). It changes everything.

Schrodinger's quantum threat.

The last good thought Taleb had before he lost the plot 😁 (Antifragility does get horrendously misused though)

Right. I think we're correctly identifying that the issue is: the syntax/semantics distinction as I like to describe it, or the rules/censorship distinction have the problem of a somewhat blurred dividing line. In my human laws example, the "hate speech" law in the UK is now protocol or "consensus" as per bitcoin's lingo, but that doesn't make it OK. Because it's a law about something like "what you are thinking" it's not actually viable; it has already created monstrous outcomes. So it's not that I'm saying you're wrong that "if it's in the protocol/consensus rules then it's not censorship by narrow definition", but I also wouldn't blame people for saying "come on, just use common sense! that's censorship!". It's probably not a very valuable discussion, except maybe to say "there are two different ways censorship could happen; but having censorship *in* the protocol rules is even far worse than the other (normal) type!".

So to rewind: what you were pointing out at the beginning is that the only things that are "banned" properly, are banned by rules, which is the protocol: the protocol is the rules. When people talk about bitcoin being "censorship resistant" they're talking exactly about how hard it is to have *other* rules (call it "soft banning" if you will), ones that are *not* in the code. OFAC e.g.; we're hoping that the way mining works prevents an OFAC rule becoming de facto (though not "de jure" in code). My "semantics vs syntax" distinction may not be the only way of framing that, but it's the one that I find most resonant, we see it very clearly across modern human society. When it comes to human language/society laws, a good example is "hate speech" laws of the type seen in the UK: it's a law about semantics, not about syntax, in my framing (and it's to my mind the rubicon which a government can never cross). In a Bitcoin context one can similarly *attempt* to create syntax rules that control semantics, but they will always be ineffective ("pissing in the wind"), and most likely also very deleterious. As I've always said, trying to ban spam is imo *both* ethically *and* technically bankrupt. It's not going to work. Instead, try to make bitcoin the best money it can be.

Yeah, I think I saw that text on another page, but definitely good find; because that text is the most explicit about their baffling decision: "no longer considered a good choice" for opening files, only for "Save As". Crazy.

Yes. Syntax means only certain patterns are allowed. But the protocol (English) makes no judgement about the purpose, or meaning, of valid combinations of words (the semantics). This distinction represents the correct analogy here. Bitcoin's protocol gives a syntax for financial state transitions, but doesn't judge whether they are acceptable state transitions. The problem is that semantics are not absolute like syntax is, and it's a fool's errand trying to control semantics. If you ban "fuck" another word will be "co opted" to somehow be equally offensive. Protocol rules control syntax, not semantics.