waxwing

Bitcoin, cryptography, Joinmarket etc.

Public Key

npub1vadcfln4ugt2h9ruwsuwu5vu5am4xaka7pw6m7axy79aqyhp6u5q9knuu7

Profile Code

nprofile1qqsxwkuyle67y94tj378gw8w2xw2wa6nwmwlqhddlwnz0z7sztsaw2qpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dstxtsm3

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub1vadcfln4ugt2h9ruwsuwu5vu5am4xaka7pw6m7axy79aqyhp6u5q9knuu7

Show more details

Last Notes

2024-09-12 16:30:04

Here is Cramer's solution:
The "challenged" does this: choose a random number in 1..1000, r, look up question number r for Komodo dragons and memorize it. The challenger then provides an unpredictable random number in 1..1000, c, and says "give me two answers, one from each list, where the question numbers add up to c modulo 1000. So the challenged calculates c - r (mod 1000) to get r2, which is the number of a question from the Fermat list, which he can immediately provide, along with the r-th Komodo dragon question, and the challenger veries that r + r2 = c mod 1000.
(For anyone interested, this is the extremely elegant solution to how to combine Sigma protocols in OR relations, "first" discovered in CDS-94 (see the first sections of my blog on ring signatures for details: https://reyify.com/blog/ring-signatures )
#nevent1q…39t8

2024-09-11 23:29:30

- reply

Really interesting idea, I like it. Obviously difficult in practice, but the spirit of the idea makes sense, as long as the numbers get large enough.

2024-09-11 23:07:27

- reply

Nice answer :)
It's a slightly more fun version of, e.g. having a computer program that asks you to enter correct answers and prints out pass/fail, so basically you answer the questions in secret and the challenger sees only the result, and believes that it was executed correctly ... which is pretty reasonable.
(not the intended answer of course; for that no mechanical or digital mechanisms needed).

2024-09-11 20: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 19: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 18: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-05 18:22:36

A train of thought coming from: "we can't do ZKPs using sigma protocols or bulletproofs on chain, because we only have ECC operations against one generator (G)":
Imagine one of the very simplest things you can do with 2 generators: proof of discrete log equivalence or DLEQ for short. This is basically the simplest possible generalization of Schnorr; one secret, two bases. This requires two ephemeral commitments (the nonce k mult. the 2 generators) and only one scalar response (one "signature", if you like).
Of course, you can't verify such a thing on chain; you can't check sJ = R_2 + hash(..)Q where Q = xJ and P = xG. You can only verify the first version, w.r.t. G: sG = R + eP, which is ofc standard Schnorr, here bip340.
But .. is there a way adaptors could help? Because an adaptor is something you verify offchain, and so it isn't restricted to one base/ generator.
Imagine your goal is "unlock a payment only if P and Q have the same DL wrt G, J" (yes I know, bizarre, but I'm fumbling towards the first sentence, here).
Obviously if we're including "verify something offchain before taking an action", we'll find it sanest to stick to a 2 party protocol first. Let's see:
1. Alice sends Bob P, Q, R1, R2 (having calculated from a random k, R1 = kG, R2 =kJ, and already knowing x_a s.t. Q=x_a J and P=x_a G); her private key is x_a
2. Alice pays into a 2-2 multisig with Bob, where her key is P, and the aggregate key is Pagg, with U1. When Alice signs it (not yet), the signature will look like:
s_a = k1 + H(R_agg + T, Pagg, txmsg_U1)x_a
Notice the +T which will be for an adaptor that Alice adds. This process is already well understood for Schnorr multisig. I am glossing over Musig related details, claiming they don't change the following.
3. Alice provides an adaptor over J for ``spending'' U1. Before writing this out, consider: we want the s-value to be the same over J as it is over G. This is problematic, because the s value comes from a structure that is basically : s = k + e*x, where e is the hash, and as per bip340, that hash *must* be exactly: H(R, P, m) where P is the onchain key, R is the onchain nonce and m is the actual transaction message. So if we do things naively, i.e. make an adaptor over the J base like:
s'J = R2 + H(R2+T, Q, message)Q
.. then we're going to fail to create the desired scenario: that the real signature 's' is the same between the J and G bases. In order to solve this we have to play a trick. We don't change the nonce or public key fields in the hash at all, i.e. we do:
s' = k2 + H(R_agg + T, Pagg, txmsg_U1)x
and have Bob verify:
s'J =?= R2 + H(R_agg + T, Pagg, txmsg_U1)Q
Superficially that is unsound; the reason is that such signatures can be forged if the corresponding nonce point R2 is not fixed into the hash/FS challenge, which it appears it isn't (also not "key-prefixing" by including the public key, here Q, in the same challenge is, at the least, problematic). However this can be solved, albeit in an unorthodox way: include both R2 and Q, which are curve points, as data inside the bitcoin transaction! (spending U1). It will just be "dead" data (e.g. OP_DROP) because you won't be able to sign against them; they use the wrong basepoint, but it is still easy).
4. Bob verifies this adaptor using (to repeat): s'J =?= R2 + H(R_agg + T, Pagg, txmsg_U1)Q.
5. Now Bob knows that if he sees the valid s for this equation, he gets the private key t of T w.r.t. J. Importantly, he also knows that if that one s corresponds to the s that is needed to spend U1, then Q and P have the discrete log equivalence property we are proving. But simply convincing Bob of a fact like that is uninteresting in itself; you can do that by simply directly sending him ZKPs of various types. So, :
6. Alice also provides offchain a DLEQ proof that T = tJ and T2 = tG
7. Alice makes another adaptor on a payment of another utxo U2, using the same t: s'_2 = k_3 + H(R_3 + T2, P2, m)P2.
8. Bob now knows that if U1 is spent, it reveals s, proves that DL Q/J = P/G, and that he can spend U2 using s_2 = s'_2 + t, having extracted t from s - s', and knowing that that t value corresponds to T2.
This could be seen as "just an adaptor based atomic swap with a bunch of extra steps", but I'd call it more "atomic swap gated by DLEQ", i.e. it will fail unless Q/J = P/G holds.

2024-09-04 17:47:49

Followers are neither vitally important, nor something you can just automatically expect.
But they still matter.
I've often used this and similar microblogging just as a kind of notepad, writing down ideas and info/evidence for something I'm working on, meaning it does have some *small* value even when no-one reads it.
But even that rather unexciting way of using these platforms benefits tremendously from interaction with an audience, even a small one.
Enhancing discovery of accounts you might enjoy interacting with is pretty obviously... good?
#nevent1q…smll

2024-08-28 22: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 17: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 19: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-11 22:34:24

- reply

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

2024-08-11 21:55:26

- reply

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

2024-08-11 21: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 21: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 19: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-09 22: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 23: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 15:48:14

- reply

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

2024-08-07 03: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 03:39:22

- reply

Oh 100%.
Good work!

2024-08-06 01: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 18:06:49

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

2024-08-03 03: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-03 00: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-08-01 01: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-08-01 01: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-08-01 00: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 18: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 17: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 20: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-18 00: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 00:06:22

- reply

No I'll take a look later, thanks!

2024-06-24 19:16:35

- reply

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

2024-06-18 20:54:21

- reply

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

2024-06-17 20:12:59

- reply

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

2024-06-17 20:11:36

- reply

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

2024-06-17 19: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 19: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 19: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 19: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 19: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 19: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 19:08:57

- reply

ye = yr sorry

2024-06-17 19: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 18:42:26

- reply

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

2024-06-16 22: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 22: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 21:55:10

- reply

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

2024-06-16 21: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 21: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 20: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 20: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 19: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-15 01:04:39

- reply

Would be interesting to see the data displayed per capita.

2024-06-11 20:27:22

- reply

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

2024-06-11 20: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 09: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-10 00:31:11

- reply

No, see Curve Trees

2024-06-10 00: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 19: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 18:54:31

- reply

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

2024-06-06 18: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 16: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 18: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-03 01: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 17: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 16: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 15: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 15: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 18:29:10

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

2024-05-31 16: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 16: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 06:13:24

- reply

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

2024-05-28 23: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 04: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 21: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-25 00:23:45

Heraclitus in shambles
#nevent1q…weva

2024-05-21 13: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 13: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 18: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 16:29:43

- reply

Yes i don't think there was any other real world use outside of that, but, it was a big one.

2024-05-19 14: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 14: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 17: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 13:16:06

- reply

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

2024-05-18 12: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 19: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 14: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)

