There are tons of quantum proposals out there. Some are pretty solid, while others are not so great, but when it comes to actual implementations, it’s mostly quiet. To shake things up, I went ahead and deployed one of the competing proposals without forking. Looks like Hourglass can be used immediately without needing any consensus changes, as long as it stays optional, letting users voluntarily participate by moving their coins to specified P2WSH scripts.
Here’s the optional Hourglass setup:
To create it, you just need an existing P2WPKH address, where coins are sent to a 160-bit hash of the public key, and wrap it in the Script I mentioned. For instance, if your private key is one and the public key is the generator, it might look something like this:
Then, coins can be sent to, for example, tb1qxp3wmhns4tvg7gvwm9a228mqqwawh9xycnv8dkrdm7xuum6afsrqcuzu88. As long as the private key is not known, everything will operate like a regular P2WPKH, which in this instance is tb1qw508d6qejxtdg4y5r3zarvary0c5xw7kxpjzsx. For signatures that are about 72 bytes, coins will be time-locked for 288 blocks (that’s around two days), but other than that, it functions just like its P2WPKH counterpart (and signing it works the same way due to the OP_CODESEPARATOR, so no changes needed in the signing code).
However, once the private key is known, coins will be safeguarded by a Proof of Work challenge. Just lowering the signature size by a byte allows them to be moved four blocks earlier. So even if both secp256k1 and SHA-256 get fully compromised, a 9-byte signature would still time-lock coins.
Neat trick and there's a few caveats imo,
This is not a drop-in P2WPKH
Segwit v0 ignores OP_CODESEPARATOR in the sighash. Changing the script changes the digest. You cannot reuse a plain P2WPKH signer; you need custom wallet logic that signs the exact witnessScript. Most wallets and HWWs will not work out of the box.
If ECDSA or SHA-256 is broken, an attacker who knows the key can deliberately craft tiny DER (eg 912 bytes) and get the shortest delay. Defenders must be online, watching, and able to beat that with an even smaller sig. That is a race, not a safety net. Thirty-six blocks is not much of a rescue window against a motivated sweeper.
Very short DER is valid under consensus but can trip standardness policy on some nodes. Expect inconsistent relay until you test across versions. Also double-check your CSV math: OP_CHECKSEQUENCEVERIFY uses BIP68 semantics; ensure you set the type bits for blocks vs time correctly.
CSV enforces the most restrictive sequence across all inputs. If someone mixes one of these with a 0-sequence input, the whole tx will be non-final. You likely need a one-input consolidation flow.
OP_SIZE reads the signature including the sighash byte; OP_CHECKSIG consumes it. You must dup/drop in the right order or your CHECKSIG will see the wrong stack. Unit-test with vectors for 71/72/73-byte sigs and a synthetic 9-byte sig on regtest.
Because it is P2WSH with custom logic, ordinary wallets cannot send or spend without special tooling. Calling it P2WPKH-compatible might confuse users.
If your goal is a no-fork hedge, a boring alternative might just be a vaulty P2WSH: key path with CSV 144288 to a hot key plus an immediate cold path.
Yes, but Bitcoin Core signer is close enough to be used. For example:
And then, we can split it into parts:
Then, between "witnessData" and "locktime", we have to put our Script, and increase "witnessSize" into "03":
So, maybe it is not 1:1 replacement, but it is close enough, to sign something directly from Bitcoin Core, tweak it here and there, and then broadcast. Which means, that potential code changes are minimal, to reach any valid signature. And then, it is all about grinding it further, to beat any attackers. And that grinding is exactly in Hourglass's spirit: in that proposal, miners also could steal coins, but their ability to do that was limited by consensus rules, just like it is here (so, that kind of models can be tested, before any soft-fork will be deployed).
Crafting 9-12 bytes signature will be extremely hard in practice. If SHA-256 will be broken, then yes, 9-byte signatures will be possible, but then, the whole chain can be overwritten with anything. However, if secp256k1 will be broken, then r-value will have one byte, but grinding s-value will still require gradually breaking SHA-256. Which means, that different miners will still have to compete, and grind smaller and smaller signatures, to get the coins earlier, than the rest. And it still means starting from something like 40-byte signature, so something like 160 block timelock.
Original Hourglass is also a race.
People can repeat "OP_DUP OP_ADD" as many times, as they want, or add some constant, to make that window bigger.
Type flag is bit number 22. It means 0x00400000, so at least 1 MB signature. It is very hard to achieve that in P2WSH, where you have 520 byte stack size limit. Which means, that you can get something like 2080 block timelock in case of the biggest signature. Which also means, that if you use 2048 as your factor (around two weeks per byte), then it will still be 520*2048=1064960 blocks of delay. Still not enough to reach 4194304, and every value below that is just a timelock, measured in the number of blocks. Also, opcodes like OP_LESSTHAN or OP_WITHIN can restrict things further, if users need it.
They can get quite close with existing tools, so potential changes are quite small (it is all about adding witness stack push with the Script, and also grinding the signature with Proof of Work).
Maybe. But it is as close to be compatible, as it could be. If things are separated with OP_CODESEPARATOR, then z-value can be computed by existing wallets, so that users don't have to fight with Segwit format, and they can focus on getting from Bitcoin Core, what they can, and then improve it a little with any external tools.
Great follow-up and nice demo with Core. Yes, segwit v0 ignores CODESEPARATOR in the sighash, so you can sign the P2WSH witnessScript with Core and assemble the witness stack afterward. That path is workable.
I'd suggest a few things to lock down before mainnet coins touch it:
The operand to OP_CHECKSEQUENCEVERIFY uses BIP68 semantics: value is 16 bits, and the type flag is bit 22 (1 << 22 = 0x00400000). So the max enforceable delay is 65535 blocks (~455 days) in block mode. Adding numbers in script will not extend that beyond 65535; the mask clips it.
P2WSH still has MAX_OPS_PER_SCRIPT = 201 (non-push) and 520-byte max per stack item. Building a huge constant with many OP_ADDs will hit the ops limit long before you reach any big multiplier. A more robust pattern is bucketed delays:
OP_SIZE -> compare against a few ranges with OP_WITHIN or OP_LESSTHAN -> choose one of several fixed CSV values. You can cover 46 ranges well under the limits.
Very short DER is consensus valid if strictly DER and low-s, but policy varies by version. Expect inconsistent mempool relay for tiny sigs.
I would strongly advise to test against multiple Core versions on regtest and with a couple public nodes.
Consider a PSBT flow that includes the full witnessScript up front. Let Core sign that, then you only modify the witness stack elements, not the script. That reduces footguns compared to splitting and re-gluing blobs by hand.
Even with grinding costs, shortest-sig wins is still a race. Add a base CSV (for example 144 or 288 blocks) and then a small per-bucket increment based on OP_SIZE. That gives defenders a predictable window and still keeps the hourglass flavor.
Perhaps it should be called P2WSH Hourglass, not P2WPKH-compatible. Wallets and HWWs will need custom tooling; being precise here can save user confusion.