waxwing

Bitcoin, cryptography, Joinmarket etc.

Public Key

npub1vadcfln4ugt2h9ruwsuwu5vu5am4xaka7pw6m7axy79aqyhp6u5q9knuu7

NIP-57 Address

redsun63681@getalby.com

Profile Code

nprofile1qqsxwkuyle67y94tj378gw8w2xw2wa6nwmwlqhddlwnz0z7sztsaw2qpp4mhxue69uhkummn9ekx7mqpz3mhxue69uhhyetvv9ujuerpd46hxtnfdur3q0an

Publishing to

nos.lol

relay.damus.io

wino@nostr.wine

Author Public Key

npub1vadcfln4ugt2h9ruwsuwu5vu5am4xaka7pw6m7axy79aqyhp6u5q9knuu7

Show more details

Last Notes

2025-11-08 01:34:39

- reply

It doesn't prevent data embedding. Consider nonce=private key. 32/96 bytes of data. Why 2.5x and not 3x?

2025-11-05 12:02:33

- reply

Hence bitcoin treasury companies I guess, for those who still can't bring themselves to go to the crypto casino 😆

2025-11-05 11:25:11

- reply

Is it though? Apart from the crazy delusion that information known to the whole market (halving dates) is somehow not priced in, the more interesting pattern that shows up here is how volatility is reducing over time as the asset gains inertia ($1B to $1T tends to do that!).

2025-11-04 18:51:44

- reply

I think it was your utxo dump tool that I was using before, I'm just wondering mainly if I can reduce the amount of data I have to dump to disk.. well, nbd, don't let it distract you :)

2025-11-04 12:45:21

- reply

I think there were some half decent thoughts in there, though not sure. But that specific post was so badly wrong on the arithmetic.

2025-11-04 12:37:07

- reply

His "5/ The math" is complete nonsense (seriously, read the numbers!). I think assuming this is is LLM output is the charitable thing to do :)

2025-11-03 16:50:34

Working in VSCode and having the AI auto-complete whole sentences at a time when I'm trying to write code comments completely throws me off. The thing is I'm always scared to turn off AI features because they're useful, but some of them are getting so intrusive.

2025-11-02 17:06:46

- reply

The difference might be small most of the time and yet still might be extremely important. If there is a sudden arrival of 100 transactions with big fees and big size in vbytes they might blow out estimates, and you don't see it if you are blocksonly. It still might be true that "the difference is on average very small" if this only happens very occasionally, but it stands to reason that without this information you are at a disadvantage in trying to judge what fee to use for fast confirmation.

2025-11-02 12:06:24

- reply

Why would it be ridiculous? That's a very strong term!
Is your argument that the information from confirmed blocks is already enough? Even if you think that, "barely affected" seems vague, and "a few dozen spam txs" seems weirdly specific?

2025-10-30 20:54:58

- reply

Not sure about zero but I have the same opinion. I personally would run a mile from such a "bitcoin".

2025-10-30 16:19:41

Had a quick read to get the main idea.
So basically: the main DKGs that are the foundations of things like FROST are protocols where, instead of having a single trusted "dealer" that gives the shares the secret to participants (e.g., basic Shamir Secret sharing has to reconstruct the whole secret in one place), you instead have every member be a "dealer" of shares of their *own* secret, and then the total secret is a kind of "homomorphic sum" and is never seen by any party; e.g. in FROST you can sign without anybody ever seeing the full private key.
This "decentralized" version of DKG was already a thing in the designs of Feldman and Pedersen, from decades ago. A lot of recent work has focused on the practical issue of how to deal with disruptions to such protocols. (Disruptions can be even worse than you might think, because someone can bias the output by re-aborting several times until the key has a property that they want). To avoid such disruptions multiple rounds are often used, as well as proofs of possession/knowledge etc.
Golden seems to handle this in a particularly clever way, where in a way similar to MuSig-DN, it creates ZKPs (in this case bulletproofs) of the correct formation of encrypted shares, then allows everyone (not just the one recipient) to see that the those encrypted shares are valid. Then the invidual participant you're handing the share to, can decrypt it, to get their overall share (which is the sum of all the shares they receive from everyone else; it's a kind of all-play-all quadratic scaling thing, if you've never looked into these things before).
There's a ton more to it than that, this was just me cherry picking certain sections to get the gist. #nevent1q…dagd

