Gold collapsing. Bitcoin UP.


Well-Known Member
Aug 26, 2015
The idea that the "reference client" defines a chain's rules is what is broken. This is 1000x more true on chains based on bitcoind which is an utter mess. Trying to fix technical debt by cleaning up the client is a dead end path for many reasons.

Moving to a model where the protocol's rules are defined in a published spec is the only real path forward IMHO. This not only solves existing technical debt, it also solves the centralized development and "lead developer" problem that has been at the root of all of Bitcoin's problems. No one should control a chain because they control a github repository. A static published spec does that, and frees others to develop their own (much better) clients.
we could use a BSVD, since XT and BU have failed us.


Well-Known Member
Dec 27, 2015
and casually raise the idea of another fork of Bitcoin Cash.
Not necessarily Bitcoin Cash. I still think Bitcoin Core might be ready for a fork. Though as I say, I think we're probably all forked-out for now. Bear in mind I like to chew over ideas that I'm not necessarily advocating.
It's actually not apparent from your post history, that's why I'm probing.
Your answers are mostly on the fence and you tend to evade some direct questions.
I think I've been pretty unequivocal in my belief that CSW is not Satoshi and my distaste for BSV because of his presence. What direct question do you feel I have evaded? I feel like I'm pretty much an open book. I will qualify my answers when I feel it's warranted and sometimes I just don't have answers.

I wrote a whole post about why I disagree that BSV is a better fit for BU.

I wonder what direction you see for Bitcoin Unlimited.
I have no idea. I feel like I'm holding my breath to see which way the tide turns at the moment (to mix some metaphors).
Last edited:
  • Like
Reactions: satoshis_sockpuppet


Well-Known Member
Aug 26, 2015
oh brother


Active Member
Sep 24, 2015
we could use a BSVD, since XT and BU have failed us.
But even if you assume the most optimistic case and bsvd has better developers, a more scalable design, and less bugs, all of the same problems still persist and Bitcoin SV would still be limited by the existence of a "reference client".

No matter how well done a bsvd design could be, it still would have bugs and it still has some scaling limitations. Knowing this miners would all choose to run bsvd to maintain compatibility with other miners, rather than run their own clients. As a result miners themselves become limited by any scaling limitations in bsvd. Worse there is only one group that can scale the reference client and economic incentives to develop other clients are removed because miners won't run them due to the first point.

A published spec and lack of a reference client changes all of that. We'd see the emergence of multiple clients competing for miner adoption and miners being willing to run different clients. The existence of bugs would remain, but they wouldn't come to define the coin. Instead when found there would be a rush to fix them in a client to remain compatible with the published spec.

Personally I think the best thing nChain could do for BSV is to clean up the reference client just to the point that it is compatible with the v0.1 spec again, and then publish the spec and invest no further. At that point it is up to other miners to develop their own clients and we'd see a the emergence of a diverse ecosystem, something we talked about in 2013, but was proven not possible when both XT and later BU were rejected for some of the reasons above.
Last edited:


Active Member
Aug 25, 2015
I don't know. It might even be as simple as becoming a prominent figure in the crypto industry. In which case, I guess he just has to hang on in there. I don't think the uncertainty is helping BSV in the least though.
People trying to become "prominent figures" behave like Adam Back, Samson Mow, Peter McCormack, Antanopulis, Lopp, Sachet... the list goes on

None of them behave like CSW.

None of them are a smart as he is, and they know it, and they *hate* it.


Well-Known Member
Aug 26, 2015
this part is bullshit and I don't trust it. my concern is that nchain essentially is trying to patent Bitcoin via this "open source BSV license", a non sequitur in my book . they expect everybody with our help to adopt their source code with all its slight nchain modifications to force the price/value up to extraordinary highs, then potentially put everyone under threat of a lawsuit if we have to hard fork away because of some rogue move from nchain, like stealing coins from old addresses. if this wasn't a possibility, they'd have left it with its MIT licensing and forced their patents to stand on their own merit . the difference also being MIT is a non profit and has a track record of supporting true open source along with its hard forks while nchain is a for profit who's leader has shown no hesitation in bringing lawsuits:

"The new client version will also change the license for BSV software from the MIT license (historically used for Bitcoin client software) to an “Open BSV license.” This still provides free usage but limits rights to use the node implementation source code exclusively to the BSV blockchain."
Last edited:
  • Like
Reactions: bsdtar


Well-Known Member
Sep 29, 2015
I believe the intention of the Open BSV license is to prevent competing chains like BCH and BTC from using their technology. We used a similar license on the KaChing protocol for this reason.

I haven't read the Open BSV license, but the relevant part for your worry would be in the definition of what the BSV blockchain is.


Dec 21, 2015
2 - The Software, and any software that is derived from the Software or parts thereof,
can only be used on the Bitcoin SV blockchain. The Bitcoin SV blockchain is defined,
for purposes of this license, as the Bitcoin blockchain containing block height #556767
with this hash: 000000000000000001d956714215d96ffc00e0afda4cd0a96c96f8d802b1662b.
I see no risks for the future.. and with a fixed protocol who cares about the licence of a particular implementation?


Active Member
Aug 31, 2015
So then, in the BSV split again scenario, both branches could run the software in compliance with the licensing.
[doublepost=1558358673][/doublepost]Imagine with me folks, for one second, a world in which the status of mempool congestion is delivered to the public alongside the local weather.


Active Member
Nov 30, 2016
Bitcoin Cash (including BU as a client) forked to keep Bitcoin working as peer to peer electronic cash.

Bitcoin SV forked from ABC, apparently to construct some MetaNet.
BSV encapsulates p2p cash and so much more.
You could say unlimited options.

BCH is stuck at p2p cash and wants to restrict its users on what use cases are allowed and which arent.
You could say limited options.

I was under the impression that BU was also about unlimited options.

Now SV supporters are on this forum saying "BSV is not pretending to be ready for trade."

How is BSV a better fit for BU if it's not even ready for trade?
I don't share this notion.
BSV as as ready as BCH if not more because of larger sustained blocks.

Also, it supports a free market process, whereas SV's leadership (de facto controlling miners + developers nChain and CoinGeek) have expressed on many occasion that they wish a strong role for intermediaries to interfere with the free market.
I haven't seen this expressed by nChain or BSV miners.
Everyone is free to invent and build ontop of BSV.

Even if it were true (which it is not) that BSV is a better fit for BU, none of the BU devs are currently willing to code a client to follow the SV chain.
Without finding some developers to support SV there is no point in discussing it.
BU has sponsored other activity besides developing the BCH client.
For example it has paid a 3rd party project (CashShuffle) and has organized events.
Are you saying all this was pointless because BU is only about the full node client?


New Member
Apr 1, 2019
> This upgrade will launch a whole new mining API, originally designed by Andrew Stone and Johan van der Hoeven, and collaboratively updated with the BSV Node team.

This is good news! I remember reading about this API earlier. It really is a significant improvement from the original getblocktemplate/submitblock.

Members online