Peter Rizzo and Aaron van Wirdum recounted those events in a Bitcoin Magazine article<\/a>. Its adapted translation is presented below.<\/p>\n ****<\/p>\n \u00abPush the date back by two months. OP_EVAL is not ready yet.\u00bb<\/p>\n<\/blockquote>\n Gavin Andresen had been working for a long time to avoid such a verdict. A single phrase sent from Russell O\u2019Connor\u2019s computer halted months of work on implementing the first post-Satoshi Nakamoto upgrade to Bitcoin Core.<\/p>\n The proposed approach, Andresen called the quickest path to safer Bitcoin wallets. However, as O\u2019Connor found, it contained a vulnerability that could allow an In other words, through OP_EVAL one could disrupt the operation of nodes and, consequently, the entire Bitcoin network.<\/p>\n \u00abIt took me a full 70 minutes to find this bug. Guys, you should stop and really understand Bitcoin,\u00bb \u2014 wrote O\u2019Connor.<\/p>\n<\/blockquote>\n This was Andresen\u2019s first major setback as the project\u2019s new lead, and he sought to dispute O\u2019Connor\u2019s conclusions. In his view, dropping OP_EVAL would waste months of writing and testing, and would also leave users without tools to defend against trojans and other malware that threatened wallets at the time.<\/p>\n OP_EVAL aimed to create simple multisignature wallets that would allow recovering bitcoins even with lost backups. The team also envisaged bank-like alert services designed to prevent theft and fraud. All within the framework of transactions already familiar to users.<\/p>\n Yet for those who saw danger in moving too fast, O\u2019Connor\u2019s warning proved sufficient.<\/p>\n \u00abI would remind everyone that we are risking a system worth more than $20 million. It\u2019s not just software at stake\u2014everything must be utterly reliable\u00bb, \u2014 wrote developer Alan Reiner.<\/p>\n<\/blockquote>\n The failure to activate OP_EVAL also carried another important consequence. Very few in 2011 truly understood Bitcoin\u2019s code, and even fewer possessed the knowledge and skills to defend it.<\/p>\n How should developers be organised? What responsibilities do they bear to users? How to activate upgrades if it is unclear who has the final say? All these questions soon became central in the first major war among Bitcoin\u2019s developers.<\/p>\n Typically, open-source projects are led by their founders, who coordinate work with contributing developers. And Bitcoin was no exception. In the early years, Satoshi Nakamoto acted as lead developer and de facto dictator. Without broad discussion in the community, he introduced eight upgrades and gradually stepped back.<\/p>\n By the end of 2010 Nakamoto\u2019s name had been removed from Bitcoin.org, and the de facto project leader became Gavin Andresen, previously known for his work in 3D graphics software. The handover was unusual: it consisted of a short public note and a confidential transfer of the system alert key.<\/p>\n Gavin Andresen. Photo: 93.9 & 101.5 THE RIVER<\/a>.<\/p>\n<\/div>\n At that time, for a small group of Bitcoin developers, this was not a particular problem. They were more focused on critical vulnerabilities, while Andresen had enough free time and enthusiasm to lead the work. There were many issues demanding urgent resolution: faster synchronization, better software testing, and a rising tide of reports of compromised wallets and reputational losses from theft. These issues were prioritised<\/a>, with the majority agreeing.<\/p>\n The solution to the wallet-hacking problem, as Andresen discovered, was proposed by Satoshi Nakamoto himself. The Bitcoin code already included the ability to conduct transactions under multi-signature conditions.<\/p>\n The multisignature system (multisig) allowed private keys to be stored on several devices in different parts of the world, or split between the user and wallet provider. This meant that to steal coins, attackers would need to compromise several targets.<\/p>\n The concept quickly inspired Andresen, and in the developer mailing list he passionately urged more active action<\/a> in this direction.<\/p>\n \u00abWhat concerns me most is that it would take only a few days to agree on how to do this right, yet six months have passed and there is still no consensus. Meanwhile, wallet thefts continue\u00bb.<\/p>\n<\/blockquote>\n These concerns were not unfounded\u2014Nakamoto\u2019s implementation had several significant drawbacks. Chief among them was the incompatibility of transactions with the standard Bitcoin address format, which required longer addresses. For this reason, when sending funds to multisig addresses, transactions took more space and demanded higher fees. Moreover, these fees were paid by the sender, not the recipient.<\/p>\n Consequently, multisig transactions were labelled \u201cnon-standard.\u201d This meant that if a node received such a transaction, it would simply ignore it. There were also no guarantees that miners would include such transactions in blocks.<\/p>\n To unlock the full potential of the multisig idea, Andresen supported a new opcode \u2014 a command used by nodes to determine whether a new type of transaction was valid, and under what conditions, if so.<\/p>\n\n
\n
\n
Power Transfer<\/h2>\n
![\"Gavin](\"https:\/\/forklog.com\/wp-content\/uploads\/gavin-andresen.jpg\")
<\/p>\nMultisig<\/h2>\n
\n
OP_EVAL<\/h2>\n