BBSV.place
Local evidence search

Find the claim. Inspect the answer.

Search across the hard questions, candid limits, inspection steps, and resource desk. No account and no search profile.

Search happens in your browser. We do not receive or store what you type.

91 guides, field notes, briefs, proof records, definitions, and resources available.

  1. Mechanism guide · Mining and settlementMining incentives and economic acceptanceProducing a block, checking it and accepting a payment are different decisions. Hashpower makes production possible and competing histories costly. Credible, coordinated rejection can reduce a profit-seeking attacker’s realizable payoff. That depends on actual enforcement, compatible settlement policies and continued accepted mining; one participant’s refusal cannot guarantee agreement.Content updated 2026-10-05 · Source scope inside
  2. Mechanism guide · Governance and responsibilityStewardship and authority in an open systemA shared system needs maintainers and coordination. Those responsibilities can be distributed across institutions with different scopes. The useful test is whether another competent participant can understand the rules, inspect a decision and continue the relevant work. BSV’s published Association powers remain real dependencies; plural stewardship is a standard to demonstrate, not evidence that concentration has disappeared.Content updated 2026-10-05 · Source scope inside
  3. Case study · Wallets and compatibilityWhen a conforming wallet still breaks an applicationA common wallet interface gives applications a shared way to request operations. It does not guarantee that every wallet policy, version and user workflow works together. The October 4 Zanaadu report and maintainer acknowledgment expose that gap. A repair needs an identified release and a successful workflow retest; neither an interface pass nor a constructive exchange proves resolution.Content updated 2026-10-05 · Source scope inside
  4. Decision guide · Applications and evidenceWhen a shared ledger helps an IoT recordA shared ledger can help independent parties inspect a common commitment and accepted ordering without relying only on the original application’s database. It cannot make a sensor truthful or preserve missing records. Use it when that verification benefit justifies its costs and dependencies; a signed database log or transparency service may be the better design.Content updated 2026-10-05 · Source scope inside
  5. Evidence brief · History & reputationDoes the BSV case depend on Craig Wright being Satoshi?No. A wallet, protocol rule, transaction proof, or application does not become correct because of a person's biography. Craig Wright's identity campaign shaped BSV's reputation, and that cost cannot be wished away. But a serious evaluation can acknowledge the history, decline the identity claim, and test the present system directly.Content updated 2026-10-05 · Source scope inside
  6. Evidence brief · InstitutionsIs BSV captured by a small set of institutions and patrons?BSV has visible institutional concentration: the Association describes a stewardship role and the published Network Access Rules assign it rule and directive functions. That does not establish control over every builder. Independent responsibility becomes credible when projects disclose their dependencies and demonstrate usable challenge, continuity and replacement paths.Content updated 2026-10-05 · Source scope inside
  7. Evidence brief · Trust & reputationHow should a serious person respond to the “scam” or “cult” label?Do not answer contempt with demands for loyalty. Translate the label into testable questions: What was promised? What works now? Who benefits? What is the user's risk? Which claims failed? Can the user leave? Evidence cannot prove that every participant is sincere, but a product can avoid manipulative patterns by making bounded claims, exposing dependencies, and offering a low-risk test path.Content updated 2026-10-05 · Source scope inside
  8. Evidence brief · AdoptionWhere are the users?BSV has live infrastructure, applications, wallets, and inspectable transactions. Those facts establish availability, not broad adoption. A credible adoption case needs defined active users, retention cohorts, successful workflows, economic activity, time windows, bot treatment, and independently checkable methods. Until that exists, say exactly what can be verified and keep the broader claim unresolved.Content updated 2026-10-05 · Source scope inside
  9. Evidence brief · Product fitDoes anything economically need BSV?Most software does not need a blockchain. BSV is worth considering only where its particular tradeoffs improve a real workflow—for example, pay-per-request APIs, independently verifiable event records, or user-authorized cross-application actions. Even then, the comparison is against ordinary databases, payment processors, and other ledgers on cost, latency, privacy, reliability, governance, and exit risk.Content updated 2026-10-05 · Source scope inside
  10. Evidence brief · Builder strategyDoes building on BSV create unacceptable reputational risk?A builder can lose credibility by inheriting claims they never needed. The safer path is to lead with the user problem, state that BSV is the present rail, disclose governance and license dependencies, avoid price and identity claims, and provide a runnable proof plus an exit map. That does not eliminate reputational exposure; it makes the product legible on its own merits.Content updated 2026-10-05 · Source scope inside
  11. Evidence brief · Protocol identityIs BSV “really Bitcoin”?BSV shares Bitcoin ancestry and argues that its design better preserves scalable peer-to-peer cash, script, SPV, and miner-set limits. BTC has the dominant market and social claim to the Bitcoin ticker and name. A person need not settle that naming dispute to compare current protocols: inspect chain history, rules, fees, proof model, governance, software, and use.Content updated 2026-10-05 · Source scope inside
  12. Evidence brief · Protocol identityIs “Satoshi's Vision” a defensible description?If “Satoshi's Vision” means scalable peer-to-peer electronic cash using proof of work, SPV, script, and fees, it names a design interpretation that can be compared with the paper and software. If it means that every BSV institutional, legal, or licensing choice was authored or mandated by Satoshi, it overclaims. Builders are usually better served by naming the specific design property.Content updated 2026-10-05 · Source scope inside
  13. Evidence brief · Consensus & securityCan nodes reject a longer proof-of-work chain and still claim Bitcoin rules?Block production, independent verification and economic acceptance are different jobs. A non-miner can check and refuse a result; it cannot produce replacement blocks or force everyone else to agree. Credible, coordinated rejection can reduce a profit-seeking attack’s payoff, conditional on enforcement, compatible settlement policies and continued accepted mining. The current BSV rules also assign institutional directive powers that need separate scrutiny.Content updated 2026-10-05 · Source scope inside
  14. Evidence brief · Asset recoveryCan BSV freeze or reassign coins?Yes, the Network Access Rules list directives that may freeze specified UTXOs, reassign frozen coins, alter peer access, or invalidate specified blocks after defined events. A reassignment enforced by nodes is not the same mechanism as forging the owner's signature or learning a private key, but it can change which spend the network accepts. That weakens pure bearer finality and creates legal-process and governance dependencies.Content updated 2026-10-05 · Source scope inside
  15. Evidence brief · GovernanceDoes the BSV Association function as a central authority?The Association is not merely an informal developer group. Its own materials describe protocol stewardship, and the NAR treat it as a party with rule and directive functions. Nodes still operate infrastructure and perform proof of work, but that does not erase the institutional layer. People who require authority-minimized bearer money may reject it; others may value explicit commercial rules. Both should evaluate the actual documents.Content updated 2026-10-05 · Source scope inside
  16. Evidence brief · Market accessDo delistings and weak liquidity make BSV unusable?Exchange listings, fiat ramps, depth, spreads, withdrawals, custody, accounting, and jurisdictional access can determine whether a BSV product is viable. They are not merely price complaints. Exposure depends on the workflow: a treasury or exchange product has far greater risk than an application that acquires small fee inventory and converts frequently. Never rely on a static exchange list.Content updated 2026-10-05 · Source scope inside
  17. Evidence brief · Messaging disciplineDo price and “flippening” narratives invalidate the builder case?Token price cannot validate a protocol claim, and a protocol demo cannot justify a price forecast. Combining them makes it harder for users to distinguish utility from financial promotion. A builder case should stand on workflow outcomes, total cost, reliability, user control, security, and adoption—while treating any treasury exposure as a disclosed risk.Content updated 2026-10-05 · Source scope inside
  18. Evidence brief · Messaging disciplineWhy does BSV discourse so often feel tribal or abusive?Public technical communities often form identities, but builders are not obliged to inherit the worst behavior of one. The useful discipline is simple: do not amplify contempt, do not require faction membership, answer the strongest concern, link proof, name gaps, and leave low-substance fights alone. A calm page cannot fix the entire culture, but it can set a different interaction contract.Content updated 2026-10-05 · Source scope inside
  19. Evidence brief · Product proofWhat can a skeptical person actually try?A useful first test is not ‘join the ecosystem.’ It is: open a documented app, connect a compatible wallet, inspect the requested permission, perform one low-value action, and inspect the resulting wallet history, transaction, or proof. The quickstarts, Builder Lab, public BRCs, and TypeScript stack provide starting points. They still need maintained fixtures and independent reproduction reports.Content updated 2026-10-05 · Source scope inside
  20. Evidence brief · Developer experienceIs BSV too complicated to build on?The stack has many concepts because it covers keys, transactions, permissions, identity, storage, proofs, payments, and distributed application state. That breadth is not an excuse for a poor first run. A credible onboarding path should produce one wallet-mediated result with a minimal API, explain the trust boundary in plain language, and defer protocol acronyms until the builder needs them.Content updated 2026-10-05 · Source scope inside
  21. Evidence brief · Wallets & standardsIs BRC-100 real interoperability or one vendor's interface?BRC-100 specifies wallet actions, signatures, encryption, certificates, permissions, baskets, and discovery. The current TypeScript monorepo includes wallet tooling and a growing language-neutral conformance corpus. That is more than a private API, but it does not settle vendor neutrality. Credible interoperability requires independent implementations, published coverage, negative tests, version handling, and a compatibility matrix.Content updated 2026-10-05 · Source scope inside
  22. Evidence brief · PortabilityCan users actually leave a wallet, app, or overlay?A user may control signing keys while still depending on one wallet database, hosted overlay, certificate issuer, lookup service, or application schema. BRC-100 and the overlay stack define useful interfaces, but each product must prove what is exportable, intelligible, restorable, and replaceable. The honest output is a layer-by-layer exit matrix and a tested migration.Content updated 2026-10-05 · Source scope inside
  23. Evidence brief · Scale & economicsIs BSV scaling real, or a datacenter marketing claim?BSV deliberately moves heavy validation and storage toward specialized block producers while expecting most applications to use headers, Merkle proofs, and services. Teranode source and a public testnet runner now make implementation more inspectable. A vendor or testnet benchmark still does not establish sustained mainnet throughput, economically useful demand, competitive block production, or reproducibility on disclosed hardware.Content updated 2026-10-05 · Source scope inside
  24. Evidence brief · SecurityWhat do hashpower and reorganization history mean for BSV security?Hashpower affects the cost of competing histories and remains essential to continuing production. Economic acceptance also matters: credible, coordinated rejection can deny a profit-seeking attacker’s intended payoff. Its success depends on actual enforcement and compatible policies, with sabotage and coordination failure still possible. Inclusion proofs do not establish absolute finality or current unspent status.Content updated 2026-10-05 · Source scope inside
  25. Evidence brief · Ecosystem accountabilityWhy have so many funded BSV projects disappeared?No one should defend every funded project. A grant, accelerator place, press release, repository, demo, maintained product, retained user base, and sustainable business are different statuses. The current BSV Hub and GitHub organizations provide discovery surfaces, but their labels need independent verification. A durable inventory should name owner, funding disclosure, last verified date, live proof, maintainer, license, and shutdown state.Content updated 2026-10-05 · Source scope inside
  26. Evidence brief · Design tradeoffsIs BSV just a cheap database for spam?BSV permits a broader use of transaction outputs and script than a money-only design. For workflows needing public timestamping, payment-linked events, or verifiable commitments, cheap blockspace can be useful. It is usually a mistake to publish private or bulky application data merely because fees are low. Good designs put only the minimum verification material on-chain and price the long-term externalities.Content updated 2026-10-05 · Source scope inside
  27. Evidence brief · Wallet trust modelCan miners, the chain, or an app sign as me or read my private data?Under the published wallet model, applications request operations from a wallet; the wallet holds or controls user key material and permissions. Miners validate transactions and order accepted history. The NAR can affect UTXO treatment at the network layer. None of those facts, by itself, gives a miner or Association the private keys needed to produce a user's application signature or decrypt properly protected data. Implementation bugs, wallet compromise, and poor permission design remain real risks.Content updated 2026-10-05 · Source scope inside
  28. Evidence brief · Architecture & contingencyDoes Project Babbage depend too heavily on the BSV rail?Project Babbage builds a wallet-mediated application model around BRCs, keys, payments, certificates, and overlays currently anchored to BSV. Some concepts and application data can be portable; transaction history, satoshi-denominated payments, proof semantics, BSV-only code, and deployed services may not be. The responsible architecture is to label every boundary, minimize irreplaceable hosted dependencies, export user-controlled material, and maintain contingency triggers.Content updated 2026-10-05 · Source scope inside
  29. Field note · Proof and preservationA Merkle Proof Is a Receipt, Not a BackupA retained transaction and Merkle proof establish inclusion relative to a particular block. They do not alone establish current accepted inclusion, finality, unspent status or data availability. Keep the bytes, application context and recovery plan, and separately check the current history and spend evidence needed for the task.Content updated 2026-10-05 · Source scope inside
  30. Proof record · legal recordCOPA v Wright official recordThe court's published findings and stated reasons are directly inspectable.
  31. Proof record · governance recordNetwork Access Rules and enforcement surfaceThe Association publishes an explicit node-governance agreement.
  32. Proof record · standardPublic BRC specification corpusWallet, identity, payment, proof, and overlay interfaces are publicly versioned and inspectable.
  33. Proof record · codeCurrent BSV TypeScript implementation stackSDK, wallet, overlay, messaging, middleware, helper, and infrastructure source is inspectable in a current monorepo.
  34. Proof record · codeLanguage-neutral conformance vectorsA shared vector format, coverage record, runners, and parity material exist.
  35. Proof record · codeTeranode source and public testnet runnerTeranode is publicly inspectable software rather than only a future architecture claim.
  36. Proof record · live flowWallet-mediated application quickstartA documented path exists for a builder to exercise wallet-mediated operations.
  37. Proof record · live flowMetanet Academy Builder LabAn ungated architecture and diagnostic learning path is live.
  38. Proof record · network dataLive block and transaction inspectionCurrent blocks and transactions can be inspected through a third-party explorer.
  39. Proof record · live flowOfficial BSV demo catalogThe Association publishes a discovery catalog linking demos and repositories.
  40. Glossary · GlossaryBRCA Bitcoin Request for Comments: a public specification or proposal in the BSV BRC corpus.
  41. Glossary · GlossaryBRC-100The unified wallet-to-application interface covering wallet actions, signatures, encryption, certificates, permissions, baskets, and discovery.
  42. Glossary · GlossaryBEEFA transaction-data format used to carry a transaction together with information needed to evaluate its ancestry and proofs.
  43. Glossary · GlossarySPVSimplified Payment Verification: checking relevant transactions with block headers and Merkle evidence without maintaining the complete block database.
  44. Glossary · GlossaryMerkle proofA compact path showing that a transaction or item is committed by a particular Merkle root, such as one in a block header.
  45. Glossary · GlossaryUTXOAn unspent transaction output: a spendable output governed by a locking script and the network's accepted rules.
  46. Glossary · GlossaryNARThe Network Access Rules published by the BSV Association for the relationship among the Association and participating nodes.
  47. Glossary · GlossaryDARDigital Asset Recovery: the ecosystem term for processes intended to support freezing and reassignment of disputed or recoverable BSV through node-enforced rules.
  48. Glossary · GlossaryDirectiveA signed instruction contemplated by the Network Access Rules and delivered to nodes through the alert mechanism after specified events.
  49. Glossary · GlossaryProof of workThe expenditure evidenced by finding a block hash below a target, used to make history costly to rewrite and to coordinate ordering among valid blocks.
  50. Glossary · GlossaryChainworkThe accumulated proof-of-work represented by a chain of block headers.
  51. Glossary · GlossaryReorganizationA change in the accepted chain tip that removes one or more previously accepted blocks and replaces them with another branch.
  52. Glossary · GlossaryWallet actionA BRC-100 request for a wallet to create, sign, internalize, list, or otherwise manage an application-related operation.
  53. Glossary · GlossaryBasketA wallet-level organization mechanism for outputs associated with an application or purpose.
  54. Glossary · GlossaryIdentity keyA public-key identity used in BRC-103 authentication and related wallet-mediated interactions.
  55. Glossary · GlossaryCertificateA signed claim about a subject that can be selectively exchanged and verified in BRC-oriented identity flows.
  56. Glossary · GlossaryCounterpartyThe other party in a wallet key-derivation, payment, signature, encryption, or authenticated-message relationship.
  57. Glossary · GlossaryOverlayAn application-specific service layer that admits, tracks, indexes, discovers, and synchronizes relevant UTXO-based state.
  58. Glossary · GlossaryTopic managerOverlay logic that decides which outputs are admissible for an application-defined topic.
  59. Glossary · GlossaryLookup serviceAn overlay component that indexes admitted outputs and answers application-specific queries.
  60. Glossary · GlossarySHIPThe overlay service-discovery mechanism used to advertise hosts that serve particular topics.
  61. Glossary · GlossarySLAPThe overlay discovery mechanism used to locate services that answer particular lookup queries.
  62. Glossary · GlossaryGASPGraph Aware Sync Protocol: a mechanism for synchronizing relevant transaction-graph state between overlay services.
  63. Glossary · GlossaryRail dependencyA product's dependence on the settlement network, token, proof semantics, node rules, services, or licenses specific to a blockchain.
  64. Glossary · GlossaryConformance vectorA versioned test input and expected result used by multiple implementations to check compatible behavior.
  65. Glossary · GlossaryAcceptance policyThe rules and evidence a participant uses to recognize a payment or history for a particular task.
  66. Glossary · GlossaryEconomic acceptanceRecognition of a result by the businesses, services and users whose agreement makes an exchange useful.
  67. Glossary · GlossaryLivenessThe ability of the relevant system to continue producing accepted results and serving its users.
  68. Glossary · GlossaryFinalityThe practical assurance, under stated assumptions, that a settlement result will remain accepted.
  69. Glossary · GlossaryAvailabilityWhether authorized parties can obtain the records and service needed for their task.
  70. Glossary · GlossaryStewardshipResponsibility for maintaining shared work, preserving competence and making decisions correctable within a defined scope.
  71. Glossary · GlossaryWorkflow compatibilitySuccessful completion of a named task using specified app, wallet and platform versions.
  72. Resource · Primary recordsCOPA v Wright — approved judgmentOfficial High Court publication of the approved judgment and identity findings.
  73. Resource · Primary recordsBitcoin: A Peer-to-Peer Electronic Cash SystemThe original paper; read its proof-of-work, incentives, privacy, and SPV claims in their own terms.
  74. Resource · Primary recordsBSV Network Access RulesThe published agreement governing the Association-node relationship; it is evidence of the stated rules, not independent proof of their application.
  75. Resource · Primary recordsNetwork Access Rules — Part III, Enforcement RulesDirective events, restrictions, and permitted steps including freezes, reassignment, peer controls, and block invalidation.
  76. Resource · Primary recordsNetwork Access Rules — Part IV, Dispute Resolution RulesPublished dispute path; inspect scope, forum, standing, and remedies rather than assuming an appeal mechanism.
  77. Resource · Primary recordsBitcoin SV node — Open BSV LicenseOperative repository license. Version 5 conditions derived software use on BSV blockchains.
  78. Resource · Standards to readBitcoin Request for Comments indexPublic specifications and proposal history; a published specification is not itself proof of independent adoption.
  79. Resource · Standards to readBRC-100 — Unified wallet-to-application interfaceThe current unified interface covering wallet actions, signatures, encryption, certificates, permissions, and discovery.
  80. Resource · Standards to readBRC-67 — Simplified Payment VerificationApplication-side criteria for verifying transaction inclusion and ancestry with proofs.
  81. Resource · Standards to readBRC-103 — Mutual authentication and certificate exchangePeer-to-peer authentication, message signatures, and selective certificate exchange protocol.
  82. Resource · Standards to readBRC-105 — HTTP service monetization frameworkSpecification for authenticated HTTP 402 pay-per-request flows; implementation and demand must be verified separately.
  83. Resource · Code and conformanceBSV TypeScript stackCurrent monorepo for SDK, wallet, overlay, messaging, middleware, helpers, infrastructure, documentation, and conformance vectors.
  84. Resource · Code and conformanceBSV TypeScript conformance corpusLanguage-neutral vectors and runners. Inspect current coverage and parity before calling the whole interface interoperable.
  85. Resource · Code and conformanceTeranode source repositoryCurrent public implementation. Source availability does not validate throughput or production-readiness claims by itself.
  86. Resource · Code and conformanceTeranode Teratestnet runnerPublic instructions and tooling for running the test network; inspect hardware and workload before comparing results.
  87. Resource · Things to tryProject Babbage quickstartsRunnable wallet-mediated application paths. Maintainer documentation is useful for reproduction, not independent adoption proof.
  88. Resource · Things to tryMetanet Academy Builder LabUngated architecture, diagnostics, and working-flow walkthroughs for builders.
  89. Resource · Things to tryUse BSV ToolsBuilder-facing tool entry point; verify each linked dependency and live path independently.
  90. Resource · Current-state surfacesWhatsOnChain explorerCurrent block and transaction inspection surface; explorer availability and interpretation remain third-party dependencies.
  91. Resource · Current-state surfacesBSV Hub demo catalogMaintainer-curated catalog with repository and status claims. Recheck every live URL, repository, and usage claim.