ETFs and the case for directly holding cryptocurrency

For the majority of time blockchains have been around, holding cryptocurrency necessarily involved jumping through hoops and doing business with a Wild West of unknown, unregulated fintech startups that specialized in providing on/off-ramps to digital assets. Some of those emerging startups grew into household names. Others spectacularly imploded in security incidents, insider fraud or compliance scandals, taking customer balances with them— Mt Gox in 2014 and more recently FTX and Celsius in 2022. With each bull market generating outsize returns far what is available from most asset classes, this pattern of blatant fraud and security negligence would pose a unique dilemma for the next group of early-adopters contemplating digital assets. On the one hand, on-boarding with one of these platforms could unlock significant returns if the asset class continues its stratospheric rise. On the other hand, it could also result in massive losses due to operational failure of the platform, as distinct from the unavoidable investment risks from the asset losing value.

This calculus was radically altered by the 2024 introduction of Bitcoin ETFs. It would not be long before similar offerings appeared for Ethereum, Solana and Ripple. Today it is possible to trade major cryptocurrencies through garden-variety brokerage accounts that most investors already have access to. (Unless of course their brokerage turns out to be an ideologue: Vanguard decided to patronize its customer base by holding out nearly two years before granting access to these “dangerous” investment options.) This poses a question: when does it make sense to hold the underlying asset directly over holding the ETF?

Variants of this existed starting with the very first, wildly successful gold ETF, GLD by State Street in 2004. Does one stack gold coins and bullions in a vault— as late-night infomercials targeted at a certain segment urge— or is holding GLD in an investment account a better route to the same outcome?

It turns out it is easier to answer this question for digital assets. There are only a handful of situations where directly holding cryptocurrency makes sense—and in those cases, it is imperative that investors capture the optionality provided by being able to operate on the blockchain. But most retail investors under most circumstances are better off seeking exposure through an ETF.

This essay is not investment advice or even personal opsec advice on appropriate safe-keeping of digital assets. Instead we posit a hypothetical investor who has already decided to hold some digital asset in their portfolio. Their decision comes down to purchasing that cryptocurrency directly through a VASP (“virtual asset service provider”) or through an ETF wrapper. This argument is also neutral on the question of self-custody versus parking funds at the VASP. Digital assets industry has come a long way since the Mt Gox implosion or even the FTX fraud. That includes making peace with the concept of regulation, accepting as the cost of mainstream acceptance and redirecting efforts to shape the exact contours of upcoming legislation instead of avoiding it altogether. Being regulated in some capacity—NYDFS BitLicense, bank-charter or even the patchwork of 50 state money-transmitter licenses— completing SOC2 audits and publishing financials are now table-stakes. Even US regulatory frameworks are starting to catch up with 2025 signing of GENIUS bill and ongoing work on CLARITY for market structure. (On the other side of the pond, the European Union was ahead of the game as usual with MiCA.) There are still material differences in risk profile between trusting one of these companies to hold funds versus taking on that responsibility for oneself, but those trade-offs are very particular to each situation. It is a function of the third-party custodian, the opsec level of the investor, their personal comfort level with attendant responsibility and even the type of asset in question, because it determines the hardware/software options suitable for an individual or enterprise to implement self-custody.

We start by focusing on the differences between the two options, focusing on additional avenues that are enabled by direct holding that are not possible with an ETF. In the discussion that follows, we only assume the investor has access to some digital asset platform for buying and selling cryptocurrency. This could be a centralized exchange where on-boarding requires KYC or a permissionless DeFi platform mediated by smart-contracts. Where custody model makes a difference, the distinction is noted.

Unequivocal advantages:

  • 24/7 trading. Cryptocurrency markets operate around the clock. ETFs only trade during market hours 9:30-4PM. Additional extended trading is available to investors who opt-in, but “extended” does not mean around-the-clock. There is also much less liquidity available during those times and no guarantee the ETF is tracking the underlying asset accurately.
  • Access to a much larger selection of digital assets. ETFs exist for only a handful of the blue-chip currencies, those with the largest market-capitalization. Even as issuers race to the tail (or bottom?) of the distribution to market Dogecoin ETFs, they have an uphill battle trying to keep up with the proliferation of copy-cat blockchains.
  • Using cryptocurrency for payments. This can be done either by directly transferring the asset to another blockchain address or participating in more complex layer-2 solutions such as the Lightning Network for Bitcoin.
  • Participating in on-chain distributed applications (dapps) such as prediction markets or lending pools.
  • Commonly zero custody fees. Securing digital assets is one of the most expensive and operationally challenging aspects of running a cryptocurrency platform. Yet most exchanges offer basic omnibus custody—where all customer funds are pooled together into a single logical wallet— as a free service, in the expectation that trading fees will subsidize that cost. By contrast an ETF charges a management fee taken out of the assets every year.
  • Exemption from wash-sale rules. There is a good reason why December sees a spike in trading: investors can manufacture artificial losses (to reduce tax liability) by selling positions that have declined in value and buying the identical position back. Net effect: portfolio remains the same but now there exist “losses” to offset capital gains for the same tax year. This works because bitcoin and other cryptocurrencies are currently classified as property rather than as securities in the US. That same trading pattern would not work for equities, including ETFs that invest in cryptocurrency. Extensive IRS rules around wash-sales discourage economically meaningless trading. These rules apply even across multiple accounts, such as selling in an investment account and buying back the same asset in a 401K. No such restrictions apply when holding digital assets directly.

Conditional advantages— these may or may not obtain, depending on particulars:

  • Censorship resistance. True for self-custody, not necessarily true when funds are held by a centralized platform. It is increasingly common for VASPs to implement anti-money laundering (AML) including complying with the OFAC sanctioned blockchain address list. Attempting to send funds to one of these addresses will be rejected. Customers tempted to work around that by first withdrawing to a personal wallet and then routing it to a sanctioned address may be surprised to receive a brief, cryptic email from the compliance department indicating that their account is being closed.
  • Seizure resistance. Same situation; only holds for self-custody. Most reputable centralized exchanges will freeze/seize customer funds in response to a law enforcement request.
  • Faster access to funds. Again true for custody, may not always hold when digital assets are parked at a centralized exchange. Most banks and brokerages have risk limits on funds movement, such as maximum amounts that can be wired in one transaction. In theory a cryptocurrency platform could allow clients to send 100% assets to a personal wallet or a competing platform but this is not a given. In fact, because blockchain transfers are irreversible, these platforms have even more stringent risk controls to avoid losses for the customer. Because that attempt to withdraw 100% of funds looks awfully like an account takeover or perhaps a romance-scam from which the customer will never be able to recover. (Aside: the question of liability for such losses has never been formally legislated. Nor is there much in the way of case law because most disputes are forced into private arbitration. VASPs will always take the stance that it was the customer’s own actions which resulted in the loss, and therefore the customer is 100% responsible for losses.)

Looking at the disadvantages:

  • High trading fees. VASPs routinely charge 0.50% to execute a single order— and recall investors must pay this toll in both directions buying and selling in order to realize gains in dollars. By comparison, most US investors can trade ETFs for free or at worst for nominal fees on the order of cents. As noted earlier, ETFs do charge a yearly management fee which eats into returns. But competition between providers naturally leads to fee compression. Nowhere is this illustrated as dramatically as with Bitcoin ETFs: even before the first day of trading, providers were racing to outdo each other by announcing drastic reductions in management fees, including a handful that promised to charge exactly zero fees for the first year.
  • Slippage, especially for retail investors. VASPs aimed at consumers include an additional spread on top of the actual cost of the asset being purchased, especially for “buy now” type experience which abstracts away the actual order book. This is not disclosed as a trading fee and can result in execution at prices substantially differing from the prevailing market value.
  • Inefficient execution. US brokerages are free to route customer orders to different execution venues (often with surprising incentives, as in the case of pay-for-order-flow practice highlighted during the 2021 GameStop incident) but they are subject to the FINRA best-execution rule. Among other things the rule calls for due diligence in finding the most favorable— to the customer— market for fulfilling the order and prohibits introducing unnecessary middle-man . VASPs are subject to no such restriction and can have private agreements with liquidity providers that results in customers getting suboptimal execution.
  • Assumption of custody risk. Security risks apply regardless of whether the investor opts for self-custody or outsources that problem to the VASP. In the former case, the investor becomes responsible for key management: setting up a hardware wallet, making sure keys are backed up offline, carefully managing withdrawals to make sure funds are not sent to the wrong address. In the latter case, the customer is still on the hook for losses when there is an account takeover or they are socially-engineered by a scammer to voluntarily transfer funds to an address controlled by that crook. While it is possible to transfer equities such as ETFs to another brokerage account, this is a much more involved process, not to mention that it requires the crook to successfully onboard with that institution— a much higher bar than generating a new wallet address.
  • Limitations for tax-advantaged accounts. It is difficult to hold cryptocurrency directly in an individual retirement account, such as IRA or self-employed 401K. No such constraints apply to holding an ETF.
  • Inheritance complications. ETFs held at a broker have straightforward mechanism to transfer ownership to the named beneficiary. That is a mandatory consequence of the Uniform TOD Securities Registration Act in the US; it is not an optional feature for financial institutions to compete on. Only a handful of VASPs allow designating a beneficiary; most require falling back on the probate process. Self-custody makes it far more tricky. Absent advanced planning to make wallet credentials or seed-phrase backups accessible to heirs, the assets can become completely unrecoverable.

Given this background, the original question can be reframed this way: Under what conditions will the advantages of direct ownership outweigh the complications? The answer for the typical American investor with long-term horizon is: rarely.

Thrilling as 24/7 trading sounds, the adrenaline rush is lost on retail investors who are not day-trading or hoping to jump on the latest memecoin release at 4AM on a weekend. These investors will gravitate to bitcoin, ethereum and similar major chains that are already well-served by ETFs. ETF coverage today extends to almost 75% of the total market-capitalization of all digital assets. What remains on the margins are L1 assets with high-volatility and low liquidity, the equivalent of penny stocks.

Similarly this investor persona has no ax to grind with the financial system in general, no ideological fixation to pay for their cup of coffee with Lightning in some grand gesture of protest directed at The Man. They are unlikely to have Metamask installed in their browser and funded with mainnet ETH, ready to interact with Web3 applications.

As for censorship resistance or the fear of arbitrary asset seizure, that is extremely relevant—in a third-world banana republic without the rule of law, where the faction in power can use the financial system to exact revenge on the politically disfavored group. In fact, given that such regimes also have strict capital controls and rapidly depreciating currency due to misguided monetary policies beholden to the autocrat in charge, bitcoin checks all the boxes as an escape hatch. That narrative becomes much less relevant in America or most of Western Europe, notwithstanding alarmist rhetoric from certain quarters that would have been very familiar to Richard Hofstadter who spoke of “the paranoid style in American politics” more than 50 years ago. Unlike the prototypical banana republic, the United States does not—generally speaking— have a history of randomly confiscating assets from broad swaths of its citizenry as a routine corollary to regime change.

To be clear, there are very legitimate concerns about existing rules that grant law enforcement too much discretion, as in the guilty-until-proven-innocent model behind asset forfeiture. There is also historical precedent of the US financial system being weaponized to exact revenge on persona non grata; politically exposed individuals have found themselves in the cross-hairs of the IRS or Treasury. In fact the cryptocurrency industry itself has earned a rightful claim to the paranoid style after being singled out for debanking during Operation Chokepoint 2.0. Incidentally, self-custody would have been of no help in that well-documented attempt to jawbone an entire politically-disfavored sector: the chokepoint in question involved access to old-fashioned fiat dollar rails. SaaS vendors and employee salaries all need to be paid in dollars, not blockchain transfers. The more general point stands: neither political activists championing controversial causes nor employees of cryptocurrency startups are representative of the “average investor” contemplating a foray into digital assets. The specter of Big Government randomly seizing the family nest egg is not a that resonates for most investors in Western countries. (It is also a logically inconsistent threat model: if a government has lost all respect for private property rights, surely they can also seize land, housing and other tangible assets that can not be spirited away to the blockchain realm.)

That leaves a narrow but highly defensible set of circumstances for the blockchain version of amassing gold bullions:

  • Residing in jurisdictions without the rule of law, where arbitrary capital controls and extra-judiciary asset-seizure is a realistic threat.
  • Investing in high-volatility, low-liquidity tail-assets for which no ETF exists or is likely to exist before the initial hype-and-crash dynamic common to those assets has already played out.
  • Transacting on-chain, for example making peer-to-peer payments or engaging with Ethereum dapps.
  • Frequent trading including off-market hours, weekends and holidays.
  • Complex tax situations when loss-harvesting from declining positions— the consolation prize when number did not go up— is important.