2025-10-29 13:09:26

Thought I'd post this for those unaware:
https://directories.w3ird.tech/
... there's a list of active Joinmarket directory nodes here.
(Background: directory nodes could be thought of like bitcoin's dns seeds, *very* vaguely: you (as a taker) want to *directly* connect to makers over their tor onion endpoints to do the coinjoin, but you need to see at least their initial static offers and then grab their onion addresses, so the directory nodes act as initial rendezvous for that, and keep lists of accessible makers vaguely up to date. Unfortunately the similarity with a proper p2p network like bitcoin is extremely partial, and trying to instantiate such a thing is game theoretically not viable, since no maker is incented to tell you about other makers)
When it works it works very well.

2025-10-29 11:30:26

https://eprint.iacr.org/2025/1924
New paper from Komlo and Bunz, 1 round DKG, dl assumptions only. Seems like a must read. #cryptography

2025-10-29 03:36:38

- reply

Sorry can't fix it rn.

2025-10-29 03:23:18

- reply

Perfect for people who have vertigo *and* claustrophobia!

2025-10-28 16:39:25

- reply

The paragraph "Softforks don't chain split.." might seem like it's disagreeing with what I'm saying, but it's not. It's expressing the same mechanics with a different emphasis. I don't disagree with that.
His "bcash is an altcoin with an airdrop" - that was his line iirc at the time, and I always thought that was unhelpful (and also rather typical of his dismissal of the reality of any conflict with his position). The point is that bcash *becomes* an altcoin or an airdrop after it becomes clear that it has fully failed to gain general economic consensus as "the" bitcoin. It isn't that *by definition*, before the market has decided.
His last paragraph is wrong and BIP444 is a disastrously bad idea imo. I strongly suspect it will not get anywhere. (Note that this does *not* mean I believe an attempt to soft fork a simple restriction on OP_RETURN would be a guaranteed fail, but BIP444 is not that).

2025-10-28 16:31:58

- reply

That reads like LLM output. Whether it is or not hardly matters. It's correct, at the very least it's roughly correct.

2025-10-28 13:47:59

- reply

Multiple utxos, but only taproot. Also it is restricted to one utxo per address.. that could be changed iirc.

2025-10-28 13:46:52

- reply

Yes not resolvable rn sorry

2025-10-28 13:46:01

With the drama of BIP444 I've seen a lot of people confused about the nature of soft-fork vs hard-fork. This might help:
Back in the block size war we had a lot of similar confusion, mostly because it isn't really very clear cut. Some people talked about "evil soft forks" to try to get rid of the simplistic notion: "soft forks are much better and hard forks are much worse" which tends to persist (naturally). The problem is that whether a fork is contentious or not is *much more important* than whether it fits the "soft" or "hard" technical definition.
When a fork isn't contentious, then the soft vs hard distinction (restricting the ruleset or relaxing it) really matters a lot, because "passive" network participants (imagine a piece of hardware that will never get updated to a new bitcoin version, in the extreme) will be fine with the first and not with the second.
When a fork *is* contentious, and miners, following economic incentive, end up choosing different rulesets to support different bitcoin users, then the chain genuinely forks into two histories. The fact that one ruleset is more restrictive than the other is part of the story but doesn't change the fundamental point that we have a chain split. This of course did actually happen meaningfully with bitcoin-cash in 2017. The term "evil soft fork" was some people trying to shake others of the misconception that if a fork is "soft" it's not coercive and not forcing action on anyone; that's definitely not true *if the fork is contentious*.
#bitcoin

2025-10-28 12:32:49

- reply

That's zk wrt your private key, but not wrt your utxos. (See my other answer)

2025-10-28 12:31:46

- reply

I made software that does it https://github.com/AdamISZ/aut-ct (see the auditor-docs subdirectory).

2025-10-27 20:01:01

- reply

Sure, but ... it doesn't *all* come down to how you use it. The intrinsic properties of a thing matter too.

2025-10-27 18:22:58

Or you could actually prove it without a third party, cryptographically, using a ZKP...
#nevent1q…hux4

2025-10-27 11:12:22

I don't agree with every word, but this general perspective is badly underrepresented.
#nevent1q…a9e4

2025-10-19 15:21:36

- reply

Ah yes, perfect, that's exactly it. I remember btw thinking that that exact mechanism is going to be needed in LN gossip too. And basically every anon network.
Btw do you have any knowledge about the deployment of this feature. There seems to be some confusion about licensing and compiling it; is it definitely available in 0.4.8; will it be switched on by default at some point?

2025-10-17 19:46:43

Anyone running recent Tor builds with HiddenServicePoWDefensesEnabled set to true?
What I'm mostly confused about is if onions have it switched on but their clients are on older versions or just incompatible versions, how does that work?
#tor

2025-10-16 11:46:55

- reply

To be fair it's a pretty strong trend here too.

2025-10-15 15:25:49

- reply

In most of Europe make that more like 2-3K.

2025-10-15 09:50:02

- reply

Oh, interesting. How?

2025-10-14 19:53:58

- reply

It may well be a clear cut crime, but bear in mind you are taking their word for it. They have straight up lied in many similar cases.

2025-10-14 19:43:13

- reply

The whole "forced labor" angle in this story feels really suspicious and weird.

2025-10-14 15:04:32

- reply

Nothing. But as a signalling mechanism, it's trivial to Sybil.

2025-10-14 14:59:19

A long time favorite of mine, "ULT!IMATE END" by Blacky, who do kind of "classical speedcore" that works really well. I love the section around 1min in, where the strings start. A full 4.5 minutes at 13 notes per second is quite the stamina drain...
https://replay.beatleader.com/?scoreId=27113928
#beatsaber

2025-10-14 12:16:00

- reply

This is false. Bitcoin didn't have an 80 byte op_return limit before; there was no change to the rules.

2025-10-13 12:11:18

- reply

I'd be against it but not very strongly, if it was specifically OP_RETURN. But yeah it's a slippery slope to banning endlessly.
But I'd much rather be having *that* argument than the delusion we see today.

2025-10-13 11:15:46

- reply

It's possible you're a bit confused about the relationship of op_return and segwit? There's an op_return *in the coinbase transaction* for committing to the witnesses in the block; that's separate from general 'segwit outputs'. OP_RETURN is just another kind of output. The op_return in the coinbase is just a commitment of bytes, there'd be no need, in a soft fork to ban op_returns, to remove it (true that it would present a technical question to address: if we banned op_return there'd either need to be an exception for coinbase transactions, or a kind of renaming of that 32 byte commitment so it's no longer called op_return. IIUC the only reason the slightly clunky choice of op_return for that commitment was made, is because you can't add to the block header itself, without a hard fork).

