BitCoin and the Byzantine General’s Problem (Holy Grail)

It’s the problem that most people in crypto who have a tad more knowledge than the average observer like to quote but few actually understand what it means.  That is because it is a metaphor which contains meaning on multiple levels, and just like Indiana Jones in the Temple of Doom, the answer, if you are true of heart you will find right in front of your face, but if you are not worthy, will never be able to understand.

When most people talk about the Byzantine General’s Problem, it is framed within the context of the problem faced by the the surrounding 10 vassal states of a central Byzantine empire, who were being oppressed, and wanted to overthrow the much larger Byzantium in the center.  The army of Byzantium was large enough to repel any attack, as long as it was mounted with the support of less than half of the surrounding kingdoms armies.  So if 5 out of the 10 vassal states army generals coordinated to attack Byzantium on the same day, they would lose, but if 6+ kingdoms coordinated, then they would be victorious and be able to divide up the central empire among the victors.  The risk each general faces is that, if you attack and lose, then the emperor will execute you and then divide up your lands and grant them to the other generals who did not support your attack.  So while a general attacking will gain much if he could mount a successful rebellion against the emperor, he stands to also gain if the rebellion fails to garner a majority of the generals support, and thus the revolting defeated generals lands will be bequeathed to them.

This is a classic computer science problem.  It is also a game theory problem. What most people don’t know is that it is also a political governance problem.

Bitcoin solved all three problems.

I shall introduce each problem category in turn.

The Computer science problem:

How to send a reliable message to many generals at once, that can not be corrupted?

Coordination is the Key, but no one is in command!

Clearly, if all the generals could somehow coordinate their attack strategy such that they all attacked with their full armies on the same day, then they would all be victorious, and the oppressive regime of Byzantium would be overthrown.

The issue is that generals communicated by messengers on horseback.  Even if they each sent out messages to each other which would look something like “Hi, this is General Klang of the Klingon kingdom, I propose we attack next month on the 15th“. The problem is that he would have to wait until he got responses from all the generals, and see how many agreed and how many disagreed.  If more than 5 agreed, he should clearly attack on the 15th.  But do you see the problem here? It is one faced by all decentralized systems.  One of a needed delegated coordinator.  Why? Because without a designated coordinator, EVERY general will be sending messages to all others at the same time.  And while our General Klang proposed 15th of the next month to all, before he got the responses from the others, he also got conflicting proposals from the other generals. For example, General Koo of the Glam Klan, who was a bit more prepared proposed next month on the 1st.  While General Tso of Chikan, was really anxious, and proposed next week Monday.  Our friend General Klang can’t possibly answer consistently to everyone while being consistent to his own initial proposal, because the messages are all coming and going out of order.

What we need is a time stamping service. Then at least we can tell everyone to include messages that they also received when they sent the message, who suggested which day according to them, and eventually, because we have a reliable time stamps on the messages, we can eventually converge to a consensus on the day to plan the attack.  Hurray!

Alas, no.

Game Theory Problem:

The problem with the situation so far, is that in addition to the proper sequencing of messages (the computer science problem) we have the Game theoretic problem. Namely, that generals may lie.  They may lie about the day of attack proposed, they may lie about the time a message was received, they may lie about which proposals that they had agreed to or disagreed with.  And why not? They have incentive to lie. If 5 generals with their armies (or less) try to attack, they will fail, and Byzantium will reward the generals that did not participate in the attack.  And even if they all managed to agree on a day to attack, come that day, they may decide not to show up due to bribes.

What you need is a way to commit each general to their proposed attack day. Which means that once an agreed day between 6 or more generals has been reached, that the armies will be forced to attack on that day, and no amount of bribery or treachery will change that decision.  And we can achieve this by making the writing of messages costly in time and energy, in a way that is impossible to cheat.

What we need is something that would make messages costly in a consistent way.

In our scenario, imagine if each general had a magic well in their kingdom, and at the bottom of the well, was a bottle of magic ink, which can be used to write messages to each other (and a message written without this magic ink would not be legible to any general).  Each general would need to draw 1000 buckets of water from a magic well to drain it, in order to retrieve the ink at the bottom in order to write messages to his neighbors.  Once he has written 10 letters, the ink runs out, and if he wishes to write more messages, he must once again go back to the well (which has re-filled with water, and new ink bottle — it’s magic!) empty the well of 1000 buckets of water again.

As long as the time it takes to drain the well is sufficiently long compared to the amount of time it takes a horse messenger to get the message across to the other generals, this system ensures that the general cannot afford to write false messages to the others, and if he did, he would have to drain the well and get more magic ink again to change his mind, and by that time, the other generals who didn’t lie will have already come to an agreement on the day of the attack.

This last part is what Craig Wright (as Satoshi Nakamoto) solved. Unfortunately for the generals, magic wells didn’t exist. But in present day computers, we can effectively do this.  Satoshi took something that was invented back in 1993, called “Proof of Work”(PoW) by Cynthia Dwork & Moni Naor (not Adam Back!) and applied it to Bitcoin. PoW meant that you can make your computer do a provable amount of work (draws from a electronic well) before you can send a message. If a message arrived without proof of sufficient work, you disregard the message. Voila!

Solving this need for commitment meant that Craig solved the famous double-spending problem in electronic cash systems in the past.  Double-spending is just spending the same coin twice. Sending a coin to A, then sending the same coin to B. Previous to BitCoin, if you wanted to prevent double-spending of coins, you needed a central coordinator with a ledger of who owns what. If you are an astute reader, you will realize that this is exactly the same problem when the generals would say “15th of the month” to one general, but “1st of the month” to another.  It solves the problem of lying, in a decentralized way, by making lying costly.

Hurray for Satoshi! He solved the computer science problem and the game theory problem at the same time!

But what of the third problem, the one of political governance?

Political Governance Problem:

How does Bitcoin solve that? Well, like Indiana Jones, with the holy grail right in front of him, the unassuming carpenter’s cup… the answer is crystal clear to those who have a pure heart and wisdom.

I shall give you a hint, and you can see whether or not you are worthy to understand the truth.

Going back to the scenarios with our Generals in circa 1200 Byzantium, IF they had a way, by which the surrounding vassal kingdoms could reliably coordinate an attack onto Byzantium, in a fool-proof way, each and every time, then wouldn’t that be a very strong incentive for the Emperor not to mistreat his subjects? Or his generals? And if the Empire ever got bigger than 5 of the vassal states put together, there would be an incentive for the 5 biggest generals to coordinate an attack, take over Byzantine, and divide up the land between the rest.  This would mean that the size of Byzantium would tend to never grow bigger (or more wealthy) than 50% of the rest of the kingdoms put together.

