diff options
35 files changed, 1052 insertions, 317 deletions
diff --git a/README.mediawiki b/README.mediawiki index d3143d3..f558246 100644 --- a/README.mediawiki +++ b/README.mediawiki @@ -279,6 +279,13 @@ Those proposing changes should consider that ultimately consent may rest with th | Gavin Andresen | Informational | Final +|- +| [[bip-0052.mediawiki|52]] +| Consensus (hard fork) +| Durable, Low Energy Bitcoin PoW +| Michael Dubrovsky, Bogdan Penkovsky +| Standard +| Draft <!-- 50 series reserved for a group of post-mortems --> |- | [[bip-0060.mediawiki|60]] diff --git a/bip-0016.mediawiki b/bip-0016.mediawiki index 0f4fb81..abc27d6 100644 --- a/bip-0016.mediawiki +++ b/bip-0016.mediawiki @@ -40,7 +40,7 @@ The rules for validating these outpoints when relaying transactions or consideri # Normal validation is done: an initial stack is created from the signatures and {serialized script}, and the hash of the script is computed and validation fails immediately if it does not match the hash in the outpoint. # {serialized script} is popped off the initial stack, and the transaction is validated again using the popped stack and the deserialized script as the scriptPubKey. -These new rules should only be applied when validating transactions in blocks with timestamps >= 1333238400 (Apr 1 2012) <ref>[https://github.com/bitcoin/bitcoin/commit/8f188ece3c82c4cf5d52a3363e7643c23169c0ff Remove -bip16 and -paytoscripthashtime command-line arguments]</ref>. There are transactions earlier than 1333238400 in the block chain that fail these new validation rules. <ref>[http://blockexplorer.com/tx/6a26d2ecb67f27d1fa5524763b49029d7106e91e3cc05743073461a719776192 Transaction 6a26d2ecb67f27d1fa5524763b49029d7106e91e3cc05743073461a719776192]</ref>. Older transactions must be validated under the old rules. (see the Backwards Compatibility section for details). +These new rules should only be applied when validating transactions in blocks with timestamps >= 1333238400 (Apr 1 2012) <ref>[https://github.com/bitcoin/bitcoin/commit/8f188ece3c82c4cf5d52a3363e7643c23169c0ff Remove -bip16 and -paytoscripthashtime command-line arguments]</ref>. There are transactions earlier than 1333238400 in the block chain that fail these new validation rules. <ref>[https://web.archive.org/web/20141122040355/http://blockexplorer.com/tx/6a26d2ecb67f27d1fa5524763b49029d7106e91e3cc05743073461a719776192 Transaction 6a26d2ecb67f27d1fa5524763b49029d7106e91e3cc05743073461a719776192]</ref>. Older transactions must be validated under the old rules. (see the Backwards Compatibility section for details). For example, the scriptPubKey and corresponding scriptSig for a one-signature-required transaction is: diff --git a/bip-0032.mediawiki b/bip-0032.mediawiki index 7a4ae84..b441658 100644 --- a/bip-0032.mediawiki +++ b/bip-0032.mediawiki @@ -151,7 +151,7 @@ The total number of possible extended keypairs is almost 2<sup>512</sup>, but th * Calculate I = HMAC-SHA512(Key = "Bitcoin seed", Data = S) * Split I into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>. * Use parse<sub>256</sub>(I<sub>L</sub>) as master secret key, and I<sub>R</sub> as master chain code. -In case I<sub>L</sub> is 0 or ≥n, the master key is invalid. +In case parse<sub>256</sub>(I<sub>L</sub>) is 0 or parse<sub>256</sub>(I<sub>L</sub>) ≥ n, the master key is invalid. <img src=bip-0032/derivation.png></img> @@ -201,7 +201,7 @@ In addition to the expectations from the EC public-key cryptography itself: the intended security properties of this standard are: * Given a child extended private key (k<sub>i</sub>,c<sub>i</sub>) and the integer i, an attacker cannot find the parent private key k<sub>par</sub> more efficiently than a 2<sup>256</sup> brute force of HMAC-SHA512. * Given any number (2 ≤ N ≤ 2<sup>32</sup>-1) of (index, extended private key) tuples (i<sub>j</sub>,(k<sub>i<sub>j</sub></sub>,c<sub>i<sub>j</sub></sub>)), with distinct i<sub>j</sub>'s, determining whether they are derived from a common parent extended private key (i.e., whether there exists a (k<sub>par</sub>,c<sub>par</sub>) such that for each j in (0..N-1) CKDpriv((k<sub>par</sub>,c<sub>par</sub>),i<sub>j</sub>)=(k<sub>i<sub>j</sub></sub>,c<sub>i<sub>j</sub></sub>)), cannot be done more efficiently than a 2<sup>256</sup> brute force of HMAC-SHA512. -Note however that the following properties does not exist: +Note however that the following properties do not exist: * Given a parent extended public key (K<sub>par</sub>,c<sub>par</sub>) and a child public key (K<sub>i</sub>), it is hard to find i. * Given a parent extended public key (K<sub>par</sub>,c<sub>par</sub>) and a non-hardened child private key (k<sub>i</sub>), it is hard to find k<sub>par</sub>. diff --git a/bip-0038.mediawiki b/bip-0038.mediawiki index bfe1f4a..511b55a 100644 --- a/bip-0038.mediawiki +++ b/bip-0038.mediawiki @@ -66,7 +66,7 @@ To keep the size of the encrypted key down, no initialization vectors (IVs) are * Count of payload bytes (beyond prefix): 37 ** 1 byte (''flagbyte''): *** the most significant two bits are set as follows to preserve the visibility of the compression flag in the prefix, as well as to keep the payload within the range of allowable values that keep the "6P" prefix intact. For non-EC-multiplied keys, the bits are 11. For EC-multiplied keys, the bits are 00. -*** the bit with value 0x20 when set indicates the key should be converted to a bitcoin address using the compressed public key format. +*** the bit with value 0x20 when set indicates the key should be converted to a base58check encoded P2PKH bitcoin address using the DER compressed public key format. When not set, it should be a base58check encoded P2PKH bitcoin address using the DER uncompressed public key format. *** the bits with values 0x10 and 0x08 are reserved for a future specification that contemplates using multisig as a way to combine the factors such that parties in possession of the separate factors can independently sign a proposed transaction without requiring that any party possess both factors. These bits must be 0 to comply with this version of the specification. *** the bit with value 0x04 indicates whether a lot and sequence number are encoded into the first factor, and activates special behavior for including them in the decryption process. This applies to EC-multiplied keys only. Must be 0 for non-EC-multiplied keys. *** remaining bits are reserved for future use and must all be 0 to comply with this version of the specification. diff --git a/bip-0052.mediawiki b/bip-0052.mediawiki new file mode 100644 index 0000000..9d5cff0 --- /dev/null +++ b/bip-0052.mediawiki @@ -0,0 +1,302 @@ +<pre> + BIP: 52 + Layer: Consensus (hard fork) + Title: Durable, Low Energy Bitcoin PoW + Author: Michael Dubrovsky <mike+bip@powx.org> + Bogdan Penkovsky <bogdan+bip@powx.org> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0052 + Status: Draft + Type: Standards Track + Created: 2021-05-13 + License: BSD-2-Clause + OPL +</pre> + + +== Simple Summary == + +Bitcoin's energy consumption is growing with its value (see Figure below). +Although scaling PoW is necessary to maintain the security of the network, +reliance on massive energy consumption has scaling drawbacks and leads to mining +centralization. A major consequence of the central role of local electricity +cost in mining is that today, most existing and potential participants in the +Bitcoin network cannot profitably mine Bitcoin even if they have the capital to +invest in mining hardware. From a practical perspective, Bitcoin adoption by +companies like Tesla (which recently rescinded its acceptance of Bitcoin as +payment) has been hampered by its massive energy consumption and perceived +environmental impact. + +<img src="bip-0052/btc_energy-small.png"></img> + +Figure. Bitcoin price and estimated Bitcoin energy consumption. +Data sources: [https://cbeci.org Cambridge Bitcoin Electricity Consumption Index], [https://www.coindesk.com CoinDesk]. + +We propose a novel proof-of-work paradigm for Bitcoin--Optical proof-of-work. It +is designed to decouple Bitcoin mining from energy and make it feasible outside +of regions with low electricity costs. ''Optical proof-of-work'' (oPoW) is a +modification of Hashcash that is most efficiently computed using a new class of +photonic processors. Without compromising the cryptographic or game-theoretical +security of Hashcash, oPoW shifts the operating expenses of mining (OPEX), to +capital expenses (CAPEX)--i.e. electricity to hardware. oPoW makes it possible +for billions of new miners to enter the market simply by investing in a +low-energy photonic miner. Shifting to a high-CAPEX PoW has the added benefit of +making the hashrate resilient to Bitcoin's price fluctuations - once low-OPEX +hardware is operating there is no reason to shut it down even if the value of +mining rewards diminishes. oPoW is hardware-compatible with GPUs, FPGAs, and +ASICs meaning that a transitional period of optical and traditional hardware +mining in parallel on the network is feasible + +More information is available here: [https://www.powx.org/opow]. + +== Abstract == + +As Bitcoin gained utility and value over the preceding decade, the network incentivized the purchase of billions of dollars in mining equipment and electricity. With the growth of competition, home mining became unprofitable. Even the most sophisticated special-purpose hardware (ASIC miners) doesn’t cover its energy costs unless the miner also has direct access to very cheap electricity. This heavy reliance on energy makes it difficult for new miners to enter the market and leads to hashrate instability as miners shut off their machines when the price of Bitcoin falls. Additionally as the network stores ever more value, the percentage of world energy consumption that is associated with Bitcoin continues to grow, creating the potential for scaling failure and a general backlash. To ensure that Bitcoin can continue scaling and reach its full potential as a world currency and store of value, we propose a low-energy proof-of-work paradigm for Bitcoin. ''Optical proof of work (oPoW)'' is designed to decouple Bitcoin’s security from massive energy use and make bitcoin mining feasible outside of regions with low electricity costs. ''Optical proof-of-work'' is a modification of Hashcash that is most efficiently computed using a new class of photonic processors that has emerged as a leading solution for ultra-low energy computing over the last 5 years. oPoW shifts the operating expenses of mining (OPEX), to capital expenses (CAPEX)–i.e. electricity to hardware, without compromising the cryptographic or game-theoretical security of Hashcash. We provide an example implementation of oPoW, briefly discuss its cryptographic construction as well as the working principle of photonic processors. Additionally, we outline the potential benefits of oPoW to the bitcoin network, including geographic decentralization and democratization of mining as well as hashrate resilience to price fluctuations. + +== Copyright == + +This BIP is dual-licensed under the Open Publication License and BSD 2-clause license. + +== Motivation == + +As Bitcoin has grown over the past decade from a small network run by hobbyists to a global currency, the underlying Proof of Work protocol has not been updated. Initially pitched as a global decentralized network (“one CPU-one vote”), Bitcoin transactions today are secured by a small group of corporate entities. In practice, it is only feasible for [http://archive.is/YeDwh entities that can secure access to abundant, inexpensive energy]. The economics of mining limit profitability to places like Iceland, Texas, or Western China. Besides the negative environmental externalities, which may be significant, mining today is performed primarily with the consent (and in many cases, partnership) of large public utilities and the governments that control them. Although this may not be a problem in the short term, in the long term it stands to erode the censorship resistance and security of Bitcoin and other public blockchains through potential regulation or [https://arxiv.org/pdf/1605.07524.pdf partitioning attacks]. + +Recent events, such as the [https://twitter.com/MustafaYilham/status/1384278267067203590 ~25% hashrate crash due to coal-powered grid failure in china] and Tesla’s rescinding of its acceptance of Bitcoin as a form of payment, show that there are practical real-world downsides to Proof of Works’s massive reliance on energy. + +<img src="bip-0052/emusk_tweet.png"></img> + +Whether on not the Bitcoin community accepts this common criticism as entirely valid, it has real-world effects which will only get worse over time. Eliminating the exponentially growing energy use currently built into Bitcoin without eliminating the security of PoW would be ideal and should not be a partisan issue. + +New consensus mechanisms have been proposed as a means of securing cryptocurrencies whilst reducing energy cost, such as various forms of Proof of Stake and Proof of Space-Time. While many of these alternative mechanisms offer compelling guarantees, they generally require new security assumptions, which have not been stress-tested by live deployments at any adequate scale. Consequently, we still have relatively little empirical understanding of their safety. Completely changing the Bitcoin paradigm is likely to introduce new unforeseen problems. We believe that the major issues discussed above can be resolved by improving rather than eliminating Bitcoin’s fundamental security layer—Proof of Work. Instead of devising a new consensus architecture to fix these issues, it is sufficient to shift the economics of PoW. The financial cost imposed on miners need not be primarily composed of electricity. The situation can be significantly improved by reducing the operating expense (OPEX)—energy—as a major mining component. Then, by shifting the cost towards capital expense (CAPEX)—mining hardware—the dynamics of the mining ecosystem becomes much less dependent on electricity prices, and much less electricity is consumed as a whole. + +Moreover, a reduction in energy consumption automatically leads to +geographically distributed mining, as mining becomes profitable even in regions +with expensive electricity. Additionally, lower energy consumption will +eliminate heating issues experienced by today’s mining operations, which will +further decrease operating cost as well as noise associated with fans and +cooling systems. All of this means that individuals and smaller entities would +be able to enter the mining ecosystem simply for the cost of a miner, without +first gaining access to cheap energy or a dedicated, temperature-controlled data +center. To a degree, memory-hard PoW schemes like +[https://github.com/tromp/cuckoo Cuckoo Cycle], which increase the use of SRAM +in lieu of pure computation, push the CAPEX/OPEX ratio in the right direction by +occupying ASIC chip area with memory. To maximize the CAPEX to OPEX ratio of the +Optical Proof of Work algorithm, we developed +[https://assets.pubpub.org/xi9h9rps/01581688887859.pdf ''HeavyHash''] [1]. +HeavyHash is a cryptographic construction that takes the place of SHA256 in +Hashcash. Our algorithm is hardware-compatible with ultra-energy-efficient photonic co-processors that have been developed for machine learning hardware accelerators. + +HeavyHash uses a proven digital hash (SHA3) packaged with a large amount of MAC (Multiply-and-Accumulate) computation into a Proof of Work puzzle. Although HeavyHash can be computed on any standard digital hardware, it becomes hardware efficient only when a small digital core is combined with a low-power photonic co-processor for performing MAC operations. oPoW mining machines will have a small digital core flip-chipped onto a large, low-power photonic chip. This core will be bottlenecked by the throughput of the digital to analog and analog to digital converters. A prototype of such analogue optical matrix multiplier can be seen in the figure below. + +<img src="bip-0052/optical_chip.png"></img> + +Figure. TOP: Photonic Circuit Diagram, A. Laser input (1550nm, common telecom wavelength) B. Metal pads for controlling modulators to transduce electrical data to optical C. Metal pads for tuning mesh of directional couplers D. Optical signal exits here containing the results of the computation and is output to fibers via a grating coupler the terminus of each waveguide. E. Alignment circuit for aligning fiber coupling stage. Bottom: a photograph of a bare oPoW miner prototype chip before wire and fiber bonding. On the right side of the die are test structures (F). + +The ''HeavyHash'' derives its name from the fact that it is bloated or weighted with additional computation. This means that a cost comparable oPoW miner will have a much lower nominal hashrate compared to a Bitcoin ASIC (HeavyHashes/second vs. SHA256 Hashes/second in equivalent ASIC). We provide the cryptographic security argument of the HeavyHash function in Section 3 in [https://assets.pubpub.org/xi9h9rps/01581688887859.pdf Towards Optical Proof of Work] [1]. In the article, we also provide a game-theoretic security argument for CAPEX-heavy PoW. For additional information, we recommend reading [https://uncommoncore.co/wp-content/uploads/2019/10/A-model-for-Bitcoins-security-and-the-declining-block-subsidy-v1.02.pdf this article]. + +While traditional digital hardware relies on electrical currents, optical +computing uses light as the basis for some of or all of its operations. Building +on the development and commercialization of silicon photonic chips for telecom +and datacom applications, modern photonic co-processors are silicon chips made +using well-established and highly scalable silicon CMOS processes. However, +unlike cutting edge electronics which require ever-smaller features (e.g. 5 nm), +fabricated by exponentially more complex and expensive machinery, silicon +photonics uses old fabrication nodes (90 nm). Due to the large de Broglie +wavelength of photons, as compared to electrons, there is no benefit to using +the small feature sizes. The result is that access to silicon photonic wafer +fabrication is readily available, in contrast to the notoriously difficult +process of accessing advanced nodes. Moreover, the overall cost of entry is +lower as lithography masks for silicon photonics processes are an order of +magnitude cheaper ($500k vs. $5M). Examples of companies developing optical +processors for AI, which will be hardware-compatible with oPoW include [https://lightmatter.co/ Lightmatter], [https://www.lightelligence.ai/ Lightelligence], [https://luminous.co/ Luminous], [https://www.intel.com/content/www/us/en/architecture-and-technology/silicon-photonics/silicon-photonics-overview.html Intel], and other more recent entrants. + +== Specification == + +=== HeavyHash === + +The HeavyHash is performed in three stages: + +# Keccak hash +# Matrix-vector multiplication +# Keccak of the result xorred with the hashed input + +Note that the most efficiently matrix-vector multiplication is performed on a +photonic miner. However, this linear algebra operation can be performed on any +conventional computing hardware (CPU, GPU, etc.), therefore making the HeavyHash +hardware-compatible with any digital device. + +The algorithm’s pseudo-code: + +<pre>// M is a Matrix 64 x 64 of Unsigned 4 values + +// 256-bitVector +x1 <- keccak(input) + +// Reshape the obtained bitvector +// into a 64-vector of unsigned 4-bit values +x2 <- reshape(x1, 64) + +// Perform a matrix-vector multiplication. +// The result is 64-vector of 14-bit unsigned. +x3 <- vector_matrix_mult(x2, M) + +// Truncate all values to 4 most significant bits. +// This is due to the specifics of analog +// computing by the photonic accelerator. +// Obtain a 64-vector of 4-bit unsigned. +x4 <- truncate_to_msb(x3, 4) + +// Interpret as a 256-bitvector +x5 <- flatten(x4) + +// 256-bitVector +result <- keccak(xor(x5, x1))</pre> + +Which in C can be implemented as: + +<pre> +static void heavyhash(const uint16_t matrix[64][64], void* pdata, size_t pdata_len, void* output) +{ + uint8_t hash_first[32] __attribute__((aligned(32))); + uint8_t hash_second[32] __attribute__((aligned(32))); + uint8_t hash_xored[32] __attribute__((aligned(32))); + + uint16_t vector[64] __attribute__((aligned(64))); + uint16_t product[64] __attribute__((aligned(64))); + + sha3_256((uint8_t*) hash_first, 32, (const uint8_t*)pdata, pdata_len); + + for (int i = 0; i < 32; ++i) { + vector[2*i] = (hash_first[i] >> 4); + vector[2*i+1] = hash_first[i] & 0xF; + } + + for (int i = 0; i < 64; ++i) { + uint16_t sum = 0; + for (int j = 0; j < 64; ++j) { + sum += matrix[i][j] * vector[j]; + } + product[i] = (sum >> 10); + } + + for (int i = 0; i < 32; ++i) { + hash_second[i] = (product[2*i] << 4) | (product[2*i+1]); + } + + for (int i = 0; i < 32; ++i) { + hash_xored[i] = hash_first[i] ^ hash_second[i]; + } + sha3_256((uint8_t*)output, 32, (const uint8_t*)hash_xored, 32); +} +</pre> +=== Random matrix generation === + +The random matrix M (which is a HeavyHash parameter) is obtained in a deterministic way and is changed every block. Matrix M coefficients are generated using a pseudo-random number generation algorithm (xoshiro) from the previous block header. If the matrix is not full rank, it is repeatedly generated again. + +An example code to obtain the matrix M: + +<pre> +void generate_matrix(uint16_t matrix[64][64], struct xoshiro_state *state) { + do { + for (int i = 0; i < 64; ++i) { + for (int j = 0; j < 64; j += 16) { + uint64_t value = xoshiro_gen(state); + for (int shift = 0; shift < 16; ++shift) { + matrix[i][j + shift] = (value >> (4*shift)) & 0xF; + } + } + } + } while (!is_full_rank(matrix)); +} + +static inline uint64_t xoshiro_gen(struct xoshiro_state *state) { + const uint64_t result = rotl64(state->s[0] + state->s[3], 23) + state->s[0]; + + const uint64_t t = state->s[1] << 17; + + state->s[2] ^= state->s[0]; + state->s[3] ^= state->s[1]; + state->s[1] ^= state->s[2]; + state->s[0] ^= state->s[3]; + + state->s[2] ^= t; + + state->s[3] = rotl64(state->s[3], 45); + + return result; +} +</pre> + +== Discussion == + +=== Geographic Distribution of Mining Relative to CAPEX-OPEX Ratio of Mining Costs === + +Below is a simple model showing several scenarios for the geographic distribution of mining activity relative to the CAPEX/OPEX ratio of the cost of operating a single piece of mining hardware. As the ratio of energy consumption to hardware cost decreases, geographic variations in energy cost cease to be a determining factor in miner distribution. + +Underlying assumptions: 1. Electricity price y is fixed in time but varies geographically. 2. Every miner has access to the same hardware. 3. Each miner’s budget is limited by both the cost of mining equipment as well as the local cost of the electricity they consume + +budget = a(p+ey), + +where a is the number of mining machines, p is the machine price, e is the total energy consumption over machine lifetime, and y is electricity price. + +Note that in locations where mining is not profitable, hashrate is zero. + +<img src="bip-0052/sim1.png"></img> + +<img src="bip-0052/sim2.png"></img> + +<img src="bip-0052/sim3.png"></img> + +An interactive version of this diagram can be found [https://www.powx.org/opow here]. + +=== Why does CAPEX to OPEX shift lead to lower energy consumption? === + +A common misconception about oPoW is that it makes mining “cheaper” by enabling energy-efficient hardware. There is no impact on the dollar cost of mining a block, rather the mix of energy vs. hardware investment changes from about 50/50 to 10/90 or better. We discuss this at length and rigorously in our paper[1]. + +=== Working Principles of Photonic Processors === + +Photonics accelerators are made by fabricating waveguides in silicon using standard lithography processes. Silicon is transparent to infrared light and can act as a tiny on-chip fiber optical cable. Silicon photonics found its first use during the 2000s in transceivers for sending and receiving optical signals via fiber and has advanced tremendously over the last decade. + +By encoding a vector into optical intensities passing through a series of parallel waveguides, interfering these signals in a mesh of tunable interferometers (acting as matrix coefficients), and then detecting the output using on-chip Germanium photodetectors, a matrix-vector multiplication is achieved. A generalized discussion of matrix multiplication setups using photonics/interference can be found in [https://journals.aps.org/prl/abstract/10.1103/PhysRevLett.73.58 Reck et al.] and [https://arxiv.org/abs/1506.06220 Russell et al.] A detailed discussion of several integrated photonic architectures for matrix multiplication and corresponding tuning algorithms can be found in [https://arxiv.org/pdf/1909.06179.pdf Pai et al.] + +Below is a conceptual representation of a 3D-packaged oPoW mining chip. Note that the majority of the real estate and cost comes from the photonic die and the laser, with only a small digital SHA3 die needed (as opposed to a conventional miner of the same cost, which would have many copies of this die running in parallel). + +<img src="bip-0052/optminer.png"></img> + +=== Block Reward Considerations === + +Although it is out of the scope of this proposal, the authors strongly recommend the consideration of a change in the block reward schedule currently implemented in Bitcoin. There is no clear way to incentivize miners with transaction fees only, as has been successfully shown in [https://www.cs.princeton.edu/~smattw/CKWN-CCS16.pdf On the Instability of Bitcoin Without the Block Reward] and other publications, therefore looking a decade or two ahead it will be important to implement a fixed block reward or to slow the decay of the block reward to maintain the security of the network. Given that oPoW miners have low operating costs, once a large number of machines are running the reward level sufficient to keep them in operation and providing robust security can potentially be significantly smaller than in the case of the current SHA256 ASICs securing Bitcoin. + +=== Implementation on the Bitcoin Network === + +A hard fork is not necessarily required for the Bitcoin network to test and eventually implement oPoW. It’s possible to add oPoW as a dual PoW to Bitcoin as a soft fork. Tuning the parameters to ensure that, for example, 99.9% of the security budget would be earned by miners via the SHA256 Hashcash PoW and 0.1% via oPoW would create sufficient incentive for oPoW to be stress-tested and to incentivize the manufacture of dedicated oPoW miners. If this test is successful, the parameters can be tuned continuously over time, e.g. oPoW share doubling at every halving, such that oPoW accounts for some target percentage (up to 100% in a complete SHA256 phase-out). + + +==== Reverse compatibility ==== + +Our understanding is that oPoW will not be reverse compatible. + + +=== ASICBOOST === + +Any new PoW algorithm carries the risk of hardware developers discovering and patenting an architecture with a significant speedup, as happened in the case of ASICBOOST for SHA256. HeavyHash is comprised of an SHA hash and 4-bit linear matrix-vector operations. The intent is for the matrix-vector multiplications to account for the majority of the work involved in computing a single HeavyHash operation. As we show in the Minimum Effective Hardness section of Towards Optical Proof of Work[1], there is no workaround to performing the matrix operations when computing HeavyHash, and since the SHA hashes are negligible, a true ASICBOOST-type speed up would require a speed up in linear matrix processing. Since matrix-vector multiplication is at the heart of neural networks and many other common computational workloads, it has been optimized very heavily and is generally very well understood. The acceleration of matrix-vector multiplication hardware (e.g. photonic coprocessors, memristors, etc.) is a very general problem and there are dozens of companies working on it, making it very unlikely for a single party to corner the market. + +== Endnotes == + +With significant progress in optical and analog matrix-vector-multiplication chipsets over the last year, we hope to demonstrate commercial low-energy mining on our network in the next 6 months. The current generation of optical matrix processors under development is expected to have 10x better energy consumption per MAC operation than digital implementations, and we expect this to improve by another order of magnitude in future generations. + +PoWx will also be publishing the designs of the current optical miner prototypes in the near term under an open-source hardware license. + +== Acknowledgments == + +We thank all the members of the Bitcoin community who have already given us feedback over the last several years as well as others in the optical computing community and beyond that have given their input. + + + + +[1] M. Dubrovsky et al. Towards Optical Proof of Work, CES conference (2020) https://assets.pubpub.org/xi9h9rps/01581688887859.pdf + +[2] https://sciencex.com/news/2020-05-powering-bitcoin-silicon-photonics-power.html + +[3] KISS random number generator http://www.cse.yorku.ca/~oz/marsaglia-rng.html + diff --git a/bip-0052/btc_energy-small.png b/bip-0052/btc_energy-small.png Binary files differnew file mode 100644 index 0000000..32ffde3 --- /dev/null +++ b/bip-0052/btc_energy-small.png diff --git a/bip-0052/btc_energy.png b/bip-0052/btc_energy.png Binary files differnew file mode 100644 index 0000000..cc37d3a --- /dev/null +++ b/bip-0052/btc_energy.png diff --git a/bip-0052/emusk_tweet.png b/bip-0052/emusk_tweet.png Binary files differnew file mode 100644 index 0000000..6e7f065 --- /dev/null +++ b/bip-0052/emusk_tweet.png diff --git a/bip-0052/optical_chip.png b/bip-0052/optical_chip.png Binary files differnew file mode 100644 index 0000000..f3ec05c --- /dev/null +++ b/bip-0052/optical_chip.png diff --git a/bip-0052/optminer.png b/bip-0052/optminer.png Binary files differnew file mode 100644 index 0000000..4fd639b --- /dev/null +++ b/bip-0052/optminer.png diff --git a/bip-0052/sim1.png b/bip-0052/sim1.png Binary files differnew file mode 100644 index 0000000..4b6b863 --- /dev/null +++ b/bip-0052/sim1.png diff --git a/bip-0052/sim2.png b/bip-0052/sim2.png Binary files differnew file mode 100644 index 0000000..043cfc2 --- /dev/null +++ b/bip-0052/sim2.png diff --git a/bip-0052/sim3.png b/bip-0052/sim3.png Binary files differnew file mode 100644 index 0000000..ee5f71e --- /dev/null +++ b/bip-0052/sim3.png diff --git a/bip-0067.mediawiki b/bip-0067.mediawiki index b164289..793039d 100644 --- a/bip-0067.mediawiki +++ b/bip-0067.mediawiki @@ -124,7 +124,7 @@ The authors wish to thank BtcDrak and Luke-Jr for their involvement & contributi ==Usage & Implementations== * [[https://github.com/bitcoin/bips/blob/master/bip-0045.mediawiki#address-generation-procedure|BIP-0045]] - Structure for Deterministic P2SH Multisignature Wallets * [[https://github.com/bitpay/bitcore/blob/50a868cb8cdf2be04bb1c5bf4bcc064cc06f5888/lib/script/script.js#L541|Bitcore]] -* [[https://github.com/haskoin/haskoin/blob/master/Network/Haskoin/Script/Parser.hs#L112-122|Haskoin]] Bitcoin implementation in haskell +* [[https://github.com/haskoin/haskoin-core/blob/b41b1deb0989334a7ead6fc993fb8b02f0c00810/haskoin-core/Network/Haskoin/Script/Parser.hs#L112-L122|Haskoin]] - Bitcoin implementation in Haskell * [[https://github.com/etotheipi/BitcoinArmory/blob/268db0f3fa20c989057bd43343a43b2edbe89aeb/armoryengine/ArmoryUtils.py#L1441|Armory]] * [[https://github.com/bitcoinj/bitcoinj/blob/master/core/src/main/java/org/bitcoinj/script/ScriptBuilder.java#L331|BitcoinJ]] diff --git a/bip-0119.mediawiki b/bip-0119.mediawiki index 0de7eb0..e887caf 100644 --- a/bip-0119.mediawiki +++ b/bip-0119.mediawiki @@ -167,6 +167,12 @@ specification for the semantics of OP_CHECKTEMPLATEVERIFY. } break; +Where + + bool CheckDefaultCheckTemplateVerifyHash(const std::vector<unsigned char>& hash) { + return GetDefaultCheckTemplateVerifyHash(current_tx, current_input_index) == uint256(hash); + } + The hash is computed as follows: uint256 GetDefaultCheckTemplateVerifyHash(const CTransaction& tx, uint32_t input_index) { diff --git a/bip-0300.mediawiki b/bip-0300.mediawiki index 08f8994..f8c9b4d 100644 --- a/bip-0300.mediawiki +++ b/bip-0300.mediawiki @@ -15,143 +15,181 @@ ==Abstract== -A "Hashrate Escrow" is a clearer term for the concept of "locked to an SPV Proof", which is itself a restatement of the phrase "within a sidechain" as described in [https://blockstream.com/sidechains.pdf the 2014 Blockstream whitepaper]. +In Bip300, txns are not signed via cryptographic key. Instead, they are "signed" by the accumulation of hashpower over time. -A Hashrate Escrow resembles a 2-of-3 multisig escrow, where the 3rd party (who will arbitrate any disputes) is a decentralized group of people: the dynamic-membership set of Bitcoin Miners. However, the 3rd party does not sign escrow-withdrawal transactions with a private key. Instead, these are "signed" by the accumulation of hashpower over time. +Bip300 emphasizes slow, transparent, auditable transactions which are easy for honest users to get right and very hard for dishonest users to abuse. The chief design goal for Bip300 is ''partitioning'' -- users may safely ignore Bip300 txns if they want to (or Bip300 entirely). -This project has [http://www.drivechain.info/ a website] which includes [http://www.drivechain.info/faq/index.html an FAQ]. +See [http://www.drivechain.info/ this site] for more information. ==Motivation== -In practice these escrows are likely to be "asymmetric sidechains" of Bitcoin (such as [http://www.rsk.co/ Rootstock]) or "virtual chains" within Bitcoin (such as [https://github.com/blockstack/virtualchain proposed by Blockstack] in mid-2016). -Sidechains have many potential benefits, including: +As Reid Hoffman [https://blockstream.com/2015/01/13/en-reid-hoffman-on-the-future-of-the-bitcoin-ecosystem/ wrote in 2014]: "Sidechains allow developers to add features and functionality to the Bitcoin universe without actually modifying the Bitcoin Core code...Consequently, innovation can occur faster, in more flexible and distributed ways, without losing the synergies of a common platform with a single currency." -# Protect Bitcoin from competition from altcoins and spinoffs. -# Protect Bitcoin from hard fork campaigns. (Such campaigns represent an existential threat to Bitcoin, as well as an avenue for developer corruption.) -# Help with review, by making it much easier for reviewers to ignore bad ideas. -# Provide an avenue for good-but-confusing ideas to prove their value safely. +Coins such as Namecoin, Monero, ZCash, and Sia, offer features that Bitcoiners cannot access -- not without selling their BTC to invest in a rival monetary unit. According to [https://coinmarketcap.com/charts/#dominance-percentage coinmarketcap.com], there is now more value *outside* the BTC protocol than within it. According to [https://cryptofees.info/ cryptofees.info], 10x more txn fees are paid outside the BTC protocol, than within it. +Software improvements to Bitcoin rely on developer consensus -- BTC will pass on a good idea if it is even slightly controversial. Development is slow: we are now averaging one major feature every 5 years. +Sidechains allow for competitive "benevolent dictators" to create a new sidechain at any time. These dictators are accountable only to their users, and (crucially) they are protected from rival dictators. Users can move their BTC among these different pieces of software, as *they* see fit. -==Specification== - -==== Components ==== - -Hashrate Escrows are built of two types of component: [1] new databases, and [2] new message-interpretations. - -===== 1. New Databases ===== +BTC can copy every useful technology, as soon as it is invented; scamcoins lose their justification and become obsolete; and the community can be pro-creativity, knowing that Layer1 is protected from harmful changes. -* D1. "Escrow_DB" -- a database of "accounts" and their attributes. -* D2. "Withdrawal_DB" -- a database of pending withdrawals from these accounts, and their statuses. +==Specification== -Please note that these structures (D1 and D2) will not literally exist anywhere in the blockchain. Instead they are constructed from messages...these messages, in contrast, *will* exist in the blockchain (with the exception of M4). +Bip300 allows for six new blockchain messages: -===== 2. New Messages ===== +* M1. "Propose New Sidechain" +* M2. "ACK Proposal" +* M3. "Propose Bundle" +* M4. "ACK Bundle" +* M5. Deposit -- a transfer of BTC from-main-to-side +* M6. Withdrawal -- a transfer of BTC from-side-to-main -* M1. "Propose New Escrow" -* M2. "ACK Escrow Proposal" -* M3. "Propose Withdrawal" -* M4. (implied) "ACK Withdrawal" -* M5. "Execute Deposit" -- a transfer of BTC from-main-to-side -* M6. "Execute Withdrawal" -- a transfer of BTC from-side-to-main +Nodes organize those messages into two caches: +* D1. "Escrow_DB" -- tracks the 256 Hashrate Escrows (Escrows slots that a sidechain can live in). +* D2. "Withdrawal_DB" -- tracks the withdrawal-Bundles (coins leaving a Sidechain). +We will cover: +# Adding Sidechains (D1, M1, M2) +# Approving Withdrawals (D2, M3, M4) +# Depositing and Withdrawing (M5, M6) === Adding Sidechains (D1, M1, M2) === -==== D1 -- "Escrow_DB" ==== -The table below enumerates the new database fields, their size in bytes, and their purpose. In general, an escrow designer (for example, a sidechain-designer), is free to choose any value for these. +==== D1 -- "Escrow_DB" ==== +The table below enumerates the new database fields, their size in bytes, and their purpose. A sidechain designer is free to choose any value for these. {| class="wikitable" +|- style="font-weight:bold; text-align:center; vertical-align:middle;" ! Field No. ! Label ! Type ! Description / Purpose -|- +|- style="vertical-align:middle;" | 1 | Escrow Number | uint8_t -| A number assigned to the entire escrow. Used to make it easy to refer to each escrow. +| The escrow's ID number. Used to uniquely refer to each sidechain. |- | 2 -| Sidechain Deposit Script Hex -| string -| The script that will be deposited to, and update the CTIP of the sidechain. +| Version +| int32_t +| Version number. |- | 3 +| String KeyID +| string +| Used to derive all sidechain deposit addresses. +|- +| 4<br /> | Sidechain Private Key | string | The private key of the sidechain deposit script. -|- -| 4 -| Escrow Name +|- style="vertical-align:middle;" +| 5<br /> +| ScriptPubKey +| CScript +| Where the sidechain coins go. This always stays the same, even though the CTIP (UTXO) containing the coins is always changing. +|- style="vertical-align:middle;" +| 6 +| Sidechain Name | string | A human-readable name of the sidechain. -|- -| 5 -| Escrow Description -| string -| A human-readable name description of the sidechain. More than enough space to hold a 32 byte hash. -|- -| 6 -| Hash ID 1 -| uint256 -| A field of 32 bytes, which could be any bytes such as a sha256 hash. -|- +|- style="vertical-align:middle;" | 7 -| Hash ID 2 +| Sidechain Description +| string +| A human-readable name description of the sidechain. +|- style="vertical-align:middle;" +| 8 +| Hash1 - tarball hash | uint256 -| A field of 32 bytes, which could be any bytes such as a sha256 hash. +| Intended as the sha256 hash of the tar.gz of the canonical sidechain software. (This is not enforced anywhere by Bip300, and is for human purposes only.) +|- style="vertical-align:middle;" +| 9 +| Hash2 - git commit hash +| uint160 +| Intended as the git commit hash of the canonical sidechain node software. (This is not enforced anywhere by Bip300, and is for human purposes only.) |- -| 8 +| 10 +| Active +| bool +| Does this sidechain slot contain an active sidechain?<br /> +|- style="vertical-align:middle;" +| 11 | "CTIP" -- Part 1 "TxID" | uint256 -| The CTIP, or "Critical (TxID, Index) Pair" is a variable for keeping track of where the escrow's money is (ie, which member of the UTXO set). -|- -| 9 +| The CTIP, or "Critical (TxID, Index) Pair" is a variable for keeping track of where the sidechain's money is (ie, which member of the UTXO set). +|- style="vertical-align:middle;" +| 12 | "CTIP" -- Part 2 "Index" | int32_t -| Of the CTIP, this is second element of the pair: the Index. See #9 above. -|- +| Of the CTIP, the second element of the pair: the Index. See #11 above. |} D1 is updated via M1 and M2. -( The following messages were modeled on SegWit -- see [https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#commitment-structure here] and [https://github.com/DriveNetTESTDRIVE/DriveNet/blob/564516653c1d876429382971a011f5f6119f7eb4/src/validation.cpp#L3348-L3375 here]. ) - ==== M1 -- "Propose New Sidechain" ==== +Examples: + +<img src="bip-0300/m1-gui.jpg?raw=true" align="middle"></img> + +<img src="bip-0300/m1-cli.png?raw=true" align="middle"></img> + +M1 is a coinbase OP Return output containing the following: + 1-byte - OP_RETURN (0x6a) - 4-byte - Commitment header (0xD5E0C4AF) + 4-byte - Message header (0xD5E0C4AF) N-byte - The serialization of the sidechain. - + 1-byte nSidechain + 4-byte nVersion + x-byte strKeyID + x-byte strPrivKey + x-byte scriptPubKey + x-byte title + x-byte description + 32-byte hashID1 + 20-byte hashID2 + +M1 is used in conjunction with M2. ==== M2 -- "ACK Sidechain Proposal" ==== 1-byte - OP_RETURN (0x6a) - 4-byte - Commitment header (0xD6E1C5BF) - 32-byte - Commitment hash: sha256D hash of sidechain's serialization + 4-byte - Message header (0xD6E1C5BF) + 32-byte - sha256D hash of sidechain's serialization -==== New Block Validation Rules ==== +==== M1/M2 Validation Rules ==== +# Any miner can propose a new sidechain at any time. This procedure resembles BIP 9 soft fork activation: the network must see a properly-formatted M1, followed by "acknowledgment" of the sidechain in 90% of the following 2016 blocks. +# It is possible to "overwrite" a sidechain. This requires more ACKs -- 50% of the following 26300 blocks must contain an M2. The possibility of overwrite, does not change the security assumptions (because we already assume that users perform extra-protocolic validation at a rate of 1 bit per 26300 blocks). -# Escrows are added in a procedure that resembles BIP 9 soft fork activation: the network must see a properly-formatted M1, followed by "acknowledgment" of the sidechain in 95% of the following 2016 blocks. -# It is possible to "overwrite" an escrow. This requires 6 months (26298 blocks) of M2s, instead of 2 weeks (XXXX). This possibility does not change the security assumptions (because we already assume that users perform extra-protocolic validation at a rate of 1 bit per 26298 blocks). +=== Approving Withdrawals (D2, M3, M4) === +Withdrawals in Bip300 (ie, "M6"), are very significant. So, we will first discuss how these are approved/rejected -- a process involving M3, M4, and D2. + +==== What are Bundles? ==== + +All Bip300 withdrawals take the form of “Bundles” (formerly known as “WT^s”) -- named because they "bundle up" many individual withdrawal-requests into one single rare layer1 transaction. + +This bundle either pays all of the withdrawals out, or else it fails (and pays nothing out). Bip300 / layer 1 does not assemble Bundles (the sidechain developer does this in a manner of their choosing). + +Bundles are identified by a 32-byte hash, which aspires to be the TxID of M6. Unfortunately, the Bundle-hash and M6-TxID cannot match exactly, since the first input to M6 is a CTIP which is constantly changing. So, we must accomplish a task, which is conceptually similar to AnyPrevOut (BIP 118). We define a "blinded TxID" as a way of hashing a txn, in which some bytes are first overwritten with zeros. In our case, these bytes are the first input and the first output. + +D2 controls Bundles, and is driven by M3, M4, M5, and M6. -=== Withdrawing from Escrows (D2, M3, M4) === ==== D2 -- "Withdrawal_DB" ==== -D2 changes deterministically with respect to M3, M4, M5, and M6. {| class="wikitable" ! Field No. @@ -160,117 +198,108 @@ D2 changes deterministically with respect to M3, M4, M5, and M6. ! Description / Purpose |- | 1 -| Escrow Number +| Sidechain Number | uint8_t -| Links the withdrawal-request to a specific escrow. +| Links the withdrawal-request to a specific hashrate escrow. |- | 2 -| WT^ Hash +| Bundle Hash | uint256 -| This is a "blinded transaction id" (ie, the double-Sha256 of a txn that has had two fields zeroed out, see M6) of a withdrawal-attempt. +| A withdrawal attempt. Specifically, it is a "blinded transaction id" (ie, the double-Sha256 of a txn that has had two fields zeroed out, see M6) of a txn which could withdraw funds from a sidechain. |- | 3 | ACKs (Work Score) | uint16_t -| The current total number of ACKs (PoW) +| The current total number of ACKs (the PoW that has been used to validate the Bundle). |- | 4 | Blocks Remaining (Age) | uint16_t -| The number of blocks which this WT^ has remaining to accumulate ACKs +| The number of blocks which this Bundle has remaining to accumulate ACKs |} +A hash of D2 exists in each coinbase txn, and has consensus-significance. -==== New Block Validation Rules for D2 ==== +==== D2 Validation Rules ==== -# A hash commitment to D2 exists in each block (even if D2 is blank). -# Withdrawals in D2 are sorted first by field #1 (Escrow Number) and second by field #4 (Age). This imposes a unique sort. -# From one block to the next, "Age" fields must increase by exactly 1. -# Withdrawals are stored in D2 until they fail ("Age" = "MaxAge"), or they succeed (the blockchain contains a txn whose blinded txID matches "WT^"). +# The D2 hash commitment must be in each block (unless D2 is blank). +# The Bundles must be listed in a canonical order (so that the hashes match). +# From one block to the next, "Age" fields must increase by exactly 1 (ie, Blocks Remaining decreases by 1). +# Bundles are stored in D2 until they fail (which occurs at "Age" = "MaxAge"), or they succeed (Bundle is paid out). +# From one block to the next, the value in the ACKs field can increase or decrease by a maximum of 1 (see below). -In addition, there are special rules for the "ACKs" field (see M4 below). +If a Bundle succeeds (in D2), it "becomes" an M6 message and is included in a block. -==== M3 -- "Propose Withdrawal" ==== +So, first: how do we add a Bundle to D2? + +==== M3 -- "Propose Bundle" ==== + + +Nodes will add an entry to D2 if there is a coinbase output with the following: 1-byte - OP_RETURN (0x6a) - 1-byte - Push the following 36 bytes (0x24) 4-byte - Commitment header (0xD45AA943) - 32-byte - The WT^ hash to populate a new D2 entry + 32-byte - The Bundle hash, to populate a new D2 entry -==== New Block Validation Rules for M3 ==== +==== M3 Validation Rules ==== -# If the network detects a properly-formatted M3, it must add an entry to D2 in the very next block. The starting values of fields #3 and #4 are zero, and #5 is pulled over by extracting the relevant value from D1. +# If the network detects a properly-formatted M3, it must add an entry to D2 in the very next block. The starting Blocks Remaining value is 26,299. The starting ACKs count is 1. # Each block can only contain one M3 per sidechain. +Once a Bundle is in D2, how can we give it enough ACKs to make it valid? ==== M4 -- "ACK Withdrawal" ==== -M4 is a way of describing changes to the "ACKs" column of D2. - From one block to the next, "ACKs" can only change as follows: -* The ACK-counter of any withdrawal can only change by (-1,0,+1). -* Within a sidechain-group, upvoting one withdrawal ("+1") requires you to downvote all other withdrawals in that group. However, the minimum ACK-value is zero (and, therefore, downvotes cannot reduce it below zero). -* While only one withdrawal can be upvoted at once, they can all be unchanged at once ("abstain") and they can all be downvoted at once ("alarm"). +* The ACK-counter of any Bundle can only change by (-1,0,+1). +* Within a sidechain-group, upvoting one Bundle ("+1") requires you to downvote all other Bundles in that group. However, the minimum ACK-value is zero. +* While only one Bundle can be upvoted at once; the whole group can all be unchanged at once ("abstain"), and they can all be downvoted at once ("alarm"). -One option for explicit transmission of M4 is: +M4 does not need to be explicitly transmitted. It can simply be inferred from the new state of D2. M4 can therefore be improved over time, without affecting consensus. - 4-byte - Message identifier (0x????????) - 1-byte - Version of this message - 1-byte - Length (in bytes) of this message; total number of withdrawal attempts; y = ceiling( sum_i(m_i +2)/8 ). Nodes should already know what length to expect, because they know the sequence of M3s and therefore the vector of WT^s. - N-byte - stream of bits (not bytes), with a 1 indicating the position of the chosen action [downvote all, abstain, upvote1, upvote2, ...] +Nonetheless, one option for explicit transmission of M4 is [https://github.com/drivechain-project/mainchain/blob/8901d469975752d799b6a7a61d4e00a9a124028f/src/validation.cpp#L3735-L3790 in our code]. -But sometimes M4 does not need to be transmitted at all! If there are n Escrows and m Withdrawals-per-escrow, then there are (m+2)^n total candidates for the next D2. So, when m and n are low, all of the possible D2s can be trivially computed in advance. +Often, M4 does not need to be transmitted at all. If there are n Sidechains and m Withdrawals-per-sidechain, then there are (m+2)^n total candidates for the next D2. So, when m and n are low, all of the possible D2s can be trivially computed in advance. -Miners can impose a "soft limit" on m, blocking new withdrawal-attempts until previous ones expire. For a worst-case scenario of n=200 and m=1,000, honest nodes can communicate M4 with ~25 KB per block [4+1+1+(200\*(1000+1+1)/8)]. +Miners can impose a "soft limit" on m, blocking new withdrawal-attempts until previous ones expire. Even if they fail to do this, a a worst-case scenario of n=200 and m=1,000, honest nodes can communicate the M4 with ~25 KB per block [4+1+1+(200\*(1000+1+1)/8)]. +Finally, we give Deposits and Withdrawals. -=== Depositing and Withdrawing (M5, M6) === +=== Deposits and Withdrawals (M5, M6) === -Both M5 and M6 are regular Bitcoin txns. They are identified by meeting an important criteria: they select a one of the Critical TxID-index Pairs (a "CTIP") as one of their inputs. +Both M5 and M6 are regular Bitcoin txns. They are identified, as Deposits/Withdrawals, when they select one of the special CTIP UTXOs as one of their inputs (see D1). -Just as these txns must select a CTIP input, they must create a new CTIP output. D1 is then updated to match only the latest CTIP output. The purpose of this is to have all of the escrow's money (ie all of the sidechain's money) in one TxID, so that depositors immediately undo any UTXO bloat they may cause. -Deposits ("M5") are distinguished from withdrawals ("M6") by simply checking to see if money is "going in", or "out". +All of a sidechain’s coins, are stored in one UTXO. (Deposits/Withdrawals never cause UTXO bloat.) So, each Deposit/Withdrawal must select a CTIP, and generate a new CTIP (this is tracked in D1, above). -https://github.com/DriveNetTESTDRIVE/DriveNet/blob/564516653c1d876429382971a011f5f6119f7eb4/src/validation.cpp#L647-L742 +If the from-CTIP-to-CTIP quantity of coins goes '''up''', (ie, if the user is adding coins), then the txn is treated as a Deposit (M5). Else it is treated as a Withdrawal (M6). See [https://github.com/drivechain-project/mainchain/blob/8901d469975752d799b6a7a61d4e00a9a124028f/src/validation.cpp#L668-L781 here]. ==== M5. "Make a Deposit" -- a transfer of BTC from-main-to-side ==== -As far as mainchain consensus is concerned, deposits to the escrow are always valid. - -However, in practice there will be additional requirements. The escrow account (ie the "sidechain") needs to know how to credit depositors. One well-known method, is for mainchain depositors to append a zero-value OP Return to a Deposit txn, so that the sidechain knows how to credit funds. Mainchain users must upgrade their wallet software, of course, (on an individual basis) in order to become aware of and take advantage of new deposit-methods. - - +As far as mainchain consensus is concerned, all deposits to a sidechain are always valid. ==== M6. "Execute Withdrawal" -- a transfer of BTC from-side-to-main ==== -We come, finally, to the critical matter: where users can take their money *out* of the escrow account, and return it to the "regular" UTXO set. As previously mentioned, this txn is one which (a) spends from a CTIP and (b) reduces the quantity of BTC in an account's CTIP. Most of the work has already been done by D1, M3, M4, and D2. Furthermore, existing Bitcoin tx-rules prevent the sidechain from ever withdrawing more money than has been placed into it. +We come, finally, to the critical matter: where users can take their money *out* of the sidechain. -In each block, a withdrawal in D2 is considered "approved" if its "ACKs" value meets the threshold (13,150). +In each block, a Bundle in D2 is considered "approved" if its "ACKs" value meets the threshold (13,150). -Approved withdrawals give the green light to their respective "WT^". A "WT^" is 32-bytes which aspire to represent the withdrawing transaction (the txn that actually withdraws funds from the escrow). The two cannot match exactly, because "WT^" is defined at onset, and the withdrawing TxID depends on the its CTIP input (which is constantly changing). -To solve this, we define a "blinded TxID" as a way of hashing a txn, in which some bytes are first overwritten with zeros. Specifically, these bytes are the first input and the first output. +The Bundle must meet all these criteria: -So, withdrawals must meet the following three criteria: - -# "Be ACKed" -- The "blinded TxID" of this txn must be member of the "approved candidate" set in the D2 of this block. -# "Return Change to Account" -- TxOut0 must pay to the "critical account" (see D1) that corresponds to the CTIP that was selected as a TxIn. +# "Be ACKed" -- The "blinded TxID" of this txn must be a member of the "approved candidate" set in the D2 of this block. +# "Return Change to Account" -- TxOut0 must pay coins back to the sidechain's CTIP. # "Return *all* Change to Account" -- Sum of inputs must equal the sum of outputs. No traditional tx fee is possible. - - - ==Backward compatibility== - As a soft fork, older software will continue to operate without modification. Non-upgraded nodes will see a number of phenomena that they don't understand -- coinbase txns with non-txn data, value accumulating in anyone-can-spend UTXOs for months at a time, and then random amounts leaving the UTXO in single, infrequent bursts. However, these phenomena don't affect them, or the validity of the money that they receive. -( As a nice bonus, note that the sidechains themselves inherit a resistance to hard forks. The only way to guarantee that the WT^s reported by different clients will continue to match identically, is to upgrade sidechains via soft forks of themselves. ) +( As a nice bonus, note that the sidechains themselves inherit a resistance to hard forks. The only way to guarantee that a sidechain's Bundles will continue to match identically, is to upgrade sidechains via soft forks of themselves. ) ==Deployment== @@ -281,10 +310,9 @@ This BIP will be deployed by "version bits" BIP9 with the name "hrescrow" and us <pre> // Deployment of Drivechains (BIPX, BIPY) consensus.vDeployments[Consensus::DEPLOYMENT_DRIVECHAINS].bit = 4; -consensus.vDeployments[Consensus::DEPLOYMENT_DRIVECHAINS].nStartTime = 1579072881; // January 15th, 2020. -consensus.vDeployments[Consensus::DEPLOYMENT_DRIVECHAINS].nTimeout = 1610695281; // January 15th, 2021. +consensus.vDeployments[Consensus::DEPLOYMENT_DRIVECHAINS].nStartTime = 1642276800; // January 15th, 2022. +consensus.vDeployments[Consensus::DEPLOYMENT_DRIVECHAINS].nTimeout = 1673812800; // January 15th, 2023. </pre> - ==Reference Implementation== diff --git a/bip-0300/appendix-1.txt b/bip-0300/appendix-1.txt deleted file mode 100644 index 736a6c4..0000000 --- a/bip-0300/appendix-1.txt +++ /dev/null @@ -1,45 +0,0 @@ - -==== Two Withdrawals at Once ==== - -Currently, the documentation and code describe a situation where only one withdrawal can proceed at a time. As a result, one "train" (carrying everyone's withdrawals) leaves the station every 3 months, and takes 3-6 months to reach its destination. - -Thus, if a withdrawing-user is very unlucky, and "just misses" the train, this user must wait double-long. First, (s)he must wait for the missed-train to reach its destination. Second, (s)he must board the new train, and wait for *it* to reach its destination. Each of these steps takes 3-6 months. - -So, even when withdrawals always go as quickly as possible (3 months each), the total time varies, from 3 months (0 months waiting + 3 months travel) to 6 months (3 months waiting + 3 months travel). The average is 4.5 months. - -To improve this, we allow for slightly different behavior if the highest-ACK-withdrawal [1st] has an ACK score >= 6575; and [2nd] is not tied with any other withdrawal. - -Basically: a second train can leave, if the furthest train is 50+% of the way to its destination. - -So, previously, for m trains, M4 could be any of the following: - - abstain - alarm (move all trains backwards) - move train #1 forward (and others backwards) - move train #2 forward (and others backwards) - ... - move train #3 forward (and others backwards) - -If our new special conditions apply, we now double the (m-1) elements, to accommodate a second train: - - |abstain - |alarm (move all trains backwards) - - |advance furthest train + advance train #1 (regress all others) - |advance furthest train + advance train #2 (regress all others) - |... - |advance furthest train + advance train #(m-1) (regress all others) - - |regress furthest train + advance train #1 (regress all others) - |regress furthest train + advance train #2 (regress all others) - |... - |regress furthest train + advance train #(m-1) (regress all others) - - -It is theoretically possible (but in practice probably impossible) to troll this rule, by getting two (or even three) withdrawals to have >6575 ACK scores, and then getting these to *tie* for first place. Then they'd both be furthest. Hence the second condition prohibiting this new behavior, if the furthest trains have any ACK-score ties. - -This simple change, which has almost zero impact on the security assumptions, improves the monthly total wait times drastically: - - Worst-case: 6 --> 4.5 - Average: 4.5 --> 3.75 - Std Dev: ~.91 --> ~.45 diff --git a/bip-0300/m1-cli.png b/bip-0300/m1-cli.png Binary files differnew file mode 100644 index 0000000..2454848 --- /dev/null +++ b/bip-0300/m1-cli.png diff --git a/bip-0300/m1-gui.jpg b/bip-0300/m1-gui.jpg Binary files differnew file mode 100644 index 0000000..edae79c --- /dev/null +++ b/bip-0300/m1-gui.jpg diff --git a/bip-0300/two-groups.png b/bip-0300/two-groups.png Binary files differdeleted file mode 100644 index c8a3ffa..0000000 --- a/bip-0300/two-groups.png +++ /dev/null diff --git a/bip-0301.mediawiki b/bip-0301.mediawiki index d6056f2..2f6b79e 100644 --- a/bip-0301.mediawiki +++ b/bip-0301.mediawiki @@ -12,181 +12,151 @@ License: BSD-2-Clause </pre> -==Abstract== - -Blind Merged Mining (BMM) is a way of mining optional extension blocks (ie, "asymmetric sidechains"). BMM produces weak guarantees that the block is valid, for *any* arbitrary set of rules; and yet it does so without requiring miners to actually do any validation on the block whatsoever. +==Abstract== -BMM actually is a process that spans two or more chains. Here we focus on the modifications to mainchain Bitcoin. For an explanation of the "whole picture", please see [http://www.truthcoin.info/blog/blind-merged-mining/ this post]. +Blind Merged Mining (BMM) allows miners to mine a Sidechain/Altcoin, without running its node software (ie, without "looking" at it, hence "blind"). -Our goal here, is to allow mainchain miners to trustlessly "sell" the act of finding a sidechain block. +Instead, a separate sidechain user runs their node and constructs the block, paying himself the transaction fees. He then uses an equivalent amount of money to "buy" the right to find this block, from the conventional layer1 Sha256d miners. ==Motivation== -Regular "Merged-Mining" (MM) allows miners to reuse their hashing work to secure other chains (for example, as in Namecoin). However, traditional MM has two drawbacks: - -# Miners must run a full node of the other chain. (This is because [while miners can effortlessly create the block] miners will not create a valid payment to themselves, unless the block that they MM is a valid one. Therefore, miners must assemble a *valid* block first, then MM it.) -# Miners are paid on the other chain, not on the regular BTC mainchain. For example, miners who MM Namecoin will earn NMC (and they will need to sell the NMC for BTC, before selling the BTC in order to pay for electricity). - -BMM addresses both shortcomings. - - -==Specification== - -Note: This document uses the notation side:\* and main:\* in front of otherwise-ambiguous words (such as "block", "node", or "chain"), to distinguish the mainchain version from its sidechain counterpart. We also use "Simon" to refer to a Sidechain Full Node, and "Mary" to refer to a mainchain miner. - - -=== BMM Request === - -To buy the right to find a sidechain block, users broadcast BMM Requests. - -Here, these can take two forms. The first does not require the Lightning Network, but it does have new requirements for Immediate Expiration (see below). The second inherits Immediate Expiration from the Lightning Network itself, but requires extra preparation and a different/larger message. +"Merged-Mining" (MM) allows miners to reuse their hashing work to secure other chains (for example, as in Namecoin). -Both forms require that certain Critical Data will be committed to within the coinbase of the block that the transaction is included in (see BMM Accept). For the OnChain (non-Lightning) version, we have created a new extended serialization transaction type (very similar to how SegWit handles witness data (the witness stack)). +However, traditional MM has two drawbacks: -==== Immediate Expiration ("Fill-or-Kill") ==== +# Miners must run a full node of the other chain(s). (Thus, they must run "non-Bitcoin" software which may be buggy.) +# Miners are paid on the other chain, in Alt-currency. (Miners who MM Namecoin, will earn NMC.) -We would like to make special guarantees to the counterparties of this transaction. Specifically, instead of Simon making a "payment" to Mary, we prefer that Simon give Mary an "offer" (which she can either accept or decline). -Crucially, we want Simon to safely make many offers to several different Mary's, in realtime (ie, quickly and off-chain). However, we ultimately want only one offer to be accepted, at most. In other words, we want Simon's offers to *immediately expire*. If only one offer can become a bona fide transaction, then Simon will feel comfortable making multiple offers all day long. Because all of the Simons are making many offers, the Marys collectively gain access to a large set of offers to choose from. +==Notation and Example== -==== OnChain BMM Request ==== +Note: We use notation side:\* and main:\* in front of otherwise-ambiguous words (such as "block", "node", or "chain"), to sort the mainchain version from its sidechain counterpart. We name all sidechain users "Simon", and name all mainchain miners "Mary". -OnChain BMMRs do not require the Lightning network, but they do have new requirements for validation. +Example: imagine that a sidechain block contains 20,000 txns, each paying a $0.10 fee; therefore, the block is worth $2000 of fee-revenue. As usual: the sidechain's coinbase txn will pay this $2000 to someone (in this case, "Simon"). Under Bip301, Simon does no hashing, but instead makes one layer1 txn paying $1999 to the layer1 miners ("Mary"). -===== Structure ===== -The following data is required: +{| class="wikitable" +|- +! colspan="3" | Upon finding a sidechain block worth $2000... +|- style="font-weight:bold; text-decoration:underline;" +| Item +| Layer1 Miner ("Mary") +| Sidechain User ("Simon") +|- +| Runs a sidechain node? +| No +| Yes +|- +| How much hashing? +| 100% +| 0% +|- +| Coins collected, on Layer2 +| $0 +| $2000 +|- +| Coins paid out, on Layer1 +| $0 +| $1999 +|- +| Coins rec'd, on Layer1 +| $1999 +| $0 +|- +| d(Net Worth) +| +$1999 +| +$1 +|} -<pre> - 32-bytes - h* sideHeaderHash - ?~?-bytes - critical data extended serialization - 3-bytes - 0x00bf00 identifying bytes - 1-byte - nSidechain - 2-bytes - prevSideBlockRef - 4-bytes - prevMainHeaderBytes -</pre> -sideHeaderHash comes from side:chain (side:nodes build side:blocks/headers). The identifying bytes are given here. nSidechain identifies which sidechain we are BMMing. By the time Blind Merged Mining can take place, it is known globally. +Bip301 makes this specialization-of-labor trustless on layer1. If Mary takes Simon's money, then she must let Simon control the side:block. -prevBlockRef, is a little more complicated (next section). -To qualify for inclusion in a block, BMM requests are subject to the following requirements: -# Requests must match a corresponding "BMM Accept" (see last section of BIP). -# At most, only one Request is allowed in a main:block, per sidechain. In other words, if 700 users broadcast BMM Requests for sidechain #4, then the main:miner must choose one single Request to include. -# The 4-bytes of prevMainHeaderBytes must match the last four bytes of the previous main:blockheader. Thus, Simon's txns are only be valid for the current block, in the block history that he knows about (and therefore, the current sidechain history that he knows about). - -===== prevBlockRef ===== - -prevBlockRef is an integer that counts the number of "skips" one must take in the side:chain in order to find the current side:block's parent block. This value is zero unless the sidechain is reorganizing (or skipping over invalid sidechain blocks). If a side:node wants to orphan the most-recent N blocks, the value of the current block will be equal to N; in the block after that it will be back to zero. - -<img src="bip-0301/bmm-dots-examples.png?raw=true" align="middle"></img> +==Specification== -Above: Three blockchains, with different max length (small number), reorganization histories, and prevBlockRef numbers (larger numbers beneath blocks). The ordering given via each side:block's "prevSideBlockRef" will be isomorphic to an ordering given by each side:block's "prevSideHeaderHash" ("prevSideHeaderHash is the sidechain's equivalent of the mainchain's "prevBlockHash"). One can freely convert from one to the other. -===== Extended Serialization ===== +Bip300 consists of two messages: "BMM Accept" and "BMM Request". These govern something called "h*". -To impose new requirements at the transaction level, we borrow the dummy vin & "flag" trick from SegWit style transactions. Unless all of the requirements for sidechain critical data transactions are met by the block it is included in, the transaction is invalid. With SegWit, this extra data is the SegWit signature stack, and the extra requirements are the signatures' locations and validity. In the sidechain BMM critical data transactions, the extra data is the (nSidechain, h\*) pair, which must meet the first two requirements (above) as well as the main:blocknumber, which must meet the third requirement (above). +So we will discuss: -<img src="bip-0301/witness-vs-critical.png?raw=true" align="middle"></img> +# h* -- The sidechain's hashMerkleRoot, and why it matters. +# "BMM Accept" -- How h* enters a main:coinbase. When Mary "accepts" a BMM Request, Mary is ''endorsing a side:block''. +# "BMM Request" -- Simon offering money to Mary, if (and only if) she will Endorse a specific h*. When Simon broadcasts a BMM Request, Simon is ''attempting a side:block''. -Above: A chart showing normal txns, SegWit txns, and CriticalData txns. The specific SegWit txn can be seen [http://srv1.yogh.io/#tx:id:D4A99AE93DF6EE3D4E42CE69338DFC1D06CCD9B198666E98FF0588057378D3D9 here]. -These types of transactions have slightly different mempool behavior, and should probably be kept in a second mempool. These txns are received, checked immediately, and if valid they are evaluated for inclusion in a block. If they are not able to be included in the specific requested block (if the block height requested has been surpassed by the chain tip), they are discarded. In fact, after any main:block is found, everything in this "second mempool" can be discarded as new payments will be created immediately for the next block height. (This includes cases where the blockchain reorganizes.) There is no re-evaluation of the txns in this mempool ever -- they are evaluated once and then either included or discarded. They never need to be rescanned. +=== h* === -Interestingly, these payments will *always* be directed to main:miners from non-main:miners. Therefore, non-mining full nodes do not need to keep them in any mempool at all. Non-miner nodes can just wait for a block to be found, and check the txn then. These transactions more resemble a stock market's pit trade-offers (in contrast, regular Bitcoin txns are more like paper checks). +h* ("h star") is the sidechain's Merkle Root hash. -==== Lightning BMM Request ==== +In Bip301, a sidechain's coinbase txn acts as a header (it contains the hash of the previous side:block, and previous main:block). Thus, the MerkleRoot contains everything important. -Lightning BMMRs require Simons to have a LN-channel pathways open with Marys. This may not always be practical (or even possible), especially today. +Note: in Bip301 sidechains, "headers" and "block hashes" do not have significant consensus meaning and are in the design mainly to help with IBD. (In the mainchain, in contrast, headers and block hashes determine the difficulty adjustments and cumulative PoW.) -LN txns cannot make use of prevSideBlockRef, as no one knows for sure when (or if) they will be broadcast on-chain. Instead, they must use prevSideBlockHash. But they otherwise require the same data: +<img src="bip-0301/sidechain-headers.png?raw=true" align="middle"></img> -<pre> - 4-bytes - Message header (0xD0520C6E) - 1-byte - sidechain number - 32-bytes - h* side:block hash - 32-bytes - prevSideBlockHash -</pre> -Notice that, in OnChain BMMRs, Simon could reuse the same h\* all he wanted, because only one OnChain BMMR could be included per main:block per sidechain. However, on the LN no such rule can be enforced, as the goal is to push everything off-chain and include *zero* txns. So, we will never know what the Requests were, or how many had an effect on anything. +Above: h* is located in the main:coinbase. h* contains all side:txns, including the side:coinbase. The side:coinbase contains many "header-like" fields, such as the hash of the previous side:block. -Therefore, Simon will need to ensure that he '''gives each Mary a different h\*'''. Simon can easily do this, as he controls the side:block's contents and can simply increment a side:nonce -- this changes the side:block, and changes its hash (ie, changes h\*). +Mary controls the main:coinbase, so she may select any h*. Her selection will determine which side:block is "found". -With a unique h\* per Mary (or, more precisely, per channel), and at most 1 h\* making it into a block (per sidechain), Simon can ensure that he is charged, at most, one time. -That's probably confusing, so here is an example, in which: Simon starts with 13 BTC, Mary starts with 40 BTC, the side:block's tx-fees currently total 7.1 BTC, and Simon is keeping 0.1 BTC for himself and paying 7 BTC to Mary. +=== BMM Accept === -We start with (I): +To "Accept" the BMM proposal (and to accept Simon's money), Mary must endorse Simon's block. <pre> - Simon 13 in, Mary 40 in ; 53 in total - Simon's version [signed by Mary] - 13 ; to Simon if TimeLock=over; OR to Mary if SimonSig - 40 ; to Mary - Mary's version [signed by Simon] - 40 ; to me if TimeLock=over; OR to Simon if MarySig - 13 ; to Simon +For each side:block Mary wishes to endorse, Mary places the following into a main:coinbase OP_RETURN: + 1-byte - OP_RETURN (0x6a) + 4-bytes - Message header (0xD1617368) + 32-bytes - h* (obtained from Simon) </pre> +[https://github.com/drivechain-project/mainchain/blob/8901d469975752d799b6a7a61d4e00a9a124028f/src/validation.cpp#L3530-L3572 Code details here]. -And both parties move, from there to (II): +If these OP_RETURN outputs are not present, then no Requests were accepted. (And, Mary would get no money from Requests.) -<pre> - Simon 13 in, Mary 40 in ; 53 in total - Simon's version [signed by Mary] - 6 ; to Simon if TimeLock=over; OR to Mary if SimonSig - 40 ; to Mary - 7 ; to Mary if critical data requirements met; OR to Simon if LongTimeLock=over - Mary's version [signed by Simon] - 40 ; to Mary if TimeLock=over; OR to Simon if MarySig - 6 ; to Simon - 7 ; to Mary if critical data requirements met; OR to Simon if LongTimeLock=over -</pre> +It is possible for Mary and Simon to be the same person.They would trust each other completely, so the BMM process would stop here. There would only be Accepts; Requests would be unnecessary. +When Simon and Mary are different people, Simon will need to use BMM Requests. -From here, if the h\* side:block in question is BMMed, they can proceed to (III): +=== BMM Request === + +Simon will use BMM Requests to buy the right to find a sidechain block, from Mary. <pre> - Simon 13 in, Mary 40 in ; 53 in total - Simon's version [signed by Mary] - 6 ; to Simon if TimeLock=over; OR to Mary if SimonSig - 47 ; to Mary - Mary's version [signed by Simon] - 47 ; to me if TimeLock=over; OR to Simon if MarySig - 6 ; to Simon +For each side:block that Simon wants to attempt, he broadcasts a txn containing the following: + 3-bytes - Message header (0x00bf00) + 32-bytes - h* (side:MerkleRoot) + 1-byte - nSidechain (sidechain ID number) + 4-bytes - prevMainHeaderBytes (the last four bytes of the previous main:block) </pre> -If Simon proceeds immediately, he removes Mary's incentive to care about blocks being built on this side:block. If Simon's side:block is orphaned, he loses his 7 BTC. Simon can either play it safe, and wait for (for example) 100 side:blocks before moving on (ie, before moving on to the third LN txn, above); or else Simon can take the risk if he feels comfortable with it. +We make use of the [https://github.com/drivechain-project/mainchain/blob/8901d469975752d799b6a7a61d4e00a9a124028f/src/primitives/transaction.h#L224-L331 extended serialization format]. (SegWit used ESF to position scriptWitness data within txns; we use it here to position the five fields above.) -If the h\* side:block is not found, then (II) and (III) are basically equivalent to each other. Simon and Mary could jointly reconstruct (I) and go back there, or they could proceed to a new version of II (with a different h\*, trying again with new side:block in the next main:block). -Now that we have described Requests, we can describe how they are accepted. +The Message header identifies this txn as a BMM transaction. h* is chosen by Simon to correspond to his side:block. nSidechain is the number assigned to the sidechain when it was created. preSideBlockRef allows Simon to build on any preexisting side:block (allowing him to bypass one or more invalid blocks, details below). prevMainHeaderBytes are the last four bytes of the previous main:block (details below). -=== BMM Accept === +This txn is invalid if it fails any of the following checks: -For each BMM Request that a main:miner "accepts", main:miners must place an OP Return output into their main:coinbase txn. (We've changed the tx-standardness policy to allow multiple OP_RETURNs.) - -The following data is required in the "accept" OP_RETURN output: - 1-byte - OP_RETURN (0x6a) - 1-byte - Push the following 36 bytes (0x24) - 4-bytes - Message header (0xD3407053) - 32-bytes - h* - ~5-bytes - BMM identifier bytes +# Each "BMM Request", must match one corresponding "BMM Accept" (previous section). +# Only one BMM Request is allowed in each main:block, per sidechain. In other words, if 700 users broadcast BMM Requests for sidechain #4, then the main:miner singles out one BMM Request to include. +# The 4-bytes of prevMainHeaderBytes must match the last four bytes of the previous main:blockheader. Thus, Simon's txns are only valid for the current block, in the block history that he knows about (and therefore, the current sidechain history that he knows about). -[https://github.com/DriveNetTESTDRIVE/DriveNet/blob/564516653c1d876429382971a011f5f6119f7eb4/src/validation.cpp#L3377-L3470 Link to code]. - -If these OP_RETURN outputs are not present, then no BMM Requests have been accepted. (And, if they are not accepted, then they cannot be included in a main:block.) +Most BMM Request txns will never make it into a block. Simon will make many BMM Requests, but only one will be accepted. Since only one BMM Request can become a bona fide transaction, Simon may feel comfortable making multiple offers all day long. This means Mary has many offers to choose from, and can choose the one which pays her the most. +This BIP allows BMM Requests to take place over Lightning. One method is [https://www.drivechain.info/media/bmm-note/bmm-lightning/ here]. (BMM Accepts cannot be over LN, since they reside in main:coinbase txns.) ==Backward compatibility== -As a soft fork, older software will continue to operate without modification. As stated above, BMM asks nodes to track a set of ordered hashes, and to allow miners to "sell" the act of finding a sidechain block. Non-upgraded nodes will notice that this activity (specifically: data in coinbases, and new txns that have OP Returns and interesting message headers) is now taking place, but they will not understand any of it. Much like P2SH or a new OP Code, these old users will not be directly affected by the fork, as they will have no expectations of receiving payments of this kind. +As a soft fork, older software will continue to operate without modification. To enforce BMM trustlessly, nodes must watch "pairs" of transactions, and subject them to extra rules. Non-upgraded nodes will notice that this activity is present in the blockchain, but they will not understand any of it. + +Much like P2SH or a new OP Code, these old users can never be directly affected by the fork, as they will have no expectations of receiving payments of this kind. (As a matter of fact, the only people receiving BTC here, all happen to be miners. So there is less reason than ever to expect compatibility problems.) -(As a matter of fact, the only people receiving money here all happen to be miners. So there is less reason than ever to expect compatibility problems.) +As with all previous soft forks, non-upgraded users are indirectly affected, in that they are no longer performing full validation. ==Deployment== @@ -196,8 +166,8 @@ This BIP will be deployed by "version bits" BIP9 with the name "blindmm" and usi <pre> // Deployment of Drivechains (BIPX, BIPY) consensus.vDeployments[Consensus::DEPLOYMENT_DRIVECHAINS].bit = 4; -consensus.vDeployments[Consensus::DEPLOYMENT_DRIVECHAINS].nStartTime = 1579072881; // January 15th, 2020. -consensus.vDeployments[Consensus::DEPLOYMENT_DRIVECHAINS].nTimeout = 1610695281; // January 15th, 2021. +consensus.vDeployments[Consensus::DEPLOYMENT_DRIVECHAINS].nStartTime = 1642276800; // January 15th, 2022. +consensus.vDeployments[Consensus::DEPLOYMENT_DRIVECHAINS].nTimeout = 1673812800; // January 15th, 2023. </pre> @@ -224,3 +194,4 @@ Thanks to everyone who contributed to the discussion, especially: ZmnSCPxj, Adam ==Copyright== This BIP is licensed under the BSD 2-clause license. + diff --git a/bip-0301/bmm-dots-examples.png b/bip-0301/bmm-dots-examples.png Binary files differdeleted file mode 100644 index 70f11f6..0000000 --- a/bip-0301/bmm-dots-examples.png +++ /dev/null diff --git a/bip-0301/m1-gui.jpg b/bip-0301/m1-gui.jpg Binary files differnew file mode 100644 index 0000000..8f3aab1 --- /dev/null +++ b/bip-0301/m1-gui.jpg diff --git a/bip-0301/sidechain-headers.png b/bip-0301/sidechain-headers.png Binary files differnew file mode 100644 index 0000000..de9697c --- /dev/null +++ b/bip-0301/sidechain-headers.png diff --git a/bip-0322.mediawiki b/bip-0322.mediawiki index 5f4704d..9b5afed 100644 --- a/bip-0322.mediawiki +++ b/bip-0322.mediawiki @@ -74,7 +74,7 @@ The <code>to_sign</code> transaction is: vout[0].nValue = 0 vout[0].scriptPubKey = OP_RETURN -A full signature consists of the base64-encoding of the <code>to_sign</code> transaction in standard network serialisation. +A full signature consists of the base64-encoding of the <code>to_sign</code> transaction in standard network serialisation once it has been signed. === Full (Proof of Funds) === @@ -120,7 +120,7 @@ Validation consists of the following steps: # Check the **upgradeable rules** ## The version of <code>to_sign</code> must be 0 or 2. ## The use of NOPs reserved for upgrades is forbidden. -## The use of segwit versions greater than 0 are forbidden. +## The use of segwit versions greater than 1 are forbidden. ## If any of the above steps failed, the validator should stop and output the ''inconclusive'' state. # Let ''T'' by the nLockTime of <code>to_sign</code> and ''S'' be the nSequence of the first input of <code>to_sign</code>. Output the state ''valid at time T and age S''. diff --git a/bip-0341.mediawiki b/bip-0341.mediawiki index 23a20a6..b88cd95 100644 --- a/bip-0341.mediawiki +++ b/bip-0341.mediawiki @@ -88,13 +88,13 @@ We first define a reusable common signature message calculation function, follow ==== Common signature message ==== -The function ''SigMsg(hash_type, ext_flag)'' computes the message being signed as a byte array. It is implicitly also a function of the spending transaction and the outputs it spends, but these are not listed to keep notation simple. +The function ''SigMsg(hash_type, ext_flag)'' computes the common portion of the message being signed as a byte array. It is implicitly also a function of the spending transaction and the outputs it spends, but these are not listed to keep notation simple. -The parameter ''hash_type'' is an 8-bit unsigned value. The <code>SIGHASH</code> encodings from the legacy script system are reused, including <code>SIGHASH_ALL</code>, <code>SIGHASH_NONE</code>, <code>SIGHASH_SINGLE</code>, and <code>SIGHASH_ANYONECANPAY</code>, plus the default ''hash_type'' value ''0x00'' which results in signing over the whole transaction just as for <code>SIGHASH_ALL</code>. The following restrictions apply, which cause validation failure if violated: +The parameter ''hash_type'' is an 8-bit unsigned value. The <code>SIGHASH</code> encodings from the legacy script system are reused, including <code>SIGHASH_ALL</code>, <code>SIGHASH_NONE</code>, <code>SIGHASH_SINGLE</code>, and <code>SIGHASH_ANYONECANPAY</code>. We define a new ''hashtype'' <code>SIGHASH_DEFAULT</code> (value ''0x00'') which results in signing over the whole transaction just as for <code>SIGHASH_ALL</code>. The following restrictions apply, which cause validation failure if violated: * Using any undefined ''hash_type'' (not ''0x00'', ''0x01'', ''0x02'', ''0x03'', ''0x81'', ''0x82'', or ''0x83''<ref>'''Why reject unknown ''hash_type'' values?''' By doing so, it is easier to reason about the worst case amount of signature hashing an implementation with adequate caching must perform.</ref>). * Using <code>SIGHASH_SINGLE</code> without a "corresponding output" (an output with the same index as the input being verified). -The parameter ''ext_flag'' is an integer in range 0-127, and is used for indicating (in the message) that extensions are added at the end of the message<ref>'''What extensions use the ''ext_flag'' mechanism?''' [[bip-0342.mediawiki|BIP342]] reuses the same common signature message algorithm, but adds BIP342-specific data at the end, which is indicated using ''ext_flag = 1''.</ref>. +The parameter ''ext_flag'' is an integer in range 0-127, and is used for indicating (in the message) that extensions are appended to the output of ''SigMsg()''<ref>'''What extensions use the ''ext_flag'' mechanism?''' [[bip-0342.mediawiki#common-signature-message-extension|BIP342]] reuses the same common signature message algorithm, but adds BIP342-specific data at the end, which is indicated using ''ext_flag = 1''.</ref>. If the parameters take acceptable values, the message is the concatenation of the following data, in order (with byte size of each item listed in parentheses). Numerical values in 2, 4, or 8-byte are encoded in little-endian. @@ -106,7 +106,7 @@ If the parameters take acceptable values, the message is the concatenation of th ** If the ''hash_type & 0x80'' does not equal <code>SIGHASH_ANYONECANPAY</code>: *** ''sha_prevouts'' (32): the SHA256 of the serialization of all input outpoints. *** ''sha_amounts'' (32): the SHA256 of the serialization of all spent output amounts. -*** ''sha_scriptpubkeys'' (32): the SHA256 of the serialization of all spent output ''scriptPubKey''s. +*** ''sha_scriptpubkeys'' (32): the SHA256 of all spent outputs' ''scriptPubKeys'', serialized as script inside <code>CTxOut</code>. *** ''sha_sequences'' (32): the SHA256 of the serialization of all input ''nSequence''. ** If ''hash_type & 3'' does not equal <code>SIGHASH_NONE</code> or <code>SIGHASH_SINGLE</code>: *** ''sha_outputs'' (32): the SHA256 of the serialization of all outputs in <code>CTxOut</code> format. @@ -167,7 +167,7 @@ Alice will not be able to notice the script path, but Mallory can unilaterally s </ref> * The remaining scripts should be organized into the leaves of a binary tree. This can be a balanced tree if each of the conditions these scripts correspond to are equally likely. If probabilities for each condition are known, consider constructing the tree as a Huffman tree. -'''Computing the output script''' Once the spending conditions are split into an internal key <code>internal_pubkey</code> and a binary tree whose leaves are (leaf_version, script) tuples, the output script can be computed using the Python3 algorithms below. These algorithms take advantage of helper functions from the [bip-0340/referency.py BIP340 reference code] for integer conversion, point multiplication, and tagged hashes. +'''Computing the output script''' Once the spending conditions are split into an internal key <code>internal_pubkey</code> and a binary tree whose leaves are (leaf_version, script) tuples, the output script can be computed using the Python3 algorithms below. These algorithms take advantage of helper functions from the [[bip-0340/reference.py|BIP340 reference code]] for integer conversion, point multiplication, and tagged hashes. First, we define <code>taproot_tweak_pubkey</code> for 32-byte [[bip-0340.mediawiki|BIP340]] public key arrays. The function returns a bit indicating the tweaked public key's Y coordinate as well as the public key byte array. @@ -175,6 +175,8 @@ The parity bit will be required for spending the output with a script path. In order to allow spending with the key path, we define <code>taproot_tweak_seckey</code> to compute the secret key for a tweaked public key. For any byte string <code>h</code> it holds that <code>taproot_tweak_pubkey(pubkey_gen(seckey), h)[1] == pubkey_gen(taproot_tweak_seckey(seckey, h))</code>. +Note that because tweaks are applied to 32-byte public keys, `taproot_tweak_seckey` may need to negate the secret key before applying the tweak. + <source lang="python"> def taproot_tweak_pubkey(pubkey, h): t = int_from_bytes(tagged_hash("TapTweak", pubkey + h)) @@ -284,7 +286,13 @@ The reason for this is to increase leaf entropy and prevent an observer from lea == Test vectors == -The test vectors used in the [https://github.com/bitcoin/bitcoin/blob/3820090bd619ac85ab35eff376c03136fe4a9f04/src/test/script_tests.cpp#L1718 Bitcoin Core unit test framework] can be found [https://github.com/bitcoin-core/qa-assets/blob/main/unit_test_data/script_assets_test.json?raw=true here]. +Test vectors for wallet operation (scriptPubKey computation, key path spending, control block construction) can be found [[bip-0341/wallet-test-vectors.json|here]]. +It consists of two sets of vectors. +* The first "scriptPubKey" tests concern computing the scriptPubKey and (mainnet) BIP350 address given an internal public key, and a script tree. The script tree is encoded as <code>null</code> to represent no scripts, a JSON object to represent a leaf node, or a 2-element array to represent an inner node. The control blocks needed for script path spending are also provided for each of the script leaves. +* The second "keyPathSpending" tests consists of a list of test cases, each of which provides an unsigned transaction and the UTXOs it spends. For each of its BIP341 inputs, the internal private key and the Merkle root it was derived from is given, as well as the expected witness to spend it. All signatures are created with an all-zero (0x0000...0000) BIP340 auxiliary randomness array. +* In all cases, hexadecimal values represent byte arrays, not numbers. In particular, that means that provided hash values have the hex digits corresponding to the first bytes first. This differs from the convention used for txids and block hashes, where the hex strings represent numbers, resulting in a reversed order. + +Validation test vectors used in the [https://github.com/bitcoin/bitcoin/blob/3820090bd619ac85ab35eff376c03136fe4a9f04/src/test/script_tests.cpp#L1718 Bitcoin Core unit test framework] can be found [https://github.com/bitcoin-core/qa-assets/blob/main/unit_test_data/script_assets_test.json?raw=true here]. == Rationale == @@ -296,7 +304,7 @@ This BIP is deployed concurrently with [[bip-0342.mediawiki|BIP342]]. For Bitcoin signet, these BIPs are always active. -For Bitcoin mainnet and testnet3, these BIPs will be deployed by "version bits" with the name "taproot" and bit 2, using [[bip-0009.mediawiki|BIP9]] modified to use a lower threshold, with an additional ''min_activation_height'' parameter and replacing the state transition logic for the DEFINED, STARTED and LOCKED_IN states as follows: +For Bitcoin mainnet and testnet3, these BIPs are deployed by "version bits" with the name "taproot" and bit 2, using [[bip-0009.mediawiki|BIP9]] modified to use a lower threshold, with an additional ''min_activation_height'' parameter and replacing the state transition logic for the DEFINED, STARTED and LOCKED_IN states as follows: case DEFINED: if (GetMedianTimePast(block.parent) >= starttime) { @@ -326,9 +334,11 @@ For Bitcoin mainnet and testnet3, these BIPs will be deployed by "version bits" } return ACTIVE; -For Bitcoin mainnet, the starttime is epoch timestamp 1619222400 (midnight 24 April 2021 UTC), timeout is epoch timestamp 1628640000 (midnight 11 August 2021 UTC), the threshold is 1815 blocks (90%) instead of 1916 blocks (95%), and the min_activation_height is block 709632 (expected approximately 12 November 2021). +For Bitcoin mainnet, the starttime is epoch timestamp 1619222400 (midnight 24 April 2021 UTC), timeout is epoch timestamp 1628640000 (midnight 11 August 2021 UTC), the threshold is 1815 blocks (90%) instead of 1916 blocks (95%), and the min_activation_height is block 709632. +The deployment did activate at height 709632 on Bitcoin mainnet. For Bitcoin testnet3, the starttime is epoch timestamp 1619222400 (midnight 24 April 2021 UTC), timeout is epoch timestamp 1628640000 (midnight 11 August 2021 UTC), the threshold is 1512 blocks (75%), and the min_activation_height is block 0. +The deployment did activate at height 2011968 on Bitcoin testnet3. == Backwards compatibility == As a soft fork, older software will continue to operate without modification. diff --git a/bip-0341/wallet-test-vectors.json b/bip-0341/wallet-test-vectors.json new file mode 100644 index 0000000..11261b0 --- /dev/null +++ b/bip-0341/wallet-test-vectors.json @@ -0,0 +1,452 @@ +{ + "version": 1, + "scriptPubKey": [ + { + "given": { + "internalPubkey": "d6889cb081036e0faefa3a35157ad71086b123b2b144b649798b494c300a961d", + "scriptTree": null + }, + "intermediary": { + "merkleRoot": null, + "tweak": "b86e7be8f39bab32a6f2c0443abbc210f0edac0e2c53d501b36b64437d9c6c70", + "tweakedPubkey": "53a1f6e454df1aa2776a2814a721372d6258050de330b3c6d10ee8f4e0dda343" + }, + "expected": { + "scriptPubKey": "512053a1f6e454df1aa2776a2814a721372d6258050de330b3c6d10ee8f4e0dda343", + "bip350Address": "bc1p2wsldez5mud2yam29q22wgfh9439spgduvct83k3pm50fcxa5dps59h4z5" + } + }, + { + "given": { + "internalPubkey": "187791b6f712a8ea41c8ecdd0ee77fab3e85263b37e1ec18a3651926b3a6cf27", + "scriptTree": { + "id": 0, + "script": "20d85a959b0290bf19bb89ed43c916be835475d013da4b362117393e25a48229b8ac", + "leafVersion": 192 + } + }, + "intermediary": { + "leafHashes": [ + "5b75adecf53548f3ec6ad7d78383bf84cc57b55a3127c72b9a2481752dd88b21" + ], + "merkleRoot": "5b75adecf53548f3ec6ad7d78383bf84cc57b55a3127c72b9a2481752dd88b21", + "tweak": "cbd8679ba636c1110ea247542cfbd964131a6be84f873f7f3b62a777528ed001", + "tweakedPubkey": "147c9c57132f6e7ecddba9800bb0c4449251c92a1e60371ee77557b6620f3ea3" + }, + "expected": { + "scriptPubKey": "5120147c9c57132f6e7ecddba9800bb0c4449251c92a1e60371ee77557b6620f3ea3", + "bip350Address": "bc1pz37fc4cn9ah8anwm4xqqhvxygjf9rjf2resrw8h8w4tmvcs0863sa2e586", + "scriptPathControlBlocks": [ + "c1187791b6f712a8ea41c8ecdd0ee77fab3e85263b37e1ec18a3651926b3a6cf27" + ] + } + }, + { + "given": { + "internalPubkey": "93478e9488f956df2396be2ce6c5cced75f900dfa18e7dabd2428aae78451820", + "scriptTree": { + "id": 0, + "script": "20b617298552a72ade070667e86ca63b8f5789a9fe8731ef91202a91c9f3459007ac", + "leafVersion": 192 + } + }, + "intermediary": { + "leafHashes": [ + "c525714a7f49c28aedbbba78c005931a81c234b2f6c99a73e4d06082adc8bf2b" + ], + "merkleRoot": "c525714a7f49c28aedbbba78c005931a81c234b2f6c99a73e4d06082adc8bf2b", + "tweak": "6af9e28dbf9d6aaf027696e2598a5b3d056f5fd2355a7fd5a37a0e5008132d30", + "tweakedPubkey": "e4d810fd50586274face62b8a807eb9719cef49c04177cc6b76a9a4251d5450e" + }, + "expected": { + "scriptPubKey": "5120e4d810fd50586274face62b8a807eb9719cef49c04177cc6b76a9a4251d5450e", + "bip350Address": "bc1punvppl2stp38f7kwv2u2spltjuvuaayuqsthe34hd2dyy5w4g58qqfuag5", + "scriptPathControlBlocks": [ + "c093478e9488f956df2396be2ce6c5cced75f900dfa18e7dabd2428aae78451820" + ] + } + }, + { + "given": { + "internalPubkey": "ee4fe085983462a184015d1f782d6a5f8b9c2b60130aff050ce221ecf3786592", + "scriptTree": [ + { + "id": 0, + "script": "20387671353e273264c495656e27e39ba899ea8fee3bb69fb2a680e22093447d48ac", + "leafVersion": 192 + }, + { + "id": 1, + "script": "06424950333431", + "leafVersion": 250 + } + ] + }, + "intermediary": { + "leafHashes": [ + "8ad69ec7cf41c2a4001fd1f738bf1e505ce2277acdcaa63fe4765192497f47a7", + "f224a923cd0021ab202ab139cc56802ddb92dcfc172b9212261a539df79a112a" + ], + "merkleRoot": "6c2dc106ab816b73f9d07e3cd1ef2c8c1256f519748e0813e4edd2405d277bef", + "tweak": "9e0517edc8259bb3359255400b23ca9507f2a91cd1e4250ba068b4eafceba4a9", + "tweakedPubkey": "712447206d7a5238acc7ff53fbe94a3b64539ad291c7cdbc490b7577e4b17df5" + }, + "expected": { + "scriptPubKey": "5120712447206d7a5238acc7ff53fbe94a3b64539ad291c7cdbc490b7577e4b17df5", + "bip350Address": "bc1pwyjywgrd0ffr3tx8laflh6228dj98xkjj8rum0zfpd6h0e930h6saqxrrm", + "scriptPathControlBlocks": [ + "c0ee4fe085983462a184015d1f782d6a5f8b9c2b60130aff050ce221ecf3786592f224a923cd0021ab202ab139cc56802ddb92dcfc172b9212261a539df79a112a", + "faee4fe085983462a184015d1f782d6a5f8b9c2b60130aff050ce221ecf37865928ad69ec7cf41c2a4001fd1f738bf1e505ce2277acdcaa63fe4765192497f47a7" + ] + } + }, + { + "given": { + "internalPubkey": "f9f400803e683727b14f463836e1e78e1c64417638aa066919291a225f0e8dd8", + "scriptTree": [ + { + "id": 0, + "script": "2044b178d64c32c4a05cc4f4d1407268f764c940d20ce97abfd44db5c3592b72fdac", + "leafVersion": 192 + }, + { + "id": 1, + "script": "07546170726f6f74", + "leafVersion": 192 + } + ] + }, + "intermediary": { + "leafHashes": [ + "64512fecdb5afa04f98839b50e6f0cb7b1e539bf6f205f67934083cdcc3c8d89", + "2cb2b90daa543b544161530c925f285b06196940d6085ca9474d41dc3822c5cb" + ], + "merkleRoot": "ab179431c28d3b68fb798957faf5497d69c883c6fb1e1cd9f81483d87bac90cc", + "tweak": "639f0281b7ac49e742cd25b7f188657626da1ad169209078e2761cefd91fd65e", + "tweakedPubkey": "77e30a5522dd9f894c3f8b8bd4c4b2cf82ca7da8a3ea6a239655c39c050ab220" + }, + "expected": { + "scriptPubKey": "512077e30a5522dd9f894c3f8b8bd4c4b2cf82ca7da8a3ea6a239655c39c050ab220", + "bip350Address": "bc1pwl3s54fzmk0cjnpl3w9af39je7pv5ldg504x5guk2hpecpg2kgsqaqstjq", + "scriptPathControlBlocks": [ + "c1f9f400803e683727b14f463836e1e78e1c64417638aa066919291a225f0e8dd82cb2b90daa543b544161530c925f285b06196940d6085ca9474d41dc3822c5cb", + "c1f9f400803e683727b14f463836e1e78e1c64417638aa066919291a225f0e8dd864512fecdb5afa04f98839b50e6f0cb7b1e539bf6f205f67934083cdcc3c8d89" + ] + } + }, + { + "given": { + "internalPubkey": "e0dfe2300b0dd746a3f8674dfd4525623639042569d829c7f0eed9602d263e6f", + "scriptTree": [ + { + "id": 0, + "script": "2072ea6adcf1d371dea8fba1035a09f3d24ed5a059799bae114084130ee5898e69ac", + "leafVersion": 192 + }, + [ + { + "id": 1, + "script": "202352d137f2f3ab38d1eaa976758873377fa5ebb817372c71e2c542313d4abda8ac", + "leafVersion": 192 + }, + { + "id": 2, + "script": "207337c0dd4253cb86f2c43a2351aadd82cccb12a172cd120452b9bb8324f2186aac", + "leafVersion": 192 + } + ] + ] + }, + "intermediary": { + "leafHashes": [ + "2645a02e0aac1fe69d69755733a9b7621b694bb5b5cde2bbfc94066ed62b9817", + "ba982a91d4fc552163cb1c0da03676102d5b7a014304c01f0c77b2b8e888de1c", + "9e31407bffa15fefbf5090b149d53959ecdf3f62b1246780238c24501d5ceaf6" + ], + "merkleRoot": "ccbd66c6f7e8fdab47b3a486f59d28262be857f30d4773f2d5ea47f7761ce0e2", + "tweak": "b57bfa183d28eeb6ad688ddaabb265b4a41fbf68e5fed2c72c74de70d5a786f4", + "tweakedPubkey": "91b64d5324723a985170e4dc5a0f84c041804f2cd12660fa5dec09fc21783605" + }, + "expected": { + "scriptPubKey": "512091b64d5324723a985170e4dc5a0f84c041804f2cd12660fa5dec09fc21783605", + "bip350Address": "bc1pjxmy65eywgafs5tsunw95ruycpqcqnev6ynxp7jaasylcgtcxczs6n332e", + "scriptPathControlBlocks": [ + "c0e0dfe2300b0dd746a3f8674dfd4525623639042569d829c7f0eed9602d263e6fffe578e9ea769027e4f5a3de40732f75a88a6353a09d767ddeb66accef85e553", + "c0e0dfe2300b0dd746a3f8674dfd4525623639042569d829c7f0eed9602d263e6f9e31407bffa15fefbf5090b149d53959ecdf3f62b1246780238c24501d5ceaf62645a02e0aac1fe69d69755733a9b7621b694bb5b5cde2bbfc94066ed62b9817", + "c0e0dfe2300b0dd746a3f8674dfd4525623639042569d829c7f0eed9602d263e6fba982a91d4fc552163cb1c0da03676102d5b7a014304c01f0c77b2b8e888de1c2645a02e0aac1fe69d69755733a9b7621b694bb5b5cde2bbfc94066ed62b9817" + ] + } + }, + { + "given": { + "internalPubkey": "55adf4e8967fbd2e29f20ac896e60c3b0f1d5b0efa9d34941b5958c7b0a0312d", + "scriptTree": [ + { + "id": 0, + "script": "2071981521ad9fc9036687364118fb6ccd2035b96a423c59c5430e98310a11abe2ac", + "leafVersion": 192 + }, + [ + { + "id": 1, + "script": "20d5094d2dbe9b76e2c245a2b89b6006888952e2faa6a149ae318d69e520617748ac", + "leafVersion": 192 + }, + { + "id": 2, + "script": "20c440b462ad48c7a77f94cd4532d8f2119dcebbd7c9764557e62726419b08ad4cac", + "leafVersion": 192 + } + ] + ] + }, + "intermediary": { + "leafHashes": [ + "f154e8e8e17c31d3462d7132589ed29353c6fafdb884c5a6e04ea938834f0d9d", + "737ed1fe30bc42b8022d717b44f0d93516617af64a64753b7a06bf16b26cd711", + "d7485025fceb78b9ed667db36ed8b8dc7b1f0b307ac167fa516fe4352b9f4ef7" + ], + "merkleRoot": "2f6b2c5397b6d68ca18e09a3f05161668ffe93a988582d55c6f07bd5b3329def", + "tweak": "6579138e7976dc13b6a92f7bfd5a2fc7684f5ea42419d43368301470f3b74ed9", + "tweakedPubkey": "75169f4001aa68f15bbed28b218df1d0a62cbbcf1188c6665110c293c907b831" + }, + "expected": { + "scriptPubKey": "512075169f4001aa68f15bbed28b218df1d0a62cbbcf1188c6665110c293c907b831", + "bip350Address": "bc1pw5tf7sqp4f50zka7629jrr036znzew70zxyvvej3zrpf8jg8hqcssyuewe", + "scriptPathControlBlocks": [ + "c155adf4e8967fbd2e29f20ac896e60c3b0f1d5b0efa9d34941b5958c7b0a0312d3cd369a528b326bc9d2133cbd2ac21451acb31681a410434672c8e34fe757e91", + "c155adf4e8967fbd2e29f20ac896e60c3b0f1d5b0efa9d34941b5958c7b0a0312dd7485025fceb78b9ed667db36ed8b8dc7b1f0b307ac167fa516fe4352b9f4ef7f154e8e8e17c31d3462d7132589ed29353c6fafdb884c5a6e04ea938834f0d9d", + "c155adf4e8967fbd2e29f20ac896e60c3b0f1d5b0efa9d34941b5958c7b0a0312d737ed1fe30bc42b8022d717b44f0d93516617af64a64753b7a06bf16b26cd711f154e8e8e17c31d3462d7132589ed29353c6fafdb884c5a6e04ea938834f0d9d" + ] + } + } + ], + "keyPathSpending": [ + { + "given": { + "rawUnsignedTx": "02000000097de20cbff686da83a54981d2b9bab3586f4ca7e48f57f5b55963115f3b334e9c010000000000000000d7b7cab57b1393ace2d064f4d4a2cb8af6def61273e127517d44759b6dafdd990000000000fffffffff8e1f583384333689228c5d28eac13366be082dc57441760d957275419a418420000000000fffffffff0689180aa63b30cb162a73c6d2a38b7eeda2a83ece74310fda0843ad604853b0100000000feffffffaa5202bdf6d8ccd2ee0f0202afbbb7461d9264a25e5bfd3c5a52ee1239e0ba6c0000000000feffffff956149bdc66faa968eb2be2d2faa29718acbfe3941215893a2a3446d32acd050000000000000000000e664b9773b88c09c32cb70a2a3e4da0ced63b7ba3b22f848531bbb1d5d5f4c94010000000000000000e9aa6b8e6c9de67619e6a3924ae25696bb7b694bb677a632a74ef7eadfd4eabf0000000000ffffffffa778eb6a263dc090464cd125c466b5a99667720b1c110468831d058aa1b82af10100000000ffffffff0200ca9a3b000000001976a91406afd46bcdfd22ef94ac122aa11f241244a37ecc88ac807840cb0000000020ac9a87f5594be208f8532db38cff670c450ed2fea8fcdefcc9a663f78bab962b0065cd1d", + "utxosSpent": [ + { + "scriptPubKey": "512053a1f6e454df1aa2776a2814a721372d6258050de330b3c6d10ee8f4e0dda343", + "amountSats": 420000000 + }, + { + "scriptPubKey": "5120147c9c57132f6e7ecddba9800bb0c4449251c92a1e60371ee77557b6620f3ea3", + "amountSats": 462000000 + }, + { + "scriptPubKey": "76a914751e76e8199196d454941c45d1b3a323f1433bd688ac", + "amountSats": 294000000 + }, + { + "scriptPubKey": "5120e4d810fd50586274face62b8a807eb9719cef49c04177cc6b76a9a4251d5450e", + "amountSats": 504000000 + }, + { + "scriptPubKey": "512091b64d5324723a985170e4dc5a0f84c041804f2cd12660fa5dec09fc21783605", + "amountSats": 630000000 + }, + { + "scriptPubKey": "00147dd65592d0ab2fe0d0257d571abf032cd9db93dc", + "amountSats": 378000000 + }, + { + "scriptPubKey": "512075169f4001aa68f15bbed28b218df1d0a62cbbcf1188c6665110c293c907b831", + "amountSats": 672000000 + }, + { + "scriptPubKey": "5120712447206d7a5238acc7ff53fbe94a3b64539ad291c7cdbc490b7577e4b17df5", + "amountSats": 546000000 + }, + { + "scriptPubKey": "512077e30a5522dd9f894c3f8b8bd4c4b2cf82ca7da8a3ea6a239655c39c050ab220", + "amountSats": 588000000 + } + ] + }, + "intermediary": { + "hashAmounts": "58a6964a4f5f8f0b642ded0a8a553be7622a719da71d1f5befcefcdee8e0fde6", + "hashOutputs": "a2e6dab7c1f0dcd297c8d61647fd17d821541ea69c3cc37dcbad7f90d4eb4bc5", + "hashPrevouts": "e3b33bb4ef3a52ad1fffb555c0d82828eb22737036eaeb02a235d82b909c4c3f", + "hashScriptPubkeys": "23ad0f61ad2bca5ba6a7693f50fce988e17c3780bf2b1e720cfbb38fbdd52e21", + "hashSequences": "18959c7221ab5ce9e26c3cd67b22c24f8baa54bac281d8e6b05e400e6c3a957e" + }, + "inputSpending": [ + { + "given": { + "txinIndex": 0, + "internalPrivkey": "6b973d88838f27366ed61c9ad6367663045cb456e28335c109e30717ae0c6baa", + "merkleRoot": null, + "hashType": 3 + }, + "intermediary": { + "internalPubkey": "d6889cb081036e0faefa3a35157ad71086b123b2b144b649798b494c300a961d", + "tweak": "b86e7be8f39bab32a6f2c0443abbc210f0edac0e2c53d501b36b64437d9c6c70", + "tweakedPrivkey": "2405b971772ad26915c8dcdf10f238753a9b837e5f8e6a86fd7c0cce5b7296d9", + "sigMsg": "0003020000000065cd1de3b33bb4ef3a52ad1fffb555c0d82828eb22737036eaeb02a235d82b909c4c3f58a6964a4f5f8f0b642ded0a8a553be7622a719da71d1f5befcefcdee8e0fde623ad0f61ad2bca5ba6a7693f50fce988e17c3780bf2b1e720cfbb38fbdd52e2118959c7221ab5ce9e26c3cd67b22c24f8baa54bac281d8e6b05e400e6c3a957e0000000000d0418f0e9a36245b9a50ec87f8bf5be5bcae434337b87139c3a5b1f56e33cba0", + "precomputedUsed": [ + "hashAmounts", + "hashPrevouts", + "hashScriptPubkeys", + "hashSequences" + ], + "sigHash": "2514a6272f85cfa0f45eb907fcb0d121b808ed37c6ea160a5a9046ed5526d555" + }, + "expected": { + "witness": [ + "ed7c1647cb97379e76892be0cacff57ec4a7102aa24296ca39af7541246d8ff14d38958d4cc1e2e478e4d4a764bbfd835b16d4e314b72937b29833060b87276c03" + ] + } + }, + { + "given": { + "txinIndex": 1, + "internalPrivkey": "1e4da49f6aaf4e5cd175fe08a32bb5cb4863d963921255f33d3bc31e1343907f", + "merkleRoot": "5b75adecf53548f3ec6ad7d78383bf84cc57b55a3127c72b9a2481752dd88b21", + "hashType": 131 + }, + "intermediary": { + "internalPubkey": "187791b6f712a8ea41c8ecdd0ee77fab3e85263b37e1ec18a3651926b3a6cf27", + "tweak": "cbd8679ba636c1110ea247542cfbd964131a6be84f873f7f3b62a777528ed001", + "tweakedPrivkey": "ea260c3b10e60f6de018455cd0278f2f5b7e454be1999572789e6a9565d26080", + "sigMsg": "0083020000000065cd1d00d7b7cab57b1393ace2d064f4d4a2cb8af6def61273e127517d44759b6dafdd9900000000808f891b00000000225120147c9c57132f6e7ecddba9800bb0c4449251c92a1e60371ee77557b6620f3ea3ffffffffffcef8fb4ca7efc5433f591ecfc57391811ce1e186a3793024def5c884cba51d", + "precomputedUsed": [], + "sigHash": "325a644af47e8a5a2591cda0ab0723978537318f10e6a63d4eed783b96a71a4d" + }, + "expected": { + "witness": [ + "052aedffc554b41f52b521071793a6b88d6dbca9dba94cf34c83696de0c1ec35ca9c5ed4ab28059bd606a4f3a657eec0bb96661d42921b5f50a95ad33675b54f83" + ] + } + }, + { + "given": { + "txinIndex": 3, + "internalPrivkey": "d3c7af07da2d54f7a7735d3d0fc4f0a73164db638b2f2f7c43f711f6d4aa7e64", + "merkleRoot": "c525714a7f49c28aedbbba78c005931a81c234b2f6c99a73e4d06082adc8bf2b", + "hashType": 1 + }, + "intermediary": { + "internalPubkey": "93478e9488f956df2396be2ce6c5cced75f900dfa18e7dabd2428aae78451820", + "tweak": "6af9e28dbf9d6aaf027696e2598a5b3d056f5fd2355a7fd5a37a0e5008132d30", + "tweakedPrivkey": "97323385e57015b75b0339a549c56a948eb961555973f0951f555ae6039ef00d", + "sigMsg": "0001020000000065cd1de3b33bb4ef3a52ad1fffb555c0d82828eb22737036eaeb02a235d82b909c4c3f58a6964a4f5f8f0b642ded0a8a553be7622a719da71d1f5befcefcdee8e0fde623ad0f61ad2bca5ba6a7693f50fce988e17c3780bf2b1e720cfbb38fbdd52e2118959c7221ab5ce9e26c3cd67b22c24f8baa54bac281d8e6b05e400e6c3a957ea2e6dab7c1f0dcd297c8d61647fd17d821541ea69c3cc37dcbad7f90d4eb4bc50003000000", + "precomputedUsed": [ + "hashAmounts", + "hashOutputs", + "hashPrevouts", + "hashScriptPubkeys", + "hashSequences" + ], + "sigHash": "bf013ea93474aa67815b1b6cc441d23b64fa310911d991e713cd34c7f5d46669" + }, + "expected": { + "witness": [ + "ff45f742a876139946a149ab4d9185574b98dc919d2eb6754f8abaa59d18b025637a3aa043b91817739554f4ed2026cf8022dbd83e351ce1fabc272841d2510a01" + ] + } + }, + { + "given": { + "txinIndex": 4, + "internalPrivkey": "f36bb07a11e469ce941d16b63b11b9b9120a84d9d87cff2c84a8d4affb438f4e", + "merkleRoot": "ccbd66c6f7e8fdab47b3a486f59d28262be857f30d4773f2d5ea47f7761ce0e2", + "hashType": 0 + }, + "intermediary": { + "internalPubkey": "e0dfe2300b0dd746a3f8674dfd4525623639042569d829c7f0eed9602d263e6f", + "tweak": "b57bfa183d28eeb6ad688ddaabb265b4a41fbf68e5fed2c72c74de70d5a786f4", + "tweakedPrivkey": "a8e7aa924f0d58854185a490e6c41f6efb7b675c0f3331b7f14b549400b4d501", + "sigMsg": "0000020000000065cd1de3b33bb4ef3a52ad1fffb555c0d82828eb22737036eaeb02a235d82b909c4c3f58a6964a4f5f8f0b642ded0a8a553be7622a719da71d1f5befcefcdee8e0fde623ad0f61ad2bca5ba6a7693f50fce988e17c3780bf2b1e720cfbb38fbdd52e2118959c7221ab5ce9e26c3cd67b22c24f8baa54bac281d8e6b05e400e6c3a957ea2e6dab7c1f0dcd297c8d61647fd17d821541ea69c3cc37dcbad7f90d4eb4bc50004000000", + "precomputedUsed": [ + "hashAmounts", + "hashOutputs", + "hashPrevouts", + "hashScriptPubkeys", + "hashSequences" + ], + "sigHash": "4f900a0bae3f1446fd48490c2958b5a023228f01661cda3496a11da502a7f7ef" + }, + "expected": { + "witness": [ + "b4010dd48a617db09926f729e79c33ae0b4e94b79f04a1ae93ede6315eb3669de185a17d2b0ac9ee09fd4c64b678a0b61a0a86fa888a273c8511be83bfd6810f" + ] + } + }, + { + "given": { + "txinIndex": 6, + "internalPrivkey": "415cfe9c15d9cea27d8104d5517c06e9de48e2f986b695e4f5ffebf230e725d8", + "merkleRoot": "2f6b2c5397b6d68ca18e09a3f05161668ffe93a988582d55c6f07bd5b3329def", + "hashType": 2 + }, + "intermediary": { + "internalPubkey": "55adf4e8967fbd2e29f20ac896e60c3b0f1d5b0efa9d34941b5958c7b0a0312d", + "tweak": "6579138e7976dc13b6a92f7bfd5a2fc7684f5ea42419d43368301470f3b74ed9", + "tweakedPrivkey": "241c14f2639d0d7139282aa6abde28dd8a067baa9d633e4e7230287ec2d02901", + "sigMsg": "0002020000000065cd1de3b33bb4ef3a52ad1fffb555c0d82828eb22737036eaeb02a235d82b909c4c3f58a6964a4f5f8f0b642ded0a8a553be7622a719da71d1f5befcefcdee8e0fde623ad0f61ad2bca5ba6a7693f50fce988e17c3780bf2b1e720cfbb38fbdd52e2118959c7221ab5ce9e26c3cd67b22c24f8baa54bac281d8e6b05e400e6c3a957e0006000000", + "precomputedUsed": [ + "hashAmounts", + "hashPrevouts", + "hashScriptPubkeys", + "hashSequences" + ], + "sigHash": "15f25c298eb5cdc7eb1d638dd2d45c97c4c59dcaec6679cfc16ad84f30876b85" + }, + "expected": { + "witness": [ + "a3785919a2ce3c4ce26f298c3d51619bc474ae24014bcdd31328cd8cfbab2eff3395fa0a16fe5f486d12f22a9cedded5ae74feb4bbe5351346508c5405bcfee002" + ] + } + }, + { + "given": { + "txinIndex": 7, + "internalPrivkey": "c7b0e81f0a9a0b0499e112279d718cca98e79a12e2f137c72ae5b213aad0d103", + "merkleRoot": "6c2dc106ab816b73f9d07e3cd1ef2c8c1256f519748e0813e4edd2405d277bef", + "hashType": 130 + }, + "intermediary": { + "internalPubkey": "ee4fe085983462a184015d1f782d6a5f8b9c2b60130aff050ce221ecf3786592", + "tweak": "9e0517edc8259bb3359255400b23ca9507f2a91cd1e4250ba068b4eafceba4a9", + "tweakedPrivkey": "65b6000cd2bfa6b7cf736767a8955760e62b6649058cbc970b7c0871d786346b", + "sigMsg": "0082020000000065cd1d00e9aa6b8e6c9de67619e6a3924ae25696bb7b694bb677a632a74ef7eadfd4eabf00000000804c8b2000000000225120712447206d7a5238acc7ff53fbe94a3b64539ad291c7cdbc490b7577e4b17df5ffffffff", + "precomputedUsed": [], + "sigHash": "cd292de50313804dabe4685e83f923d2969577191a3e1d2882220dca88cbeb10" + }, + "expected": { + "witness": [ + "ea0c6ba90763c2d3a296ad82ba45881abb4f426b3f87af162dd24d5109edc1cdd11915095ba47c3a9963dc1e6c432939872bc49212fe34c632cd3ab9fed429c482" + ] + } + }, + { + "given": { + "txinIndex": 8, + "internalPrivkey": "77863416be0d0665e517e1c375fd6f75839544eca553675ef7fdf4949518ebaa", + "merkleRoot": "ab179431c28d3b68fb798957faf5497d69c883c6fb1e1cd9f81483d87bac90cc", + "hashType": 129 + }, + "intermediary": { + "internalPubkey": "f9f400803e683727b14f463836e1e78e1c64417638aa066919291a225f0e8dd8", + "tweak": "639f0281b7ac49e742cd25b7f188657626da1ad169209078e2761cefd91fd65e", + "tweakedPrivkey": "ec18ce6af99f43815db543f47b8af5ff5df3b2cb7315c955aa4a86e8143d2bf5", + "sigMsg": "0081020000000065cd1da2e6dab7c1f0dcd297c8d61647fd17d821541ea69c3cc37dcbad7f90d4eb4bc500a778eb6a263dc090464cd125c466b5a99667720b1c110468831d058aa1b82af101000000002b0c230000000022512077e30a5522dd9f894c3f8b8bd4c4b2cf82ca7da8a3ea6a239655c39c050ab220ffffffff", + "precomputedUsed": [ + "hashOutputs" + ], + "sigHash": "cccb739eca6c13a8a89e6e5cd317ffe55669bbda23f2fd37b0f18755e008edd2" + }, + "expected": { + "witness": [ + "bbc9584a11074e83bc8c6759ec55401f0ae7b03ef290c3139814f545b58a9f8127258000874f44bc46db7646322107d4d86aec8e73b8719a61fff761d75b5dd981" + ] + } + } + ], + "auxiliary": { + "fullySignedTx": "020000000001097de20cbff686da83a54981d2b9bab3586f4ca7e48f57f5b55963115f3b334e9c010000000000000000d7b7cab57b1393ace2d064f4d4a2cb8af6def61273e127517d44759b6dafdd990000000000fffffffff8e1f583384333689228c5d28eac13366be082dc57441760d957275419a41842000000006b4830450221008f3b8f8f0537c420654d2283673a761b7ee2ea3c130753103e08ce79201cf32a022079e7ab904a1980ef1c5890b648c8783f4d10103dd62f740d13daa79e298d50c201210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798fffffffff0689180aa63b30cb162a73c6d2a38b7eeda2a83ece74310fda0843ad604853b0100000000feffffffaa5202bdf6d8ccd2ee0f0202afbbb7461d9264a25e5bfd3c5a52ee1239e0ba6c0000000000feffffff956149bdc66faa968eb2be2d2faa29718acbfe3941215893a2a3446d32acd050000000000000000000e664b9773b88c09c32cb70a2a3e4da0ced63b7ba3b22f848531bbb1d5d5f4c94010000000000000000e9aa6b8e6c9de67619e6a3924ae25696bb7b694bb677a632a74ef7eadfd4eabf0000000000ffffffffa778eb6a263dc090464cd125c466b5a99667720b1c110468831d058aa1b82af10100000000ffffffff0200ca9a3b000000001976a91406afd46bcdfd22ef94ac122aa11f241244a37ecc88ac807840cb0000000020ac9a87f5594be208f8532db38cff670c450ed2fea8fcdefcc9a663f78bab962b0141ed7c1647cb97379e76892be0cacff57ec4a7102aa24296ca39af7541246d8ff14d38958d4cc1e2e478e4d4a764bbfd835b16d4e314b72937b29833060b87276c030141052aedffc554b41f52b521071793a6b88d6dbca9dba94cf34c83696de0c1ec35ca9c5ed4ab28059bd606a4f3a657eec0bb96661d42921b5f50a95ad33675b54f83000141ff45f742a876139946a149ab4d9185574b98dc919d2eb6754f8abaa59d18b025637a3aa043b91817739554f4ed2026cf8022dbd83e351ce1fabc272841d2510a010140b4010dd48a617db09926f729e79c33ae0b4e94b79f04a1ae93ede6315eb3669de185a17d2b0ac9ee09fd4c64b678a0b61a0a86fa888a273c8511be83bfd6810f0247304402202b795e4de72646d76eab3f0ab27dfa30b810e856ff3a46c9a702df53bb0d8cc302203ccc4d822edab5f35caddb10af1be93583526ccfbade4b4ead350781e2f8adcd012102f9308a019258c31049344f85f89d5229b531c845836f99b08601f113bce036f90141a3785919a2ce3c4ce26f298c3d51619bc474ae24014bcdd31328cd8cfbab2eff3395fa0a16fe5f486d12f22a9cedded5ae74feb4bbe5351346508c5405bcfee0020141ea0c6ba90763c2d3a296ad82ba45881abb4f426b3f87af162dd24d5109edc1cdd11915095ba47c3a9963dc1e6c432939872bc49212fe34c632cd3ab9fed429c4820141bbc9584a11074e83bc8c6759ec55401f0ae7b03ef290c3139814f545b58a9f8127258000874f44bc46db7646322107d4d86aec8e73b8719a61fff761d75b5dd9810065cd1d" + } + } + ] +} diff --git a/bip-0342.mediawiki b/bip-0342.mediawiki index 87e07ae..bbefcaa 100644 --- a/bip-0342.mediawiki +++ b/bip-0342.mediawiki @@ -104,13 +104,17 @@ The following rules apply to <code>OP_CHECKSIG</code>, <code>OP_CHECKSIGVERIFY</ *** For <code>OP_CHECKSIG</code>, a 1-byte value <code>0x01</code> is pushed onto the stack. *** For <code>OP_CHECKSIGADD</code>, a <code>CScriptNum</code> with value of <code>n + 1</code> is pushed onto the stack. +===Common Signature Message Extension=== + +We define the tapscript message extension ''ext'' to [[bip-0341.mediawiki#common-signature-message|BIP341 Common Signature Message]], indicated by ''ext_flag = 1'': +* ''tapleaf_hash'' (32): the tapleaf hash as defined in [[bip-0341.mediawiki#design|BIP341]] +* ''key_version'' (1): a constant value ''0x00'' representing the current version of public keys in the tapscript signature opcode execution. +* ''codesep_pos'' (4): the opcode position of the last executed <code>OP_CODESEPARATOR</code> before the currently executed signature opcode, with the value in little endian (or ''0xffffffff'' if none executed). The first opcode in a script has a position of 0. A multi-byte push opcode is counted as one opcode, regardless of the size of data being pushed. Opcodes in parsed but unexecuted branches count towards this value as well. + ===Signature validation=== To validate a signature ''sig'' with public key ''p'': -* Compute the tapscript message extension ''ext'', consisting of the concatenation of: -** ''tapleaf_hash'' (32): the tapleaf hash as defined in [[bip-0341.mediawiki#design|BIP341]] -** ''key_version'' (1): a constant value ''0x00'' representing the current version of public keys in the tapscript signature opcode execution. -** ''codesep_pos'' (4): the opcode position of the last executed <code>OP_CODESEPARATOR</code> before the currently executed signature opcode, with the value in little endian (or ''0xffffffff'' if none executed). The first opcode in a script has a position of 0. A multi-byte push opcode is counted as one opcode, regardless of the size of data being pushed. Opcodes in parsed but unexecuted branches count towards this value as well. +* Compute the tapscript message extension ''ext'' described above. * If the ''sig'' is 64 bytes long, return ''Verify(p, hash<sub>TapSighash</sub>(0x00 || SigMsg(0x00, 1) || ext), sig)'', where ''Verify'' is defined in [[bip-0340.mediawiki#design|BIP340]]. * If the ''sig'' is 65 bytes long, return ''sig[64] ≠ 0x00 and Verify(p, hash<sub>TapSighash</sub>(0x00 || SigMsg(sig[64], 1) || ext), sig[0:64])''. * Otherwise, fail. diff --git a/bip-0371.mediawiki b/bip-0371.mediawiki index a061962..189c36f 100644 --- a/bip-0371.mediawiki +++ b/bip-0371.mediawiki @@ -172,15 +172,15 @@ The following are invalid PSBTs: ** Base64 String: <pre>cHNidP8BAHECAAAAASd0Srq/MCf+DWzyOpbu4u+xiO9SMBlUWFiD5ptmJLJCAAAAAAD/////Anh8AQAAAAAAFgAUg6fjS9mf8DpJYu+KGhAbspVGHs5gawQqAQAAABYAFHrDad8bIOAz1hFmI5V7CsSfPFLoAAAAAAABASsA8gUqAQAAACJRIFosLPW1LPMfg60ujaY/8DGD7Nj2CcdRCuikjgORCgdXARchAv40kGTJjW4qhT+jybEr2LMEoZwZXGDvp+4jkwRtP6IyAAAA</pre> * Case: PSBT With <tt>PSBT_KEY_PATH_SIG</tt> signature that is too short -** Bytes in Hex: <pre><70736274ff010071020000000127744ababf3027fe0d6cf23a96eee2efb188ef52301954585883e69b6624b2420000000000ffffffff02787c01000000000016001483a7e34bd99ff03a4962ef8a1a101bb295461ece606b042a010000001600147ac369df1b20e033d6116623957b0ac49f3c52e8000000000001012b00f2052a010000002251205a2c2cf5b52cf31f83ad2e8da63ff03183ecd8f609c7510ae8a48e03910a075701133f173bb3d36c074afb716fec6307a069a2e450b995f3c82785945ab8df0e24260dcd703b0cbf34de399184a9481ac2b3586db6601f026a77f7e4938481bc3475000000/pre> -** Base64 String: <pre>cHNidP8BAHECAAAAASd0Srq/MCf+DWzyOpbu4u+xiO9SMBlUWFiD5ptmJLJCAAAAAAD/////Anh8AQAAAAAAFgAUg6fjS9mf8DpJYu+KGhAbspVGHs5gawQqAQAAABYAFHrDad8bIOAz1hFmI5V7CsSfPFLoAAAAAAABASsA8gUqAQAAACJRIFosLPW1LPMfg60ujaY/8DGD7Nj2CcdRCuikjgORCgdXARM/Fzuz02wHSvtxb+xjB6BpouRQuZXzyCeFlFq43w4kJg3NcDsMvzTeOZGEqUgawrNYbbZgHwJqd/fkk4SBvDR1AAAAN/pre> +** Bytes in Hex: <pre><70736274ff010071020000000127744ababf3027fe0d6cf23a96eee2efb188ef52301954585883e69b6624b2420000000000ffffffff02787c01000000000016001483a7e34bd99ff03a4962ef8a1a101bb295461ece606b042a010000001600147ac369df1b20e033d6116623957b0ac49f3c52e8000000000001012b00f2052a010000002251205a2c2cf5b52cf31f83ad2e8da63ff03183ecd8f609c7510ae8a48e03910a075701133f173bb3d36c074afb716fec6307a069a2e450b995f3c82785945ab8df0e24260dcd703b0cbf34de399184a9481ac2b3586db6601f026a77f7e4938481bc3475000000</pre> +** Base64 String: <pre>cHNidP8BAHECAAAAASd0Srq/MCf+DWzyOpbu4u+xiO9SMBlUWFiD5ptmJLJCAAAAAAD/////Anh8AQAAAAAAFgAUg6fjS9mf8DpJYu+KGhAbspVGHs5gawQqAQAAABYAFHrDad8bIOAz1hFmI5V7CsSfPFLoAAAAAAABASsA8gUqAQAAACJRIFosLPW1LPMfg60ujaY/8DGD7Nj2CcdRCuikjgORCgdXARM/Fzuz02wHSvtxb+xjB6BpouRQuZXzyCeFlFq43w4kJg3NcDsMvzTeOZGEqUgawrNYbbZgHwJqd/fkk4SBvDR1AAAA</pre> * Case: PSBT With <tt>PSBT_KEY_PATH_SIG</tt> signature that is too long -** Bytes in Hex: <pre><70736274ff010071020000000127744ababf3027fe0d6cf23a96eee2efb188ef52301954585883e69b6624b2420000000000ffffffff02787c01000000000016001483a7e34bd99ff03a4962ef8a1a101bb295461ece606b042a010000001600147ac369df1b20e033d6116623957b0ac49f3c52e8000000000001012b00f2052a010000002251205a2c2cf5b52cf31f83ad2e8da63ff03183ecd8f609c7510ae8a48e03910a0757011342173bb3d36c074afb716fec6307a069a2e450b995f3c82785945ab8df0e24260dcd703b0cbf34de399184a9481ac2b3586db6601f026a77f7e4938481bc34751701aa000000/pre> +** Bytes in Hex: <pre><70736274ff010071020000000127744ababf3027fe0d6cf23a96eee2efb188ef52301954585883e69b6624b2420000000000ffffffff02787c01000000000016001483a7e34bd99ff03a4962ef8a1a101bb295461ece606b042a010000001600147ac369df1b20e033d6116623957b0ac49f3c52e8000000000001012b00f2052a010000002251205a2c2cf5b52cf31f83ad2e8da63ff03183ecd8f609c7510ae8a48e03910a0757011342173bb3d36c074afb716fec6307a069a2e450b995f3c82785945ab8df0e24260dcd703b0cbf34de399184a9481ac2b3586db6601f026a77f7e4938481bc34751701aa000000</pre> ** Base64 String: <pre>cHNidP8BAHECAAAAASd0Srq/MCf+DWzyOpbu4u+xiO9SMBlUWFiD5ptmJLJCAAAAAAD/////Anh8AQAAAAAAFgAUg6fjS9mf8DpJYu+KGhAbspVGHs5gawQqAQAAABYAFHrDad8bIOAz1hFmI5V7CsSfPFLoAAAAAAABASsA8gUqAQAAACJRIFosLPW1LPMfg60ujaY/8DGD7Nj2CcdRCuikjgORCgdXARNCFzuz02wHSvtxb+xjB6BpouRQuZXzyCeFlFq43w4kJg3NcDsMvzTeOZGEqUgawrNYbbZgHwJqd/fkk4SBvDR1FwGqAAAA</pre> * Case: PSBT With <tt>PSBT_IN_TAP_BIP32_DERIVATION</tt> key that is too long (incorrectly serialized as compressed DER) -** Bytes in Hex: <pre><70736274ff010071020000000127744ababf3027fe0d6cf23a96eee2efb188ef52301954585883e69b6624b2420000000000ffffffff02787c01000000000016001483a7e34bd99ff03a4962ef8a1a101bb295461ece606b042a010000001600147ac369df1b20e033d6116623957b0ac49f3c52e8000000000001012b00f2052a010000002251205a2c2cf5b52cf31f83ad2e8da63ff03183ecd8f609c7510ae8a48e03910a0757221602fe349064c98d6e2a853fa3c9b12bd8b304a19c195c60efa7ee2393046d3fa2321900772b2da75600008001000080000000800100000000000000000000/pre> +** Bytes in Hex: <pre><70736274ff010071020000000127744ababf3027fe0d6cf23a96eee2efb188ef52301954585883e69b6624b2420000000000ffffffff02787c01000000000016001483a7e34bd99ff03a4962ef8a1a101bb295461ece606b042a010000001600147ac369df1b20e033d6116623957b0ac49f3c52e8000000000001012b00f2052a010000002251205a2c2cf5b52cf31f83ad2e8da63ff03183ecd8f609c7510ae8a48e03910a0757221602fe349064c98d6e2a853fa3c9b12bd8b304a19c195c60efa7ee2393046d3fa2321900772b2da75600008001000080000000800100000000000000000000</pre> ** Base64 String: <pre>cHNidP8BAHECAAAAASd0Srq/MCf+DWzyOpbu4u+xiO9SMBlUWFiD5ptmJLJCAAAAAAD/////Anh8AQAAAAAAFgAUg6fjS9mf8DpJYu+KGhAbspVGHs5gawQqAQAAABYAFHrDad8bIOAz1hFmI5V7CsSfPFLoAAAAAAABASsA8gUqAQAAACJRIFosLPW1LPMfg60ujaY/8DGD7Nj2CcdRCuikjgORCgdXIhYC/jSQZMmNbiqFP6PJsSvYswShnBlcYO+n7iOTBG0/ojIZAHcrLadWAACAAQAAgAAAAIABAAAAAAAAAAAAAA==</pre> * Case: PSBT With <tt>PSBT_OUT_TAP_INTERNAL_KEY</tt> key that is too long (incorrectly serialized as compressed DER) @@ -200,7 +200,7 @@ The following are invalid PSBTs: ** Base64 String: <pre>cHNidP8BAF4CAAAAAZvUh2UjC/mnLmYgAflyVW5U8Mb5f+tWvLVgDYF/aZUmAQAAAAD/////AUjmBSoBAAAAIlEgAw2k/OT32yjCyylRYx4ANxOFZZf+ljiCy1AOaBEsymMAAAAAAAEBKwDyBSoBAAAAIlEgwiR++/2SrEf29AuNQtFpF1oZ+p+hDkol1/NetN2FtpJBFCyxOsaCSN6AaqajZZzzwD62gh0JyBFKToaP696GW7bSzZcOFfU/wMgvlQ/VYP+pGbdhcr4Bc2iomROvB09ACwlCiXVqo3OczGiewPzzo2C+MswLWbFuk6Hou0YFcmssp6P/cGxBdmSWMrLMaOH5ErileONxnOdxCIXHqWb0m81DywEBAAA=</pre> * Case: PSBT With <tt>PSBT_IN_TAP_SCRIPT_SIG</tt> signature that is too short -** Bytes in Hex: <pre><70736274ff01005e02000000019bd48765230bf9a72e662001f972556e54f0c6f97feb56bcb5600d817f6995260100000000ffffffff0148e6052a01000000225120030da4fce4f7db28c2cb2951631e003713856597fe963882cb500e68112cca63000000000001012b00f2052a01000000225120c2247efbfd92ac47f6f40b8d42d169175a19fa9fa10e4a25d7f35eb4dd85b69241142cb13ac68248de806aa6a3659cf3c03eb6821d09c8114a4e868febde865bb6d2cd970e15f53fc0c82f950fd560ffa919b76172be017368a89913af074f400b093989756aa3739ccc689ec0fcf3a360be32cc0b59b16e93a1e8bb4605726b2ca7a3ff706c4176649632b2cc68e1f912b8a578e3719ce7710885c7a966f49bcd43cb0000/pre> +** Bytes in Hex: <pre><70736274ff01005e02000000019bd48765230bf9a72e662001f972556e54f0c6f97feb56bcb5600d817f6995260100000000ffffffff0148e6052a01000000225120030da4fce4f7db28c2cb2951631e003713856597fe963882cb500e68112cca63000000000001012b00f2052a01000000225120c2247efbfd92ac47f6f40b8d42d169175a19fa9fa10e4a25d7f35eb4dd85b69241142cb13ac68248de806aa6a3659cf3c03eb6821d09c8114a4e868febde865bb6d2cd970e15f53fc0c82f950fd560ffa919b76172be017368a89913af074f400b093989756aa3739ccc689ec0fcf3a360be32cc0b59b16e93a1e8bb4605726b2ca7a3ff706c4176649632b2cc68e1f912b8a578e3719ce7710885c7a966f49bcd43cb0000</pre> ** Base64 String: <pre>cHNidP8BAF4CAAAAAZvUh2UjC/mnLmYgAflyVW5U8Mb5f+tWvLVgDYF/aZUmAQAAAAD/////AUjmBSoBAAAAIlEgAw2k/OT32yjCyylRYx4ANxOFZZf+ljiCy1AOaBEsymMAAAAAAAEBKwDyBSoBAAAAIlEgwiR++/2SrEf29AuNQtFpF1oZ+p+hDkol1/NetN2FtpJBFCyxOsaCSN6AaqajZZzzwD62gh0JyBFKToaP696GW7bSzZcOFfU/wMgvlQ/VYP+pGbdhcr4Bc2iomROvB09ACwk5iXVqo3OczGiewPzzo2C+MswLWbFuk6Hou0YFcmssp6P/cGxBdmSWMrLMaOH5ErileONxnOdxCIXHqWb0m81DywAA</pre> * Case: PSBT With <tt>PSBT_IN_TAP_LEAF_SCRIPT</tt> Control block that is too long diff --git a/bip-0380.mediawiki b/bip-0380.mediawiki index d57bbc6..f870734 100644 --- a/bip-0380.mediawiki +++ b/bip-0380.mediawiki @@ -206,7 +206,7 @@ However many components of the expressions reuse encodings and serializations de Output script descriptors are designed for future extension with further fragment types and new script expressions. These will be specified in additional BIPs. -==Reference Implemntation== +==Reference Implementation== Descriptors have been implemented in Bitcoin Core since version 0.17. diff --git a/bip-0381.mediawiki b/bip-0381.mediawiki index 8d7e391..f439597 100644 --- a/bip-0381.mediawiki +++ b/bip-0381.mediawiki @@ -78,6 +78,6 @@ TBD As these are a wholly new descriptors, they are not compatible with any implementation. However the scripts produced are standard scripts so existing software are likely to be familiar with them. -==Reference Implemntation== +==Reference Implementation== <tt>pk()</tt>, <tt>pkh()</tt>, and <tt>sh()</tt> descriptors have been implemented in Bitcoin Core since version 0.17. diff --git a/bip-0382.mediawiki b/bip-0382.mediawiki index 0508d2b..768079e 100644 --- a/bip-0382.mediawiki +++ b/bip-0382.mediawiki @@ -65,6 +65,6 @@ TBD As these are a wholly new descriptors, they are not compatible with any implementation. However the scripts produced are standard scripts so existing software are likely to be familiar with them. -==Reference Implemntation== +==Reference Implementation== <tt>wpkh()</tt>, and <tt>wsh()</tt> descriptors have been implemented in Bitcoin Core since version 0.17. diff --git a/bip-0383.mediawiki b/bip-0383.mediawiki index 6b74950..92e86e3 100644 --- a/bip-0383.mediawiki +++ b/bip-0383.mediawiki @@ -73,6 +73,6 @@ TBD As these are a wholly new descriptors, they are not compatible with any implementation. However the scripts produced are standard scripts so existing software are likely to be familiar with them. -==Reference Implemntation== +==Reference Implementation== -<tt>multi()</tt>, and <tt>multi()</tt> descriptors have been implemented in Bitcoin Core since version 0.17. +<tt>multi()</tt>, and <tt>sortedmulti()</tt> descriptors have been implemented in Bitcoin Core since version 0.17. diff --git a/bip-0384.mediawiki b/bip-0384.mediawiki index da7cb23..e735d74 100644 --- a/bip-0384.mediawiki +++ b/bip-0384.mediawiki @@ -43,6 +43,6 @@ TBD As this is a wholly new descriptor, it is not compatible with any implementation. However the scripts produced are standard scripts so existing software are likely to be familiar with them. -==Reference Implemntation== +==Reference Implementation== -<tt>combo</tt> descriptors have been implemented in Bitcoin Core since version 0.17. +<tt>combo()</tt> descriptors have been implemented in Bitcoin Core since version 0.17. diff --git a/bip-0385.mediawiki b/bip-0385.mediawiki index 2469eb0..5c46d75 100644 --- a/bip-0385.mediawiki +++ b/bip-0385.mediawiki @@ -52,6 +52,6 @@ TBD As this is a wholly new descriptor, it is not compatible with any implementation. The reuse of existing Bitcoin addresses allows for this to be more easily implemented. -==Reference Implemntation== +==Reference Implementation== -<tt>raw()</tt> and <tt>addr</tt> descriptors have been implemented in Bitcoin Core since version 0.17. +<tt>raw()</tt> and <tt>addr()</tt> descriptors have been implemented in Bitcoin Core since version 0.17. |
