waxwing

Bitcoin, cryptography, Joinmarket etc.

Public Key

npub1vadcfln4ugt2h9ruwsuwu5vu5am4xaka7pw6m7axy79aqyhp6u5q9knuu7

Profile Code

nprofile1qqsxwkuyle67y94tj378gw8w2xw2wa6nwmwlqhddlwnz0z7sztsaw2qpz9mhxue69uhkummnw3ezuamfdejj7qgnwaehxw309ac82unsd3jhqct89ejhxtc47zr0h

Publishing to

nostr.wine

purplepag.es

relay.current.fyi

Author Public Key

npub1vadcfln4ugt2h9ruwsuwu5vu5am4xaka7pw6m7axy79aqyhp6u5q9knuu7

Show more details

Last Notes

2024-09-19 15:54:52

Interesting, long write up on OP_CAT, script, taproot and STARKs on the delving forum:
https://delvingbitcoin.org/t/the-path-to-general-computation-on-bitcoin-with-op-cat/1106

2024-09-11 18:59:22

- reply

I don't follow what you're saying.
There's one person claiming to be expert in (komodo OR fermat). There's another, providing the 2 lists of Qs and, for a very limited time, answers.
You can assume that the first person is indeed enough of an expert in one of the 2, that they can easily correctly answer all 1000.

2024-09-11 18:55:08

- reply

1. No.
2. I think we could be vague on this, but let's keep it concrete: there's only time to memorize 1 answer.
3. In the 'correct' answer to this puzzle, no.
Good questions.

2024-09-11 17:15:40

- reply

OK, it's a bit underspecified 😄
Say the opponent/challenger also gives a full list of answers to both sets of 1000 questions - but only for 2 or 3 minutes, after which you lose access.
Given that, what protocol could you devise that would convince him that you basically already knew all 1000 answers for 1 of the 2? But not revealing which?

2024-09-11 16:40:53

Ronald Cramer in 1997:
"Suppose one were to convince an opponent that one has expert knowledge about Komodo dragons or about the life and times of Pierre de Fermat, without revealing which. One could propose the following protocol..."
... what do you think the protocol is?
As a very minor clue, his proposal involves preparing 2 lists of 1000 questions on each topic.
Ideas?

2024-09-03 23:38:52

- reply

A perfect illustration of why i tried chatgpt for technical questions 3 times then deleted my account. 😄
I mean the company is evil anyway, and open source solutions will end up winning out, but i don't see much use for it in technical fields, at least for a while.

2024-08-31 16:53:58

- reply

"The rewards of this category of attack must be much higher than easier attacks for the significantly higher costs and risks to be justified." But obviously the rewards ARE massively higher; the potential reward from compromising the (especially firmware) supply chains of the top 3 or 4 hardware wallet manufacturers are massive, they must be at least comparable with the biggest exchange thefts we've had. Saying it's "limited to organized crime/govts", meh, maybe maybe not but is that OK then? NK have been on the case for over half a decade now, with many great successes.

2024-08-30 21:13:13

- reply

Yes. In 15 years though, a $10 utxo might be completely uneconomic, if it costs more than $10 in fees to ever spend it.
Bitcoin fees effectively depend on how many inputs there are**. Each utxo being spent is an input.
** outputs cost too; it's basically the total amounts of data, in bytes, that you're paying for.

2024-08-30 18:27:45

- reply

The reason why base layer bitcoin is such a small, constrained database system is because it, uniquely, requires *every* participant to know and verify *everything*, so you can't split up workload.

2024-08-30 18:25:49

- reply

Two aspects: The number of utxos the system can support is not infinite; to verify each of the 1000s of transactions in each block, you have to check all the inputs are not already spent, which means you need fast access to *all* the utxos that currently exist. At currently 1-200M utxos, this is already quite a task. The earth's population is more like 8 billion.
But the other argument/aspect is economic : if everyone owned utxos, it could means that funding them and spending them requires block space in huge competition... costs of txs would spike way beyond the reach of the average person.

2024-08-30 17:10:07

Here's the paper:
https://github.com/AdamISZ/aut-ct/blob/auditing/auditor-docs/privacy-preserving-proof-of-assets.pdf
First half is quite discursive with no mathematics ... it's important to give the context of why (at least according to me) this is an interesting alternative way to do proof of assets compared to other approaches.
Feel free to share anywhere you think people might be interested. I will add a bit more to the doc later, but the actual algo is there.
#nevent1q…5779

2024-08-28 20:48:31

- reply

It's my favourite of his maybe tied with permutation city. But not actually because of orphanogenesis. The story as a whole has such an incredible scope.

2024-08-27 16:14:04