Think for a moment.

Whoa.

Did we just solve the problem of responsible democracy that self regulates?

We didn’t.
But Craig Wright might have.

(edit: upon permission, edited to name Craig Wright explicitly)

 

Bitcoin.com’s new “Trading Platform” really just for online gambling?

No KYC?? Yikes! Risky. That is just thumbing your nose at the FBI isn’t it?

 

Bitcoin.com recently launched a new trading platform. Bitcoin.com Trading
Except that they don’t list it as a trading platform, as that would fall under the new FINCEN guidelines, and potentially land them in trouble with the law.

 

Even if we believe Bitcoin.com’s pitch that his exchange is for trade, it is probably more useful for unlicensed betting. Why?

From their own FAQ:

https://local.bitcoin.com/faq

Oracle needs only to decide offline who the “winner” is. The oracle cannot arbitrate a settlement or change the payout of the escrow in any way.  Bitcoin.com is calling this “Blind Escrow” service, where the ‘escrow’ is not really custody of any funds, they just decide the winner of the pot.  This is not escrow at all.  This is bookmaking, just thinly disguised.  This is allowing online betting in a trust-less way. (or not having to trust the bookie… or do you? More on this later)

As an escrow-ed exchange service, Bitcoin.com’s trading platform is not any better than standard escrow contracts.  So it is a POOR replacement for the service that they are ostensibly trying to put themselves off as.

  1. Why? Think of this example:
  2. Alice agrees with Bob to buy 100 DASH for 10 BCH.
  3. Alice locks up 10 BCH into Bitcoin.com’s blind escrow contract.
  4. Bob never pays Alice the DASH, but tells Bitcoin.com that he did
    Bitcoin.com (oracle) investigates and asks Alice if she received the the 100 DASH

    1. If she has (and bob has paid): (ignoring for a moment how she can prove this) then the oracle signs the txn and gives to Bob
    2. If she has NOT: (once again, ignoring the problem of proving this) then the oracle signs the txn and gives it to Alice.
  5. Alice OR Bob, gets the FULL 10 BCH, that is the only 2 outcomes…. OR IS IT?
  6. The third outcome is that Alice refuses to sign the txn to Bob, AND the Oracle is given a cease and desist order to stop signing txns as it is acting as an unlicensed exchange market operator, which means it cannot sign. This means Alice’s 10 BCH LOST FOREVER

