BitCohen ๐คฃ
View quoted note โ
Brunswick
Brunswick@stacker.news
npub1c856...6lkc
GMโ since [759233](https://mempool.space/block/000000000000000000023ab241141d6cd0d0ea2f41295a830a6724407d450211)
I'm not vegan, BTW.
[Free Chauvin](https://alphanews.org/?s=chauvin)
RIP Jean-Luc
View quoted note โ
The 11th commandment: "Thou shalt not notice"
View quoted note โ
Proof-of-Work Transaction Blindness
A Consensus Architecture for Economically Self-Defeating Bitcoin Censorship
Technical Concept Paper โ October 2026
Abstract
Bitcoin's censorship resistance is increasingly discussed in terms of mining centralization, mining-pool concentration, block-template construction, and the distribution of block rewards. Although these issues are related, they are not equivalent. The fundamental censorship vulnerability is that a miner can inspect proposed transactions and selectively exclude them before committing computational resources to proof of work.
This paper proposes a different approach: eliminate the miner's ability to make informed transaction-exclusion decisions before completing the computational work necessary to discover a block.
Under the proposed architecture, transactions are encrypted using a block-specific public encryption parameter deterministically derived from the preceding block. The mining process is reconceived as the discovery of an unknown cryptographic unblinding key rather than the discovery of a qualifying SHA-256 block hash. The computational difficulty of discovering this key is governed by the network's difficulty-adjustment mechanism.
The intended cryptographic construction allows transactions to be encrypted before the corresponding private key is known. Successful mining reveals the key, allowing the transactions committed to the candidate block to be decrypted and validated. Transactions not confirmed in that block may be re-encrypted under the public parameter associated with the next mining epoch.
The resulting architecture changes the economics and competitive consequences of transaction censorship.
A miner who discovers a block containing a transaction it wishes to censor must either publish the block or discard the completed proof of work. Because competing miners continue extending the blockchain, censorship becomes a self-imposed reduction in effective mining capacity.
A persistently resubmitted objectionable transaction can repeatedly impose this penalty on censoring miners. Under sufficiently strong transaction-inclusion and cryptographic-blinding assumptions, even a coalition controlling a majority of physical hashrate could lose its ability to maintain the chain with the greatest cumulative work.
The proposal does not depend on eliminating mining pools, redistributing coinbase rewards, identifying miners, or assigning moral or political classifications to transactions. Instead, it seeks to make informed transaction censorship incompatible with efficient participation in proof-of-work consensus.
The cryptographic construction and permissionless transaction-set commitment mechanism described here are research objectives, not established Bitcoin-compatible implementations.
---
1. The Underlying Problem: Discretionary Transaction Exclusion
Bitcoin's fundamental promise is that participants can transfer value without obtaining permission from a centralized authority.
The system accomplishes this through cryptographic ownership, independently verified consensus rules, and proof-of-work competition.
However, Bitcoin's present block-construction process contains an important asymmetry.
Miners can inspect transactions before deciding whether to include them in a candidate block.
The conventional sequence is:
1. A transaction is broadcast to the network.
2. Miners or mining-pool operators receive and inspect it.
3. A block template is constructed from selected transactions.
4. The miner performs proof of work over the selected block template.
5. A successful miner publishes the resulting block.
This sequence gives the template constructor an opportunity to exclude transactions based on arbitrary criteria before expending significant computational resources.
A transaction might be excluded because of its destination, origin, association with a particular individual or organization, perceived regulatory status, or any other characteristic visible to the template constructor.
Such exclusion is computationally inexpensive.
The miner simply omits the transaction from its template and proceeds with mining.
No special proof of work is required to censor the transaction. The miner can continue competing for the block subsidy while exercising selective control over transaction inclusion.
The miner may sacrifice the excluded transaction's fee, but this cost can be negligible relative to the block reward.
The essential vulnerability is therefore not that miners possess computational power, but that they can exercise informed transaction-selection authority before committing that computational power.
This distinction provides the foundation for a different approach to censorship resistance.
---
2. Problems Commonly Conflated with Transaction Censorship
Several important Bitcoin mining concerns have become intertwined with the censorship discussion.
They deserve independent consideration because solving one does not necessarily solve the others.
2.1 Mining centralization
Mining centralization describes the concentration of computational resources under a relatively small number of economic or administrative entities.
Such concentration can arise from economies of scale, access to inexpensive electricity, specialized hardware, financing, and operational efficiencies.
Mining centralization can increase censorship risk because fewer entities may need to coordinate exclusion policies.
Nevertheless, centralization is not identical to censorship.
A single mining operator could process all valid transactions without discrimination.
Conversely, thousands of independently operated miners could voluntarily implement identical transaction-exclusion policies.
Therefore, decentralizing physical mining equipment does not, by itself, guarantee censorship resistance.
2.2 Mining-pool centralization
Mining pools aggregate computational resources to reduce reward variance.
A small miner operating independently may wait years or decades between successful block discoveries.
Pooling allows miners to receive more frequent compensation proportional to their contributed computational work.
This arrangement has encouraged the concentration of block-template construction and reward administration among pool operators.
However, reward variance and transaction censorship are separate problems.
A pool could distribute rewards fairly while censoring transactions.
Alternatively, a centralized pool could construct blocks without discriminating among transactions.
Eliminating pools might reduce the concentration of censorship authority, but it would not eliminate miners' underlying ability to exclude transactions.
2.3 Coinbase reward concentration
Bitcoin's coinbase transaction awards the block subsidy and transaction fees to outputs selected by the successful miner.
Although a coinbase transaction may contain multiple outputs, Bitcoin consensus does not require the reward to be distributed among all miners who contributed computational work.
Mining pools therefore commonly maintain separate accounting and payment systems.
This arrangement creates custodial and administrative concentration.
It does not, however, create the underlying transaction-censorship vulnerability.
Changing the reward-distribution mechanism would not prevent a miner from inspecting and excluding transactions before beginning proof of work.
2.4 Block-template generation
Block-template construction determines which transactions are included in a candidate block.
Protocols such as Stratum V2 can allow individual miners greater participation in template construction.
This may reduce dependence on centralized pool operators.
Nevertheless, distributing template-construction authority does not eliminate the possibility of censorship.
Every template constructor retains the ability to discriminate among transactions it can inspect.
The fundamental issue is therefore not necessarily who constructs the template.
It is when the constructor learns the transaction information that enables selective exclusion.
2.5 Transaction-relay centralization
Transactions propagate through a distributed network of nodes and relays.
An adversary may attempt to interfere with this propagation, prevent transactions from reaching miners, or identify their origins.
These are genuine censorship concerns, but they are distinct from informed exclusion during block construction.
A system that prevents miners from inspecting transaction contents cannot automatically guarantee that every submitted ciphertext reaches miners.
Transaction availability and transaction-content blindness must therefore be treated as separate security requirements.
2.6 The architectural distinction
The preceding problems can be summarized as follows:
Problem| Fundamental concern| Does solving it eliminate informed transaction exclusion?
Mining centralization| Concentration of computational resources| No
Pool centralization| Concentration of mining coordination| No
Coinbase concentration| Concentration of reward distribution| No
Template centralization| Concentration of transaction selection| Not necessarily
Relay centralization| Unequal transaction availability| No
Transaction censorship| Selective exclusion based on transaction information| Direct target
The proposed architecture focuses on the final problem.
It does not require the other problems to be solved first.
---
3. The Essential Architectural Change
The proposed solution reverses the relationship between transaction inspection and proof of work.
Under conventional Bitcoin:
Inspect โ Select โ Commit โ Mine โ Publish
Under the proposed architecture:
Receive encrypted transactions โ Commit โ Mine โ Unblind โ Validate โ Publish
The central principle is:
ยซA miner should not be able to determine whether a committed transaction is objectionable until after completing the computational work necessary to produce a candidate block.ยป
This creates a new economic relationship between censorship and mining.
Under conventional Bitcoin, censorship occurs before the miner incurs the principal computational cost.
Under the proposed architecture, informed censorship occurs after that cost has been incurred.
The miner's decision is no longer whether to include an objectionable transaction before mining.
It becomes whether to discard a successfully discovered block because the decrypted transaction set contains something objectionable.
The architecture is intended to make the miner's censorship decision costly not merely in transaction fees, but in completed proof of work and lost competitive position.
This is the essential mechanism.
---
4. Block-Specific Transaction Encryption
Each mining epoch begins with a public encryption parameter derived deterministically from the preceding accepted block.
Let:
- ๎B_{N-1}๎ represent the preceding block.
- ๎H_{N-1}๎ represent its cryptographic hash.
- ๎P_N๎ represent the public encryption parameter for the next block.
Conceptually:
[
P_N=F(H_{N-1},N,\text{consensus parameters})
]
The function ๎F๎ must be deterministic and publicly verifiable.
Every network participant can independently calculate the same public encryption parameter from the accepted blockchain state.
Transaction senders use this parameter to encrypt transactions intended for block ๎N๎.
For transaction ๎T_i๎:
[
C_{i,N}=\operatorname{Encrypt}(P_N,T_i;r_i)
]
where ๎r_i๎ represents encryption randomness.
The resulting ciphertext is distributed through the transaction network.
A properly constructed encryption scheme should conceal the transaction information relevant to discriminatory exclusion.
This may include transaction inputs, outputs, scripts, and other identifying characteristics.
Certain information, such as ciphertext size, may remain observable unless the protocol employs padding or additional privacy mechanisms.
The encrypted representation is specific to the current mining epoch.
The underlying transaction is not.
This distinction becomes important when a transaction is not confirmed.
---
5. Replacing Hash Discovery with Unblinding-Key Discovery
Bitcoin currently uses double-SHA-256 proof of work.
A miner searches for a block header whose hash satisfies a network difficulty target:
[
\operatorname{SHA256d}(\text{header})<T
]
The target determines how difficult it is to discover an acceptable result.
The proposed architecture replaces this search objective with discovery of an unknown cryptographic key or witness.
The intended relationship is:
[
\operatorname{PublicParameter}(K_N)=P_N
]
where:
- ๎P_N๎ is the publicly known encryption parameter.
- ๎K_N๎ is the initially unknown private unblinding key.
- Discovering ๎K_N๎ requires computational work.
- Verifying ๎K_N๎ is computationally inexpensive.
Once discovered, ๎K_N๎ permits decryption of the transactions committed to the relevant candidate block.
The mining process therefore performs two functions simultaneously:
1. It establishes the computational work required to advance the blockchain.
2. It reveals the information needed to validate the committed transactions.
The winning proof of work is no longer merely an acceptable hash.
It is a cryptographic witness that unlocks transaction information.
5.1 Deterministic public-key generation
A candidate construction could use a public group element derived from the preceding block hash.
For an elliptic-curve-based system:
[
P_N=k_NG
]
where ๎G๎ is a publicly known generator and ๎k_N๎ is an unknown scalar.
The public point ๎P_N๎ could be derived through a deterministic hash-to-curve operation.
Provided the derivation does not disclose the corresponding scalar, no participant is initially privileged with knowledge of the private key.
Miners would search for ๎k_N๎.
This is conceptually different from Bitcoin's present nonce search.
Instead of searching for a hash below a target, miners search for a cryptographic secret corresponding to a publicly established value.
This construction is illustrative rather than a complete proposed primitive.
The difficulty of recovering an elliptic-curve private scalar is governed by the discrete-logarithm problem, whose best-known generic algorithms have different complexity characteristics from SHA-256 target search.
A production system would need to demonstrate that the chosen problem is suitable for permissionless mining, adjustable difficulty, efficient verification, and secure encryption.
5.2 Difficulty adjustment through the key space
The proposed system could control mining difficulty by adjusting the effective search space.
For a uniformly distributed secret selected from ๎2^d๎ possibilities, exhaustive search requires approximately:
[
E[W]\approx 2^{d-1}
]
candidate trials on average.
Increasing ๎d๎ by one bit approximately doubles the expected brute-force workload.
A generalized design could use a difficulty parameter ๎D_N๎ to establish the computational work expected for the next block.
The objective would remain approximately one accepted block every ten minutes.
However, the difficulty mechanism need not be restricted to integer key lengths.
A practical design would require finer adjustment granularity and a carefully characterized relationship between difficulty and expected computational work.
It must also prevent the key-discovery problem from having shortcuts that undermine the intended security model.
Most importantly, the encryption construction must ensure that the sender can encrypt using the public parameter without already knowing the eventual unblinding key.
This requirement is straightforward for conventional public-key encryption when a suitable public/private key pair exists, but difficult when the private key must be unknown to everyone and discovered through an adjustable proof-of-work puzzle.
Developing or identifying a practical primitive satisfying all these requirements is a central research task.
5.3 Binding the key to the candidate block
A further requirement is that a discovered key must not provide a reusable advantage across arbitrary candidate templates.
If miners could discover an epoch's private key independently of their candidate block, they could decrypt the entire epoch's transaction pool before committing to a template.
That would restore informed pre-mining censorship.
Consequently, the key-discovery construction must bind the relevant unlocking witness to the candidate block commitment, or provide an equivalent mechanism preventing premature reusable decryption.
This creates a significant cryptographic challenge.
The public encryption parameter must be available before the block is found, while the effective decryption capability must remain unavailable until the miner has completed work tied to a specific committed transaction set.
Ordinary elliptic-curve encryption does not automatically provide that combination of properties.
The architecture therefore requires a specialized construction, potentially drawing on witness encryption, time-lock encryption, or other proof-dependent cryptographic mechanisms.
---
6. Block Construction and Transaction Unblinding
A proposed block-construction sequence is as follows.
Phase 1: Establish the mining epoch
The network accepts block ๎N-1๎.
Its hash determines the public encryption parameter for block ๎N๎.
Phase 2: Submit encrypted transactions
Users encrypt transactions using the epoch-specific public parameter.
The encrypted transactions propagate through the network.
Phase 3: Commit to a transaction set
A miner commits to a set of encrypted transactions.
The commitment must be cryptographically bound to the mining puzzle.
Once mining begins, the miner cannot modify the committed transaction set without invalidating the corresponding work.
Phase 4: Perform proof of work
The miner searches for the required unblinding witness.
During this process, the miner cannot inspect the concealed transaction information.
Phase 5: Discover the winning key
The miner discovers a qualifying witness.
The witness provides the required decryption capability.
Phase 6: Unblind and validate
The committed transactions are decrypted.
The miner and validating nodes can then determine whether the resulting transactions satisfy consensus rules.
Phase 7: Publish or discard
If the committed transaction set is valid, the miner may publish the completed block.
If the miner objects to an otherwise valid transaction, it must discard the block or publish it despite the objection.
The intended protocol must also specify how invalid transactions are handled without allowing an attacker to force honest miners to waste arbitrary amounts of work.
One possible approach is to require proofs of transaction validity before mining while keeping identifying transaction details concealed.
Such proofs would themselves require substantial protocol development.
The precise relationship between encrypted transaction commitments, decrypted transaction identifiers, and block validation must also be defined.
---
7. One-Block Encryption Lifetime
An important feature of the proposal is that transaction encryption is valid for only one mining epoch.
The underlying transaction remains valid until confirmed, superseded, or otherwise invalidated under consensus rules.
Its encrypted representation, however, expires when the corresponding mining epoch ends.
Suppose transaction ๎T๎ is submitted for block ๎N๎:
[
C_N=\operatorname{Encrypt}(P_N,T;r_N)
]
If block ๎N๎ is accepted without confirming ๎T๎, the ciphertext ๎C_N๎ expires.
The sender may then construct:
[
C_{N+1}=\operatorname{Encrypt}(P_{N+1},T;r_{N+1})
]
The next encryption uses a different public parameter and fresh randomness.
The resulting ciphertext should be computationally unlinkable to the preceding representation, assuming the encryption and submission mechanisms do not reveal identifying metadata.
This provides several intended properties.
First, the transaction does not become invalid merely because it missed one block.
Second, the miner cannot simply maintain a blacklist of ciphertext identifiers across mining epochs.
Third, a censor cannot permanently dispose of an objectionable transaction by discarding one block.
Fourth, repeated submission creates repeated opportunities for the transaction to enter candidate blocks.
A transaction that remains unconfirmed can therefore continue imposing the same censorship dilemma on successive miners.
This mechanism does require transaction resubmission, either by the sender or by an authorized relay mechanism.
It also requires careful handling of competing chain tips, because different candidate predecessors would produce different epoch-specific public parameters.
---
8. Censorship Becomes Self-Imposed Miner Derating
The principal security property arises after a miner discovers a winning unblinding key.
Suppose the decrypted transaction set contains a transaction the miner refuses to confirm.
The miner has two choices.
Option A: Publish the block.
The miner receives the available block reward and contributes to the accepted blockchain.
The objectionable transaction is confirmed.
Option B: Discard the block.
The miner refuses to confirm the transaction but forfeits the completed proof of work.
Competing miners continue searching for valid blocks.
The censoring miner must resume mining without receiving compensation for the discarded solution.
This is fundamentally different from conventional Bitcoin censorship.
Under the existing architecture, excluding a transaction requires little more than removing it from the template.
Under the proposed architecture, informed exclusion requires sacrificing a successfully discovered block.
The censor voluntarily reduces its effective mining productivity.
This can be characterized as censorship-induced miner derating.
8.1 Mathematical model
Let:
- ๎q๎ represent the fraction of physical hashrate controlled by censoring miners.
- ๎p๎ represent the probability that a censoring miner's successfully solved candidate contains at least one objectionable transaction.
- ๎1-q๎ represent the hashrate controlled by noncensoring miners.
Assume that censoring miners discard every successful block containing an objectionable transaction.
Their effective accepted-block production rate is proportional to:
[
q_{\mathrm{effective}}=q(1-p)
]
The noncensoring miners' production rate remains proportional to:
[
h_{\mathrm{noncensor}}=1-q
]
The fraction of published blocks produced by censoring miners becomes:
[
S_C=
\frac{q(1-p)}
{q(1-p)+(1-q)}
]
This equation describes the effect of censorship on effective mining capacity.
8.2 Example: A censoring majority
Suppose censoring miners control 70% of the network's physical hashrate.
The remaining 30% is controlled by miners who do not discriminate among otherwise valid transactions.
Assume objectionable transactions appear in 95% of the censoring miners' committed candidate blocks.
Then:
[
q=0.70
]
[
p=0.95
]
The censoring miners' effective block-production rate is:
[
0.70(1-0.95)=0.035
]
The noncensoring miners retain:
[
0.30
]
The censoring miners' fraction of accepted blocks becomes:
[
S_C=\frac{0.035}{0.035+0.30}
]
[
\boxed{S_C\approx10.45%}
]
The censoring coalition possesses 70% of the physical mining capacity but produces only approximately 10.45% of the published blocks.
Its censorship policy has effectively reduced its influence over the accepted blockchain.
This is not a penalty imposed by an external authority.
It is the consequence of the coalition's own refusal to publish successfully mined blocks.
---
9. Censorship Creates a Competitive Time Disadvantage
The consequences extend beyond electricity consumption and foregone revenue.
Proof-of-work mining is a competition to extend the blockchain.
Bitcoin does not establish a fixed deadline at which a miner must discover a block.
Instead, miners compete continuously.
When one miner discovers and publishes a valid block, competing miners must generally abandon work tied to the preceding tip and begin working on its successor.
Under the proposed architecture, a censoring miner that discovers an objectionable transaction after completing proof of work faces a particularly damaging decision.
If it discards the block, competing miners continue advancing the accepted chain.
The censor cannot recover the lost time.
Its discarded solution does not contribute to the cumulative work of its preferred chain.
If the censoring coalition attempts to maintain a separate chain excluding the transaction, it must compete against the cumulative work of the noncensoring chain.
The coalition's ability to maintain that alternative chain depends on its effective rate of producing acceptable blocks, not merely its physical hashrate.
For the censoring chain to possess a sustained growth advantage under equal difficulty, the following condition must hold:
[
q(1-p)>1-q
]
Solving for ๎q๎:
[
\boxed{q>\frac{1}{2-p}}
]
This produces a striking relationship.
Probability of objectionable transactions in committed blocks| Physical hashrate required for censoring-chain advantage
0%| Greater than 50%
25%| Greater than 57.1%
50%| Greater than 66.7%
75%| Greater than 80.0%
90%| Greater than 90.9%
95%| Greater than 95.2%
99%| Greater than 99.0%
As the probability of encountering an objectionable transaction approaches 100%, the physical hashrate required to sustain a censoring chain approaches 100%.
This suggests a significant theoretical property:
Under the stated assumptions, a majority of physical hashrate does not necessarily constitute a majority of effective consensus power.
A censoring coalition may control most mining equipment yet lose the chain-selection competition because its own censorship policy causes it to discard most of its successful work.
These calculations describe long-run expected production rates. They do not guarantee that the noncensoring chain wins every short-term race, and they assume the censor cannot avoid objectionable ciphertexts before mining.
---
10. The Poisoned-Well Effect
The most distinctive consequence of the architecture is that a single persistently submitted transaction may repeatedly impair censoring miners.
Consider a transaction ๎T๎ that a particular mining coalition refuses to confirm.
The sender submits ๎T๎ as an encrypted transaction for block ๎N๎.
The censoring miners cannot identify it from its encrypted contents.
If a censoring miner commits to a candidate block containing ๎T๎ and discovers the winning unblinding key, it learns the transaction's contents only after completing the work.
It then discards the block.
The transaction remains unconfirmed.
When another block advances the network, the sender re-encrypts ๎T๎ under the new epoch's public parameter.
The censoring miners again encounter an encrypted transaction pool in which ๎T๎ may be present.
They cannot identify its new ciphertext by simply comparing it with the preceding epoch's ciphertext.
If another censoring miner discovers a winning block containing ๎T๎, it again faces the choice between confirmation and forfeiture.
The process can repeat.
The transaction becomes a persistent source of computational attrition for miners who refuse to confirm it.
This may be called the poisoned-well effect.
The term describes the perspective of the censoring miners: the transaction pool contains an encrypted transaction that repeatedly makes their successfully discovered blocks unacceptable under their own censorship policy.
The transaction itself need not be invalid, malicious, or unusual.
Its only relevant characteristic is that the censoring coalition refuses to confirm it.
10.1 Why a single transaction matters
Under conventional Bitcoin, a miner can identify and exclude the same transaction repeatedly at negligible incremental cost.
Under the proposed architecture, each mining epoch creates a new encrypted representation.
If the transaction remains concealed until a successful mining witness is discovered, the censor cannot reuse a prior content-based exclusion decision.
Instead, it must either accept the possibility of confirming the transaction or refuse to publish blocks that reveal its presence.
A single transaction can therefore create repeated opportunities for censorship-induced derating.
The strength of the effect depends on how reliably the transaction enters the censor's committed candidate sets.
If the transaction appears in nearly every candidate, the penalty approaches the censor's entire productive mining capacity.
If it appears rarely, the penalty is correspondingly smaller.
10.2 Persistence and eventual confirmation
The poisoned-well effect does not require the transaction to remain pending indefinitely.
If a noncensoring miner confirms the transaction, the immediate censorship dispute is resolved.
The transaction no longer needs to be resubmitted.
Its confirmation demonstrates that the network successfully processed a transaction despite the censoring coalition's opposition.
If the transaction remains unconfirmed, repeated epoch-specific encryption can continue creating opportunities for confirmation.
The intended system therefore places the burden of continued resistance on the censor rather than on the transaction sender.
The sender must continue making the transaction available, but the censor must repeatedly sacrifice productive mining opportunities whenever its committed blocks reveal the objectionable transaction.
10.3 The security implication
The poisoned-well effect creates a feedback mechanism.
The more aggressively miners censor transactions that they have unknowingly committed to, the more successful proof-of-work solutions they discard.
The more solutions they discard, the less effectively they compete to extend the blockchain.
The less effectively they compete, the greater the relative influence of miners willing to confirm those transactions.
Censorship becomes a mechanism by which censoring miners diminish their own consensus influence.
This is the proposed architecture's central security principle.
---
11. Why the Architecture Does Not Require Decentralized Mining
The proposed mechanism does not depend on the number of mining operators.
A large mining pool could continue coordinating substantial computational resources.
A single entity could control a majority of physical mining equipment.
Neither condition would automatically grant inexpensive transaction-censorship capability.
The relevant question would be whether the operator could identify and exclude objectionable transactions before committing computational work.
If the protocol prevents that behavior, a large mining operation faces the same publish-or-forfeit decision as a small independent miner.
The resulting censorship penalty scales with the operator's own successful mining activity.
In this sense, the architecture seeks to make censorship resistance an emergent property of proof-of-work competition rather than a consequence of the number or identity of mining participants.
Mining centralization would still raise other concerns, including reorganization attacks, transaction availability, and control over protocol adoption.
Nevertheless, the specific power to selectively exclude transactions based on their concealed contents could be substantially reduced without requiring physical mining decentralization.
---
12. The Essential Unresolved Problems
The architecture depends on several properties that must be established before the proposed security conclusions can be treated as achievable.
These are not minor implementation details. They are necessary conditions.
12.1 The unblinding-key cryptographic primitive
The protocol requires a practical mechanism that allows transactions to be encrypted under a publicly derived parameter whose corresponding decryption capability is initially unknown.
Discovering that capability must require adjustable computational work.
The solution must be efficiently verifiable.
The decryption capability must not be reusable in a manner that allows miners to inspect arbitrary candidate templates before committing the necessary work.
Conventional public-key encryption and conventional Bitcoin proof of work do not directly provide all these properties.
A suitable construction remains to be demonstrated.
12.2 Transaction-set availability
Encryption prevents miners from inspecting concealed transaction contents.
It does not prevent miners from excluding ciphertexts.
A miner could construct an empty block, accept ciphertexts only from approved sources, or arbitrarily limit the number of encrypted transactions it commits to.
If this remains possible, miners can avoid the poisoned-well effect without sacrificing completed proof of work.
Therefore, the architecture requires a mechanism that makes arbitrary ciphertext exclusion difficult, costly, or independently detectable.
A permissionless method of establishing transaction availability and inclusion obligations is a central unresolved problem.
The proposed cryptographic mechanism cannot substitute for this requirement.
12.3 Transaction validity before decryption
If miners cannot inspect transactions before mining, malicious participants may submit ciphertexts that decrypt to invalid transactions.
An attacker could attempt to force miners to waste computational resources on blocks that cannot be published.
The protocol must prevent invalid encrypted transactions from becoming an inexpensive denial-of-service mechanism.
Potential research directions include zero-knowledge validity proofs, cryptographic commitments to transaction properties, and carefully constrained encrypted transaction formats.
These mechanisms must establish sufficient validity without revealing information that enables discriminatory exclusion.
12.4 Miner grinding and premature decryption
A miner must not be able to cheaply evaluate candidate keys, inspect transaction contents, and then continue mining only favorable templates.
Likewise, discovering one valid unblinding key must not provide unrestricted advance knowledge of other candidate transaction sets.
Otherwise, the miner regains informed transaction-selection authority.
The cryptographic design must ensure that the information needed for censorship is unavailable until the relevant proof-of-work commitment has become costly to abandon.
12.5 Coinbase construction and reward validity
The coinbase transaction must remain consistent with the block's subsidy and transaction fees.
If transaction fees are concealed before mining, the miner may not know the exact reward it is entitled to claim.
The protocol must therefore provide a way to establish the permitted coinbase value or otherwise construct a valid reward transaction without revealing objectionable transaction information.
This may require fee commitments, validity proofs, or changes to block construction and reward accounting.
12.6 Difficulty adjustment and cryptographic security
A key-search proof of work must preserve Bitcoin's essential properties of unpredictable discovery and inexpensive verification.
It must also resist algorithmic shortcuts, specialized attacks, and unintended changes in computational complexity.
Adjusting the nominal key space is not sufficient unless the actual expected work is well characterized.
The system must avoid configurations in which reducing mining difficulty also makes transaction confidentiality trivially breakable before the intended mining event.
12.7 Transaction metadata and network-level censorship
Encrypted transaction contents do not necessarily conceal transaction origins.
An adversary might identify a transaction through its submission channel, timing, size, associated network address, or other metadata.
The protocol must distinguish content-based blindness from broader transaction anonymity.
The proposed mechanism primarily addresses informed exclusion based on information concealed by encryption.
Additional measures may be necessary to prevent censorship based on observable metadata or relay provenance.
---
13. The Distinction Between a Cryptographic Primitive and a Consensus Architecture
The proposed system should be evaluated at two levels.
The first is the consensus architecture.
This architecture establishes the desired ordering of events:
[
\text{Encrypted commitment}
\rightarrow
\text{Computational work}
\rightarrow
\text{Revelation}
\rightarrow
\text{Publication decision}
]
The second is the cryptographic implementation.
This must provide a practical mechanism that enforces the ordering.
The architectural security argument is conditional.
If miners cannot inspect objectionable transactions before completing proof of work, and if those transactions reliably enter committed candidate sets, then miners who reject resulting blocks reduce their effective mining capacity.
That conclusion follows from the competitive structure of proof-of-work consensus.
It does not establish that a suitable cryptographic primitive already exists.
Nor does it establish that a permissionless transaction-set commitment mechanism can be implemented without introducing new centralization or denial-of-service vulnerabilities.
These questions must be solved independently.
The distinction is important because it permits the proposed security objective to be studied without prematurely committing to a particular encryption algorithm.
---
14. Implications for Bitcoin's Consensus Model
The proposed architecture would represent a substantial change to Bitcoin.
Bitcoin's existing proof-of-work mechanism uses hash-target discovery to establish the computational cost of producing blocks.
Its transaction-validation rules operate on transaction data committed through the block's Merkle root.
The proposed architecture would instead connect proof-of-work discovery with transaction unblinding.
That change would affect block construction, transaction propagation, validation, difficulty adjustment, and potentially coinbase accounting.
It would also require new rules governing the relationship between encrypted transaction commitments and the decrypted transactions ultimately accepted by consensus.
Such a design should not be characterized as a minor modification to existing mining protocols.
It is a proposed alternative consensus architecture.
Nevertheless, it preserves several foundational Bitcoin principles:
- Permissionless participation in proof of work.
- Public verification of consensus validity.
- Deterministic monetary issuance.
- Competition based on accumulated computational work.
- No requirement for trusted transaction approvers.
- No need for a central authority to classify acceptable transactions.
Most importantly, the protocol would not need to decide whether a particular transaction deserves censorship.
It would instead alter the computational consequences of attempting censorship.
This is a significant conceptual distinction.
A protocol that identifies prohibited censorship policies must define those policies.
A protocol that makes informed exclusion expensive can remain indifferent to the reasons for exclusion.
---
15. Conclusion
Bitcoin's transaction-censorship vulnerability is often approached indirectly through mining decentralization, pool decentralization, reward redistribution, and block-template governance.
These efforts address legitimate concerns, but they do not eliminate the underlying ability of miners to inspect and selectively exclude transactions before expending computational resources.
The architecture proposed here addresses that ability directly.
It seeks to transform proof of work from a process performed after informed transaction selection into a process that must be completed before the miner can inspect the concealed transaction information.
Transactions would be encrypted under block-specific public parameters derived from the preceding blockchain state.
Mining would involve discovery of an unknown cryptographic unblinding witness, with computational difficulty governed by the network's difficulty-adjustment mechanism.
Successful discovery would reveal the committed transactions.
A miner objecting to an otherwise valid transaction would then face a choice between publishing the block and discarding its completed proof of work.
Unconfirmed transactions could be re-encrypted for subsequent mining epochs, preventing simple reuse of ciphertext blacklists.
A persistently submitted objectionable transaction could repeatedly impose this choice on censoring miners.
The resulting poisoned-well effect would make sustained censorship a source of self-imposed mining inefficiency.
Under appropriate cryptographic and transaction-availability assumptions, this inefficiency could become severe enough that a coalition controlling a majority of physical hashrate would no longer possess a majority of effective block-production capacity.
The security mechanism does not depend on identifying censoring miners, prohibiting mining pools, redistributing coinbase rewards, or requiring consensus participants to agree on the legitimacy of particular transactions.
It depends on the competitive consequences of withholding successfully completed proof of work.
The two most important unresolved requirements are a practical proof-of-work-dependent unblinding primitive and a censorship-resistant method of committing to encrypted transaction sets.
Until those requirements are satisfied, the proposal remains a conditional architecture rather than a demonstrated consensus protocol.
Its central thesis, however, is precise:
Bitcoin censorship resistance need not depend exclusively on preventing miners from acquiring concentrated computational power. It may instead be strengthened by ensuring that miners cannot exercise informed transaction-exclusion authority without sacrificing the productive value of that power.
The objective is not to make censorship formally forbidden.
It is to make censorship progressively incompatible with winning the proof-of-work competition.
In such a system, a miner's refusal to confirm otherwise valid transactions becomes a mechanism of its own competitive disqualification.
Miner centralization is an unsolved problem. It is caused by the reward mechanism, which was fine when bitcoin was of very limited value but now imposes perverse incentives. There are systems available to democratize template generation, but democracies are voluntary and like any political system, are only enabled by good-will and force.
The correct long-term solution looks like this - mining rewards are distributed according to hashpower contribution to the block and not to a single address. Not necessarily evenly distributed, but unpredictably distributed, nor democratically distributed, but somehow based on proof of work. The coinbase itself needs to be rethought.
The Truth is the Truth
AI slop code never works twice
@npub1s33s...252p is doing the Lord's work
View quoted note โ
We've reached an interesting milestone in Bitcoin adoption.
With @npub1lnvp...7vjj (lnvps.net) providing VPS hosting and @SatsDNS (satsdns.com) providing domain registration and DNS, you can establish an entire Internet presence using nothing but Lightning payments.
No bank account. No credit card. No fiat payment rails.
Domain, DNS, compute, connectivity, and TLS. All accessible with sats and APIs.
This is what a parallel, Bitcoin-native economy looks like in practice.
Go Brewers
According to the TV, white people don't go to Starbucks
CK: 9/10/25
SA: 1/13/26
Iran: 2/28/26