2024-05-17 14:24:28

- reply

It's a common perception that the problem with things like Bisq (P2P trade) is UI, but it's not.
First, it's crucial to distinguish between P2P trade of fiat for bitcoin and P2P trade of 2 different cryptocurrencies, because they're entirely different animals. I'm only going to talk about the former, because that's the one that really matters, and that's the hard one.
Problem 1: because of the ethically odious AML policies there is substantial real risk from counterparties. If you are receiving dollars/euros into your bank account without first doing a full scale police level investigation into your counterparty you are potentially violating AML and this could impact *your* bank account. Even if you did such investigations, if you start doing multiple such trades your account can easily get flagged and frozen. Nothing I'm saying here is theoretical, it really does happen, a lot.
Problem 2: The process of P2P fiat trade is *intrinsically* not convenient and doesn't give *traders* what they want, which is why it doesn't tend to have volume, and volume is a necessary component for convenience (low spreads, quick matching), to the extent that ordinary users just give up (when you see 15-25% spreads you tend to give up, that is not because you're a lazy user who needs good UI). It's true that e.g. in Europe you have SEPA and very quick bank-to-bank is possible, but it's very precarious and ironically, when problem 2 is solved, problem 1 just reappears quickly anyway.
Problem 1 is mostly solved by avoiding banks and using cash or cash substitutes in *small* amounts only. Localbitcoins had this perfect in the early days, but they got "done" at some point, and sold out to KYC only. I would even argue that a cash-only localbitcoins substitute that's Tor-only might be the best we could do ... if things get tough enough for people I could see them putting up with this inconvenience, but of course this is a world away from the volume you get from degen traders sitting in their bedrooms, who just want braindead point and click. But old localbitcoins for cash *did* work, though it is subject to stings by LEA, you only have to exercise minimal common sense to avoid the law coming for you. This is not a "solution" for 6 figure trades though ...
Problem 2, I don't think it really gets solved, if anything it'll get worse over time, as banks for the last decade have only moved in the direction of making conversion of fiat to bitcoin more and more absurdly difficult.
I was chatting a lot with Manfred Karrer right at the time he invented Bitsquare, I even managed to convince him not to use MAD 2 of 2 multisig, so you can blame me on that, and I tried it in the early days. It was honestly decent in UI even then (yes I know it *looks* complicated, but I mean, try using Interactive Brokers interface to trade stocks, it just takes a little time), and I'm sure it's way better now. IMHO, The problem is not UI.

2024-05-17 01:55:51

Lol, Tim Ruffing did a funny and I don't think anyone noticed:
[1] It's so bad, we can't even agree on a spelling. BIP340 spells it "X-only", some people write "x-only", and some write "xonly", probably in order to save a byte
😆
https://github.com/jonasnick/bips/issues/32#issuecomment-1177725159

2024-05-17 01:52:23

- reply

Schnorr sig aggregation would have worked fine with the old serialization.

2024-05-17 01:50:33

- reply

A very relevant thread; if anything it's notable just because it's long:
https://github.com/jonasnick/bips/issues/32

2024-05-17 01:47:30

- reply

Yeah removing the parity byte in bip340 key serialization certainly made life .. interesting :) There's a whole section of bip327 https://github.com/bitcoin/bips/blob/master/bip-0327.mediawiki to deal with this. I even wrote a function named with a nerd joke about it :) https://github.com/AdamISZ/pathcoin-poc/blob/b9e5021cdce5d394ab170068584ff20c265baf23/pathcoin.py#L97
Your tool seems like a very good idea to help you debug if you're trying to work out a new protocol, it's quite confusing.

