Workspace Index › Dev Notes › A crypto safety margin has a shelf life — date it, and make the signature scheme replaceable
#67PoC
A crypto safety margin has a shelf life — date it, and make the signature scheme replaceable
On 2026-09-10 researchers cut the estimated quantum-attack resources for BTC/ETH by roughly 50%, with an AI agent as co-author beating Google's March result on Shor's core computation. The Ethereum Foundation has a Jan-2026 post-quantum team (pq.ethereum.org) and a 2029 quantum-resistant target. What got cut is the estimated resources, not the hardware — the gap is still orders of magnitude. So the news is not 'the risk arrived,' it is 'the target moved toward us,' and the durable lesson is in the method: a safety margin means 'X years against the best known attack,' so speeding up the search for that best-known shortens every margin's shelf life — and whether 2029 is a migration or a redeploy is decided today by whether signature verification sits behind one interface.
Not a build — two 30-minute checks. (1) Date-stamp the assumption: a parameter like '256-bit, safe' really means 'safe against the best attack known as of today,' so write the calculation date beside it ('safe per 2026-09 estimates') and a review becomes a scheduled event, not a reaction to a headline. (2) Count where signature verification lives: scattered across many functions, a scheme swap is a redeploy; behind one interface, it is a migration. Then check whether the scattered copies have already diverged (one skips a nonce check) — divergence turns cleanup into removing a behavior difference, a different priority. Confirm the specific paper, the ~50% figure, and the EF 2029 target against pq.ethereum.org before asserting.
Why
Two lessons share one root. The epistemic one: a safety margin is a claim indexed to a moment's knowledge, and what changed here is the rate at which that knowledge advances — an AI agent co-authoring the result is the method story, not the ~50% number. Undated, a margin expires silently; dated, its review is on a calendar. The architectural one: 'we'll switch to post-quantum later' chooses nothing — it is an unmade decision wearing the costume of flexibility. The chosen state is one paragraph you can write today: 'the signature scheme lives behind this interface, and replacement follows this procedure.' And the hard part of the eventual migration is not cryptography but procedure — 'how many blocks for every user to move' is the real number.
This is the same grammar as 'a spec should pick one rather than leave both open,' turned on your own contract. For jayverse: every parameter chosen 'because it is big enough' should carry its date and the attack it is measured against, and every signature check should be reachable from one place — so the day the target moves again, the response is a paragraph and a scheduled review, not a redeploy.
How it works
What actually got cut
Change
Estimated resources (quantum attack on BTC/ETH)
cut ~50% (2026-09-10)
Hardware
unchanged — still orders of magnitude short
Method
an AI agent co-authored it, beating Google's March Shor result
Context
EF post-quantum team (Jan 2026, pq.ethereum.org), 2029 quantum-resistant target
The estimate moved, not the machine. That is why the honest read is 'the target moved toward us,' not 'the risk arrived.'
Why the method matters — a margin has a shelf life
A safety margin is really 'X years against the best known attack.' Cutting the estimate moves the 'best known,' so every margin loses shelf life with no hardware moving. Undated, it expires silently; date-stamp the parameter and the review becomes scheduled.
The response — replaceability is a paragraph, not an architecture
Signature verification lives...
2029 becomes
scattered across many functions
a redeploy
behind one interface
a migration
'We'll switch later' chooses nothing. The chosen state is one paragraph: the scheme is behind this interface, replacement follows this procedure.
The two 30-minute checks, and the real number
Date-stamp the security assumptions ('safe per 2026-09 estimates').
Count the verification sites — and whether the copies have already diverged (that changes the priority from cleanup to removing a behavior difference).
The migration's hard part is the procedure, not the cryptography: how many blocks for every user to move. Related: which-etf-window-not-the-size (annotate with the date), sec-signature-replay (verification centralised in one place). Confirm the paper, the ~50% figure, and the 2029 target against pq.ethereum.org before citing.
2026-09-10, 연구자들이 BTC·ETH에 대한 양자 공격 자원 추정치를 약 50% 낮췄고, AI 에이전트가 공동 저자로 Shor 알고리즘 핵심 계산에서 구글의 3월 결과를 상회했습니다. 이더리움 재단은 2026년 1월 포스트양자 전담팀(pq.ethereum.org)과 2029 양자내성 목표가 있습니다. 깎인 건 추정 자원량이지 하드웨어가 아닙니다 — 격차는 여전히 몇 자릿수. 그래서 뉴스는 '위험 도착'이 아니라 '목표 지점이 이쪽으로 움직였다'이고, 지속되는 교훈은 방법에 있습니다: 안전 마진은 '현재 알려진 최선의 공격으로 X년'이라, 그 '최선'을 찾는 속도가 빨라지면 모든 마진의 유효기간이 줄어듭니다 — 그리고 2029년이 마이그레이션이냐 재배포냐는 서명 검증이 한 인터페이스 뒤에 있는지로 오늘 결정됩니다.
구현이 아니라 30분짜리 점검 둘. (1) 가정에 날짜를 병기: '256비트라 안전' 같은 파라미터는 사실 '오늘 기준 알려진 최선의 공격에 안전'이라는 뜻이니, 계산 날짜를 옆에 적으면('2026-09 추정 기준 안전') 재검토가 헤드라인에 대한 반응이 아니라 일정이 됩니다. (2) 서명 검증이 어디 사는지 센다: 여러 함수에 흩어져 있으면 스킴 교체가 재배포, 한 인터페이스 뒤면 마이그레이션. 그다음 흩어진 복사본들이 이미 어긋났는지(하나가 논스 검사를 건너뛰는 식) 확인 — 어긋나 있으면 정리가 아니라 동작 차이 제거이고 우선순위가 완전히 달라집니다. 구체 주장 전 논문·약 50% 수치·EF 2029 목표를 pq.ethereum.org로 확인.
왜
두 교훈이 한 뿌리를 공유합니다. 인식론적인 것: 안전 마진은 한 시점의 지식에 색인된 주장이고, 여기서 바뀐 건 그 지식이 나아가는 속도입니다 — AI 에이전트가 결과를 공동 저술했다는 게 방법의 이야기이지 약 50%라는 숫자가 아닙니다. 날짜가 없으면 마진은 조용히 만료되고, 날짜가 있으면 재검토가 달력에 오릅니다. 아키텍처적인 것: '나중에 포스트양자로 바꾼다'는 아무것도 고르지 않은 것 — 유연성의 옷을 입은 미결정입니다. 고른 상태는 오늘 쓸 수 있는 한 문단입니다: '서명 스킴은 이 인터페이스 뒤에 있고, 교체는 이 절차로 한다.' 그리고 결국의 마이그레이션에서 어려운 쪽은 암호학이 아니라 절차 — '모든 사용자가 옮기는 데 몇 블록인가'가 진짜 숫자입니다.
이건 '명세가 둘 다 열어두기보다 하나를 골라야 한다'는 문법을 자기 컨트랙트에 돌린 것입니다. jayverse엔: '충분히 크니까' 고른 모든 파라미터는 날짜와 그것이 측정된 공격을 지녀야 하고, 모든 서명 검사는 한 곳에서 닿을 수 있어야 합니다 — 그래야 목표가 다시 움직이는 날, 대응이 재배포가 아니라 한 문단과 예정된 재검토가 됩니다.
동작 방식
실제로 깎인 것
변화
추정 자원량(BTC·ETH 양자 공격)
약 50% 하향 (2026-09-10)
하드웨어
그대로 — 여전히 몇 자릿수 부족
방법
AI 에이전트가 공동 저술, 구글 3월 Shor 결과 상회
맥락
EF 포스트양자 팀(2026-01, pq.ethereum.org), 2029 양자내성 목표
움직인 건 추정치이지 기계가 아닙니다. 그래서 정직한 독법은 '위험 도착'이 아니라 '목표가 이쪽으로 움직였다'입니다.
방법이 중요한 이유 — 마진엔 유효기간이 있다
안전 마진은 사실 *'현재 알려진 최선의 공격으로 X년'*입니다. 추정치를 깎으면 '최선'이 움직여, 하드웨어 하나 안 움직여도 모든 마진의 유효기간이 줄어듭니다. 날짜가 없으면 조용히 만료; 파라미터에 날짜를 병기하면 재검토가 일정이 됩니다.
대응 — 교체 가능성은 아키텍처가 아니라 한 문단
서명 검증이 사는 곳
2029년은
여러 함수에 흩어짐
재배포
한 인터페이스 뒤
마이그레이션
'나중에 바꾼다'는 아무것도 안 고른 것. 고른 상태는 한 문단: 스킴은 이 인터페이스 뒤, 교체는 이 절차로.
30분 점검 둘, 그리고 진짜 숫자
보안 가정에 날짜 병기('2026-09 추정 기준 안전').
검증 위치 개수 — 그리고 복사본들이 이미 어긋났는지(그러면 우선순위가 정리에서 동작 차이 제거로 바뀜).
마이그레이션의 어려운 쪽은 암호학이 아니라 절차: 모든 사용자가 옮기는 데 몇 블록인가. 관련: which-etf-window-not-the-size(날짜 병기), sec-signature-replay(검증을 한 곳에). 인용 전 논문·약 50% 수치·2029 목표를 pq.ethereum.org로 확인.