Transactions in Stamp: Part 1 - Privacy
Stamp (EDIT: getstamp.io it seems that the owner of read.cash has banned my domain.) is an upcoming wallet that is currently functioning on Bitcoin Cash testnet. It is an experimental project that will change the way people communicate by attaching a spendable value directly to messages - or messages to Bitcoin Cash transactions depending on your perspective. It uses a suite of protocols called CashWeb ( getstamp.io/whitepaper.pdf ).
When Stamp sends a Bitcoin Cash transaction, to another CashWeb wallet, it also attaches metadata that is relayed directly to the recipient. This allows ***your wallet*** to instruct your ***friend's wallet*** on how to spend that transaction.
Currently, the recipient of a transaction must ***first*** send you an address via email, or telegram, or some other messaging service. This puts all the terms of the contract in the recipients hands. It also means that the sender cannot generate a contract and give it to you like cash. Any metadata associated with the transaction must also be sent off-chain manually -- this could be, for example, an invoice, a receipt, or contract details.
There are two things that separate cash and digital (non-crypto) payments right now: the ability to push, rather than pull money; and doing that without a fee paid to a specific organization.
Someone cannot give you money ***without*** your consent, and the payment system's consent (and without your attention). Smart contracts cannot make unsolicited payments to Bitcoin Cash users right now because this control is in the hands of recipients.
By having an encrypted off-chain metadata also attached to every transaction, there is a mechanism to provide ***seamless integrations for standard contract types***; and without any possible third party interference. (e.g. maybe you want to make a friendly binary contract with a friend over the price of BCH in a year from now.)
The first contract that has been written is one that sends a recipient a bundle of multiple transactions. This bundle includes instructions on how to generate spend keys for all of the outputs. It prevents any Stamp transaction from being associated with a public address, or a third party knowing how much money is being sent.
This also means that you can send a total amount to your intended recipient across multiple transactions. Because of this, a wallet never needs to re-combine any outputs - a recipient's wallet can understand that multiple Bitcoin transactions are being used as part of one transaction.
Because re-combining outputs leaks information to chainalysis programs and reveals associations which previously could not be inferred. Stamp, by obviating the need to recombine outputs, makes chainalysis lose a significant source of data. This means chainalysis becomes significantly less reliable for identifying co-party to all transactions.
**This greatly improves Bitcoin Cash privacy and Stamp sends all transactions in this way.**
Additionally, when sending multiple transactions as a group, most of these transactions will not require a change output. Imagine you want to send a friend 100000000 sats. But you have UTXOS of 43214230 sats, 34124312 sats, and 43224312 sats. Your wallet will send three transactions, one sending 43214015 sats, 43224097 sats, and a final one sending 13561888 sats to the recipient and 20562424 in change.
In the above example, 2 out of 3 transactions had no change. **That is to say, the majority transactions will have one input, and one output**.
Currently, Chainalysis is able to be ***almost entirely sure*** that any transaction that has one input, and one output, is ***still*** owned by the person who generated the transaction. They can do this because it is unlikely that an individual UTXO (Coin) that is exactly the right size for the amount they wish to send someone else - not so under the regime of Stamp-compatible wallets.
Under a future where people are using Stamp-compatible wallets, the majority of transactions will be 1x1 transactions. Which means that the ***majority of transactions*** transferring "ownership" of a UTXO will be 215 byte 1x1 transactions. Re-keying a UTXO becomes ***very likely a change of ownership.*** Previously, to generate uncertainty about UTXO ownership, you needed to generate at least a 1x2 transaction, and even then there was a 50% chance that an individual UTXO was owned by the sender. 1x1-transactions were almost always held by the same party.
This is extremely important, because almost all court cases hinge upon proving that a defendant made a specific financial transaction. Ultimately, Chainalysis data must be valid in a court of law. Their data cannot be accepted when the probabilities of association are too low.
***If, in the future, there is no deductive basis for determining transaction ownership, Chainalysis data becomes worthless.***
With Stamp-compatible wallets the majority, on the Bitcoin Cash network, it becomes possible to add uncertainty to the blockchain simply by moving coins around ***without requiring 3rd party liquidity***. Moving UTXOs a few times generates anonymity similar to things like CoinJoin and CashShuffle, but ***without liquidity constraints.***
This is only one of the benefits of allowing Bitcoin Cash transactions to have attached off-chain metadata. There are many others which I will discuss in coming articles.
Red vs Blue: The second fork
Anywhere there is leadership, there will be opposition. There will be decisions that someone does not like. A good leader manages these individuals by making them feel heard, and understanding why one decision was made over another. Amaury doesn't do that. He listens, he hears, but then he makes decisions without first talking to his biggest detractors.
*This is incredibly unfortunate, because it means every 6 months someone will be upset and start a battle over the decision.*
It started right after the 1 August fork. A handful of individuals including Haipo, Jihan, Amaury, freetrader, sickpig, calin, jonald (and many others I'm sure I've forgotten) did the hard work to make Bitcoin Cash happen. There were a lot of other people involved, as Toomim said in a recent post, however they were largely standing around the campfire still trying to come to consensus.
The individuals I mentioned above, found consensus within themselves. They decided to take risks and make actual steps to creating a big block fork. *The individuals who did the fork understood that they would be getting a new ticker.* They took preparations to buy domains, create websites, get logos made, listed on an exchange, find some funding for development, and lots of other tasks that were required.
Amaury was seen as the lead of this effort; although maybe his influence should have been limited - it was not. However, the people who funded this effort were not looking for control. They did not want to influence developers and largely gave no-strings-attached funding. My hats off to them for their stance of letting decisions be made by someone else.
Now, there were many other individuals who were talking about big blocks, but they did not want Bitcoin Cash as it were.. *These individuals were largely hoping to keep the BTC ticker.* Many of them only joined the Bitcoin Cash effort after the fact. They did nothing to make it a reality; or had failed to manifest their visions during the previous two attempts to depose the Bitcoin Core development team.
*Bitcoin Cash was a peaceful hardfork in an effort to try big blocks and see if it could succeed.*
Shortly after these late-comers joined the effort, the first clash of leadership came. Logos had already been chosen, websites had already been set up, but some core proponents, who wanted to differentiate branding, wanted the color changed. There was also a relatively large group of individuals who did support Bitcoin Cash who also wanted the color changed because they wanted brand differentiation.
Brand differentiation was the ***exact opposite*** of what the original Bitcoin Cash team wanted. The purpose was to be different, but make it clear that it was continuing the P2P cash vision. It was also supposed to have a logo with coloring that ***stood out***.
**A retheme was** **proposed** **and was rejected due to color; a compromise was proposed of sticking to the existing brand color.** Now, the website that was already set up. The majority of people involved in BitcoinCash.org had already come to consensus around the logo. The few individuals making this initial demand were by far in the minority, but did not want to compromise with those people who had already done the work to setup the website. https://github.com/bitcoincashorg/website/pull/28 http://archive.is/wip/kvLBi
The Bitcoin Cash Fund/Association was shortly thereafter set up because of the disagreements over the marketing material that had been created. Singularity87, the individual who set this up received some funding from the various donors to help market Bitcoin Cash. What he didn't tell his donors was that he was going to start a campaign to rebrand everything. https://github.com/BitcoinUnlimited/BitcoinUnlimited/pull/868 http://archive.is/wip/4y7mx
Now, you may or may not agree with his logic. I think it is somewhat compelling, but the other side of the argument was that it was different enough; and still eye catching. A/B testing had been done on logos of various colors and orange is far more easy for people to see. My suggestion at the time was to allow the color to be set, and to put up images of every color of the rainbow. ***However,*** ***Green does not elicit color arousal - it is a background color.***
https://www.nickkolenda.com/color-psychology/
*Amaury didn't go with my suggestion*. However, I didn't stop helping him, because Bitcoin Cash is more important to me than petty squabbles over the colors of logos. If we build a good product, Bitcoin Cash will be successful regardless of logos - and better logos will come and go in the future.
However, instead of contributing to the existing effort, and allowing the branding to stay orange until the BCF was able to persuade the other participants in BitcoinCash.org. They BCF started a **new website** which they started a paid advertising campaign for in an effort to make it the primary digital property for information about Bitcoin Cash. https://bitcoincashers.org/
*The disagreement was not primarily over color, but over who gets to make decisions about the color.*
Now, imagine someone goes up to the owner of a house and says "Hey you need to repaint your home!" The owner responds with "No thank you, I like the color it is." Then they go try to lobby the neighborhood to forcibly repaint the house because they *refused* your demands. BitcoinCash.org is ***property***.
However, **refusing demands** to rebrand *your* website is not an evil position. And demands from others that BitcoinCash.org's content should be put to some kind of vote by people *not working on it* is somewhat fascinating. Many people on social media bought in to these arguments.
I bring this history up, because it was the first social fork in Bitcoin Cash. Perusing these comments on github will reveal that many of the same parties have taken opposing positions on every change that has been proposed - or they are entirely gone due to the toxicity of the conflict. There was a significant amount of friendly fire taken by ABC due to the branding, although this specific issue has largely been abandoned.
The social campaign that took place vilified ABC; and you can still see the utterly contemptible posts on r/btc. Many of them make assertions about the **motives** behind ABCs decisions. This is a common rhetorical technique called **poisoning the well**. If the main drivers were simple technical disagreements; there would be no need to employ these kinds of rhetorical techniques. https://en.wikipedia.org/wiki/Poisoning_the_well
No, the main drivers in these internal battles are not about any particular decision, but about who gets to make those decisions. Malice, and nefarious intent, are attributed to Amaury as a justification for not helping ABC. ***And you can see this by the “party lines” that have formed.***
However, the vast majority of any conflict are ***never*** part of an ideological party. They are otherwise neutral. However, it is unfortunate that a fair number of people have bought into the propagandizing of Bitcoin Cash development and marketing. Amaury has NIH syndrome, he doesn’t listen, he’s mean, etc. I don’t believe any of this is true - I think he’s just a shitty diplomat. He is a software engineer, not a politician nor a manager. He should leave these things for other people to do.
Amaury "became" an evil dictator; even though he was only setting requirements about his own digital property. This continues today. Amaury is only making changes to ABC; he is not demanding that BU, BCHN, Knuth, or any of these other nodes implement the Grasberg DAA.
People say Amaury isn't compromising and therefore is "bad" or "wrong." However, Amaury did implement a DAA due to demands of the community when he believed it was not worth fixing at this moment in time. He also used the algorithm that was shown to work well. He did add some of his own spice to the algorithm - but this is the definition of compromise. The people upset about Grasberg are actually the ones not seeing the steps made towards their position. It is an all-or-nothing demand for ASERT *without* emission control - emission control that a fairly large group of people either want, or do not care strongly about.
People are claiming Bitcoin ABC wants a fork. This should be obvious. Bitcoin ABC forks every six months so they can make changes towards the goal of enabling world money and digital P2P cash. Nobody is being forced to follow along.
It is the obligation of the disgruntled mob, the same mob trying to convince us all to abandon ABC, to convince me and everyone else why we should continually create chaos. It is not up to Amaury to do this.
Announcing the Bitcoin Cash mêmé competition of 2020
Due to the threats of censorship on this platform. The meme contest is being continued on reddit. Here are the new rules: https://www.reddit.com/r/commucurrency/comments/i042m2/the_bitcoin_cash_m%C3%AAm%C3%A9_competition_of_2020_shall/
There is an additional 2BCH being added to the pool.
Nothing about this meme contest was to encourage personal attacks. The fact is that personal attacks are RAMPANT in the Bitcoin Cash "community" and this contest is meant to mock those these attacks and indirectly those who make them. They mascarade as attacks against the supposed motives of certain people, but in reality attacking a person's motives is identical to attacking them *as a person.* This is unacceptable, and I will continue mocking everyone that continues this sort of attack.
In the spirit of fun, I am announcing the BCH mêmé competition. I will be giving out 2 BCH in tips to the best meme's as independent read.cash posts linked in the comments of this post. 0.65BCH of prizes have already been given out between several anonymous individuals.
I am looking for mêmés that characterize and summarize the prevailing narratives within the Bitcoin Cash "community."
Some examples:
Amaury the Socialist Dictator
Marc De Mesel is Calvin Ayre Lite
Bitcoin ABC is just like core
Gasberg is a plot to ram through Avalanche
BCHN our the saviors of Bitcoin Cash from ABC
Bitcoin Cash development is decentralized, but we can't do accomplish anything because Amaury makes all the decisions
Bitcoin ABC is controlled opposition meant to destroy the big block movement!
Anything else you can come up with!
Thank you in advance for your participation. May the best mêmés win.
EDIT: Please make a top level post so the tips promote the content, and then post a link here in the comments.
Submissions:
Considering Liquid Democracy
Over the last three years, there have been many calls to change the decision making process in Bitcoin Cash. It is an inconvenient secret that the current process is "Amaury makes the final decision on all protocol matters." Often, people are not happy with his decisions.
His behavior has indeed been questionable with regards to HOW he goes about finalizing these decisions; although I trust the actual *technical* portions of the decisions he has made. Yet, there are demands for change, and if there is a better way to make decisions it certainly deserves consideration and effective effort to put the mechanism in place. As Thomas Sowell has said, "compared to what?" Demanding a change in process, without a concrete plan is a waste of everyone's time and energy.
Yesterday, I challenged the Bitcoin Cash Cryptocurrency Network participants to produce proposals for a better governance mechanism. Jonathan Toomim took me up on that challenge on reddit to argue for Liquid Democracy. I'm responding through read.cash to elevate the discussion from being buried in a reddit comment thread, to a top level discussion because of how much attention I believe the topic warrants. I also invite any others who are dissatisfied, with the current process, to discuss any other proposals in the same way. https://read.cash/@micropresident/amaury-is-irrelevant-until-he-isnt-cc992fe8 https://www.reddit.com/r/btc/comments/hwrapm/amaury_is_irrelevant_until_he_isnt/fz2nae5/
**Toomim's arguments for Liquid Democracy are reproduce here for clarity. Italicized sentences are mine from a previous comment.**
*Liquid democracy is what happens between coins already.*
Very good point, I hadn't quite realized that myself.
Ultimately, any governance system within a coin should be based on the same principles that govern success/failure for the resulting coins in the event of a chainsplit. Otherwise, if one party has a relative disadvantage in the within-coin governance system compared to the post-chainsplit inter-coin competition, then they'd have an incentive to split just to get their voice heard.
This is similar to governance among nations being determined in a similar fashion to the likely outcomes of a hypothetical war. The UN Security Council's five permanent members aren't chosen arbitrarily: they're all military superpowers with substantial nuclear arsenals. They're given a disproportionate voice because they would have a disproportionate effect on any armed conflict that occurred in defiance of their voice.
*And why is this process better than the emergent one that is already taking place?*
Quick non-exhaustive list:
Better granularity. It allows for the same process that ultimately dictates the fate of entire projects to also be applied in an efficient and low-friction manner to decisions within a project.
Clarity of decisions. It's a quantitative method. It comes up with quantitative results. It's not ambiguous, not subject to interpretation. It's formally definable, and ultimately depends on cryptographic signatures on the blockchain.
Less inertia. If someone in a position of authority unilaterally makes an epically bad decision, the community can make a rapid and specific response to overrule him on that specific decision.
Conflict resolution and closure. Often, people who disagree on issue A will agree on many other issues. They will have more in common than they disagree on. Having the ability to make a clear and decisive group decision on issue A allows people to mark the issue as settled and move on. Often, this allows people to focus more on the things they can agree upon, rather than the closed issues they disagreed upon.
**My response is as follows:**
Ultimately, any governance system within a coin should be based on the same principles that govern success/failure for the resulting coins in the event of a chainsplit.
I don't agree with that. There are existential differences between how markets work and how software can be developed. In one situation a natural market can arise, in the other there is no mechanism to have a marketplace for "development" -- that is outside of paying effective labor (which is what is happening currently.)
Otherwise, if one party has a relative disadvantage in the within-coin governance system compared to the post-chainsplit inter-coin competition, then they'd have an incentive to split just to get their voice heard.
This is what I am trying to make clear. However, there is also a negative incentive of having to do a lot of work to make a fork, or new coin happen. Creating a fork or new coin is not trivial. It also causes a significant loss of network effect for both coins.
Right now it is clear that those people who want a change in leadership do not have enough incentive to actually carry out making that happen.
Better granularity. It allows for the same process that ultimately dictates the fate of entire projects to also be applied in an efficient and low-friction manner to decisions within a project.
Is this really true? There are a number of problems with implementing this process:
In order to prevent sybils, coins have to be locked up over a period of the vote. This favors individuals who do need to move coins regularly.
Making sure a reasonable quorum of users are paying attention is nearly impossible.
Few users have the technical knowledge required to participate in such staking without new software being written - which is a significant cost in itself.
It caries no executive power, or funding, for proposals, unless the staking is into a covenant that allocations an apportionment to the development.
Roger Ver already tried something to this effect with vote.bitcoin.com, and other sites, have already tried this. It had no impact on the outcome of decisions because it caried no executive power. http://archive.is/blkv7
And finally, and most importantly, Liquid democracy does not obviate the problems which the current emergent process solves. Without doing so, there will never be an effective mechanism to move to a change in the mechanism ofdecision making.
I tried to discuss these reasons in a previous article. However, it seems as if it has been largely ignored by those who do wish to change power dynamics within Bitcoin Cash. https://read.cash/@micropresident/the-cryptocurrency-of-theseus-what-is-our-identity-and-why-are-we-fighting-16ff0d1b
Amaury is irrelevant, until he isn't
Today, Amaury released an article on his proposal for the next DAA. It seemingly came with a declaration that this DAA will be what ABC is implementing for the November protocol upgrade. https://coinspice.io/news/bitcoin-abc-grasberg-daa/
A lot of people in the Bitcoin Cash Cryptocurrency Network are angry and upset that Amaury has ***made a decision*** about what he is going to include in the ABC Bitcoin Cash Node software. It's worth examining why people are upset about his ***behavior***.
All feeling are worth examining, because at their core is always a golden nugget of truth. And, understanding the truth allows for making effective decisions about behavior. Feelings alone motivate us to action, but they do not motivate to right action without understanding.
At its core, Anger is generally a secondary emotion. It covers up for a primary emotion that reveals our vulnerability. I would argue, that most of the anger right now is due to individuals feeling afraid, attacked, offended, disrespected, forced, trapped, and pressured - feeling powerless. https://creducation.net/resources/anger_management/anger__a_secondary_emotion.html
**And to this, the question is raised: Why do people feel slighted about Amaury's decisions regarding what he does or does not do?**
There are many people who claim that Amaury is not relevant to the development of Bitcoin Cash, and then at the same time they are upset and angry whenever he makes a decision they do not agree with. So what is it? Do the decisions of Amaury coercively impact anyone?
I have previously argued that Amaury was both *in charge*, and *not in charge*, of Bitcoin Cash. People choose to believe whichever one they want. However, the group of people who continue to assert that he is not in charge, are the very same people who are perpetually upset when he makes a decision.
Their anger implies that they do believe he is in charge. They really do believe that they cannot function without his cooperation. They believe that Amaury should, or should not do, particular things.
Now, I don't think that Amaury handles his responsibilities as lead maintainer well at all. I think he's absolutely horrible at them. Yet, he is the lead maintainer of Bitcoin ABC.
But, ultimately anger is not productive, and continuing to be angry while denying the core of the cause of the anger is even less so.
Those people who are angry with Amaury have several paths they can take:
Continue to believe they do not need to interact with Amaury in the way he wants, and never get any productive work done.
Accept that Amaury is in charge and interact with him in a way that is pragmatic.
Accept that Amaury is in charge of protocol development, and take concrete steps to make that no longer true.
The third option is likely what is currently happening. However, I wonder what he will be replaced with? Every vague proposal sounds like he will be replaced with, something akin to, a **dictatorship of the proletariat****.** https://en.wikipedia.org/wiki/Dictatorship_of_the_proletariat
We all know how that ends.
If there is actually a better proposal for how things should be done, I'm all ears. I don't know of one; and I know of no historical examples of any other functional decision making systems.
Review of the ASERT DAA proposal
Recently, **Jonathan Toomim has written a detailed proposal** for addressing a significant issue on Bitcoin Cash. That issue has been that "benevolent" miners are losing money relative to profit seeking miners. This is undesirable because Bitcoin is ***supposed*** to run on profit motives. If miners who drive the chain forward are not profiting properly, the system is effectively broken. https://read.cash/@jtoomim/bch-upgrade-proposal-use-asert-as-the-new-daa-1d875696
This problem is also why the current Difficulty Adjustment Algorithm (DAA; the system responsible for ensuring that coin issuance is stable and fair) was put in place relative to the previous Emergency Difficulty Adjustments. Much of the analysis that Toomim presents was done at that time. Toomim’s proposal is that we switch to an algorithm called **ASERT**. http://toom.im/files/da-asert.pdf
The proposal’s problem statement correctly points out that the DAA is responsible for this. It also points out that no Difficulty Adjustment Algorithm as currently proposed can entirely fix this problem. This is fundamentally due to a lack of instantaneous price information. This information is only able to be inferred by the behavior of miners, and based on noisy data. The calculation of the DAA must only rely on internal blockchain information, or consensus cannot be reached, and there would also be the problem of trusted oracles.
Fundamentally, the DAA has two pieces of information about what the current hashrate is: Block times, and Chainwork. Both of these are noisy data sources:
Block time has two sources of error: Miners, for whatever reason, may not update the time of their blocks to be accurate to when they were mined -- this is shown in practice. There is also a potential to manipulate these timestamps in order to affect difficulty and game the algorithm.
Chainwork for a particular block is the sum of the estimated number of hashes required to have produced said block if the entire chain was recreated from scratch. It may be thought of as the blockchain's **enthalpy**. However, because Chainwork is based on these block hashes, they are necessarily probabilistic. As such, each block's chainwork has some divergence from the actual number of hashes required to produce the block. https://en.wikipedia.org/wiki/Enthalpy
As such, the noise in the data introduces a fundamental minimum error. The error in these parameters are independent of any choice in DAA. These errors limit the ability of a DAA to respond to hash that is changing over a period of time that is bounded by a minimum of ten minutes, and increases the more switch miners there are.
However, I believe the simulation that is being used is also fundamentally flawed. As one of the original authors of the simulation that Jonathan used, I believe there are several important flaws that impact the validity of its output.
First, the simulation makes **fundamental assumptions** about the behavior of greedy miners. These assumptions are likely not valid. We are currently observing strategic greedy miners that exhibit **second order thinking**. They can, and are currently, strategically applying their hashrate, and manipulating timestamps, in order to create future changes in the difficulty adjustments. https://github.com/jtoomim/difficulty/blob/comparator/mining.py#L74-L89 https://medium.com/@noahmp/second-order-thinking-3fc2a224b131
Additionally, the lead author of the simulation made **relative profitability of mining Bitcoin Cash an independent random variable**. This assumption makes the calculation of revenue ratio based on current hashrate seem independent of miner behavior. It is not. https://github.com/jtoomim/difficulty/blob/comparator/mining.py#L641-L644
Finally, there is no **error introduced into the timestamps**. There is significant variability in the actual timestamps, and time it takes to produce a block. https://github.com/jtoomim/difficulty/blob/comparator/mining.py#L626-L644
In reality, the greedy miners have a significant impact on the future exchange rate based on their behavior. Because of limitations of 10 minute block times, and a larger response to variations in hashrate, switch mining actually becomes more of a problem, not less.
Greedy miners, with significant hashrate available, have a large incentive to switch large pools to BCH for brief periods of time, and mine a block and leave. The result will be that the next block will have a significantly increased difficulty, and the block after it having a much reduced difficulty. As a result, selfish mining becomes a natural response to protect profits. If you are a miner taking the much reduced profitability of the next block, it makes rational sense to withhold it and mine an easy block on top.
These scenarios are explicitly not discussed in Jonathan’s proposal, but deferred to the following issues: **EMA for BCH (part 2)** and **Hash Attack Examples** github issue threads. However, the fundamental problem here is that the DAA cannot adjust until a block is found. If a block is found quickly, the difficulty will rise substantially, and it cannot be reduced until a new block is found - even if that difficulty increase was due to hash which has left the chain, or by timestamp manipulation. https://github.com/zawy12/difficulty-algorithms/issues/62 https://github.com/zawy12/difficulty-algorithms/issues/18
Interestingly, from the analysis one proposal from ABC (**cw-16-sha**) for fixing the issue of resonances. It does so by modifying the current DAA (cw-144) to use a randomized window based on the current block hash. This also prevents any resonances from forming within the difficulty targets. From testing in 2017, it also outperforms other algorithms on all attacks at the expense of creating larger block solvetime variability. **However**, this still does not solve problems associated with switch miners. ABC has not chosen to implement this due to a variety of other factors not considered in Jonathan’s proposal. https://github.com/jtoomim/difficulty/blob/comparator/mining.py#L235-L246
One of those factors is that changing the DAA is a significant undertaking, because it does not just require updating the node software, but it also requires updating every SPV wallet in the ecosystem. This is no longer simply a problem for exchanges, and miners, but for every user. It is nearly impossible to ensure that every user gets a notification that they need to update their wallets - and will necessarily involve interrupted service. In 2017, the user base was smaller, and more engaged; this made such a change easier. Also, the magnitude of the profitability issues for benevolent miners were significantly larger than they are now.
As such, changing the DAA should be considered carefully before a change is made. I applaud Jonathan’s effort and thorough analysis of the DAA’s choice. However, I would like to see:
Simulations performed under constant price ratio, so that miner behavior can be better seen.
Add select timestamps based on the probability distribution, so that short term profitability variations show up more often due to random chance.
Faster switching of rational miners. Pools can change chains very quickly, the cost to do so is miniscule. Very small price fluctuations due to solvetimes can dramatically impact profitability.
Better tests for various rational miner behavior.
Finally, and ***most importantly*** is there a way to make better data available to the difficulty adjustment algorithm by fundamentally changing the way we think about the problem? The proposal does not consider any alternatives which would fix issues with difficulty adjustment algorithms entirely.
Some of these other options are:
**Bobtail** https://arxiv.org/pdf/1709.08750.pdf
**Bounded mining** https://arxiv.org/abs/1603.00814
**Real-time targeting** (RTT). Where wall clock time impacts what the difficulty accepted will be, and can be soft-forked into the protocol. https://arxiv.org/pdf/2006.03044.pdf
**Avalanche consensus** to determine which block is chosen every 10 minutes. https://ipfs.io/ipfs/QmUy4jh5mGNZvLkjies1RWM4YuvJh5o2FYopNPVYwrRVGV
All of these options have tradeoffs, but they all allow block times to be significantly less variable, and prevent selfish mining, and greedy mining, by ensuring that real-time price data is trustlessly provided to a DAA in a way it can react to quickly.
An iceberg is coming and nobody is at the helm
I, like many of you, was born human. Unfortunately, I was born flawed and full of character defects. I was born filled with lust, gluttony, greed, sloth, wrath, envy, and most of all ***pride*****.** Despite my flaws, I wish to see a true Money Libre realized into the world. This is my end goal, and I wish to work with anyone who shares that goal.
Money Libre would free us all from tyranny. It would free us from the endless wars we have heard about for our entire lives. Money Libre would put everyone on equal footing. Footing from which they can succeed or fail by their own.
***Money Libre is the most important goal anyone could assist in realizing.*** https://www.youtube.com/watch?v=vEU13R5jt1w
Recently, I have published two articles which pertain to ***our*** goal of Money Libre. The first about the current political situation in Bitoin Cash - arguing that Bitcoin Cash's identity is contingent upon the Bitcoin ABC project. The second being about how decisions are made, and arguing that nobody is in charge of Bitcoin Cash. https://read.cash/@micropresident/the-cryptocurrency-of-theseus-what-is-our-identity-and-why-are-we-fighting-16ff0d1b https://read.cash/@micropresident/a-story-of-how-amaurys-broken-difficulty-adjustment-algorithm-came-to-be-b0b7c142
The first argument, summarized below, is that Bitcoin Cash is Amaury's project by *identity:*
Bitcoin Cash is defined by what consumers believe to be Bitcoin Cash. Consumers believe Bitcoin Cash to be a product that is compatible with the Bitcoin ABC software. Therefore, exchanges selling coins which are not compatible with Bitcoin ABC software would be potentially guilty of fraud. As a result, Bitcoin ABC, and thus Amaury Séchet, define what features Bitcoin Cash has, or does not have.
No amount of rhetoric within r/btc, or twitter, is going to change the expectations quorum of exchanges and users to change this fact. Those who are traveling down this path are wasting their time that could be spent on more productive endeavors.
Now, it is also argued that Bitcoin Cash is ***not*** Amaury's project. Rightfully so, it is **everyone's** project. Thus, the second perspective is this: https://read.cash/@noise/bitcoin-cash-is-nobodys-project-a-response-to-micropresident-87ec6789
Bitcoin ABC is not Bitcoin Cash. However, Bitcoin ABC is Amaury's project and he is free to include or exclude any functionality he wishes within his Bitcoin Cash client. Users of this software are free to continue running it or not. Thus, Amaury does not have any control over Bitcoin Cash and should not be subject to criticism over the changes he chooses to make in his client.
These arguments are seemingly in disagreement. However, both statements I believe to be true, and form a complete perspective. "Imaginary Username", a thought leader in the Bitcoin Cash cryptocurrency investor network, correctly noticed that my publicly stated viewpoints *seem* **inconsistent***.* https://www.reddit.com/r/btc/comments/hkbf5r/a_story_of_how_amaury_broken_difficulty/fwrz527/
Now, everyone ***should*** be able to agree that it is true that either Amaury Séchet is the leader, or he is not the leader.
It is *precisely* because **everyone** is in charge that Amaury Séchet is unable to force his will upon *them*. Is it because **everyone** is in charge that **the opposition** has been *unable* to achieve their goals? The opposition continually levels complaints regarding what Amaury does, or does not include, in Bitcoin ABC. However, Bitcoin ABC is not Bitcoin Cash, it is just Bitcoin Cash because we've all implicitly agreed to that.
This is why some people feel powerless - because social consensus does not support the changes they wish to make. Twitter and r/BTC are not representative of the true economic power and consumer sentiment behind Bitcoin Cash. People who are not getting their way are truly just frustrated that social consensus does not support them. They must take out their frustration on people who are freely making changes to software that nobody is forced to run.
Those individuals who continue to publicly complain in public about the hegemony of Amaury within Bitcoin Cash protocol development are actually directing their frustrations with ethereal social consensus onto the King of the Bitcoin Cash Protocol. He is the King precisely ***because*** Bitcoin Cash is a decentralized project. He is the leader, because we choose to follow him (and ***complaining*** about ***him*** is an act of following)
It should be clear, to anyone who knows me, that I do not desire for Amaury to be King. However, I believe that it is critical that reality be accepted for what it is, and make decisions from there.
If I were to refuse to believe my conclusions, about who is in charge of the protocol, I would continue to waste time trying to interact at the protocol development level. I would not be spending my time on more productive endeavors like Stamp and CashWeb. https://t.me/stampchat
After three years of working on Bitcoin Cash, the primary things that I can conclude are that:
Human beings are horribly flawed.
People don't want to take responsibility for their decisions.
Many libertarians do not want to accept reality when it conflicts with their ideology - just like communists and fascists.
Libertarians suck at collaborating.
We may never realize our goal because we're too busy fighting about who isn't in charge to realize that there are bigger problems at stake.
I wish the best to Shadow Of Harbringer, freetrader, Imaginary Username, and others. I wish the best for their effort to become the deciders on Bitcoin Cash protocol specifications. However, I do not believe they will be successful.
I will be choosing to spend my time developing useful front-end technology for users. The Bitcoin Cash protocol is not the rudder of the ship, it is the engine. Control of the engines, at best, allows you to slow or speed up the ship - to halt the project. It does not allow you to steer the ship. ***Being the interface to cryptocurrency for end-users does.***
An iceberg is coming, and nobody is at the helm.
A story of how Amaury's broken difficulty adjustment algorithm came to be
The topic of the current Bitcoin Cash Difficulty Adjustment Algorithm (DAA) is up again. It's both being discussed in terms of algorithm changes, but also in terms of the history of how we got the current DAA.
First, I want to say, moving forward with technical advancements is paramount. Anyone who is concerned about the DAA and has the skills to be working on it should be participating in writing requirements, specifications, simulations, and ultimately the C++ code to be included in Bitcoin ABC. The working group for these changes is here. https://t.me/joinchat/HCYr506_9oNIjmWgXh_kyA
Given that the history of this change has come up repeatedly, I think the Bitcoin Cash Cryptocurrency Investor Network should have all perspectives available to them. So, I am writing here for a collective record and to inform people who are not reading Slack messages.
And, when reading this account, keep in mind that it is now three years later from the events being discussed, and and there is still ***no solution that is agreed upon, has a specification, and a working C++ implementation.*** We don't even have an ***accepted list of requirements***.
At the time of the DAA, I was newly involved in the Bitcoin Cash project. I had some past history with Amaury, and was aware of his communication style from working with him on past open source projects. Part of the difficulties people have with him are due to English being a second language, the fact that he is French, and becoming impatient and frustrated ***with himself*** when he is ***he is struggling*** to convey his meaning in a way that can be understood. Attempting to bridge communication gaps was one of my considerations in choosing to get involved in Bitcoin-ABC. I had no prior experience working with any of the other developers involved in Bitcoin Cash protocol development to cause past history to taint current communication.
My perspective and experience in working with other Bitcoin Cash developers on the DAA is by no means fact. It is the truth insomuch as it is my experience, and my feelings - just as all the other statements about this history are also true feelings and experiences.
However, these feelings are **not fact** and it always takes two to tango. When I was still working on Bitcoin-ABC I saw an environment where mind reading dominated. Developers failing to practice egoless programming**, allowing** their feelings to be hurt. There was also a general lack of understanding around how criticism in code reviews come across to other humans. Good faith was generally never assumed. Nearly, every developer in this space, including myself, is guilty of one or more of these behaviors. https://en.wikipedia.org/wiki/It_takes_two_to_tango https://www.theemotionmachine.com/mind-reading-avoid-this-common-trap-to-improve-your-communication-skills/ https://blog.codinghorror.com/egoless-programming-you-are-not-your-job/ https://mtlynch.io/human-code-reviews-1/ https://meta.wikimedia.org/wiki/Assume_good_faith#On_Wikipedia
Now, regarding the DAA flaws. ABC was aware of the potential for resonances. I even came up with my own algorithm that was easy to implement, but it ultimately wasn't implemented. Amaury was even very amiable to it. However, it was after the release was already in flight -- it had taken too long to come up with an adjustment.
The reason the release needed to be done at the time it was, was to be ready for the S2X hardfork of Bitcoin Core. There would have been three major contenders for SHA256 hash, with major price changes between all of them. Miners would have been switching chains continuously, and result in even worse problems for the existing EDA on Bitcoin Cash. https://lists.linuxfoundation.org/pipermail/bitcoin-ml/2017-November/000422.html
However, other developers continue to say this:
Freetrader claims that Amaury could have chosen Tom Harding's algorithm and did not for some unspecified reason. From context, it is unclear if Freetrader thinks that Tom Harding's solution should have been implemented. However, other developers, within the context of three years, have continued to assert that Harding's DAA was not implemented due to Amaury's insistence on only using his own solutions. I don't believe that was his motivation. I was involved in the selection decision and signed off the choice. https://reviews.bitcoinabc.org/D601
***And the fact that this is still being talked about, rather than acted upon by the people who are talking about it, is indicative of a real problem.***
Amaury made the rational choice between alternatives. Getting a reasonable DAA out the door before things became even worse should have been a priority for everyone. Perfect is the enemy of good, and complicated solutions have more surface area for fatal errors. The DAA as it stands is extremely simple, but there is a lot of room for improvement.
For those not aware of the history, the Emergency Difficult Adjustment algorithm was performing terribly. The EDA was written by Amaury with input from other developers who did not want the original Bitcoin DAA changed at all; but it was not his preferred solution. *Had Amaury listened to the consensus of developers at that time, the August 1st 2017 Bitcoin Cash hardfork event would have resulted in a blockchain that was dead-on-arrival.* https://medium.com/@Mengerian/bringing-stability-to-bitcoin-cash-difficulty-adjustments-eae8def0efa4
The #1 reason we went for the EDA mechanism is that many actors were opposed to any change to the DAA at all, and EDA was the bare minimum possible change that could ensure the chain's survival in face of a hashrate drop at the fork point. Not because it is the best solution. Not because it even is a good solution, because it is what people were ready to accept. It is clear by now that more is required, and it would be a shame to not leverage all the great work that people working on alts have done. Some will call this copyright infringement, I on my side, call this science.
Amaury Sechet via Bitcoin-ML https://lists.linuxfoundation.org/pipermail/bitcoin-ml/2017-October/000326.html
It became apparent that the EDA would be a problem in August. There are an abundance of posts on the bitcoin-ml from Amaury about it, as well as others. Indeed, there **was** civil conversation there, *initially*, but no actual consensus on anything. Freetrader claims there was almost agreement on this issue. I don't know how he has any better mechanism for determining this than myself, or anyone else; which is to say no mechanism at all. https://lists.linuxfoundation.org/pipermail/bitcoin-ml/2017-August/000136.html
That being said, I would like to be proactive rather than reactive, so I worked on the problem to make sure we can deploy something if/when we think it is needed.
Most implementations are basing their mechanism on the block time, however, this data is extremely chaotic and can also be faked to some extent by miners. In the ideal world we want to estimate hashrate over several blocks and then use this estimation to recompute a new target. Because the input data is very noisy, we need to either do that over long timespan, but then we adapt poorly to violent hashrate swings, or quickly, in which case the difficulty output ends up being chaotic and may not be stable. Ideally, we'd come up with a solution that rely on individual block time as little as possible as this is the least stable data we have.
Amaury Séchet via Bitcoin-ML, Aug 25th 2017 https://lists.linuxfoundation.org/pipermail/bitcoin-ml/2017-August/000136.html
However, these discussions devolved quickly when, in mid October 2017, Amaury decided to start implementing a DAA himself. This first iteration was ultimately abandoned due to feedback from Neil Booth, and others. Neil Booth came into an ABC development chat - seemingly upset - to point out that the newly proposed DAA would be incredibly difficult for SPV wallets to implement. I explained to him that nobody was trying to break SPV wallets, and that we would do whatever is necessary to ensure that didn't happen. The situation was temporarily de-escalated.
Then, Tom Harding and Neil Booth both started working on simulations of various other algorithms. Amaury was also doing the same. Their repository is here, and was an effort I actively participated in. However, my feedback was repeatedly dismissed by both Tom and Neil. Tom Harding believed I was working for nChain and could not be trusted -- rather than looking at the content of what I was telling him. https://github.com/kyuupichan/difficulty
***If we almost had agreement then, why are debates about difficulty adjustment algorithms still ongoing now - 3 years later? I'm glad we haven't been stuck with the EDA for 3 years.***
This kind communication only got worse from there. Both algorithms that were proposed had major flaws by my estimation. Neil Booth's algorithm was asymmetrical and thus unsuitable to the problem space. He persisted until he decided Tom Harding's algorithm was better some time later. Tom Harding was continually asked to show that his algorithm responded reasonably to selfish mining. Freetrader admits that Tom's response was: "I want Amaury to prove he doesn't beat his wife" -- these kind of remarks derailed all attempts at any productive collaboration. ABC developers did indeed review all these proposals, Antony Zegers even provided a detailed write up about Tom Harding's proposal. https://medium.com/@Mengerian/dgenr8s-difficulty-adjustment-algorithm-explained-e77aa47eb281
Meanwhile, Peter Rizun was arguing publicly against changing the DAA at all. Claiming that leaving it in place would "cause a death spiral that would kill off BTC" (paraphrased). Assuming it were possible, that would have been absolutely disastrous for the entire cryptocurrency space. Tom Zander (the maintainer of Bitcoin Classic) was still advocating for a reverse-EDA, which would have not helped the situation involving S2x at all. https://lists.linuxfoundation.org/pipermail/bitcoin-ml/2017-October/000326.html
After the new DAA was incorporated into ABC, Neil and Tom went into various public chats, private chats, and direct messages, to claim Amaury was being rude, strong-headed, ignoring feedback, and ultimately implemented ***his*** solution because of his ego. Many people, without any other knowledge, and trusting these two developers, took what they said at face value.
However, this was **not** my experience when interacting with these three individuals in trying to develop a new DAA. These public allegations have become a running theme, over the last three years, with nobody seemingly remembering that it takes two people to have an argument. The ramifications on the progress of Bitcoin Cash have been substantial.
A well known friend of mine, and software engineer, told me privately something to the effect of, "Can't Amaury just merge someone else's solution so people will be stop complaining?" Network protocols are not about people's feelings, and merging poor solutions to placate people is not a good precedent to set. Since that time, despite the claims about Amaury, he has merged a lot of code from other people.
**Given Freetrader's renewed interest in development processes, and evidence-based development. There's another aspect to consider when he says that** ***we were near agreement at the time of the DAA being implemented.***
How does he know this? How does he come to this conclusion? Who was involved in this agreement? Are we simply exchanging one set of people as decision makers for another? Do we implement solutions by voting? Who gets to vote? Who gets to propose things for a vote? What is the **actual** consensus mechanism that Freetrader wants to see?
There is some history that might shed light on to Freetrader's mechanism for development. He was participating in ABC up until December of 2017. He ultimately left shortly after Amaury went ahead with implementing CashAddr in Bitcoin ABC.
Freetrader wanted to throw out a public community survey to gauge support on this matter; tacitly *expecting* people to come to *him*. Amaury wanted to ***reach out*** and have ***direct*** communication with parties that had relevant experience to provide useful feedback. He ignored Freetrader's surveys in favor of the data he had already collected from direct contact with businesses in the space. Even one of the Copay developers preferred the CashAddr specification. Fixing the address format was an important change to make happen as soon as possible. Significant amounts of money was being lost by sending to the wrong addresses. I tried to on-board multiple friends and lost funds when they sent me a BTC address. https://lists.linuxfoundation.org/pipermail/bitcoin-ml/2017-November/000534.html https://lists.linuxfoundation.org/pipermail/bitcoin-ml/2017-November/000544.html
In fact, this issue should have been resolved by the time of the fork, and a suitable address format already implemented. The draft CashAddr specification was 7 months old at the time of the fork, and some kind of resolution should have happened on this issue. Would the BUIP vote sufficed at a community survey? Maybe, but BUIP037 was never even brought to a vote within BU. https://github.com/BitcoinUnlimited/BUIP/blob/master/045.mediawiki
People believed so staunchly that Bitcoin Cash would take the BTC ticker and name. They refused to do the work on necessary features to ensure the survival of Bitcoin Cash if their *beliefs* didn't work out - they perpetually failed to consider any alternative than their own visions; they failed to gauge that social consensus was not *actually* on their side.
Now, implementing another supported address format was totally within the scope of Bitcoin ABC. This was not a network consensus change and did not require anyone else to implement it. It could have remained unused by the rest of the ecosystem. The rest of the ecosystem could have coalesced around any other address specification. Amaury did not ***force*** it on anyone, and yet there are still people who believe that Amaury somehow made people implement this.
Nevertheless, shortly after CashAddr was incorporated into Bitcoin ABC, Freetrader disappeared from participating in ABC. He can speak for his own motivations, but it seemed that it was in regards to how the survey was disregarded. He is still doing community surveys. But neither surveys, nor their results, imply that there is broad community support for anything. How are people genuinely notified they need to participate? How does someone know people haven't participated more than once? Who collates the results? When community opinion conflicts technical requirements, who gets to make the final decision? https://read.cash/@freetrader/bitcoin-cash-node-community-survey-march-2020-c23eb5a8
It ultimately amounts to a system were Freetrader would end up making the final decisions, and he would show his survey as evidence that his decisions had community support to dismiss critics. But this evidence isn't evidence of anything at all - just like BUIP votes from Bitcoin Unlimited are not representative of the businesses and user base of Bitcoin Cash.
Another complaint lodged by Freetrader is about making decisions using unpublished data: However, the data was circulated between individuals but never prepared for publication due to prioritization. Freetrader either had access to, or could have access to. If it was his priority, where was his write-up to formally publish it? There was a severe shortage of hands at this time to do everything necessary, a significant number of people complaining, and almost no volunteering to do any of the work. https://lists.linuxfoundation.org/pipermail/bitcoin-ml/2017-November/000438.html
When Bitcoin Cash finally came on the scene, there were already three forks of Bitcoind: Bitcoin Classic, Bitcoin XT, Bitcoin Unlimited. None of the lead developers of these codebases could get along, that is ***why*** they came to be. If these developers were capable of getting along in any meaningful way, there would never have been any need to fork Bitcoind multiple times. Amaury Séchet was not the source of their inability to collaborate - it clearly preceded him.
And again here we are, three years later from the events around the DAA and ***no solution that everyone agrees upon has been specified, coded, and released.*** We don't even have an accepted list of ***requirements***.
From my perspective, Amaury's primary "sins" have been to:
***Having the fearlessness to make decisions when others would not, and deal with the possible consequence of his client forking off.***
Dismissing individuals who are more interested in debating solutions rather than solving problems.
To have little patience leading him to speak harshly to others he deems to be wasting his time.
To sometimes erroneously assume that some people are no longer worth working with.
And to generally be terrible at giving meaningful feedback on code reviews, instead expecting mind-reading, or attempting to use the Socratic method in lieu of giving clear constructive criticism. *Attempting the Socratic method with someone who didn't sign up for your class is almost always seen as condescending.*
Amaury has made fearless executive decisions on what to include, or not include, in Bitcoin ABC. And he has been short with people who wished for him to include something. However, nobody has ever been entitled to have their code incorporated into that code repository. People have always been free to run, or not run, the Bitcoin ABC software.
For whatever reasons, people have continued to do so. It is asserted that he has the power to force his changes on others, but who gives him that power? He only has the authority to merge code into Bitcoin ABC. Where does the public outcry over changes to Bitcoin ABC come from? If I make a Bitcoin Cash Node that has protocol changes that people do not want, would anyone care?
After three years of these disagreements, Freetrader has come back from his absence to work on Bitcoin Cash again. His new project exists primarily in opposition to Bitcoin ABC, rather than an effort to move the needle forward on P2P cash. The disagreement, that brought him back, was the infrastructure funding proposal.
Rather than assist with any existing project to come up with a palatable mechanism to do development and handle funding, he started his own project, and his own fundraising. Has this project helped in any way to build community consensus, or to further fragment it? Has progress been accelerated, or diminished?
The purpose of his project is an to attempt to implement a different decision making mechanism about what changes are, or are not, included in a bitcoin cash client. The Bitcoin Unlimited mechanism was insufficient, and the Bitcoin ABC mechanism was insufficient. It would seem that development decision have to be done **the way freetrader wants** for him to be willing to participate - and who could expect anything else?
But will he, and his compatriots, practice what they advocate and leave Automatic Replay Project in their client due to public dissent? Myself and many others do not want to see it removed. When freetrader becomes lead developer of Bitcoin Cash, will there be alternative ways to to make decisions? Or, will I have to use ***freetrader's way*** of making decisions?
And what has Freetrader's project accomplished so far? He's removed code for miner voting, and now proposing removing code for Automatic Replay Protection. What else will be removed, or left undone, based on "collective agreement" - whatever he deems is agreement, ***despite*** the fact that I, and many others, do not agree with the process?
If nobody *has the ability* to make decisions for their *own project*, how does anything get done? There will always be someone who does not want a change. It is human nature to resist change - change is dangerous.
Many have recently also stated that Bitcoin Cash is not Bitcoin ABC. It is as they say. Amaury cannot change Bitcoin Cash, he does not have the power to do so since the protocol does not belong to him. So, why are we having so many disagreements about what he chose to do on his software project with his time and energy? Why have ***any*** disagreements over what a project maintainer includes or does not include in their software - who cares? How can anyone claim that Bitcoin ABC has unilaterally changed anything about Bitcoin Cash? https://read.cash/@noise/bitcoin-cash-is-nobodys-project-a-response-to-micropresident-ce3671ba
*Someone* always has to make the decision to take the first step in building something. What we have right now *is* decentralized development. WE are free to do whatever we want and try to get people to run our updates. We are free to deal with the consequences of our software potentially not being compatible with anyone else's.
At what point will we leave the pettiness, over who gets to be in charge, behind and actually work to make meaningful products that we can show the outside world - products that will make people want to use Bitcoin Cash?
The Problem with Group Decisions
Westerners, for the last few centuries, have asserted that democracy is the best form of government. Comparatively, democracies have greatly exceeded any other current form of government in terms of human prosperity and flourishing. Although, that can be directly attributed to the economic freedom of those societies, rather than any other factor.
However, empirical results compared to existing forms of governance do not imply that democracy is the ideal way to run a society. There have been many past attempts to theorize about the ideal society. None of them, to my knowledge, examined why democracy is comparatively good, and what its flaws are.
The reason is that **each choice made by an individual communicates valuable information** to the rest of society. This information, in aggregate, improves resource allocation, and improves the lives of everyone within a society. Democracy, as a side effect of voting, tends to give the majority of people access to actions they would most likely make. https://en.wikipedia.org/wiki/Action_axiom
“The best government is that which governs least”
People should take this to heart as it has a real impact on the gross production of society.
However, I am not so radical as to believe no organization is required within society. Indeed, we have no examples of an a-governmental society doing anything meaningful. It need not take a vivid imagination to understand that such an anarchic situation quickly devolves into bodies of people who monopolize violence.
Under the assumption that government is necessary, it makes sense to examine the flaws in our current forms of democracy and possibly revise it. The primary flaw that is often cited is that the majority of people really have no business making decisions that could impact everyone else. Simple voting does not actually aggregate the best information available, but simply enacts laws based on the opinions of the majority. The best decisions tend to be made by outliers.
There is the obvious problem with democracy, is that all desired votes cannot be called. If so, we’d all be voting continuously and nothing practical would be done. There has to be a filter placed on what things can even be called to a vote. But how do you fairly decide what can be voted on?
Aggregating yes/no votes over a large body of people destroys useful information about what would most benefit society. Minority opinions are essentially discarded, along with the information which led them to hold those opinions. We assume that the majority has the “right viewpoint,” but contrarians often are left laughing last.
Aside from destroying information, the majority for any given vote may be made of different cohorts of the population. This can lead to a situation where majority group preferences can contradict each other. This problem is called the **Condorcet paradox**. https://en.wikipedia.org/wiki/Condorcet_paradox
Finally, for most voters, the cost of the time required to participate in voting actually outweighs any expected benefit to them. This is documented as the **Downs paradox**. https://en.wikipedia.org/wiki/Paradox_of_voting
In short, democracy gives citizens the **illusion of control** -- something libertarians are very familiar with. It keeps society largely complacent by diverting their attention to mechanisms which largely have no impact. This is a Good Thing™ as it obviates violent upheavals which do not benefit anyone. Stability is often preferable to an angry mob. https://en.wikipedia.org/wiki/Illusion_of_control
However, there are ways to consider the opinions of everyone in an efficient way. These mechanisms require the use of numerical values which can be summed and averaged. No particular person's opinion is discarded, even outliers -- although the validity of their opinion may not be able to be appropriately weighted. An example of this might be: “How much money should the government spend on maintaining a military?”
The answer to such a question is not a binary yes/no, and significantly more information can be retained.
Maybe the best form of government is for the citizens to simply decide on a tax rate, and where to allocate funds? The economic incentives may possibly cause everything else to fall out appropriately.
The society which can most efficiently aggregate and make use of the collective knowledge of its citizens will easily outcompete and outperform anything else. We should look for better ways to make informed group decisions.
Responding to mtrycz’s “A humble response to The Cryptocurrency of Theseus”
Responding to mtrycz’s “****A humble response to The Cryptocurrency of Theseus******”** https://read.cash/@mtrycz/a-humble-response-to-the-cryptocurrency-of-theseus-8f8c22f6
***You define BCH as numbers produced by Mr Sechet's software. I propose a different definition: it's the numbers produced by the BCH protocol. You could claim that it's the same, claiming ABC is BCH. I think it's the source of our disagreement.***
I want to clarify a point with regards to the above statement. The claim I was making is that these are numbers produced by the BCH Protocol, just like you say in your article. However, I also argue that the definition of the BCH protocol **is** defined by what is validated by the Bitcoin ABC software.
***I had joined BCH to avoid capture of Bitcoin by a single entity, which for BTC is Bitcoin Core. I thought at the time that decentralised development was unique to BCH and it's strongest asset for the development of a decentralised protocol.***
Bitcoin Cash is a decentralized protocol, but this is orthogonal to a decentralized software or decentralized protocol definitions. It is a necessary condition that, in order to have a language or protocol, you must have a shared understanding. Computers, unlike people, cannot coalesce into a shared consensus of language. There must be some organization which sets a strict protocol that software accepts. This is independent of what any of us *wish* to be the case.
This is the **nature** of Bitcoin. It’s **why** we had to fork away and create Bitcoin Cash. Nothing has changed in this respect when the fork on Aug 1st 2017 occurred. Had the options we wish for actually existed then, and now, we would use them.
***Decentralised development of a decentralised protocol is something that has never been tried before, not that I'm aware of.***
Indeed, it has been tried, and it doesn’t work because ultimately the differing pieces of software will no longer be able to speak the same language. This is a Tower of Babel problem.
***BCH could have avoided a lot of animosity if development was more publicly evidence-based. And this is the main reason I joined BCHN.***
I’m going to refer to a **recent article from David Allen** to respond to this point. https://read.cash/@DavidRAllen/why-do-i-chair-bch-dev-meetings-and-who-gets-invited-4d075f64
***I think that on the basis of your article you think I'm "willfully ignorant, stupid, or malicious"***
It is not my belief that you **were** willfully ignorant. My point is that, now having been made fully aware of the reality of cryptocurrency development -- in all cryptocurrencies -- if you choose to hold to your ideology, you are being willfully ignorant.
***My points of disagreements were twofold: 1) I believe it alters Bitcoin's economic model in a disruptive way and 2) the way the thing was handled by ABC***
The “way the thing was handled by ABC” is very vague. How was it handled by ABC? The repeated narrative, and I assume you are pointing to this, does not align with what actually occurred.
***Momentum had built up against the IFP, and out of that momentum BCHN was founded. I joined BCHN because I wanted to support that momentum.***
I’m glad for that, but your motivation is founded on faulty assumptions. And, you could have joined the momentum around ABC at any point in time over the last three years. The primary point of contention with ABC is that they are not communicative, and not being transparent enough. This has always been due to a shortage of manpower. People have chosen not to participate.
Now, when the time is dire for Bitcon Cash and ABC -- instead of coming in to assist and help -- an alternative project was launched even with many others already in existence. To nearly every outside observer -- given the resentful people that started it -- this is **extremely** counterproductive.
***There is a common misconception that BCHN wants to replace ABC and be “in charge” of BCH, and you argue as much in your article. That's not the point.***
I think freetrader, maintainer of Bitcoin Cash Node, should clearly state what his goals are then. It seems only to be there to provide an alternative to ABC in the case where they are perceived to be doing the “wrong thing” again. And in that sense, it is there to become “in charge” of BCH if something were to happen.
But, again, instead of helping and collaborating, it was founded on resistance. The IFP would have never been proposed or needed if the same kind of energy was applied to assisting Amaury instead of what amounts to a rebellion.
***I say, let's not have one single Lead Maintainer. The point is a push for evidence-based decentralised development, where multiple teams cooperate on the protocol and compete on the implementation/performance/features.***
Firstly, there is an implication here that ABC does not, and has not, been doing evidence based development. That simply does not match reality. ABC was always very methodological in what changes needed to happen, and in what order they are prioritized.
And again, this is an *ideological argument*, it doesn’t pass the test of pragmatic investigation. What does evidence-based in this case mean? Who decides? Someone has to decide to include code in implementations. Any one implementation has veto power over features if there is, in fact, a spattering of node software in use. Any effort to push forward on protocol changes will result in a network split, and two different currencies.
If you want to be evidence-based, first examine the practicalities of network protocols, software development, and economic and legal incentives for exchanges and miners.
Alternative node developers are anything-but evidence based.
***We are all different. But we can try to discuss and come to an agreement, or at least try. BCH has actually no shortage of talent, Mr Sechet, you, Mr Rizun, freetrader, Mr Zander, Mr Culianu, Mr Toomim, and tens of other named and pseudonymous competent engineers work on BCH to make it better. Let's try.***
I’m going to again refer to a **recent article from David Allen** to respond to this point. A tree is judged by its fruit. Good talent yields good, and useful code. Bad talent talks, complains, and does nothing of value. Not everyone on your list provides good and useful code. https://read.cash/@DavidRAllen/why-do-i-chair-bch-dev-meetings-and-who-gets-invited-4d075f64
Mr. Rizun, Freetrader, and Mr Zander were all invited to developer meetings and refused to attend with any regularity. How can you collaborate with people who won’t show up to discuss anything?
***I find it also perfectly possible (reasonable, actually) to disagree or criticize ABC/Mr Sechet without this being an attack. A disagreement or a critique doesn't cancel respect or gratitude for all the work, either.***
Absolutely, and I did critique Amaury, and I do disagree with him quite a bit. I’m not discussing people who do as I do, and give constructive criticism. Read through r/btc and you’ll see people outright lying and slandering Amaury.
***There is also the idea floating around that BCHN was created to fork BCH again. This is unfounded. BCHN wants to collaborate with everyone for the furtherment of BCH. It also happens that implementing the IFP is seen as sacrificing a fundamental property of what makes BCH what it is on its way to becoming world money.***
Nobody is confused about what the stated intent is for the so-called “Bitcoin Cash” Node. Freetrader is not interested in collaborating, he was invited many times to do so. He talks about evidence-based development, but then refuses to follow any evidence-based methodology. **Rough consensus** is the standard for protocol development, other mechanisms have been tried -- including the polls that Freetrader has tried to use in the past. https://en.wikipedia.org/wiki/Rough_consensus
And at the same time, he has refused to show up to any development meetings for the last three years. Yet he speaks of wanting to collaborate.
ABC has put out its hand in collaboration with all of these individuals many many times -- I know because I came in as a neutral party and was part of these attempts.
The Cryptocurrency of Theseus: What is our Identity, and why are we fighting?
Greetings and Salutations from Shammah Chancellor; micropresident within the Bitcoin Cash ecosystem. For the first year of Bitcoin Cash, I worked directly with Amaury Séchet on Bitcoin-ABC. I stress my identity because I was the point of contact for many miners and exchanges for Bitcoin-ABC for the better part of a year, and that’s relevant to the content of this article -- I provided support services, and notified them of software upgrades directly.
I started working on Bitcoin Cash shortly after the August 2017 hardfork. I had known Amaury for many years beforehand, and saw that he needed help on his project. One of my primary passions has been monetary reform since the first time I asked where money came from at the age of 8 -- why shouldn’t an 8 year old have the privilege to print money too; what makes the Federal Reserve so special?
Cryptocurrency, and Bitcoin Cash, has the potential to be the biggest equalizer of man (apart from guns with rifling) in history. It has the potential, I believe, to stop cyclic societal collapse; **which by my estimation is caused by debt cycles**. It can do that, because Bitcoin Cash is not based on creation of debt. And, it will be just that, assuming we can get over ourselves and work together; armed with the knowledge that there are many powerful outside forces which do not want to see their privileged positions, of monetary control, taken away. https://www.youtube.com/watch?v=vEU13R5jt1w
The invention of Bitcoin enabled anyone to mint new Bitcoins just by providing some electricity, and this invention also allowed anyone to create new currencies entirely. It allows you to use your own money from the privacy of your own home; away from bankstate enforcers who would demand you use *their* money.
But to return to the topic of this letter, recently there has been a lot of social pressure to depose Bitcoin ABC -- specifically Amaury (nobody has a problem with the software as far as I am aware) -- from the hegemonic position within the Bitcoin Cash cryptocurrency network (BCCN; which I will continue to use instead of “community”). They are doing so for two main reasons. Firstly, Amaury has pissed off nearly every software developer, and investor, in the BCCN because he has an upside-down value system for a lead maintainer -- a value system which leaves many other participants feeling insulted, unheard, and unvalued. Secondly, there has always been external pressure, of those who currently print money, to destroy alternatives like Bitcoin Cash. One of the best ways to do that is to sabotage the leader, and rouse a coup.
While the external factors are inescapable, and we should remember these propagandists will always be around. Amaury has done little to help himself. Not everyone has known him for as long as I have, and is sure of his motivations, commitment to truth, and his desire for monetary reform. Despite my ***large*** personal differences with him, I have no questions about his motivations, or his technical leadership. He is not “evil” nor is he trying to “co-opt” Bitcoin Cash (assuming such a thing were even possible to do).
Amaury has overvalued doing, at the expense of consensus building. He feels a great time pressure to get things done quickly; an urgency that requires someone with his expertise to do rather than oversee. His, often self-imposed, time clock does not leave room for teaching other novice developers, and developers without firm professional software development experience. Although I do not agree that we should remove **Automatic Replay Protection**, I do think we should have more network upgrades that contain ***nothing*** so we can slow down and get people working together (who want to work together if they could just get the tiniest amount of positive reinforcement and attention.) His value system never underwent the mandatory patches to move from Principal Engineer to a leadership role of CTO or Benevolent Dictator. https://read.cash/@micropresident/why-automatic-replay-protection-exists-efdf9e51
Yet, Amaury is indeed extremely talented as an engineer. He is arguably Bitcoin Cash’s greatest asset. If he could just learn some lessons from some of the more respected and positively viewed projects we would be in much better shape (no not Linus Torvalds, Linus gave more productive feedback than Amaury, and even then he **apologized recently and went to counselling**). Culture is set from the top; and Amaury, whether he likes it or not, whether he will admit it or not, is the top of the BCCN. He was the one who led the production of Bitcoin ABC, and coordinated the hard fork on August 1 2017 -- his work led to the creation of Bitcoin Cash. https://www.cnbc.com/2018/09/17/linux-creator-linus-torvalds-takes-time-off-apologizes-for-behavior.html
Though, this is not to make Amaury responsible for all the communication problems within the development community. He cannot be expected to endlessly battle with people suffering from Dunning-Kruger syndrome. The Lead Developer at Bitcoin XT once remarked to me that Amaury was too pedantic for requiring linting and auto-formatting as they were of “no value” -- his pull request should not be subjected to formatting standards.The phrasing leaves no room for discussion, that developer knows best, and Amaury is just wrong. Although, any professional software engineer will understand, just from that statement, that the developer needs to be upgraded. If this is the ***start*** of the disagreements, there was never any common ground to work from.
It ought to be obvious to anyone that when you contribute to any project you follow the guidelines set by the project. These guidelines are never large requests, and certainly setting up a development environment is **less difficult** than contributing anything worthwhile to the project itself. These kinds of occurrences -- demands that Amaury conform to ***their way of doing things*** -- were far too prevalent from developers while I was still involved.
Seemingly, technologies like Kubernetes, Python, Ruby, JavaScript, C++, and Go are easier than figuring out how to use **Phabricator** . That time spent learning how to participate in a project is not worth the effort. The maintainer of the project should conform to *their desires* and use **Github** (and then gitlab) instead. These trivialities were the start of the disagreements, and they have only magnified since then. https://en.wikipedia.org/wiki/Phabricator https://github.com/
Still, much of the problems within the development ecosystem are due to Amaury’s frenetic pace. Communicating with individuals who are trying to contribute, but flailing, is often not seen as a worthwhile task due to self-imposed overloading. Coding sessions, traveling, speaking engagements, and snarky tweets are all more important during the perpetual time crunch. This freneticism causes him to be terse with people who do genuinely deserve more attention, explanations, correspondence, and praise. And this is unfortunate, because when Amaury is not stressing himself out, he is a genuinely wonderful human being and fun to be around.
And all of Amaury’s faults -- and none of anyone else’s -- have led to this situation we are in now. The situation where other developers are creating new Bitcoin Cash clients in the belief and hope in deposing him from the position of lead maintainer for the Bitcoin Cash reference client. Only focusing on that one problem within Bitcoin Cash, that would certainly be a good solution. Although, in reality there is no suitable human replacement.
But the desire to depose someone from ***leading*** Bitcoin Cash demands the question: What is Bitcoin Cash? What is the ***thing*** which they wish to gain control of?
This may seem like a metaphysical question, but there are practical ramifications due to ***what*** Bitcoin Cash is. It’s easy for us to pragmatically observe what these ramifications are, and determine the identity of Bitcoin Cash -- what makes some numbers Bitcoin Cash, and not other numbers.
Are Bitcoins just numbers? Is it a network protocol? Is it the software network that runs it? Is it the tokens produced by miners? It might be just numbers. It certainly isn’t a network protocol, as we make breaking changes to that every 6 months. It also can’t be tokens that miners produce, as that simply isn’t specific enough -- there are lots of different mined tokens.
Things are nominally defined, and identified, in terms of their use. I propose this definition then:
***A Bitcoin Cash is a measurement that defines a specific and standard arbitrary unit of value, that people use to measure the relative worth of “good and services” and the representation of that unit, which people use to exchange with one another to make trading more efficient. A specific instance of a “currency.” [1]***
I’m not entirely happy with the end of that definition, but it should suffice for understanding the identity of Bitcoin Cash; which hangs on the fact that people ***must*** be exchanging it for it to be Bitcoin Cash. As such, both parties, in an exchange, need to share a ***common understanding*** of what it is they are exchanging.
So that is to say, Bitcoin Cash is the thing which the users agree is Bitcoin Cash and can be used as currency. If we all were brainwiped tomorrow to believe Bitcoin Cash was seashells, and we started exchanging those, then they would be Bitcoin Cash. But, that’s not true, we instead believe that Bitcoin Cash is what cryptocurrency exchanges sold us, or what people initially gave us.
When I bought my first Bitcoin Cash, I bought a token being represented by data that was produced by the Bitcoin ABC software and catalyzed by the Bitcoin Cash miners. If you did not buy or work for your Bitcoin Cash, then you were gifted tokens by the rest of us who chose to exchange them with you.
I did not buy numbers produced by any other software. Nobody else did either. Even if they did not know they were buying coins produced and verified by Bitcoin ABC, they at least have the expectation that the exchange and wallet they use is not going to switch out this software underneath them. They also either explicitly or implicitly bought into the roadmap, and the upgrade schedule advertised on BitcoinCash.org. They bought tokens that allowed them to exchange value with a specific network of people, via a computer network.
Exchanges must maintain the implicit expectations for customers they set when they sold them those coins. Attempting to replace the Bitcoin ABC on some exchanges would necessarily create a social network fork, while attempting to claim that something that didn’t exist prior is now the “legitimate” Bitcoin Cash. Yet, the network supported by Bitcoin ABC, that did exist, would still exist. You cannot take ideas, and a name is an idea.
If in November, there is a network fork and Coinbase installed Bitcoin Cash Node there will be serious consequences for them. When the first customers buys “Bitcoin Cash” from them, and it doesn’t appear as a valid coin under Bitcoin ABC software, there will be a lawsuit. A lawsuit those customers will ***win*****.** It will **not matter** what percentage of the BCCN thinks Bitcoin Cash should flow from the Bitcoin Cash Node software! Most people who buy and sell BCH do not care about, nor pay attention to, the internal squabbling of r/btc.
But this leads to another **Ship of Theseus** problem, what is the Bitcoin ABC software? I would argue it is compiled out of the source code repository “blessed” by Amaury Séchet, compiled, and distributed either by Amaury or one of his representatives. This is simply a complicated way of saying that nobody else can make Amaury’s Bitcoin Client, but Amaury himself. (Now, I do not want to get into the question of the identity of Amaury, I think we can all agree on common sense here.) https://en.wikipedia.org/wiki/Ship_of_Theseus
This means that exchanges are going to run the software he makes, regardless of what rules he decides. They must in order to avoid lawsuits. This is why every forked client has always been listed as a separate token: S2X, BSV, ETC, the plethora of Monero forks, and many others. Amaury Séchet is the only person who decides the network rules on Bitcoin Cash, and what code is in the mainline client. Not miners, and not users. I know this because I was the one who communicated with exchanges during the 3 hardforks immediately after 1 Aug, and the CashAddress migration. The reasoning should also make it apparent.
I don’t say this because I ***want*** it to be that way. After I left ABC, I considered launching my own node client because I believed that Amaury’s leadership was detrimental to ***his*** project. However, I came to understand that it would not only be wasted time, but counterproductive towards my goal of monetary reform. The repository is over **here**. https://github.com/cashweb/cashd
In my **blog post regarding Bitcoin Unlimited**, I was careful to say “I still believe Amaury is the best person to lead the technical direction of the Bitcoin Cash protocol.” I, specifically, did not say he was the best leader of people. I also did not say that his leadership style was not absolutely destructive to ***his*** project -- it is. https://shablag.com/article/every-new-beginning/
At some level, the rabble rousers in the BCCN understand that Amaury is “in charge”, that’s the entire premise of this perpetual revolt. “Amaury isn’t allowing us to do something.” Intuitively, we understand that Amaury has effectively absolute authority over Bitcoin ABC and thus Bitcoin Cash. However, some of us are unwilling to acknowledge it consciously. To acknowledge it would be to admit our mythologies about Bitcoin are wrong. Bitcoin isn’t working out as it is ***supposed*** to: there are no privileged positions in Bitcoin Cash! Some cling to this belief despite 10 years of evidence to the contrary, starting with Bitcoin Core.
But all is not lost! In reality, the cryptocurrency marketplace subjects these privileged individuals to market pressure and makes them compete with each other. When they have to compete for business, their privileged positions become subject to user preference, and their accountability is restored to order. No longer can the Bank of Amaury do whatever he wants -- but it is still his bank.
In fact, this is why the IFP didn’t pass. Amaury could have hardcoded it, but he didn’t. Instead, he let miners vote on it with user input. Reasonably anticipating the coin depreciation was worse than any potential gain, it did not pass voting. This is how users keep Amaury accountable.
Now we can continue to live in our delusions of deposing Amaury from the position of “Leader”, or we can choose to interact with the world as it is. We can continue to fight a non-existent unwinnable battle, wasting all our time, damaging the project, and causing uncertainty in the market which ***depreciates the price of Bitcoin Cash for us all***, or we can accept reality. Prominent whales who, to be sure have done great things for BCCN, but nevertheless are human and fallible, have let themselves be fooled into funding an unwinnable war -- instead of more productive endeavours.
I don’t want to see Amaury removed, I want to see him improve his communication. I want to see the community help out more, and understand his deficiencies. I want people to understand that not every adult lived a childhood that equipped them with the interpersonal skills required to run a multi-billion dollar transaction network. I want to see the people who continually antagonize him leave and not come back. And, I want block-reward based funding, because that’s the right way to incentivize developers; and if they misappropriate those funds, the market will punish them.
The people who continue to battle over who gets to be “in charge” can reasonably be assumed to be: unthoughtful and ignorant, stupid, or malicious. I will be referring to this letter in all future discussions that draw into question Amaury’s right to lead his own project. Those of us who want to move forward cannot endlessly spend time debating people who are willfully ignorant, stupid, or malicious. At some point it has to stop.
If someone really doesn’t want to see Amaury as the Lead Maintainer anymore, they need to find a different cryptocurrency where you’ll see someone else as the Lead Maintainer.
Endnotes:
[1] It should flow from this definition that in order to be a currency, it must be a unit of account, a medium of exchange, and a store of value. The last one being required due to the delay between two symmetric trades exchanged with the same tokens (i.e. it cannot be a unit of account, unless that unit is reasonably consistent over time.) I point this out because this has been a hot point for debate in recent years in the cryptocurrency intelligentsia. However, this debate shouldn’t exist, since these three statements are actually equivalent. A store of value is also a unit of account and a medium of exchange. A medium of exchange is a store of value and a representation of a unit of account. Again the same for the unit of account. These properties are inseparable because they are different only perspectives on how humans ***use*** currency. Anything humans use for *one of these functions* they will also use for the other two.
取回身份所有权
原文发表于: https://read.cash/@micropresident/taking-back-our-identities-65fc6db5
互联网正在变得更加中心化。谷歌、脸书、Reddit等，占据着在线社交论坛的主导地位，并越来越多地控制着我们与他人的交流以及我们的数据。但是，当我们无法再匿名发表线上内容时，我们维持自由社会的能力也受到了威胁。你那无政府资本主义的推特账号怎么样呢？推特定会将你的数据发送到类似LiveRamp的地方，将你的账号、设备打包成单个实体，以供在线广告商追踪你的行为。匿名、安全地发言变得几乎不可能。只要政府需要，随时可以访问这些数据。
破坏我们自治的主要因素有两个：
在线电子支付非常麻烦。所有的电子支付，需要将信用卡和个人信息交给第三方--这侵犯了你的隐私和匿名性，同时也侵害了基于广告的服务模式。此外，这些服务需要时间来搭建免费的服务，以便在广告上获利。然而，在基于广告的模型中，你才是那个商品。
互联网上消息的传送费用由接收者承担。因此，电子垃圾邮件迫使人们避开公开协议，转而投向可以监控和删除垃圾邮件的中心化平台。这些服务，通常会将你的身份绑定在一些类似于电子邮箱地址、电话号码等有价值的资源上。垃圾邮件发送者会很快失去其账户的访问权限，白费他们使用某个电话号码或邮箱注册所花的精力。这样，电子邮件就有效地集中在诸如gmail、hotmail以及其它几个主要的服务供应商上。
我相信，缺乏真正的数字匿名性将是这十年来我们面临的最大问题之一。而且我相信比特币现金（BCH)可以用比特币原始的初衷，即用作类似于无形价值物的电子现金，来解决以上提到的问题。
比特币的主要贡献者--哈尔·芬尼（Hal Finney）梦想着使用一种他称为“可重复使用的工作量证明”（RPoW）的电子货币。 这个概念其实很简单，即以数字方式标记现实世界的资源消耗。以下是他的原话：
“通过允许通证在人与人之间传递和交换，RPOW将有助于POW通证的使用成为比特金（bit gold）的一种形式。
在一些应用中，已提出将POW通证作为一种伪支付的形式。 其中一个例子便是电子邮件。 就计算能力而言，发送包含POW通证的电子邮件信息的成本相对较高。 这样一来，POW通证可以成为该信息不是垃圾邮件的标志。”
比特币现金，是哈尔所设想的RPoW的有效实例。 现在，我们所要做的便是实现他梦想的其余部分。
在开发Bitcoin ABC时，我就时常在思考这个慨念；并想当下的钱包并没有为隐私性和大规模应用而开发。大约在一年前，我不再积极开发Bitcoin ABC, 取而代之的是开始研究可以解决上述问题的新型钱包。其他几位开发者也加入其中，为此我深表谢意。
这款钱包，以及相关的公开协议，可以解决这些问题，并为我们取回自己线上身份的所有权提供了机会--如果我们想要匿名，完全可以实现。通过为任何电子服务提供丝滑的支付，以及为消息附带真正的价值，来限制垃圾邮件并将发送垃圾邮件的成本重新分配给邮件发件人，从而解决了这些问题。
我们目前将钱包称为“Stamp”，其目的是为使用一组协议的客户端提供执行参考，以便任何钱包在未来时间点都可以执行（该协议）。 该协议通过比特币现金之上的网络覆盖，实现了钱包到钱包的直接通信。
由于用户间BCH的相互交换，覆盖网络（我们称为CashWeb）能够开放且不受限制。 非垃圾邮件发送者之间相互传输小额的BCH，以极低的矿工费实现高价值的对话。 向许多人广播的用户很快就会发现自己没钱了。 用户之间的每条消息，都通过类似于SMTP，但终端到终端加密的中继服务器来实现传输。 中继服务器无法读取你的消息，也无法根据内容进行管理。
拥有可供钱包使用的覆盖网络，使许多密码货币爱好者之前设想过但暂时无法实现的事情变为可能：
秘密交易
有限的机密交易
支付给端点
撤销和轮换无需信任的秘钥
直接发讯息给收款人
去中心化的密码货币交易和混币
它同时也让一些之前未曾设想过的事情成为可能：
无管理的内容交换
在线服务的丝滑支付
随处一键支付
互联网是产品，而不是个人作为产品的互联网。还有很多我无法想象的其他东西，可以建立在这基础上。 我的希望是一旦建立基本产品并可供使用，许多其他开发者就会提出自己的想法并参与其中。我们目前已经建立了概念证明，并在使用时对其进行完善，来判断需要在哪里进行重大更改。 以下是当前系统的一个屏幕截图：
虽然它目前看上去像是电报的克隆体，这其实只是钱包布局的一种选项；除了简单的加密聊天，这项技术还具有许多其它功能。 https://t.me/stampchat
如果你和我一样，认为这是令人兴奋和重要的，请在电报或推特上与我取得联系。 https://twitter.com/micropresident
WeChat: Micropresident
如果你并不是开发者，那么可以通过alpha测试、捐款（bitcoincash:qq7vt04md0pt6fk5szhcx4cgsfuzmppy5u4hxshr4a）或打赏这篇文章来做贡献。
这些捐款，将用于聘请工程师和加速开发该钱包的可量产移动版本。
Answering questions about the IFP
I was recently asked by Shadow of Harbringer to answer questions about the IFP, because I disagreed with him about what happened. Many people are still making assertions about the nefarious nature 👻 of the IFP - that ABC (read: Amaury Sechet) is unilaterally co-opting Bitcoin Cash. (This is ironic given that the complaint supposes its own problem. That is to say, Amaury must have already co-opted Bitcoin Cash if he has the power to unilaterally co-opt it.) https://old.reddit.com/r/btc/comments/hct5dn/requesting_clarity_from_george_and_the_official/
Now, I was not involved any any of the decision making process regarding the IFP -- except that I initially proposed developer funding from the block reward in 2018. A proposal which was originally accepted -- until nChain started a propaganda campaign labeling it a tax. In reality, the motivation was that development would be funded independently of them, preventing them from becoming the next Blockstream -- and they would be unable to capitalize on their patents.
However, questions that Shadow Of Harbringer cited do not require me to be familiar with the inner-workings of the IFP in order to answer. In fact, anyone can answer them for themselves. Fundamentally, I disagree with the framing of the questions as a whole, and my answers seek to obviate, rather than answer.
As a group of libertarians, voluntaryists, anarchocapitalists, and pragmatists (myself being the lone wolf in this final category I suppose). I hope we can examine the implicit framing in these questions, and see past them to market-based solutions to supposed problems that stem from a desire for democracy and collectivism.
I will also state, again, that I don't like the exact mechanism of the previous (and now defeated) IFP. Yet, I do believe that some form of funding, from the Block reward, is necessary if Bitcoin Cash is to succeed.
Here are my answers to the questions: https://old.reddit.com/r/btc/comments/hct5dn/requesting_clarity_from_george_and_the_official/
What is the exact method for adding names, addresses and entities to the whitelist?
Presumably, some people looked around at all the projects providing useful products. Ascertained if they were in fact a "public good" (by the technical definition). And then added them to the list, which then Amaury added to the code through a commit.
How do you think it should happen? I wrote in depth about what I think should happen. https://shablag.com/article/bitcoin-cash-development-funding/
Who runs the quarterly and annual transparency audits on the distribution of those funds? How can we guarantee no siphoning or misuse of those funds will ever take place - or that if it did, it will be caught?
The transparency audit is on the blockchain. If miners aren't comfortable with the information the organization is exposing, then they shouldn't donate to them. Not every one of these things needs to be solved through complicated processes -- market incentives are enough to drive it.
How can we vote to add or remove development entities?
Social petitioning, just like was done to stop it from being done in the first place. If you have the power to stop it, you can change it.
Can we add non-development entities to the list of those funded?
This list is intended to fund public works. Why would you add other stuff? Presumably you could through the same mechanism as above.
Is there a steering committee to decide on the trajectory of the IFP and its future goals and iterations?
Why do we need a formal committee when market incentives are enough to result in a pragmatic solution?
What is the governance model this committee follows? What are the voting mechanisms, rotation schedules and guiding principles?
The framing presumes that these things are ***needed***. I ***don't*** want such a system. I want a system where funds go to trustworthy individuals - individuals who are experts on what needs to be done, and are distributed accordingly. They'll likely produce transparency reports. If they don't, miners won't continue to send them funds, and users won't continue to use Bitcoin Cash.
What is the formal process for objecting on the funding of certain entities?
The same one that was used to block it from being implemented in the first place.
As a user of BCH - can I choose to not fund a specific entity if legally or ideologically I am ought not to?
Yes, by not using BCH. Vote with your feet. Stop pretending to be powerless.
Does me using a network which funds such illegal entity (if my country deems them illegal) put me as a user in any legal risk?
What if your country makes cryptocurrency illegal? 🙄 You're asking the wrong people, and if your country does, move or stop using it.
Why Automatic Replay Protection Exists
Hello, my name is Shammah Chancellor, I go by micropresident within the Bitcoin Cash community. I use to work on Bitcoin-ABC as a developer.
Recently, Automatic Replay Protection (a.k.a. the Poison Pill 👻) has become controversial, with some people seeking to get rid of it. I wrote the specification for this protocol rule. As such, I’ve been asked by a few different Bitcoin Cash users to explain this functionality to them. Hopefully this article appeals to a wider audience.
“Automatic replay protection” is critically important to the future of Bitcoin Cash. It was unanimously asked for by exchanges. Without it, routine protocol upgrades would be practically impossible due to the amount of extra work required by exchanges, wallets, and other developers to smoothly enable.
This is because, during an upgrade, if a minority of individuals do not agree with the new rule-set then they may continue mining a chain using the old rule-set. However, the blocks produced will not be valid under the new client, and not seen by the exchange running the new node software. When this happens, transactions will still continue to be valid on both the upgraded chain, and the legacy chain under most conditions.
Transactions, that are valid on both of these persistent chains, can be rebroadcast by nefarious individuals to potentially steal money from end-users and exchanges. For example, during the Ethereum Classic fork, some individuals would deposit coins which were uniquely Ethereum to an exchange, withdraw it, and replay that transaction on the Ethereum Classic chain in order to obtain “free” ETC from exchanges.
Now, if this happens, and the minority chain becomes valuable, the exchange will have lost money. The exchange will no longer be able to property credit customer accounts for the fork. As a result, when protocol upgrades happen, without any replay protection, then exchanges must halt deposits and withdrawals for that coin.
In order to resume trading, they need to ensure their reserves are “split” (meaning that their funds become unique to each of the new chains) before offering withdrawals. Doing this is a somewhat complicated process and cannot be made fully automatic due to the steps involved.
As such, the ABC team was told by many exchanges that they would not continue to support protocol upgrades, if there was no easy-to-implement replay protection. The result was the implementation of Automatic Replay protection.
The basic premise of implementing replay protection in the node, rather than indirectly by exchanges, is to include some data indicating upon which fork a transaction should be valid when being signed. In the initial August 2017 fork from BTC, this was done by introducing a signed field called a “fork identifier.” Bitcoin Cash uses fork identifier of “0” since Aug 2017.
It would be possible to meet the needs of exchanges by continuing to increment for each protocol upgrade. However, implementing replay protection like this also requires updating every wallet to include the new fork identifier. This puts a burden on all wallet users, in addition to exchanges and miners.
During the first fork, this was an acceptable cost, as we were launching a new cryptocurrency. However, doing this during routine upgrades would cause significant loss for end-users who forget, or fail to upgrade their wallets in a timely manner.
Ultimately, the better solution which we came up with was to cause the old bitcoin nodes to change the fork identifier every 6 months instead. Thus, software that didn’t upgrade would now use a *new* fork identifier, ensuring that transactions would not be valid on both chains. This stops loss of funds through replay attacks. This is called “Automatic Replay Protection.”
That caveat here, is that there does need to be minimal upgrades every 6 months -- even if it contains no other change than to reset the fork identifier. However, this is an acceptable situation to ensure that the software **can** be upgraded in the future. No set schedule for upgrades is why BTC is stuck with soft-fork upgrades, and ossification of the protocol.
Additionally, because everyone has to upgrade their nodes every 6 months, there can be no complacency in participating in the Bitcoin Cash network. And as there cannot be complacency, it means that there is a potential for users, assuming they can reach consensus, to switch to new node software.
So, in summary, Automatic Replay Protection is important to, ensure protocol upgrades continue to be possible by:
Stopping the loss of funds from exchanges.
Making exchanges feel reassured during protocol upgrades.
Ensure that every 6 months, users have the willful intention to keep running the *SAME node software -- and to run new software if they want.
It seems that, those individuals calling this functionality controversial are simply not aware of the purpose and have become a victim of Chesterton's fence. https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's_fence
Although, in the past the individuals (i.e. nChain and BSV) were attempting to force a different ***brand*** of Bitcoin on users ***without*** their voluntary participation in the power shift. I hope that's not the case again.
P.S. It was pointed out to me that some people are saying ARP doesn't matter because none of the other nodes use it, and they're still in consensus." The reason that's the case, is these nodes are not widely used by miners and exchanges -- and if they were to fall out of consensus it doesn't have much impact. Remember, this is functionality for commercial operations, and **only** matters in the case that there is an **intentional** coin split.
P.P.S. It seems to me that part of the arguments for removing it is that it "doesn't matter," or that it "doesn't do anything." If that's the case, then why bother removing it? If that's not the case, and it is being removed, then the original claim seems to be disingenuous...
Taking back our identities
The internet has become increasingly centralized. Google, Facebook, Reddit, etc., dominate online social forums and take more and more control over both our ability to speak to one another, but also our data. Yet, our ability to maintain a free society is at risk when we can no longer pseudonymously publish content online. Your anarchocapitalist twitter account? Twitter surely ships your data off to a place like LiveRamp that detangles all your accounts, and devices, into a single entity for online advertisers to track you. Speaking out anonymously, and safely, becomes impossible. Access to this data is one government request away.
There are two main enablers of this destruction of our autonomy:
Online digital payments are cumbersome. All digital payments require giving credit card and personal information over to a third party -- violating your privacy and anonymity as much as service model based on advertising. Additionally, these services require time to set up over free services that make a profit on advertising. However, in an ad-based model, you are the product.
The cost of messages on the internet rests on the receiver. Thus, digital spam has forced people to retreat off open protocols and onto centralized platforms that can moderate and remove spam. These services often tie your identity to some valuable resource like an email address or a phone number. Spammers lose access to their accounts quickly and the effort they took to sign up via that particular phone number or email. This has effectively centralized email to certain providers such as gmail, hotmail, and a few other major services.
I believe the lack of true digital anonymity will be one of the biggest problems we face this decade. And I believe that Bitcoin Cash can solve both of these problems using what was the original purpose of Bitcoin. That is, to serve as a digital cash for likewise intangible valuables.
Hal Finney, a key contributor to Bitcoin, had the dream of a digital currency he called “**reusable proof of work**” (RPoW). The concept is simple, digitally tokenize real world resource consumption. Here's what he had to say about it: https://nakamotoinstitute.org/finney/rpow/index.html
"RPOW would facilitate the use of POW tokens as a form of bit gold by allowing the tokens to be passed and exchanged from person to person.
POW tokens have been proposed as a form of pseudo-payment in several applications. One example is email. An email message containing a POW token would be relatively costly to send in terms of computing power. A POW token could then be a sign that the message was not spam."
Bitcoin Cash is the working implementation of RPoW that Hal Finney envisioned. We now need to make the rest of his dream reality.
While working on Bitcoin ABC, I thought about this concept quite a lot; and about how current wallets were not being developed for privacy and scale. About a year ago I stopped actively working on Bitcoin-ABC and instead started working on a new wallet and associated services to fix the aforementioned problems. Several other developers have joined me in working on this, and for that I am very grateful.
This wallet, and associated open protocols, solve these problems and give us a chance to take back our online identities -- being anonymous if we so choose. It solves these problems by providing frictionless payments for any digital service, and attaching real value to messages in order to limit spam and place the cost of spamming back on the sender of messages.
We currently call the wallet “Stamp” and the intent is to serve as a reference implementation for a client that uses a set of protocols which any wallet can implement in the future. The protocols enable direct wallet-to-wallet communication via a network overlay on top of Bitcoin Cash.
The overlay network (which we call the CashWeb) is able to be open and unmoderated due to the associated exchanges of BCH between users. Non-spammers pass small amounts of BCH amongst themselves while having high-value conversations for small mining fees. People broadcasting to many people will find themselves soon out of money. Every message, between users, is passed via relay servers similar to SMTP but encrypted end-to-end. Relay servers cannot read your messages, nor can they moderate based on the contents.
Having a overlay network available to wallets enables a number of things which cryptocurrency enthusiasts have envisioned but not been able to implement for awhile:
Stealth transactions
Limited confidential transactions
Pay to endpoint
Trustless key revocations and rotations
Direct messaging payment recipients
Decentralized crypto exchanges and coin mixing
It also enables a few things which were not envisioned:
Moderation-free content exchange
Frictionless payments for online services
Ubiquitous one-click purchases
An internet which is the product, rather than an internet where you are the product.There are so many other things which can be built on top that I cannot even imagine. My hope is that once the basic product is built and usable that many other developers will bring their own ideas and participate.We currently have a proof of concept built and are refining it as we use it and see where breaking changes need to be made. Here’s a screenshot of the current system:
Although it currently looks like a telegram clone, this is just one option for how to layout a wallet, and there are many more things this technology enables beyond simple encrypted chat.
If you think this is as exciting and important as I do please reach out to me via **telegram** or **twitter**. https://t.me/micropresident https://twitter.com/micropresident
If you are not a developer, you can contribute time by alpha testing, or by contributing donations to bitcoincash:qq7vt04md0pt6fk5szhcx4cgsfuzmppy5u4hxshr4a or by tipping this article.
These donations will be used to hire engineers and to accelerate development of a production-ready mobile version of this wallet.
On Bitcoin Cash Development Funding
There have been many different conversations about how Bitcoin Cash *node* development should be funded. Some of these have been:
That developers could sell some service
That developers could sell a product
That some percentage of the block reward could go to developers.
The first two of these ideas amount to saying that developers should work on the node software in addition to doing some other work. This doesn’t really solve the key issue at hand, and it misaligns the incentives of developers. They end up forming companies to build things like the Liquid network which have harmed Bitcoin in a not insignificant way.
The third option is to explicitly charge a mining fee to produce blocks for the Bitcoin Cash network. There is a lot of contention that this is a bad idea for a variety of reasons. The two main reasons are the argument that it is (1) coercive, and (2) produces a centralized organization controlling BCH.
Setting aside the point of coercion briefly, it is economically sound in that it aligns the incentives of developers with that of the network. However, this does not mean that it is a good idea. The point of centralization still stands. Whichever centralized authority controls these funds would have a significant amount of power over the Bitcoin Cash network and its future. This problem can be addressed by invoking a distributed consensus mechanism to decide who gets funds. Nakamoto consensus can work very well for this purpose.
Now, the original proposal, which was a soft fork, had a large cartel of mining pools refuse blocks which did not include payment to a development fund. However, this created a situation where these miners risk ending up in a minority fork and unable to sell their block rewards. This risk has caused the proposal to be amended to be a hardfork, with all nodes validating that the mining fee exists.
In the proposal becoming a hardfork, distributed consensus was removed, and developer consensus was emplaced. This is not a good idea where it can be avoided. This alone would make the proposal a bad idea that should not be implemented. With the issue of this proposal being a bad idea now settled, the question as to if the proposal is coercive remains.
Currently, the software pays only miners to run it. However, individual miners and pools are economically disincentivized to fund developers. Any additional overhead takes away from their ability to re-invest in their own mining farms and continue to compete with other miners on level footing. As such, miners have not been funding development at a level required to maintain software as complex as Bitcoind. The only way in which funding development makes economic sense for miners would be if they all had to fund it together. This situation is equivalent to the public good game. https://en.wikipedia.org/wiki/Public_goods_game
Yet, by making developers also profit, from the node software, their incentives become aligned with miners. An explicit incentive is created for developers to build what businesses need and what will bring value into the Bitcoin Cash network. No such incentive exists, except for the price increase in whatever coins they may have purchased themselves.
Yes, sending some of the block reward back to developers comes at the expense of some security. It will lower the total security that is being demanded of the entire SHA256 pool. As such, it comes at the expense of every SHA256 mining group. It makes sense for most miners to oppose such a change as it cuts into their profit margins. Most miners have no inherent loyalty to Bitcoin Cash – they mine what is profitable.
However, labeling this proposal as “coercive”, or a “tax”, is far from true. Miners are entitled to run whatever software they want, but they do so knowing what that software does – and that may be a different reward structure than they would like. The fact that the node software will no longer demand as much SHA256 hashing is far from coercive. Actually, the opposite is true – demanding that the developers of Bitcoin Cash write software that continues to buy, the same amount of SHA256 security, is coercive.
This is visible when considering what is actually required of each ideological party in this disagreement. Opposing the mining fee involves demanding that developers NOT do something. Whereas, if developers new version of the software that refuses to validate blocks that don’t pay them it is completely up to miners to choose to run that new software or not. There is only a demand being made of one group of people: developers.
In fact, this proposal was originally discussed in Hong Kong in June of 2018. A meeting was held with some of the largest miners that were participating in the development of Bitcoin Cash. At that meeting, the only miner which in opposition was nChain/Coingeek – a company which was concurrently trying to deprive ABC of funding, and become the sole source of funding, so that it could control the future direction of Bitcoin Cash.
Now, the voluntary nature of the mining fee does not return this proposal to good standing. In creating centralized governance, it would create a single point of failure for the Bitcoin Cash network. No one development group should be making decisions about what is funded. It is incredibly important that choosing where funds are allocated does not require centralized coordination.
Therefore, I am proposing the following change to the proposal to add a development fee as such:
Initially, the node software will be seeded with a whitelist of acceptable donation addresses for Bitcoin Cash node implementations.
The software will then validate that the coinbase includes UTXOs that pay a total of 12.5% to a combination of this whitelist.
If any additional address appears within some threshold of recent blocks (e.g. 90% of the last 2016 blocks) that address will be added to the whitelist by the node software.
In this way, miners who want to redirect funds to a different development group can do so by donating a small amount – above and beyond the 12.5% – to a new organization over the course of two weeks. After that time, the address would be counted within the total 12.5% and the miners who wish to donate to that address could return to their normal profitability.
Additionally, this provides a mechanism whereby a supermajority of miners can turn these consensus rules off by adding their own addresses to the whitelist. As such, these consensus rule changes do not need to be temporary for the purpose of trying them out. Miners can, if they so agree with each other, turn them off at any point.
If the proposal is amended in this way, I would be very happy to see it implemented and give Bitcoin Cash a fighting chance with continued development and improvement. Bitcoin Cash is the most important project, for human freedom, in the world. Supplying proper funding for maintenance, and improvements, are of critical importance. Establishing funding, in this way, is aligned with the belief that increasing human freedom increases human prosperity.
@micropresident
