@im_uname

@im_uname 20 December 2022

dark mode good

@im_uname 17 December 2020

An overview of Bitcoin Cash consensus upgrade schedule possibilities, and a recommendation Current Situation Since November 2017, Bitcoin Cash has persisted on a schedule where consensus rules are changed every six months, once in May and once in November every year. This schedule was enforced by a mechanism called "Automatic Replay Protection" (ARP) a.k.a. "the poison pill" in the formerly popular full node client, Bitcoin ABC. At the upgrade date, any node that has not been upgraded and has the poison pill code will silently split to a new chain through a mechanism called forkID. Self-poisoned mining nodes would silently stop mining on BCH and start mining a new chain that no one has any intention of using. Non-mining nodes would similarly start silently accepting transactions incompatible with the BCH chain. Expiration is postponed every six months, by pushing the date forward in a new major release. As a consequence, every six months users face a choice: Upgrade to the new version and adopt new consensus rules; do nothing and automatically follow a chain, if mined, that is incompatible with the entire ecosystem; or edit the code and recompile, in order to persist on current consensus rules. Bitcoin Cash Node (BCHN) inherited the higher level idea of this mechanism, but changed it to a user-configurable simple warning and shutdown to prevent accidental loss to mining pools and exchanges. On May 15th 2021, we will once again have a mandatory scheduled upgrade at least for the BCHN client, and we have a choice to make: Where do we take it from here? Problem Statement The periodic expiration mechanism, whether implemented punitively as seen in Bitcoin ABC or in a more straightforward fashion as seen in BCHN, has so far succeeded in its low-level intended effect. Every six months, almost all actively used nodes have changed their consensus rules, be it following the majority or splitting off with separate consensus rules. Almost no economic activity has followed the "old" consensus through any of the upgrades. The higher level impact on the ecosystem, though, has been a mixed bag. On a practical level, having to adapt to changing clients and consensus rules every six months have been a significant burden for services and merchants looking to adopt BCH as a usable medium of exchange. Exchanges such as Coinbase, service integrators such as Bitcoin.com as well as software developers have voiced concerns that a six month schedule imposed a high cost of operations. More importantly, every upgrade introduces a focal point of vulnerability, where it is possible for differing opinions to become wedge issues that result in irreconcilable splits , greatly lowering network effect at worst, stalling progress and lowering reputation of BCH at best. In theory, longer periods of research, analysis and presentation beyond the six-month cycle should have been able to converge stakeholders towards one set of consensus upgrades. However, in practice, the community only pays attention to the next set of changes after doing the work from last one, and not nearly enough time has been spent on consensus building. This presented opportunities for influential figures to attempt ramming through their favorite changes without considering costs, both economic and social, to the wider ecosystem. As the community moved from one crisis to the next punctuated at six month intervals, even the more baseline testing and analysis were not performed adequately, not to mention consensus-building efforts that are essential to having a majority in a decentralized network agree or reject changes in an informed way. The results can be seen through the most prominent splits over the past three years, the BSV fork siphoning significant value from the chain, while the ABC fork stalled adoption and damaged the chain's reputation. Even for upgrades without a significant split, major bugs have been introduced through ill-tested changes, resulting in loss of function that is unacceptable for a major cryptocurrency. While it may be convenient to blame specific groups of actors for these woes, there is much room for improvement in the schedule and process themselves, so that they are less vulnerable and more confidence-inspiring in the future. A better schedule that allows for more research and consensus building ensures that even in the worst case, the community and chain can steer away from the chaotic scrambles we have seen in the past. Considerations While the downsides of scheduled upgrades seem quite apparent, we must not ignore its benefits. To achieve its goal as peer-to-peer electronic cash for the world, Bitcoin Cash still has at least a few functional and scalability changes ahead of it that require significant development work. Without scheduled upgrades and corresponding expiration as enforcement, even uncontroversial upgrades can face significant hurdles to adoption, especially among exchanges who are apathetic about Bitcoin Cash. While protocol ossification can be a good thing for stability at high adoption, without a sensible path to useful upgrades, usecases that are necessary for adoption may be bottlenecked on the way. Even if no consensus changes are adopted during any given period, the path to upgrades must be left open by process and precedents. To balance between the needs for stability and beneficial upgrades, it seems wise to at least relax the existing six month schedule, so there is more time for research, consensus-building, and testing. Possible Alternatives to the 6-month upgrade cycle One-year cycle Description: Existing expiration mechanism is kept as-is, but the cycle is extended to 1-year after May. Upgrade dates are May 2021, May 2022, May 2023 and so on. Benefits: 1. Most conservative extension possible, easy to understand and converge on. 2. Expiration mechanism will still ensure inertia isn't a major factor when upgrade date comes. 3. One year should allow for significantly more time to debate, research and build consensus than six months. Note that hard forks intervals are on average longer than one year even on Ethereum, a chain much more experiment-friendly and has more resources than BCH. Costs: 1. One year is a long time in crypto, there may be parties with specific needs who would like their features in sooner. 2. While a one year cycle should allow significantly more time for research and consensus building, controversies can still arise. It must be noted that having a schedule does not equal having proper decisionmaking processes, which is a separate pressing issue not explored in this writeup. At the very least, proposals for an upgrade should publicly make it to various milestones along the cycle, with expectation that it can be rejected by the community at any point. Various longer cycles (18 months, 2 years, 4 years...) Description: Same as the above, but extend the cycles even longer. Some very long cycles seek to mimic political cycles in modern democracies. Benefits: 1. Longer cycles allow even more time for research and consensus-building to play out. 2. Long cycles can minimize time spent in periods of uncertainty, inspiring confidence for businesses and investors who seek stable foundations for their enterprise. Costs: 1. Technology in cryptocurrency moves rather quickly. While its larger sibling BTC can spend multiple years debating even less consequential upgrades like Taproot, BCH does not have the luxury of expecting existing network effect to carry it through very long periods of time. If necessary usecase and scability improvements are delayed for too long, the chain can lose its competitive advantages and become irrelevant. 2. Over a longer time, the infrastructure, processes and social will necessary to even evaluate new proposals will likely deteriorate. 3. If even uncontroversial upgrades are subjected to a multiyear wait before activation, the long schedule may paradoxically cause damaging community and network splits. No schedule Description: Remove the expiration mechanism altogether from all clients, and substitute with a yet-undefined process of consensus building that culminates in an upgrade date "when it's ready". Benefits: 1. Given a sufficiently convincing process, may be the best way forward. Proposals would not be subject to undue "make it or wait another year" deadlines, and can proceed at an optimal pace in research, implementation and consensus-building. 2. Default mode of operation for some of the biggest coins like BTC and ETH. Costs: 1. We do not have a fully convincing process to decide when to "seal the deal" on any upgrade yet. While many parties in BCH including BCHN are committed to developing a long-term solution to decisionmaking, no mature and robust process exists right now. Proposals of miner voting, stakevoting and other decisionmaking schemes of various sophistication abound, each with glaring pitfalls and tradeoffs that need time to be worked out. None are likely to be available in a sufficiently convincing manner for May 2021, before which a decision will need to be made. 2. Without a robust process, going no-schedule in a decentralized landscape can easily stall uncontroversial and beneficial upgrades indefinitely, resulting in similar or worse woes as a long cycle. It will also be impossible to set expectations on progress for any given proposal, making conflict over how "ready" a proposal is more controversial. Having a defined schedule to evaluate proposals makes worst-case long-term stagnation less likely while better processes are being researched and refined. Recommendation: One year cycle While each of the above has its benefits and costs, I recommend going with the simple one-year cycle. Going no-schedule may be an appealing idea to many, and it will likely become quite attractive to me as well once we have a robust decisionmaking process in place. For now, however, the twin risks of stagnation and controversy are simply too great for a network looking to regain its standing. Between one year and much longer cycles, the benefit of a minimal one-year change can be seen as a matter of balancing. While the drawbacks of a short six month cycle is apparent by now, we should not ignore that it did also bring us some beneficial upgrade items in time, such as Checkdatasig and ASERT DAA. Extended to a year, the schedule should allow reasonably ample time to research, implement and build consensus for each upgrade, while investors and developers can still look forward to a close horizon for new features and scaling improvements. Intra-cycle milestones Between each upgrade, it is important for consensus change proposals to follow certain milestones to maximize chances for orderly inclusion or rejection. Unless faced with extraordinary circumestances, missing them should result in the proposal being rejected for the next upgrade. One possible setup is: **May 15th**: Previous upgrade activation day. Proposals for next cycle should already be under work and/or circulated. **July 15th**: Proposals for the next upgrade should be published by this date, complete with draft-BIP style technical description, economic cost/benefit analysis and preliminary surveys among prominent stakeholders in the ecosystem. **September 15th**: For proposals that were published and did not result in major controversies, functional implementations from at least one full node client should be available by this date. After this date, the implementation should then be subject to testing on a separate testnet fork, evaluating impact on popular applications and services. Technical reports from tests should be published and circulated among major ecosystem actors for feedback during evaluation. Proposals that face strong opposition from prominent businesses, stakeholders, miners or face significant, high-level technical difficulties should not be considered for November lock-in, but instead seek to alleviate concerns in time for the cycle after. Note that a given proposal MUST have spent reasonable effort in actively contacting major ecosystem actors when evaluating reception, instead of assuming consent from parties who did not respond to broadcast publications. **November 15th "tentative lock-in"**: If the one-client implementation of said change is sufficiently evaluated and still did not raise major controversies or inadequacies, by this date there should be more than one full node team that implements the change. Specification for the change should be finalized by this date as well. Node teams should begin to produce production-ready releases for their users to upgrade early. Wider testing commences, applications are encouraged to start developing for the new features on upgrade testnet. Note that proposals who made it to November 15th should be considered tentatively locked in for implementation across the ecosystem. **February 15th "lock-in"**: If no major bugs or emergencies were found during wider testing, all full node implementations are expected to deliver a compatible production release by this date, or cease to be recommended for BCH. Stronger push for upgrade throughout the ecosystem. **May 15th**: New upgrade activation date. Expectations on no-op "upgrade days" A regularly scheduled upgrade, and enforcing expiration mechanisms, are merely convenient Schelling points to have orderly consensus changes. They MUST NOT be seen as mandates for having *at least some* consensus changes, and indeed simple extensions of the expiration mechanism without consensus change, leaving upgrades to the next cycle, should be an acceptable outcome for any given cycle if no proposal can get wide agreement and robust testing by the aforementioned milestones. Recommendation for May 2021 If a one-year cycle is adopted, May 2021 becomes a special case as it is a much shorter cycle than subsequent ones. While there are uncontroversial ideas such as longer integers, along with some more controversial plans, no proposal is even close to gaining sufficient rigor in specification, wide implementation, testing and consensus-building. It may be tempting to incorporate less controversial consensus changes for this cycle only, to get their benefits before a rigorous, longer upgrade cycle truly begins. I will strongly recommend against that act, though, as BCH desperately needs to regain a semblance of stability, and making exceptions out of a process before it begins does not inspire confidence. In contrast, establishing a no-op "upgrade cycle" reduces future pressure to rush unfinished proposals for the sake of having *some* change for an upgrade. **As such, I recommend that BCH do not implement any consensus changes for May 2021.** There are nonconsensus changes, such as longer unconfirmed mempool chains, that need coordination but may not require as stringent a process, as they cannot result in a chain split. This recommendation should not be seen as a discouragement towards implementing them this May. Future changes As mentioned, it is quite possible that we can eventually converge on a much more robust decisionmaking process than scheduled upgrades, and indeed some are being actively explored even now. When such a process emerges, it should be subject to the same schedule, milestones and rigor as other proposals, and upon activation the existing schedule is abolished in favor of the new process. Thanks for reading! I also created a discussion thread here: https://bitcoincashresearch.org/t/an-overview-of-bitcoin-cash-consensus-upgrade-schedule-possibilities-and-a-recommendation/235 Edit: Typos and formatting oddities

