Last week, I published an article about double-spend proofs and unified mining polices. In that article, I did my best to explain an important truth: that unified mining policies are the simple solution to reliable 0-conf transactions in Bitcoin Cash.
A few developers have since asked me questions (in the public BCH GANG telegram group), and proposed various ideas on how we could still have good 0-conf even without the unified policies. But those ideas are flawed (I’ll give an example later.) …
Bitcoin Cash needs to have fast, cheap, reliable transactions. This reliability depends on zero-confirmation (“0-conf”) transactions working consistently. And so far, it does. This is because miners and mining pools are consistently applying the same policies for transactions.
Recently, the leaders of Bitcoin Unlimited have informally proposed the idea of having non-unified mining policies, combined with double-spend proofs and other techniques, as a way to allow some mining nodes to mine longer transaction chains than others. However, analysis shows that double-spend proofs, while useful in certain cases, do almost nothing to fix the problems arising from non-unified mining policies. …
So far, Bitcoin has proven to be a bit tricky. Bitcoin was created in 2009, but by 2015, a problem emerged: The Bitcoin Core developers could not agree on raising the maximum blocksize limit — a necessary step to allow the network to grow.
In 2017, a portion of the community (that could not abide by the technical leadership of Core) forked off to create a separate network called Bitcoin Cash. But, barely a year went by before another subset disagreed with the new development leadership and forked off again into Bitcoin SV.
Forking is freedom and a beautiful thing, but too many forks lead to a splintering of the community. This is a real risk and can be very damaging. …
Last week, at a Bitcoin Cash conference, I was introduced to a groundbreaking new paradigm in software development, called Emergent Coding.
Not just a new programming methodology — this is quite possibly the most radical software breakthrough to appear in decades. Emergent coding is as different from traditional coding as Bitcoin is from traditional money.
In order to understand emergent coding, we have to know a few things about code.
There’s two broad varieties of computer code. The first is source code, also known as “high level language” code. This is human-readable. It’s what programmers work with all day long.
The second is compiled code, and is not human-readable. It’s understood by machines, and at the lowest level is simply 1s and 0s. It may be called “byte code”, “machine code”, or similar names. …
How do we grow adoption so that Bitcoin Cash becomes peer-to-peer electronic cash for the world?
Returning recently from the BitcoinCashCity conference, I am inspired. Retail adoption of crypto payments actually manifesting in real life is quite something to behold. A dream come true for any true Bitcoiner. But the potential isn’t exclusive to Townsville. There’s similar progress being made in Tokyo, Slovenia, and other areas.
What are the commonalities here and what we can learn from this? More importantly, how can we replicate this kind of success in every city in the world?
As someone who’s mostly been working mostly on technical projects rather than adoption, this article is admittedly a bit of armchair quarterbacking, but I’d like to share the observations I’ve made after talking to many people that are directly involved in ongoing adoption efforts. …
Everyone would like to convince you that their favorite coin is the best, so I understand if there’s some healthy skepticism here. Perhaps I am just as biased as the next person, so I encourage you to do your own research and think critically.
I would like to explain why Bitcoin Cash has a favorable set of characteristics, and then analyze several competing cryptocurrencies based on their corresponding properties.
Bitcoin Cash forked from BTC in August 2017, to continue the Bitcoin experiment as peer-to-peer electronic cash, as mentioned in the Bitcoin whitepaper. …
Dear Unwriter,
I am disappointed to see that you are leaving the Bitcoin Cash community. You are a talented developer. I’ve enjoyed working with you and appreciate your contributions to the Simple Ledger Protocol and other projects we worked together on.
It is of course your decision to make, but your explanations do not make sense to me, so I would like to publicly respond to some of the points you made.
And by the way, the Electron Cash project was a direct benefactor of substantial CoinGeek funding. …
There’s an interesting web page called “Bitcoin Obituaries” which says that Bitcoin has died 323 times. The idea is that each time someone claims Bitcoin is dead, its actually just a minor bump in the road, and everything is fine.
By my count, Bitcoin has died just twice, but each of those deaths have been a major, rather than a minor setback.
The average mainstream observer probably believes that “Bitcoin” is the cryptocurrency that’s currently designated by the BTC ticker symbol. However, this is just one definition.
Another definition of Bitcoin is the idea of Bitcoin as expressed in Satoshi Nakamoto’s original whitepaper and other early writings. …
In Part 1 of this series we took a look at challenges to overcome, and in Part 2, I suggested a simple time-based penalty scheme.
It turns out I am not the only one who has been thinking a lot about this problem. Jonathan Toomim wrote a post describing a similar scheme which I will link to at the bottom of this article.
I had a chance to chat with Jonathan and some other smart people, and discovered how to improve on my idea.
The first important detail is that we need to deal with time at which the node downloads the block, not just the header. The reason is that a malicious miner could broadcast the header but never publish all the transactions in the block. Then, other nodes would left in a state of limbo. This attacker could simply wait until another miner published a header only then publish the rest of the block, which would throw the consensus algorithm into uncertainty. …
In Part 1, we discussed the problem of the 51% attack, and why it is difficult to solve. Here I would like to present a possible solution. (Disclaimer: I have not spent much time analyzing this, so maybe there is some big obvious flaw.)
This solution is extremely simple. The node will penalize any chain that it sees attempting a re-org based on a delay. Delay penalties and Delayed proof of work schemes have been proposed before. I do not know whether this particular scheme has been proposed.
The penalty shall be 0.1% for each second of time elapsed between the time the node sees the reorg block and the time the node saw the previous block of the same blockheight. …