2024-05-16 23:31:17

- reply

Yes it is, good find, tim ruffing covers it well in that answer. And my bad for not remembering it. If you look at e.g. FROST they argue strongly that for the even more tricky case of *threshold* signatures (ie M of N, not just N of N, which as you can imagine is much more delicate), that a proof of knowledge of key shares is realistically essential, I came to the same conclusion looking at the security proofs of these things - it's stupidly complicated otherwise. MuSig2 is a very "industrial" protocol, by which I mean, partly because of the requirements of bitcoin, they push the limits on sophistication in order to achieve the most performant and smallest interactivity footprint possible version of multisignature. The cruder way is "key + proof of knowledge of key" in setup and then "nonce point + proof of knowledge of nonce point" in signing. But while that is kind of "the" solution to this niche problem, I'm for sure not going to recommend doing some half cocked protocol instead of doing the sane thing of creating fresh keys and then following the very well analyzed standard(s).
On your "more generic question", sure, the immediate thought is "well this was my secret key in the first case so it can't be adversarially chosen", yes, but the signing process has another "key", namely the nonce "shares" you do for each signing event. If they are adversarially chosen you again can get a forgery; in fact you can *use* this to extract the private key of the other signer. This is why the original MuSig was patched up to commit to the nonce points first, in an extra round.
If you add that 3rd round in, the overall idea is *perhaps* safe ... indeed that 3 round musig is quite nice, when I coded it for pathcoin I used that instead of MuSig2, it's a simpler security model at the cost of 3 instead of 2 rounds of comms. But meh, this is too slapdash, i suspect.