2025-10-12 11:11:30

- reply

That's a good point about futures and exchanges. We need a mechanism to bet on the fork outcome inside bitcoin transactions. I think there was some research into that years ago. Hopefully the mechanism doesn't use OP_RETURN 😁

2025-10-10 15:29:34

- reply

It's an algorithm for agreement under conditions of extremely weak "coupling" (using the term how physicists use it).

2025-10-09 21:19:28

- reply

Considering the delta to an old-style SPV client: there, you only care about your own coins, so (modulo the privacy issues, bip37 etc) you can just request proofs for the few things you care about.
But to take part in p2p block propagation (and indeed to know quickly whether to accept new blocks) wouldn't it cause big problems to sort of scoop up the necessary proof "after the event" so to speak.
Just speaking in generalities here, I'm no expert. Might be worth digging up the old discussions on spv clients from the 2012-2015 era.

2025-10-07 01:30:52

- reply

I mean it's *an* argument. But, consider the 'transaction on a sanctions list' case. Same thing; what makes bitcoin special is how outrageously difficult, arguably impossible, it is to fully censor something.
We would like that only financial data gain that privilege, but by the nature of information, the distinction of what a string of bytes means is near impossible to make.
One reason on the mailing list I've been raising the question of how much data can theoretically be embedded just in schnorr signatures/scriptpubkeys alone.