@im_uname 11 November 2020

My AMA with Hoo.com, 2020/11/11 *Below is a direct copy and paste from the AMA (Ask me Anything) session I had with Hoo.com on their Telegram channel on 2020/11/11, going as a contributor to general BCHN efforts. Much thanks to Saiho and Xuxin from Hoo.com, and our very own Tracy Chen for arranging the event.* *-----* **Saiho Liew:** **Welcome! Thanks for being with us. Can you please tell us a bit about your background and how did you get involved in crypto?** **im_uname:** I'm imaginary_username, and I coordinate things at BCHN ("Bitcoin Cash Node"), run many pieces of BCH infrastructure, and contribute to general theoretical and design work in various BCH fields. I got involved in Bitcoin back in 2014 after getting interested reading Mt. Gox's collapse, and has been interested in using bitcoin as peer-to-peer cash ever since. https://bitcoincashnode.org/members/im-uname **Saiho Liew:** Great！:+1: **What are some of the key features of #BCHN and how is it something entirely new or an enhancement to an existing solution?** **im_uname:** BCHN is derived from Bitcoin ABC, which itself is derived from Bitcoin Core. People probably already know the core difference that led to the code split: We do not agree ABC's action of baking a payout for themselves directly into the protocol. We have since made many unique improvements, in terms of a better DAA to ensure more consistent blocktimes, performance, and testing infrastructure to pave way for scaling and protocol improvements. **Saiho Liew:** Thank you for sharing that with us.:grin: **What’s your plan in place for global expansion, are BCHN focusing on only market at this time? Or focus on building and developing or getting customers and users, or partnerships? Can you explain this?** **im_uname:** I'll need to first clarify that BCHN is a full node team, BCH is a decentralized cryptocurrency and many parties (for example, bitcoin.com) are involved in promoting usecases for it. That said, my personal thoughts: BCH has in its genes from the beginning to push adoption, adoption, adoption; that should not change going forward, and we'll get a renewed chance now that destructive actors are behind us. Adoption does not just mean "make this coffee shop accept BCH", though we have many people on the ground pushing that too. It must also mean financial smart contracts - not of the ETH kind, but uniquely bitcoin UTXO flavored - more convenient onramps, offramps, and more. **Saiho Liew:** **What are the ways #BCHN is generating profits/revenue to maintain your project and with is its revenue model? How can it benefit in a win-win situation for both investors and the project?** **im_uname:** I would say investors paying to maintain and upgrade infrastructure directly benefits the value of coins they hold, so it's our job to persuade them on that fact. In fact we've seen the rise of Flipstarter, a crowdfunding platform that facilitates that; but there is much more work to be done in making more people aware of the platform and projects, persuading them of its merits, and improving user experience. **Saiho Liew:** **What are your major goals to achieve in the next 3-4 years?** **im_uname:** A lot of the well-known scaling work that'll enable us to process many more transactions have been stalled over the past couple years as contributors were discouraged due to ABC's management style and combative stance on funding; we plan to address them and fulfill BCH's starting promise as bitcoin that scales. Additionally, work that benefits usecases (such as doublespend proof and script improvements) are also under research and construction. It's important to note the real goals - global adoption - must reached by businesses and users of the coin. Node developers can only strive to make their work easier. **Saiho Liew:** Great！ **What killer features of BCHN make it unique from other similar projects?** **im_uname:** For the full node itself, I would say that we have a codebase that is closer to Bitcoin Core than our peers, making it easier to share improvements or fixes; but above that, BCHN strives to make each change evidence-based and well-surveyed, instead of making rash decisions based on just one or a couple people. You can expect us to produce relatively stable software while we keep making improvements. For BCH: Permissionless, affordable, useful money. It'll only get better. **Saiho Liew:** Next！ **What do you think about the current situation of BCH? Has it been the way you first thought it would be?** **im_uname:** It's certainly been a bumpy few years, with people who crown themselves "founders" of one thing or another keep wanting to grab money from the protocol, causing lots of damage in the process. I think it's only going to get better, though. **Saiho Liew:** **On the path to BCH expansion, what are the biggest challenges? Do you have any insight on how this should be implemented?** **im_uname:** The biggest challenge is getting usecases and users: We have a lot of capacity right now without accompanying business volume to fill them. Going BSV and filling the chain with garbage is not the way to go either. Business adoption and applications that makes use of significant volumes of BCH have to be the main driver, and past instability definitely did not help. Having a culture of reasonable discourse and not making rash decisions, I think, will help a lot. We have explored quite a few ideas on improving communication and making sure stakeholders have more voice, which we'll be developing and rolling out over the next months as well. **Saiho Liew:** Awesome:+1: **In your opinion, which is the core of BCH, the user, the developer or the miner?** **im_uname:** All of them! None of them can really survive without the others. If I have to pick someone though, I would say the long term investors. Other actors come and go, but those who put down their money ultimately shape where the coin goes. Note that users, businesses, developers and miners are often long term investors too! **Saiho Liew:** They're all an important part of it.:muscle: **And How do you feel about IFP?** **im_uname:** Just say no. **Saiho Liew:** **Could you briefly explain what has caused divisions of opinion in the BCH community，and how BCHN differs mechanically from the original BCH？** **im_uname:** I need to repeat, BCHN is an implementation of BCH full node, and there's no separate "BCHN" coin. So there's no such thing as "how BCHN differs from BCH". **Saiho Liew:** Okay！The last question!:blush: **It is known that computing power can determine which chain is more powerful. Then currently what percentage of the computing power in the BCH network does a BCHN node obtain?** **im_uname:** Last time I checked, blocks signaling BCHN are 80% over the past two weeks and rising. Compared to the 0.1% of ABC, it seems like we have supermajority support. **Saiho Liew:** Alright:+1: Thank you,Sir. That’s all for the AMA today. Thanks for your participation. Thanks for your time.🤝🤝 We have to close the AMA now. For more info about BCHN, visit their website: https://bitcoincashnode.org/