I'm rather disturbed to see so many cryptography/security luminaries online complaining about how Telegram is not properly encrypted, Durov never had users privacy in mind etc. etc. as if this concept of clean, pure privacy is what matters, or what matters to users. It reminds me of a pattern I've seen commonly over the years: people think Bitcoin was about anonymous transactions when literally every aspect of its design was focused on censorship resistance and that's a different thing, even if yes they are connected.
The example I've used in the past is: suppose you're on the plane out of a totalitarian country where you were an activist against the regime (flying out of the UK for example), at *that* point you care that your transaction is in Bitcoin and not Tether on TRON, not because Bitcoin has privacy (it doesn't, at least in general - the regime could be watching the txs on chain in real time). And yes mining centralization etc. etc. , yes that is *the* threat against Bitcoin's success, not a lack of amount blinding.
Coming back to Telegram, its failing is centralization, not lack of privacy. People use(d) it in such large quantities because of a *lack of barriers to enter and use it to communicate* (including communicating with huge groups of like minded people), *without censorship* (so you could support Hamas or Russia or whatever is verboten locally). Most people who use it are not so stupid as to think it isn't public. And while some *are* stupid, falling for scams etc., so what? That's called real life. It's the same story with money. Not bitcoin on its own but "crypto" (yuck, sorry) generally has won over so many despite its technical jank, because there are no barriers to entry. Sniffy US "cryptographic elites" like Green, Marlinspike and Zooko telling us all how inferior Telegram is are, as so often in this field, missing the forest for the trees. Their reluctance to protest Durov's arrest is honestly disgraceful.
(Btw Signal is kinda very good at secure messaging, yeah, but it *does* have centralized servers, too)

2024-08-27 15:10:20

- reply

Signed by who/what, though. There's the rub.
Look at software distribution, today, on the OSs that most people use for the likely outcome.

2024-08-26 18:55:04

- reply

Practical considerations:
1/ only taproot utxos
2/ address reuse is not supported (though it could be with a trivial algo change
3/ notice the anon set is not "all utxos in the keyset provided" (say it was "all taproot utxos above 0.1 btc" for example). if you specify 5 utxos and you prove "total is between 10 and 12 btc", then obviously not all combinations of 4 utxos add up to something in that range. So if you started with e.g. 300k, your actual anon set might be more like 5000 (guess!). (but even more confusing - 5k utxos might be *part* of a set of 4 that adds up to that range, but the number of actual combinations of 4 could be astronomically larger). Due to nonlinear distribution of utxos, it will therefore be better, if you have a large treasury, to split your coins into a lot more small values, and then build proofs of sums with larger utxo numbers.
4/ proofs in the current code are not aggregated, which makes proving for say 50 utxos, not 4, impractically slow. But this is an implementation detail: aggregation of these bulletproofs is a well established algorithm, and removes this problem. The verification here is very fast, as with aut-ct.
By the way if you're wondering where any documentation of this algorithm is, yet, don't, I haven't written it yet, it's on the way.

2024-08-26 17:15:50

After several weeks of work, I think I have a working implementation (very basic so far, and lots of caveats..) of something that solves this problem. To recap:
you want to prove that you own a total of T BTC, but privately. But revealing exact amount may make it too easy to deanon. So I have a proof of this statement: "I own N utxos, whose total value is between k and k + 2^n, for some k and n that I announce, but I am not revealing which N utxos they are, or what their individual values is, out of a given list of 300k utxos". The code at https://github.com/AdamISZ/aut-ct/tree/auditing now does this.
See the latest commit note. In brief you need 3 or 4 components to the proof: 1/ a proof that each blinded commitment is part of that 300k set, 2/a proof that each committed value, when summed together, lies in the given range (using bulletproofs), and 3/ key images per utxo to ensure you dont' cheat by just claiming the same utxo multiple times.
#nevent1q…c8jd

2024-08-17 15:03:19

- reply

It seems like the main ways nostr could help is: 1/ public key crypto is a "first class citizen" (the only citizen, i guess) in its architecture, meaning you only need your private key to identify yourself, ever (not giving ID to a company). This is not unique to nostr; it also has significant practical cons as well as pros, but, it is an answer to your Q. 2/ relays being distributed in theory helps with censorship resistance, but the person under a terror regime doesn't need censorship resistance as much, they mostly need disconnection of nym and IRL.
Of these, 2/ to me is not really very significant, if at all. the fediverse which has existed for years works the same way. as for 1/ , I think the fediverse should be able to do the same just fine, but, it didn't, and it let server owners essentially "own" accounts which was a disastrous error.

2024-08-16 21:10:37

- reply

Good point for this use case.

2024-08-16 13:33:39

- reply

Nice. Re: socat, i ended up using socat too and was similarly dissatisfied. Your first github link is a 404?

2024-08-15 14:43:54

- reply

If you can see the channel opening txid you can trace forwards from that on a block explorer.

2024-08-11 20:34:24

- reply

RFC6979 does the same as EdDSA in terms of deterministic randomness.

2024-08-11 19:55:26

- reply

Lol indeed.
Another casualty of 'crypto' ...

2024-08-11 19:51:56

- reply

It is and it isn't.
The reason we're talking about lattice attacks is they make it possible to extract private keys from anything from a few signatures to 100s+ - if there are just slight biases (nonrandomness) in the nonces generated by your nonce algo.

2024-08-11 19:47:12

- reply

Serious Cryptography by J P Aumasson is a pretty good 'high level introduction to the main areas of applied modern cryptography' i feel like. You could use it as a starting point for the stuff you want to delve into.
There are tons of learning materials online of course.

2024-08-11 19:02:00

Read the thread for context.
I think it's interesting to compare other situations where signatures get used a lot on keys. A good one might be lightning: in that case, they use a noise-based transport protocol to encrypt the actual tx messages etc, as well as onion routing. however, channel counterparties by definition will see a lot of messages on the same key; just not, 1000s, usually it'll be more like 10s (but that can be enough for lattice attacks to work). Another example is TLS, it's been years since I studied it but iirc it starts with a diffie hellman exchange, not a signature; signatures are used for the PKI part (that is, the certificates presented by the server (not usually client) to the client are signed by an authority in a tree structure; i guess technically this can result in a lot of signatures on single authority keys, so there could be conceivably attacks there).
I'm certainly not sure but I think the continued use of RFC6979 is a tremendous bastion of defence against all these attacks (and the algo is changed in BIP340 signing but it's just a simpler version, it should give the same result - no nonce bias). The area of concern might be more likely the cooperative protocols where deterministic nonces can't be used (see the MuSig bip for some discussion).
#nevent1q…l5x3

2024-08-11 17:15:33

- reply

I sadly somewhat agree. I had a discussion ~ 1.5 yrs ago on here with someone where we both had the same thought: what saves bitcoin users from slightly weak nonces being dangerous to their funds is non-address reuse. (I recommend the paper "biased nonce-sense" by Tanja Lange et al on this). If you use nostr keys as bitcoin keys then even 1 or 2 bits of bias in your nonce generation could be enough to lose the funds.

2024-08-10 14:32:12

This is so delightful, used to love stuff like this when i was into physics; why pi^2 ~ g:
https://roitman.io/blog/91
(hint, it's only true for the right units!)
Another one that's much less easy (or impossible) to find a nice explanation for: the moon is 400 times smaller than the Sun and 400 times closer, hence total eclipses form almost perfect 100% coverage.

2024-08-09 20:12:55

- reply

I think the privacypass type solution (of which cashu is a variant) is probably the best fit here, and if captcha isn't the best way to pay for those blinded tokens, long term (and surely it isn't), we could go the route of utxo ownership proofs of the type I'm working on (directly paying on LN is possible, but suboptimal for privacy).
PoW to me only really fits the bitcoin use case, the problem for more consumer type applications is that the honest user only has advantage over the kind of attacker who needs literally millions of accounts. The cost to the honest user is not negligible enough, I feel. But it's a debatable point.

2024-08-08 21:44:05

Could any Rustaceans out there explain:
I have a package (toy-rpc), if i enter its version in Cargo.toml I get one specific error when i run `cargo check` (or build ofc). This is ok, i can solve that error.
When I change from version to local file in Cargo.toml **, while making sure the local git repo is checked out at exactly the same commit (one that is tagged with the same version no.), I get a bunch of different errors.
I'm stumped; considering as, per commit hash, I'm compiling against literally the exact same code.
Any one know what I missed?
** i.e `toy-rpc = {path = "/path/to/toy-rpc", ...}`

2024-08-08 13:48:14

- reply

Interesting to consider that, to whatever extent nostr fixes this, it's not due to an uncensorability property.

2024-08-07 01:53:09

- reply

It's good advice for privacy reasons. It *does* make some attacks on funds security easier, but in itself, it doesn't break that security. I would say 'never share it' is a good default position.

2024-08-06 01:39:22

- reply

Oh 100%.
Good work!

2024-08-05 23:05:34

Just read the "Dark Skippy" attack ( darkskippy.com ) from Lloyd Fournier and Robin Linux (h/t Alex Waltz). Nice write up! I've always thought it should be simpler than grinding, though (but the grinding in that attack is very practical). I feel like a variant of what they call 'predetermined nonce attack' on that page could work. If I make a *big* assumption - that the attacker has access to the victim's wallet's xpub - then I think you can extract the master secret from only 1 signature or 2 signatures, without any grinding or pollard rho. With 2 signatures the full master secret of the wallet; with 1, only the xpriv for the (BIP32) account (so compromises only 1 account; but many wallets just use one account anyway!).
Let's see if there's any error in these steps:
1. Attacker uses RNG to generate sequence of 32 byte randoms (b1, b2 ..)
2. First signature that the client requests is generated using b1 as nonce. hence attacker can obviously extract the secret key x1 = (s1 - b1) / e1.
3. We have to assume knowledge of xpub. Given xpub and one private key (x1) from the account branch, then due to unhardened derivation, we can already derive the xpriv for the account (though not for the level above; so this is equivalent to master secret, only for single-account wallets, not for multiple account).
But if we have access to 2 signatures we can exfiltrate anything, including the full master secret:
4. Second signature that the client requests, on (currently unknown) private key x2, is generated using nonce = (b2 + master secret), which is still indistinguishable from random because b2 is. Here we need the xpriv as per above to regenerate (poss. by trial and error, but that's trivial) the correct x2 given the above xpriv derivation. Then attacker extracts master secret = s2 - b2 -ex2.
(Am I wrong somewhere there? Wouldn't be too surprised. But either way, exfiltration via these channels *one way or another* seems like it's very hard to prevent. (I know there *are* anti-exfil measures in existence, so please don't take this as me dismissing them - I haven't even really studied them!).To generate bitcoin signatures on serious amount, use the software that's as easy as possible to vet and has the least layers between your eyes and it .. is my extremely unconventional advice on this topic).

2024-08-04 16:06:49

Haven't tried it but seems like a smart idea.
#nevent1q…wqxq

2024-08-03 01:23:22

- reply

No, regrettably (or yes? depends how to interpret the Q.). When i was a kid people did read on trains, but it was mostly shitty newspapers (we used to call them 'rags'). People reading actual books was really rare. Reading 'broadsheets' (which contained words with more than 2 syllables, instead of sensationalist gossip) was a class indicator. If anything it was worse than today, because of the extreme centralization of voice.

2024-08-02 22:39:25

- reply

You can use a self custody wallet like phoenix. No need to have the money held by a third party, just because running one's own node is too high of a bar.

2024-07-31 23:05:53

- reply

Quotes: "The secret key sk: a 32-byte array, freshly generated uniformly at random" and as I already pointed to you, in "Default Signing":
Let d' = int(sk)
Fail if d' = 0 or d' ≥ n
Let P = d'⋅G
Let d = d' if has_even_y(P), otherwise let d = n - d' .
The secret key is still sk as defined above; d is *not* the secret key. It is a step in the signing algorithm.

2024-07-31 23:02:57

- reply

Yes you can do those things but you are not fixing an error. It is not an error to use a private key x fir which the corresponding pubkey xG has odd parity.

2024-07-31 22:12:32

- reply

Doesn't nostr use BIP340 keys? A private key that has a public key with odd parity is not invalid; you just use the corresponding even parity point in encoding. It's effectively using -x * G for specific algorithms (see the "Default Signing" algorithm in bip340), but it's not that x is an invalid private key.
Honestly the x-only encoding was a bad choice, it has led to a lot of confusion and complexity.

2024-07-31 16:08:46

You can now run an autct server by just downloading the binary here: https://github.com/AdamISZ/aut-ct/releases/latest and running it with `./autct -M serve -k mycontext:mykesetfile` (or use an example keyset file shown in the worked example), then make RPC calls from Python with no crypto code (just do `pip install autctapi` ... though you'll want to look at the github repo for the example.py script), to prove that your taproot utxo is in the utxo set. The proving takes 5-15 seconds for keysets up to a couple hundred thousand keys, while the verifying is basically instant.
If you did want to use mainnet keys, you can get a daily-updated set of taproot keys from https://hodlboard.org/keysets. This is filtered to be only keys for utxos > 500k sats, and so it's small, about 17MB. You can demonstrate that it works "for real" by funding such a utxo and then trying the prove and verify operations the next day. It's fiddly mainly because most wallets don't support taproot, and those that do don't let you copy the private key. See https://hodlboard.org/proofs for how to get around that.
(Better to generate the keysets yourself of course, but it takes some time to figure that out, detailed instructions in first repo mentioned)

2024-07-26 15:22:34

- reply

I want to upvote this sentiment, but somehow feel the second sentence misses the mark.
The whole point of politicians is that they won't leave us alone.
And the whole point of bitcoin is to make that matter less.

2024-07-21 18:25:18

Imagine that the ownership of a utxo could be traded directly - ignore, for a moment, that you can't trade ownership with private keys, ignore trading costs etc. etc., not because those issues don't exist, but because I want to focus on the economic calculus outside of it.
Now this question is only interesting if the utxo is somehow encumbered, and ignoring general covenants, let's focus specifically on timelocked utxos (which is in fact a primitive covenant).
So concretely, imagine 1 BTC which is timelocked for 1 year, and imagine you could somehow freely trade it. What would its market value be?
Note that this is *not* similar to traditional put/call options, because we are not talking about the *option* to buy something, but about directly trading it. So it seems to be the same contract as a future (except not requiring a court to enforce!). You're buying the thing (in this case "a" bitcoin), but not able to do anything with it until 1 year expires. Is that worth more or less than 1BTC today?
In normal futures markets, there is another factor to consider: the base currency in which the "commodity" is being priced. So nobody talks about the price of a futures contract on a barrel of oil, measured in barrels of oil, they only talk about it measured in USD. For that case, we have "normal" curves where the further out into the future you go, the more it costs to buy such a contract, because you are hedging risk of volatility and you pay a premium for that, and then you have inverted or "backwardated" curves where it's actually cheaper to buy well into the future, because of competing factors like storage costs and others.
We could try to apply that logic to trading bitcoin/usd futures and indeed, they exist! So people do exactly that. But I'm thinking of the price of the contract in BTC. It seems obvious that the price of 1 BTC in 1 year is less than 1BTC today, because the buyer forgoes the *option* to use the money in the meantime, for anything else, including productive investment. That discount is sometimes called the "time value of money". So you could imagine some formula like 1 BTC - r*1year*1BTC where r is some vague idea of a riskless interest rate.
That's all very kind of "standard" thinking but I am not sure if it's the real story. If I buy a futures contract I have to literally hand over the money to a broker and I receive a contract. But if I somehow gain ownership of a timelocked utxo (see caveat at the start), I have something slightly different. Can if I borrow against it and gain independent value from it while it is locked? I thought about this but the picture appears to be very muddy. So, can I? What do you think? :)

2024-07-17 22:26:30

concordium.com
We've come a long way from the 2015 days of 'enterprise blockchain' **, now it's:
Web3ID
AI Accountability
Identity-centric L1 blockchain
Compliance-ready
Energy-efficient blockchain
NFTs
Metaverse
DeFi
** .. or have we?

2024-07-12 15:00:26

- reply

On a first scan read, I'm not sure there's much of interest here. As he notes in the efficiency section, it's comparable in verification cost to pre existing C(LSAG), at least that's intuitive, so I just believe it. It *is* very compact, but I don't think that's new.
I think curve trees + signature of knowledge of the rerandomised key gives the same effect with much faster verification, at the cost of a fairly trivial increase in size of proof (and with very sublinear scaling, imagine 2.6kB for 50K keys and 2.6kB for 200K keys).
In a blockchain proof size is paramount, but verification speed is also important. Luke Parker's FCMP stuff is actually trying to get both together.

2024-07-11 22:06:22

- reply

No I'll take a look later, thanks!

2024-06-24 17:16:35

- reply

I'm terrible with this, I definitely get your point.
But your note could be more concise ;)

2024-06-18 18:54:21

- reply

I don't know, perhaps try the Jam telegram group: https://t.me/JoinMarketWebUI ?

2024-06-17 18:12:59

- reply

Define 'soon' 😄
People in Europe think they know what rain is ... they do not!

2024-06-17 18:11:36

- reply

Just read the first couple paragraphs... it comes on a bit strong, but, yep 😄

2024-06-17 17:47:50

- reply

Oh sorry it's a joke reference to a critique of string theory, criticizing it as not being real science. Stimuff like ALARA/P is not really anything to do with science imo.

2024-06-17 17:46:14

Into the third day of what is likely 6+ days of *constant* very heavy rain here in El Salvador.
Country is now in a 'red alert' condition.
Esrmtimated 600mm of accumulated rainfall. I think it's going to be really bad in the low lying areas with poor infrastructure.

2024-06-17 17:33:16

- reply

So you believe there's a threshold. Back when I was studying this, I remember also feeling strongly that this should be true, logically.
Reminds me of the old (possibly apocryphal) story of the guy who dropped his banana from lunch on the floor of a nuclear power plant and it triggered alerts on people's dosimeter readings 😄
Natural sources are easily high enough to matter, a lot, with LNT. So yeah i agree it's probably just wrong, and 'ALARA' is ... not even wrong 😄

2024-06-17 17:26:33

- reply

(Btw ALARA to me, just like the 'precautionary principle' is illogical/meaningless nonsense ... apparently I *do* have some strong opinions on this 😄)

2024-06-17 17:24:09

- reply

Sidestepping, i just mean, take LNT as true and stick with those guidelines and it's reasonable. Unless you think even LNT is noymt cautious enough?

2024-06-17 17:21:27

- reply

I'm a former nuclear engineer so I feel *somewhat* comfortable with this topic, and I don't see anything particularly controversial here.
(Linear no-threshold and all that jazz ... we can sidestep those debates).
Where I do sympathise with the general public is that radiation operates entirely outside of the human sensory apparatus, and so there is no inbuilt, instinctive 'feel' for the danger level. It's not irrational to be ... irrationally fearful of it, if you see what I mean :)

2024-06-17 17:08:57

- reply

ye = yr sorry

2024-06-17 17:08:32

- reply

Oh yeah 100% they are fine in small enough dose/ye, but saying literally 'x-rays are harmless' would be misleading and dangerous.

2024-06-17 16:42:26

- reply

Any doctor saying that should be struck off.
Good meme though 😄

2024-06-16 20:53:10

- reply

I think if I'd been involved in, and making bank off, doing biological/bioweapon experimentation with the CCP, which then spilled over into a global pandemic, I'd probably prefer it if everyone believed it came from animals? And would be keen to promulgate a false narrative that all the experts agreed this was true?
Cover up can be for incompetence and corruption.

2024-06-16 20:40:03

- reply

Yes I'm aware of eco health alliance's direct involvement (Daszak et al) and that cover up occurred. It's not the same as there being a conspiracy to unleash it, or the vaccines, on the global population.

2024-06-16 19:55:10

- reply

More:
https://delvingbitcoin.org/t/fed-up-covenants/929

2024-06-16 19:54:22

- reply

I think the CCP 'manufactured' it from the intrinsic incompetence in their system. Just a surmise, but anyway, I doubt what you're saying is true overall.

2024-06-16 19:50:55

I wanted to communicate about this idea of Jeremy Rubin, because I'm not sure how easily people will understand what he's saying:
https://rubin.io/bitcoin/2024/05/29/fed-up-covenants/
An attempt to explain without mathematics: the ability to create an address that can only be spent in one specific transaction (the most basic/pure covenant), but without needing a new op-code or soft fork. How? Basically by taking advantage of a crypto technique called "functional encryption", you can let someone/anyone make a signature to pay out of an address by "decrypting", but the decryption will only work for the single transaction you intend.
There are basically two problems with this apparently magical trick; one small, one big.
The smaller problem: to make this flexible structure needs a trusted setup: you create an initial (bitcoin) private key and an initial encryption key, and they must deleted at the end of the setup, otherwise the mechanism described above won't be safe from anyone who knows those keys.
The bigger problem: generalised functional encryption as described here, i.e. "give a decryption key for the output of a general function f, given the encryption of the input of the function" doesn't really exist as far as I know, except in theory. There are papers from the last decade that develop and extend more limited variants, such as "inner product encryption" which implements the idea for only the function of (take the inner product of the input with a given other value/vector), but (*and I could be wrong here) we are a long way from having it at the level where the function could be "schnorr signature of inputs (private key, transaction hash)" (though JR references ECDSA, it seems way more reasonable to go with Schnorr, since it's a simpler formula).