2025-10-06 18:48:55

- reply

Thanks for the article.
I don't see why 95% of nodes running knots will make any difference; people who want to put things in blocks can still do so trivially. I mean you kind of explained as much, earlier.
Campaigning for a consensus change would be the coherent position to take imo.

2025-10-05 01:57:45

- reply

We specifically don't trust cryptographic hardness assumptions (ECDLP, preimage resistance) to audit supply.

2025-10-04 12:27:05

- reply

I see all these systems with a client server relationship as at least quasi-centralized. Including nostr, though that's much lower on the sliding scale of "how problematically centralized is this".

2025-10-04 12:23:49

Glock is simple really. It only uses: Binary elliptic curves, Garbled circuits, Oblivious transfer, verifiable secret sharing, adaptor signatures, lamport signatures, SNARKs, and cut-and-choose. Oh and Bitcoin too, it uses that somewhere.
#cryptography

2025-10-04 10:40:51

- reply

Oh but this is not a counter to my point imo. The basic architecture of a hub and spoke interaction with a central server is what I mean.
Otoh if development requires interoperability w/ Lightning clearly that bumps the difficulty.

2025-10-04 10:38:33

- reply

I'd agree at least partly about Ark. From what I remember anyway. Not knowledgeable enough about BitVM current ideas, but obviously not having centralized control of the money being exchanged is going to affect architecture etc.
Lots of gray areas right, like Eth L2s being centralized when you look under the hood.

2025-10-04 09:52:09

- reply

Centralization makes things an order of magnitude easier.

2025-10-04 02:26:38

- reply

Libbitcoin
btcd
Many others over the years but very hard thing to do with decent quality/security for reasons specific to the nature of Bitcoin.

2025-10-03 19:41:24

- reply

Sure. That has always been "the" concern, in the success scenario. That's why we have to pay attention to L2+

2025-10-03 18:02:44

- reply

I don't relly get why it's a larp to run your own nodes with the advantages involved, privacy, security, self sovereignty etc. And if you use it as money then you have a bearing on bitcoin to the extent any person or group should have any bearing.

2025-10-02 12:15:18

"It is often thought that communications may be secured by encrypting the traffic, but this has rarely been adequate in practice. Æneas the Tactician, and other classical writers, concentrated on methods for hiding messages rather than for enciphering them [1]; although modern cryptographic techniques started to develop during the Renaissance, we find in 1641 that Wilkins still preferred hiding over ciphering [2, ch. IX, p. 67] because it arouses less suspicion." - the first paragraph of "Information Hiding - A Survey" by Anderson Kuhn and Petticolas.
(My gut reaction was thank you! Finally someone fucking gets it! ... as I put it in "tlstweet", encryption is powerful but it is the tool of the already powerful, the "resistance" has to use steganography, no matter its weaknesses).
#cryptography

2025-09-26 10:04:29

- reply

2025-09-23 13:35:20

- reply

Yes, very true, but your standard here is "don't use fiat money". It's a good standard! But it's one that literally no country meets.
I do agree it's reasonable to criticize Milei for not taking non-fiat money more seriously, but he actually put the government in surplus and did *not* print money to finance govt activities, despite what people apparently believe (choosing to believe western media is just incredibly stupid here, but apparently if it suits your bias, it's fine!)

2025-09-23 13:07:22

- reply

512 bit wouldn't help against quantum; the problem is Shor's algo is not exponential in that parameter, it's polynomial so it basically doesn't help.
Meanwhile we're at about 128 bit security (think birthday) w/ 256 bit curves, at least as far as anyone knows, shifting to 512->256 bit security is obviously "better" but otoh nobody seriously considers anything above 90 bits is attackable (and remember that scale is exponential!)

