BIP-360: QuBit - Pay to Quantum Resistant Hash #1670

cryptoquick · 2024-09-27T16:08:30Z

This spent several months gathering feedback from the mailing list and from other advisors. This is hopefully polished enough to submit upstream.

Let me know if you have any questions or feedback, and of course feel free to submit suggestions.

Thank you for your time.

… to bitcoin/bips

bip-p2qrh.mediawiki

jonatack

Interesting (the question of resistance to quantum computing may have resurged lately with the publication of https://scottaaronson.blog/?p=8329, see also https://x.com/n1ckler/status/1839215426091249778).

bip-p2qrh.mediawiki

jonatack · 2024-10-01T18:09:31Z

@cryptoquick Can you begin to write up the sections currently marked as TBD, along with a backwards compatibility section (to describe incompatibilities, severity, and suggest mitigations, where applicable/relevant)? We've begun to reserve a range of BIP numbers for this topic, pending continued progress here.

typo fix

jonatack · 2024-10-21T15:27:42Z

@cryptoquick ping for an update here. Have you seen https://groups.google.com/g/bitcoindev/c/p8xz08YTvkw / https://github.com/chucrut/bips/blob/master/bip-xxxx.md? It may be interesting to review each other and possibly collaborate.

jonatack · 2025-03-13T19:25:34Z

@cryptoquick I re-read through the review feedback of the past four months, but it is difficult and laborious to try to understand what you did to concretely address each comment.

Would you please indicate in response to each comment the link to the commit patch with the relevant change you made, and particular for the review feedback from @jonasnick and @vostrnad above?

There is also review feedback marked as resolved, but without a reply. Please help reviewers connect the dots :)

Those pointers would be very helpful, I think, in determining what was done and/or remains to be done in response, and would aid review.

cryptoquick · 2025-03-13T22:56:54Z

@jonatack Thank you for the advice! I went back and did my best to provide some links to the relevant changes. Hope that helps.

Also, I've made a note to address this concern I overlooked:

https://github.com/bitcoin/bips/pull/1670/files#r1994349769

I'd appreciate any thoughts you have on that. Thanks!

…ch from merkle tree commitment to sorted vector hash commitment.

cryptoquick · 2025-03-18T09:57:17Z

In the above changeset I rethought how we do the SegWit v3 scriptPubKey hash commitment... I think the merkle tree is nonsense at this point, since it cannot be sparse because all public key hashes must be known in advance in order to compute a complete commitment. Even in selective disclosure, all hashes have to be provided. @EthanHeilman originally suggested the merkle tree to me, so maybe there's something I'm missing, but for now I'm going back to concatenated hashes. Hopefully this simplifies the BIP a bit, also.

I also made sure we're more declarative of keytypes and thresholds in the attestation because bytes there will be cheap, especially if there's an increased attestation discount. The reason the attestation exists is because it can be discounted separately and its functionality limited to fixed signature operations.

cryptoquick · 2025-03-18T15:50:12Z

In the above changeset I also updated the descriptor format to show a more complete example of how I expect selectively disclosed threshold multisigs to work.

QbitsCode · 2025-03-19T20:44:47Z

Is there somethin in a horizon, how can we reflect the current progression in percent. A clarfication meeting was requested to accelerate finalizing pqcBitcoin but no feedback.

cryptoquick · 2025-03-20T07:53:37Z

@QbitsCode A community call isn't a bad idea. If there is one, we'll most likely announce it in our Telegram group.

murchandamus

People appear to agree conceptually that we should be looking into PQ, but skimming the conversation on this PR, I must admit that I am a bit concerned regarding the seeming lack of approach buy-in.

There seem to be concerns about e.g., introducing too many different PQ Signature schemes introducing unnecessary complexity, the resulting scheme dropping support for existing features, and uncertainty about the properties of the attestation structure's properties. It also seems to me that it is not clear to me what the priority is:
If this is developing an emergency PQ-response that might be deployed on short notice, it would seem that going for less complexity would be fruiltful. If we are going for a fully-fledged, comprehensive response to PQ, it should e.g., not gratuitously drop support for scripting in outputs—don’t we still want HTLCs in a PQ future?