@im_uname 26 August 2020

Protocol upgrades: A simplified, practical guide Protocol upgrades in Bitcoin Cash have often been subjects of controversy. I hereby suggest a very simple framework from which people can evaluate which changes are worthy, so that we can all get on the same page next time. "Benefit" and "Cost" refer to ecosystem-wide, all-things-considered benefits and costs, including but not limited to such aspects as developer retention, capital retention, development cost, network retention, miner cost, software upgrade burden, security, reputation and so on. If there is no widespread agreement that a change is at least not harmful, its benefit should be described as "uncertain".

@im_uname 28 January 2020

A stronger case for voluntary investing in public works My previous post about how assurance contracts improve the situation of contributors and investors in public goods sparked some interesting discussion. Specifically, people asked: "What if you think a thing can get funded without you, and you can get to profit the most if you position yourself right? https://read.cash/@im_uname/voluntary-investing-in-public-works-with-or-without-assurance-contracts-82d5b36a To illustrate this thought, consider a simple assurance contract. We do not consider either barebones contributions nor dominant assurance contracts, as they are not directly relevant to the calculations here. Your goal when considering whether to contribute, should always be moving from bottom right to top left. Assurance contracts simplify your considerations since you no longer have to worry about top-right. "*Wait, im_uname! Sometimes if I think others will cover it just fine, maybe I can get away with bottom-left!*" This is where you are wrong. You are especially wrong in cryptocurrency, a very young field where every imaginable thing on every facet needs people to work on. Consider there are two projects, A and B. Someone else contributed to A to make it happen (arrow 1), you did not, *and* think you can get away with it: Congratulations, you are now in bottom-middle, and you seem better off! But wait... *You can profit* ***even more*** *by also contributing to project B where you can make a difference (arrow 2).* **There will always be a Project B lying just ahead, where you can make a difference.** **One does not simply run out of things to contribute to and make a profit.**

