pull down to refresh
If we're willing to make users wait 1440 blocks between commit and reveal, they'd only need to sacrifice (a bit more than) one 1440th (i.e. ~0.07%) of their rescued coins to incentivize miners. One quarter would be drastic overkill. See the "Parameters" section of the article for the math.
To clarify, the miners aren't "reverse-engineering" anything in a censorship attack - they're just blocking the authentic reveal TX from being mined, for long enough that their own malicious commitment can mature, allowing them to mine their own (malicious) reveal TX.
The happy path would look roughly like this:
- Your wallet sends an opaque commitment hash to an aggregator server (e.g. via an API call)
- The aggregator combines that hash with hundreds or thousands of others
- A few minutes later the aggregated commitment is mined
- a long time (e.g. 1440 blocks) later, you reopen your wallet and your funds are ready to rescue. Your wallet sweeps them into your primary account with a reveal transaction, paying 0.08% of their value as a fee to incentivize miners.
- now your coins are all on PQ-secure addresses.
then p2(w)pkh and taproot are potentially clean as well as anything that has a hash in a key derivation path, and then the only question is: whether or not to confiscate p2pk?
In theory yes. I have never heard of any knowledge asymmetries for P2PK wallets, so DropKick deployment has no utility or impact on those coins.
Thanks. Yes, that's mostly correct. A few minor notes:
- You don't necessarily need to use the same PQ key $Q$ for publishing the "timestamp" (commitment) transaction.
- You (the wallet user) don't need to publish the commitment transaction - you can delegate that to an untrusted 3rd party: an "aggregator", who publishes a merkle tree that merges many users' commitments together, a la opentimestamps.
hehe sorry, the miner incentives game-theory appendix at the end was rather long-winded, but necessary if i wanted to argue security. Otherwise one could claim the scheme is broken by just saying "Miners will collude"
Any proposal that asks for additional proof post Q-day, no matter which flavor, will always confiscate every coin in such a wallet.
That's not correct. If a rescue protocol were deployed to allow rescue via only decidable knowledge asymmetries (hashed addresses, taproot) then none of those coins you cite would be confiscated. As Tadge said recently at Bitcoin++, "who doesn't know their public keys?".
Confiscation only occurs if we encumber coins with undecidable KA's, such as BIP32 derivation, where it's impossible to tell at-a-glance which addresses were generated via BIP32 and which weren't.
DropKick generalizes to any KA, so it can be deployed with or without confiscatory side-effects, depending on whether the future community puts more value on (1) rescuing the most coins from the QC, in which case use all the KAs, or (2) preventing all confiscation, in which case use only decidable KAs.
Hey there, quantum cryptography researcher here. I've written extensively on the subject: #735909 #1288781 #1453183 #1419471
Nobody can answer the question "When will quantum computers be powerful enough to threaten classical cryptography?". You're right to be skeptical of anyone who claims the threat is imminent without proof. But i would like to dispell a few inaccurate notions in your post and its comments.
First, facts only:
- Private keys aren't stored on the blockchain. A private key is just a big number, which you either know, or you don't.
- Public keys are sometimes stored on the blockchain. A public key is another big number, mathematically related to its private key. If you have the private key, you can create signatures which spend any bitcoins locked to your public key.
- If you have a big quantum computer, you can run Shor's algorithm to factor a public key into its private key.
- You cannot use a quantum computer to efficiently invert a strong hash function like SHA256. It gets easier, but is still thought to be intractable.
- Many public keys are exposed on the blockchain, including those of Satoshi's coins and of big exchange cold wallets. See this dashboard (explainer).
- Most NATO-aligned governments (US, UK, EU, AU) have deadlines to migrate fully to post-quantum crypto and disallow the use of quantum-vulnerable algorithms by 2035.
Now some corrections:
a hard fork involving hashing algorithm change would be the most effective solution
We do not need to change Bitcoin's block-mining hash algorithm any time soon. Grover's Algorithm gives at best a mild speedup over classical computers. IF in the distant future quantum computers start threatening classical mining, they will be a centralizing force (due to the nature of QCs, see https://stephanlivera.com/episode/670/), and we should soft fork in a change of hash algorithm (no hard fork needed).
For one, quantum proof bitcoin exists (I've never confirmed but heard from multiple sources).
There are quantum-resistant sidechains pegged to bitcoin, but their bridges are still vulnerable to sufficiently advanced quantum computers. At best they are a stopgap. There are suggestions which use newly proposed opcodes like OP_CAT to implement PQ-safe address formats. There are BIPs currently being drafted which may someday introduce explicit PQ-safe cryptography opcodes.
But AFAIK there is no consensus mechanism on bitcoin (mainnet) in existence today which fully secures coins against big quantum computers (QCs). At best you can avoid being the low-hanging fruit by using hashed addresses and spreading your coins out among many smaller UTXOs.
Any wallet that has not sent any money has not published a key to crack.
Correct, but that's not why people are worried.
In total about a third of all bitcoins which will ever exist are currently locked to pubkeys which are exposed on-chain. Even if your coins stay secure in a hashed address, a QC could steal a large portion of the Bitcoin supply because many coins are pubkey-exposed, and are (conjecturally) held by dead hands who can make no moves to rescue them. So this inheritance falls to the first organization to aim a sufficiently big QC at it.
The FUD comes from the idea of supply flooding: That if a QC attacker wanted to, they could flood the market selling stolen dormant bitcoins and crash the value of bitcoin, at least in the short term.
Whether this would actually happen is unknown - We can't know what the motivation of a QC attacker would be (see this article for an examination of that question), or what legal precedent such an attacker would use to justify mass theft, or whether exchanges would permit such high volume from a single customer who is clearly malicious. I think most of the FUD comes from fear of the many unknown outcomes of that scenario.
The good news is that scalable and quantum-safe signature schemes exist, which can replace the current quantum-vulnerable scheme used today, and they're only going to get better. So most people have no reason to worry. Just hodl tight in hashed addresses and move to PQ-safe addresses once they become available.
how do you think about the risks of using some of these fairly new cryptographic techniques?
The fundamental problems like the endomorphism ring problem are fairly well studied. Not as well-studied as the EC discrete log problem we rely on today but still, I think if isogeny-based schemes are broken, they'll be broken one at a time, by flaws in their security proofs rather than by flaws in the underlying core assumptions of the field.
PRISM is an interesting case study. They have a curious security proof. They make the assumption that it's hard to find prime degree isogenies from an arbitrary curve.
It just so happens that if producing prime-degree isogenies from an arbitrary curve was easy, it would prove SQIsign secure because SQIsign assumes the existence of prime-degree isogeny oracles in their security proofs. So if SQIsign is broken, this would prove no such oracles exist, and that PRISM's assumption is secure. Vice versa, if a prime-degree isogeny oracle does exist it would break PRISM but prove SQIsign secure.
I've heard one of their authors refer to this as "security by common belief". This doesn't necessarily mean that only one OR the other is secure. It's possible that both are secure, but no one knows how to prove it rigidly yet.
Would you feel comfortable using them for Bitcoin in the next year or two (if there was lots of time and energy put into it) or would you want to wait longer?
Personally I see isogeny crypto as a long-term replacement to consider in maybe 10 years or more, not something that should be rushed into consensus.
i don't think waiting is the right thing to do either though. We as a community should be investing in research that shows promise, tech that may play a role in our future. Right now that's what i'm trying to do with my time, and i hope others will join me in that effort so that someday we can still do fun stuff on top of bitcoin's cryptography even after QCs come around.
SQIsign verifies fast but signing takes seconds on current hardware
That's not true anymore. Using Kani's lemma, the SQIsign authors boosted signing speed so it's now much more competitive. The new SQIsign (also known as SQIsign2D-West) can sign in a few tens of milliseconds on a decent CPU.
The primary candidates I know of are SLH-DSA (AKA SPHINCS+) or SHRINCS. You could technically use plain XMSS or even WOTS, but while more space-efficient these algorithms require statefulness.
Personally I would prefer that knotsers delude themselves, and proceed with their soft-fork confident. Gets it over with faster and less contentiously that way.
Fortunately though, you're right. Regular (non bip110) Bitcoin nodes do not simply follow the longest chain- they follow the chain with the most cumulative proof of work. This metric is called "chainwork". It's basically the overall expected number of hashes needed to get to a chain of this size, after all previous difficulty adjustments.
If BIP110 activates without majority hashpower right off the bat, then legacy nodes will (eventually) follow the regular legacy chain as it accumulates more chainwork.
For BIP110 miners to "wipe out" and reorg the legacy chain in the future, as some have conjectured, they must not merely attract a majority of hashpower- they'd have to attract it and keep it for a very long time. The BIP110 miners would need to (on average) compute more hashes than the legacy miners did while the legacy miners had the advantage. The longer it took BIP110 miners to earn their hashpower advantage, the longer the BIP110 miners must maintain it for, to exceed legacy miners' chainwork and cause a reorg for the legacy nodes.
The rules of PoW favor whichever ruleset has more work put into it over time, not just whichever chain has majority hashpower in the moment. Think integrals, not derivatives.
This isn't about a mint stealing funds from its own users. It's about a malicious mint stealing funds from users of another mint. E.g. you trust Alice's mint and have $1000 on there. You don't trust Bob's mint, but someone airdrops you $5 in ecash from Bob's mint. You try to transfer (melt) the ecash to Alice's mint (which you trust) but doing so allows Bob to steal the $1000 of valid ecash that you already had on Alice's mint.
This is partially correct, but it's not the whole picture. Lava's old custody model used DLCs as one component of a complex cross-chain (Solana) multi-transaction smart contract where, in theory, the user would always have a unilateral exit back to Bitcoin when the loan expires. In theory, the user should always be able to get their Bitcoin back in full by repaying the stablecoins on Solana. Vice versa: Lava should always be able to recover the loan capital plus any accrued interest even if the user is malicious.
The problem was, like Spark's protocol, there were many assumptions made to get to that goal. The oracle behaving, the Solana smart contract key staying secure, the closed-source software being authentic, etc. The on-chain protocol itself was as well-designed as it could be, but ultimately brittle and susceptible to subtle implementation bugs or misuse.
If they wanted to, it would've been easy for Lava to rug-pull everyone, which is exactly the same as any other closed-source bitcoin wallet, because of remote code updates, naive users, etc. Lava's CEO Shehzan and I have spoken about this subject quite a bit, and while I'm more optimistic about self-custody than he is, we mostly see eye to eye.
There was no practical path to fixing all of these issues definitively. All the while, if even the smallest bug were to sneak through, if they were hit by a phishing attack, or an NPM supply chain attack, etc, it would lead to a catastrophic hack or lost user funds. This never happened, but it was a factor on their minds.
Knowing this, and also having opportunities to build a better product by doing so... Lava rebuilt everything and moved to an institutional custody model. But unlike most custodians, every user's deposits are kept isolated until they are withdrawn. You can audit on-chain to confirm your collateral isn't being rehypothecated and gambled away SBF-style. You can find more info about their new system here.
Having audited both the old and the new code bases, I would be far more confident using the new platform rather than the old DLC-based on-chain protocol.
Source: I work part time for Lava as a security contractor.
Just based on historical precedent alone, I imagine people would default to whichever fork is more economically popular (larger market cap)
I do really hope that if a fork comes, there isn't a protracted fight over naming rights
I'm happy to report I worked with Ken from paywithmoon to get my coins returned without doxxing myself. Turns out the problem was just old-fashioned buggy chainalysis, big surprise. I verified the source of my funds without KYC and that did the trick. I might give their service another try in the future, but when I do i'll make sure I deposit only with Lightning where chainalysis flagging me is less of a concern.
Absolutely agreed.
If nvk or another high-level CoinKite employee had wanted to execute a rug-pull, they'd have far stealthier and more effective ways of accomplishing it than committing their malicious code directly to github in a signed commit.
For example, just distribute malicious firmware builds but keep the git tree "clean". 99.9% of people, even experienced devs, aren't going to build their own firmware from source or reproduce the firmware's hash - they just install whatever binaries the devs ship. A backdoor inserted through a malicious build is undetectable without some serious reverse-engineering skills. If anyone does call you out on the build being impossible to reproduce, you can just blame some unknown "bug" in the dev's local build system, change the tooling a bit, and call it "fixed" before anyone catches on.
And if you were going to introduce a vulnerability into a git tree, you wouldn't do it in the main firmware repo. You'd place the vulnerability deep in the dependency graph, so that when the rug is pulled, you can blame some anonymous 3rd party library as a scapegoat and maybe recover a semblance of your reputation.
Hanlon's Razor applies here.