While you are reconsidering the structure of the attestation, perhaps it would be good to take another step back and collect more input on the big picture design goals before jumping back into the tweaking details of another variant of the same approach.

cryptoquick · 2025-03-21T16:28:54Z

Thanks for chiming in once more, Murch.

There seem to be concerns about e.g., introducing too many different PQ Signature schemes introducing unnecessary complexity

You have good timing with this, since I just published libbitcoinpqc, which should be a one-stop shop focal point for PQC needed for BIP-360, similar to how libsecp256k1 was for BIP-340. You can check out that work here:
https://github.com/cryptoquick/libbitcoinpqc

The algorithmic complexity shouldn't be so bad now that it's abstracted in a useful way.

If we are going for a fully-fledged, comprehensive response to PQ, it should e.g., not gratuitously drop support for scripting in outputs—don’t we still want HTLCs in a PQ future?

I'm not dropping support for witness scripts. The attestation is just like putting additional locks on coins in an address, in addition to whatever is expected to happen in the witness. I expect this to be compatible with a lot that's already been developed for Lightning and Taproot. I would like to verify that in practice however. A good start to that would be post quantum-flavored versions of rust-bitcoin, BDK, and LDK.

While you are reconsidering the structure of the attestation, perhaps it would be good to take another step back and collect more input on the big picture design goals before jumping back into the tweaking details of another variant of the same approach.

Perhaps, but another alternative is to put the work needed into proving out this design. There's too many variables to consider without something concrete to work from and think about. I'm definitely willing to do that in order to prove that BIP-360 works in various scenarios.

jonasnick · 2025-03-24T14:28:50Z

bip-0360.mediawiki