CP

Reluctant enforcers: certificate authorities as malware police

Learning the wrong lessons from Internet Exploder [sic]

Previous posts have alluded to the role certificate authorities play— or at least are expected to play when operating effectively— in response to discovery of digitally signed malware. Part of the bargain for inclusion in the Windows code-signing ecosystem is that CAs have an obligation to revoke code-signing certificate known to have signed malicious code. This is not exactly a new, onerous condition that MSFT has foisted on certificate authorities in a bid to raise the bar. (Unlike the way Chrome monopoly was leveraged effectively to compel CAs to adopt certificate transparency, after they had been operating for decades with no such requirement.)

The idea that CAs can be enlisted to “police” the third-party software ecosystem on Windows is almost as old as the history of Authenticode. In 1996, Seattle-area developer Fred McLain decided to make a point about the danger of ActiveX controls, by writing one subversively named “Internet Exploder” [sic] riffing on the name of the MSFT browser and signed it using an Authenticode certificate from VeriSign. By modern standards, it was a measured, responsible proof-of-concept: when the control executed in a web browser, it initiated a shutdown of the PC. Nothing particularly destructive or irreversible. MSFT, stuck at the nadir of its pre-Trustworthy Computing dark-ages approach to security, was not amused. Neither was VeriSign, which promptly revoked the certificate on the grounds of breaching the subscriber agreement, sparing Microsoft any additional work or further embarrassment— thus initiating a long-running tradition of conscripting reluctant third-parties into policing the software ecosystem.

From a narrow perspective, the intervention “worked:” because Authenticode involves mandatory revocation checks, that particular ActiveX control would be flagged as untrusted and could no longer be executed. Never mind that the broader point this developer tried to make was completely missed: namely, running native code downloaded from random websites without any semblance of sandboxing is a Bad Idea™. ActiveX was a certifiably bad idea for many reasons beyond security: native code was necessarily OS and platform dependent. Even viewed as typical, knee-jerk Redmond reaction to the peril of portable Java applets in the browser— “write once, run anywhere” Sun promised, and how exactly did that turn out?— the concept made no sense when MSFT was hawking multiple operating systems (Windows 95/98 and NT4, with different kernels and significant API differences) with the “favored” OS shipping on multiple hardware architectures: Intel x86, DEC Alpha, MIPS and PowerPC.

Relics of the ActiveX trust model

While ActiveX was quickly relegated to two niches—the backwaters of enterprise “line of business” applications and the far more vibrant ecosystem of malware development— and eventually put out to pasture, its precedent of equating “signed” with “trusted” would remain a fundamental tenet of Windows. Part of the reason is the open ecosystem: unlike mobile devices which are designed from day-one as locked down appliance with centralized control over app distribution— often by multiple actors vying for influence, such as Google vs Samsung vs T-Mobile— the PC is an open platform. To this day, it is not uncommon for legitimate Windows applications to be downloaded and installed from third-party websites, an act of “side-loading” that would be considered borderline irresponsible and dangerous on Android. Without a single app-store curating selections and keeping out bad actors, trust decisions require a correspondingly open, distributed solution. Authenticode is one piece of the puzzle. Having an ecosystem of CAs trusted to issue code-signing certificates gives developers a choice of providers for sourcing their credential.

But implicit in the Authenticode model is an unstated assumption that trust is entirely a function of publisher identity. That knowing the provenance of an application is sufficient to determine whether it is safe to run that code. That premise is suspect, even in an ideal world where we posit:

  • CAs are infallible and will never issue a code-signing certificate to the wrong person
  • Software publishers have perfect opsec around key-management and will never allow a threat actor to misuse their private key.

Even under these wildly unrealistic assumptions— easily debunked by contemporary real-life examples from that era— this model breaks down. It places the burden on consumers to become experts in the competitive dynamics of the software industry. Authenticode can answer the question of who published the software, but it can not distinguish between a reputable vendor and a fly-by-night operation. Who is to say the reputable vendor will not be tempted into bundling some spyware for a price or that unknown garage-company with the strange name one day becomes the most valuable company on Earth? Brand recognition only goes so far. At best it stacks the deck towards established incumbents with familiar names, casting suspicion on software from upstarts seeking to challenge the status quo. “What kind of person names their company Google?” one can imagine a Windows user asking, while considering whether to install the Google toolbar extension for IE back in 2000.

Creative justifications for revocation

For all of the dubious premises behind equating code-signing with trust in software, it pales in comparison to the conceptual muddle behind leveraging revocation to remove that trust:

1. Revocation is not a precision instrument: it does not simply blacklist one binary, it invalidates all code signed using that certificate after the effective date of revocation. (Third-party trusted timestamps are used to establish the signing time; otherwise a malicious signer could back/future-date signatures.) If a vendor accidentally signs a back-doored version once in the middle of a sequence of ten legitimate releases, there is no way to only revoke that single instance. At best one can specify a revocation time to shield past releases; anything after the malicious sample will still become collateral damage. There is no way to achieve the opposite effect and preserve validity of latest versions while revoking older ones. That seems reasonable when focusing on the threat model of key-compromise. The implicit assumption is, if an attacker could sign using a key once, they can do so again in the future. Strangely that is less likely to hold today when code-signing certificates are required to be held in cryptographic hardware, creating a new failure mode: an attacker can get temporary access to the code-signing infrastructure to sign some unauthorized code but they can not extract the private key and walk away with it for indefinite access.

2. There is no global “do-not-issue” list that is the equivalent of the TSA No-Fly list for digital certificates. One CA revoking a developer certificate for creating malware has no effect on whether the same developer can provision another valid Authenticode certificate from another CA to sign the exact same offending code. (Or, as in the recent case of short-lived Azure Code Signing certificates appearing on malware, to obtain them from the same issuer.)

3. Stepping back: revocation was never intended as a policing mechanism on the behavior of software publishers. Let’s look at the revocation reasons standardized in RFC 5280. This document lists a closed-ended set of choices the issuer can state as the justification. This reason appears in the CRL entry and OCSP response. These are precisely:

CRLReason ::= ENUMERATED {
unspecified (0),
keyCompromise (1),
cACompromise (2),
affiliationChanged (3),
superseded (4),
cessationOfOperation (5),
certificateHold (6),
-- value 7 is not used
removeFromCRL (8),
privilegeWithdrawn (9),
aACompromise (10) }

Nowhere in this list is an option for “behaved badly” or “wrote malware.” Such scenarios were historically outside the purview of PKI. Code-signing certificates are statements of identity. They are not merit badges awarded for ethical standards or excellence in software engineering. When McLain signed a malicious ActiveX control to make a point about Internet Explorer, he did not impersonate anyone, make false representations to VeriSign or deliberately divulge his private-key for others to misuse.

CAs commonly opt for “privilegeWithdrawn” as the putative reason when certificates are revoked for malware authorship. But historically that reason code meant something different. X509 distinguished between identity assertions and privilege assertions, with the latter encoding specific (as in, not unique) information about a person such as being employed by a particular company. This was envisioned as the grand Privilege Management Infrastructure counterpart to its better-known brethren PKI. PMI motivated the introduction of new reason codes #9 and #10. “aaCompromise” is the logical parallel to “caCompromise” but “privilegeWithdrawn” is something unique, with no equivalent in identity analog. It refers to a privilege contained in the certificate no longer applying to the grantee. With the benefit of 30 years, it is safe to say this grant vision of PMI went nowhere. In theory identity certificates can encode privilege attributes, but Authenticode never made use of that. There was no “virtuous developer” privilege to withdraw begin with.

Authentication vs authorization

There is a fundamental category error in using revocation to combat malware: certificates are intended for authentication. Whether a piece of code is allowed to execute is a question of authorization. Trying to deny authorization by withholding authentication is akin to combating crime by having the DMV deny driver’s licenses to people convicted of fraud, on the theory that it will prevent them from opening additional bank accounts to perpetrate more fraud.1 An Authenticode certificate is not a guarantee of developer integrity: if Bernie Madoff had been sentenced to writing Windows apps as part of his penance, nothing in the Authenticode issuance policies would stop a CA from issuing him a certificate. Given that CAs are not in the business of running background checks on software publishers as a gating factor prior to issuing credentials, it is strange to enlist them into an enforcement role after the fact when their customer turns out not to be an upstanding citizen.

In the case of Windows applications, there are already multiple authorization systems: SmartScreen for binary reputation, Windows Defender malware scanning and WDAC policies for enterprise enforcement. There is no reason to burden the identity system with solving emergent problems belonging to a higher layer. Tellingly, this is not done for TLS certificates: CAs are not obligated to revoke server certificates when a website is caught hosting scams. Those CAs have significant leverage: loud browser warnings for unencrypted traffic have made possession of a valid TLS certificate table-stakes for web presence. Yet we do not conscript CAs into policing the web.

Code Signing Baseline Requirements— the policies and procedures Authenticode CAs are expected to follow— solidified this responsibility on CAs without addressing the category error. 2024 CSBR changes require CAs to revoke certificates that signed “Suspect Code” within 24 hours While it is difficult to argue with demanding more accountability from CAs. CSBR are a contractual agreement between the platform owner and an open ecosystem of CAs hoping for a slice of the pie from issuing code-signing certificates. Microsoft can impose its terms on that captive audience, but contractual obligations are not X509 semantics.

CP

1 This pattern would repeat in the early 2000s with “Kids Passport,” a feature in Microsoft’s online identity platform for complying with COPPA requirements, a precursor to controversial age verification requirements being contemplated today. If a user was known to be underage, the centralized authentication system would refuse to log them into certain Microsoft sites—a clear example of denying authorization by denying authentication.

Windows revocation providers: beyond platform trust

A malleable operating system

Windows often gets a bad rap for pulling in other Microsoft technologies and services for providing functionality—think Edge defaulting to Bing. Yet the underlying design of the operating system has been historically modular to a fault, containing an abundance of extensibility hooks. These are interfaces where third-party software can augment or even entirely replace built-in operating system functionality. Common examples from the security realm include:

  • Anti-malware scan interface for leveraging third-party antivirus solutions
  • Credential providers, to allow logging into the OS using a protocol anchored in any identity provider, such as a cloud service.
  • Key Store Providers for adding new implementations of cryptographic algorithms, such as post-quantum signatures that did not ship out-of-the-box
  • Password filters for enforcing password policy and synchronization with external identity systems.

One of the lesser-known extensibility mechanisms is the ability to extend certificate verification logic by providing custom revocation providers. Windows has historically shipped a robust certificate management engine starting in the early 2000s, featuring support for the two standardized ways of revocation checking:

  1. Certificate revocation lists (“CRL”)
  2. Online Certificate Status Protocol (“OCSP.”)

But the platform also exposes a generic hook for anyone to bring their own revocation provider. At a high-level, revocation is structured as a cascade of providers in predetermined priority order. Each provider is structured as a DLL that gets loaded in process for the application invoking the X509 validation process. When CertVerifyRevocation API is called, it queries the available providers in order about the status of the given certificate. Every provider can respond in one of three ways:

  • State that the certificate is still valid. In this case the revocation check is considered complete and no other providers are queried.
  • State that it is revoked and should no longer be trusted. This also terminates the process and returns control to the caller.
  • Throw up its hands and proclaim ignorance about the state of this certificate. In that case, the process continues by querying the next provider in the sequence.

Caveats

Before discussing some applications of a custom revocation provider, it is important to cover some limitations. The most significant one is that some applications are not using the Windows cryptography API for certificate validation. Chrome and Firefox are notorious offenders in this regard, bypassing the platform capabilities in favor of their own home-brew (but at least cross-platform consistent) trust management logic for validating server TLS certificates.

The second limitation applies even when applications are “well-behaved” and invoke the platform API for trust management. Revocation checks only happen after chain building has succeeded. If a leaf certificate does not chain up to a known trust anchor, has expired or any number of other chain validity criteria fails— intermediate CA does not have the right EKU for this leaf— the process stops early. At that point, revocation checks become moot because that certificate will never be considered valid.

Finally there is the possibility that an application specifically opts out of revocation checking in the way it calls the platform API. (Note this is different from requesting offline revocation checking to avoid network latency. In that case, the system will still execute the same steps of querying providers in sequence while passing along the request to limit checks to offline sources. Of course there is no way of enforcing this— a provider can disregard the offline flag and still perform blocking network I/O.)

Use-cases

