 Hello and welcome to The Daily Decrypt. I am your host, Amanda. Today's episode is brought to you by Dash. Bitcoin Unlimited is a reference client that is an alternative to Bitcoin Core, and they have published what they call Articles of Federation, and I would just like to read them to you. So this will be a longer than average video, so feel free to kick back and just listen to it audio style if you like. All right. Bitcoin is at a crossroads that will determine whether it becomes a worldwide public good, embodying a trustless ledger and currency for all people, companies, and financial institutions worldwide. The Bitcoin Unlimited project seeks to provide a voice in terms of code and hash power to all stakeholders in the Bitcoin ecosystem. As a foundational principle, we assert that Bitcoin is and should be whatever its users define by the code they run and the rules they vote for with their hash power. This project seeks to remove existing practical barriers to stakeholders expressing their views in these ways. We see in the Bitcoin ecosystem many companies, groups, and economic actors that have made large investment decisions based on maintaining the current trajectory of growth, a growth that would naturally ensue if Bitcoin is available as a public good. These include payment processors, micropayment solutions, exchanges, merchants, and more. We recognize the importance of the mining industry and the necessity to increase transaction revenue to support its growth as the block subsidy decreases. This growth is aligned with the interests of the Bitcoin network as a whole since it increases network security. In the Bitcoin core variant, we do not see a venue for these actors to formally express their desires in regards to the evolution of the network. Instead, we see a project controlled by a small group of developers employed by finance-oriented for-profit startup companies and the emergence of corporate products, lightning network, side chains, and permissioned ledgers that would materially benefit from a Bitcoin network that is incapable of handling the transactional demand required for a worldwide public good. Whether these corporate developers are intentionally acting against the long-term success of Bitcoin is irrelevant. In cases of potential conflict of interest, the ethical and socially accepted behavior should be to recuse oneself from such a position of influence. Instead, these developers insist on a poorly defined consensus for determining the development of an MIT-licensed code base which they did not initially create. This tactic has had the opposite effect of recusal, giving themselves veto power over any changes. This has stalled improvements on the block size issue in the Bitcoin core variant. Bitcoin Unlimited perceives itself as an important element in the Bitcoin ecosystem. We believe our founding statutes are firmly based on Satoshi's original vision. However, we acknowledge that Bitcoin is fundamentally a decentralized system, and thus we will not assert centralized ownership of the protocol. And within the Bitcoin Unlimited client, we aim to help people assert and express their own freedom of choice. Article 1. A peer-to-peer electronic cash system for planet Earth. Section 1. Satoshi's original vision, a scalable Bitcoin. Bitcoin Unlimited adheres to Satoshi Nakamoto's vision for a system that could scale up to a worldwide payment network and a decentralized monetary system. Transactions are grouped into blocks and recorded on an unforgeable global ledger known as the Bitcoin blockchain. The blockchain is accessible to anyone in the world, secured by cryptography and maintained by the most powerful single-purpose computing network ever created. Section 2. Governed by the code we run. The guiding principle for Bitcoin Unlimited is that the evolution of the network is decided by the code people freely choose to run. Consensus is therefore an emergent property, objectively represented by the longest proof-of-work chain. This fact is an unassailable property of Bitcoin and cannot be changed by fiat. The final sentence of the Bitcoin whitepaper states, quote, they, nodes, or miners, vote with their CPU power expressing their acceptance of valid blocks by working on extending them and rejecting invalid blocks by refusing to work on them. Any needed rules and incentives can be enforced with this consensus mechanism, end quote. It is this mechanism of voting with their CPU power that keeps Bitcoin permissionless and uncensorable. Were it possible to compel miners to run a specific application with a specific set of rules, then it would be trivial for the owner of the code base to, for example, invalidate transactions, modify the inflation schedule, block certain Bitcoin addresses or IP ranges, limit the quantity of transactions in a block, or implement any other centralized policies. In other words, Bitcoin only maintains its intrinsically valuable properties of being permissionless, uncensorable, trustless, and uninflatable precisely because the software is not and should not be controlled by any single governance entity. Section three, what makes a valid block? From the Bitcoin whitepaper, quote, nodes accept the block only if all transactions in it are valid and not already spent. A block cannot be invalid because of its size. Instead, excessively large blocks that would pose technical challenges to a node are dealt with in the transport layer, increasing the block's orphaning risk. Bitcoin unlimited nodes can accept a chain with an excessive block when needed in order to track consensus. Section four, values and beliefs. Adoption is paramount. Bitcoin should freely scale with demand through a market-based process. The user's experience is important. We seek to engage with all people. Therefore, low fees are desirable. As the block subsidy declines, miners can make money based on volume, not exclusivity. As the Bitcoin network grows, the limitations of the underlying transport and storage technologies will naturally create a fee market, and this market will naturally fluctuate with supply and demand and properly track innovations in the underlying physical technologies. It is understood that instant or zero confirmation transactions are intrinsically less secure compared to confirmed transactions. Transactions that have only been confirmed once are less secure compared to transactions that have been confirmed twice and so forth along the continuum. Since zero confirmation transactions are practically useful for people, we encourage innovations that enhance their security without undermining other key properties of the Bitcoin network. Security and resistance to censorship improves with adoption. The more actors that are in a peer-to-peer network, the harder it becomes to gain control of an influential percentage. Section five, technical. Put the user in control. Any software can join the Bitcoin network because it is a permissionless decentralized ledger. If adding code that allows users to easily change the behavior of their note puts the entire network at risk, then the network is at risk today. But we reject this idea. Instead, we believe that the free market and dynamic network will eliminate bad actors, that differing implementations and behavior make the network more robust against attackers, and that a heterogeneous network will allow good actors to discover and fix potential problems before the bad actors do. Section six, politics. Bitcoin is interdisciplinary. The voices of scientists, scholars, developers, entrepreneurs, investors, and users should all be heard and respected. Article two, confederation. Section one, all Bitcoin unlimited, henceforth BU, activities shall be recorded and publicly accessible. Section two, BU roles shall consist of a president, a publicly identified real life identity is known, BU member, who is responsible for the ongoing activities of the confederation. The president shall assign BUIP numbers, organize BUIP discussion, and voting. Secretary, a publicly identified BU member who is responsible for recording activities and vote results and making this information publicly available. The secretary is responsible for creating, maintaining, and moderating a public forum where discussion can be held. Moderation is exclusively limited to moving content with an indication of it being moved. No content may be deleted. Developer, a publicly identified BU member who is responsible for maintaining the BU code repository, choosing which committers have access to the software repository, reviewing and merging patches, and periodically releasing BU software. The developer is in outreach position. He, she must actively work to encourage others to work on submissions and to convert one time submitters into regular committers. Pool operator, a publicly identified BU member who is responsible for running the BU mining pool, as specified in article four. The position of pool operator might be vacant and pool operation is optional as resources permit. Member, an individual who is invited by BUIP to join the confederation, signs this document, and has voted within the last one year. Non publicly identified members may have restricted voting or other restrictions as determined by subsequent BUIPs. This measure may be needed to restrict duplicate accounts. Officer term is for two years. For continuity, elections shall be staggered by six months and take place one week prior to responsibility transfer. Beginning with the president on January 15th, 2018, then secretary, developer and pool operator. This means that the initial officer term may exceed two years. Voting for all the initial officers shall occur on January 15th, 2016. Section three. Formal interaction between members, including but not limited to BUIP submission and voting, must occur via cryptographically verified identities. Members shall supply a Bitcoin public key when applying for membership and sign all formal communications with the corresponding private key. Section four. Decisions shall be made via the following procedure. Any member can propose a Bitcoin unlimited improvement proposal, the proposer. The proposer can submit a proposal on behalf of another non-member. The president or secretary shall assign this proposal a number and make it publicly accessible. The president, secretary or developer has a two week opportunity to review the proposal and suggest modifications within their own domain. That is, the president reviews proposals related to the operation of the Bitcoin unlimited confederation, the secretary reviews proposals for adherence to BUIP standards, and the developer reviews proposals related to the Bitcoin unlimited code. The proposer may choose to extend this two week period as long as desired. After this period, the officers may attach an opinion or counter BUIP to this BUIP. This package shall be presented to all members and opened for discussion for a minimum of a two week period. The proposer may choose to extend this period for a maximum of six months. At the end of the public discussion period, members shall vote whether to adopt the BUIP. A BUIP is adopted if accepted by a majority of voters, 51%, with at least 50% of members voting, unless otherwise indicated in this document. BUIPs that change these articles or remove officers. If a counter BUIP is proposed, voting occurs in a two-fold manner. First, each member votes his preference, BUIP, counter, or none with a 33% majority. Then if the BUIP or counter BUIP wins, each member votes to accept it or not with the normal majority requirement. Note that members could make both votes simultaneously. I vote for the counter, but if BUIP wins, I vote to accept it, depending on the secretary's implementation of this process. Voting shall be open for a 24-hour period. Members who will not be available during that period may submit an early vote in a manner described by the secretary. Members may not change their vote. All votes are publicly recorded. Section 5. Additional BUIP requirements on patches. If a BUIP contains a patch, the developer may review the patch for acceptability, including but not limited to bugs, tests, coding standards, after BUIP acceptance. The developer may work with the proposer or other party for as long as necessary to ensure the patch is acceptable. After two months, if the proposer believes that this process is taking too long, the president, secretary, or proposer may propose that the patch be included as is via the same BUIP proposal channel and schedule a vote, normal BUIP majority rules. This vote may not occur within one week of the formal commit as is proposal. If the BUIP does not contain a patch but suggests technical changes, it is the responsibility of the proposer or any other party to produce this patch. After the patch is produced, the developer reviews it as suggested in the preceding paragraph, except in the as is case, the normal BUIP schedule and process must be followed. In the unfortunate situation where a patch is deliberately accepted, which does not agree with the proposer's BUIP, the proposer's recourse is to resubmit the BUIP with a patch. Section 6. This document can be modified via a greater than 66% majority vote on a BUIP with at least 75% of the member's voting. Section 7. Elections occur via the following procedure. The secretary, or president, then developer if the secretary or president is vacated, announces vacancy or impending vacancy of a position to the BU Public Forum and an election date not earlier than four weeks subsequent to the announcement. Interested members submit a BUIP announcing their candidacy, real life identity, and including any other desired information. Submissions can happen at any time. Public discussion of the candidates is allowed and follows the same mechanism as other BUIPs. During the election, a modified BUIP voting process occurs where members vote for the candidate of their choice. If there are more than two candidates, a second round of voting occurs solely between the two candidates with the most votes. Largest number of votes wins. Note that for expediency purposes, the secretary may choose to collapse the voting operation into a single phase, where voters make multiple choices in a manner similar to the BUIP or counter BUIP system if the number of candidates is small enough to reasonably do so. Section 8. The president, secretary, developer, or pool operator may voluntarily resign before term completion via a signed public message posted to the BU Public Forum. In this situation, elections occur prematurely via the process outlined in section 7 starting from the date of resignation. In the case of abrupt departure, an interim person may be appointed by the president, including someone currently holding another role. In that case, he or she will not vacate the originally elected role. Section 9. An officer can be removed via a no-confidence BUIP. This BUIP follows the normal schedule, however, it must pass with a 75% majority of voters with at least 33% of members voting. A BUIP advocating for the removal of a particular officer may not occur within four months of a prior unsuccessful proposal advocating for the removal of that officer. Removal proposals will be managed by an officer who is not affected by the BUIP. Multiple officer removal BUIPs are not allowed to submit them separately. Section 10. If actions of the president, secretary, developer, pool operator, or member is in violation of these rules, that is grounds for removal. Any member may submit a no-confidence BUIP as per section 9. Members are exhorted to vote based on their belief as to whether the individual broke these rules rather than their personal opinion of the individual's fitness for the office. A removed officer may rerun for any position. Article 3. Operations and Resources This article provides guidelines for operations assuming that Bitcoin Unlimited becomes a non-profit corporation. Yet it also provides instructions for operations before that event occurs. Section 1. Any unallocated funds raised shall be held in a two of three multi-signature account with the president, secretary, and developer holding the keys. Fiat currency holdings shall only occur to ensure that commitments can be paid regardless of Bitcoin's volatility and shall be held either by the president or in a Bitcoin Unlimited non-profit corporation account. Allocated funds may be held temporarily by the person who will employ them. Section 2. Funds donated to Bitcoin Unlimited may be applied to any purpose, including the Bitcoin Unlimited pool, that furthers the project's goals and is authorized by majority vote via line items in a president's operational BUIP. Donations may not be used to pay salaries, bonuses, etc. for the president, secretary, developer, or pool operator. These volunteer roles are unpaid with the expectation that these individuals will benefit from Bitcoin's success. However, the people fulfilling these roles may be paid upon completion of particular tasks that exceed their stated role. For example, the developer may be paid to implement a particular feature, however the time required to review and merge the feature is unpaid. Section 3. The source repository administrative account shall be held by the president, but the president may only add and remove committers on the recommendation of the developer. Additionally, the president may not use his administrative account to directly commit software to the source repository. Instead, these contributions must be submitted as a fork or patch and be reviewed and merged by the developer or another committer. Section 4. All domain name registrations shall be controlled by the developer. Section 5. Public forum infrastructure shall be controlled by the secretary. Section 6. Source repository committers may commit to the master branch repository without explicit BUIP approval during the course of their day-to-day work. Commits that implement a particular BUIP should reference that document in the check-in comments. However, committers have the responsibility to implement any large or potentially controversial change on a fork or branch and bring it to member attention via the BUIP process. Committers have the responsibility to respect the efforts of independent submissions by ensuring that authorship attribution is correct in the final commit to the BU repository. Committers must work respectfully with independent submitters to ensure coding, testing, documentation, and formatting standards are met as defined by the developer. Section 7. A member that feels a commit needs BUIP approval can submit a BUIP referencing the commit arguing against the change. This change may remain in the repository until the issue is determined, but the developer may not issue non-experimental binary releases containing any commit that is under BUIP debate. Section 8. The developer may release experimental features under the Bitcoin Unlimited brand and develop them in Bitcoin Unlimited repository branches. However, these releases must be named and advertised as distinctly separate from the primary Bitcoin Unlimited release. Additional flavors of release may also be recommended to be created by members through the BUIP process. Section 9. Administrators of resources, source repository account, domain name, public forum, and any others are responsible for paying for the resource of the duration of the administrator's term. However, these administrators should be compensated or pre-compensated out of BU funds if available via an operational BUIP. Section 10. The president may periodically issue a special BUIP called an operational BUIP that details proposed payments and other organizational activities. This BUIP follows the same voting methodology as any other. Section 11. The president, secretary, developer, or pool operator can issue, or issue on behalf of another member, a special BUIP called an informative BUIP, which allows members to vote on a non-binding issue or question. These BUIPs allow the community to formally give feedback on future directions for the project. For example, an informative BUIP could be, should we look into and then propose partnerships with hardware wallets? issuance is restricted to reduce BUIP spam. And Article 4. The Bitcoin Unlimited mining pool. Increasingly, users who have a strong vested interest in the success of Bitcoin control proportionally little hash power. The Bitcoin Unlimited mining pool seeks to provide companies and users a transparently run, not-for-profit, high-payout mining pool, which explicitly supports global Bitcoin adoption through Bitcoin Unlimited block creation. Section 1. Operation. The pool will be run by the Bitcoin Unlimited pool operator and other real identity known Bitcoin Unlimited members as designated by the pool operator, with operational and mission transparency as key priorities. The Bitcoin Unlimited pool will run Bitcoin Unlimited full node software. Section 2. Donor incentives. Users, companies, and other ecosystem stakeholders will be incentivized to contribute to this pool as long as it supports their values. As has always been the case, hash power speaks loudest and stakeholders ultimately exercise their vote via hashing. Section 3. User incentives. In the ideal case, donations will exceed operational cost and therefore the Bitcoin Unlimited pool will offer an overlay payout to participant miners, specifics to be decided by BUIP. This should build a strong base of hash power for the pool. Donations can be made for the specific purpose of supporting the pool, as opposed to donations to the general Bitcoin Unlimited fund, and will be managed in a two of three, President, Secretary, Pool operator, Multisig account, separate from Bitcoin Unlimited general purpose funds. Section 4. 51% risk. To alleviate real or perceived risk of this pool gaining more than 50% of total network hash power, if the pool's hash power exceeds an average of 30% for more than 30 consecutive days, it must disband into two completely separate entities with no personnel overlap. And that is the entirety of Bitcoin Unlimited's articles of federation, and it includes a signing statement at the bottom for people who would like to join. You can learn more about this potential governance model for Bitcoin at Bitcoin Unlimited.info. Today's episode has been brought to you by Dash, a currency with a highly robust and decentralized infrastructure. This infrastructure has been incentivized because Dash's block reward is halved between its miners and its nodes. In fact, Dash has 96% of the node count that Bitcoin has. Not kidding. You can learn more about how they did it by visiting dash.org. We're independent members of the LTV network. If you'd like to listen to this longer video on the go, check out our downloadable podcast there via SoundCloud. And today's magic word is governance. Have a great day.