2025-09-23 11:07:23

Unsurprisingly people are really clueless about Argentina and so if they decided Milei is bad they don't really have to check more than the headline, they already "know" the reasons behind the story ...
#nevent1q…jqjt

2025-09-23 11:00:58

- reply

The reason is that the Peronistas won the provincial elections, convincingly. Markets are not taking it well (currency, stocks etc.). Meanwhile Milei's team took the (imo) ill considered decision to create a slowly expanding "band" (think soft peg) around the ARSUSD exchange rate. And the ceiling of the band was hit in the above market panic. They started selling reserve USD to defend that ceiling.

2025-09-22 17:59:12

- reply

Is that good or bad? 😅 ... i see a bewilderingly long list of options; I see 4 search relays active, I think, and 1 inbox DM relay ... and there's a long list of relays right at the bottom, but I'm not sure what that signifies.

2025-09-22 16:28:57

- reply

No argument here. I'm still suspicious of the pure PoW solutions, and also of the ecash solutions, too.

2025-09-22 15:55:50

- reply

"We" have, yes (maybe you're specifically referring to bitcoin but it works either way), but a large plurality of people are convinced that WoT and similar community based scoring systems are the right answer.
The evidence doesn't support that thesis imo, specifically for anon systems as we're discussing here.

2025-09-22 15:52:07

- reply

I never saw anything completely satisfactory, but, payment rates massively convex wrt rate of requests seems like the only completely correct answer. Think surge pricing. That's one a few reasons I narrowed in on utxo ownership tokens, as there is some hard to define rate at which they become absurdly expensive to produce, whereas at low rates they are very close to free.

2025-09-22 15:29:23

Is anyone else having a lot of trouble getting things to load on Amethyst after the recent update?

2025-09-22 14:23:05

- reply

It's hardly new. States all over the globe have been doing this at scale for a long time ... though the book was prescient there, as it was a pretty niche thing in the 90s.

2025-09-21 17:45:24

- reply

I guess you can read his comments like that, true. I also think he just genuinely finds the question of how to address the potential threat intellectually interesting. Maybe a bit of all three.

2025-09-20 17:41:06

- reply

It's one of those tricky arguments to which people will apply this concept of "the precautionary principle". For my money that principle is wrong; every choice has both benefits *and* costs, so you can't argue that we should always do something to prevent a small probability threat, "just in case". It depends.

2025-09-18 12:50:03

Re: https://delvingbitcoin.org/t/provable-cryptography-for-bitcoin-an-introduction-workbook/1974 that was recently advertised
As I spent some time this summer working through this material (with a bunch of other people), I can heartily recommend it, but, it's not for the faint of heart! I think it would be much more useful to explain why the title is what it is - "*provable* cryptography". Without getting technical, let me give you some background that might inspire you to get involved:
The concept of "provable security" sounds a bit bland; of course you want to prove things are secure, rather than just hope it! But in the history of cryptography, it .. wasn't always like that. Pre- asymmetric encryption (think from Caesar cipher to Enigma machines, so until 1960ish), cryptography and cryptanalysis were in a constant battle - one side came up with clever ciphers, the other side found clever ways of breaking them. Like an arms race (except ciphers are not weapons! they're armor .. so, an armor race). As far as I know, nobody tried to *prove* the Enigma machine's complex cipher was secure at the time. But in the 70s and 80s, after Diffie and Hellman's groundbreaking work introduced practical cryptography without having to share a secret key (the DH protocols, and RSA around the same time), things started to change for a definite reason: these protocols were based on a deep "fact" (usually not a proven fact, but a belief) about number theory. The classic one is factoring: the "fact" that factoring a very large number takes an exponentially long time. Rapidly, many other similar "very hard problems" were found, the one most familiar to readers will be the "elliptic curve discrete log problem" (find the private key, given only the public key). Cryptosystems were being built with these "hard problems" as foundation.
And people started using the concept of "reduction", which is slippery logically but very powerful: I build cryptosystem A. If you can break A (notice: I'm not saying how, I'm just saying if you can break it *in any way*) with some magical machine, you can take that same magical machine and ... find a private key given only a public key. If you think about it, it makes sense to describe that as "reducing the security of A to the elliptic curve discrete log problem". The reason this gained traction through the 80s and 90s is because it circumvents the cryptographer-cryptanalyst war we mentioned at the start (at least, in theory it does!). The cryptographer doesn't have to consider all the different ways the cryptanalyst might break his system. He only has to believe that the math problem (e.g. factoring) is indeed hard, because if it is, and because he has a reduction, he knows that any such clever cryptanalyst is breaking the factoring problem, too.
I'll admit I balked a bit at this "backwards" logic when I first encountered it. I thought "hmm well maybe the clever cryptanalyst is going to use his technique against my cryptosystem A, and *actually* break ECDLP by doing it!". (I remember Greg Maxwell's response when I expressed this was "good luck" 🙂 ). But I hope you can see that this is generally missing the point, since the reduction isn't saying anything at all about ECDLP or factoring or whatever. It's just making a bridge from your specific thing, to the general "hardness" of the "big" problem like factoring. A bit like how money is useful because we don't need an unreasonable number of barter prices; everything is compared, numerically, with one central thing. Similarly there is a zoo of crypto protocols that use ECDLP as their "foundation", their security can be (even numerically) related to the security of that underlying thing.
As usual I'm now waffling a bit, but the main point I'm trying to get across is: "provable security" is based on these reductions, and in the "modern era" of cryptography, it's the main way you have any chance of navigating the huge complexity of answering the question "is this cryptosystem secure"? If you can reduce it to a known problem, you are done. Of course such reductions are sometimes wrong, and sometimes fail to model certain details that occur in real implementations, so they're not a panacea, but they are the best we have.
#cryptography

