Bitcoin Cash Development Series
The 4 projects I will summarize today are:
BUIP078: Enable Binary Contracts in Bitcoin Cash via OP_DATASIGVERIFY
BUIP087: Utilization of “cash” denomination
BUIP088: Double spend proof creation and forwarding
Graphene
BUIP078:
BUIP078 pursues the goal of reinstating code designed to make it possible to evaluate the condition of data included in transactions using an identical algorithm to the one already used to verify Bitcoin transaction signatures. The author of the effort’s description on Coin Dance, Andrew Stone, is of the view that this mechanism was deliberately rendered non-functional when Bitcoin was new to avoid a potential security weak point in a component deemed non-essential. The further mainstreaming of cryptocurrencies to him signals that it is a better time to run these algorithms. Stone's vision is that this reactivation will lead to more BCH users. The modification would include a hard fork.
BUIP087:
The authors, Ken Shishido and Jonald Fyookball, along with Andrew Clifford propose the term "cash" be used to describe 1 millionth of a BCH (1 micro BCH) or 100 satoshi. This unit would be informally expressed with "XCH". They see this as being an improvement since it would distinguish BCH units from similar units used for BTC called "bits," a word undesirably reminiscent of a naughty word in French. “Cash" is a word representing a physical token of currency that is less relevant as time goes on. A three character ISO code representing such a small fraction of a BCH would also get around the problem of having units that are too small to be supported by financial computer programs. It would meet transnational currency standard ISO 4217's requirements also. Other benefits would include reducing errors by users and offering them simplified price comparisons.
BUIP088:
This concept is for a mechanism to enable merchants to rapidly know whether a double spend scenario is likely at play when they receive BCH from another user. It takes approximately 10 minutes for transactions to be recorded in a block. The act of being recorded in a block makes double spending impossible but the aforementioned span of time is problematic for merchants because it requires them to rely on their faith in the customer when exchanging a service for BCH.
User torusJKL proposes implementation of a mechanism to detect double spends more rapidly. Ideally, this will improve the security of 0-conf transaction, which might spur on adoption of BCH. The idea is that a node in the network that encounters conflicting transactions will release a proof that will be confirmed and propagated by other nodes, with no requirement that its mempool contain either transaction.
The goal is for the double spend proof to be ready to deploy when the BCH protocol is updated in November of this year.
Graphene:
Programming progress for Graphene blocks has advanced to the point where the upgrade operates and the pipeline for the upgrade runs from the “request”step all the way to the “reconstruction” step. Ongoing questions surround the ordering of transactions and Graphene/xthin code sharing. The author of the Coin Dance entry for this project, Bissias', current objective is to review Graphene's workflow. He acknowledges that optimization is incomplete as well.
Links:
Comments
Post a Comment