1. Supplying missing revocation status

While the above caveats seem to imply that a custom revocation provider can only reduce trust in a certificate, this is not necessarily the case. If the provider is registered to execute first, it can preempt the answer that would have been returned from the built-in Windows engine. That means in particular that it can return “not revoked” for a certificate that has in fact been revoked. It’s difficult to imagine a realistic scenario where that would actually be useful or improve security. But there is a different use-case where preempting the built-in provider makes sense: when the standard revocation checking mechanisms are not available.

Examples include:

  • The certificate has no CRL Distribution Point (CDP) or OCSP responder field present
  • That field exists but is now outdated. For example PKI administrators can change the locations where CRLs are published, but existing certificates will continue to point to the deprecated version.
  • Even if the information is accurate, revocation checks could be taking place on a system that does not have access to the designated locations. For example ADCS allows publishing CRLs to a local SMB file-share or Active Directory for clients to fetch from. While that works fine for machines located inside the corporate perimeter, those locations may not be accessible directly from external locations.

In these cases the standard CRL/OCSP path would result in an inconclusive answer to the effect that revocation information is not available. A well-designed system fails safe in that scenario: it must treat this failure mode as being equivalent to a positive revocation outcome. (Otherwise an adversary has the incentive to DDoS the revocation servers or block network traffic in hopes of trying to use a revoked credential without the destination realizing it is no longer trusted.) Absent some way of supplying a definitive “not revoked” answer, these certificates would fail validation.

A variant of this exact scenario was encountered in a high-security deployment of Active Directory Federation Services (ADFS) configured to authenticate users with client certificates. When revocation checking is enforced, ADFS would insist on revocation checks on the entire chain— not just the leaf certificate associated with the client. While those leaf certificates had perfectly functioning CRLs, the intermediate CA issuing them had no revocation mechanism. (This is not entirely uncommon, since the introduction or deprecation of an intermediate CA is an infrequent operation best handled out-of-band, instead of by publishing CRLs.) The problem is solved by a simple revocation provider that returns a predetermined result for a set of certificates identified by their thumbprint, based on registry configuration. In particular, the provider was configured to always report a clean bill of health on the intermediate CA to avoid the ADFS validation failure.

2. Post-facto name constraints

It is no secret that the infrastructure for public TLS certificates is a house-of-cards: there are over a hundred CAs distributed around the world, capable of issuing a TLS server certificate for any website— whether or not the actual owner of the website asked for it. Some of those CAs are probably well-run, with reasonable policies and procedures in place. Others may be incompetent, YOLOing their way through managing a PKI with rudimentary controls. But the worst case scenario are a handful of CAs that are known to be affiliated with or under the control of a nation state. At that point, the CA becomes a natural extension of the surveillance capabilities of that nation, able to mint certificates to intercept traffic. The main defense against such incompetence/malice is detection: Google Chrome has leveraged its monopoly position to foist certificate transparency requirements on CAs, much to their chagrin.

Interestingly the X509 standard historically had a mechanism for constraining the power of certificate authorities. Called name constraints, these are specific fields embedded in the issuer certificate that limit issuance scope. Examples of useful constraints include:

  • DNS name: Only issue for “*.mil” domains. Makes sense for a CA operated by the US Department of Defense.
  • Email address: Only issue for users with “@acme.com” email address. Applicable to an S/MIME CA operated by the Acme company.

On its face, this is a promising feature for confining potentially rogue CAs. For example a CA affiliated with the government of China should naturally be restricted to only issue for “*.cn” hostnames, corresponding to the top-level country domain for China. The restriction would prevent it from issuing a valid “google.com” certificate even if the CA wanted to. The problem is most TLS certificate authorities are completely unconstrained; historically the root programs have shied away from taking a stance on confining nation-state affiliated CAs. From the perspective of existing roots, that ship has sailed.

Luckily custom revocation providers are not bound by the diplomatic stance taken by the CA/B Forum and they need not bestow every CA under the sun with privileges to issue certificates globally. As long as the provider gets a look at the certificate, it can enforce regional boundaries. If the CA is operating within its natural TLD, the provider stays silent and allows the revocation check to fall through to the standard CRL/OCSP path. But if the CA steps out of line, it can react by reporting the certificate as revoked.

3. Generalized revocation for code-signing

Another use-case comes out of the recent malware campaign involving ScreenConnect. To recap: threat actors were leveraging ScreenConnect installers (groundhog day) signed with their own Authenticode certificate, issued by the Microsoft Entra ID CA, to get remote control over unsuspecting consumer Windows PCs.

This particular certificate authority operated by Microsoft has a pathological design pattern that renders revocation ineffective for combatting malware: it issues a series of short-lived certificates on-demand based on code-signing events, each valid for a couple of days. Imagine a defender coming across a malware sample signed by an Entra ID certificate issued to John Smith. That could be a certificate provisioned by Mr. Smith operating as the mastermind of the malware campaign or it could be a different threat actor using stolen identity documents to impersonate Mr. Smith. Either way there is good reason to believe all other code signed by this person is suspect. In these situations, the CA has an affirmative obligation to revoke those certificates. (Whether it makes sense to enlist certificate authorities in this manner to police the software ecosystem is a separate question, meriting a future post.)

That is exactly what happened to ScreenConnect in 2025. Revocation was more sporadic in the more recent campaign involving repurposed ScreenConnect installers: Microsoft appeared to act on some, but not all Entra ID certificates reported for signing malware. Not that it mattered: given the pattern of issuing multiple short-lived certificates, the John Smith character may well have dozens of other valid Authenticode certificates. Defenders can only observe some subset from the malware samples in our possession; they cannot rule out the possibility that more exist or even that John Smith still has a valid Entra ID account for obtaining future certificates.

What this calls for is a way to blacklist the entire identity instead of some particular expression of that identity embodied in a specific X509 certificate—the narrow capability CRLs and OCSP are tailored for. Custom revocation logic allows going beyond playing a whack-a-mole with serial numbers of known-bad certificates: learning the perpetrator’s identity from the distinguished name field of one certificate, we can remove trust from all certificates issued to that threat actor. That covers past, present and future issuance:

  • Past: expired certificates where signatures made during the validity period will still validate due to time-stamping
  • Present: outstanding valid certificates that have not been revoked by the issuer yet
  • Future: certificates that do not exist, but have the potential to be issued based on existing business relationship between the CA and threat actor

In fact such generalized revocation logic can even operate across certificate authorities. If Entra ID permanently blacklists this person and they have to seek Authenticode certificates from another CA, those certificates can also be reported as “revoked” by the custom provider as long as the same legal name appears in the credential.

CP

Constructing quine loops with QCC

[This is a follow-up on a previous blog post on QCC, the Quining C Compiler which is designed to transform any single-file C program into a valid quine.]

Recall that a quine is a program that can print its own source code, or more generally, perform some meaningful computation that includes its own source code as an input. One of the logical questions once we have an application for automatically constructing quines is asking whether it can be generalized to multiple programs. The objective is creating programs A and B such that:

  • A can print the source code for B
  • B functions as the mirror image and can print the source code for A

This is true in a trivial way when A and B are the same program, so there is an implied assumption of A≠B to make it worthwhile. Of course, the criteria “unequal” itself is subjective: if the two programs differ in a trivial way, the problem can reduce to the case of the single-quine. We will not try to formalize this definition of A and B being “meaningfully different” but the following examples will clarify the intent.

1. Simple quine-loop with multiple languages

Here we construct a simplified version of the well-known quine Ouroboros. limiting our cycle to two languages for simplicity: C and Python. The objective is to come up with two program A and B such that:

  • A is a valid C program that prints out the source code of B
  • B is a valid Python program that prints out the source code of A

The use of different languages here serves as the separation between A and B. 1

The construction proceeds along the same lines of using QCC in general: first we write a “prequine”— an almost-valid C program relying on a nonexistent get_self() function, assumed to return its own source code. QCC converts that bogus C program into a proper quine by applying source-level transformations and supplying an implementation of the mystery function consistent with the modified source.

Prerequisite: writing programs that output strings

There is one more building block necessary for this construction. It happens to be quite straightforward, involving no recursive self-reference or strange loops: we need to be able to convert a string into a Python program that prints that string when invoked. That is, we want a C program that takes as input a string and outputs a valid Python program whose only function is to print that string. This may sound complicated, but notice the end product is a minor variation on the canonical Hello World application for Python.

Main difference: instead of printing a greeting, our target Python program is hard-wired to print some other constant string determined at construction time. About the only tricky aspect involves escaping special characters from that input. The text we are supposed to output may contain arbitrary ASCII or even Unicode symbols. So we cannot simply enclose it in single quotes as in the hello world example and call it a day. If there was a single quote present in the included string, it would terminate the Python string prematurely and cause parsing errors on the remainder. Instead, we process the input one character at a time and special-case some characters consistent with the way Python expects string escaping to work.

With a little help from Claude 4.8, the result is a small C program characterized by this behavior:

  • Expects to receive one command line argument as string
  • Writes a Python3 program to stdout
  • Where this Python code is constructed to print that exact string to stdout when invoked by a Python interpreter

From prequine to quine

Stepping back, we have created a pair of programs A and B in two different languages:

A: C program that outputs a Python program (call it “B”) based on external input S
B: Python program that outputs this hard-coded string S

This is starting to resemble the A-B quine loop defined in the objectives. The missing piece holding back the closure of the loop is that free-floating, external string S provided as input. If we could replace S by the source code of A, the cycle will be complete. Looked another way, we need to modify A such that it ignores the command line arguments and runs the same Python-generation logic on its own source code.

This is exactly what QCC solves for. First, we create the prequine, by rewiring A to use its own source code get_self() as the input. This is also an opportunity to clean up the now redundant niceties around checking command line arguments and printing helpful error messages. Next, we run QCC on the prequine to generate the final quine. Compiling that and running through the steps proves the output from the final Python program is identical to the original C code:

Expanding the cycle

It is straightforward to expand this cycle to include multiple languages, by modifying only the starting C program. Recall that the driving force behind A is a function that writes Python programs. What if we add a second function that writes Rust in an analogous manner? That is we define a function that:

  • Receives as input an arbitrary string S
  • Returns a valid Rust program R such that when compiled and executed, R will print S

This function will be similar to the Python example, but instead use the hello-world template for Rust and apply Rust-specific string escaping rules.

Armed with this additional capability, we can extend the cycle by taking the output of the Python-writer and feeding it as input to the Rust-writer. Drawing out the sequence of transformations, the original chain looked like:

Self source-code ⟶ String-to-Python ⟶ Final output

Adding one more link to the chain:

Self source-code ⟶ String-to-Python ⟶ String-to-Rust ⟶ Final output

Instead of being a valid Python program, the output from the initial invocation is now a valid Rust program. When compiled and executed, it prints the Python program— its predecessor in the sequence— which in turn will print the original C code if invoked.

In principle there is no limit to the number of additional links that can be added here. In practice, one may need to watch for line limits of certain languages, as each transformation adds space overhead to the string being passed as input to the “printf” equivalent. At some point it may be necessary to break up the string into multiple lines.

2. Quine loops with useful programs

One limitation with the above example is that all programs in the cycle after A perform no “useful” work: their behavior is strictly predetermined to print something to stdout and exit. Meanwhile A as the starting point of the cycle can include arbitrary functionality, since QCC makes no assumptions about what its input program is doing. That raises a logical question: is there a way to apply QCC transformation to a pair of arbitrary programs A and B?

More precisely, suppose we have two programs A and B with arbitrary function— maybe A retrieves weather forecasts while B reports on World Cup scores. The objective is to create a quine loop out of these such that:

  • A and B retain their existing functionality
  • Both are augmented with the ability to print the source-code of the other app (That behavior would become conditional on some external input, such as a specific command line argument. This is similar to how the quine-version of QCC selects between doing its usual job of converting C programs to quines or printing its own code.)

This is straightforward with QCC alone provided both programs are written in C. The core idea is to create the prequine by “splicing” the two programs, interleaved with preprocessor macros to control which one actually gets compiled. Conceptually the merged version looks like:

#ifdef COMPILE_A
/* source code for A... */
#elifdef COMPILE_B
/* source code for B... */
#endif

Absent any other macro definitions, this code is equivalent to an empty file. But by prefixing the contents by a single line of code containing a #define directive, it can be cajoled to act as A or B. Both A and B are then developed under the assumption that get_self() will return this single, merged version regardless of whether it is called from A or B. By prepending one of the above macro definitions to the returned string, each app can choose to print its own code or that of its peer.