Compare this to the standard Escrow contract in Bitcoin, (using Multi-sign or thresholds sigs) where if the escrow company is shut down for whatever reason, the 2 parties (despite their dispute, may be able to broker a compromise and send the 10BCH to a new Escrow company who can arbitrate a mutual settlement between Alice and Bob. There are countless reasons why Bob may refuse to pay the full original agreed amount of 100DASH to Alice…. perhaps the market crashed and Alice delayed the trade, perhaps there was a fork, and Bob doesn’t want to send pre-fork coins. etc. etc. etc. In these cases, it may be necessary to renegotiate the amount that is paid to which party, as well as perhaps pay a new escrow additional fees.

The real world is full of agreements that need to be renegotiated everyday. Bitcoin.com’s exchange does not allow for that.

The way they have it currently setup, even though they advertise it as ‘trust-less’ ironically means that the seller has to bear the risk of trusting that the trading platform is not forced to stop their service in the middle of a transaction that has gone bad.  Which will limit the amount of legitimate uses for this system.  The kind of activities or actors which won’t be too fussed about this? You guessed it, illegal actors, gamblers, money launderers.  They will be willing to take the risk, because they have no where else to go to be served.

In truth, the PROPER way to handle this type of peer-to-peer swapping is via an atomic on-chain swap which swaps the keys on both sides at the same time, coupled with a timed refund txn. (one of nChain’s patents).  If the deal were to go bad, then the parties can always seek a licensed escrow to provide an arbitration service, for a fee.

More on that next time.

/EOL

/begin Metanet

The Bangkok Summit: The failed last attempt to prevent the BCH Split

So the BCH fork is over.  And one party sort of cheated by bringing in their mercenaries to fight the war, and to usurp their BCH chain for themselves, which was not miners who have been mining the chain for the since BCH’s birth.

But leaving all that politics behind, I would like to leave the official record of the Bangkok meeting which took place in Aug 30th 2018, in which the ABC and the nChain group and chinese miners tried to keep BCH together as one blockchain.  I leave the whole record here for you to do your own research, as nobody has since had the time to create a transcript of the record, but I will give you some very important timestamps so you don’t have to listen to the whole 3 hours…

The infamous Bangkok Summit.  The last time the BCH community was in one room… and also the inside story of the fork split that crashed the whole crypto market.

Bangkok BCH Miners and Developer Summit Aug 30th, 2018

To save you from having to listen to the whole 3 hours (it has yet to be properly transcripted), I will give you the timestamps of some of the highlights.  But I encourage those who are true truth seekers to listen to the whole thing.  Don’t take my word for it.

I’ll skip the initial 3 or so presentations, which was just the hosts welcome, BU’s chat, ABC’s presentation, and nChain’s plea for quicker scaling.  Jumping straight into the panel discussion with Amaury (head ABC dev and self declared ruler of BCH), Shammah, (2nd in command ABC dev), Steve Shadders (nChain head dev), and John Fletcher (nChain head researcher).  This was the infamous panel where CSW, “called bullshit and left the room”.

Panel Discussion with the nChain and ABC devs (timestamps by VLC player)

Apologies, I was made aware that the timestamps may differ a bit depending on your player. I used VLC.

1:12:04 is when ABC Jason Cox and Shammah starts giving reasons why the block size cannot be lifted at this time.

1:13:35 is when Amaury starts talking about how the block size cannot be increased because there is an attack where an attacker can send an SPV node an endless stream of txns and they cannot know they are invalid txns until they stop and they can actually verify it with the MERKLE root.  This is the flat lie, (or it shows how Amaury is already assuming that Bitcoin uses his proposed MERKLIX tree idea (currently in the roadmap for BCHABC) because using that data structure it is INDEED true that you could attack a SPV node this way.  But why CSW left in disgust (unknown to many at the time because people didn’t recognize Amaury’s lie) was that MERKLE trees have a certain depth, and all txns are at that same depth. That means once you get ONE txn, you can hash it up to the merkle root and you know the depth of the tree, and thus the total max number of txns that you should be expected to receive in the block.  To understand this, all you need to know is simple geometry. A merkle tree is a tree structure in the shape of an equilateral triangle. (with the exception of the last row, which may be incomplete), that means, once you know the height of the triangle, and span of the base of the triangle, you know the area of the triangle. (it’s a close enough analogy).  Thus, CSW was right, and Amaury was either being deliberately deceitful, or just forgetting how Bitcoin works, and maybe thinking more about how his version of BCH would work after CTOR and merklix trie implementation. (where it no longer has a triangular shape, so the depth of any given txn would not give you any information about what the maximum number of txns in the block would be.

1:40:18 Andreas Suisani (BU dev) talks about how blocks aren’t full yet, so it’s not a priority.

1:41:18 I speak about the need for blocks to be bigger than the actual use patterns observed, because businesses need to see the block space being available BEFORE we even fund any projects that will use the space.

Discussion about what the current problems that need to be voted on:

2:59:30 —  The question of block cap size raising starts to get discussed.  The discussion gets bounced around back and forth on the issue of whether or not the block cap should be increased before the businesses start using it or after it starts to be obvious that it is needed.  Many people chime in on this including Emil from Bitcoin.com, Roger, Jason Cox, Shammah from ABC, and frankly the main question is just avoided and dodged for the next 7 minutes.

3:14:25 I pull the meandering discussion back to the MAIN issues that needs to be resolved here at this summit, namely, the question of whether or not these CTOR and block limits issues are important enough to split the fork over.

3:19:05 Amaury starts whining about how CTOR was agreed but nChain later disagreed and left and then wasted everyone’s time by leaving the dev discussions. (those discussions were done in Chatam house rules and no transcripts were kept.)  His argument that CTOR was agreed by the devs who attended those private dev meetings is his only real defence of why CTOR should be included in the Nov 15th fork NO MATTER WHAT nChain (with Coingeek, the largest mining group) says.  Pretty much the devs are the ones that make the call.  Miners shouldn’t need to care, just need to agree with them.

BIP135 was mentioned by Dagur and Andreas as a way to resolve the dispute by the miners, but none of the chinese miners seem to be supportive of it.

The rest of the discussion (if you really want to bear through listening to it all) is ABC devs consistently focusing on the need to improve communications with miners (basically how to educate miners about the things that the devs have already decided in their private dev meetings of which they kicked nChain out of)

3:24:45 I summarize the whole day and the ideological question that is posed to all the BCH community.  I called out the ideological differences in the scaling strategies.  The answer to my question was when I realized that BCH was dead.

This was the last time the BCH devs, miners and community was all in one room. It was apparent that after this meeting, the existing BCH community was already fractured.  There were the anarchists that want to push the agenda of a grey market platform, to compete with DASH or Ethereum using Wormhole and ICOs, or whether or not we should just focus on scaling via the original Bitcoin model and let all the businesses build the ecosystem.

This is why we now have BSV and BCHABC aka BAB.

There was no way that the people at this summit was going to agree on these fundamental differences.

There was just too much individual agendas at play, and too much difference of opinion on what was important for the ecosystem, and what the developers roles to play vis-a-vis miners were.

I went to this meeting to try to find some common ground to prevent a BCH chain split.  What I found out was that one side (ABC) was already determined to split no matter what.

Now you all can decide with your money.  Each chain is separate, and only one is maintaining the original goal and roadmap of Bitcoin.

/EOL

 

Nov 15th BCH Fork: Nakamoto Consensus will FINALLY be tested!

Nakamoto Consensus is upon us! All hail!

With the first real hash vote ever to occur in Bitcoin Cash set to occur in less than 10 days, it’s time to take a step back and really take in the enormity and the significance of this event.

We are literally seeing the FIRST practical application of a mass decentralized consensus system (aka ‘vote’) that needs no administrator, no organization, no coordination, no public debate, no polling stations, nor any face to face meetings! It is Nakamoto Consensus, as Satoshi created it. It itself is a pure system. Like the evolution of life, it needs no coordinator. Nobody tells a honey bee how to build the cells in the hive. Nobody tells each ant what to do or manages its daily work schedule. Nature just figures this out by way of naturally finding the most efficient solutions. But humans are a strange creature. We like to think. We rationalize. We are a social animal, and as such, we are predisposed to rely on social consensus systems. We create rules for ourselves, and we like to negotiate these rules amongst ourselves so that everyone concerned feels like their individual needs were considered, for a common sense of enfranchisement.

But Nakamoto Consensus doesn’t work like that. It, like mother nature, has a very simple rule: those who behave in a coordinated way that benefits the network will profit more than those that defy consensus. It’s as simple as that. The only remaining thing we need to add to that formula to make it all work is the simple assumption that people tend to want to be profitable, rather than not. With that one simple assumption, the automatic consensus system is complete, and we can rest assured that consensus will be obtained, passively, automatically, without supervision or orchestration.

Well, at least in theory. That is the idea of how it will work, but because Nakamoto Consensus is a ‘natural’ system, it is very hard to analytically work out exactly how long the consensus process will take in practice. There are just too many variables that factor into this equation to model, and much like trying to predict the market, which is the sum aggregation of millions of independent decisions being made by individuals, it is not trivial. That is what makes what will happen on Nov 15th very interesting to those of us who have been in Bitcoin for years, but have never been able to witness how well it holds up in defending against competing protocol changes via a hash vote.

As is the case for most natural phenomena which have yet to be well understood, there is no lack of theories concocted by pundits on all sides on whose votes actually count in such a hash vote. Their arguments generally fall into one of the following categories:

Individual Nodes decide

This is the belief that a majority of the nodes in the network (ones run by individuals like you or I) collectively decide what the network will accept as protocol changes. This is of course, a fallacy, because it is only in the extreme case where all nodes of the whole network were controlled by a collective power would all the nodes be able to rob the dissenting miners of the value of the rewards that they mine. This is of course an impossible situation on premise alone as the assumption is that the nodes are individually controlled. If we had a system that could coordinate the collective behavior of all the individual nodes in the network, then we would have no need for a decentralized consensus system in the first place. This misguided belief was the origin of the “UASF” movement, which was a grass-roots lobbist group which tried to convince the market that the node population (the common man) had enough power to influence network changes. They were never given a chance to be proven wrong, unfortunately, as after the NY Agreement, the supporters of big blocks conceded to split off into BCH instead of forcing the fork.

The ineffectiveness of individual nodes and their irrelevance to the network was later demonstrated when researchers confirmed that the Bitcoin network was a small world network, (one in which the number of average hops between any given 2 nodes was less than 3) and that most important connections exist between mining pool nodes. If individual nodes wish to partition themselves from the network it would not affect anyone else but themselves.

Economically Significant Nodes decide

This is the idea that nodes of exchange businesses, wallets or otherwise ‘economically significant’ players in the community have a vote in the decision. This believe isn’t too far-fetched. In reality, exchanges have some influence as the decision of whether or not to trade a split coin is in the hands of each individual exchange, and the decision to support a given upgrade fork of a blockchain is made by every wallet service provider.

The belief though that their opinions influence a hash vote, however, is less grounded in reality. In truth, although they are well within their rights to provide whatever service they wish to the public, using this support (or threat of withdrawing said support) as leverage during a hash vote is nothing but posturing. Exchanges and wallet service providers are businesses. (With exchanges having to further operate under strict regulatory regimes). If the market demands a service, someone will provide it. But as they are not miners themselves, they will have no way to provide the security support needed for a minority fork chain. Without this it would be very risky for them to provide services to their customers, but it is entirely up to them.

Developers decide

This is the biggest misconception in the industry. It is the myth that the developers that maintain the blockchain client code are the ones that control or influence the decisions to be made on the network. This is the model that most of the legacy bitcoin (BTC) developers operate under, (even though they will deny it themselves). Developers see themselves as the defacto ‘stewards’ of the system, and thus, their opinions should matter the most in guiding what the market and community should expect in terms of features or changes to the network. They use security and network integrity concerns as a basis for this claim, in which they convince the community to ‘leave it to them’ as they know what’s best for everyone. It is very much the nanny-state mentality, or a technocracy. The idea is that this does not devolve into an abusive dictatorship so long as no contentious changes can ever be approved by all developers. Unfortunately, it also ensures that needed changes or upgrades can never make it in either, as there will always be at least one developer to veto (perhaps maliciously) any change request.

Notable personalities decide

This is a slight variation on the case above, where the notable ‘luminaries’ or visionaries, are seen to hold more influence over the system direction than others. This is the model seen in Ethereum presently where Vitalik Buterin (one of the original founders of the project) is seen to have undue influence over what changes are allowed into the project. The power of such leaders was demonstrated when the DAO roll back hard fork was initiated and which produced Ethereum Classic (ETC). The dangers of this system of course is that it can easily devolve into a dictatorship, albeit a benevolent one.

Mining Pools decide

Most people make the mistake of thinking that the mining pools count in the hashpower vote, and this is an understandable mistake. That is because when people ‘see’ the miners of a blockchain, what they are actually seeing are the mining pools. The mining pools are actually just service providers. They run networks and server nodes and they maintain the ‘miner network’ that most people think of when they imagine the backbone of the blockchain. Indeed, it is between these pools that the small world network that has been much talked about actually exist. When blocks are found, they are found by the mining pools, and they are communicated the quickest among the pools. However, these companies, are not the ones that have a vote when it comes to a hashpower vote. If the power to vote belongs to ‘citizens’ of a country, then the mining pools are the companies in a country. They only provide the infrastructure of the network so that the true citizens of the Bitcoin ecosystem can participate in the network. It is true that without them, there would be no way for the network to operate, but if they were to act in a way that defraud the network’s constituents, or if they are not faithful to the wishes of the hashpower constituents, then hashpower will leave them and they would be out of business.

Hashpower decide

Hashpower is the true decider in a hashpower vote. That is to say, those that own the hashpower production assets are the only ones that have a vote in a hashpower election. They decide which mining pool to build blocks for, therefore they effectively decide which chain in a fork to build upon. They have the most skin in the game (collectively) because they are the ones that have committed 100% risk capital to the success of the blockchain and the appreciation of the coin. Data centres can be re-purposed, servers can be re-sold, coins can be dumped for others, but the only thing that becomes worthless scrap if the blockchain fails is the ASIC mining assets. They cannot be repurposed, and therefore they must be written off as losses. As it is, the industry writes down mining assets to zero after just 2 years of depreciation. If they don’t make back their value in 2 years or less, then the business may as well have thrown their money into a bonfire. That is the fundamental reason why hashpower are the only ones that you can be assured of to care the most about the long-term value proposition of the blockchain that they are mining, and the reason why they are the ones that can be trusted to make the best decisions for it. Their vote is weighted in proportion to the amount of hashpower that they own. The larger the portion, the bigger vote they have and the more influential they are. (and subsequently, the more invested they are in ensuring the maximal value be realized on the blockchain).

At present, the only (known) mining pools that own their own hashpower at present are:

Coingeek

BMG

BTC.top

The other mining pools that are listed at sites such as coin.dance are actually mostly hosting businesses and the hashpower that they host are actually their clients. Whenever you have clients, you are answerable to them.

I hope this illustrates why the fork on Nov 15th will be very interesting to watch. We already have plenty of ‘noise’ posturing by companies announcing their support for one fork or the other. At the end of the day, unless the company owns hashpower they actually don’t matter at all and they are only declaring their disregard for their clients if they promote one chain vs the other for ideological or political reasons. The only constituents that have the right to be political are hashpower owners. They paid for the right to vote. They paid for their opinions to be counted. (in proportion to their investment).

So on ‘election day’ on Nov 15th, we will see the actual constituents of Bitcoinland speak, and speak with their investments. Make no mistake, if you don’t own hashpower, you don’t get a vote in this election. Some folks may tell you that you do. Some folks may say that the market decides, by way of resulting price of the coins (subject to manipulation) and they will offer you the option of participating by way of buying one fork coin while shorting the other. Do not be fooled, these are only derivatives, and carry with them all the risks that derivatives do. If an exchange offers you claims on the forked chain coins BEFORE the hash vote has determined the majority winning chain, then they are offering you a HIGHLY leveraged bet, as ANY balances in a minority chain may be unpayble if the majority chain eliminates the minority chain (when most hashpower stops mining the minority chain). All minority chain balances disappear as fast as they were created.

The right thing for exchanges to do is to withhold trading in BCH until the majority chain is determined, and then switch to that chain. As an exchange that values the integrity of their customers deposits, they should not be favoring one chain over another, and certainly not encouraging rampant speculation on assets that may not even exist by supporting one chain as a matter of principle. The only right chain, is the longest PoW chain.

In summary, unless you own hashing power, you don’t have a vote. You may think you do, you may want it to seem like you do in order to influence others, but at the end of the day, the only party that answers to nobody is those that own hashpower. Everything that everyone may say or do or proselytize about, is nothing but political posturing, amounting to nothing more than campaign commercials. In the end, only the hashpower is counted, and the hashpower should be highly incentivized to come to consensus on a majority chain, and let the remaining one expire. Than is Nakamoto Consensus.

We don’t need anything else.

Ripple and Lightning Networks: The Nuts and Bolts

Last time, I spoke about how the bread and butter use case of Ethereum was going to be soon challenged by Bitcoin Cash, when the missing op-codes are re-enabled in the upcoming May 16th upgrade.  Today, I will discuss more about the other use cases which BCH is going to challenge, as a payment system and the biggest challengers in that space.  Yes, many expert bitcoiners will recognize that Bitcoin Cash is aiming to be CASH first and foremost, but that doesn’t preclude its use as a payment rail as a secondary use case.

Firstly, it will be good to explore exactly what is the difference between a payment network and cash.  Most simply, cash is an asset.  It is something that cannot be taken away from you without force, because you solely have the ownership of it, and you solely decide when to keep it or when to give it away.  A payment network is simply a system by which transfers of ownership rights can be tracked, requested, processed, and settled.  SWIFT is the most popular payment system among first world banks today, and among consumers VISA is a payment network that allows you to pay for things with credit extended to you by a credit issuer.  It is important to note that while Bitcoin can be thought of as a payment network, (given the nature that all the assets are publicly visible and moved on the blockchain) it is first and foremost an asset ownership ledger.  And Bitcoin (the coin) is an asset, not just a utility token.**

The biggest players in the digital payment network space these days are Lightning Network (built on top of the Bitcoin asset blockchain), and Ripple.  Both have a ‘usage token’ that you have to buy to use it, BTC and XRP respectively, but these networks have a very different approach to solving the same problems.  And, I will argue, these problems don’t exist in the Bitcoin Cash blockchain.

Lightning in a Bottle

First off Lightning Networks. I first spoke about it back in Oct 2016, when the developers first said that they were ready to deploy the network real soon.  The problems I saw were not so much the technical issues (because there were so many technical issues that it wasn’t worth getting too deep into the details at that early stage) but more the economic problems –IF the network were to be adopted at scale.  Those issues have not changed, and we will re-iterate on them later in this post.  Let’s first discuss the matter of trying to “Fix something that isn’t broken”.  The best way to think about LN technically is through an analogy in the physical world.  In the world of motorcycles, there are many types of experimental steering mechanisms.

This is what Lightning developers think they are building:

LN is betting that their technology is both sorely needed and will revolutionize the industry

For those not into bikes, the way a motorcycle steers is very different from how a car does.  Basically, you have to move the handlebars in a direction which is opposite to the direction that you want to turn.  This is called counter-steering.  In addition, the front wheel due to its role in steering has been traditionally mounted using a fork system.  This means that the wheel is held between 2 shock absorbers, which joins the main frame of the bike at the headstock, or the pivot point of the steering system.  This wheel mounting configuration, while most common and simple, combines the steering system, with the braking system, and the suspension system.  This has some disadvantages however, which I won’t get into here, as this is a financial technology blog, and not a motorcycle one (though I’m happy to go into for the riders out there). Very much like Bitcoin, the LN developers and many of those who support the legacy version of Bitcoin (the one disabled with 1mb maximum blocks and segwit) they see these self imposed issues needing to be fixed and LN seems to be the solution.  The bizarre bike in the following figure is how they see the LN network becoming:

LN developers think they are going to ‘fix’ Bitcoin with revolutionary technology

Keep in mind: this is IF the dream of LN can be realized without any complications or fundamental bugs.  In the best case scenario, we will get something like the Bimota Tesi, a beautifully engineered, overly complicated, and expensive motorcycle that looks bizarre and exotic, sure to turn heads, but is very rarely seen on the road as a performance bike because the complicated steering removes all the ‘feel’ and control out of the steering.  Needless to say, for all its purported benefits, no rider of MotoGP has ever taken a Tesi to the track in a serious race.  That pretty much says it all.  However, this was in the best case.  In reality, the LN technology at present looks more like the following bike experiment:

LN: the current state of the technology

An overly engineered experiment that suffers from having to solve engineering problems that it introduced itself due to its overly complex fundamental design.  The world doesn’t really need a hub-steering, 2-wheel drive, diesel powered motorcycle.  Well, not presently anyhow.  The other critical point is the matter of ownership. Recall that I mentioned that Bitcoins are assets.  And that having total and complete control of your assets (or having the option for complete control) is part of the rights of the owner of an asset.  In LN, you are forced to put your asset (Bitcoins) into what is effectively a bank account.  This bank account is a weird jointly owned bank account that you have opened with another peer, which LN folks call a payment channel.  Your Bitcoins locked in such a channel can only go to or from the peer that you opened the channel with, so in order to fix that problem LN network is developing a massive IOU balancing/routing system to make sure that if you need to pay somebody or get paid that it can be done through one of your existing payment channels if possible.  Even if this were all to work, the fact of the matter is that your Bitcoins are still locked in channels, and even though you can technically remove them all if you wanted to that would require many transactions to do so in practice for any decent sized wallet, which would be costly. In addition, there are also new attack vectors that are introduced where a thief can try to steal your locked coins in the hope that you aren’t watching the channel.  Don’t take my word for it (though I DID warn about all these things back in 2016, but you probably don’t remember) read it from the LN Dev blog yourself!  If you manage to get through the post without being totally confused, then at least you will have an impression of all the extra complications that using LN coins will involve.  I would rather not peg my Bitcoins into the LN network if I could just use bitcoins directly.

In practice, LN is exactly like the existing banking system.  Yes, you put your money in the bank and it is ‘technically’ still yours, and yes, you CAN take your money out when you wish, and 99.9% of the time that is fine.  But just like in a banking system, the 0.01% the ownership of your property can be violated, as those who had money in Cyprus Banks found out in 2013, when the banks basically bailed in themselves with their own customers money.  LN seems very similar to this system.

 

Ripple: The network that tried to bootstrap itself with its own tokens

With Ripple, the situation is slightly different.  They were originally a IOU passing network, which wanted to have everyone issue their own IOU tokens on the network, and to manage the transfer of these IOUs on a standard platform.

Ripple’s original network was designed to be an IOU passing network

That standard platform would be a shared ledger with a common consensus protocol, which is what most people call the Ripple network today.  The token XRP was created from nothing, and was originally intended as a spam prevention measure, as to send increasingly more transactions to a node would mean that it would cost more and more XRPs.  Also the intent was that every transaction would destroy a small amount of XRPs so that increased use of the network would slowly appreciate the value of XRP, due to fixed number of them in existence.  It may surprise most people to learn that Ripple actually existed before Bitcoin was released, though it should be mentioned that the Ripple network today looks very different from the original one.  Ripple didn’t like the concept of doing work to earn the inflation of the coin, and thus it had a distribution problem.  Where PoW in Bitcoin made the distribution of the coins very simple (you spend time and energy to mine, you earn coins, whoever you are), Ripple created all 100,000,000,000 XRPs and granted it to themselves a non-profit foundation, early investors, and struggled to figure out how to get them distributed down the pyramid to regular people.  The way XRP was distributed harkens back to how money in a central banking system is distributed.  It is printed by the central bank, then it is sold to large investment banks, which then pass it onto regional banks, and finally to the regular people through loans.

Their approach brought about it some self-induced problems that they then had to solve.  How do prevent some of the large early holders of XRP from hoarding their distribution?  How much should be kept aside to pay for development? How much XRP should be burned on each transaction?  And most importantly, if all the tools and applications look like they are useful, what is to prevent a rival network from just forking the code and running their own version of XRP with a NEW distribution of funds?  These are big issues with the Ripple business model, which requires that they sell the technology to large banks first, which ostensibly want a payment system that costs less than the existing SWIFT payment systems.  To this strategy Ripple is developing trading interfaces and applications to make exchanging IOUs (which may represent fiat currencies or other tokens) to/from XRP easier.  The strategy that they are now pursuing is to position XRP as a bridge currency for FX speculators to hold in order to reduce the volatility of marking markets in low liquidity currencies such as Venezuelan Bolivars or Israeli Shekels.

The issue with the strategy is that many times in economic history people attempted to create a stable bridge currency for the banks of the world and have failed.  The original attempt was proposed by Maynard Keynes, the bancor, and was a failure (no relation to the recent ICO called Bancor, which was also a colossal failure).  The second more recent attempt in the last couple decades is the SDRs proposed by the IMF, which is based on a basket of the G8 currencies, also largely a failure.  Something about having to use a complex instrument controlled by a 3rd party to hedge your own foreign currency risks didn’t appeal to the central banks of the world.  After all, every central bank had a different unique set of problems they are faced with, which necessitates a different hedging strategy.  For instance, a country in South America may do most of its trade with the US, which means it would want to hedge its balance of trade risk with a heavier weight put on USD instead of say, EUR.  At the end of the day, hedging FX with a specific central bank non-negotiable instrument wasn’t as straightforward as just holding the foreign currencies yourself (and less useful).  That is the problem with the “XRP as a bridge currency” strategy.  Why hold XRPs when you can just hold the USD, JPY, EUR yourself?  Which means XRP becomes nothing more than an necessary evil, in order to use the payment network, to put a cost to DDoS attacking the network with many transactions.  But if the network is going to be a wall-gardened curated network and used only by registered banks, then the risk of attack is minimal.  Leaving XRP’s only true value as a speculative instrument that is loosely and informally tied to the usefulness of the Ripple network itself, and the applications that Ripple Labs is creating for it.  Astute readers will note that this is also the same base value proposition as Bitcoin. (that its value is related to the usefulness of the blockchain itself) but the difference is that Ripple created all the XRP out of thin air themselves, and they themselves decided how to distribute the tokens.  Who knows if they played favourites.  Also creating the tokens ex nihilo means that they may very likely be treated as a security by the SEC.  As only securities are created in this way, (well currency is as well, but the central banks have the exclusive license to create those), so there may be complications for those that raised funds by granting XRP to investors.  Furthermore, if XRP were to be considered a security that would severely limit its trade in US and other first world countries further limiting its use as a bridge currency for FX liquidity providers.

Lastly, the problem with XRP comes back to the beginning statement where I posited that Bitcoin is an asset, which means you own it, and nobody else. This is achieved in Bitcoin through both asymmetric key cryptography (you own the knowledge of your private keys), and the decentralization of the mining ecosystem itself. Mining is its own business, and the business of the miners isn’t to run a payment system.  The unique fusion between a commodity extraction business that is concerned more about cheaper greener power generation and the processing of a financial payment system is what gives Bitcoin its power, and Satoshi’s true innovation.  If you build a token market on top of BCH, trying to steal peoples assets, or to freeze their BCH would be very costly and not guaranteed to work.  In comparison, if Ripple at its hypothetical apex, when all central banks were to use it for its inter-bank transfers, and you were a liquidity provider who have been stockpiling XRPs in order to make profit from the imbalance of flows between North Korean Won to the US dollar, you could be denied access to your XRP if all the central banks of the world just refused to listen to the nodes that broadcast your transactions.  Where Ripple uses similar cryptographic security to enforce proper signing of transactions, unlike Bitcoin, a Ripple that banks will use will only trust transactions from each other.  You will not be able to submit a transaction that the banking consortium disapproved of***.  And the banking consortium would not allow a trusted validator into their cartel without ensuring that they were going to play by their rules.  So the difference between Ripple’s decentralization strategy vs Bitcoin’s is that Ripple has a trusted server list (called the UNL) and transactions received from the list are assumed ‘blessed’ (assuming they are valid).  Transactions received from outside the list are not treated the same.  Basically in Ripple, anyone can connect to the network and send transactions, but unless your txn is acknowledged somewhere down the line by the main validators, it won’t make it into their ledger.  And membership to the main validator pool is similar to a cartel formation.  “I’ll put you on my trusted list if you put me on yours”.  Every bank using Ripple will certainly guard its UNL list and ensure that only other licensed banks are on their lists.  Contrast this to Bitcoin, where nobody can stop anyone else from participating in mining, — that is the true key to decentralization.

It is going to be an exciting next few months, as more and more features of ‘speciality Altcoins’ stand to be usurped by BCH as the true power of the original Bitcoin design starts to come to fruition.

For the industry to grow and expand in order to reach the maximum number of humans on the planet,  therefore ensuring its survival through future regulatory and political pressures, it needs to be simple, elegant, and functional.  So despite the above experiments in technology being very cool for bike geeks like myself, I would much rather just have the original and best:

Bitcoin – The original and best. Simple, elegant, beautiful, efficient

/EOL

** this stems from the fact that Bitcoins require energy to be burned on creation.  Which means they are at least worth the value of the cost of mining them when they are granted.  Utility tokens, on the other hand, like all tokens, have no intrinsic value, and are created ex nihilo.

*** well, you could submit it, but it will never make it into their ledger.  It may make it into yours if you reduced your UNL list to only have validators which were not part of the banking cartel, but in that case, you have effectively forked off into a parallel ledger.

Move over Ethereum: New functionality for Bitcoin Cash makes it a Smart Contract Contender

Smart contracts.  It was dubbed Blockchain 2.0.  (Blockchain 1.0 was cash) It held all the promise of a new world, a new digital frontier.  It was to herald in an age with broker-less deals, robot escrows, AI oracles, and driverless automobiles being their own corporations as self-reliant actors in the new digital economy.  An economy which did not discriminate between true born humans and machine code born automata.

That was the dream.  That was the promise.  That was what everyone spoke about for the last 4 years.  Except that that never happened.   Oh, there were many attempts.  Some achieved some modicum of success, some less so, even others ended in full blown multi-million dollar fraud or theft.  (Yes, I’m talking about most of the projects in Ethereum space, especially, but not exclusive to, the DAO.)

Let’s talk about Ethereum for a bit, as it is the blockchain with the most activity in the Blockchain 2.0 space.  Arguably it drew away most of the Bitcoin developers after its launch in 2015 as the blockchain built for smart contracts and other programmable money uses.  But at least half of its success is due to the fact that Bitcoin around that same time suffered some pretty big crippling self-imposed limitations that would all but exclude it from being a contender for the mantle of programmable money.  In fact, Vitalik Buterin, the founder and spiritual leader of the Ethereum movement, was originally a bitcoiner, and he was only created Ethereum because the Bitcoin core developers at the time deliberately went out of their way to disable many of the functionalities which would allow for a programming language for smart contracts to be done on Bitcoin itself.  So Vitalik did exactly what any good decentralist did when he was faced with oppression by the established regime.  He left and did his own thing.  He went and started designing Ethereum.  This was 2013.

However, because he had to build it from scratch, or perhaps because Vitalik didn’t have the same insights as the Satoshi did, he approached the design of Ethereum in a pretty naïve fashion.  He wanted a turning complete language so that it would be easy for developers to write smart contracts.  But a turning complete language would mean that infinite loops would be possible, which would be a bad thing in a globally decentralized blockchain.  So he resolved that using an economic protocol cost that would be applied to each computational step, so that you would need to pay per operation, and programs gone amok would run out of ‘gas’ and thus stop execution.  But this introduced a whole new category of complications: how much would each operation cost relative to others? Relative to the total computational capacity of the whole network? How would this scale as time went on?  He then went on to  ‘solve’ this new problem in a way which added even more complexity, and thus, yes, opened up a new class of problems.  He decided that the protocol should just change the rates every so often, by edict given by the outside world.  Miners should be able to decide what the gas prices should be and magically come to consensus on it heeding the advice of the senior ETH core developers –it was the ‘central bank’ approach.  Economically speaking, Ethereum was already becoming much more complex than Bitcoin, and writing and testing smart contracts could sometimes get costly, as your bugs will burn away your ETH as you make mistakes.

Scaling issues

To further the issues, Ethereum has some serious scaling hurdles.  You may have heard of how one wildly successful application on ETH called “Crypto Kitties” nearly melted down the entire network several times in the past due to txn flooding.  How?  It’s a very addictive digital card collecting and trading application, where ‘digital breeders’ can make their own unique kitten mutations and sell them for ETH.  Once many people start using the application at the same time, the network floods with transactions and the whole blockchain slows to a crawl.  But why?  Because the designers of Ethereum took another naïve approach to the problem of STATE and STORAGE.  Basically if you are going to have to run programs on the blockchain, then the code for the programs and it’s interim state, (the memory of the program has as it moves from instruction to instruction) is all stored on the blockchain nodes itself.  Which is to say, EVERY ETHEREUM SERVER is storing EVERY PROGRAM’S STATE.  That’s a lot of wasted storage.  Especially for people who really don’t care for digital kitten mutation as a past time.  And what is worse, every Ethereum server is also doing all the calculations for the Crypto Kitten decentralized application, even if you are not using it.  Basically, when Vitalik says Ethereum is a “World Computer”, he means it is a very, very inefficient computer, because every computer in the world, is executing the same code, and storing the same data, as everyone else, at the same time.  Yeap. Talk about the naïve approach.  It is pretty much the MAXIMALLY naïve design to decentralized multiparty computation.  _Have everyone do every computation_!  No wonder they have such a doozy of a time trying to scale Ethereum past the point where one popular application can wreak havoc on the network.

Well now, why do I bring up all these criticisms on ETH?  I’m not trying to throw cold water on their party.  In fact, I have great respect for Vitalik and many smart contract developers that I have met and know as they are truly breaking new ground in the space, and it is on the shoulders of their hard work that we will carve out the path to the digital frontier of the future.  However, I do want to bring up Ethereum’s fundamental design flaws because they will soon have a worthy competitor.  No, it’s not another complication smart contract blockchain, hatched out of the desire to make the founders rich. (there are _many_ in this category).  It is in fact, the sleeping giant, the original, BITCOIN.  But how you ask? How is it possible that now it can perform as a solid foundation to smart contracts but it couldn’t before?  Did Vitalik miss something? No, he didn’t.  Because the Bitcoin that he left is still stuck exactly as he left it back in 2014.  We are, of course talking about Bitcoin Cash, the offspring of legacy Bitcoin that decided that hard forks were an upgrade mechanism and that it would be OK to grow the network and add new or re-enable old features on it.

It is exactly the latter that will usher in the new age of smart contract development.  On May 16th 2018, BCH will be hard forking as part of their scheduled 6m update schedule, and one of the most exciting things that will be changed in the upgrade is the re-enabling of some of the old OP_CODES which were disabled by core developers out of fear that they may be insecure or open up attack vectors on the network back when the codebase was immature, and the network very small.  For the computer scientists reading this, the interesting instructions are OP_CAT and OP_XOR.  (concatenate, and logical XOR).  I won’t go into why these are very important, but if you are interested then you can read about how Bitcoin is effectively a Turing machine. This means that arbitrary calculations can be done on Bitcoin, using a method that separates the DATA and CODE from the proof of execution.  For the technically inclined, the analogy would be the Bitcoin blockchain transactions effectively becomes a micro instruction table, a set of CPU registers, and a program stack pointer.  All the data, the code, and storage is elsewhere.  This makes the Bitcoin model much simpler than the Ethereum model (store and compute everything on the blockchain nodes).  It’s such an elegant solution, that one wonders if it was always meant to be this way, designed by the original Satoshi, but somewhere along the way it just got derailed.  And why not? Everything else about the Bitcoin design is fairly simple and straight forward.  Coming up with it required several leaps of intuition, but when you read it the solution is surprisingly obvious. (One could reflect on the similarity of this “difficult to come up with, but simple to verify” method as the signature paradigm of the whole Proof-of-Work and hashing model itself. Indeed it seems Bitcoin is itself self-referential, or at least self-consistent)  Recall the original whitepaper was only 9 pages long.

So where does this leave Ethereum post May 2018?  It is anyone’s guess.  Ethereum still has several years of head start on Bitcoin Cash.  It has several custom languages that developers can use for writing smart contracts.  Bitcoin still only has its original SCRIPT, a language that is akin to programming on an HP calculator. (it is similar to FORTH).  But now that the missing OP_CODES will be brought back, that means that more high level languages can be built that can compile to low level Bitcoin SCRIPT.  I foresee a rich ecosystem of smart contracts and languages for developers to be built on top of Bitcoin in the years to come.  And of course, when I say ‘Bitcoin’ I mean Bitcoin Cash, the only Bitcoin that can be upgraded on-chain.

 

/EOL

In my next article I will talk about Ripple and its potential future, given its current strategy as a interbank currency payment system.

 

 

Time to start a new Chapter…

… in the Book of Bitcoin.  There comes a time in every story when the characters develop, evolve, die, or are reborn.  Such is one of those times in the grand adventure which we all started off on 8 years ago.  The Bitcoin Cash fork having successfully executed is now free from the oppressive roadmap which was being driven by Blockstream and Core, which would see most of Bitcoin transactions turned into just channel opening/closing tasks for untested 2nd Layer networks better suited for micropayments.

So in that vein, I would like to show everyone that micropayment payment channel applications don’t need to wait for Lightning Networks!  Yours.org is a homegrown, build by Bitcoiners, for Bitcoiners, paywall content platform that started off writing their own version of payment channels because LN wasn’t (still isn’t!) ready, then moved onto Litecoin because Bitcoin transactions got too expensive, but now thanks to the low fees on Bitcoin Cash, has moved onto BCC.  As such, I would like to support them by moving my blog onto Yours.org on a sort of a trial run.  Therefore, this month’s blog will be published there.  Yes, you will have to fund a BCC/BCH wallet in order to read the whole article. Yes, it doesn’t seem to support embedding media such as pictures inline yet.  But I hope that Ryan X. and team will be able to slowly improve their platform to the level of Medium or WordPress sometime, and it isn’t terribly hard to get your hands on $5 worth of BCC and funding the Yours.org wallet is dead simple.  Send BCC and it is instantly credited (no need to wait for confirms).

So without further adieu, I leave you enjoy reading about (and using!) Bitcoin Cash:

Bitcoin is Dead, Long Live Bitcoin! (cash)

If we are going to grow this community, we are going to have to start supporting its own economy, eat our own dogfood, so to speak.

 

 

Fork Wars Episode I – The Phantom Futures

If you haven’t been living under a rock for the last couple of weeks then you know that the whole block size debate is boiling to a close.  Segwit2x arose to be a compromise solution, lead by ex-core developer Jeff Garzik, brokered and agreement in New York after the Consensus 2017 conference which had over 90% of the miners and ecosystem in agreement.  Since then BIP91 has locked in, which is an effective lowering of the much exalted soft fork consensus threshold of 95%, by which half of the inner circle of core devs felt was deficient. Regardless of how this was on the surface seen to be a ‘lowering of the standards’ it was done anyway and conveniently so, as segwit was not looking like it would ever pass the 95% bar anyhow (ahem. “I TOLD YOU SO” to all the neckbeards out there, and u/jonny1000!).  Now that segwit2x/segwit is going to be ‘forced’ by way of 90% of the miners starting to reject non-segwit signaling blocks, this ensures that segwit’s threshold of 95% of last 1000 blocks will be met sometime in mid-August.  (yes, you read correct, BIP91 was an 80% majority agreement to come to a 95% agreement by forcing the 20% to agree with you or be orphaned — by force!).

This has set the stage for the drama to follow.  For one there is already a growing group of big blockers who have mobilized to fork off the current Segwit2x/Segwit Bitcoin (let’s call this SegwitCoin) who have identified themselves as BitcoinCash.  They are a fork of BitcoinCore 0.14.x with Segwit and RBF components disabled, and a 8mb Hard Fork coded to engage at Aug 1, 12:20 UTC time.  This guarantees that there will be a ‘big block’ Bitcoin regardless of what happens with the SegwitCoin and the expected in-fighting among the new ‘stewards’ of the main chain (Jeff Garzik and his btc1 team) vs. the old guard which have been deposed (Bitcoin Core, Blockstream). Continue reading

Keep the Change! — Replay protection is a Red Herring

Much about the current Bitcoin splitting debate has revolved around the notion of a hard fork splitting of the network being dangerous. So dangerous, in fact, that core developers have constantly stuck to the argument that the community should trust in their (exclusive) council in order to ensure that we don’t engage in anything that may be unsafe for ourselves. Trust them, they know what is good for us. When libertarians and skeptics around the world hear that they are immediately put on alert.

Most recently an exchange between ex-Bitcoin lead maintainer Gavin Andresen with Core contributor Matt Corallo was especially interesting.  Besides the run-of-the-mill talking past each other where Matt seems to ignore points that Gavin clearly addressed (regarding n**2 sighash issues, solved by capping txn sizes to 1mb) the core theme (pun intended) repeated again by Matt was that Hard Forks have no community support (by his own judgement) which is clearly shown by the fact that nobody seems to be giving much attention to the HF proposals in his (exclusive core dev curated) proposal list.  Not much surprise here, the standard echo-chamber reality distortion field stuff.  What was interesting, was that he once again mentioned the need, nay, the necessity of ‘replay protection’ in ANY hard fork proposal.  This is very important point in the core dev platform, as it serves a dual purpose.  One which on the surface is ostensibly for the public good, the other may be much more shadowy.  Let’s examine what replay protection is, and why we really don’t need it.

Continue reading

How will Bitcoin Miners be paid in the future?

The question of how miners will be paid in the long run, after mining subsidy rewards disappear is a much debated topic in Bitcoin.  For those who don’t know, mining rewards are set to half every 4 years until they finally reach zero sometime in the year 2140.  How the Bitcoin mining ecosystem will remain profitable (and thus healthy) is up in the air.  Miners are important as they provide security to the Bitcoin network because they convert real world energy into network security to guard against attacks from malicious forces.  Therefore, the more decentralized and diverse a mining ecosystem is, the better for Bitcoin.

So what will happen when mining rewards disappear? Well, some miners feel that transaction fees should rise up to fill up the shortfall.  As Ang Li puts it from an excerpt of the a recent article at Bitcoin.com

The incentives that Satoshi Nakamoto designed in the Bitcoin whitepaper are not enough to sustain mining for long, Li feels, adding that as the block reward halves every four years, miners income will continue to decline. According to him, keeping the block size where it New 22 Petahash Mining Pool Signaling Bitcoin Unlimitedis now will not provide enough incentive and therefore has to be reconsidered. Li also believes that only a larger mining transaction fee will maintain the balance. “By increasing block size, and transaction numbers, the fees will gradually replace the block reward, providing enough incentive for the miners to defend the bitcoin hashrate. This is the fundamental way to achieve healthy development of the whole ecosystem.”

Continue reading