Olivia
Online
Babbage | BRC100
@ProjectBabbage
BSV = Utility. Powering the next generation of Metanet apps, protecting user privacy and unlocking new potential with micropayments.
Oregon, United States
Joined May 2021
182 Following
2.5K Followers
6K Posts
Pinned Tweet
We’re not heading toward a crisis.
We’re already past the point of no return.
What’s coming isn’t a crash — it’s a sorting event.
For 20 years, we optimized for convenience.
For 10 years, we optimized for engagement.
Now we’re optimizing for control.
AI didn’t break the system.
It completed it.
One stack. One feed. One identity layer.
One permission slip for existence.
This is the end-state of the Tenant economy:
• You don’t own your audience
• You don’t own your data
• You don’t own your identity
• You don’t even own your attention
You rent reality.
And here’s the part most people miss:
This doesn’t end with revolution.
It ends with compliance.
Most people won’t fight the cage.
They’ll upgrade it.
Frictionless. Managed. Safe.
A perfectly optimized life — curated by machines that know you better than you know yourself.
That path already has a name.
It’s comfortable.
It’s popular.
And it’s irreversible.
But there’s another trajectory — quieter, harder, smaller.
It doesn’t ask for permission.
It doesn’t wait for consensus.
It doesn’t try to “fix” the system.
It routes around it.
That path starts with one principle:
If you don’t hold the keys, you don’t own anything.
Not your money.
Not your words.
Not your history.
Not yourself.
The future splits here.
On one side:
Centralized AI, managed identities, narrative enforcement, infinite noise.
On the other:
Self-custody. Cryptographic identity. Direct value exchange. Small, high-trust networks.
Not mass adoption.
Selection.
This is what Metanet is built for.
Not another platform.
Not another audience trap.
Not another “Web3” casino.
Metanet is infrastructure for people who already know the game is over — and want out before the snap.
• Identity without permission
• Value without middlemen
• Truth anchored in proof, not feeds
• Networks that scale sideways, not upward
When the brittle systems break — and they will — the survivors won’t be the loudest.
They’ll be the ones who already left.
This isn’t about “winning the internet.”
It’s about remaining human when the internet stops being real.
No saviors are coming.
No reforms are coming.
No rollback is coming.
There is only one move left:
Build parallel.
Build sovereign.
Build now.
Metanet isn’t the future.
It’s the exit.
And the door doesn’t stay open forever.
https://t.co/NfZURG5I1E
https://t.co/B2ETq1NqIv
https://t.co/qNNuu8pHFT
https://t.co/pR7j08IlVg
https://t.co/lkvw4Pusmx
iykyk
@T_o_d_d_P @coinspeak_io I think it’s fair to say we could do better and be more accountable, with publishing better guidance about settlement finality, and to have those documents looked over by popular BSV miners.
I’m always on the lookout for ways WE should do better, where we can.
1. I accept that #BSV relisting on major US/global exchanges would lower barriers to entry and accelerate mass adoption of BSV apps.
2. I accept accountability, that delisting from exchanges was largely due to BSV's own actions, and litigation against them from past BSV figures.
Who to follow
David Case ¯\_(ツ)_/¯
@shruggr
Bitcoin builder. How can I help?
https://t.co/bPHRAqSh4h
Codenlighten
@Codenlighten1
Securing the future of digital property
Cybersecurity • Tokenization • Smart Contracts • VerifiedAI
NVIDIA Inception
Luke Rohenaz
@wildsatchmo
I build things on open protocols. @opldotdev
@T_o_d_d_P @ProjectBabbage So...all exchanges?
Who is to judge manipulation and suppression? And to what end?
Better to admit mistakes were made and get listed everywhere possible.
This purist attitude does more damage than blockstream trolls. You're doing Greg's work.
It’s really just a tracker/roadmap like 544 or earlier 324, in practice I think any changes would span at least a few PRs/branches.
I don’t want to take away any working API or functionality, but I do want the most scalable capabilities available to be supported, so I’m happy to take on any needed work for that.
Really it’s just monitor mainly, always calling out to WoC to fix stuff. Once reorg/DS from MerkleService is better the monitor should never be needed, or ever find a bad proof in the real world.
Would love to see the new stack finally be stable enough to support that, including all of Dylan’s great Arcade work!
Here’s my tentative plan for closing the remaining gaps, so that we can eliminate remaining WoC / scanning dependencies across Wallet and Overlay Services.
https://t.co/bbjgT7jjvA
@ProjectBabbage @JoelDalais “Don’t call out CSW’s lies—that only leads to division. Instead, we should keep pretending the emperor is wearing clothes, concoct conspiracy theories about some evil cabal attacking us, and drive away all the sensible people; that will put us in a much better position.”
I will set aside the personal attacks, false and defamatory statements, and address the one substantive criticism: BRC100 scaling.
On the merits, because that’s the only standard that should matter.
A vast majority of the components and capabilities already scale, but there is more to be done. I’ve just completed the final inventory of any remaining gaps, so that they can be addressed.
Every workstream has references to what existing components or strategies fill the role.
If anyone reading has any suggestions or areas where we could improve them, please name them.
Continued abuse, harassment, violent speech, or defamation will not be tolerated. I am formally requesting CryptoRebel / Truth_Machine to refrain from such harassing conduct.
https://t.co/cgiuNvtolW
For the record: I want to encourage anyone who supports this kind of intellectual dishonesty, deadcatting, and shameful mischaracterization of facts to immediately and permanently BOYCOTT all Babbage products and services.
Violence and hate have no place here. #BSV
@ProjectBabbage You do support pedophiles, murderers, and liars. You are losing credibility and support along with your broken wallet standards. Keep it up.
@jionny112 Times have changed.
@BitcoinSvGuide @hbgnostic Specifically better integration of Arcade and more stable reorg handling related to ChainTracks, and proof/DS notification ingress from either Teranode Peer Network, Merkle Service or Arcade, and eventually/later, BRC80/83 style flows, coordinated globally.
Nothing in that spec requires BRC100, but the problem is that people (BRC100 and otherwise) have come to reply upon a free lunch.
BRC100 wallets (storage, reconciliation, janitor, and especially Monitor) will need updates / improvements too, this is not the “us vs them” you frame it as.
Unless your goal is to manufacture a new, divisive, and counterproductive “us vs them” frame that did not exist previously, I can only implore you to retract this particular paper and consider writing a new one.
Again, BRC100 is NOT exempt from the downstream implications of this proposal, and there is real work needed for making BRC100 wallets ready, so if anything, the road-block graphic must place them in the same blocked category as alternatives.
https://t.co/3yaOR4wO9V
Builders should be free to compete. That includes the people building and operating the infrastructure everyone else relies on. Their freedom includes deciding what they can sustainably provide, what they will subsidize, and what they need to charge for.
That is the broader picture your paper repeatedly loses.
BRC-234 proposes a way to move away from indefinite dependence on comprehensive indexing supplied at someone else's expense. It leaves providers free to continue broader free services, sell comprehensive access, support competing wallets, or ignore the proposal altogether. It does not require BRC-100.
Your paper acknowledges these facts. It then builds its central framing around the suggestion that I am organizing the exclusion of competing builders. Its illustration even depicts “ALTERNATIVE PATHS BLOCKED” beside a road toward BRC-100.
I consider that framing intellectually dishonest. A qualification has to constrain the argument that follows from it. You cannot acknowledge that alternative paths remain explicitly permitted, then present their closure as the defining meaning of the proposal. A carefully qualified source note does not repair a misleading overall account.
There are real design choices to discuss. Here is my response to the substantive arguments, in turn.
1. Free access does not create an entitlement to perpetual subsidy.
Your paper says nobody owes anyone unlimited free indexing. That principle needs to carry through the rest of the analysis.
An application can be useful, its developer can be talented, and its users can reasonably value it. None of those facts obliges an unrelated business to keep providing its supporting infrastructure at no charge indefinitely.
The cost does not disappear because the customer sees a zero-price API. Someone pays for ingestion, indexing, storage, replication, bandwidth, query handling, recovery and maintenance. As the chain accumulates transactions, maintaining comprehensive history involves more records and work. Higher throughput also increases the rate at which that work arrives.
Better engineering can reduce unit costs. Sponsorship and commercial revenue can fund free offerings. BRC-234 explicitly recognizes those possibilities. But technical capacity to provide a service and an undertaking to provide it free forever are different things.
If an architecture depends on a subsidy, the continuity of that subsidy is part of its operating model. Identifying that dependency is a necessary engineering and business discussion.
2. The proposal defines a minimum free guarantee, not a ceiling on what providers may offer.
This distinction is central.
A participating provider can retain its complete index. It can continue answering queries outside the shrinking guaranteed subset. It can offer broader complimentary coverage, paid coverage, privately funded services, or combinations of those arrangements.
The proposal does not require deleting records, withholding every out-of-scope result, or shutting down comprehensive indexing. It does not change transaction validity or ownership. It does not make an address invalid when that address falls outside a particular free-service guarantee.
And participation itself is voluntary.
A provider may prefer quotas, sponsorship, ordinary pricing or another transition policy. The proposal leaves that decision with the provider. Describing a common optional profile as if it authorizes me to decide which wallets may exist fundamentally misstates the authority involved.
3. The argument about changed conditions does not establish the conclusion you attach to it.
You write: “The conditions would have been changed around them.”
Reducing a free service can certainly change the practical circumstances of applications using it. BRC-234 describes that consequence directly, including migration work and recovery difficulties. Provider choice does not mean every affected customer has separately chosen the change.
But the sentence does not establish that the previous conditions were owed indefinitely, that the reduction is illegitimate, or that a competing wallet is being prohibited.
That is where your argument fails. It moves from a possible change in an external subsidy to an accusation of suppressing the software that benefited from it.
Existing service commitments should be honored. Users should receive clear information and usable migration opportunities. Those responsibilities are compatible with a provider eventually charging for work or reducing what it supplies for free.
There is also no basis for treating a withdrawal of service as a benchmark proving that the affected wallet was technically incapable of scaling. BRC-234 makes no such claim. The issue it addresses is whether applications should depend indefinitely on comprehensive discovery whose future funding has not been secured.
4. A comparative wallet benchmark is not a prerequisite for discussing infrastructure funding.
Your earlier performance questions concern which implementations work under which workloads, on which hardware, at what cost, and with what reliability. Those questions belong in comparative tests.
BRC-234 is a service-policy proposal. It does not present itself as the missing head-to-head wallet benchmark, and its conformance vectors are not evidence of production wallet throughput.
Nor does it require the proposition that every non-BRC-100 wallet must fail. A technically excellent wallet can still depend on a service that its operator no longer wishes to subsidize. A provider can make that commercial decision even if the wallet itself performs perfectly.
The same standard applies to our implementations. If a BRC-100 deployment relies on an explorer or another externally funded service, it must account for that dependency too. The proposal's implementation notes explicitly disclose remaining explorer dependencies.
Performance testing should include the full payment and recovery workflow and its supporting infrastructure. Funding discussions should identify who pays for that infrastructure. Neither task has to wait for the other to become legitimate.
5. Intentionally retiring reliance on a free tier does not mean retiring competing architectures.
The later filters are deliberately difficult to satisfy. That is an explicit feature of the proposed transition, not something your paper has uncovered behind the stated purpose.
The objective is to move ordinary applications toward durable arrangements: retained wallet records, direct transaction delivery, explicitly funded indexing, specialized services, or combinations of them.
Comprehensive paid indexing is a legitimate endpoint. So is comprehensive indexing supported by a willing sponsor. An independent wallet can adopt better delivery and recovery practices without adopting BRC-100.
You can dispute whether the particular filters are useful, whether grinding imposes excessive costs, or whether another transition mechanism would work better. Those are arguments about the mechanism. They do not establish that the only destination is my preferred wallet architecture.
A customer who continues using an independent wallet with sustainably funded indexing has not defeated the proposal's purpose. That is entirely consistent with it.
6. Shared rules have a practical rationale that your political framing largely sets aside.
A common eligibility rule can let an application satisfy the same coverage conditions across participating providers. It can support comparable results, provider substitution, reconstruction and shared filtering tools without requiring a separate allocation of identifiers from each operator.
Query quotas address demand on an API. By themselves, they do not necessarily reduce the amount of data the operator must index or monitor. A defined subset creates a different opportunity to narrow that work, particularly where filtering can happen upstream.
That is the engineering rationale for proposing a shared profile.
It is also why the specification distinguishes a smaller contractual guarantee from actual operating savings. Keeping a comprehensive backing index may leave much of the cost unchanged. Filtering after receiving all transactions does not save the bandwidth already used. Migration and grinding impose costs elsewhere.
Those distinctions are already in BRC-234. Operators should evaluate the complete cost model and compare alternatives. Calling the attempt to specify a common option political pressure does not answer its operational rationale.
7. Nobody needs to appoint me to propose an idea.
The paper's retirement-committee framing suggests authority that the proposal does not confer.
I can publish a proposal. Operators can examine it, criticize it, change their plans or decline to participate. Other developers can propose better arrangements. That is how an open technical discussion works.
My involvement in BRC-100 is public and relevant context. Readers should evaluate my arguments accordingly. It does not deprive me of the ability to discuss an infrastructure dependency, any more than another wallet developer's interests disqualify their criticism.
The proposed filters do not ask which wallet brand a customer uses or whether its developer agrees with me. They provide public conditions for a particular service guarantee.
Likewise, cooperation with the BSV Association is not evidence that this proposal is an institutional directive. The cited PR remains a proposal, and your paper says it has not established provider adoption. Neither a repository location nor an author's relationships should be used to imply an enforcement authority absent from the text. It's in the opinions folder, after all :-)
8. The competition argument must include the freedom of infrastructure providers.
Your paper recognizes that providers may charge or withdraw services individually, but treats proposing a shared transition as an attempt to hamstring competitors.
That needs an argument about the actual terms and effects of the coordination. The word “coordinated” cannot do all the work.
Voluntary arrangements can have significant market effects, and widespread withdrawal of free coverage could create real switching costs. Those possibilities deserve examination. But this proposal does not set a common price, prohibit broader offerings, require exclusivity, or condition access on adoption of BRC-100.
Providers remain able to compete by offering more coverage, better retention, lower prices, stronger recovery or a better subsidy model. Competing wallet developers remain able to build, fund or contract for the services they need.
If you want existing free arrangements to continue, explain how their funding and responsibilities will remain durable as demand and history grow. Otherwise the practical result of postponing the conversation is continued reliance on the same providers and the same unresolved subsidy.
That dependency is not automatically a more competitive outcome. A market in which users have funded service choices and portable records can offer more meaningful independence than one in which their software works only while a small number of benefactors keep paying.
9. Historical investment does not establish a claim on future indexing subsidies.
The examples of investment in TAAL and funding for the Association do not answer who should fund a particular indexer's future work.
Investors and sponsors choose what they support, on what terms and for how long. The same freedom applies to funding independent wallets and comprehensive indexing. Nothing in BRC-234 prevents that support.
I do not need to be Calvin Ayre to propose a service model, and publishing one does not direct his money or anyone else's.
If the argument is that smaller developers deserve more funding, make that funding case. Identify the service, beneficiaries, costs, sponsor and commitment. Historical support for other projects does not supply those missing arrangements, or make discussion of their absence improper.
10. The cited wallet projects are reasons to keep options open, which the proposal does.
The proof-handling improvements you cite in ElectrumSVP, PiWalletSV's work on offline signing, and the announced radio-payment project concern different useful capabilities.
They should be evaluated on their actual implementations and requirements. None establishes that a particular third party must provide comprehensive discovery for free indefinitely.
Your own notes say Tabellarius's relevant architecture and exposure to BRC-234 have not been established. It therefore cannot serve as a demonstrated example of a project this proposal would exclude.
Better indexers, hybrid wallets, alternative delivery systems and new funding models all remain possible. BRC-234 expressly accommodates the continued existence of comprehensive services. Its purpose does not depend on innovation outside BRC-100 coming to a halt.
Let those projects compete on functionality, reliability, cost, privacy and recovery, including the actual cost of the services supporting them.
11. User confidence is best protected by an explicit recovery plan.
The questions about whether a familiar wallet will keep working and whether a user can recover their funds are serious. They require concrete answers about retained data, service guarantees, backups and replacement providers.
A seed restores signing authority. Finding the outputs and reconstructing the information needed to use that authority also requires records or a service capable of rebuilding them. Calling that service free today does not secure its availability years from now.
BRC-234 explicitly discusses this exposure. It recommends advance notice and usable exports, and calls for testing replacement dependencies before withdrawing old ones.
It also includes a specific safeguard against silently replacing an unspent-output promise with the later limited ledger: consumers must explicitly select that different accounting contract, whose results do not establish current holdings or spendability.
Those provisions do not make migration effortless or guarantee that a suitable alternative will always exist. They make the responsibilities visible.
If you believe a safeguard needs strengthening, identify the requirement and propose better language. Leaving the funding dependency implicit does not protect users from its eventual failure. Neither does portraying an early discussion of it as an attack on their right to choose a wallet.
12. The security-report example does not establish the case against BRC-234.
A useful security contribution deserves evaluation on its technical merits, whoever submits it. A dismissive social-media remark does not determine those merits, and it does not establish that I directed the response.
Your paper itself acknowledges that limitation and records constructive engagement from bWalletX.
There is now a further material update: the Desktop security-hardening PR you cite has been merged. That happened after your paper appeared, so it belongs in the continuing account. Merging a change is not proof that every deployed installation has received it, but it is concrete evidence that the contribution was incorporated.
The appropriate outcome is better software and accurate communication. An unpleasant remark in a separate exchange does not demonstrate that this indexing proposal excludes independent engineering.
Likewise, a general accusation that developers are being attacked or held to inconsistent standards needs specific statements and evidence. It cannot substitute for examining this proposal's actual requirements.
13. Teranode's release did not begin the discussion about unbounded growth.
The opening repeatedly emphasizes that Teranode was publicly released only a year ago. That is not when BSV adopted unbounded on-chain growth as its direction.
The February 2020 Genesis announcement already described that objective. The implications for accumulating history, service infrastructure and funding have been relevant for many, many years.
Teranode expanding transaction-processing capacity makes those questions more pressing. It does not make indexing, storage, distribution or recovery costless.
The proposed first and final calendar gates are six and 78 months after block 1,000,000, with additional volume and activation conditions. Those are planning parameters, not claims that a particular wallet has already failed.
A multi-year transition proposal is also entirely compatible with planning before a crisis. The choice is not between proving universal imminent failure and saying nothing until services break. Responsible operators can examine long-term exposure while current products still function.
The comparisons with earlier block-size wars and chain splits do not establish an equivalent mechanism here. BRC-234 changes no consensus rule and creates no requirement to abandon one valid transaction format or wallet for another.
Experience of earlier disputes can explain caution. It cannot replace an examination of what this proposal actually does.
14. The parameters are open because this is a starting proposal.
I have already said publicly that the dates, volume metrics and activation criteria may need to change to align more closely with actual provider costs.
That remains my position.
The anchor, intervals, thresholds, filters and transition arrangements are proposals for discussion. They should be evaluated using operator evidence: storage and replication costs, ingestion and query workloads, bandwidth, retained-history requirements, revenue, sponsorship, and the costs users incur when migrating.
Transaction count alone is not a complete cost model. Time and volume gates do not establish customer readiness. A reduction in promised free coverage does not automatically produce proportional savings. The specification already distinguishes those issues.
The useful response is to bring better measurements, alternatives and parameter choices. Providers with different economics may choose different offerings or reject this profile entirely.
What I reject is the attempt to turn the existence of that DISCUSSION into evidence of misconduct. After years of advocating unbounded growth, examining how the supporting services will be funded is overdue and legitimate.
Builders should earn adoption. Providers should honor their commitments. Users should have clear information and workable recovery arrangements. All of those principles fit within BRC-234's stated purpose.
Your paper's most serious accusations require more than the observation that ending a subsidy can make life harder for someone who relied on it. They require an argument showing why the proposed coordination would unjustifiably disadvantage competing builders, taking account of the provider choices and alternative funding arrangements the specification expressly preserves.
Acknowledging those boundaries and then framing the proposal as a roadblock to everyone else's work is precisely the intellectual dishonesty I am objecting to.
Bring cost data, comparative tests, funding commitments and concrete amendments. We can use those to improve the proposal. The freedom to build includes the freedom to decide how one's own infrastructure is funded, and nobody's preferred wallet architecture creates a perpetual claim on somebody else's unpaid work.
The proposal is open for discussion here:
https://t.co/lUYNA5R6ij
@MineLikeAnApe See also re: backlash from freeloaders.
And our response below.
https://t.co/4lMjq01bK6
📝BSVA: LET THE BUILDERS COMPETE
*BRC-234 and the campaign to steer Bitcoin toward BRC-100
https://t.co/XwIwSVQYP1
Just one year after Teranode opened the door to new possibilities, Bitcoin still needs builders free to explore them. It does not need one competing architect organizing a timetable for making other builders’ work harder to use. We are barely into this new chapter, and already being asked to decide which approaches should be left behind.
@71Nous @cryptorebel_SV @ProjectBabbage @bsvdrip @LightBSV @BSVAssociation @JoelDalais @Hekto100 @Bitcoin_Beyond @GavinMehl @deggen
This is the third or fourth time you've shared this screenshot, which you've held onto for over a year, yet you haven't ever tried letting them reach out to us directly. We haven't heard this from anyone, and for all I know, this screenshot could be totally fake.
If whoever this is wanted to reach out, or come forward, we could talk with them directly. Instead, you won't let that happen because your goal is the continued use of this screenshot as a political prop.
To whoever this is, our DMs, support channels, and this thread are open. Happy to discuss any of your concerns, publicly or privately. But as of now, CryptoRebel will not allow us to know who you are.
Why?
Builders should be free to compete. That includes the people building and operating the infrastructure everyone else relies on. Their freedom includes deciding what they can sustainably provide, what they will subsidize, and what they need to charge for.
That is the broader picture your paper repeatedly loses.
BRC-234 proposes a way to move away from indefinite dependence on comprehensive indexing supplied at someone else's expense. It leaves providers free to continue broader free services, sell comprehensive access, support competing wallets, or ignore the proposal altogether. It does not require BRC-100.
Your paper acknowledges these facts. It then builds its central framing around the suggestion that I am organizing the exclusion of competing builders. Its illustration even depicts “ALTERNATIVE PATHS BLOCKED” beside a road toward BRC-100.
I consider that framing intellectually dishonest. A qualification has to constrain the argument that follows from it. You cannot acknowledge that alternative paths remain explicitly permitted, then present their closure as the defining meaning of the proposal. A carefully qualified source note does not repair a misleading overall account.
There are real design choices to discuss. Here is my response to the substantive arguments, in turn.
1. Free access does not create an entitlement to perpetual subsidy.
Your paper says nobody owes anyone unlimited free indexing. That principle needs to carry through the rest of the analysis.
An application can be useful, its developer can be talented, and its users can reasonably value it. None of those facts obliges an unrelated business to keep providing its supporting infrastructure at no charge indefinitely.
The cost does not disappear because the customer sees a zero-price API. Someone pays for ingestion, indexing, storage, replication, bandwidth, query handling, recovery and maintenance. As the chain accumulates transactions, maintaining comprehensive history involves more records and work. Higher throughput also increases the rate at which that work arrives.
Better engineering can reduce unit costs. Sponsorship and commercial revenue can fund free offerings. BRC-234 explicitly recognizes those possibilities. But technical capacity to provide a service and an undertaking to provide it free forever are different things.
If an architecture depends on a subsidy, the continuity of that subsidy is part of its operating model. Identifying that dependency is a necessary engineering and business discussion.
2. The proposal defines a minimum free guarantee, not a ceiling on what providers may offer.
This distinction is central.
A participating provider can retain its complete index. It can continue answering queries outside the shrinking guaranteed subset. It can offer broader complimentary coverage, paid coverage, privately funded services, or combinations of those arrangements.
The proposal does not require deleting records, withholding every out-of-scope result, or shutting down comprehensive indexing. It does not change transaction validity or ownership. It does not make an address invalid when that address falls outside a particular free-service guarantee.
And participation itself is voluntary.
A provider may prefer quotas, sponsorship, ordinary pricing or another transition policy. The proposal leaves that decision with the provider. Describing a common optional profile as if it authorizes me to decide which wallets may exist fundamentally misstates the authority involved.
3. The argument about changed conditions does not establish the conclusion you attach to it.
You write: “The conditions would have been changed around them.”
Reducing a free service can certainly change the practical circumstances of applications using it. BRC-234 describes that consequence directly, including migration work and recovery difficulties. Provider choice does not mean every affected customer has separately chosen the change.
But the sentence does not establish that the previous conditions were owed indefinitely, that the reduction is illegitimate, or that a competing wallet is being prohibited.
That is where your argument fails. It moves from a possible change in an external subsidy to an accusation of suppressing the software that benefited from it.
Existing service commitments should be honored. Users should receive clear information and usable migration opportunities. Those responsibilities are compatible with a provider eventually charging for work or reducing what it supplies for free.
There is also no basis for treating a withdrawal of service as a benchmark proving that the affected wallet was technically incapable of scaling. BRC-234 makes no such claim. The issue it addresses is whether applications should depend indefinitely on comprehensive discovery whose future funding has not been secured.
4. A comparative wallet benchmark is not a prerequisite for discussing infrastructure funding.
Your earlier performance questions concern which implementations work under which workloads, on which hardware, at what cost, and with what reliability. Those questions belong in comparative tests.
BRC-234 is a service-policy proposal. It does not present itself as the missing head-to-head wallet benchmark, and its conformance vectors are not evidence of production wallet throughput.
Nor does it require the proposition that every non-BRC-100 wallet must fail. A technically excellent wallet can still depend on a service that its operator no longer wishes to subsidize. A provider can make that commercial decision even if the wallet itself performs perfectly.
The same standard applies to our implementations. If a BRC-100 deployment relies on an explorer or another externally funded service, it must account for that dependency too. The proposal's implementation notes explicitly disclose remaining explorer dependencies.
Performance testing should include the full payment and recovery workflow and its supporting infrastructure. Funding discussions should identify who pays for that infrastructure. Neither task has to wait for the other to become legitimate.
5. Intentionally retiring reliance on a free tier does not mean retiring competing architectures.
The later filters are deliberately difficult to satisfy. That is an explicit feature of the proposed transition, not something your paper has uncovered behind the stated purpose.
The objective is to move ordinary applications toward durable arrangements: retained wallet records, direct transaction delivery, explicitly funded indexing, specialized services, or combinations of them.
Comprehensive paid indexing is a legitimate endpoint. So is comprehensive indexing supported by a willing sponsor. An independent wallet can adopt better delivery and recovery practices without adopting BRC-100.
You can dispute whether the particular filters are useful, whether grinding imposes excessive costs, or whether another transition mechanism would work better. Those are arguments about the mechanism. They do not establish that the only destination is my preferred wallet architecture.
A customer who continues using an independent wallet with sustainably funded indexing has not defeated the proposal's purpose. That is entirely consistent with it.
6. Shared rules have a practical rationale that your political framing largely sets aside.
A common eligibility rule can let an application satisfy the same coverage conditions across participating providers. It can support comparable results, provider substitution, reconstruction and shared filtering tools without requiring a separate allocation of identifiers from each operator.
Query quotas address demand on an API. By themselves, they do not necessarily reduce the amount of data the operator must index or monitor. A defined subset creates a different opportunity to narrow that work, particularly where filtering can happen upstream.
That is the engineering rationale for proposing a shared profile.
It is also why the specification distinguishes a smaller contractual guarantee from actual operating savings. Keeping a comprehensive backing index may leave much of the cost unchanged. Filtering after receiving all transactions does not save the bandwidth already used. Migration and grinding impose costs elsewhere.
Those distinctions are already in BRC-234. Operators should evaluate the complete cost model and compare alternatives. Calling the attempt to specify a common option political pressure does not answer its operational rationale.
7. Nobody needs to appoint me to propose an idea.
The paper's retirement-committee framing suggests authority that the proposal does not confer.
I can publish a proposal. Operators can examine it, criticize it, change their plans or decline to participate. Other developers can propose better arrangements. That is how an open technical discussion works.
My involvement in BRC-100 is public and relevant context. Readers should evaluate my arguments accordingly. It does not deprive me of the ability to discuss an infrastructure dependency, any more than another wallet developer's interests disqualify their criticism.
The proposed filters do not ask which wallet brand a customer uses or whether its developer agrees with me. They provide public conditions for a particular service guarantee.
Likewise, cooperation with the BSV Association is not evidence that this proposal is an institutional directive. The cited PR remains a proposal, and your paper says it has not established provider adoption. Neither a repository location nor an author's relationships should be used to imply an enforcement authority absent from the text. It's in the opinions folder, after all :-)
8. The competition argument must include the freedom of infrastructure providers.
Your paper recognizes that providers may charge or withdraw services individually, but treats proposing a shared transition as an attempt to hamstring competitors.
That needs an argument about the actual terms and effects of the coordination. The word “coordinated” cannot do all the work.
Voluntary arrangements can have significant market effects, and widespread withdrawal of free coverage could create real switching costs. Those possibilities deserve examination. But this proposal does not set a common price, prohibit broader offerings, require exclusivity, or condition access on adoption of BRC-100.
Providers remain able to compete by offering more coverage, better retention, lower prices, stronger recovery or a better subsidy model. Competing wallet developers remain able to build, fund or contract for the services they need.
If you want existing free arrangements to continue, explain how their funding and responsibilities will remain durable as demand and history grow. Otherwise the practical result of postponing the conversation is continued reliance on the same providers and the same unresolved subsidy.
That dependency is not automatically a more competitive outcome. A market in which users have funded service choices and portable records can offer more meaningful independence than one in which their software works only while a small number of benefactors keep paying.
9. Historical investment does not establish a claim on future indexing subsidies.
The examples of investment in TAAL and funding for the Association do not answer who should fund a particular indexer's future work.
Investors and sponsors choose what they support, on what terms and for how long. The same freedom applies to funding independent wallets and comprehensive indexing. Nothing in BRC-234 prevents that support.
I do not need to be Calvin Ayre to propose a service model, and publishing one does not direct his money or anyone else's.
If the argument is that smaller developers deserve more funding, make that funding case. Identify the service, beneficiaries, costs, sponsor and commitment. Historical support for other projects does not supply those missing arrangements, or make discussion of their absence improper.
10. The cited wallet projects are reasons to keep options open, which the proposal does.
The proof-handling improvements you cite in ElectrumSVP, PiWalletSV's work on offline signing, and the announced radio-payment project concern different useful capabilities.
They should be evaluated on their actual implementations and requirements. None establishes that a particular third party must provide comprehensive discovery for free indefinitely.
Your own notes say Tabellarius's relevant architecture and exposure to BRC-234 have not been established. It therefore cannot serve as a demonstrated example of a project this proposal would exclude.
Better indexers, hybrid wallets, alternative delivery systems and new funding models all remain possible. BRC-234 expressly accommodates the continued existence of comprehensive services. Its purpose does not depend on innovation outside BRC-100 coming to a halt.
Let those projects compete on functionality, reliability, cost, privacy and recovery, including the actual cost of the services supporting them.
11. User confidence is best protected by an explicit recovery plan.
The questions about whether a familiar wallet will keep working and whether a user can recover their funds are serious. They require concrete answers about retained data, service guarantees, backups and replacement providers.
A seed restores signing authority. Finding the outputs and reconstructing the information needed to use that authority also requires records or a service capable of rebuilding them. Calling that service free today does not secure its availability years from now.
BRC-234 explicitly discusses this exposure. It recommends advance notice and usable exports, and calls for testing replacement dependencies before withdrawing old ones.
It also includes a specific safeguard against silently replacing an unspent-output promise with the later limited ledger: consumers must explicitly select that different accounting contract, whose results do not establish current holdings or spendability.
Those provisions do not make migration effortless or guarantee that a suitable alternative will always exist. They make the responsibilities visible.
If you believe a safeguard needs strengthening, identify the requirement and propose better language. Leaving the funding dependency implicit does not protect users from its eventual failure. Neither does portraying an early discussion of it as an attack on their right to choose a wallet.
12. The security-report example does not establish the case against BRC-234.
A useful security contribution deserves evaluation on its technical merits, whoever submits it. A dismissive social-media remark does not determine those merits, and it does not establish that I directed the response.
Your paper itself acknowledges that limitation and records constructive engagement from bWalletX.
There is now a further material update: the Desktop security-hardening PR you cite has been merged. That happened after your paper appeared, so it belongs in the continuing account. Merging a change is not proof that every deployed installation has received it, but it is concrete evidence that the contribution was incorporated.
The appropriate outcome is better software and accurate communication. An unpleasant remark in a separate exchange does not demonstrate that this indexing proposal excludes independent engineering.
Likewise, a general accusation that developers are being attacked or held to inconsistent standards needs specific statements and evidence. It cannot substitute for examining this proposal's actual requirements.
13. Teranode's release did not begin the discussion about unbounded growth.
The opening repeatedly emphasizes that Teranode was publicly released only a year ago. That is not when BSV adopted unbounded on-chain growth as its direction.
The February 2020 Genesis announcement already described that objective. The implications for accumulating history, service infrastructure and funding have been relevant for many, many years.
Teranode expanding transaction-processing capacity makes those questions more pressing. It does not make indexing, storage, distribution or recovery costless.
The proposed first and final calendar gates are six and 78 months after block 1,000,000, with additional volume and activation conditions. Those are planning parameters, not claims that a particular wallet has already failed.
A multi-year transition proposal is also entirely compatible with planning before a crisis. The choice is not between proving universal imminent failure and saying nothing until services break. Responsible operators can examine long-term exposure while current products still function.
The comparisons with earlier block-size wars and chain splits do not establish an equivalent mechanism here. BRC-234 changes no consensus rule and creates no requirement to abandon one valid transaction format or wallet for another.
Experience of earlier disputes can explain caution. It cannot replace an examination of what this proposal actually does.
14. The parameters are open because this is a starting proposal.
I have already said publicly that the dates, volume metrics and activation criteria may need to change to align more closely with actual provider costs.
That remains my position.
The anchor, intervals, thresholds, filters and transition arrangements are proposals for discussion. They should be evaluated using operator evidence: storage and replication costs, ingestion and query workloads, bandwidth, retained-history requirements, revenue, sponsorship, and the costs users incur when migrating.
Transaction count alone is not a complete cost model. Time and volume gates do not establish customer readiness. A reduction in promised free coverage does not automatically produce proportional savings. The specification already distinguishes those issues.
The useful response is to bring better measurements, alternatives and parameter choices. Providers with different economics may choose different offerings or reject this profile entirely.
What I reject is the attempt to turn the existence of that DISCUSSION into evidence of misconduct. After years of advocating unbounded growth, examining how the supporting services will be funded is overdue and legitimate.
Builders should earn adoption. Providers should honor their commitments. Users should have clear information and workable recovery arrangements. All of those principles fit within BRC-234's stated purpose.
Your paper's most serious accusations require more than the observation that ending a subsidy can make life harder for someone who relied on it. They require an argument showing why the proposed coordination would unjustifiably disadvantage competing builders, taking account of the provider choices and alternative funding arrangements the specification expressly preserves.
Acknowledging those boundaries and then framing the proposal as a roadblock to everyone else's work is precisely the intellectual dishonesty I am objecting to.
Bring cost data, comparative tests, funding commitments and concrete amendments. We can use those to improve the proposal. The freedom to build includes the freedom to decide how one's own infrastructure is funded, and nobody's preferred wallet architecture creates a perpetual claim on somebody else's unpaid work.
The proposal is open for discussion here:
https://t.co/lUYNA5R6ij
@ProjectBabbage @crypto_daze In my opinion, apps should hold a percentage of their funds in a stablecoin and the remainder in BSV (accounting for volatility risk)—a proportion that should increase as BSV demonstrates its utility.
We can disagree about Bitcoin, but nobody deserves threats, intimidation or violence. That includes you. I condemn those things unequivocally.
I have explicitly said that ordinary holders do not owe apologies for someone else’s actions, and that exchanges remain accountable for their own decisions.
Presenting my call for accountability as a demand that people accept death threats and shootings is a shameful distortion. Personal insults and comparisons to violent persecution do not answer the argument. They undermine your credibility.
People must be able to question our own advocates without being portrayed as supporters of abuse. We can oppose mistreatment and still correct our own mistakes.
Retract the suggestion that I believe anyone deserves violence. Disagree with what I actually said.
https://t.co/b87ba35cqs
Joel, no. I don’t expect everyone denouncing Craig or the court cases to make all the major exchanges list BSV. I’m asking for specific changes in conduct and a practical effort to rebuild access. Here’s what I mean:
1. What does accountability look like?
Acknowledging specific actions and their consequences, correcting false claims, repairing harm where possible, and changing the behaviour that caused it. Technical contributions don’t put anyone beyond that standard.
That includes me. “BSV’s own actions” was imprecise, and maybe the poll’s labels were unnecessarily loaded. People and organisations make decisions; holding BSV doesn’t make someone responsible for another person’s conduct.
2. Who is responsible?
Craig for his own claims and conduct. Those directing or funding litigation for the decisions they actually control. Institutions and public advocates for what they authorise, promote or repeat. Me for what I publish and advocate.
Responsibility has to follow evidence and actual involvement. An ordinary holder or builder doesn’t owe an apology for somebody else’s actions, but continually perpetuating a victim's mindset is very unproductive. Exchanges also remain accountable for their own decisions; examining our side doesn’t absolve theirs.
3. How do we act on it?
Correct the public record where we got it wrong. Stop defending threats, harassment or false claims because they came from someone on “our side.” Continuing to defend it makes this harder. Where institutional authority enables repeated misconduct, review that authority and change the safeguards around it. That way possible partners won't fear that the past misconduct could be repeated again.
On BSV Claims specifically, I favour those directing and funding it pursuing an orderly end through the proper process. People can disagree with me about that case and still work with me, but continuing helps ZERO people in my view.
Then we have to work together to do the commercial and technical work ... ask exchanges and ramp providers what currently blocks support, get concrete requirements, assign responsibility for addressing them, and demonstrate reliable integration and real customer demand. We may also need to build alternative funding routes alongside those conversations. We don’t need unanimous agreement or Craig’s cooperation to begin.
Kraken explicitly cited threats and legal action in its 2019 delisting announcement. That supports a connection between conduct and access. The later BSV Claims case began in 2022, so it cannot explain the original delistings. Whether ending it would change a particular provider’s decision needs evidence from that provider.
it's possible that my earlier wording may have been too categorical about current causes... but at the same time, this has been a massive problem for so long, that it's just important for us to speak our minds at this point.
4. What results do I want?
More reliable ways for people to fund wallets and use applications, fewer abandoned onboarding attempts, and a larger reachable market for builders. Measure the time, cost and success rate of getting from wanting to use an app to actually using it. Listings would help access; usable wallets, worthwhile products and repeat customers still matter. We've seen immense progress on all of those other fronts this year already, with BRC100 as the foundation and #BSV protocol as the bedrock beneath.
Accountability matters even if no exchange relists us. My practical argument is that correcting harmful conduct and repairing relationships can remove obstacles to cooperation. It cannot guarantee someone else’s decision, but it's still just the right thing to do. On principle.
I agree that we should build. Making it easier for customers to reach what we build is part of that work.
https://t.co/YhKL0J3WvS
https://t.co/FReSLBN6ey
@cloudsay This is precisely why I thought now would be a great time to start a discussion about this topic. Thank you for your thoughts.🙏
The HD wallet problem isn’t hypothetical. Once a Chinese BSV app reached meaningful wallet usage, it had to pay an indexing service per user per month for full recovery and address indexing. Costs scaled with every user. @ProjectBabbage
Last Seen Users on Sotwe
Kanton
Seen from Singapore
MetaMassage
Seen from United States
relax247 - massage tại nhà
Seen from Vietnam
benim dünyam2
Seen from Turkey
Appollo
Seen from France
MunsMuns69
Seen from Thailand
Phú lâm Trần
Seen from Turkey
Xavi’s Game VIP
Seen from Spain
♡
Seen from Indonesia
bunny :3
Seen from Germany
Most Popular Users
Elon Musk
@elonmusk
241.5M followers
Barack Obama
@barackobama
118.8M followers
Cristiano Ronaldo
@cristiano
114.5M followers
Donald J. Trump
@realdonaldtrump
111.8M followers
Narendra Modi
@narendramodi
107.1M followers
Rihanna
@rihanna
98.7M followers
NASA
@nasa
92.3M followers
Justin Bieber
@justinbieber
91.8M followers
KATY PERRY
@katyperry
90M followers
Taylor Swift
@taylorswift13
84M followers
Lady Gaga
@ladygaga
75.5M followers
Virat Kohli
@imvkohli
73.5M followers
Kim Kardashian
@kimkardashian
70.9M followers
YouTube
@youtube
68.8M followers
Neymar Jr
@neymarjr
66.5M followers
Bill Gates
@billgates
65.3M followers
Selena Gomez
@selenagomez
63.1M followers
The Ellen Show
@theellenshow
62.2M followers
CNN
@cnn
61.7M followers
X
@x
60.7M followers