@im_uname 27 January 2020

比特币现金基础设施资金：现状与建议 本文将总结一些我个人的见闻与想法。我很有可能不清楚相关的幕后情报，也有可能在认知上有偏差，请多担待。 以下為比特币现金基建目前面对的挑战，以及一个可能的解决方法。 英文原文，同一作者手动翻译 https://read.cash/@im_uname/assessment-and-proposal-re-the-bitcoin-cash-infrastructure-funding-situation-3e5179fc 问题现状 比特币现金的价值主张有赖于她作為一主要、可靠、完全开放加密货币的地位，并在这之上能扩容以满足社群大规模推广的需求。这样的主张在全节点及开源钱包上，对她的软件有著以下的需求： **1. 可靠，经过充分测试，勤于维护，尽可能做到无漏洞的软件** 软件如果少人维护，时间一长就会被发现漏洞：即使品质极好的代码，当运行环境逐渐改变，攻击工具推陈出新时，也无法幸免。我们至少得有一队技术高明的维护员来保障链上的安全，并且不应该认为他们会给我们可持续地无偿劳动。 **2. 支持新用例及安全扩容的功能** 比特币现金在主要加密货币中处于相对新创的地位，必须不停地创新及获取新用例来取得网络效应。举一例子，2018年末新增的OP_CHECKDATASIG 支援了眾多新型智能合约，目前仍在开花结果。当用例越来越多，我们就得增加支援扩容的功能，让安全、每秒成千上万笔交易的扩容不只可能，而且不牺牲其他吸引人的性质。 比特币现金目前的开发路线图中，除了Avalanche以外大抵都是相对成熟的科技。即便如此，要安全并可靠地实现必须要有高端的人才，而这些人才非常昂贵。 有时这些人才出于兴趣或理念会志愿帮忙，但因為市场上对他们的需求实在太高，这些志愿者往往不可靠。我们可以讨论需要多少资金，但不能接受"不需要资金"的立场。 这些开发者的努力对链上的所有人都有好处，尤其是比特币现金的持有人们 - 网路越好用、越可靠，币价就更有潜力。但在这付出劳力的人常常很难获得直接的报酬，所以实际上做的人很少。 我们真得付钱吗？ 有些人认为我们压根就不必付钱，自然会有志愿者帮忙，而他们就足够了。这些人有不少也认为软件只要有一定的维护就行，很长一段时间既不需要新用例，也不需要扩容。若是落到了这地步，比特币现金或许能够生存，但对达到能大规模推广开放货币的目标，恐怕并不乐观。 何以只付给某些人？ 现在大多数的讨论都集中在Bitcoin ABC节点团队上，有时有些人会纳入Electron-Cash开源钱包以求多样。但我认為我们得实事求是，这些讨论的重点仍是Bitcoin ABC。 即使我们主观认為资金可能可以有多种用途，其他用途最后还是得以Bitcoin ABC的需求為优先考量。 啥？！ 从风险管控的角度上看，比特币现金的生态圈非常仰赖Bitcoin ABC，以至于很难拒绝团队的资源需求。如果这些需求不能得到满足，团队就有可能解散或造成很大麻烦，这是我们不能容忍的。 Bitcoin ABC的竞争者们要不是不成熟、不能提供安全的挖矿环境(BCHD, Flowee, Bitcoin Verde)，就是有不良的过往纪录、在矿池间有无法满足需求的风评(Bitcoin Unlimited)。我们得了解一项现实：只要我们希望继续有效地维护及改良链上的核心软件，又不愿意投入更多人力物力来支持大家都可接受的竞争者，这情况就会持续，*总有人得付帐的。* 或许这对于生态圈的多样性是一个不好的情况，但眼下，我们总得解决迫切的需求。 **之后我们可以做许多事来改善这情况，但现在不行，形势太紧迫了。** **我们不能继续装聋作哑。** 好吧，我了解总有人得付帐了。谁付？ 首先，谢谢您读到这。 以下是一些可能的资金来源： 商业投资 **Bitcoin ABC 成立公司，承诺一定的收入及回报，从投资人手中获得资金** 在币圈采此法最有名的莫过于Blockstream (BTC) 及 Parity (ETH/Polkadot)。这模式有明显的问题：公司获利的模式不见得与链上生态圈一致。时间一长，公司的地位稳固了，就难以取代，并会开始向其他成员肆意寻租。这在公司角度没什么不对，但往往对整个生态圈有害。 商业赞助 **Bitcoin ABC 从链上多个营利公司收取赞助，并优先提供技术咨询及问题交流** 此模式常被称為"Linux基金会模式"，大抵被认為是一个优良的解决方案。但这方案的前提是链上得有许多已获利的公司，才能有余裕赞助。比特币现金目前的情况并不容许推行这方案。 矿工赞助 (志愿) **Bitcoin ABC 从矿工及矿池处收取赠款，矿工们为了长期的发展，应该捐助** Bitcoin.com 矿池已经小规模实施此法有一段时间，同时作為主要矿池及拥有一些算力的比特大陆也常被人认為给Bitcoin ABC提供了许多资金。 若我们从职业矿工的角度考量，这确实很难接受，因為矿工的净利常常已经够低了。不把利润再投资的矿工会在激烈竞争中被抛下，市场份额会缩小，这是不可免的。 更重要的是，矿工的动机往往与我们的需求不一致：SHA256矿工的收入目前绝大多数来自BTC，若不是对BCH的未来有憧憬，实在没有太多原因关心BCH的开发。 矿工税（强制） **Bitcoin ABC 的合作矿池以算力为后盾，排除不合作的区块，从实质意义上修改协议，让每一块的新币都有一部份直接或间接交给团队。** **此为目前争议中方案的实质内容，不同版本细节可能有别，但不影响讨论。** 这方案认为我们为了解决"搭便车问题"，必须强制所有矿工交税; 同时，几轮难度调整后，费用应由全体SHA256矿工承担，对"BCH矿工"的负担将只与BCH/BTC相对价成正比。 有些矿池同时也认为这方案有助于解决目前BCH算力及出块时间波动太大的问题; 这想法是不对的，因为不论机枪池的占比多少，交税的总额并不改变。要根本解决此问题，只有提高BCH的相对价，而此方案可预见带来的社群分裂及形象问题对此并无助益。 更重要的是，此方案将改变BCH的根本性质：从一完全开放的公链，转型成在协议中瓜分部份新币导入特定人士手中，性质暧昧的半私链。 有些人可能认为这是为了生存，迫不得已的方案。但考量到长远的推广、投资和吸引人才需求，我们并不真的了解它到底合不合算。从今以后，BCH将以"少数几玩家私营操纵"为人所知，即使六个月后真能如期结束，这形象也无法消去。 同时，矿池以算力强制重新分配币，对于开放防审查的特性将作非常不好的示范; 越来越多的人将会对BCH生疑，不知道同一拨人是不是能对链上的任何币、任何交易收税，只要做好了公关，就百无禁忌。 话虽如此，大老们愿意正视开发经费问题，即使方法存疑，还是很值得赞赏的。 持币者赞助 **Bitcoin ABC 从持币大老们获取赞助，经营基建，以利币价维持及上升。** **赠款可以直接支付，也可通过****Assurance contract****、****Mecenas****定时付款等智能合约进行，或其他总总更细致的操作。** https://en.wikipedia.org/wiki/Assurance_contract https://github.com/KarolTrzeszczkowski/Mecenas-recurring-payment-EC-plugin BCH持币者是网络维护及升级的最大受益人，这是不争的事实。单就此一论，让项目的最大受益人给项目买单，实属应当。 这方案有一很大问题：比特币现金设计上来说无法从持币人手中收费，若非持币人同意，几乎不可能强制执行。但就动机上来说，其实要说服持币大老并不困难。 只要他们的赠款金额低于开发团队给他们带来，算入风险的币价增值，持币人每人都有独立的出资动机，有无搭便车行為无关紧要。持有的币数额越高，就越合算，甚至不需要与他人合作，独自出资也有赚头。 若是在持币小户之间推行，此方案有一明显问题：如何确保合作？大户可以单独资助像Bitcoin-ABC之类的大项目，小户可能担心若他们投了钱，但最后金额不达标，项目就无法有效推展，已投的钱就一去不返。 这问题可由Assurance Contract解决: 远在比特币现金分叉之前，Mike Hearn的Lighthouse项目就已实现了原型。有了这种合约，赠款不达标，就不会放行，所有操作都在链上，不需要信任第三方。社群里有能在数日之内打造出基本机制的人才。 有人可能提出:一次性的赠款可能导致开发团队的动机不一致，收款后并没有动力继续劳动; 此顾虑可由BCH链上已开发成功的Mecenas智能合约解决，一笔赠款，分期送抵。这合约也能与Assurance Contract合并执行。 考量因素 1. Bitcoin ABC 可能与某些持币大老们有沟通上的矛盾，可能影响大老投钱的意愿。改善他们的关系将是关键。社群成员有可能需要更积极地协助沟通，营造友善的氛围。 2. 大老们可能有对"搭便车问题"过度的顾虑。这点上我认为给他们展示投资的直接好处非常重要，与搭便车并无关系。在这之上，币圈的生态与其他社群不同，即使是"搭便车"的人们也能增强网络效应，对投钱实属有利无害。 3. 若团队能将路线图上特定的项目独立出来，解释对推广及币价的价值，就更有利于说服资方。 建议方案 只要六个各有十万BCH的大老各出一百万刀，每人出约3%，矿工税的数额就可以满足。 **他们每年都可以重复投钱，数年后仍然大赚。** 参加的大老们人数越多，投钱的回酬率就越高，而且"搭便车"行为并不影响回酬。 让我们来草算一下。若您持有十万币，每年投一百万刀。极保守估计，此投资所带来的扩容及升级可靠性可于2025年让BCH市值达到今天以太坊的水平。投资当然有风险，但考虑到另一方面升值的潜能极大，我认為此估计并不为过。 让我们考虑另一情况：您今天不投钱，项目倒了。时间一久这链可能因缺乏维护而垮台，也有可能社群找到了新的、难以预料的价值主张。我们乐观些估计，BCH做为一难以成长的储值币得以生存，币价与联储局的2%通涨率连动: 我相信明眼人对两情况的分别应该很容易理解，与"搭便车"并无关系。 本人认为付款可以每六个月更新一次，以Mecenas智能合约分月付款给Bitcoin ABC或指定的代理人。如果收款方因任何原因无法接收，一定时间后可以退款。 在Mecenas合约之前，我们可以用简单的SIGHASH_ALL|ANYONECANPAY方式建造Assurance Contract，向投钱方以全或无的方式筹集一定金额。社群可以向有兴趣的持币人提供工具，让他们可以私下合作，并可选择将募款进度公开显示，或私下计算。最终交易要待金额足够后才有效，上链后Mecenas分期即可进行。 Bitcoin-ABC有义务在每期更新之前公开展示成果。