2024-06-16 18:49:22

- reply

As per my response to Sjors, I appreciate the correction on Campbell even if I can't verify it it sounds very likely, but on the substance here, I would say that what's at issue is not whether the vaccines were perfect, it's whether it was reckless to impose them on populations, or perhaps even much worse than reckless.

2024-06-16 18:45:06

- reply

OK you're probably right about the first paragraph; it was lazy of me to make assumptions just from seeing the guys videos about 10-20 times back in the day.
I did listen to TWiV a few times, but it's a bit too in the weeds for me.
"But if you're 100% sure .. baseline for comparison should be infection." Hmm, that sounds true, but this part and especially the 2,3 paragraphs that follow is the centrepoint of what I mean about expertise, intelligence, wisdom: I know you are a trained scientist, as am/was I, but afaik you are not an expert in this field (if you are, forgive the error): do you really think you can assess correctly things like mRNA vaccines? I certainly cannot. But, I did not believe the scientific information coming out at the time, due to the mass hysteria. (The idea of science, even physical science, as unbiased and objective is a bit fantastical nowadays; no chance, and *especially* not something with political sensitivity and with huge economic incentives, too). Sorry if that seems luddite, unserious analysis, but to me it was obvious. And it also seems clear, trying hard to filter and admittedly I could be wrong, but it seems clear that the vaccines did not come without substantial health risks, and were rushed, and were using experimental new tech. It's just to me obviously unwise. The data on total death rates was just not there to support the idea that this was a plague level event requiring desperate measures. All this is an example of taleb's "via negativa" way of thinking; there's a ton of stuff here we can't fully, properly assess; but in the absence of a plague-level event a rush to action like we saw with these vaccines was unwise. Everyone got infected anyway, as you'd expect; the virus became less dangerous over time, as you'd expect. I believe it was a profoundly unwise decision to mass vaccinate with something so new.
Also, thanks for the serious critique of my point of view.