The Github repository for QCC has an example quine-loop constructed with this pattern.

  • Invoked without any arguments, program A prints the standard greeting, along its own identity “Alfa” (This is the intrinsic, non-quine related functionality.)
  • If the first argument is non-zero, A prints its own source code
  • Otherwise it prints the source code for B

Program B is the mirror image: it identifies itself as “Bravo” in the greeting and features conditional logic to print out either A or B based on the supplied command line argument.

There is a helper script in the same repository to merge the files, producing the combined A/B chameleon referenced above. That combination becomes the input to QCC, which supplies the necessary get_self() implementation. Finally the actual A and B quines are constructed from the QCC output by prepending a single line of code that defines the appropriate macro for selecting either A or B.

Putting it all together:

Two observation about this construction:

  1. Quines A and B differ by a single line— in fact a single letter in that line— even if their behavior at runtime can have arbitrary differences. This is an artifact of a shortcut taken here: recall that each program is “carved out” of a single block of code returned by get_self() using preprocessor macros and conditional compilation. As expedient as that approach is, it results in each program containing a lot of dead-code that is never compiled. With a little bit more work, we can avoid this by moving the carving-out process to runtime. Instead of relying on preprocess macros to select which block of code is visible to the compiler, we can have A and B perform basic text processing: locate the starting #ifdef line and corresponding #endif directive, then capture the section between those lines as a substring. (Note we still have to include the trailer following the conditional blocks, as the quine machinery is located there.) This will remove redundant. uncompiled code and make the underlying differences between A and B more prominent.
  2. The trick also extends naturally to more than two programs— in fact, the combination script is designed to accept any number of source files as input, automatically assigning successive letters of the alphabet to each program when crafting preprocessor macros. Once that merged file is run through QCC and individual quines created by prepending the appropriate macro definition, we end up with something more than a cycle: the collection resembles a complete graph. Every program in the collection can output the source-code for any other program in that collection. Contrast that with the standard Ouroboros cycle, where movement goes strictly in one direction. Here one can navigate the graph freely by asking any program for the source code of any other program.

CP

1 While it is possible to create C/Python polyglots to satisfy this trivially, this example will not be using that escape hatch.

Mark-of-the-web and pinning installers to sites

Is it possible to create an application that behaves differently based on which website it is downloaded from? At first glance, this seems impossible if the problem is interpreted strictly: the downloaded content must be identical byte-for-byte. (It would be trivial if each site was allowed to alter the contents.) The success criteria could be summarized as:

  • Serve the application from original URL #1.
  • Copy the downloaded file and mirror it from another URL #2.
  • The application behaves differently when downloaded from the mirror compared to the original location.

Recap: dark ages of web security & mark-of-the-web

Zone of naivete

In the late 1990s when the web was taking off, Microsoft’s web-browser Internet Explorer security model was predicated on a laughably over-simplified division of the world into zones. While one could define custom zones, there were 5 built-in:

  • Local machine
  • Intranet
  • Trusted sites
  • Internet
  • Restricted sites

Browser security policies were then configured based on zone. Consider ActiveX controls: arbitrary, unconfined native Win32 code that runs with full privileges of the user— which on most Windows installations meant administrator—and could wreak havoc on the machine. What happens if the user visits a webpage trying to run an ActiveX control? If that page hails from the friendly territory of the internal enterprise network (aka “intranet” zone) no problem: run the code, no questions asked. But a random website out on the wild-wild-web (aka “internet” zone) would require more caution: the user must click through a cryptic modal dialog with information about Authenticode signatures before allowing that code to execute.1

While this model “works” in the rudimentary sense intended for content rendered inside the browser, it poses an obvious problem with downloaded attachments. Suppose the attachment malware.exe is downloaded first and later opened from the Windows shell called “explorer” (which naturally bequeathed its name to the web browser, following MSFT’s creative naming conventions.) In principle the same zone-based distinctions should apply to the user experience: whether any warnings are shown and what type of scary language explains the consequences of proceeding with the decision to open the file should be a function of whether the file originated from the friendly confines of the corporate intranet or the terra incognita of the dangerous internet.

Mark-of-the-web

This is the problem mark-of-the-web (commonly abbreviated MoTW) solves. Whenever a file is downloaded, IE saves additional metadata about that file, including its origin URL and zone mapping.2 How this is done without altering the contents themselves and guaranteeing the metadata is permanently attached to the file is nonobvious. If IE simply wrote a second hidden file in the same directory, the connection would be severed as soon as the user copied the original file—the only file that the user is aware of— to another directory. Instead MoTW leverages an ancient feature of the NTFS file-system: each file can have multiple “alternate data streams.” Most files only have one stream: the default one which we normally consider as the contents. But additional streams can be created to store arbitrary data, without altering the original content. (Linux has extended attributes, MacOS has a similar concept as well as named forks.) MoTW uses a specific data-stream to store the information about the provenance of the file when it is downloaded, preserving that context for future security decisions.

Leveraging MoTW: from PoC to defense-in-depth

Introspection with MoTW

While MoTW is intended for the operating system and other origin-aware applications such as MSFT Office to make security decisions, an executable can also access its own MoTW. This is the basis for a proof-of-concept with a simple Win32 GUI application:

  • Downloaded from Github and executed, it displays a “Hello world” message.
  • Downloaded from another location it will instead display an error message about unrecognized origin.

Both files have the same SHA256 hash: 002d0bdbaaad909c8a6b49939b7f19ed8e897debce7aceb82732c2d590359bf2

(One caveat: because this executable does not have an Authenticode signature, SmartScreen can interfere in the demonstration. Clicking through the SmartScreen warning to continue to run the executable will delete the mark-of-the-web, and replace it by a different alternate data stream used by ScreenConnect. That behavior is by design; it is intended to avoid repeated warnings when the user has already indicated a binary is safe. To avoid such interference, simply open a terminal window and directly execute the binary from a command line instead of going through the Windows shell.)

This meets the criteria outlined in the introduction for an app with behavior conditional on distribution point. Before discussing a more realistic scenario where such tricks can be useful, it is important to recognize the limitations around threat model: MoTW can be trivially tampered with or deleted by the user. It is not authenticated. (Although the URL itself may contain a signature that the application can verify, since query-string parameters allow attaching arbitrary data. But in the same threat model the user can also tamper with the binary itself, since we are assuming write-permission to the file.) That means it cannot be relied on to implement arbitrary policies against the machine owner, such as enforcing license restriction on software.

Malicious repurposing of dual-use apps

Recall the case of ScreenConnect from 2025: ScreenConnect is a dual-use remote control application published by ConnectWise, ostensibly intended for IT departments to manage their fleets. Due to a combination of dubious design decisions and own-goals from ConnectWise, it turned out ScreenConnect had become very popular with threat actors using authentic, signed installers signed by ConnectWise to take over the PCs of unsuspecting consumers and hijack their accounts. The attackers’ modus operandi involved sourcing legitimate installers from ConnectWise, modifying some “free form” data without invalidating the Authenticode signature and serving these malicious installers from their own website, under a different pretense. For example, in the campaign picked apart here, it was renamed RiverDesktop.exe to impersonate a non-existent desktop application for River Financial.

Had the ScreenConnect installer used MoTW introspection— or really, any type of introspection, starting by looking at its own name— it could have easily detected this repurposing and refused to proceed with the installation. Even an installer customized to trust a malicious distribution URL specified by the attacker would have gone a long way to minimize blast radius: malicious sites are taken down quickly and attackers rely on being able to cycle through multiple look-alike domains in a game of whack-a-mole with defenders. An installer that does not care about its distribution point can be served from any host; one pinned to a specific distribution point is useless after the first abuse report.

Despite the previous caveat around users being able to tamper with the MoTW, there are three reasons why this mitigation still works for this specific threat-model:

  1. What matters is that the remote attacker serving malware can not tamper with the MoTW. It is the user’s own trusted web browser— Chrome, Edge, Firefox, Safari etc.— that dictates the contents of that alternate data stream. While the attacker can register any domain and serve the malicious binary from a URL of their choice, an MoTW will still be created and that URL reflected verbatim.
  2. The user has no incentive to remove the MoTW or otherwise tamper with it. Recall the attack depends on tricking the user to downloading and running what they believe is a legitimate application. A user could fire up Notepad and edit the ADS containing MoTW, but the attacker has no way to make that happen.
  3. Attackers can not tamper with the installer to remove MoTW introspection, without greatly undermining the persuasiveness of their scam. Recall that any alterations to the binary would invalidate the original software publisher’s Authenticode signature on the binary. These scams work precisely because Windows extends trust to code signed by ConnectWise, a reputable vendor of enterprise IT applications. An invalid signature or unsigned application will throw all kinds of additional warnings. (If the attackers did not care about the trust inherited from the signature, they would not have any reason to bother with ScreenConnect. They could have used any number of purpose-built, malicious RAT applications available for sale on the dark web.3)

CP

1 Later versions of IE tried to improve security by making it more and more difficult to run ActiveX controls. For example instead of the modal dialog which required an explicit yes/no decision, the user would have to notice a subtle notification above the status bar indicating that the page wants to run a control.

2 Note the obvious TOCTOU issue here: if the zone mappings are changed, the metadata will still reflect the original categorization.

3 Sure enough, in the 2026 iteration of a similar campaign, they were observed using code-signing certificates handed out by MSFT’s own ID verification CA. This frees them from having to use “factory-original” ScreenConnect binaries and in theory allows modification of the vendor logic.

Building quantum canaries and tripwires with smart-contracts

There is great uncertainty about when “Q-day” arrives for blockchains— when a cryptographically relevant quantum computer (CRQC for short) will exist that can recover private keys that control major digital assets, such as bitcoin and ethereum. Reflecting that uncertainty, there is a wide range of opinions on the urgency of post-quantum transition. Some voices are already sounding the alarm, while others dismiss such talk as crying wolf and urge a cautious, incremental upgrade path. Meanwhile a proposal from BitMEX research tries to make the concept of Q-day more concrete, by attempting to create a challenge on-chain such that when the challenge is successfully cracked, it becomes indisputable proof of a quantum computer in existence. This blog post will take a look at the options for constructing such “quantum canaries” and outline why smart-contract capable chain such as Ethereum can host even more powerful constructs, without requiring any changes to the underlying blockchain.

Recap: proof-of-quantum

The idea behind a quantum challenge is exactly same as the one around creating unusable public keys covered in a previous post: we invert the usual order of operations for key generation. Instead of generating an ECDSA private key first and deriving the public-key from the private scalar, we start by picking a public-key as the output of some hash function or other pseudo-random process operating on a natural input such as digits of pi or an English sentence. In the literature these are known as “NUMS” schemes, for nothing-up-my-sleeve: anyone else can verify those bytes were generated as part of a deterministic process without sneaking in arbitrary choice of parameters that could influence the result. Assuming the resulting public key is valid— in the sense of being a valid curve point, and there is roughly 50% chance of that for any random starting point— there is good reason to believe the private key was not known in advance. Recovering that unknown private key from the public key we picked is computationally intractable for classical computers. This is why we treat such keys as “unusable:” no one can sign with them, even the person who generated the corresponding public key. If a lock is designed to only open for those in possession of the private key, we can assert that door will never open.

Quantum computers invalidate that core assumption: they can efficiently solve the discrete logarithm problem and recover the private key. This provides a straightforward way to prove the existence of a quantum attack: pose a suitable challenge and wait for a solution.1

Quantum challenges on blockchains

On paper a blockchain would be a great platform for posing such a challenge: anyone can participate and if the challenge is structured appropriately, the winner does not have to worry about whether they will get paid. Contrast this with competitions run by a centralized entity with private submissions: whether the reward is given is very much at the discretion of that organization.

In fact, many observers have wryly pointed out that all blockchains operate a massive, unofficial bug-bounty with all attacks considered fair-game, including quantum computing. If one can recover private keys— or at a lower bar, trick the legitimate owner into signing with those keys— they can “collect a bounty” or in more colloquial terms, commit theft.

Unfortunately when any attack is fair-game, it becomes difficult to distinguish a ground-breaking quantum computer advance from garden-variety security breach or disgruntled insider. This is where the NUMS approach comes into pay: if one can prove no one could have known the private key to begin with, it could only have been a quantum attack.

There are some subtleties around realizing this purely on-chain. The first problem is that blockchain addresses are not same aspublic-keys. Addresses are typically commitments to public-keys that are derived from the key. For example a Bitcoin address is obtained from the ECDSA public-key by applying two hash functions in a sequence. This process is one-way: it is not possible to infer the public-key from the address. The original public key is not revealed until withdrawing from that address. That means merely depositing the bounty bitcoin at some address is not enough; one must also disclose the public-key.

