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.
Listening to nostr:npub1cj8znuztfqkvq89pl8hceph0svvvqk0qay6nydgk9uyq7fhpfsgsqwrz4u podcasting about security and hardware wallets…what is meant by “most people will not be able to own a UTXO”?? #asknostr #lowtechpleb
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.
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.
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.
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.
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)
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.
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.
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.
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.
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.
Good point for this use case.
Nice. Re: socat, i ended up using socat too and was similarly dissatisfied. Your first github link is a 404?
If you can see the channel opening txid you can trace forwards from that on a block explorer.
RFC6979 does the same as EdDSA in terms of deterministic randomness.
Lol indeed.
Another casualty of 'crypto' ...
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.
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.
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).
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.
This is so delightful, used to love stuff like this when i was into physics; why pi^2 ~ g:
(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.
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.