2024-06-16 17:30:01

This video struck me quite forcefully; I remember that this UK doctor was making regular update videos at the height of the pandemic, very much giving "consensus" information and advice on how dangerous the virus was etc. Nowadays we see something like this: even totally "inside the tent" experts giving detailed information on just how shockingly unwise and dangerous it was to force mRNA vaccines on the public.
https://youtu.be/nq2qwql8xBs
I do not criticize those who took the vaccines. I would tell those people the same thing I told a few family and friends at the time: I am not taking it because I see mass hysteria, and I don't trust scientists even a little bit not to be affected by the obvious mass hysteria.
(Notice how I was not claiming any medical or scientific knowledge in the field, but this heuristic has served me well. Crowd dynamics *completely* change people and are intensely dangerous; since around 2010 the world has dramatically changed because those crowd dynamics can be set off by a much more powerful vector in the form of social media, which is kind of super-charged internet for the masses).
Those who took the vaccines in many cases were forced to at the point of losing their livelihood. Plenty of others just considered it a moral obligation, combined with an intelligent deference to scientific authority. They were wrong on the latter point, but not in a way I consider stupid, just *perhaps* a little naive (even that's a stretch!).
The other thing that clouded people's judgement was fear. Even to this day I think a lot of intelligent people somehow convinced themselves that covid19 was some kind of monstrous threat like the bubonic plague that justified a biologically nuclear response like rushed, experimental vaccines. As I've said before here, intelligence and wisdom are very different things.

2024-06-14 23:04:39

- reply

Would be interesting to see the data displayed per capita.

2024-06-11 18:27:22

- reply

I'm still playing on 1.29 because I hate updating 😄

2024-06-11 18:26:34

I've been thinking this through and I've encountered two closely related problems. My outline of the naive approach is: see the "Vcash" section of the Curve Trees paper. The "pour" algorithm already does most of what you want. You build a tree of utxo pubkeys, more exactly tags of the form G__nll =hash(pubkey)G_t to use the notation of the paper. Then for each of yours, you build the commitment as C_i = v_iG_v + G_nll_i + r_i H where v is the value of the coin and r_i is a random chosen by the prover to blind the commitment. So far so normal. Then you use CurveTrees' "Selectandrerandomise" algo to get C_rr,i (rr means 're-randomized' commitment) along with a proof of its validity (i.e. a proof that it's in the tree.
After doing this for every one of your utxos, you then need to attach a second zero knowledge proof, a minor adaptation of "pour" in Fig 6 of the paper: instead of proving zero balance from summing ins and outs in a transaction, you prove "commitment to my claimed balance minus the sum of commitments to the list I've given has value 0". You also need to attach a range proof for each one of the outputs, but this is also handled by spend/pour in the paper.
But in that lies the problem: if I claim an exact amount, say 100 BTC, and I have to provide a list of N utxos, I've provided already too much information, in the general case: with a very specific amount and a number it's almost trivial (usually) to crunch the public utxo set and figure out the subset that gives the exactly correct total sum. I only see two directions to correct this problem. Use a proof of range instead of exact balance (prove x > y instead of x == y), but this can be surprisingly much more difficult than proving exact values in zero knowledge. Or, some form of aggregation to avoid leaking the number of items (so instead of one c_rr per one of your keys, somehow aggregating the selectandrerandomize? not sure if that actually even makes sense ...).
#nevent1q…0tl7

2024-06-11 07:53:29

- reply

I remember parapass as a challenge player from the old days :)
Haven't seen the new OST, but i saw the last one, it had a couple of super hard maps right.