2024-05-16 17:04:44

- reply

As opposed to just making a fresh 2 keys? I mean it'd always be easier to just do that ofc (and authorise new key(s) with old).
Hmm with MuSig2 it's not possible I think. The aggregated pubkey is designed to withstand key subtraction attacks, and that means you can't backsolve to make the aggregated pubkey be equal to the preexisting pubkey.
So you're in a weird area ... try do just combine signatures naively without the protections of musig2 against adversarial behaviour? Very unlikely to make sense since you're doing this for improved security in the first place.

2024-05-16 01:17:53

- reply

Coincidentally that's one of the first things I posted on nostr about :) Yes, 2 people could cooperatively control a nostr npub and use musig2 to sign for it. MuSig2 was designed to do exactly that for secp256k1 keypairs (which nostr as well as bitcoin use). It's a protocol to let N of N individual keys create a combined keypair and make signatures which require the consent of all keyholders. The protocol (musig2 that is) is pretty complicated to make it so that the end product look just like any other signature, and the combined pubkey looks like any other pubkey. HTH.

2024-05-15 17:52:34

- reply

Don't know if it's still true but for years bitcoin node IBD was like *the* stress test of a hard disk. People used to report failures all the time.

2024-05-14 17:47:58

- reply

I realise you're not a lawyer but, any sense of how this judgement might have the potential to affect other judgements in the EU (or even perhaps outside it)?

2024-05-14 13:43:45

- reply

This is the response I'm wondering about, i.e. is this perspective the reason we don't hear much about it? Algos can be user chosen so that argument has always seemed dumb.
I used to use mastodon and the developer had a similar reason for not having algos. I think it's incoherent and stupid. Time ordering is an algorithm, just an extremely simple one.
It's totally different in a FOSS scenario.