One thing I'm noticing over time from reading about different ZKP (or just succinct proof) systems is how often two patterns/tricks come up:
one is: represent a composite claim about numbers by random-combination: say you want to prove A is zero and B is zero, you construct A + alpha * B, where alpha has to be unpredictably random - but that's what hash functions + fiat shamir transform can do for you easily. This is seen in basically every construction ever; if nothing else, it's used to make verification faster by batching proofs together.
the second one is something many of us learnt in school with a concrete example: to add up a long list of consecutive numbers, the trick is to take the first and last, then the second and penultimate, then the third and third-from-last etc. as pair, because all of those pairs have the same total. So the general form of this is "pair off items in a list to make a list that's half as long *and* has some special property", and then repeat that until a huge list becomes just a single value.
I've just seen this in FRI as well as it being in bulletproofs and Halo etc. (sometimes called 'recursive' proof technique but that's misleading because that's really something else; that's proofs that prove other proofs are correct :)). The FRI one is interesting because they choose even/odd as the "splitting" function that reduces to half size.
Trick question. A flat surface doesn't have a core.
Indeed, identities are not a desirable solution. That's why https://github.com/AdamISZ/aut-ct exists for example. Of course there are other approaches, many of them pretty well tested by now, all have tradeoffs.
Good long term advice. As a point of focus, you could look at the concept of 'Schnorr signature' and drill down into areas from there.
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.
Thanks, that's exactly what i was wondering.
Yeah 90% of my 'study' is, like, watching telenovelas :) imo it's better that way, albeit it depends on your reason for learning.
But doing grammar exercises is interesting, too.
So apparently #español has 2 completely interchangeable versions of the imperfect subjunctive. e.g. 'cupiera' can be 'cupiese'.
Because verbs were too simple, sure let's add multiple versions of each conjugation!
For those non-students of the language, here's what the conjugation of that verb looks like:
https://conjugator.reverso.net/conjugation-spanish-verb-caber.html
To be fair, the core 4 or 5 conjugations bed into your mind OK after enough time, for most 'normal' verbs (caber is a bit 'spicier' than most), but the very complex way the subjunctive gets used mixed in with past tenses and conditionals really is over the top sometimes).
when i sign up for such a platform, i might want to find info/news about the things that interest me. say my hobby is chess. i can (and should!) use some kind of hashtag system to find chess related content, and then i can choose to follow based on that. as for an algorithm, if i've followed 10 people to find more discussions about (x, y, z) then an algorithm might be able to find 10 more people that talk about similar things. i only vaguely remember, as it was about 8 years ago when i started using twitter, but i think it succeeded in recommending me bitcoin/dev related accounts that i wasn't aware of, quite a few times.
if you already know who you want to interact with, sure. but in a case like that there were probably at least 50 accounts of people i "knew" from irc, reddit, mailing lists, conferences w/e that i had no idea were on twitter, let alone their user names.
Isn't that obvious? while i admit, it is *not* obvious, how to do such a recommendation algo "right".
I mean nostr isn't social media right, and i don't think users have the right to 'require' anything, I'm just trying to say it's common sense to have discovery on social media. I don't think it being 'done the right way' is a relevant Q, let people have a choice on how to do it.
Good one.
Also the old 'spend 2 hours trying to solve a problem then go and ask a coworker, only to immediately realize the solution halfway through asking the Q' 😄
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?
No worries i already have what i need now **, anyway i am probably not the target user.
For example over 1000 blocks to 859720 there were about 27K taproot outputs value above 150K sats created ... with 20K being at unique addresses.
Interesting project, thanks! Don't think it has what i need though (though it does have total p2tr utxos).
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.
Does anyone know if there's data like this:
https://transactionfee.info/charts/transactions-spending-taproot/
but filtered by nondusty sats value? The vast majority of these utxos were created with dusty amounts - but the data i collected only tells me that in the aggregate, it'd be interesting to see over time, what percentage of taproot utxos carry any meaningful value.
"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.
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.