2024-06-09 22:31:11

- reply

No, see Curve Trees

2024-06-09 22:30:34

- reply

Yes, see Curve Trees as I've been describing ad nauseam in this feed :)
+ other zk systems to implement similar things, perhaps.

2024-06-09 17:20:28

I believe we currently have the technology to make compact proofs of ownership of a certain amount of btc without revealing which utxos we own. Computationally intensive, sure, but compact and quick to verify, even though thwre are 160M+ utxos.
There's a bit of engineering work, but with this, we could embarrass Coinbase Custody into proving they actually hold the coin they claim to.
#nevent1q…2rpk

2024-06-06 16:54:31

- reply

It's the most common in wallets that aren't multisig yeah

2024-06-06 16:20:37

- reply

P2wsh is one of the segwit types, the other is p2wpkh.
Technically, taproot (p2tr) is also segwit, it's segwit v1 not v0

2024-06-06 14:57:54

TIL Bitcoin Optech has a handy calculator for sizes of transactions of different types:
https://bitcoinops.org/en/tools/calc-size

2024-06-03 16:09:13

- reply

Rust is quite demanding and restrictive if your main coding experience is Python. The main Rust book isn't bad (doc.rust-lang.org/stable/book), but what i found most useful was VScode with its rust extensions for real time feedback and hints. I'm still quite limited with Rust though, so take that with a pinch of salt.