+This design maintains compatibility for [https://github.com/bitcoin/bips/blob/master/bip-0114.mediawiki BIP-114]
+Taproot Merkelized Alternative Script Tree (MAST) merkle root in the commitment, which makes P2QRH a
+quantum-resistant version of Taproot transactions. The TapScript itself must however be provided in the witness,


Did you mean to refer to BIP 341 here?

mraksoll4 · 2025-04-26T22:48:55Z

the idea itself is quite simple, we have a separate address, a separate storage of keys, a double signature. In the case of old wallets ignore the new pq signature when verify, new ones read both.

but we will most likely have to forgot about derevation logic in new address type atleast for now, yes it will make the wallet file thicker, and the blockchain will become thicker. But it will provide additional security, also do not forget that unlike the same ETH, Bitcoin blockchain can be kept on HDD without problems and pruned, when ETH only requires super fast SSD.. and there pq signatures will be real problem.

jonatack · 2025-05-27T20:53:30Z

@cryptoquick any update here?

cryptoquick · 2025-05-27T20:55:44Z

@jonatack I'm waiting for Ethan to finish his rewrite before adding new changes. Please bear with us, the wait will be worth it!

cryptoquick · 2025-06-23T10:30:55Z

@EthanHeilman has joined the chat.
cryptoquick#21
It's a big change, so I recommend reviewing the PR separately.
Any suggestions, especially answers to the questions / open checkmarks would be helpful, thanks!

* Rewrote rationale * Fix bolded principles * Actually fix bold * Updates to talk about signature + public key size rather than just signature size * Took a pass over rationale * Started work on specification * Adds example tapscript hybrid signatures * More work on the specification * Cleans up TODO * Fixing grammar, other minor changes * SHL --> SLH * Apply suggestions from code review Co-authored-by: Hunter Beast <[email protected]> * Adds discussion of SQIsign * Fixes broken llink to libbitcoinpqc Co-authored-by: Hunter Beast <[email protected]> * Fixes writing in SQIsign section Co-authored-by: Hunter Beast <[email protected]> * Add rational section on big signatures and public keys * Fixes typos * Adds script validation from BIP 341 * Add commas * Add design section, stack element size increase now in PQ sigs * Fixes typo * Fixes typos and formatting Co-authored-by: Hunter Beast <[email protected]> * Add authorship to readme * Add diagram of P2QRH merke tree, scriptPubKey and Witness * Remove completed todo * Add security section * Clean up wording, moves some things around * Minor rewording * Review suggestions Co-authored-by: Hunter Beast <[email protected]> * Clarified size differences * Changed header size and order * does --> doUpdate bip-0360.mediawiki Co-authored-by: Hunter Beast <[email protected]> * Add related work section * Better scale figure * Respond to review comments * remove double space Co-authored-by: Armin Sabouri <[email protected]> * Address review comments * Addressing Ademan comments * Sync source svg * Address review * Addresses review * Apply suggestions from code review Co-authored-by: Joey Yandle <[email protected]> * Update bip-0360.mediawiki Co-authored-by: Joey Yandle <[email protected]> * Update bip-0360.mediawiki Co-authored-by: Joey Yandle <[email protected]> * Addressing review comments * Addressing reviews --------- Co-authored-by: Hunter Beast <[email protected]> Co-authored-by: Armin Sabouri <[email protected]> Co-authored-by: Joey Yandle <[email protected]>

cryptoquick · 2025-07-07T15:06:10Z

The latest has been merged. This is a very different BIP now and took a lot of time and effort. We'll be making an announcement to the mailing list soon.

Thanks everyone to who reviewed, and thanks @EthanHeilman for all the help as co-author.

…P-360. (#24)

cryptoquick · 2025-07-13T15:55:27Z

I just wanted to confirm who's reviewing this BIP? I've addressed several of the previous reviewer's asks, including getting a co-author and reducing the scope of the BIP by omitting the PQC components. I do appreciate everyone's time and any review help I can get! I realize we made a lot of big changes and that will take more time to review. I just wanted to make sure everything was addressed in order to speed up the review process and hopefully get this merged.

Also, one question, would it simplify or complicate the review process if we added test vectors to this pull request? Should we wait to merge test vectors (when they're finished, which should be soon) until this PR is approved and merged? They will be available in both Rust and Python, in case that helps.

murchandamus

Thanks for the big update, it is much easier to follow and the design seems to be drastically improved. There are a number of instances in which I find naming of concepts a bit odd, especially where it needlessly deviates for concepts replicated from BIP 341.

murchandamus · 2025-07-14T20:47:49Z

bip-0360.mediawiki

+{| class="wikitable"
+|+ Output types vulnerable to long-exposure attacks on unspent addresses
+|-
+! Type !! Vulnerable !! Prefix !! Example
+|-
+| P2PK || Yes || Varies || 2103203b768951584fe9af6d9d9e6ff26a5f76e453212f19ba163774182ab8057f3eac
+|-
+| P2PKH || No¹ || 1 || 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa
+|-
+| P2MS || Yes || Varies || 52410496ec45f878b62c46c4be8e336dff7cc58df9b502178cc240e...
+|-
+| P2SH || No¹ || 3 || 3FkhZo7sGNue153xhgqPBcUaBsYvJW6tTx
+|-
+| P2WPKH || No¹ || bc1q || bc1qsnh5ktku9ztqeqfr89yrqjd05eh58nah884mku
+|-
+| P2WSH || No¹ || bc1q || bc1qvhu3557twysq2ldn6dut6rmaj3qk04p60h9l79wk4lzgy0ca8mfsnffz65
+|-
+| P2TR || Yes || bc1p || bc1p92aslsnseq786wxfk3ekra90ds9ku47qttupfjsqmmj4z82xdq4q3rr58u
+|-
+| P2QRH || No || bc1r || bc1r8rt68aze8tek87cnz4ndnvfzk6tk93jv39n4lmpu5a4yw453rcpszsft3z
+|}


Nit: There are no address standards for P2PK and P2MS, so perhaps the fourth column should be titled "Address or output script example" or similar

murchandamus · 2025-07-14T21:06:18Z

bip-0360.mediawiki

+A Long Exposure Quantum Attack is an attack in which the public key has been exposed on the blockchain for an extended
+period of time, giving an attacker ample opportunity to break the cryptography. This affects:
+
+* P2PK outputs (Satoshi's coins, CPU miners, starts with 04)


P2PK output scripts start with a push opcode, not "04". IIRC, uncompressed public keys start with 0x04, but compressed public keys start with 0x02 or 0x03 as the one in your example in the table.

This is meant to be a visual indication, and that's how they show up in the mempool explorer:
https://mempool.space/tx/0e3e2357e806b6cdb1f70b54c3a3a17b6714ee1f0e68bebb44a74b1efd512098
iirc compressed public key output types use pushbytes33.

I’m not sure why you are telling me that, when I already pointed out that uncompressed public keys start with 0x04. The points I’m raising are:

A P2PK output scripts do not start with 0x04 its starts with a push.

P2PK output scripts can either hold compressed or uncompressed, therefore the content of the push can start with 04, but only if its an uncompressed key. It’s not the case for a compressed key.

Your own example in line 99 is 2103203b768951584fe9af6d9d9e6ff26a5f76e453212f19ba163774182ab8057f3eac, which is a compressed key that starts with 0x03 and you are providing the whole script including the push opcode.

My recommendation would be to either drop "starts with 04", or to explain what exactly starts with 04, because P2PK outputs do not.

murchandamus · 2025-07-14T21:11:17Z

bip-0360.mediawiki

+Coinbase outputs to P2PK keys go as far as block 200,000, so there are, at the time of writing, 1,723,848 coins that
+are vulnerable from the first epoch in P2PK outputs alone. The majority of these have a block reward of 50 coins each,


P2PK outputs were created as recently as 2021, and the total amount of bitcoins held in P2PK outputs was 1,719,270.33902196 three days ago, so it does not seem accurate that all of these coins are held in outputs from the first epoch.

murchandamus · 2025-07-14T21:26:30Z

bip-0360.mediawiki

+and there are roughly 34,000 distinct P2PK scripts that are vulnerable. These coins can be considered
+"Satoshi's Shield." Any addresses with a balance of less than the original block subsidy of 50 coins can be considered
+cryptoeconomically incentive incompatible to capture until all of these are mined, and these addresses serve to provide
+time to transition Bitcoin to implement post-quantum security.
+
+It's for the above reason that, for those who wish to be prepared for quantum emergency, it is recommended that no more
+than 50 bitcoin are kept under a single, distinct, unused Native SegWit (P2WPKH, "bc1q") address at a time. This is
+assuming that the attacker is financially motivated instead of, for example, a nation state looking to break confidence
+in Bitcoin. Independently, this assumes that other vulnerable targets such as central banks have upgraded their
+cryptography by this time.


As mentioned before, the "Satoshi’s Shield" is argument is not convincing to me.
Satoshi’s coins are closely monitored and spending them would raise awareness immediately. Grabbing coins from some reused addresses likely would go unnoticed (or disputed) much longer. Once an attacker is able to take coins from any address, they may decide to find a number of private keys first before swiping a smaller UTXOs for a few blocks and then e.g., taking the Binance Cold Wallet and start with Satoshi’s coins after. Arguably I haven’t spent a lot of time thinking about it, but I just don’t see how it is useful for this BIP to attempt to predict the order in which an attacker would attack UTXOs and then to venture even further into the weeds by making recommendations to users about how to structure their UTXOs.

It's not trying to predict the order, it's making the observation that people with UTXOs fewer than 50 bitcoin are safer for longer. It's good, practical advice.

murchandamus · 2025-07-14T21:43:55Z

bip-0360.mediawiki

+called P2QRH (Pay to Quantum Resistant Hash). This output type is designed to support post-quantum signature algorithms
+but those algorithms will be specified in future BIPs.
+
+It is proposed to use SegWit version 3. This results in addresses that start with bc1r, which could be a useful way to


A convenient mnemonic is a poor reason to skip version 2.

Ethan has backed me up in this, you can find some of his reasoning here:
cryptoquick#23 (comment)

Another reason to skip version 2, or bc1z, is it would be ideal for use with BitZip if that ever works out.

I know it is a bit strange. There is a comment way back on the BIP where I also objected to it, but the idea has grown on me. That said, it is proving one of the most controversial aspects of P2QRH and I wouldn't fight for inclusion if it continues to be controversial. I want to write up a mailinglist post about it as I think treating SegWit versions as flags might be something we should consider for all new output types.

murchandamus · 2025-07-15T00:24:14Z

bip-0360.mediawiki

+P2QRH outputs provide the same tapscript functionality as P2TR outputs, but without the quantum-vulnerable key-spend
+path. This enables users, exchanges and other hodlers to easily move their coins from taproot outputs to P2QRH outputs


Suggested change

P2QRH outputs provide the same tapscript functionality as P2TR outputs, but without the quantum-vulnerable key-spend

path. This enables users, exchanges and other hodlers to easily move their coins from taproot outputs to P2QRH outputs

P2QRH outputs provide the same tapscript functionality as P2TR outputs, but without the quantum-vulnerable key path.

This enables users, exchanges and other hodlers to easily move their coins from taproot outputs to P2QRH outputs

murchandamus · 2025-07-15T00:29:43Z

bip-0360.mediawiki

+scripts into its design. P2QRH inherits this capability from taproot because P2QRH is simply taproot with the key-spend
+path removed. As a result, P2QRH does have the taproot internal key or tweak key, instead P2QRH commits directly to the


Suggested change

scripts into its design. P2QRH inherits this capability from taproot because P2QRH is simply taproot with the key-spend

path removed. As a result, P2QRH does have the taproot internal key or tweak key, instead P2QRH commits directly to the

scripts into its design. P2QRH inherits this capability from taproot because P2QRH is simply taproot with the key path

removed. As a result, P2QRH does not have the taproot internal key or tweak key, instead P2QRH commits directly to the

murchandamus · 2025-07-15T00:30:23Z

bip-0360.mediawiki

+
+Below we attempt to summarize some of the ideas discussed on the Bitcoin Bitcoin-Dev that relate to P2QRH.
+
+The idea of a taproot but with the key-spend path removed has been discussed a number of times in the Bitcoin community.


Suggested change

The idea of a taproot but with the key-spend path removed has been discussed a number of times in the Bitcoin community.

The idea of a taproot but with key path spending removed has been discussed a number of times in the Bitcoin community.

murchandamus · 2025-07-15T00:32:40Z

bip-0360.mediawiki

+
+The idea of a taproot but with the key-spend path removed has been discussed a number of times in the Bitcoin community.
+[https://gnusha.org/pi/bitcoindev/CAD5xwhgzR8e5r1e4H-5EH2mSsE1V39dd06+TgYniFnXFSBqLxw@mail.gmail.com/ OP_CAT Makes Bitcoin Quantum Secure]
+notes that if we disable the key-spend in taproot and activated CAT [https://github.com/bitcoin/bips/blob/master/bip-0347.mediawik BIP-347],


Here and everywhere: "key path (spending)" instead of "key-spend" or "key-spend path".

Thanks for point that out. I should have checked I was maintaining a consistent terminology.

I was trying to use key-spend path to refer to the capability and key-spend to refer to the action.

BIP-0342 uses

taproot spend to mean key-spend

script path spend to mean script-spend

I could use the language in BIP-0342, but it seems confusing to say we disable the taproot spend in pay-to-taproot. Rereading BIP-0342, I know realize that it is using path as shorthand for merkle path.

No one seems to use this "taproot spend" language anymore.

We could use:

script path spend and key path spend. "taproot but with the key path spend removed..."

script-spend and key-spend. "taproot but with the key-spend capability removed..."

script spend and key spend (no hyphen).

Do you have any preference?

I was unaware that BIP 342 was not consistent with BIP 341 in that regard, but I would consider "key path spend" and "script path spend" to be the established terms.

murchandamus · 2025-07-15T00:34:31Z

bip-0360.mediawiki

+attestation was later discarded when Ethan Heilman joined as co-author, whom I'm incredibly grateful to for
+transforming this BIP into something far more congruent with existing Bitcoin design. Thank you as
+well to those who took the time to review and contribute, including Jeff Bride, Adam Borcany, Antoine Riard, Pierre-Luc
+Dallaire-Demers, Mark Erhardt, Joey Yandle, Jon Atack, Armin Sabouri, Jameson Lopp, Murchandamus, and Vojtěch Strnad.


Murchandamus and Mark Erhardt are the same person

cryptoquick added 2 commits September 27, 2024 10:05

QuBit - P2QRH spending rules - Final draft before submitting upstream…

1fa2485

… to bitcoin/bips

Add pqNTRUsign to .typos.toml.

6f67a3d

cryptoquick marked this pull request as draft September 27, 2024 18:18

EthanHeilman reviewed Sep 27, 2024

View reviewed changes

bip-p2qrh.mediawiki Outdated Show resolved Hide resolved

EthanHeilman reviewed Sep 27, 2024

View reviewed changes

bip-p2qrh.mediawiki Outdated Show resolved Hide resolved

EthanHeilman reviewed Sep 27, 2024

View reviewed changes

bip-p2qrh.mediawiki Outdated Show resolved Hide resolved

jonatack added the New BIP label Sep 27, 2024

jonatack reviewed Sep 27, 2024

View reviewed changes

bip-p2qrh.mediawiki Outdated Show resolved Hide resolved

cryptoquick force-pushed the p2qrh branch 2 times, most recently from b6ed2c3 to d6d15ad Compare September 28, 2024 18:01

kingcathy23 approved these changes Sep 28, 2024

View reviewed changes

cryptoquick force-pushed the p2qrh branch 2 times, most recently from 0608cc1 to a595bf0 Compare September 28, 2024 18:12

cryptoquick requested review from jonatack and EthanHeilman September 28, 2024 18:55

cryptoquick force-pushed the p2qrh branch from a595bf0 to eae4707 Compare September 29, 2024 07:22

luisschwab mentioned this pull request Sep 29, 2024

Tópicos Out/24 BitDevsBSB/BitDevsBSB#11

Closed

cryptoquick force-pushed the p2qrh branch 2 times, most recently from 19d4592 to 7f4456d Compare September 30, 2024 11:42

jonatack reviewed Sep 30, 2024

View reviewed changes

bip-p2qrh.mediawiki Outdated Show resolved Hide resolved

QuBit - P2QRH

d83c29d

cryptoquick force-pushed the p2qrh branch from 7f4456d to d83c29d Compare October 1, 2024 01:03

jlopp and others added 2 commits October 2, 2024 10:30

typo fix

ae0936a

Merge pull request #13 from jlopp/patch-3

d89b7c5

typo fix

jonatack added the PR Author action required Needs updates, has unaddressed review comments, or is otherwise waiting for PR author label Oct 9, 2024

luisschwab mentioned this pull request Oct 14, 2024

Novembro 2024 saopaulobitdevs/saopaulobitdevs.org#38

Closed

QuBit - P2QRH spending rules

b4c329b

cryptoquick force-pushed the p2qrh branch from a3af198 to b4c329b Compare October 21, 2024 17:39

Correct inconsistencies in commitment and attestation structure. Swit…

61faee6

…ch from merkle tree commitment to sorted vector hash commitment.

Update descriptor format.

e6e7207

cryptoquick force-pushed the p2qrh branch from aa70850 to e6e7207 Compare March 18, 2025 15:48

murchandamus reviewed Mar 21, 2025

View reviewed changes

jonasnick reviewed Mar 24, 2025

View reviewed changes

This comment was marked as spam.

Sign in to view

bitcoin deleted a comment from masoudahg00 Apr 5, 2025

murchandamus mentioned this pull request May 7, 2025

BIP 443: OP_CHECKCONTRACTVERIFY #1793

Merged

This comment was marked as off-topic.

Sign in to view

This comment has been minimized.

Sign in to view

This comment was marked as duplicate.

Sign in to view

Update changelog and acknowledgements with the new developments in BI…

77dbeee

…P-360. (#24)

murchandamus reviewed Jul 15, 2025

View reviewed changes

Fix duplicate acknowledgement

44778df

bitcoin deleted a comment from Noxcheborz Jul 16, 2025

		Coinbase outputs to P2PK keys go as far as block 200,000, so there are, at the time of writing, 1,723,848 coins that
		are vulnerable from the first epoch in P2PK outputs alone. The majority of these have a block reward of 50 coins each,

		P2QRH outputs provide the same tapscript functionality as P2TR outputs, but without the quantum-vulnerable key-spend
		path. This enables users, exchanges and other hodlers to easily move their coins from taproot outputs to P2QRH outputs

		scripts into its design. P2QRH inherits this capability from taproot because P2QRH is simply taproot with the key-spend
		path removed. As a result, P2QRH does have the taproot internal key or tweak key, instead P2QRH commits directly to the


		Below we attempt to summarize some of the ideas discussed on the Bitcoin Bitcoin-Dev that relate to P2QRH.

		The idea of a taproot but with the key-spend path removed has been discussed a number of times in the Bitcoin community.

	The idea of a taproot but with the key-spend path removed has been discussed a number of times in the Bitcoin community.
	The idea of a taproot but with key path spending removed has been discussed a number of times in the Bitcoin community.

BIP-360: QuBit - Pay to Quantum Resistant Hash #1670

Are you sure you want to change the base?

BIP-360: QuBit - Pay to Quantum Resistant Hash #1670

Conversation

cryptoquick commented Sep 27, 2024

Uh oh!

Uh oh!

Uh oh!

Uh oh!

jonatack left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

jonatack commented Oct 1, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jonatack commented Oct 21, 2024

Uh oh!

jonatack commented Mar 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

cryptoquick commented Mar 13, 2025

Uh oh!

cryptoquick commented Mar 18, 2025

Uh oh!

cryptoquick commented Mar 18, 2025

Uh oh!

QbitsCode commented Mar 19, 2025

Uh oh!

cryptoquick commented Mar 20, 2025

Uh oh!

murchandamus left a comment

Choose a reason for hiding this comment

Uh oh!

cryptoquick commented Mar 21, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This comment was marked as spam.

Uh oh!

This comment was marked as spam.

Uh oh!

mraksoll4 commented Apr 26, 2025

Uh oh!

This comment was marked as off-topic.

jonatack commented May 27, 2025

Uh oh!

cryptoquick commented May 27, 2025

Uh oh!

This comment has been minimized.

This comment was marked as duplicate.

cryptoquick commented Jun 23, 2025

Uh oh!

cryptoquick commented Jul 7, 2025

Uh oh!

cryptoquick commented Jul 13, 2025

Uh oh!

murchandamus left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

murchandamus Jul 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jonatack left a comment •

edited

Loading

jonatack commented Oct 1, 2024 •

edited

Loading

jonatack commented Mar 13, 2025 •

edited

Loading

murchandamus Jul 15, 2025 •

edited

Loading

EthanHeilman Jul 16, 2025 •

edited

Loading