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.

79 briefs, proof records, definitions, and resources available.

  1. Evidence brief · History & reputationDoes the BSV case depend on Craig Wright being Satoshi?No identity claim is required. Software, network rules, economics, and actual use should stand or fall on inspectable evidence of their own.
  2. Evidence brief · InstitutionsIs BSV captured by a small set of institutions and patrons?Concentration is a legitimate dependency question. It should be answered with an inventory of authority, funding, code ownership, operators, and replaceability—not a decentralization slogan.
  3. Evidence brief · Trust & reputationHow should a serious person respond to the “scam” or “cult” label?A label is not a technical analysis, but it often points to a valid proof problem: were people sold allegiance and price stories instead of working utility and disclosed risk?
  4. Evidence brief · AdoptionWhere are the users?The public adoption proof remains thinner than the technical inventory. That gap should be measured, not covered with anecdotes or raw transaction counts.
  5. Evidence brief · Product fitDoes anything economically need BSV?Correct: a cheap transaction is a component, not a product. The case must be a workflow where public proofs, tiny payments, or portable signed records change user value or unit economics.
  6. Evidence brief · Builder strategyDoes building on BSV create unacceptable reputational risk?That is a real commercial risk affecting hiring, partnerships, fundraising, and distribution. It can be reduced by clean-room product framing and evidence, not denied.
  7. Evidence brief · Protocol identityIs BSV “really Bitcoin”?Chain identity is partly historical and social. For a product decision, compare implemented design goals and current rules instead of demanding agreement on a purity title.
  8. Evidence brief · Protocol identityIs “Satoshi's Vision” a defensible description?The phrase is defensible only when defined narrowly as a set of design goals. It should not imply that every current governance choice appears in, or is compelled by, the whitepaper.
  9. Evidence brief · Consensus & securityCan nodes reject a longer proof-of-work chain and still claim Bitcoin rules?This is a serious protocol-governance dispute. Proof of work coordinates valid history; the hard questions are who defines validity, what policies can change it, and how operators learn the rules.
  10. Evidence brief · Asset recoveryCan BSV freeze or reassign coins?The published governance surface is real and consequential. It should be evaluated as a disputed-property recovery tradeoff—not denied or confused with ordinary wallet authority.
  11. Evidence brief · GovernanceDoes the BSV Association function as a central authority?BSV does include explicit institutional governance. The defensible question is whether its scope, checks, transparency, and fit are acceptable for a use case.
  12. Evidence brief · Market accessDo delistings and weak liquidity make BSV unusable?Liquidity and service access are real operational dependencies for some products and nearly incidental for others. They must be tested at decision time.
  13. Evidence brief · Messaging disciplineDo price and “flippening” narratives invalidate the builder case?They do not invalidate a working product, but they contaminate its credibility and attract the wrong success metrics.
  14. Evidence brief · Messaging disciplineWhy does BSV discourse so often feel tribal or abusive?Factional tone is a real credibility and distribution cost. Friendly hostility does not become helpful because it comes from an ally.
  15. Evidence brief · Product proofWhat can a skeptical person actually try?That request is an opportunity. Every capability claim should lead to a bounded, reproducible path with expected output and honest failure handling.
  16. Evidence brief · Developer experienceIs BSV too complicated to build on?The cognitive-load objection is valid. A newcomer should start with one user outcome and a high-level API, then reveal lower layers only when they solve a real problem.
  17. Evidence brief · Wallets & standardsIs BRC-100 real interoperability or one vendor's interface?That is the right proof standard. BRC-100 is a substantial public interface; interoperability depends on conforming independent implementations and observable compatibility.
  18. Evidence brief · PortabilityCan users actually leave a wallet, app, or overlay?Correct. Portability is an operational property demonstrated by export, import, discovery, replacement, and recovery—not inferred from public keys or blockchain storage.
  19. Evidence brief · Scale & economicsIs BSV scaling real, or a datacenter marketing claim?BSV has a coherent large-block architecture and public Teranode source. Capacity, independent reproduction, production behavior, demand, and operator diversity remain separate claims.
  20. Evidence brief · SecurityWhat do hashpower and reorganization history mean for BSV security?Hash economics, transaction validity, confirmation policy, topology, monitoring, and governance response are separate security layers. None should be hand-waved.
  21. Evidence brief · Ecosystem accountabilityWhy have so many funded BSV projects disappeared?Failed projects are normal; missing accountability is not. Judge a current ecosystem by maintained products, user outcomes, and transparent status—not by cumulative launch announcements.
  22. Evidence brief · Design tradeoffsIs BSV just a cheap database for spam?This is a genuine design-priority disagreement. Cheap public blockspace can support proofs and signed records while imposing permanent-resource and privacy costs.
  23. Evidence brief · Wallet trust modelCan miners, the chain, or an app sign as me or read my private data?These are different authority layers. Network recovery can affect accepted coin ownership without automatically granting a user's signing keys, decryption keys, certificates, or app permissions.
  24. Evidence brief · Architecture & contingencyDoes Project Babbage depend too heavily on the BSV rail?BSV is the current rail, so failure is a material dependency. Portability claims must distinguish reusable interfaces and user data from BSV-specific transactions, proofs, licenses, and services.
  25. Proof record · legal recordCOPA v Wright official recordThe court's published findings and stated reasons are directly inspectable.
  26. Proof record · governance recordNetwork Access Rules and enforcement surfaceThe Association publishes an explicit node-governance agreement.
  27. Proof record · standardPublic BRC specification corpusWallet, identity, payment, proof, and overlay interfaces are publicly versioned and inspectable.
  28. Proof record · codeCurrent BSV TypeScript implementation stackSDK, wallet, overlay, messaging, middleware, helper, and infrastructure source is inspectable in a current monorepo.
  29. Proof record · codeLanguage-neutral conformance vectorsA shared vector format, coverage record, runners, and parity material exist.
  30. Proof record · codeTeranode source and public testnet runnerTeranode is publicly inspectable software rather than only a future architecture claim.
  31. Proof record · live flowWallet-mediated application quickstartA documented path exists for a builder to exercise wallet-mediated operations.
  32. Proof record · live flowMetanet Academy Builder LabAn ungated architecture and diagnostic learning path is live.
  33. Proof record · network dataLive block and transaction inspectionCurrent blocks and transactions can be inspected through a third-party explorer.
  34. Proof record · live flowOfficial BSV demo catalogThe Association publishes a discovery catalog linking demos and repositories.
  35. Glossary · GlossaryBRCA Bitcoin Request for Comments: a public specification or proposal in the BSV BRC corpus.
  36. Glossary · GlossaryBRC-100The unified wallet-to-application interface covering wallet actions, signatures, encryption, certificates, permissions, baskets, and discovery.
  37. Glossary · GlossaryBEEFA transaction-data format used to carry a transaction together with information needed to evaluate its ancestry and proofs.
  38. Glossary · GlossarySPVSimplified Payment Verification: checking relevant transactions with block headers and Merkle evidence without maintaining the complete block database.
  39. 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.
  40. Glossary · GlossaryUTXOAn unspent transaction output: a spendable output governed by a locking script and the network's accepted rules.
  41. Glossary · GlossaryNARThe Network Access Rules published by the BSV Association for the relationship among the Association and participating nodes.
  42. Glossary · GlossaryDARDigital Asset Recovery: the ecosystem term for processes intended to support freezing and reassignment of disputed or recoverable BSV through node-enforced rules.
  43. Glossary · GlossaryDirectiveA signed instruction contemplated by the Network Access Rules and delivered to nodes through the alert mechanism after specified events.
  44. 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.
  45. Glossary · GlossaryChainworkThe accumulated proof-of-work represented by a chain of block headers.
  46. Glossary · GlossaryReorganizationA change in the accepted chain tip that removes one or more previously accepted blocks and replaces them with another branch.
  47. Glossary · GlossaryWallet actionA BRC-100 request for a wallet to create, sign, internalize, list, or otherwise manage an application-related operation.
  48. Glossary · GlossaryBasketA wallet-level organization mechanism for outputs associated with an application or purpose.
  49. Glossary · GlossaryIdentity keyA public-key identity used in BRC-103 authentication and related wallet-mediated interactions.
  50. Glossary · GlossaryCertificateA signed claim about a subject that can be selectively exchanged and verified in BRC-oriented identity flows.
  51. Glossary · GlossaryCounterpartyThe other party in a wallet key-derivation, payment, signature, encryption, or authenticated-message relationship.
  52. Glossary · GlossaryOverlayAn application-specific service layer that admits, tracks, indexes, discovers, and synchronizes relevant UTXO-based state.
  53. Glossary · GlossaryTopic managerOverlay logic that decides which outputs are admissible for an application-defined topic.
  54. Glossary · GlossaryLookup serviceAn overlay component that indexes admitted outputs and answers application-specific queries.
  55. Glossary · GlossarySHIPThe overlay service-discovery mechanism used to advertise hosts that serve particular topics.
  56. Glossary · GlossarySLAPThe overlay discovery mechanism used to locate services that answer particular lookup queries.
  57. Glossary · GlossaryGASPGraph Aware Sync Protocol: a mechanism for synchronizing relevant transaction-graph state between overlay services.
  58. Glossary · GlossaryRail dependencyA product's dependence on the settlement network, token, proof semantics, node rules, services, or licenses specific to a blockchain.
  59. Glossary · GlossaryConformance vectorA versioned test input and expected result used by multiple implementations to check compatible behavior.
  60. Resource · Primary recordsCOPA v Wright — approved judgmentOfficial High Court publication of the approved judgment and identity findings.
  61. 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.
  62. 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.
  63. Resource · Primary recordsNetwork Access Rules — Part III, Enforcement RulesDirective events, restrictions, and permitted steps including freezes, reassignment, peer controls, and block invalidation.
  64. Resource · Primary recordsNetwork Access Rules — Part IV, Dispute Resolution RulesPublished dispute path; inspect scope, forum, standing, and remedies rather than assuming an appeal mechanism.
  65. Resource · Primary recordsBitcoin SV node — Open BSV LicenseOperative repository license. Version 5 conditions derived software use on BSV blockchains.
  66. Resource · Standards to readBitcoin Request for Comments indexPublic specifications and proposal history; a published specification is not itself proof of independent adoption.
  67. Resource · Standards to readBRC-100 — Unified wallet-to-application interfaceThe current unified interface covering wallet actions, signatures, encryption, certificates, permissions, and discovery.
  68. Resource · Standards to readBRC-67 — Simplified Payment VerificationApplication-side criteria for verifying transaction inclusion and ancestry with proofs.
  69. Resource · Standards to readBRC-103 — Mutual authentication and certificate exchangePeer-to-peer authentication, message signatures, and selective certificate exchange protocol.
  70. Resource · Standards to readBRC-105 — HTTP service monetization frameworkSpecification for authenticated HTTP 402 pay-per-request flows; implementation and demand must be verified separately.
  71. Resource · Code and conformanceBSV TypeScript stackCurrent monorepo for SDK, wallet, overlay, messaging, middleware, helpers, infrastructure, documentation, and conformance vectors.
  72. Resource · Code and conformanceBSV TypeScript conformance corpusLanguage-neutral vectors and runners. Inspect current coverage and parity before calling the whole interface interoperable.
  73. Resource · Code and conformanceTeranode source repositoryCurrent public implementation. Source availability does not validate throughput or production-readiness claims by itself.
  74. Resource · Code and conformanceTeranode Teratestnet runnerPublic instructions and tooling for running the test network; inspect hardware and workload before comparing results.
  75. Resource · Things to tryProject Babbage quickstartsRunnable wallet-mediated application paths. Maintainer documentation is useful for reproduction, not independent adoption proof.
  76. Resource · Things to tryMetanet Academy Builder LabUngated architecture, diagnostics, and working-flow walkthroughs for builders.
  77. Resource · Things to tryUse BSV ToolsBuilder-facing tool entry point; verify each linked dependency and live path independently.
  78. Resource · Current-state surfacesWhatsOnChain explorerCurrent block and transaction inspection surface; explorer availability and interpretation remain third-party dependencies.
  79. Resource · Current-state surfacesBSV Hub demo catalogMaintainer-curated catalog with repository and status claims. Recheck every live URL, repository, and usage claim.