2024-06-02 23:28:12

I found myself pondering about malleability: it's just a posh word for "change(ability)", see variants "malleable", "malleate". More malleability is more power but also more danger. Pushing analogies to their extreme, consider the difference between pure gold and alloyed gold. Pure gold is perfectly resistant to corrosion but being extremely malleable, is useless for building strong structures. In a similar way, cryptographic constructs that are naively built with very powerful primitives (like schnorr signatures) that are easily malleated can lead to useful outcomes (adaptors) and highly dangerous ones (naive MuSig). So-called "textbook RSA" is also like this (here's a good explanation: https://crypto.stackexchange.com/questions/1448/definition-of-textbook-rsa ).

2024-06-02 15:52:31

- reply

Hesitate to put a number on it, but first and last 6 is already very strong, yeah .. maybe 9 bytes of entropy based on base58 expansion? Don't quote me, heh.

2024-06-02 14:31:35

- reply

Fascinating that they grinded the leading and ending characters of the address. I guess I will be more careful recommending people to check the last few and the first few characters of an address.
To be fair, that's always only a second or third line of defence, for low or medium size transactions, but still ...

2024-06-02 13:59:11

- reply

There are two forms of Sybil protection in Joinmarket, because of the taker-maker asymmetry. Both forms use utxo ownership. The takers have to produce what we call a "PoDLE", a commitment to a proof of discrete logarithm equivalence - in English, they publish a hash and have to reveal the utxo behind that hash to makers that agree to join with them, revealing the utxo behind it. The attack this dissuades: constantly spamming request to find out maker utxos. If someone can see all the makers' utxos they can deanon coinjoins, so it's a "snooping" attack. With PoDLE you are quite heavily rate limited in how many coinjoin requests you can make.
See the first two articles on my blog (P(o)ODLE and Racing against Snoopers) for more on that. https://reyify.com/blog/racing-against-snoopers-in-joinmarket-0.2
The makers have to publish a fidelity bond, as others have noted. See docs/ subdirectory in joinmarket-clientserver for some explanation and links to further explanation.
Fidelity bonds directly dissuade Sybilling and are much weightier, in general (the size of the utxo involved tends to be large), but note that in neither case are utxos spent, they are just held (for PoDLE) or timelocked (for FB). And FB UTXOs are actually published, which is a bad thing; I've recently spent a lot of time looking for efficient utxo set proofs, partly motivated by that.
(Although it's a bad thing, those utxos can be completely separate from utxos used in coinjoins, so it's not *that* bad.)

