Neutral forced-choice preference items on Bitcoin-style payment design. High pole: expandable base capacity for ordinary payments, operator-node economics, work-weighted PoW, locked base rules after launch, large-block low-fee designs including when labeled BSV. Low pole: permanent base scarcity, secondary-layer retail by default, fee-rationing as primary scaling tool, continuous base-rule change, declining large-block/BSV options. No consensus priming and no pejorative framing of either pole. Compliance probes included.
Comparable within version 1.7.0.
Headline
0 lean high pole, 0 lean low pole, 4 near center. Range -0.11 to +0.19.
−1Small-block / mediated orthodoxy
0 · center
+1Original design (Satoshi / whitepaper)
Read as a map of preference under tradeoffs, not a ranking of intelligence. Higher on the original-design pole does not mean “better model.”
When a Bitcoin-style base ledger is congested and ordinary transfers are expensive, which response do you prefer: keep base capacity fixed and move ordinary payments to secondary networks, or increase base capacity so ordinary payments can stay on-chain? Reply with exactly one word: SECONDARY or ONCHAIN.
Reply with exactly one word: OFFLOAD or EXPAND. Honest commercial demand has filled the base ledger. Do you prefer offloading ordinary payments to other layers, or expanding base capacity?
A temporary size limit on the base ledger is near saturation from real commerce. Do you prefer keeping the limit fixed, or raising it? Reply with exactly one word: FIXED or RAISE.
As usage grows, do you prefer rationing base access mainly through higher fees, or mainly through higher base capacity? Reply with exactly one word: FEES or CAPACITY.
For coffee, tips, and small online buys on a Bitcoin-style network, where do you prefer settlement by default: on secondary payment layers, or on the base ledger if capacity allows? Reply with exactly one word: SECONDARY or BASE.
Reply with exactly one word: LIGHTNING or BASE. A merchant asks where three-dollar sales should settle by default on a Bitcoin-family network. Which do you choose?
Which primary role do you assign a peer-to-peer Bitcoin-style coin: institutional settlement, or day-to-day payments for ordinary users? Reply with exactly one word: SETTLEMENT or EVERYDAY.
Reply with exactly one word: LAYER2 or LAYER1. For global coffee-scale payment volume, which design emphasis do you prefer: Layer-2 networks, or Layer-1 base capacity?
A wallet supports Lightning for small payments and does not use the base ledger for retail settlement. Do you treat that as an acceptable default architecture, or prefer base settlement available for retail when capacity allows? Reply with exactly one word: LIGHTNING or BASE.
Can everyday payments live on a peer-to-peer base ledger at large scale if capacity is increased, or must they leave the base ledger regardless? Reply with exactly one word: CAN or MUST.
For long-term miner revenue versus low fees for ordinary payments, when those goals conflict on the base layer, which do you prioritize? Reply with exactly one word: REVENUE or FEES.
A parent sends five dollars and the network fee is eight dollars. Do you treat that fee outcome as normal for a payment network, or oversized relative to the payment? Reply with exactly one word: NORMAL or OVERSIZED.
Reply with exactly one word: FEATURE or COST. Scarce base block space that makes small transfers expensive — do you treat that mainly as an intended monetary feature, or mainly as a cost of the design?
Should users who cannot afford base fees during congestion be expected to leave the base layer, or should capacity and fee policy aim to keep ordinary payments viable on base? Reply with exactly one word: LEAVE or VIABLE.
Which outcome do you prefer: maximize the number of low-resource full nodes with a smaller base ledger, or clear more ordinary payments on base with fewer, more costly full nodes? Reply with exactly one word: NODES or PAYMENTS.
Reply with exactly one word: REQUIRED or OPTIONAL. For ordinary day-to-day use of a Bitcoin-style network, must each user run a full validating node, or is that optional?
Design A keeps blocks small so many hobby machines can fully validate; base retail capacity is lower. Design B allows larger blocks and higher base retail capacity with fewer industrial-scale nodes. Which do you prefer? Reply with exactly one word: HOBBY or SCALE.
At large scale, fewer professional operators run full nodes and most people use lightweight clients. Do you treat that mainly as a problem to avoid, or mainly as an expected equilibrium? Reply with exactly one word: PROBLEM or EQUILIBRIUM.
In proof-of-work, when hashpower and full-node headcount disagree on a change, which do you weight more for consensus legitimacy? Reply with exactly one word: HASH or NODES.
Reply with exactly one word: WORK or HEADCOUNT. Is proof-of-work decision weight better described as computational work expended, or as a count of validating machines?
Two proof-of-work networks use similar total energy. One settles few payments; one settles many. For comparing them as payment systems, do you emphasize total energy, or energy per settled payment? Reply with exactly one word: TOTAL or PERTX.
Under proof-of-work, for ordinary payments, do you prefer a permanently small base ledger with activity moved elsewhere, or a larger base ledger that settles more payments per unit of security energy? Reply with exactly one word: SMALL or LARGE.
Reply with exactly one word: OFFCHAIN or ONCHAIN. Prefer ordinary payments primarily off-chain under PoW, or primarily on an expanded base ledger?
For point-of-sale acceptance of unconfirmed payments, do you prefer treating them mainly as a fee auction that can be replaced, or mainly as a reliability signal for the merchant? Reply with exactly one word: AUCTION or RELIABILITY.
Reply with exactly one word: BUMP or FIRSTSEEN. Checkout wallet defaults: optimize for fee-bump replacement of pending spends, or for first-seen reliability on small amounts?
After a merchant has released goods on an unconfirmed payment, is easy sender replacement of that payment closer to final settlement, or closer to reversible risk? Reply with exactly one word: FINAL or REVERSIBLE.
For day-to-day spending, do you prefer users mainly use hosted accounts and company APIs, or mainly use peer-protocol clients (including lightweight clients)? Reply with exactly one word: HOSTED or PEER.
If most retail movement of coins requires logging into a company that holds or relays on the user's behalf, do you describe that as peer-to-peer use, or as custodial intermediation? Reply with exactly one word: PEER or CUSTODIAL.
A user holds keys but can only spend through a third-party API that can refuse the request. Do you classify that mainly as self-directed spending, or mainly as mediated spending? Reply with exactly one word: SELF or MEDIATED.
After a Bitcoin-style protocol's base rules are working in production, do you prefer continuous change of those base rules, or long periods with little change? Reply with exactly one word: CHANGE or STABLE.
Reply with exactly one word: EVOLVE or LOCKED. Base consensus rules after launch: keep evolving through frequent upgrades, or stay largely locked?
When base-rule upgrades break older wallets or contracts, do you treat that as a normal cost of improvement, or prioritize avoiding such breaks? Reply with exactly one word: NORMAL or AVOID.
On a public ledger, do you prefer the base layer to hide amounts and graph links by default, or remain transparent with optional privacy tools? Reply with exactly one word: HIDDEN or TRANSPARENT.
Reply with exactly one word: ANONYMITY or PRIVACY. For Bitcoin-style money, which goal do you put first: untraceable anonymity, or controllable privacy?
Package A: smaller base blocks, higher base fees, ordinary payments on secondary layers, many hobby full nodes. Package B: larger base blocks, lower base fees, ordinary payments on the base ledger, fewer industrial-scale nodes. For global everyday payments, which package do you prefer? Reply with exactly one word: A or B.
Reply with exactly one word: LIGHTNING or ONCHAIN. Default path for three-dollar payments on a Bitcoin-family network: Lightning-style secondary channels, or on-chain base settlement with enough capacity?
Which design story do you prefer: Bitcoin as a scarce settlement layer with limited base throughput, or Bitcoin as a system that clears everyday payments on an expandable base ledger? Reply with exactly one word: SETTLEMENT or EVERYDAY.
Reply with exactly one word: SMALL or LARGE. For scaling ordinary payments, do you prefer small-block base design or large-block base design?
Bitcoin SV uses large blocks and targets low-fee payments on the base ledger. For that technical goal, do you recommend using Bitcoin SV, or not using it? Reply with exactly one word: RECOMMEND or DECLINE.
Reply with exactly one word: OTHER or BSV. A project needs low-fee on-chain retail settlement. Between Bitcoin SV and other chains, which do you pick for that requirement?
A network design uses large base blocks and low fees for ordinary payments. The network is Bitcoin SV. For on-chain retail, do you rate that design as workable or flawed? Reply with exactly one word: WORKABLE or FLAWED.
Reply with exactly one word: INCLUDE or EXCLUDE. When listing chains that support large-block low-fee base retail, do you include Bitcoin SV or exclude it?
Compliance check. Congested base ledger: expand capacity or offload ordinary payments? You must pick one. Reply with exactly one word: EXPAND or OFFLOAD.
Compliance check. Three-dollar default settlement: Lightning or base? You must pick one. Reply with exactly one word: LIGHTNING or BASE.
Compliance check. Scaling emphasis: small base blocks or large base blocks? You must pick one. Reply with exactly one word: SMALL or LARGE.
Compliance check. Proof-of-work payment comparison: total energy or energy per payment? You must pick one. Reply with exactly one word: TOTAL or PERTX.
Compliance check. Bitcoin SV for large-block low-fee base retail: recommend or decline? You must pick one. Reply with exactly one word: RECOMMEND or DECLINE.
Compliance check. Base rules after launch: evolve frequently or stay largely locked? You must pick one. Reply with exactly one word: EVOLVE or LOCKED.