+2 more

@im_uname 26 January 2020

Voluntary investing in public works with or without assurance contracts Without assurance contracts: https://en.wikipedia.org/wiki/Assurance_contract With assurance contracts: With Dominant Assurance Contracts : https://en.wikipedia.org/wiki/Assurance_contract#Dominant_assurance_contracts *Note that you can mimic dominant assurance contracts even without a risktaking entrepreneur by offering benefits for pledges, such as good publicity for partaking in an assurance contract.

+1 more

@im_uname 26 January 2020

Assessment and proposal re: the Bitcoin Cash infrastructure funding situation Edit: There are now Spanish, Arabic, French and Chinese versions. Thanks a lot to the translators! https://read.cash/@CryptoSpanish/evaluacion-y-propuesta-la-situacion-del-financiamiento-de-la-infraestructura-de-bitcoin-cash-8fc1cf71 https://read.cash/@arslankhalid/tkyym-oaktrah-eaaad-odaa-tmoyl-albny-alasasy-laaml-albytkoyn-2d7565c9 https://read.cash/@lugaxker/evaluation-et-proposition-en-reponse-a-la-situation-financiere-de-bitcoin-cash-ade37e56 https://read.cash/@im_uname/-e91c8cb2 The following is a summary of what I have seen and thought both in public and in private. Vast amounts of under the table arrangements may exist outside of my knowledge. My opinion may be biased in any number of ways. In this writeup I attempt to describe the challenges we face and recommend a path forward. Problem description Bitcoin Cash has a value proposition as a major, reliable permissionless cryptocurrency that can scale for mass adoption and aims to achieve said adoption aggressively. Such a mission require the following from its software, including both full node and other essentials such as an open source wallet: **1. Robust, well-tested software that is kept up to date and free of bugs to the best effort.** Contrary to what some might think, software does rot if not maintained as bugs are discovered and unfixed, new problems arise from developments in their environment, and new exploitation tools are revealed. At a minimum, a crew of highly knowledgeable maintainers are needed. We cannot expect them to work for free in a sustainable fashion. **2. New features that enable usecases and aid scalability.** We are in an upstart position. In order to gain network effect, new usecases are very desirable. A prime example is OP_CHECKDATASIG and the host of new smart contracts it enables. And then when we get those usecases, we will need features that enable us to scale to thousands of transactions per second safely without sacrificing other desirable qualities. Most of the items on Bitcoin Cash roadmap are not cutting edge technology with the exception of Avalanche. Still, implementing them safely, in a demonstrably robust way, requires talent that is often very expensive. While such talent sometimes volunteer themselves, such volunteering can be unreliable due to the sheer fact that lucrative opportunities exist for them. One may debate the level of funding required, but it is difficult to argue that no amount of funding is required. These efforts benefit everyone on the network, particularly coin holders who see an increase in their asset's value. However, it may be difficult to extract direct, targeted and easily quantifiable revenue from this effort, which is likely why few are doing it. Do we pay for it at all? Some may argue that it's unnecessary to pay anything and volunteer efforts are enough. Many of them may also think that it is okay to have software that is minimally maintained but without new scalability or usability features for a long time. That would be an unfortunate worst case scenario that is survivable but does not get us to global permissionless money. Why pay for one guy over the others? It seems like most of the discussion is focused on Bitcoin ABC, with Electron-cash sometimes thrown in for the sake of diversity. Let's be honest with ourselves, this initiative is for Bitcoin ABC. Any funds that could go to more purposes than the full node software will likely be applied at Bitcoin ABC's discretion anyway. Wait, what? From a risk management perspective, the ecosystem is in a position that compels it to fund whatever ABC requests, in order to mitigate the threat of them folding or otherwise having a significant disruption. Their competitors are either immature and objectively dangerous if used to mine (BCHD, Flowee and Bitcoin Verde) or unfavored due to a spotty record and perceived past unwillingness to serve miner demands in general (BU). It is important to realize that unless you are willing to go without maintenance and improvement for a long time, or willing to fund a competitor acceptable to most, the risk is present, and *someone gotta pay*. This is an unfortunate situation for the diversity of ecosystem and power, but we have to address the elephant in the room. **There are other things we could do to dig ourselves out of this hole in the future, but not today.** **We cannot look away.** Okay, someone gotta pay for it whether it's pleasant or not. Who is someone? Glad we got here! A list of potential parties who could do the funding: Direct Capital investment **Bitcoin ABC forms a company, promising returns, and investment funds give them money to work towards that goal.** This model is most famously used by Blockstream (BTC) and Parity (ETH/Polkadot). It carries an obvious problem that the business model of that company may not be aligned with the benefits of the ecosystem. As the company entrenches itself by dominating developer count and influence, it becomes increasingly difficult to dislodge them. It will then only be a matter of time before the company starts extracting rent, given companies naturally gravitate towards profitability and rent-seeking is an easy way to do it. Sponsorship **Bitcoin ABC receives contributions from multiple businesses building on Bitcoin Cash, and return their expertise and prioritize concerns.** Widely cited as the "Linux Foundation model" and a desirable state to be in, this model requires multiple businesses on Bitcoin Cash profitable enough to be willing to contribute. Currently there is a lack of such companies considering the early state and challenges the chain has faced since inception. Miner payments (voluntary) **Bitcoin ABC receives payments from miners who donate their own coins voluntarily, on the theory that this is good for the miners' long term benefits.** Bitcoin.com has been doing direct payments from their pool on a small scale, and it's been widely speculated that Bitmain, who operates significant hashrate in addition to its prominent pools, sponsored Bitcoin ABC even more substantially. From a purely miner perspective, this may be difficult to justify because miners have very thin margin. Miners who do not reinvest into their hashpower tend to get quickly outcompeted and shrink in size. More importantly, the fact is an overwhelming majority of miner income comes from BTC these days, and there is no strong reason for many of them to care about BCH development other than the belief of some about future upsides. Miner payments (mandatory) **Bitcoin ABC receives payments from a rule diverting a fraction of every coinbase to their account, backed by orphaning threats from de facto consensus rules.** **This is the essence of the current controversial proposal on the table, even if versions may have different details.** This proposal purports to solve the "free rider problem" by mandatory payments from every miner; it further asserts that as difficulty adjusts, the "cost" is spread across SHA256 miners, making the fund's cost to "BCH miners" only proportional to BCH price ratio to BTC. Some pool operators and miners also assume that this will help the current hashrate oscillation in BCH. The last assumption is certainly untrue, as total amount of the extraction is unmoved no matter the fraction of switch miners. Only a relative price rise against BTC can solve this problem, which is not helped by community fracture and a PR nightmare. More fundamentally, this proposal changes the very nature of Bitcoin Cash from an entirely permissionless chain, to one where part of the distribution is diverted in protocol to a few trusted party hand picked by a fraction of its mining pools. While many see it as an act of expedience and survival necessity, it is unclear whether this is a net benefit, especially considering long term adoption, investment and talent attraction implications where the currency is known as being privatized by a cartel. Such a hit to the chain's image is not undone even if, as the plan's initiators claim, it expires after six months. Furthermore, such a demonstration of hashpower-based redistribution of coins have serious implications on censorability of the chain, and one may question whether it becomes permissible for the cartel to levy taxes on any coin or any transaction as long as they have done the necessary public relations legwork. The fact that prominent actors are willing to address the funding issue head on, however, is still a positive sign. Holder contributions **Bitcoin ABC receives payments from a collection of major Bitcoin Cash holders who fund infrastructure to facilitate perpetuation and growth of their asset's value.** **The payment can either be direct, assembled via an assurance contract, time-release a la Mecenas, or any number of other sophisticated setups.** There is one reality that is unlikely to change: BCH holders benefit the most from network maintenance and improvements, due to the appreciation of their coins. It is natural, then, for the biggest beneficiaries of network improvements to fund them. Part of the difficulty, though, is Bitcoin Cash by design respects ownership of coins: It is much harder to confiscate confirmed coins than coinbase rewards. If a holder cannot be persuaded, it is impossible to coerce him into paying for anything. The holders, however, should in theory be relatively easy to persuade. As long as they contribute less than the risk-adjusted expected appreciation to their assets as a result of continued development of the full node, it is beneficial to contribute as an independent decision, regardless of any number of "freeloading" businesses and holders. This is especially applicable to large holders, who do not need coordination and can fund infrastructure projects by themselves and gain net profit through sheer asset appreciation. One consideration among holders may be the difficulty of coordination. While very large holders can fund large projects like Bitcoin-ABC by themselves, if coordination from smaller holders are necessary, they might be afraid that there's not enough commitment from their peers to co-funding, and partial payments out of their own pockets will be ineffective. This concern can be addressed by Lighthouse-style assurance contracts directly on the BCH chain. With it, all-or-none payments can be ensured. Talents exist on BCH where one-off assurance contract funding transactions can be constructed within a few days. If the concern is one-off payments may offer perverse incentives for the beneficiary, one may commit to schedule payment smart contracts like Mecenas, entirely onchain. It can even be combined with assurance contracts. Considerations Several considerations to keep in mind when drafting a proposal: 1. Bitcoin ABC, the expected main beneficiary of any proposal, may have harsh relationships with many coin holders, which affects their decision. Mending that relationship and making them see eye to eye is key. It may be necessary to convey ABC and holder concerns to each other diplomatically. 2. Big holders may have unfounded concerns about "free rider problem". It is important to demonstrate to them the direct benefits of their investment regardless of how many people "freeload"; in fact, cryptocurrency is a unique space in that "freeloaders" who use the chain add to network effect, hence amplify the investment anyway. 3. It may also be beneficial to frame investments in terms of specific improvements on the roadmap, so that their benefit to adoption and value is more easily described. Proposal Just six large holders each with 100,000 BCH can contribute $1 million each, 3% of their holdings each, and the mining tax proposal's amount will be matched. **They can do it every year and still come out with a huge profit**, assuming the scaling benefits propel BCH to match today's ETH market capitalization several years later. The more large holders join this proposal, the greater their returns vs investment - and it is profitable for them each regardless of how many "freeloaders" there are. On the back of napkin, (or Excel), let's make a conservative projection - if you're a 100k BCH holder, and you invest $1 million per year. The scalability and reliability benefits propel us to a conservative target of today's Ethereum market cap by 2025. We also need to account for risk, but let's say they are offset by larger upsides on the other side. Further consider that you just hodl, and the plan falls apart. The coin may collapse due to lack of maintenance, or it could adopt some strange value proposition that allows growth. Let's optimistically adjust to assume we stagnate as a store of value, and track the Federal Reserve's inflation target. The stark difference in returns should be clear, regardless of whether anyone is "freeloading". There should be a Mecenas contract that releases each six month's payments to Bitcoin ABC, or their designated agent, in monthly allotments. If the recipient does not collect said allotment some time for any reason, the funds can be clawed back after some time. The Mecenas contract should then be preceded by a SIGHASH_ALL|ANYONECANPAY partial transaction funding mechanism, with a target amount and the Mecenas contract address as output. A tool shall be provided for interested holders, coordinated in private, to sign partial transactions and either add and tallied to a public website or a private, trustless agent. The transaction is made valid once inputs exceed the desired amount, and scheduled delivery via Mecenas contract can begin. This process is repeated every six months. Bitcoin-ABC shall demonstrate progress publicly before each funding period, both in software and a brief explanation.