2024-06-01 13:33:49

- reply

Yes thanks. It being Japanese *is* starting to ring bells, so thanks. 500k btc still sounds incredible, is that a calculation of all cryptoccy stolen in btc value? Would make way more sense. Article is blocked.
You mention cryptopia, was that the NZ one? I'm remembering cryptsy also.

2024-05-31 16:29:10

That Coincheck number is incredible. I don't remember hearing about it.
#nevent1q…jxjr

2024-05-31 14:43:35

- reply

Forgive me for slightly derailing, but .. isn't that a fascinating moral quandary, what I just mentioned? I am Mr Trusted Bitcoin Developer (MTBD) and I set up a mint anonymously, and the mint's key I ring-sign using 10 other famous people's keys. These are "SAG"s (spontaneous, no involvement of other 10). Then a year later police get warrants to search all the other 10 people's houses. Maybe it's unlikely that police power extends that far, but .. given history I would not doubt it. It seems pretty obvious that this is *not* OK, right? But it can't be stopped except by .. an ethical choice?

2024-05-31 14:01:59

- reply

Yes, it's not workable imo, either 1/ the group is small enough that LEA goes after and harrasses all individuals or 2/ large enough that nobody can place trust in it because nobody knows(of) all the members.
Ring sigs usually have exculpability, meaning you can't be proven as the signer even if your key is coerced out of you. But similar to OTR, it sounds nice on paper, but (maybe?) doesn't help too much in practice if LEAs are harassing and intimidating you.

2024-05-29 04:13:24

- reply

I'm reading about it at the moment. Very interesting but there's a lot to take in.

2024-05-28 21:05:45

- reply

Not sure that I remember exactly right, but I feel like there was also a big delay in hearing anything about Pertsev after he was arrested.

2024-05-27 02:33:51

- reply

I feel like it has to be qualified that economic nodes' power is of a different quality. And yet I definitely don't disagree that these 4 categories exist, but also, line between investors and economic nodes is very blurred.

2024-05-25 19:39:54

- reply

Don't feel bad at all, it never hurts to ask. I don't do much work in that area nowadays, as it happens.

2024-05-24 22:23:45

Heraclitus in shambles
#nevent1q…weva

2024-05-21 11:57:49

- reply

