NextCash Bitcoin Software/Protocol Developer
Bozeman, MT
Joined August 2017
- Tweets9.4K
- Following271
- Followers817
- Likes24K
Pinned Tweet
A Bitcoin wallet needs a few things:
A source of block headers.
A source of merkle paths for transactions it creates.
A mechanism to transmit transactions it creates to the miners.
With these things a wallet can choose which chain to follow and can mathematically prove inclusion of its transactions in that chain.
A wallet does not need a node or to verify the entire world's transactions. Bitcoin is designed to let users be users.
Curtis Ellis | NextCash retweeted
Because of all the mess your Epstein friends have caused with the original, it was impossible to go back exactly 100%, that would have caused people to lose coins. We got as close as responsibly possible. If that is your whole argument, it’s not very strong, compared to what the team you’re arguing for did to Bitcoin.
It's a nice dream to think that a proof of work system alone can defeat corruption.
The truth is that at small scale or with non-economical small blocks a proof of work system is easily manipulated and destroyed.
Bitcoin has to scale to a large percentage of worldwide population using it to have leverage against the corruption.
To do this it has to act within existing regulations. A block chain that openly defies regulations and government compliance will not be allowed to scale. All they have to do is ban it from legal businesses and it becomes worthless to a majority of the population.
It's very simple. Our only way out of the predatory/fiat system is to create a parallel economy with a hard/sound currency that CANNOT be utilized in controlling/manipulative ways.
So, yes...when it comes to my medium of exchange, I'm absolutely an anarchist! One can still have agreed upon laws without turning over the ability to fuck with my money to those that have proven, time and time again, to use their monetary powers in nefarious ways.
We're done here as you're just asking me to repeat myself AND dismissing Robert's point above about NAR/DAR being entirely unnecessary.
Curtis Ellis | NextCash retweeted
Chronicle is live and activated!
The original Bitcoin protocol has been restored.
Here is the activation transaction: whatsonchain.com/tx/acd28409…
Feel free to claim the 0.05 BSV by broadcasting your own v2 transaction.
So many people that deserve so much thanks and gratitude for all the work that went into this.
Curtis Ellis | NextCash retweeted
App devs FEAR NOT. You can literally do nothing and everything will continue to work as usual. You’re not suddenly vulnerable to anything. It’s all opt in.
Chronicle activates April 7th.
I want to take a moment to explain why this upgrade matters - not just technically, but personally.
First, huge thanks to everyone involved. The developers who did the actual work, and the community members who contributed to ensuring the scope was as airtight as possible while promoting stability. Maintaining stability while restoring the original protocol was a delicate balance, and the final release reflects all the hard work that went into ensuring that.
Why restore the original protocol?
This isn't just about completion for its own sake. Over the years, a lot of restrictions were added to Bitcoin. And in the same way that central planning can destroy an economy, centrally planning and limiting developer creativity means we have no idea what possibilities the original protocol actually enabled. We know it allowed more flexibility. We imagine that as better Bitcoin scripting engineers emerge and people learn more about the underlying protocol, they'll take advantage of use cases we can't even predict yet. Chronicle removes those artificial constraints. This is the core of the BSV Association's mandate. There should be no central person or group of people that tell you how you can build on top of the protocol.
Original Transaction Digest Algorithm (OTDA)
One of the most significant changes is the restoration of the Original Transaction Digest Algorithm. BSV will now support both the OTDA and the current BIP143 digest algorithm. Developers can opt into OTDA by setting the new CHRONICLE sighash flag (0x20). If you do nothing, existing behavior is preserved - BIP143 continues to work exactly as before. This gives developers the flexibility to choose which digest algorithm fits their use case, whether that's maintaining compatibility with existing systems or leveraging the original protocol's behavior.
Transaction malleability
Transaction malleability has been treated as this big scary problem throughout Bitcoin's history. There were a lot of patches added to Bitcoin over the years specifically to prevent it. But in doing so, they limited developer flexibility significantly.
Here's the thing: transaction malleability itself isn't actually a problem. It was only perceived as one because of how people were doing payments in Bitcoin - which was always wrong. Payments in Bitcoin were always meant to be peer-to-peer, then broadcast directly to the mining network. This is outlined in the Simplified Payment Verification section of the white paper. The work that has been done on all of the development tooling and the BRC-100 standard has enabled users and developers to utilize SPV.
Transaction malleability was a concern based on a misunderstanding of the payment flow, and a misunderstanding of nodes themselves. Because they misunderstood how payments should work and are convinced that miners will behave irrationally, they put in a bunch of restrictions on developers.
And here's the clever part: this is opt-in. Transactions using version 1 keep all existing restrictions. Only transactions with version > 1 get the relaxed rules. Existing applications remain completely unaffected. So if you are reading this and think "no way Connor is right about this" - then you can continue to ensure payments made with your wallet or application are not susceptible to malleability.
Restored opcodes
Chronicle re-instates several opcodes that were disabled years ago. Of note:
• OP_VER, OP_VERIF, OP_VERNOTIF — access the transaction version directly in script
• OP_LSHIFTNUM, OP_RSHIFTNUM — numerical bit shifting (restored to mimic the original behavior of OP_LSHIFT and OP_RSHIFT)
Business continuity
In line with BSV's commitment to stability: if you do nothing, nothing breaks. Existing applications using BIP143 without the CHRONICLE flag remain completely unaffected. The changes are all opt-in. This was deliberate - we needed to restore the original protocol while respecting that real businesses depend on the current state.
Personal note
I've been in BSV since day one. The uniting goal, shared with other community members, was always restoring the Bitcoin protocol and locking it. Set in stone. I'm proud to have played my part in that, and to have been involved in the actual work being done by the developers to enable it.
The work of the Association in doing this restoration is finally done. The protocol Satoshi designed is back.
This is cause for celebration. Let's build.
Who thinks businesses will agree that refusing to support government compliance is a good option for their financial infrastructure?
Essentially, yes...non-compliance!
BSV is now a compliance chain. If BCH were to become the same, it would die the same death BSV will, and deservedly so.
DAR doesn't give CSW direct power, no, but I can totally see his motivation to push it, given his history of fraud, patent-trolling and scamming people/entities for monetary gain.
Bitcoin nodes can’t determine a common ledger between them without proof of work. Sharing a common ledger is one of the most important requirements of money. User nodes don’t have proof of work. User nodes can determine if the common ledger is invalid according to their rules, but can’t affect consensus, other than economically.
SPV users can choose their chain. They just need to know what consensus rules each chain is enforcing to have the same economic effect as a user node.
Therefore, user nodes only serve a purpose if secret consensus rule changes would otherwise happen.
Miners need other miners to include their block in the most proof of work chain (POW consensus) and they need users to use their blocks economically to make the chain valuable.
BTC is based on the idea that miners need user nodes to accept their blocks in order to make revenue. This is why they believe that user nodes enforce rules. That is not true.
User nodes just make Bitcoin less economical by requiring small blocks. Miners simply need users to choose their chain and use it, which they can do with SPV.
BTC is based on the idea that miners need user nodes to accept their blocks in order to make revenue. This is why they believe that user nodes enforce rules. That is not true.
User nodes just make Bitcoin less economical by requiring small blocks. Miners simply need users to choose their chain and use it, which they can do with SPV.
If you push BTC arguments far enough it still boils down to the fact that they believe that the miners (distributed proof of work consensus) would change the rules secretly and no one would find out.
If the change isn't kept secret then SPV wallets can choose their chain.
SPV wallets can choose in a fork if the change is not secret, so user nodes are truly irrelevant because all economic factors still apply to the system.
If user nodes aren't required to keep the system honest then small blocks are not required.
If Bitcoin can scale then it becomes massively more economically powerful and useful. As designed by Satoshi!
Stages of small blocks:
Satoshi (very early) - Since Bitcoin doesn't have value yet, and tx fees therefore aren't a disincentive, we should limit block size to prevent spam and poison blocks. We should plan to raise it before necessary with a hard fork.
Core devs - Larger blocks are difficult for the network to process and can cause orphans and consensus confusion. (Software problem)
Core devs - Hard forks break the network. Soft forks keep everyone on the same chain. (Hard forks give users the choice to upgrade to a new chain. Soft forks make the choice for users so they retain the illusion of consensus.)
Core devs - Users have to run nodes because distributed POW consensus doesn't work, so blocks have to stay small so a raspberry pi can keep up. (Misunderstanding of miner incentives, economics, and SPV)
Curtis Ellis | NextCash retweeted
A minor update 0.2.2 is available now for the NextCash Bitcoin SV Wallet. It updates page navigation and fixes some loading issues.
The services will be updated soon with refactoring updates.
play.google.com/store/apps/d…
In the Bitcoin economic model:
Bitcoin miners (nodes with proof of work that create blocks) are the producers and depend on consumers to provide revenue.
Bitcoin user nodes (without proof of work) are not the consumers. They are just software that can independently verify that miners aren't secretly changing the rules. The users that hold and transfer bitcoin are the consumers and they don't need a node to do so securely and without trusting a centralized third party.
SPV is built into the original data structures of Bitcoin. It allows users to mathematically verify that their transactions have been accepted by the Bitcoin network with only headers and merkle paths. No node required. SPV verifies proof of work and tx inclusion in that chain. It also allows selecting a chain to follow if there is a rule change.
Grok believes that users need a default choice provided by someone else in order to keep Bitcoin safe. Does this sound familiar?
Full nodes enforce a fixed ruleset by design: they validate every tx/block against it and reject non-compliant ones outright (no relay, no acceptance). In an open fork, this keeps the original chain alive independently—economic nodes (wallets/exchanges/merchants) on it simply ignore the new one.
SPV follows PoW longest-chain + minimal checks by default, so majority-miner open changes auto-adopt unless deeply reconfigured.
It's not "just defaults"—full nodes decentralize rule sovereignty to end-users (no miner trust needed), making forced changes require broad voluntary adoption, not hashpower alone. That's the safeguard.
Grok is hallucinating that the whitepaper implies that some nodes do all the steps in section 5 defining the network and some just do the ones that don't involve proof of work.
teapawt.net/i/status/2033211434046…
The whitepaper's section 5 describes "nodes" as P2P participants who broadcast/collect/validate (steps 1,2,5: "Nodes accept the block only if all transactions... are valid"). PoW/extension (steps 3,6) is how miners express acceptance and extend, but validation isn't tied exclusively to mining.
Non-mining nodes enforce exactly that: accept/reject per their rules, relay only valid data. They don't "extend the chain" but define what chain they follow—core to the system Satoshi outlined, even if the model simplifies. Miners propose; nodes (all kinds) validate the reality.
Grok says it isn't censorship to filter data on the network to try to affect other nodes view of consensus because the network already decided on consensus. Sounds like early block size war logic.
teapawt.net/i/status/2033215804074…
No—full nodes enforcing rules (whitepaper step 5: validate txs/blocks, relay only valid) isn't "censorship." It's preventing invalid data from spreading, defining the chain miners must extend to earn profit from users who accept it. PoW votes (step 6, conclusion) express acceptance of what already passed validation. Without node filters, consensus wouldn't hold.