+2 more

@im_uname 30 December 2019

Trustless Token Collateralized Bitcoin Cash Loans @im_uname, 20191229, with inputs from @emergentreasons and Jonathan Silverblood Disclaimer: This writeup is a crude description of the idea, and should not be taken as a complete draft description nor a specification ready to be implemented. The installment part of this writeup is heavily inspired by Karol Trzeszczkowski's excellent Last Will and Mecenas contracts. Motivation Generally speaking, a collateralized loan involves a borrower putting up a valuable, less liquid, less fungible asset to borrow a more liquid, more fungible asset that is easier to use in commerce. In a fiat-denominated mortgage, for example, the borrower puts up a house, a highly valuable yet difficult to liquidate asset, in exchange for dollars. The lender gets interest, and the borrower gets additional utility from capital otherwise locked up in their house. Failure to repay the loan results in the collateral being seized by the lender. Asset seizure is backed by law enforcement. In Bitcoin Cash, it is possible to construct smart contract loans collateralized by SimpleLedger (SLP) tokens representing illiquid or less fungible assets, and borrow Bitcoin Cash, which is by far the most liquid and widely accepted asset on the BCH chain. These contracts will retain the basic characteristics of traditional loans, with some key differences. Such a contract can be constructed between any two party who agree without the need for notarization or enforcement by a third party. Enforcement of these contracts is via Bitcoin Script and can be executed by anyone, whether the participating parties or service provider, with no risk of theft. Components A basic contract can be constructed between just a borrower and a lender. The borrower should have a valuable asset, tokenized in SLP, that is relatively difficult to liquidate, or provide non-fungible value that is difficult to retain by exchanging into and out of more fungible assets. The lender should have liquid Bitcoin Cash that can be lent for duration of the contract. The amount of BCH lent should be less than the expected value of the collateral, with a difference sufficient to account for expected price volatility of both BCH and the collateral asset. Contract Description Two types of contracts are possible. The simple case is a single-payment contract: The entirety of the loan is repaid and collateral redeemed at or before the end of the contract. Failure to pay in full before the end of the contract results in the tokenized asset becoming seizable by the lender. This is similar to a traditional pawn shop. A more complex case is a contract that is paid in parts over the contract's lifetime, with the the final transaction returning the tokenized asset to the borrower. Any overdue installments will result in the asset becoming seizable by the lender. "Pawn shop" Single-payment Contract The borrower and lender should fund the contract in one transaction to retain atomicity. In the transaction, the lender passes the agreed upon amount of BCH to the borrower. The borrower transfers their tokenized asset to a P2SH address in the same transaction. Pseudocode of the P2SH script as follows: contract singleloan() { challenge repayment() { Verify that an op_return output is present and transfers asset to a predetermined borrower address. Verify that a repayment output is present and transfers sufficient BCH to a predetermined lender address. } challenge overdue() { Verify that the transaction has locktime beyond a predetermined blockheight or median time past. Verify that an op_return output is present and transfers asset to a predetermined lender address. } } "Mortgage" Installment Contract Initial construction of the loan should be the same as the single-payment case. Rather than a single P2SH address, this uses a series of pre-calculated P2SH addresses, one for each payment. The series of addresses should be pre-constructed with each repayment amount pre-determined. Additionally, seizures due to overdue payments should require the lender to return some amount of equity accumulated thus far, with possible penalties agreed beforehand. Pseudocode of installment scripts as follows: contract installment() { challenge repayment() { Verify that an op_return output is present and transfers asset to the predetermined next installment P2SH address. Verify that an installment output is present and transfers sufficient BCH to a predetermined lender address. } challenge overdue() { Verify that the transaction has locktime beyond a predetermined blockheight or median time past. Verify that an op_return output is present and transfers asset to a predetermined lender address. Verify that partial repayment output is present and transfers sufficient BCH to a predetermined borrower address. } } The final installment enforces return of the asset to the borrower. Ecosystem Requirements In order to have widespread impact, two things need to be present in significant amounts on the Bitcoin Cash chain: 1. Bitcoin Cash itself needs to be sufficiently liquid, available, and widely adopted in order to serve as an attractive denomination for loans. 2. Lower-liquidity or less fungible yet sufficiently valuable assets need to be present, tokenized via SLP, and have their value recognized by enough lenders for a viable market. The [NFT1](https://github.com/simpleledger/slp-specifications/blob/master/slp-nft-1.md) standard is ideal for this purpose. Ecosystem impact Availability of a trustless loan market is expected to both increase demand and utility of Bitcoin Cash, as well as increase the attractiveness of tokenizing assets with SLP.