That could be done either by:

  1. Out-of-band, for example in a blog post announcing the challenge
  2. On chain, by withdrawing a symbolic fraction of the bounty while leaving the majority of the funds at the same address.

The second solution is appealing in that it operates entirely on-chain without relying on additional communication channels. That also means it can be used to create tripwires: quantum-canaries that are not publicized ahead of time, and therefore unknown to attackers. A rational attacker armed with a quantum computer may deliberately want to stay under the radar, and avoid attacking known bounty addresses. But if some collection of coins looks like any other address on chain, there is a real possibility they will accidentally target that address and unwittingly herald the arrival of Q-day.

Unfortunately this design also runs into a circularity: if the private key is not known to the organizer of the challenge, they can not execute an ordinary withdrawal to deliberately leak the public-key either. One might suspect multisig could solve that problem. For example, one could create a 1-of-2 multisig address, with one known and one provably unknown key. Then a withdrawal using the known key ends up revealing both public keys. But this also poses a problem for the canary: since both keys are exposed, the attacker also gets their choice of targets. In fact a rational attacker would always choose to break the private key that was already used on-chain instead of the canary, since that pattern blends in with existing attack patterns. At that point we are back to the original problem: was it a garden variety compromise of the known private-key or was it a quantum attack?

Taproot addresses as ideal tripwires

This is where the new Taproot addresses come in, solving both problems at once. Unusual among blockchain address formats, Taproot addresses are public keys. They are also commitments to alternative spending paths, defined by ordinary Bitcoin script and efficiently compacted into a compact Merkle tree. Funds can be spent either by doing a Schnorr signature with the public-key defined in the address or by disclosing the internal structure of the address, including the specific node in the Merkle tree selected for a particular transaction.

This structure allows for an optimal bug-bounty structure:

  • Merely depositing funds into a taproot address creates a target for a quantum computer. No withdrawals or publishing additional data offline requierd.
  • That address looks no different than any other taproot address. In other words, the setup can also function as a tripwire if one does not publicize it in advance. (You can still prove after the fact that it was generated in a NUMS fashion.)
  • If no one trips the alarm after a given period of time, it is possible to reclaim the funds. This solves for another problem with the deposit-and-publish approach: if the private key is truly unknown, those funding the reward program will never be able to get their funds back, even if the reward is never claimed and the early-warning system is no longer necessary.

Canaries and tripwires with smart-contracts

Not surprisingly, it is possible to construct much better canaries on layer-ones with smart-contract capabilities. Turing completeness overcomes two limitations of the Bitcoin canary approach:

  1. Each canary requires recovering a specific private key. Consider a benevolent quantum capable intelligence agency that wants to tip off the world or for that matter a Snowden-type insider who wants to signal that capability exists. In order to announce the discovery using the Bitcoin blockchain, they would have to break that specific private key. But what if they had already solved other NUMS-style challenges internally as part of demonstrating that capability? Those demonstrations can not be used to meet the canary requirement. (Of course they can be leaked through other traditional channels whistle-blowers have historically relied on.)
  2. Finding out about Q-day is one thing, taking action is another. While a tripwire getting hit would be front-page news, it leaves everyone scrambling to decide on how to protect their funds. This is why the BitMEX proposal is coupled to a soft-fork that freezes certain funds if the canary is ever triggered.

Purpose built contracts for quantum-canaries

Smart-contract capable blockchains can improve on both of these aspects. This sketch will use Ethereum for concreteness but the same ideas translate equally well to layer-two rollups or Solana.

First a smart-contract can be written to accept a much more generalized type of CRQC proof. Instead of requiring that the prover solve any specific challenge, they can be broaden criteria to accept a much wider selection of NUMS-type schemes. This ideas has been explored in previous work, such as Brace for impact: ECDLP challenges for quantum cryptanalysis. Adopting it to the Ethereum setting involves creating a smart-contract to validate more generalized proofs:

  • Prover supplies a seed W, scalar Y, message M and signature S
  • A cryptographic hash function such as SHA256 is applied to the seed to generate 32 bytes that are interpreted as the X-coordinate of a public key point.
  • This is combined with the supplied Y value to get an alleged2 curve point <X, Y>
  • The public-point is hashed with Ethereum’s own variant of pre-standard SHA3 (“Keccak”) to generate the corresponding 20 byte address A.
  • The built-in ecrecover() primitive is used to recover the expected address E, which corresponds to a public key that would have generated a valid signature S on M
  • Check if A ≟ E
  • If equality holds, send all funds held by this contract—the reward for disclosing the existence of a quantum computer— to the prover.

Effectively this logic checks that the prover was able to sign some message using a private-key corresponding to a public-key that was generated deterministically from a hash function. Note how much freedom the prover has: they can sign any message. It does not have to be a Bitcoin or Ethereum transaction. (But if a BitMEX-type canary did trigger on Bitcoin, the exact same signed message could be replayed on Ethereum and accepted as proof that Q-day arrived.)

Second, other contracts can be written to depend on this canary. For example, before performing an important operation such as releasing funds, an institutional wallet can check on the canary status to ensure that ECDSA signatures are still reliable. (Recall that Ethereum contracts can call other contracts to retrieve information as part of their execution flow. Retrieving a yes/no answer from another contract would be a relatively “cheap” operation in gas terms.) Every other application is free to use this information as they see fit: for example, a contract could fall-back to an “emergency mode” where it will only accept signatures from a set of backup-keys that have never been used on chain before.

Alternatively one could implement a contract with two authorization paths:

  1. Standard ECDSA-based signing. Efficient because ECDSA signature verification is a native operation for Ethereum.
  2. Quantum-safe hash based signatures. These would be more costly and possibly have limitations such as a limit on how many messages can be signed.

As long as the canary has not been tripped, the first path is executed. But once the canary signals Q-day, only the second type of authorization is accepted.

Paradoxically, the same power that makes it possible to create such generalized canaries makes it much harder to create tripwires. Recall that a tripwire must be stealthy and look like any other vulnerable blockchain address. A smart-contract carefully crafted to serve as early-warning system to be invoked by other contracts clearly does not fit the bill. Using a plain “externally owned” address controlled by a single ECDSA key runs into the same problem as bitcoin: it is not possible to deliberately leak the public-key without doing a withdrawal, and by definition withdrawal is impossible without the unknown private key. (Ethereum does not have an alternative address format comparable to Taproot that directly reveals public keys.)

Designing for incentives

Dealing with front-running on Ethereum

Building a bug-bounty is one thing. Whether it will work to incentivize disclosure is a different problem. Same goes for tripwires: they are only effective if the attacker is likely to stumble into one early on in their rampage through the blockchain, otherwise the warning comes too late. Before exploring this complex topic of game-theoretical incentives for the hypothetical attacker, we need to address one flaw in the design sketched above.

Let’s posit that the actors deliberately signaling the canary are financially motivated. (Note this does not apply to an attacker unwittingly hitting the tripwire.) They want to collect the associated financial reward. By design the bitcoin held in the Taproot canary is only claimable by the entity who wields the private key corresponding to that address and can sign a specific message. More importantly, that signed message is a bitcoin transaction and unambiguously specifies where the rewards are to be sent: those are the outputs of the transaction. That is not the case on Ethereum: any signed message for a suitably constructed key works and that message need not have any particular structure.

That leads to a problem: since transactions sit in mempool before they are confirmed, there is a window of vulnerability where anyone can observe the proof before it has been officially recorded. They can then construct another transaction with higher gas to tempt the block builders into prioritizing it ahead of the original. If this second transaction executes first, the reward for proving a quantum attack goes to the copycat reporter, not the original person who deserves credit.

There are two complementary ways of dealing with this, depending on the expected disclosure mode:

  1. If the entity triggering the canary has access to the full private key, they have full control over what message is getting signed. The protocol sketched above assumed no particular structure in that message, which is useful for accepting the widest spectrum of evidence as proof-of-quantum. While keeping that property we can add an additional check: if the message consists of exactly two blockchain addresses, one being the address of the canary contract, interpret the second address as the destination where rewards will be sent. These transactions can still be front-run but now doing so has no effect: the address where rewards are sent is hard-wired in the signed message. Racing to broadcast the same evidence from a different address only delivers the bug-bounty faster to the deserving recipient.
  2. That still leaves open the question of how to safely submit evidence in cases where the person does not control the private-key. For example, a conscientious employee working for an organization that achieved a surreptitious CRQC breakthrough. In this case, they may only have access to a handful of signed message examples, but not the ability to use the CRQC for a selected public-key of their choice. To prevent front-running in that scenario, the contract logic must be modified. Instead of disclosing the evidence outright, there is a two step commit-and-reveal protocol:
  • First the reporter commits to the triple <message, signature, rewards address> by sending its hash to the contract. This alone does not trigger the canary since anyone can make up commitments. The canary contract still makes a note of all such commitments, along with the time when they were first made.
  • Only after that first transaction has executed and the contract recorded the commitment, the reporter follows up by disclosing the full evidence. The contract checks the evidence as before and also confirms there is a prior commitment serving as a promise to deliver the evidence. There is also a deadline imposed, to make sure commitments are opened within say 24 hours.
  • The canary is immediately triggered to indicate proof of a quantum attack. However the rewards payout will have to wait until a few checks are cleared.
  • In the best case scenario, there are no earlier unopened, unexpired commitments. In that case the bounty can be paid out immediately.
  • Otherwise the priority of the disclosure is being contested. A countdown begins to select among multiple submissions, with the current reporter becoming the leading contender for the reward.
  • If any earlier commitment is successfully opened by providing valid evidence consistent with that commitment, it becomes the new leading contender.
  • At the end of the 24 hour period, the winning submission can make a final call to the contract to collect the reward.

Note it is still possible to front-run all transactions from the original prover and resubmit them with identical payloads, with higher gas to ensure they are processed ahead of the legitimate submission. But since an adversary has no way to open binding commitments to reveal a different payout address, all they accomplish is accelerating the reward payout to the rightful owner.

Questioning incentives

Underlying all this discussion is an implicit premise: that establishing a high-enough monetary reward is enough to incentivize disclosure on-chain. We now turn our attention to sanity-checking that.

The original BitMEX proposal hinges on a core assumption: a benevolent organization with a CRQC will choose to deliberately reveal that capability on-chain by solving one very specific challenge and reaping the modest associated rewards. This is at best a dubious assumption. If they are financially motivated, there is no need for an artificial bug-bounty. There are exposed public-keys controlling BTC collectively worth billions of dollars that are vulnerable to recovery by a CRQC. As long as compute time on CRQC remains precious, incentives favor chasing after the maximum gain possible with the targeted private key. For example the third-highest balance bitcoin address today has an exposed public-key and a balance north of 140,000₿, a figure that dwarfs any reasonable bounty. An unscrupulous actor can help themselves to a fraction of that amount while retaining plausible deniability that it was an ordinary security breach or human error.

At best a monetary reward can incentivize disclosure by a legitimate organization such as one of the pioneering quantum-computing companies who are already committed to operating within the bounds of the law. But even in that case, why should that company have to jump through the hoops of solving one particular challenge on one particular blockchain? Why not put out a press release with a solution to one of the many previous quantum-computing challenges published in the literature?

By contrast, a quantum-tripwire is useful precisely because it does not depend on good faith actions by the CRQC owner. One would expect an actor unconstrained by legal or ethical rules to chase moderately concentrated holdings of bitcoin first: not too large to panic the market with a major theft—even if there is plausible deniability on root cause— and not too small to waste precious CRQC time on economically unprofitable targets. If the tripwire address falls into that sweet-spot, an attacker could accidentally end up revealing their capabilities. On the other hand, it is also easy for threat actors to avoid that fate: while Taproot transactions account for 15-20% of activity today, they only account for ~1% of stored value. So an attacker can avoid hitting a tripwire by simply steering clear of all Taproot addresses, without meaningfully reducing their expected gain.