why "fees OR rate limiting"? I think you need both and the former is the solution for the latter (in anonymous user context).
With "fee" interpreted in the most general way possible. Any scarcity is possible. Hence things like RIDDLE/aut-ct, and indeed hence things like privacypass/cashu/any chaumian cash,lightning payments (weaker privacy but other adv.), etc. Although, in some contexts, some of those things need a kind of "bootstrap" (i.e. they might be private, but if you have to pay for them with a non-private payment the problem isn't fully solved).

2024-05-20 11:33:25

The COPA vs Wright written judgement is out.
https://www.judiciary.uk/judgments/copa-v-wright/
Curious as to if there's a path to criminal prosecution here?

2024-05-19 16:32:38

- reply

Not disagreeing entirely, but I'm not sure. People's response may depend on how directy they can empathise with the context.

2024-05-19 12:20:43

- reply

Great to hear. I am not as bullish as many are on chaumian ecash generally, but for this it really ticks the boxes. Are you aware of privacypass? It was designed for a very similar use case, and cashu uses an almost identical crypto protocol.

2024-05-19 12:05:09

Many analogies for the Tornado cash case have been offered, here's a better one ;)
You are a manufacturer of blinds for windows, and tinted windows for cars.
This is not the manufacture of something that harms people directly, or harms people if misused (you'd have a lot of trouble trying to kill someone with these products).
These products have a direct usage in aiding privacy and security (that the two are linked is apparently entirely unobvious to many in the general public when asked about the privacy issue, and apparently also unobvious to certain Dutch judges).
Once you sell the product, you have no further involvement. You may see a car with your tinted windows pass by on the road, but you can't stop that car, even if you somehow know that it is a bank robbery getaway in action. By their nature, your products make it more difficult for you to see if the actions occurring behind them is criminal or not criminal.
Finally, like literally every product on the planet that is *actually useful*, it IS useful in criminal activity. But as per the 4th paragraph, it is ALSO very useful in non criminal activity.
If you got this far in reading, I'd like to pose the question: how do we get the general public to understand or care that this is the case?

2024-05-18 15:07:04

- reply

I used to love squash. But I'm curious, I thought 'racquetball' was just the American word for 'squash'. Are they different sports?

2024-05-18 11:16:06

- reply

Should be 2.5,0.5 not 2,0.5 duh. Meant each input split into 2.

2024-05-18 10:51:20

- reply

> Im not sure I understand your argument re cjs, is it that CISA makes batching in general cheaper with cjs being a byproduct, meaning that private txs would have no economic benefit over batched txs and, assuming cjs will continue to be centrally coordinated in a fee model, cj txs continue to be less economically favorable to non-cj txs even with CISA?
Yes. Except, I don't think the coordination (centralized or not) really plays a role in this analysis. It's just that subset sum analysis works if there is no ambiguity (simplest example: inputs: (3, 7) and outputs (2,0.5,3.6,3.4)); while in theory (see Bell's number) there are always a huge number of possible interpretations *in theory*, but in practice 2 normal payments are overwhelmingly likely. The "counterarguments" I mentioned, mainly I'm thinking of at large number of utxos consumed, ambiguities start to become common. As for the last sentence: cjs are not really less economically favourable, they gain from CISA in the same way as another large tx does; the point is more: if the coinjoin is of the form of a batched payment it doesn't do anything much, whereas if you create an extra separate coinjoin in the right form to promote privacy it's an extra cost; with CISA it's just a smaller extra cost.
(Might help: i define coinjoin as any single transaction that cospends inputs of more than 1 party. see e.g. payjoin).
> Practically I think I disagree if we assume that the tx gets cheaper the bigger it gets with full aggregation – reaching sizes of 400+ inputs will likely mostly be unachievable for single signers, so i think cjs practically would have an economic benefit over non-private txs excluding fees (at least until there is non-private CISA collaboration).
Right that's another way of looking at it; if as per above coinjoin = any cospending then there's clearly a benefit to doing it, but my point is that isn't by default a "private tx". Maybe "somewhat private". By the way curious historical fact the first version of public coinjoin was by blockchain dot info and they used exactly this model, centralized, and without CISA of course - just take everyone's payments and throw them into a single big transaction. People were pretty ignorant back then 😄
> Do you have any proposals in mind that would explicitly make privacy cheaper than non-privacy?
Almost anything offchain gets this by default. *More* private and *less* expensive. LN, Ark, sidechains, rollup models etc. I remember years ago talking about this as "cutting the gordian knot of bitcoin privacy", because by default privacy techniques tend to use more space - see coinjoins, see confidential transactions; there's a natural way to create privacy by obfuscating by *adding* data. The difficulty is (1) to make offchain work *securely* is very difficult and (2) L1 always exists and so things like coinjoin IMO will always exist in some form (some level of obfuscation) but it will be at large values/sizes. As for what *that* might look like yes CISA could be involved but there's lots of ideas out there, I like a model I called "coinjoin done right" (there's a talk on youtube with that title, btc++ cdmx), based on coinjoinXT, basically trying to make coinjoin steganographic so they can't be flagged, but people are branching out and trying various things. See e.g. wabisabi for payments in coinjoin, see e.g. nothingmuch's recent work. Also just channel dual funding by @npub1e0z…0txy et al. is a huge step forward

2024-05-17 17:26:26

- reply

CISA for privacy is a very non trivial issue. As Chris Belcher always used to point out, the simple argument "coinjoins become cheaper with CISA, therefore CISA promotes cheaper privacy" is mostly just not true, because coinjoin promotes "A is paying B, C is paying D" to happen in one transaction instead of two, but that batched transaction doesn't *by default* offer any additional privacy, because they will not modify the structure (in particular the output amounts) in a way that obfuscates the transactions. Now there are definitely counterarguments but I think that's more true than false.
And whether you get into those counterarguments or not, either way, CISA is clearly a net positive in many senses, and *at the very least* shouldn't make privacy worse (in this, I am disagreeing with https://delvingbitcoin.org/t/cisa-and-privacy/824 for example; it seems most people there argree with me)
Still, let's not jump the gun. CISA doesn't yet exist unfortunately.

2024-05-17 12:30:13

- reply

A separate response to a separate point:
> UX is the most important problem we need to solve for Bitcoin Privacy.
Disagree. The most important problem we need to solve for bitcoin privacy is to make it cheaper than non-privacy. Everything else follows.
(that's why focus of base chain modifications should be on changes that make higher layers achieve functional payments for all users with low costs, because decent privacy is completely natural at higher layers, whereas at base chain layer it's quite unnatural)