alin.apt retweeted
7/ the actual forking lemma (the probability part)
the tricky part: the forger doesn’t succeed every time. maybe they succeed with probability ε
when we rewind and replay with a different challenge, they might fail the second time
the forking lemma (Pointcheval and Stern, 1996) quantifies this:
if the forger succeeds with probability ε and makes at most q queries to the random oracle, then the probability of getting TWO valid signatures (same R, different e) is at least:
ε · (ε/q - 1/|F|)
roughly: if ε is non-negligible and q is polynomial, the extraction succeeds with non-negligible probability
in simpler terms: if the forger has any reasonable chance of succeeding once, we have a reasonable chance of making them succeed twice. and twice is all we need to extract the key
the tricky part: the forger doesn’t succeed every time. maybe they succeed with probability ε
when we rewind and replay with a different challenge, they might fail the second time
the forking lemma (Pointcheval and Stern, 1996) quantifies this:
if the forger succeeds with probability ε and makes at most q queries to the random oracle, then the probability of getting TWO valid signatures (same R, different e) is at least:
ε · (ε/q - 1/|F|)
roughly: if ε is non-negligible and q is polynomial, the extraction succeeds with non-negligible probability
in simpler terms: if the forger has any reasonable chance of succeeding once, we have a reasonable chance of making them succeed twice. and twice is all we need to extract the key
1
1
5
248
"slop infestation"
I interviewed ~2 dozen researchers, engineers, research / engineer managers etc. asking them how they / their teams use coding agents in their work. Then I sprinkled it with my opinions and hot takes and wrote a substack post (link in the next tweet, I'd be delighted if you subscribe; of course, the post is free and any future post will be free too!) trying to triangulate the current reality of software engineering / industry research as opposed to what gets peddled on social media.
TL;DR (3. and 4. are the most important!):
1. Models, harnesses, workflows: don't bother with fancy workflows, they don't really work. Use stock Claude Code / Codex (or Copilot with Claude / GPT models if you are a Microsoft stan), perhaps with subagents in some very special cases. Write a design doc, then plan a change, then implement it, then merge. Wash, rinse, repeat. Don't get swayed by people online who are trying to sell you snake oil in the form of their new harness or workflow. None of this stuff works (in general).
2. Correctness/tests/reading or not reading code: it's OK not to read code if you do one of the following three things. a) One-off stuff / demos, which you need to work on exactly one input. b) Testable / verifiable stuff, e.g., GPU kernels. c) Stuff, where it's OK to be "directionally correct" (ML / data work / research code). In other cases, especially if you require any degree of maintainability / reliability or your code is customer-facing, reading code is still necessary. Reading tests and steering the model to write better tests is a good idea too. It's often good to use a different model to review the code that the other model wrote. Even if you approve the PRs without changing them, reading still helps for future more productive prompting.
3. Team dynamics: if we are not careful, agents can really undermine team dynamics. Two biggest problems are "slop infestation", where over time all PRs / emails / Slack messages end up being unreadable slop, and "overbuilding", where we are building and shipping useless stuff to get recognition or as a form of procrastination. Other, less severe but still important problems include: reduced communication, being secretive about ideas, decreased diversity of thinking, mode collapse of the ideas, trusting LLMs more than people.
4. Call for action: we really need to be careful with preserving team work and collaboration. We still need to "form packs to hunt mammoths", but with coding agents this becomes increasingly harder. Overall, many of the agents-induced problems stem in myopic short-term thinking of the sort "we have a couple of years left until our jobs are fully automated, so I can as well extract as much value as possible, everyone else be damned". While somewhat understandable, I think it’s important to resist these urges, if nothing else, for your own sanity’s sake.
[Full disclosure: until 2 months ago, I worked at OpenAI and my work directly contributed to Codex, I'm a big fan of coding agents and quite strongly AI-pilled, but there is little I hate more than fearmongering, gaslighting, lies and rage-bait that are ubiquitous in this space, unfortunately, hence spending time on all of this.]
2
0
4
1,417
alin.apt retweeted
I interviewed ~2 dozen researchers, engineers, research / engineer managers etc. asking them how they / their teams use coding agents in their work. Then I sprinkled it with my opinions and hot takes and wrote a substack post (link in the next tweet, I'd be delighted if you subscribe; of course, the post is free and any future post will be free too!) trying to triangulate the current reality of software engineering / industry research as opposed to what gets peddled on social media.
TL;DR (3. and 4. are the most important!):
1. Models, harnesses, workflows: don't bother with fancy workflows, they don't really work. Use stock Claude Code / Codex (or Copilot with Claude / GPT models if you are a Microsoft stan), perhaps with subagents in some very special cases. Write a design doc, then plan a change, then implement it, then merge. Wash, rinse, repeat. Don't get swayed by people online who are trying to sell you snake oil in the form of their new harness or workflow. None of this stuff works (in general).
2. Correctness/tests/reading or not reading code: it's OK not to read code if you do one of the following three things. a) One-off stuff / demos, which you need to work on exactly one input. b) Testable / verifiable stuff, e.g., GPU kernels. c) Stuff, where it's OK to be "directionally correct" (ML / data work / research code). In other cases, especially if you require any degree of maintainability / reliability or your code is customer-facing, reading code is still necessary. Reading tests and steering the model to write better tests is a good idea too. It's often good to use a different model to review the code that the other model wrote. Even if you approve the PRs without changing them, reading still helps for future more productive prompting.
3. Team dynamics: if we are not careful, agents can really undermine team dynamics. Two biggest problems are "slop infestation", where over time all PRs / emails / Slack messages end up being unreadable slop, and "overbuilding", where we are building and shipping useless stuff to get recognition or as a form of procrastination. Other, less severe but still important problems include: reduced communication, being secretive about ideas, decreased diversity of thinking, mode collapse of the ideas, trusting LLMs more than people.
4. Call for action: we really need to be careful with preserving team work and collaboration. We still need to "form packs to hunt mammoths", but with coding agents this becomes increasingly harder. Overall, many of the agents-induced problems stem in myopic short-term thinking of the sort "we have a couple of years left until our jobs are fully automated, so I can as well extract as much value as possible, everyone else be damned". While somewhat understandable, I think it’s important to resist these urges, if nothing else, for your own sanity’s sake.
[Full disclosure: until 2 months ago, I worked at OpenAI and my work directly contributed to Codex, I'm a big fan of coding agents and quite strongly AI-pilled, but there is little I hate more than fearmongering, gaslighting, lies and rage-bait that are ubiquitous in this space, unfortunately, hence spending time on all of this.]
TL;DR (3. and 4. are the most important!):
1. Models, harnesses, workflows: don't bother with fancy workflows, they don't really work. Use stock Claude Code / Codex (or Copilot with Claude / GPT models if you are a Microsoft stan), perhaps with subagents in some very special cases. Write a design doc, then plan a change, then implement it, then merge. Wash, rinse, repeat. Don't get swayed by people online who are trying to sell you snake oil in the form of their new harness or workflow. None of this stuff works (in general).
2. Correctness/tests/reading or not reading code: it's OK not to read code if you do one of the following three things. a) One-off stuff / demos, which you need to work on exactly one input. b) Testable / verifiable stuff, e.g., GPU kernels. c) Stuff, where it's OK to be "directionally correct" (ML / data work / research code). In other cases, especially if you require any degree of maintainability / reliability or your code is customer-facing, reading code is still necessary. Reading tests and steering the model to write better tests is a good idea too. It's often good to use a different model to review the code that the other model wrote. Even if you approve the PRs without changing them, reading still helps for future more productive prompting.
3. Team dynamics: if we are not careful, agents can really undermine team dynamics. Two biggest problems are "slop infestation", where over time all PRs / emails / Slack messages end up being unreadable slop, and "overbuilding", where we are building and shipping useless stuff to get recognition or as a form of procrastination. Other, less severe but still important problems include: reduced communication, being secretive about ideas, decreased diversity of thinking, mode collapse of the ideas, trusting LLMs more than people.
4. Call for action: we really need to be careful with preserving team work and collaboration. We still need to "form packs to hunt mammoths", but with coding agents this becomes increasingly harder. Overall, many of the agents-induced problems stem in myopic short-term thinking of the sort "we have a couple of years left until our jobs are fully automated, so I can as well extract as much value as possible, everyone else be damned". While somewhat understandable, I think it’s important to resist these urges, if nothing else, for your own sanity’s sake.
[Full disclosure: until 2 months ago, I worked at OpenAI and my work directly contributed to Codex, I'm a big fan of coding agents and quite strongly AI-pilled, but there is little I hate more than fearmongering, gaslighting, lies and rage-bait that are ubiquitous in this space, unfortunately, hence spending time on all of this.]
81
78
799
59,916
alin.apt retweeted
Zcash wouldn't exist without @zooko. He seeded the technical and cultural values of the project that have kept us vigilant in defense of its integrity.
Much of Zcash's recent success has been because Zooko plays a less central role in the project, and it has decentralized and grown to transcend him. I think he would agree! But he is still a major spiritual force of the project, and an ally that wants it to succeed.
Let's be mindful of the signal we send our next generation of risk takers, by how we treat his legacy. Zcash has a long road ahead of it, and no single one of us can carry it across the finish line.
We're all liable to end up in @zooko's shoes one day. You do not want to be on the receiving end of the poetic justice served for the things you said when you were once on the winning team.
Much of Zcash's recent success has been because Zooko plays a less central role in the project, and it has decentralized and grown to transcend him. I think he would agree! But he is still a major spiritual force of the project, and an ally that wants it to succeed.
Let's be mindful of the signal we send our next generation of risk takers, by how we treat his legacy. Zcash has a long road ahead of it, and no single one of us can carry it across the finish line.
We're all liable to end up in @zooko's shoes one day. You do not want to be on the receiving end of the poetic justice served for the things you said when you were once on the winning team.
35
87
537
31,799
You can read my take on why proactive refresh seems hard in their set up: alinush.github.io/near#why-presi…
2
0
0
348
You can also read about how they modify the additive key derivation from Groth-Shoup’21 here: alinush.github.io/near#why-presi…
0
0
2
234
alin.apt retweeted
6/ There's been this persistent notion that formal verification isn't worth doing because "a spec can just as easily have a bug as code".
We decided to test that with real empirical evidence. And the answer is an emphatic *NO*. Especially in an age of agentic coding
We decided to test that with real empirical evidence. And the answer is an emphatic *NO*. Especially in an age of agentic coding
2
3
29
1,513
I remember a cryptocurrency space that used to have higher ideals.
Satoshi did not set out to “solve users’ problems today.”
What Sandeep would call “larpers” were the early adopters from 2012 and before, whom Satoshi won over, and who set out to establish the field we’re all in today.
None of them built pragmatic solutions.
There was nothing pragmatic about Ethereum. Or Zcash.
It was due to their complete disregard for pragmatism that we’ve made it this far (scalable BFT, fast ZK) and we now stand to solve **tomorrow’s** problems (censorship, surveillance).
The f*** outta here with “today’s problems.”
Satoshi did not set out to “solve users’ problems today.”
What Sandeep would call “larpers” were the early adopters from 2012 and before, whom Satoshi won over, and who set out to establish the field we’re all in today.
None of them built pragmatic solutions.
There was nothing pragmatic about Ethereum. Or Zcash.
It was due to their complete disregard for pragmatism that we’ve made it this far (scalable BFT, fast ZK) and we now stand to solve **tomorrow’s** problems (censorship, surveillance).
The f*** outta here with “today’s problems.”
What @ilblackdragon and NEAR team has built is a pragmatic solution which solves users’ problems “today” and such solutions win the users, technically perfect solutions win larpers (that too for a short time, you can never satisfy them for long)
8
14
85
5,453
> show me what your privacy looks like...
> THIS IS WHAT FAKE PRIVACY LOOKS LIKE!
> THIS IS WHAT FAKE PRIVACY LOOKS LIKE!
This is craazy. I asked one of our PhD engineers to look into NEAR *Confidential* Intents wondering how they designed their system. Unredacted, word-for-word, this was his answer 😱😱😱
"Everything I found out about the privacy claims and confidential intents is so bad that it seems almost comical and I cannot believe what I am seeing. Apparently they run a completely separate instance of the protocol, which is called FAR (as an opposite to NEAR), and that has a permissioned operator set. The entire confidentiality claim seems to rest upon the fact that it is a permissioned chain and the nodes are trusted to keep things private, there doesn't seem to be any deep technology behind it and it also does not seem to be open source. The entities running the nodes are also not publicly known.
I almost feel weird writing this because it is so absurdly bad that it feels like ... I don't know ... a simulation? I know the usual level of overpromising in Web3 but this is so many levels beyond believable that it still feels unreal."
4
3
51
2,959
An important "clarification" by @CommunityNotes: turns out the danish national ID system wasn't hacked.
No, no, no...
It was simply *designed* to be easily & legally accessed by every dimwit who can't set a password.
But it was not hacked. Totally-secure design!!
No, no, no...
It was simply *designed* to be easily & legally accessed by every dimwit who can't set a password.
But it was not hacked. Totally-secure design!!
2
0
14
1,085