The more generalized quantum-canary for Ethereum opens up new incentives, by exploiting the schism between the organization wielding the CRQC and individuals associated with that work. An organization may have no official policy around wanting to protect the bitcoin community by warning of impending capabilities. But there may well exist conscientious whistle-blowers within that organization with access to CRQC development, who choose to take matters into their own hands by disclosing a cryptographically verifiable proof on-chain. These individuals need not even harbor a profit motive. Since the protocol is flexible enough to specify that the bug-bounty is burned (by using the 0 address for rewards destination) it is compatible with disclosure motivated by ideological reasons. On the flip-side of the coin, there is a clear lesson for CRQC operators hoping to remain under the radar: avoid solving any NUMS challenges, even for internal testing purposes. This is rational guidance anyway. By definition a NUMS challenge is an artificial target: no one relied on that key to encrypt highly sensitive traffic or authenticate critical actions. Therefore recovering the corresponding private key will not result in learning useful intelligence from intercepted traffic or impersonating some high-value target to gain access to some system. Given that CRQC time is going to remain extremely valuable, wasting cycles on such a demonstration is unwise even without the added risk of creating undeniable proof that can be leaked.

CP

1 Assuming that discrete logarithm problem is indeed as intractable as believed— it is worth nothing that there is no mathematical lower-bound established on its complexity.

2 Note “alleged” part because there is no guarantee this point is actually on the curve. This turns out not to matter for the correctness of the protocol, because the address generated from such an off-curve point can not be equal to one returned by ecrecover.

ScreenConnect redux: the limits of certificate revocation

An earlier post from 2025 covered the case of ScreenConnect, a popular remote-administration utility developed by the vendor ConnectWise for IT administrators to remotely manage Windows PCs. Such applications are inherently “dual-use:” they work equally well for legitimate IT departments to manage their corporate PCs as they do for criminals looking to take over unwitting consumers’ machines. Combined with a number of questionable design decisions in the ScreenConnect client around lack of notice/consent, it was no surprise the threat actors jumped on the chance to leverage this application for their campaigns. Typical modus operandi: targets are sent a phishing message suggesting they install a new Windows desktop application associated with a service they already use. Not surprisingly, that application was just a renamed ScreenConnect installer, which grants remote-control of the machine to the attacker as soon as installation is complete.

Multiple reports and eventual escalation of these incidents to Microsoft and DigiCert— the certificate authority who issued the code-signing certificate used by ConnectWise to sign their Windows binaries— resulted in a number of disruptive changes to the application and the associated cloud service. Two stand out from a security perspective:

  • ScreenConnect installer no longer uses the “unauthenticated data” field in Authenticode signatures to stuff critical configuration. As the name implies, this field is not covered by the signature and could have been trivially altered by attackers to modify settings of a legitimate install, redirecting the C&C server away from the original customer (eg the IT department using ScreenConnect) to one controlled by the threat actor.
  • ConnectWise no longer digitally signs installers for on-prem versions. Instead customers themselves are responsible for getting their own Authenticode certificate to sign the binary.

One would expect this to have been the end of the story. Fast forward to 2026, and more renamed ScreenConnect installers are showing up in the wild. This post takes a look at how the attacks have evolved.

Suspect binary

Phishing site that offers an alleged native DocuSign app

The suspect binary comes from a malicious website sporting generic DocuSign branding but registered under domain names intended to impersonate a financial service. Targets receive phishing emails with a false pretext involving new policy documents that they are required to review and sign for continued access to their account. Clicking the download button on this page returns a file named “DocuSignSetup.exe” Interestingly while the fine-print under the button claims both Windows and MacOS are supported, the exact same file is served for all platforms, including Linux. Presumably the threat actors concluded Windows is a sufficiently target-rich ecosystem and saw diminishing returns in chasing other platforms despite ScreenConnect having cross-platform support.

Looking closer at the binary:

1. Running strings on the binary turns up references to ScreenConnect, as well as XML configuration snippets observed in previous samples of the real installer:

It is possible these strings and XML configuration were planted as a false-flag operation, as unused resources embedded in the binary to confuse attribution. Far more reliable evidence comes from running the installer in an isolated VM and observing changes to the system. Sure enough there is a ScreenConnect directory created under \Program Files (x86) and the helpful autoruns utility from SysInternals shows persistence components associated with ScreenConnect— including a DLL that is in fact signed by ConnectWise itself. While there is no guarantee that the threat actor did not make changes to the original installer prior to signing it, there is no question that real ScreenConnect components are installed and activated after running the malicious binary.

2. It carries a valid Authenticode signature chaining up to a publicly trusted root— specifically one of Microsoft’s own code-signing CAs. (Signer name has been redacted for privacy reasons explained below.) This is a very short-lived certificate with a mere 3 day lifespan, and the trusted timestamp on the binary shows it was signed about six hours after issuance, within the validity window of the certificate. Corollary: this binary will not result in a warning about unknown publisher when invoked on standard Windows versions.

3. This is a garden-variety Authenticode signature. There is no evidence of the bloat associated with hiding configuration data in unsigned fields characteristic of ScreenConnect incidents from 2025. That rules out an installer created for a legitimate ConnectWise customer somehow landing in the hands of crooks who repurpose it by tampering with unauthenticated, free-floating configuration parameters.

Conclusion: crooks are still able to leverage ScreenConnect to remotely take over consumer PCs despite all steps taken by ConnectWise.

Microsoft in the middle

Accidental doxxing

What stands out in the above investigation is that the code-signing certificate was issued by MSFT itself. The common name on the immediate issuer reads: “Microsoft ID Verified CS AOC CA 04” This turns out to be part of the Azure Artifact Signing program, Microsoft’s own entrant in the increasingly popular code-signing-as-a-service category. After watching software publishers fumbling security around high-value signing keys— failures seized on by threat actors in high-profile incidents to sign exploits, including the Stuxnet worm discovered in 2010 that sabotaged Iran’s nuclear enrichment facilities— the industry has collectively given up on the idea that companies can be entrusted to manage their own keys. Instead a cloud service holds the keys on behalf of the software publisher and signs binaries subject to governance rules defined by the customer. DigiCert, SSL.com and other certificate authorities offer this functionality.

Regardless of whether keys are self-custodied or held by a trusted cloud service, requirements for issuing code-signing certificates are identical: the CA must verify the identity of the software developer. There are three levels of verification available, ranging from the most accessible to most stringent: individual/independent developers, organization validated and extended validation. In this case MSFT has issued the code-signing certificates to a specific individual rather than corporate entity. According to Azure artifact-signing documentation, the necessary identity verification for this type of certificate is outsourced to the third-party service Au10tix. Au10tix documentation suggests they can scan and validate government issued ID documents using smartphones. This type of remote identity verification is increasingly common for onboarding with fintech applications.

The surprising part: Azure Artifact Signing has an option to include the verified street address in the issued certificate. That is not a required field; its inclusion is controlled by a command line parameter or checkbox. Yet the persons who provisioned these certificates went out of their way to include their street address. (This is why the X509 subject name was redacted from the image above.) Whether or not they realize it, the developers who signed this binary doxxed themselves.

Verifiable criminality

There are three ways to interpret these observations:

  1. Threat actors are willingly signing malware under their true identity. This could be a matter of bad opsec: maybe they are not aware of how Authenticode works in general or do not realize that Azure’s artifact-signing exposes their identity to all targets receiving the malware. Or it could be calculated risk taking, assuming that law enforcement will not have resources to pursue this matter even when they are leaving their fingerprints all over the attack.
  2. Threat actors are enlisting unwitting accomplices to “borrow” their identity and complete Azure’s verification process. Support for this is mixed, given the limited data points. Of the three different signing certificates observed in the wild for this sample, one belonged to an individual in Oklahoma but two were associated with residents of Texas in close geographic proximity. If this hypothesis is true, there is still an investigative trail leading from individuals named in the Authenticode certificates to the perpetrators.
  3. Threat actors are using stolen identities to bypass Au10tix. This is the optimal choice for a seasoned criminal: it causes misattribution, framing someone else if law enforcement pursues the matter.

Malware bundle

There is another crucial difference between this campaign and previous ones built around ScreenConnect: this time around the installers appear to contain a veritable kitchen-sink of additional components. Standard ScreenConnect installers clock in at a few megabytes. The installers observed in this campaign vary in size from under 10MB to over 50MB. Additional reverse engineering is necessary to identify exactly what these components are but it can not be explained as natural variation in the size of the authentic installer. More likely the threat actor is bundling additional malware alongside ScreenConnect, such as a backup RAT in case ScreenConnect stops working in the future. This is a legitimate risk for the attacker— depending on configuration, the command & control channel is a cloud service operated by ConnectWise. That gives the company broad leeway to take action against any customer abusing the product, by disabling that account and disrupting the remote-control capability.

In a way, attackers are much better off than 2025 when they had to work with the installer provided by ScreenConnect. While they could make some changes to the configuration left unprotected by the Authenticode signature, they could not bundle arbitrary code. That constraint no longer applies. Empowered by Azure Artifact Signing to sign any executable, the threat actor is free to bundle additional malware or even tamper with safeguards in ScreenConnect if they wanted to. Suppose the ScreenConnect client added a mandatory notification for the user whenever remote-control sessions are started. An attacker can directly patch the binary to strip this out and then sign the whole bundle with their own certificate. That latter signature is just as good for appeasing Windows’s requirement for code provenance and suppressing scary warnings about unknown publisher.

Limits of revocation

As of Jun 3, at least one certificates that signed a malware sample has been revoked retroactively, while another one remains valid. In a sense, it may not matter even if revocation had been more timely and comprehensive. For consumers who were already tricked into installing the malware, the damage is already done: their PCs have already fallen under the threat actor’s control. Windows does not retroactively check Authenticode signatures for already installed applications in hopes of catching ones that were later revoked. EDR software can provide continuous monitoring, and there is some reason for optimism there: Windows Defender is categorizing the binary with revoked signature as malicious. But it is unclear how far that generalizes to all other variants with their variable payloads and for that matter, whether Defender will take the drastic step of neutralizing the ScreenConnect persistence mechanism on an existing PC. It is after all a “dual-use” application that can have legitimate uses in a managed IT environment. The distinction between “RAT” and “corporate fleet management” is not in the eye of the beholder, but it does depend on context: who paid for the PC, who is using it and whether they consented to remote management. ScreenConnect is better poised to neutralize an unauthorized use of their remote-control software by bringing the hammer down on specific instances of abuse. But that mechanism operates out-of-band in a messy world subject to human discretion, outside the regimented structures of PKI.

CP

NFTs for ticketing: when scarcity matters

Often the first application of a technology turns out to be its worst proving grounds. During the 2021 crypto craze, NFTs have achieved dubious notoriety as one of the more inane use-cases of blockchains. Pixelated images of primates trading for outsize sums invited comparisons to the Dutch tulip mania. Once prices crashed many of the so-called “collectors” were left holding the bag as schadenfreude spread in other quarters. As difficult as it may be to suggest resurrecting NFTs with a straight face today, there is a good case to be made for ticketing. This application has not been tried on any commercial scale outside of limited trials. More importantly recent landmark litigation officially labeling Ticketmaster a monopoly may finally provide an opening for new entrants in an otherwise concentrated industry.

Solid foundations: fungibility and on-chain tokenization

Sometimes the first application of a technology an industry gets wrapped around the axle on turns out not to be the optimal one. (See QR codes before the pandemic, secure-elements on mobile devices for NFC payments…) The original enthusiasm around NFTs for digital art follows that pattern. Before NFTs, there were FTs— fungible tokens, without the leading negative. As one of the earliest standards building on Ethereum, these had already proven useful in the issuance of secondary assets on the Ethereum blockchain, especially those intended to mirror an existing fiat currency such as the US dollar. Tether and Circle already boasted billions of dollar-equivalent stablecoins as ERC-20 fungible tokens in circulation before the pandemic. With the passage of the GENIUS act officially recognizing and regulating stablecoin issuers, these tokens are ever more tightly coupled with the traditional financial system, much to the chagrin of cryptocurrency detractors.

Stablecoins are meant to be fungible in the same way cash is: a dollar bill in paper currency has no unique properties to differentiate it from another bill. That also holds for bars of gold or shares of stock. But there are other types of assets where this is not true: real-estate is an example. If there are two adjacent houses in some suburban planned community with cookie-cutter construction that are identical in every aspect including their selling, the titles for those houses are still not interchangeable. The buyer of the house on the left can not legally move into the one on the right by arguing they are indistinguishable. Non-fungible tokens standardized by ERC-721 took the next logical step for tokenization— mirroring real-world assets on-chain— by introducing a variant of ERC-20 intended for one-of-a-kind objects. There is nothing fundamentally unsound about this step. It still requires the present of a trusted third-party to enforce the correspondence between on-chain representation and real world possession, but this is no different than stablecoins. One USDC stablecoin is accepted as a substitute for one traditional dollar on DeFi markets because of the belief that Circle— the company issuing USDC— is willing and able to exchange the virtual dollars for real ones in a bank account. That belief is not enforced by any consensus rules of Ethereum: it requires positing the existence of those dreaded trusted-third parties that blockchains were supposed to eliminate. Putting aside the irony, it is clear that network participants have been willing to make that leap of faith— even in the presence of evidence suggesting the stablecoin issuer has less-than-stellar reputation. Once that level of confidence exists, it is only an incremental jump to believe that some other trusted third-party can also enforce the connection between real-world property ownership and their virtual representations on chain.