2025-09-17 13:07:35

Over 100 replies.
That's not common here!
#nevent1q…p0ng

2025-09-17 13:05:38

- reply

Wow. That 2nd message.
He seems to be saying that it's not a problem if it ends up in a block, but is a problem if it's gossiped. But ... blocks get gossiped ..?

2025-09-16 16:15:27

- reply

What's the audio like?

2025-09-16 12:37:44

- reply

> “if X percentage of filtering nodes are unable to 100% reliably stop spam, then they don’t work” is just a fallacious claim. The obvious contradiction is that if 99.9% nodes aggressively filter spam, and filtered txs still end up in blocks (they can), then filters also can’t be used for censorship (the whole argument falls apart)
So we agree: censoring doesn't work if it's not at the level of consensus: if it did, bitcoin would fail. but further, what kind of restrictions can and should exist at the consensus level is very controversial. even limiting the *rate* of transactions per block was controversial enough to create a full blown war in Bitcoin, for years. The only argument that falls apart is the one saying there's any point in doing mempool filtering; while there are very clear and concrete negative outcomes (though I wouldn't overplay them) from filtering, too.
> And no, filters work not because they reliably prevent spam from getting into blocks, but because they force behaviour that makes spam economically and rationally self-defeating (to a large extent)
I don't agree. Your argument seems to be that they make spam much more expensive, but I see absolutely no reason to think that, specifically because, as we already agreed, they don't work - the same transactions you are filtering end up in blocks, relayed directly to miners, often.

2025-09-16 11:28:02

- reply

What exactly do you think has been debunked? Do you think that if 90% of nodes on the p2p network apply filters, that the filters will prevent those transactions from getting into blocks? 99%?

2025-09-15 22:05:20

- reply

They can't work. If the rules need to change, they have to do so at consensus level, i.e. a soft fork.

2025-09-15 20:12:37

- reply

The point is, whose decision is it what the transaction's meaning is? The only correct answer is nobody at all.

2025-09-15 16:22:30

- reply