Nonexistent scarcity

It was not the failure of a trusted-third party that resulted in the first NFT gold-rush turning into an easily ridiculed tulip-bulb craze. (At least, not a failure in the traditional sense of failing at their primary responsibility: maintain the correspondence between the real-world and its on-chain reflections. Investigative journalists have uncovered plenty of cases of digital art purveyors acting with less than stellar ethical standards in marketing and price-manipulation.) The fundamental problem with encapsulating public digital art in an NFT is that by definition such art has no scarcity. There is exactly one authentic instance of The Birth of Venus. It is located at the Uffizi. Laying eyes on the original involves a non-virtual trip to Florence. Any one can create a copy of that original, complete with the appearance of age by using paint and materials approximating their 15th century equivalents. Those copies are decidedly not interchangeable with the original. An art museum could conceivably create an exhibition out of replica paintings to spare visitors the inconvenience of having to travel to Italy. But no one could mistake that for actually seeing the real thing by Botticelli, any more than walking down the Las Vegas strip qualifies as having “visited” the pyramids, the Eiffel Tower and the Statue of Liberty all in the same day because simulacrums of these objects have been recreated there.1

What the proponents of digital-art-as-NFT have struggled to articulate is the answer to the question: what distinguishes one copy of the image from another? When anyone can visit the same web-page to view the exact same image— pixel for pixel identical to what all other viewers are observing— what benefit does “ownership” of the associated NFT exactly confer? It is not even bragging rights about patronage of the arts or demonstrating refined personal aesthetic, even if one takes the cynical view of modern art as a Veblen good. Having an original Picasso on the wall creates an experience that is not available to anyone else not in possession of that specific artwork, for example being able to admire said painting while having dinner with friends. If the painting is later sold, that experience is no longer available. What benefit accrues to the present “owner” of a digital-art NFT that is not accessible to anyone else who accesses the same image and downloads it locally?

Artificial scarcity

When there is no intrinsic scarcity, producers are motivated to artificially prop-up prices by creating the appearance of scarcity. This is why new mints of NFTs must be carefully controlled in quantity: there is no reason a batch of NFTs could not feature a million variations on the same theme, but justifying sky-high valuations is (relatively) easier when the marketing collateral can drum up FOMO by predicting the “limited run” will sell out in a matter of hours.

Other NFT projects attempted to sidestep this problem in a creative fashion: make-up new benefits exclusively available to holders of their NFT line. For example, events where attendance is conditioned on current ownership of a BAYC. While this type of red-velvet-rope treatment certainly creates a distinction between the NFT-haves and have-nots, it raises a question on what digital artworks have anything to do with the benefits. Why not simply auction off attendance rights to the event directly? Having a low-resolution simian image attached to the on-chain representation of that right does not appear to add any value, certainly not one to justify the large difference in price based on the exact characteristics of the same image.

Ticketing

That brings us to the pedestrian business of event ticketing, back in the headlines briefly after a federal jury in New York officially branded Ticketmaster/LiveNation an illegal monopoly. It is unclear whether any structural remedies will follow from this decision but there is a fighting chance that new entrants may be able to challenge this incumbent monopoly now operating under the watchful eye of regulators. Ticketing turns out to be a much better fit for NFTs for several reasons:

  1. Real scarcity. There are only so many seats at Madison Square Garden and so many calendar days in a year when Bruce Springsteen can perform. This is the ultimate constraint event promoters must contend with, even if they are constantly trying to create additional scarcity to squeeze even more profit. (Why are there only 100 “VIP packages” that come with mass-produced souvenir schlock when one could just as well have made 1000 copies? Why is that benefit a function of seating close to the stage when it could have been decoupled from location and made available to all fans even in the nosebleed sections?)
  2. Unsolved trust problem. It is difficult to resell tickets in a peer-to-peer manner without a centralized platform to coordinate the transactions. Direct sales between individuals would be rife with fraud because the recipient can not verify the authenticity of what they are paying for. Anyone can create a PDF or even print a piece of paper that looks like a valid ticket to a highly-coveted World Series game. But can a seller convince prospective buyers that this piece of paper is authentic? Even if it is authentic, what if they had already “sold” the same ticket to multiple people already? (This is the real-life version of the double-spend problem that bitcoin has solved elegantly.) In economics this type of information asymmetry between buyers & sellers is known to result in an inefficient dynamic called “the market for lemons” inspired by the used-car sales dynamic. Buyers artificially discount the price they are willing to pay for a car when there is a significant chance it will turn out to be a lemon worth much less than the asking price— a condition that only the seller has visibility into. This is the problem SeatGeek, Stubhub and other online market places for ticket resales solve for. It allows buyers to transfer the risk: they will be made whole for the occasional counterfeit ticket purchased from the platform, a guarantee that does not exist when directly transacting with the seller.
  3. Lack of transparency in secondary-markets. While Stubhub and its ilk have built lucrative businesses around this risk-transference model, consumers are worse off from a pricing perspective. These secondary markets thrive on opacity: while a buyer may know exactly which seat they are paying for— and thanks to federally mandated all-in pricing, how much the platform is earning in fees— they have no clue about the original face value of that ticket, much less its resale history. Is this a professional scalper charging triple price for a random batch of tickets they purchased mechanically using a bot? Or die-hard fan trying to recoup the cost of their tickets after some unforeseen life-event derails their plan to watch their favorite artist live? The distinction matters even when we acknowledge the supply/demand dynamics: artists often deliberately underpricing tickets for good-will result in a secondary market closer to fair value. Opacity props up the demand side: knowing that they are about to get ripped off by a seller demanding a ridiculous multiple of the face-value is likely to influence how much one is willing to bid. (Of course Ticketmaster and Stubhub have zero incentive to “fix” that problem and make the market more efficient: buyers getting ripped-off is good for business when the revenue depends on collecting a fraction of the sale price.)

What NFTs can and can not solve

Looking at each of the structural problems with the market, NFTs obviously can not solve the intrinsic scarcity problem: minting more NFTs on-chain does not create more seats in the stadium. Virtual tickets can only mirror this scarcity. But they solve for the trust problem in a very robust, cryptographic manner, far better than what paper tickets or animated QR codes can achieve. It would be trivial to check that a given address is the official holder of a particular NFT. Since each NFT is associated with a URL, it is also possible to look up exactly what that NFT corresponds to in real life: attendance rights for a specific seat at a particular event. Crucially that URL may hold the piece of information Ticketmaster and its ilk desperately strive to withhold from consumers: the original face-value. With some standardization around how tickets are encoded, it becomes possible to index inventory on-chain and track distribution in real-time.

To be clear: there is still a trusted third-party involved— the issuer of the NFT must be authoritative for real-world allocation of those tickets. They are in a position comparable to stablecoin issuers: they guarantee interchangeability between the virtual construct on-chain and the real life privilege of sitting at that seat. Initially this role may well end up being the same Ticketmaster/LiveNation monopoly, resulting in no structural market change for primary sales. (Just because tickets can be issued on-chain does not mean the Boss will throw away all existing distribution channels and farm out this crucial side of the music business to random upstarts.)

But the existence of tickets in NFT format could drastically reshape the secondary sale market. It is no longer necessary to have Stubhub sitting in the middle of every transaction to guarantee the authenticity of tickets, or more accurately, to refund buyers in case those tickets turn out to be counterfeit. This lowers the barriers to entry for creating true peer-to-peer marketplaces, including potentially ones operating entirely on-chain. Just as decentralized exchanges allow trading cryptocurrencies directly with a smart-contract, a decentralized ticket resale platform can enable buyers to bid on inventory. Interestingly none of the usual criticisms of DeFi platforms—that they are too slow, too expensive per transaction and susceptible to front-running compared to centralized exchanges— apply to this scenario. On-chain transaction fees are significant for an automated strategy executing thousands of trades with gains/losses are measured in cents. That is not how ticket resales work; hedge-funds are not built around high-frequency trading of tickets. If anything, introducing additional friction to handicap professional scalpers is arguably a feature. It is not possible to arbitrage across different markets: there is no “hedging” one’s exposure to holding Bruce Springsteen tickets by “shorting” Taylor Swift tickets for a different date.

Limits of transparency

For all these advantages, there is still no guarantee that NFTs can bring about full transparency or efficiency around secondary-sales. There are two reasons, one that is fundamental to all unregulated peer-to-peer sales and one contingent on the exact structure of these hypothetical marketplaces that emerge.

The intrinsic limitation is around the possibility of manipulating prices with bogus sales. Seller Alice can collude with her friend Bob to “sell” her ticket at an artificially inflated price, paying Bob under the table for his costs. (If all activity is taking place online, there is no need for Bob the co-conspirator: Alice can just create a second wallet address to bid on her own listings. This is the standard practice for artificial pump-and-dump schemes.) Bob can then list the ticket himself or hand it back to Alice: rinse and repeat. Or if Alice has a batch of tickets in the same row, inflating the price of one may now justify a higher price for the others. No money has exchanged hands and no meaningful economic activity has taken place here. But this fraudulent transaction distorted the price signal, by creating the appearance of those tickets being worth more than their fair market value. In regulated markets this type of activity is strictly illegal; the market operator is tasked by law with surveilling their platform and reporting on questionable trading patterns. Ticketing already plagued by a class of professional bottom-feeding scalpers, is unlikely to merit any significant scrutiny around market integrity.

The second limitation is a function of how much transparency the new platforms choose. Even today there is no reason that Ticketmaster could not disclose the entire transaction history associated with a ticket: issued at this face value, resold on such date for a second price, that buyer then turning around to sell it again later for a different price. To the extent that such prices are known to platforms, they are not surfaced publicly. It is possible that no single platform has necessary visibility to reconstruct that timeline: in a competitive marketplace, each resale could have taken place on a different service, each one jealously guarding its internal hoard of transactions. In reality, given the highly concentrated oligopoly that exists today, chances are a single ticket spends its entire lifetime within the confines of the same platform. The challenge is not lack of information; incentives favor keeping consumers in the dark. Those exact incentives operate even when tickets are represented as NFTs: while the object being traded exists on-chain, the transaction itself can still take place off-chain on a garden-variety website. This is very similar to how NFT sales were often conducted: buyers escrow their NFT with the platform, buyer pays the platform which arranges for transfer. While the blockchain will record the change of ownership, there is no guarantee that it will also reflect exactly how much money changed hands in the other direction. Such transparency is more likely if the platform operates entirely on-chain and each NFT transfer is accompanied by some other visible record of cryptocurrency movement in the other direction.2

CP

1 In fairness, the Vegas simulacrums are not identical in dimensions or construction to the real object either.

2 It would be possible to hide the payment using smart-contracts if buyer and seller can agree on a specific condition to be enforced by the contract for releasing the NFT. This is not quite the same as outright price manipulation. It can be rational for both parties if the seller is trying to save face and move inventory without signaling declining prices to the broader market.

Reckoning with address reuse: the post-quantum challenge for Bitcoin

Backed into a corner

Blockchains are confronting the challenge of quantum computing with renewed urgency as more researchers continue to sound the alarm. Denial is giving way to anger and bargaining. As the first and largest cryptocurrency, Bitcoin has always benefited from a certain immunity against criticism over its original design decisions and selection of features— or lack thereof, as critics frame it: rudimentary scripting language and stubborn refusal to accept even simple improvements that restore pre-existing functionality. Defenders see the intransigence and allegiance to 2008-vintage design as a virtue: sound money must be resistant to fads, very difficult to change except by near unanimous consensus of the community. Constantly hard-forking to jump on the latest smart-contract bandwagon or implementing the most fashionable signature algorithm of the day is the last thing users need. In the extreme, this becomes a version of the originalism doctrine from US jurisprudence: every contentious question is adjudicated by deference to historical pronouncements from Satoshi.