Interesting thought for sure. Obviously *any* out of band could work (with clearly some tradeoff), nostr fits particularly nicely. I'll read it more.

2025-09-15 14:36:23

- reply

For example: for receiver B, and multiple payers A_i, we want this: payments P_i are not linkable to B, except payment P_i is linkable to B by payer A_i (of course!). Thinking in this way allows you to realize for example that the effectiveness of SilentPayments may crucially depend on B's spending policies. (in the ideal case: B only receives coins via this protocol and only co-spends utxos that were created with it; you can satisfy yourself that in this case the non-cospent utxos should not be linkable. Or maybe you can't. But that's the kind of thing I think is worth investigating. A bit beyond a BIP of course, maybe, likely, someone has already done it.)

2025-09-15 14:26:42

- reply

You're missing a lot in that characterization, but the main reason such an analogy might be made, even if it's ultimately an unfair one, is the pro-filter arguments don't make sense "mechanically" (they don't achieve the intended goal *and* they harm the network) and are actually anathema to the entire purpose of bitcoin, which is censorship resistance.

2025-09-15 14:21:57

Been spending some time looking at the design of Silent Payments, just from a crypto point of view. Overall I like it; the only wiggle room for attack I can find so far is if the spending key is somehow a key that itself previously existed and was used for something, which it never would be. I see basically no attacks that make sense, so far. If I have a complaint about the BIP, it's that it isn't as clear as it should be about what privacy guarantees it's claiming (though the common sense reading seems to be right; it should be explicit though). Obviously the way out there stuff, like inputs that are from MuSig2/FROST, or coinjoins, which are pointed at in the BIP, are very much uncharted territory and would be hard to get right, but for now I think that is just not going to happen. Anyway I'll keep looking.
#cryptography #bitcoin

2025-09-15 14:20:55

- reply

My response to them is the same as that of Austan Goolsbee, Obama's chair of council of economic advisors, when asked about Bitcoin:
ROFLMAO

2025-09-15 11:59:21

- reply

There is no central server but there is a trusted root "community owner" for the PKI.

2025-09-14 18:04:17

- reply

Been a while but that first part of the game was definitely the best for me.

2025-09-13 15:26:58

The .mediawiki format is an interesting one for the bitcoin/bips repo. With markdown, you can preview your documents pretty much anywhere. But when I was recently editing a BIP to make a PR, I found it was an ... interesting ... process trying to preview my version of the doc. Short of literally setting up a local wiki with database and everything, it wasn't easy to figure out how to preview what the edits look like (and the syntax of mediawiki is significantly different to the by now very well known markdown (.md files)). Best I could find was the result from "mediawiki sandbox" search, like: https://meta.wikimedia.org/w/index.php?title=Meta:Sandbox&action=edit .

2025-09-12 19:08:10

- reply

😆 ... Or, you create a timelocked transaction to pass money to your heirs. Developer who included the nlocktime field in the GUI ... straight to jail.

2025-09-12 18:52:49

- reply

I would say that's the least important of the arguments he's making here. People should read this, but, they've already had all this explained to them and they don't care, shrug.

2025-09-12 18:49:06

- reply

My favorite one is the last one. Waiting to have a cup of tea before sending your payment? Straight to jail.

2025-09-12 12:27:07

- reply

Not sure about the nostr analogy, because about Visa/Mastercard: it's a bit like Tether, in a way. What Tether does, technically, is very trivial. The absurd profit comes from negotiating through the legal and regulatory minefield, and becoming "the incumbent".
With bitcoin/nostr and similar I don't see how something similar can happen. The whole Saylor thing is along those lines, but it's epiphenomenon, not phenomenon.

2025-09-10 16:11:26

- reply

Right, there's no total solution in jumping jurisdictions. It can't work for more than a small minority. I'm more just saying that in some scenarios, you can't expect much in terms of adoption at the level of everyday life. Progress tends to occur at the edges.

2025-09-10 13:31:41

- reply