The specter of cryptographically relevant quantum computers (CRQC) is bringing some of those ancient design relics back into sharp relief. If the engineering challenges around quantum computers are overcome anywhere as quickly as optimists are predicting, the security guarantees of Bitcoin and virtually every other cryptocurrency will be immediately undermined. That often-repeated self-custody mantra “your keys, your coins” starts to ring hollow when a quantum computer can turn your keys into their keys. This is the problem every blockchain must contend with. There are some incremental solutions such as minimizing address reuse. These are not realistic, for reasons discussed in following sections. There is widespread agreement on principle that the only long-term defense against CRQC is the adoption of new signature algorithms purpose-built to resist known quantum capabilities. The engineering challenge is deciding which one— or which options, if one fully embraces cryptographic agility and giving users an option among multiple competing algorithms— and exactly how these new capabilities will be phased into an unruly system with no formal governance model. The challenge for Bitcoin is that all options on the table pose the same problem: signatures or public-keys will take up significantly more space on chain, cutting into already scarce limits for the number of transactions that can be accommodated in each block. It turns out one of those original design assumptions will greatly aggravate that problem.

Address reuse in the original vision

To explain how 2008-era decisions have backed Bitcoin into a corner today, it is helpful to highlight one aspect of the original design. Satoshi expected that addresses would only be used once. This also implies underlying cryptographic keys are also not reused, since there was a strict one-to-one mapping between them originally.1 Every Bitcoin wallet could generate an unbounded list of new addresses from a single “seed” secret. Each time the owner of that wallet needs to receive funds, they generate a fresh address with no previous history on-chain. That would be true even when sending funds back to oneself, as part of the so-called “change output.” If Alice has an unspent output of 10 bitcoins and needs to send Bob 1 bitcoin, the remaining 9 bitcoins would be sent back to a brand-new address Alice controls, not the original source address where the funds originated.

It was privacy and not the distant threat of quantum computers that underpinned this original avoidance of address reuse. CRQC remained very much in the realm of academic research during the 2000s when core ideas underlying Bitcoin were brewing in the cypherpunk community. Regardless of the motivation, some key decisions followed from this assumption:

  • Every transaction input is signed independently. If there are 10 inputs, there must be 10 signatures. It would not make sense to have a single signature authenticating multiple inputs, since they are all going to be coming from different addresses controlled by different keys. (In theory there is another, more advanced optimization possible: called “signature aggregation,” it allows combining multiple signatures into a single signature that is in turn verified against a combination of public-keys. But this is not supported by the consensus layer either.)
  • Each signature must be accompanied by the associated public key, since there is no other way to verify whether that address is controlled by that key. Later this would extend to revealing the full redeem script, which may include multiple public keys in the case of multisig. Again this makes sense if addresses are never reused. That specific public-key or redeem script has never appeared on-chain before, so it is not possible to refer back to a previous occurrence or waste space on storing that for future use, since that address will never appear in a future transaction again.

Address reuse in reality

In actual usage of Bitcoin, it turns out address reuse has become the norm. It is not some exceptional case of opsec failure. In fact later blockchains even made a virtue of address stability. For example, Ethereum and Solana group funds by address, not by chunks of coins (“UTXO” for “unspent transaction output”) as with Bitcoin. There are good reasons for this:

1. Enforcing transaction policy. The easiest way to lose control of assets on a blockchain is key compromise— when the threat actor gets hold of the private key. A close second is when the legitimate owner is tricked into wielding that private key to sign the “wrong” transaction: one that sends funds to the threat actor instead of the intended recipient. The difference between a right and wrong transaction comes down to a handful of factors, with the most significant one being the destination address. When addresses are stable, it is easy to determine whether a given address is friend or foe. Given a list of known addresses for every potential recipient, including other wallets belonging to oneself, it becomes trivial to determine what the effect of a transaction will be: how much funds are being sent to another party, how much is returned back to the sender as “change” and what fees are paid to miners for the privilege of transacting.

This concept of address whitelisting is now table-stakes for custodial services: users commit to a list of known safe addresses ahead of time and the system does not allow transfers outside of that set. (Of course there has to be some way of adding new entries to the list, and that process is made deliberately high-friction, for example by requiring out-of-band authentication or mandatory 7-day waiting period. The threat model is that even if an attacker can impersonate the legitimate customer or attempts to coerce them into executing a transfer, they can not succeed.)

2. Proof-of-reserves. In PoR a custodial service proves to its customers that they have control of all digital assets entrusted to its safekeeping. This involves two pieces:

  • Proof of liabilities: committing to the BTC balance of every customer in a verifiable manner, including the total balance across the entire customer base
  • Proof of assets: proving that the custodian controls an amount of BTC on the blockchain that is equal or greater than the liabilities.

For all practical purposes, this second step requires not only disclosing addresses but proving that the custodian still has possession of the private keys associated with that address by signing with them. While there have research proposals for doing semi-private proof-of-assets by mixing in an additional “cover” set of addresses to obfuscate the ones controlled by the custodian, it turns out the privacy improvements are limited. A satisfactory proof also requires keeping funds at the existing addresses over which the proof was conducted. If one were to conduct the PoR by moving all funds to new addresses, it would leave open the question of whether the custodian accidentally moved funds to some address they can not control, until the next PoR demonstration when they can be moved again.2

Signature bloat

As noted, the Bitcoin transaction signing format lacks any optimizations to reduce the cost of signing multiple inputs with the same public key. This is hardly noticeable when using ECDSA because both signatures and public-keys are short: public-keys take up 33 bytes with point compression while signatures are around ~70 bytes depending on encoding.

That calculus changes with post-quantum signatures. All of the algorithms standardized as part of the NIST post-quantum cryptography effort have either large signatures, large public-keys or both. NIST Signature Zoo provides a convenient way to compare these schemes, including an option to sort by total size of public-key plus signature. That is the relevant metric for Bitcoin’s existing design where every input is signed independently and contains the full public-key. Among algorithms standardized by NIST so far, the “winner” according to that criteria is ML-DSA. At 3723 bytes for one signature and public-key, it still represents a almost 40-fold expansion in space required— and that is at the lowest acceptable security level by NIST standards. Slightly more promising is Falcon/NTRU scheme, currently pending standardization. It would reduce that overhead to ~1600 bytes, a meaningful improvement over ML-DSA but far from the status quo.

Hash-based signature schemes such as SLH-DSA fare much worse on this metric. Their public-keys are qiute compact— effectively the size of one classical hash— but signatures run into multiple kilobytes. In a world where address reuse is common, this is exactly the wrong trade-off: a public-key can be “cached” on chain to amortize the storage cost of a public-key, but every transaction must still be signed independently. Note these figures assume funds are controlled by a single key: the overhead gets worse when starting to compare more complex configurations such as multi-signature schemes where all possible public-keys must be included in the signature script. 3

Reckoning with address reuse

For Bitcoin to achieve post-quantum security without further degradation of its throughput, there are two paths forward:

  1. Double-down on the hope that address reuse can be eliminated or at least strictly bounded. If one assume only a limited number of transactions are permitted out of each address, there are purpose-built stateful hash-based “few-time” signature algorithms that are more compact than the general NIST-sanctioned stateless hash-based signatures. The trade-off is a highly brittle security model: if the number of transactions is exceeded or state is mismanaged (for example, restoring from a backup resulting in reuse of previously “spent” private-key) the result is a catastrophic failure.
  2. Accept that address reuse is going to be the norm and implement difficult protocol changes to optimize for block space given the demands of post-quantum signatures. This will likely involve a hard-fork to improve transaction verification:
  • Cache redeem scripts in unpruned UTXO, to avoid outputting the same public-key over and over again
  • Allow one signature to cover multiple inputs. This could involve consolidating inputs when they share a redeem script or supporting signature aggregation across inputs. Aggregation is a more generic, powerful technique: it works across messages signed with different keys. But it is also highly dependent on the choice of signature algorithm; not every scheme lends itself to efficient aggregation. Having a “batched” signature cover multiple inputs is more straightforward from a cryptographic perspective as it does not depend on the mathematical structure of the algorithm. On the other hand, it is more complex for interoperability with Bitcoin script, since the spending conditions encumbering an input may include additional logical constraints in addition to a signature check.

CP

1 Interestingly that is no longer true: with the introduction of Bitcoin script, it is possible to generate infinite variants of a script that effectively expresses a spending condition involving the same key. Each of those variants would result in a unique address that looks independent, until the script is revealed at the time of spend.

2 Interestingly the proof-of-reserves requirement also complicates attempts to defend against quantum computers by hiding public-keys until they are spent.

3 Incidentally this discussion ignores speed of signing and verification. As things stand, the Bitcoin blockchain can only sustain a handful of transactions per second. One modern, low-end embedded device can handily out-sign and out-verify the entire network, even with the increased computational requirements of post-quantum algorithms.

Mix-and-match: risks of serial two-factor authentication

Here is a case study from a financial institution that implemented “two-factor authentication” for remote access. Our setting is the type of old-school, on-premise, Windows shop that is nearing extinction: fixed workstations managed through Active Directory, which would have felt right at home in the 1990s along with the Macarena. In a rare concession to the novel idea of employees having to access their work PC while they are not physically in the office (credit COVID for this modern epiphany) the IT department has rolled out a VPN and enabled remote-desktop access. In order to access their assigned workstations, employees jump through two layers of access control:

  1. First, they connect to the corporate VPN, authenticating with their AD domain credentials (username + password) augmented by TOTP two-factor authentication
  2. Once on the VPN, they can use one of the standard remote-desktop clients to connect to their specific workstation, again authenticating with domain credentials.

When this enterprise is going through their ritualistic yearly review of IT controls, an auditor is very likely to ask:

“Does remote access to internal systems require multi-factor authentication?”

Based on the above description, one expects this IT department to confidently respond in the affirmative and the auditors to quickly rubber-stamp that answer after cursory validation.  The subtle flaw in this model— common to legacy systems where second factor authentication has been bolted-on to satisfy some compliance requirement without much consideration for the relevant threat model— is likely to escape notice.

Mix-and-match authentication

The core issue is a disconnect between the two different authentication steps performed in series. There is no consistency check verifying whether the user connected to the VPN is the same one connecting to a specific workstation. In other words, one can connect to the VPN as Alice using Alice’s domain password & OTP credentials, then login to Bob’s workstation using Bob’s domain password. While that may look like an edge case, it points to an intrinsic weakness: once an attacker can fully impersonate any account (second factor included) every other account is only protected by a password alone.

From the threat actor perspective: if the objective is getting access to the documents on the CEO’s workstation, it is not necessary to compromise the CEO’s second-factor authentication. Instead this “mix-and-match” combination is sufficient:

  • Password + 2FA for any random employee
  • Password for the CEO

Does this qualify as two-factor authentication? Under a charitable interpretation, the answer is yes: the attacker still has to satisfy 2FA for some employee. Under a more strict interpretation, it falls short of the intended security guarantee: they did not have to defeat the 2FA associated with the CEO account. Viewed in terms of probabilities, the situation looks much better for the attacker: in a company with thousands of employees, there is a good chance some employee will get phished for both factors or have their device compromised by malware. (At which point, even phishing-resistant authentication is useless; the threat actor can ride the active session once the legitimate user completes authentication using as many convoluted steps as necessary– tapping the hardware security dongle, connecting their smart-card or performing an interpretive dance.)

Mitigations

As with most security challenges, correctly enforcing multi-factor authentication is more challenging than bolting on the half-baked version. There are a few options here, ranging from window-dressing to fully robust:

  • Alerting after the fact: correlate VPN events against remote desktop access events. This will not prevent mix-and-match authentication but it can detect unauthorized access after the fact. Depending on the latency of aggregating logs, detecting anomalies and the maturity level of incident response for the enterprise, there is a fighting chance the breach can be contained before significant damage is done.
  • Enforce two-factor authentication on endpoints. Third-party offerings such as Duo Authentication for Windows Logon allow enforcing MFA as part of the remote-desktop logon, where the presence of the second factor counts the most. (Depending on what is accessible once on the VPN, one could even argue the original design had it completely backwards: if the only thing employees can do is access their own workstation over RDP, they would have been better off with a single-factor VPN while saving the proper MFA enforcement at the endpoint.)
  • Implement proper two-factor authentication at Active Directory layer. This is the most comprehensive solution, based on a little-known fact: AD has supported phishing-resistant two-factor authentication with cryptographic hardware for 20+ years— long before consumer-grade/watered-down FIDO & its ilk existed. Based on the standardized PKINIT extension to Kerberos and smart-cards, this is widely used in high-security environments including the US government CAC & PIV programs. Realistically, the complexity of operating a PKI and issuing smart-cards places this far outside the meager capabilities of most IT departments likely to exist within the confines of a traditional financial institution.

CP