I've lived in El Salvador for 3 years, mostly on bitcoin. It's not just a dream. To me the actual unrealistic thing is to try to push bitcoin adoption in jurisdictions where there is very little motivation. You have to "read the room", so to speak.

2025-09-10 11:49:05

- reply

You'd be surprised how practically possible it is to live without bank accounts in certain parts of Latin America (and not only), if you're pragmatic about it. Bitrefill, debit cards you can charge, tons of exchange places that accept both bitcoin and (much much more) usdt, and most important of all: countries where cash transactions remain the norm. A huge reason it seems so bad in much of Europe is because cash is slowly being softbanned.

2025-09-08 21:01:22

- reply

Kinda funny that he's advising against anything but hardware wallets, when it's exactly things like Ledger that have been using an egregiously insecure architecture of electron apps in javascript. (Ok, metamask style web apps are worse, but Ledger allows you to plug into that...)

2025-09-08 18:18:11

The story of integrating Schnorr into Bitcoin and its related applications has been very much this: wow this new (old) signing algorithm is super clean and powerful. We can now do X and Y and Z. But then after some delving into details it becomes "yeah we can do X and Y and Z, but attackers can also do X' and Y' and Z' so, shit, we'd better add a bunch more details to the algorithms for X, Y, Z". and those details have been hard. Crudely, Schnorr being "linear" means you can munge them around in clever ways that are efficient and private, but you need to sort of "restrict" how the linearity is used to make it work the way you want, and not some arbitrary other way that leads to security breaks. Here's a good example of what I mean:
I was recently revisiting the idea of an adaptor-based atomic swap. That is, a coin swap which is secure because if one side spends, the other side can also spend, by extracting a secret from the corresponding Schnorr signature. See https://github.com/BlockstreamResearch/scriptless-scripts/blob/a8b6ff21fc7f4529eabbe639fbff49f047a3579d/md/atomic-swap.md . I realized that there's a certain way to do it, that seems very natural, but is actually broken (if not trivially in practice .. but still, broken, in that money *could* be stolen, depending on the setup). I wrote about that attack yesterday here: https://gist.github.com/AdamISZ/489a08a0367137ed131efb90439bc9f5 . But, it's quite obvious (if you're familiar with Wagner's attack!), so not surprisingly this has already been considered and a more secure variant of "adaptor signature for a MuSig2 protocol execution" is in a years-old PR by Jonas Nick here: https://github.com/BlockstreamResearch/scriptless-scripts/pull/24 . It's not merged because it's not thoroughly reviewed and worked out, though I'm not sure if anyone's working on it. Bottom line, using the power of Schnorr and actually convincing yourself that it's being done safely, is not a simple matter. (Consider for example that PTLC Lightning intends to use something like this, so it's not exactly a completely uninteresting side topic).
#cryptography

2025-09-08 14:59:31

- reply

Ok found it nvm.

2025-09-08 14:56:30

- reply

Where (if anywhere) can I get a link to zkpoor?

2025-09-07 10:57:18

Latest ZK podcast episode has Huijia Lin giving a really good introduction to what the heck is "indistinguishability obfuscation":
https://zeroknowledge.fm/podcast/375/
#cryptography

2025-09-06 09:33:09

- reply

How does tx relay over nostr help with censorship resistance? Genuine Q, I'm curious.

2025-09-06 09:23:04

- reply

How reliable is Orbot nowadays?

2025-09-05 15:18:51

- reply

Ok that makes sense, but to be clear, you are saying it doesn't include stablecoins, right?

2025-09-05 14:55:46

- reply

Is stablecoins treated as a separate category?
Was never really sure of the definition of "defi".

2025-09-04 18:32:47

- reply

I guess we need a culture that makes anon accounts desirable. On the other hand, we don't even have any emphasis on network level anonymization here, so your point stands...

2025-09-03 19:54:25

- reply

There has to be a really strong motivation not to be in a client-server relationship. Bitcoin and bittorrent both have/had that.

2025-09-03 18:59:51

- reply

Yeah, at least, use something that isn't my normal email 😆