├── README.md ├── spec-p2p.md └── spec.md /README.md: -------------------------------------------------------------------------------- 1 | # Extension Blocks 2 | 3 | This repository contains the specification for extension blocks with a BIP141 4 | ruleset. 5 | 6 | - Consensus: https://github.com/tothemoon-org/extension-blocks/blob/master/spec.md 7 | - P2P: https://github.com/tothemoon-org/extension-blocks/blob/master/spec-p2p.md 8 | -------------------------------------------------------------------------------- /spec-p2p.md: -------------------------------------------------------------------------------- 1 | # Extension Blocks (peer services) 2 | 3 | ``` 4 | Layer: Peer Services 5 | Title: Extension Blocks (peer services) 6 | Author: Christopher Jeffrey 7 | Status: Draft 8 | Created: 2017-03-17 9 | License: Public Domain 10 | ``` 11 | 12 | ## Abstract 13 | 14 | This specification defines peer services for extension blocks. 15 | 16 | ## Specification 17 | 18 | ### Peer Services 19 | 20 | Extension blocks defines a new service bit (service bit 5) to signal whether 21 | extension blocks is supported by the remote node. 22 | 23 | ### Block and transaction relay 24 | 25 | This specification defines new INV types for GETDATA requests. Similar to the 26 | INV types defined in BIP144, an `extended bit` is to be set on both `tx` and 27 | `block` inv types. The extended bit exists as the 30th bit, e.g. `1` would 28 | become `536870913` (`(1 << 29) | 1`). 29 | 30 | Newly defined inv types are as follows: 31 | 32 | - `EXT_TX`: `536870913` (`(1 << 29) | 1`) 33 | - `EXT_BLOCK`: `536870914` (`(1 << 29) | 2`) 34 | 35 | #### Backward Compatability 36 | 37 | To avoid an enormous amount of orphan transactions on non-upgraded nodes, 38 | upgraded nodes shall respond with a NOTFOUND message in response to any regular 39 | GETDATA TX request which maps to an extension chain transaction. Invs 40 | containing extension transactions shall not be broadcast to non-upgraded peers. 41 | 42 | Responses GETDATA EXT_TX shall include both extension and non-extension 43 | transactions. 44 | 45 | ### `EXT_BLOCK` message serialization 46 | 47 | `block` messages requested with the `EXT_BLOCK` inv type are to use the 48 | canonical serialization with an extra varint count appended. Following the 49 | varint count shall be a transaction vector using BIP141 serialization. Clients 50 | MUST disregard blocks which use BIP141 serialization in the canonical 51 | transaction vector. 52 | 53 | ### Extensions to Compact Block Relay (BIP152) 54 | 55 | Compact block relay shall be initiated using the previously specified (BIP152) 56 | `sendcmpct` message, with a version of `3`. Serialization for `cmpctblock`, 57 | `blocktxnrequest`, and `blocktxn` are modified to include two transaction 58 | vectors. The first being canonical, and the second being extended. 59 | 60 | ## Reference Implementation 61 | 62 | https://github.com/bcoin-org/bcoin-extension-blocks 63 | 64 | ## Copyright 65 | 66 | This document is hereby placed in the public domain. 67 | -------------------------------------------------------------------------------- /spec.md: -------------------------------------------------------------------------------- 1 | # Extension Blocks 2 | 3 | ``` 4 | Layer: Consensus (soft-fork) 5 | Title: Extension Blocks 6 | Author: Christopher Jeffrey 7 | Joseph Poon 8 | Fedor Indutny 9 | Stephen Pair 10 | Status: Draft 11 | Created: 2017-03-17 12 | License: Public Domain 13 | ``` 14 | 15 | ## Abstract 16 | 17 | This specification defines a method of increasing bitcoin transaction 18 | throughput without altering any existing consensus rules. 19 | 20 | ## Motivation 21 | 22 | The bitcoin network's transaction throughput is correlated with its consensus 23 | rules regarding retargetting and denial-of-service limits. 24 | 25 | Bitcoin retargetting ensures that the time in between mined blocks will be 26 | roughly 10 minutes. It is not possible to change this rule. There has been 27 | debate regarding other ways of greatly increasing transaction throughput, with 28 | no proposed consensus-layer solutions that have proven themselves to be 29 | particularly safe. 30 | 31 | ## History 32 | 33 | _Auxiliary blocks_, as first proposed by [Johnson Lau in 2013][aux], outlined a 34 | way of having funds enter and exit an additional block by using special 35 | opcodes. 36 | 37 | _Extension blocks_ were a later proposal, also [from Lau in 2017][ext], which 38 | revised many of the ideas of the original proposal. 39 | 40 | ## Specification 41 | 42 | Extension blocks devise a second layer on top of canonical bitcoin blocks in 43 | which a miner will commit to the merkle root of an additional block of 44 | transactions. 45 | 46 | Extension blocks leverage several features of BIP141, BIP143, and BIP144 for 47 | transaction opt-in, serialization, verification, and network services. This 48 | specification should be considered an extension and modification to these BIPs. 49 | Extension blocks are _not_ compatible with BIP141 in its current form, and will 50 | require a few minor additional rules. 51 | 52 | Extension blocks maintain their own UTXO set in order to avoid interference 53 | with the existing UTXO set of non-upgraded nodes. This is a tricky endeavor, 54 | requiring a `resolution` transaction to be present at the end of every 55 | canonical block. 56 | 57 | This specification prescribes a way of fooling non-upgraded nodes into 58 | believing the existing UTXO set is still behaving as they would expect. 59 | Unfortunately, this requires a bit of extra book-keeping on the upgraded node's 60 | side. 61 | 62 | ### Commitment 63 | 64 | An upgraded miner willing to include extension block is to include an extra 65 | coinbase output of 0 value. The output script exists as such: 66 | 67 | ``` 68 | OP_RETURN 0x24 0xaa21a9ef[32-byte-merkle-root] 69 | ``` 70 | 71 | The commitment serialization and discovery rules follows the same rules defined 72 | in BIP141. 73 | 74 | The merkle root is to be calculated as a merkle tree with all extension and 75 | canonical block txids and wtxids as the leaves. 76 | 77 | Any block containing an extension block MUST include an extension commitment 78 | output. 79 | 80 | ### Extension block opt-in 81 | 82 | Outputs can signal to enter the extension block by using witness program 83 | scripts (specified in BIP141). Outputs signal to exit the extension block if 84 | the contained script is either a minimally encoded P2PKH or P2SH script. 85 | 86 | Output script code aside from witness programs, p2pkh or p2sh is considered 87 | invalid in extension blocks. 88 | 89 | ### Resolution 90 | 91 | Resolution transactions are a book-keeping mechanism which exist to maintain 92 | the total value of the extension block UTXO set. They exist as a consecutively 93 | redeemed OP_TRUE output. They handle both entrance into and exits from the 94 | extension block UTXO set. 95 | 96 | Every block containing entering or exiting outputs MUST contain a final 97 | `resolution` transaction. This resolution transaction spends all outputs that 98 | intend to enter the extension block. The resolution transaction MUST appear as 99 | the last transaction in the block (in order to properly sweep all of the newly 100 | created outputs). The funds are to be sent to a single anyone-can-spend 101 | (OP_TRUE) output. This output is forbidden by consensus rules to be spent by 102 | any transaction aside from another `resolution` transaction. 103 | 104 | The resolution transaction MUST contain additional outputs for outputs that 105 | intend to exit the extension block. 106 | 107 | Coinbase outputs MUST NOT contain witness programs, as they cannot be sweeped 108 | by the resolution transaction due to previously existing consensus rules. 109 | 110 | The first input of a resolution transaction MUST reference the first output of 111 | the previous resolution transaction. 112 | 113 | Fees are to propagate up from the extension block into the resolution 114 | transaction. In other words, the resolution transaction's fee should should be 115 | equal to the amount of total fees collected in the extension block. 116 | 117 | #### Bootstrapping 118 | 119 | In order to bootstrap the activation of extension blocks, a "genesis" 120 | resolution transaction MUST be mined in the first block to include an extension 121 | block commitment along with any entering outputs (the `activation` block). This 122 | is the only resolution transaction in existence that does not require a 123 | reference to a previous resolution transaction. 124 | 125 | The genesis resolution transaction MAY also include a 1-100 byte script in the 126 | first input, containing a single push-only opcode. This allows the miner of the 127 | genesis resolution to add a special message. The input script MUST execute 128 | without failure (no malformed pushdatas, no OP_RESERVED). 129 | 130 | #### Resolution Rules 131 | 132 | The resolution transaction's first output MUST have a value equal to: 133 | 134 | `(previous-resolution-value + entering-value - exiting-value) - ext-block-fees` 135 | 136 | The following output scripts and values must replicate the extension block's 137 | exiting outputs _exactly_ (in the same order they appear in the ext. block). 138 | 139 | The resolution transaction's version MUST be set to the uint32 max (`2^32 - 1`). 140 | After activation, this version is forbidden by consensus rules to be used with 141 | any other transaction on the canonical chain or extension chain. This is 142 | required for easy non-contextual identification of a resolution transaction. 143 | 144 | ### Entering the extension block 145 | 146 | Any witness program output is considered an opt-in to fund a keyhash or 147 | scripthash within the extension block's UTXO set. 148 | 149 | Example block: 150 | 151 | ``` 152 | Transaction #1 (coinbase): 153 | 154 | Output #0: 155 | - Script: P2PKH 156 | - Value: 12.5 157 | 158 | Output #1: 159 | - Script: OP_RETURN 0xaa21a9ef[merkle-root] 160 | - Value: 0 161 | ``` 162 | 163 | ``` 164 | Transaction #2 (extension block funding transaction): 165 | 166 | Output #0: 167 | - Script: P2WPKH (will enter the extension utxo set) 168 | - Value: 5.0 169 | 170 | Output #1: 171 | - Script: P2PKH (stays in the canonical utxo set) 172 | - Value: 2.5 173 | ``` 174 | 175 | The resolution transaction shall redeem any witness program outputs: 176 | 177 | ``` 178 | Transaction #3 (resolution transaction): 179 | 180 | Input #0: 181 | - Outpoint: 182 | - Hash: previous-resolution-txid 183 | - Index: 0 184 | 185 | Input #1: 186 | - Outpoint: 187 | - Hash: Transaction #2 TXID 188 | - Index: 0 189 | 190 | Output #0: 191 | - Script: OP_TRUE 192 | - Value: 5.0 193 | ``` 194 | 195 | In the case that a spender wants to redeem tx2/output0, the corresponding 196 | extension block may exist as such: 197 | 198 | ``` 199 | Transaction #4 (redeemer of transaction #2): 200 | 201 | Input #0: 202 | - Outpoint: 203 | - Hash: Transaction #2 TXID 204 | - Index: 0 205 | 206 | Output #0: 207 | - Script: P2WPKH (this output remains in the ext. block) 208 | - Value: 5.0 209 | ``` 210 | 211 | ### Exiting the extension block 212 | 213 | In order to ensure a 1-to-1 value between the existing blockchain and the 214 | extension block, an exit must be provided for outputs that exist in the 215 | extension block. 216 | 217 | In a later transaction, the spender of Transaction #2's output may want an 218 | output to exit with some of their money. 219 | 220 | ``` 221 | Transaction #5 (coinbase): 222 | 223 | Output #0: 224 | - Script: P2PKH 225 | - Value: 12.5 226 | 227 | Output #1: 228 | - Script: OP_RETURN 0xaa21a9ef[merkle-root] 229 | - Value: 0 230 | ``` 231 | 232 | ``` 233 | Transaction #6 (resolution transaction): 234 | 235 | Input #0: 236 | - Outpoint: 237 | - Hash: previous-resolution-txid 238 | - Index: 0 239 | 240 | Output #0: 241 | - Script: OP_TRUE 242 | - Value: 2.5 243 | 244 | Output #1: 245 | - Script: P2PKH (duplicated from the exited output below) 246 | - Value: 2.5 247 | ``` 248 | 249 | Extension block: 250 | 251 | ``` 252 | Transaction #7: 253 | 254 | Input #0: 255 | - Outpoint: 256 | - Hash: Transaction #4 TXID 257 | - Index: 0 258 | 259 | Output #0: 260 | - Script: P2WPKH (this output will remain in the ext. block) 261 | - Value: 2.5 262 | 263 | Output #1: 264 | - Script: P2PKH (note that this causes an exit!) 265 | - Value: 2.5 266 | ``` 267 | 268 | #### Exit Redemption 269 | 270 | As described above, outputs exit from the extension block onto the main chain 271 | by way of the resolution transaction. The outpoint created in the extension 272 | block MUST not to be spent on either chain. Instead, exiting outputs must be 273 | spent from outpoints created on the resolution transaction. 274 | 275 | #### Exit Maturity Requirement 276 | 277 | Similar to coinbase transactions, resolution transactions can also be 278 | permanently un-mined in the case of a reorganization. This potentially 279 | invalidates all spends from any exiting outputs it may have contained, 280 | rendering the spending transactions not relayable and no longer mineable on the 281 | best chain. An exit maturity requirement is required for this reason. 282 | 283 | See: https://github.com/tothemoon-org/extension-blocks/issues/9 284 | 285 | ### Fees 286 | 287 | Fees collected from inside the extension block propagate up to the 288 | corresponding resolution transaction. The resolution transaction's fee MUST be 289 | equal to the cumulative amount of fees collected inside the extension block. 290 | 291 | On the policy layer, transaction fees may be calculated by transaction cost as 292 | well as additional size/legacy-sigops added to the canonical block due to 293 | entering or exiting outputs. 294 | 295 | In the previous example, the spender of Transaction #2's output could have also 296 | added a fee. 297 | 298 | ``` 299 | Transaction #5 (coinbase): 300 | 301 | Output #0: 302 | - Script: P2PKH 303 | - Value: 12.501 (reward + fee) 304 | 305 | Output #1: 306 | - Script: OP_RETURN 0xaa21a9ef[merkle-root] 307 | - Value: 0 308 | ``` 309 | 310 | ``` 311 | Transaction #6 (resolution transaction): 312 | 313 | Input #0: 314 | - Outpoint: 315 | - Hash: previous-resolution-txid 316 | - Index: 0 317 | 318 | Output #0: 319 | - Script: OP_TRUE 320 | - Value: 2.499 (fee is subtracted) 321 | 322 | Output #1: 323 | - Script: P2PKH (from the exited output below) 324 | - Value: 2.5 325 | ``` 326 | 327 | Extension block: 328 | 329 | ``` 330 | Transaction #7: 331 | 332 | Input #0: 333 | - Outpoint: 334 | - Hash: Transaction #4 TXID 335 | - Index: 0 336 | 337 | Output #0: 338 | - Script: P2WPKH (this output will remain in the ext. block) 339 | - Value: 2.499 (fee is subtracted, this propagates up) 340 | 341 | Output #1: 342 | - Script: P2PKH (note that this causes an exit!) 343 | - Value: 2.5 344 | ``` 345 | 346 | ### Verification 347 | 348 | Verification of transactions within the extension block shall enforce all 349 | currently deployed softforks, along with an extra BIP141-like ruleset. 350 | 351 | Transactions within the extended transaction vector MAY include a witness 352 | vector using BIP141 transaction serialization. 353 | 354 | Verification shall be performed on extended transactions with `VERIFY_WITNESS` 355 | rules. 356 | 357 | Extended transactions MUST NOT have any access to the canonical UTXO set. 358 | 359 | If an extension block fails any consensus check, the upgraded node MUST 360 | consider the entire block invalid. 361 | 362 | ### BIP141 Rule Changes 363 | 364 | - Aside from the resolution transaction, witness program outputs are only 365 | redeemable inside of an extension block. 366 | - Witness transactions may _only_ contain witness program inputs. 367 | - BIP141's nested P2SH feature is no longer available, and no longer a 368 | consensus rule. 369 | - The concepts of `block weight` and `transaction weight` have been removed. 370 | - The concept of `sigops cost` remains present for future soft-forkable and 371 | upgradeable DoS limits. 372 | 373 | ### DoS Limits 374 | 375 | DoS limits shall be enforced by extension block size as well as the newly 376 | defined metrics of inputs and outputs cost. Be aware that exiting outputs 377 | inside the extension block affect DoS limits in the canonical block, as they 378 | add size and legacy sigops. 379 | 380 | ``` 381 | MAX_BLOCK_SIZE: 1000000 (unchanged) 382 | MAX_BLOCK_SIGOPS: 20000 (unchanged) 383 | MAX_EXTENSION_SIZE: TBD 384 | MAX_EXTENSION_COST: TBD 385 | ``` 386 | 387 | The maximum extension size should be intentionally high. The average case block 388 | is truly limited by inputs (sigops) and outputs cost. 389 | 390 | Future size and computational scalability can be soft-forked in with the 391 | addition of new witness programs. On non-upgraded nodes, unknown witness 392 | programs count as 1 inputs/outputs cost. Lesser cost can be implemented for 393 | newer witness programs in order to allow future soft-forked dos limit changes. 394 | 395 | ##### Extended Transaction Cost 396 | 397 | Extension blocks leverage BIP141's upgradeable script behavior to also allow 398 | for upgradeable DoS limits. 399 | 400 | ###### Calculating Inputs Cost 401 | 402 | Witness key hash v0 shall be worth 1 point, multiplied by a factor of 8. 403 | 404 | Witness script hash v0 shall be worth the number of accurately counted sigops 405 | in the redeem script, multiplied by a factor of 8. 406 | 407 | Unknown witness programs shall be worth 1 point, multiplied by a factor of 1. 408 | 409 | To reduce the chance of having redeem scripts which simply allow for garbage 410 | data in the witness vector, every 73 bytes in the serialized witness vector is 411 | worth 1 additional point. 412 | 413 | This leaves room for 7 future soft-fork upgrades to relax DoS limits. 414 | 415 | ###### Calculating Outputs Cost 416 | 417 | Currently defined witness programs (v0) are each worth 8 points. Unknown 418 | witness program outputs are worth 1 point. Any exiting output is always worth 419 | 8 points. 420 | 421 | This leaves room for 7 future soft-fork upgrades to relax DoS limits. 422 | 423 | #### Dust Threshold 424 | 425 | A consensus dust threshold is now enforced within the extension block. 426 | 427 | Outputs containing less than 500 satoshis of value are _invalid_ within an 428 | extension block. This _includes_ entering outputs as well, but not exiting 429 | outputs. 430 | 431 | ### Rules for extra Lightning security 432 | 433 | Lightning Network faces certain kinds of systemic attacks as defined in the 434 | Lightning Network whitepaper risks (mass-closeout of old states). 435 | 436 | If the second highest transaction version bit (30th bit) is set to to `1` 437 | within an extension block transaction, an extra 700-bytes is reserved on the 438 | transaction space used up in the block. [NOTE: Transaction space and sigops 439 | cost not yet defined] 440 | 441 | This space per transaction is pre-allocated and can be consumed in the same 442 | block by two transactions (of a maximum size of 350 bytes each), which fulfill 443 | specific constraints as defined below. 444 | 445 | The first allocation may only be consumed by a transaction which directly 446 | spends from the first output of the transaction with the 30th bit set. 447 | 448 | The second allocation may only consume the first output of ANY transaction 449 | within the past 2016 blocks which have the 30th bit set. 450 | 451 | If the allocation is not used by other transactions, the transaction consumes 452 | that extra space, reducing the blocksize by up to 700 bytes in available space. 453 | 454 | This is a consensus rule within the extension block and does not apply to the 455 | main-chain block. 456 | 457 | The purpose of this is to ensure that without miner coordination, the costs 458 | will be unusually high for systemic attacks, since blockspace is preallocated 459 | for miners to include penalty Lightning Network transactions, and this is 460 | enforced since both parties must agree to the version bit in Commitment 461 | Transaction in Lightning. This is an opt-in feature in Lightning, and trades 462 | higher transaction fees for greater availability for penalties. The assumption 463 | is that in the majority of cases of an incorrect broadcast, the penalty will be 464 | included in the same block via the second allocation, and give room for other 465 | transactions in the first allocation. 466 | 467 | ### Migration and adoption concerns 468 | 469 | Most of the bitcoin ecosystem is currently well-equipped to handle an upgrade 470 | to BIP141. 471 | 472 | For wallets currently supporting BIP141, the migration should be trivial. 473 | 474 | For fullnode-based services, APIs may be altered to transparently serve 475 | extension block transactions to clients as if they appeared in the canonical 476 | block. This, of course, would not include any miner API. 477 | 478 | ### Wallet concerns and migration 479 | 480 | Wallets currently supporting BIP141 must be modified in a few key ways in order 481 | to achieve compatibility with extension blocks. 482 | 483 | 1. Wallets must pick a chain to spend from when creating a transaction (either 484 | the canonical block or the extension block, but not both). In other words, 485 | transactions must have all witness program inputs, or all non-witness program 486 | inputs. For wallets that support both chains, the coin selector can 487 | automatically pick which chain to use if the user does not specify. 488 | 489 | 2. Wallets supporting extension blocks must ignore inputs on 490 | resolution transactions if seen. This should be a simple check of transaction 491 | version number, and similar to how wallets already ignore a coinbase's input. 492 | This is necessary to prevent wallets from mistakenly seeing a double spend. 493 | 494 | 3. Wallets supporting both canonical block and extension block funds 495 | must ignore exiting outputs within the extension block. This is necessary to 496 | prevent wallets from mistakenly indexing the same output twice. 497 | 498 | The latter two points only apply to wallets with operate via direct blockchain 499 | monitoring. Monitoring wallets typically watch the blockchain and index their 500 | own transactions and outputs. 501 | 502 | ### Mempool Concerns 503 | 504 | Changes to mempool implementations are surprisingly minimal. Although details 505 | may differ across implementations, a conforming mempool must disallow 506 | cross-chain spends (mixed inputs on both chains), as well as track exiting 507 | output's outpoints. These outpoints may not be spent inside the mempool (they 508 | must be redeemed from the next resolution txid in reality). 509 | 510 | ### Mining Concerns 511 | 512 | #### Additional size and sigops calculation 513 | 514 | Nodes creating block templates internally will have to take into account 515 | entering and exiting outputs when reserving size for the canonical block. A 516 | transaction with entering outputs or exiting outputs adds size to the canonical 517 | block. 518 | 519 | Entering outputs add size in the form of inputs in the resolution transaction. 520 | 521 | Exiting outputs add both size and legacy sigops in the form of duplicated 522 | outputs on the resolution transaction. 523 | 524 | Transaction sorting and selection algorithms must take care to account for 525 | this. 526 | 527 | #### Extensions to `getblocktemplate` (BIP22) 528 | 529 | In addition to the `transactions` array, conforming implementations MUST 530 | include an `extension` array. The `extension` array contains transactions as 531 | defined in BIP22 as well as the BIP145 extensions to `getblocktemplate`. 532 | 533 | Conforming implementations MUST include the resolution transaction as part of 534 | the `transactions` array. The resolution transaction must have an extra 535 | property called `resolution`, which is a boolean value set to `true`. Including 536 | the resolution TX in the `transactions` array directly is done for backward 537 | compatibility with existing mining clients. 538 | 539 | `default_witness_commitment` has been renamed to `default_extension_commitment` 540 | and includes the extension block commitment script. 541 | 542 | An extra `mutable` field is defined for `"resolution"`. If `transactions` is 543 | present in the mutable array, `resolution` allows extension block mutation, 544 | provided the client is able to properly update the resolution transaction. 545 | 546 | Along with the `resolution` mutable field, a `resolution` `capabilities` field 547 | is also defined in order for the client to state that it is capable of updating 548 | the resolution transaction. 549 | 550 | For nodes dealing with out of date mining clients, storing the extension block 551 | locally in a map of `commitment-hash->ext. block` may be required (along with 552 | some reserialization during a `submitblock` call). 553 | 554 | ### Data Migration Concerns 555 | 556 | It is likely that implementations will need to include an extra bit on every 557 | stored UTXO in order to mark which chain they belong to. Depending on the 558 | implementation's UTXO serialization/compression format, this may require a 559 | database migration. 560 | 561 | ### Activation 562 | 563 | - Version bit: 2 564 | - Deployment name: `extblk` (appears as `!extblk` in GBT). 565 | - Start time: TBD 566 | - Timeout: TBD 567 | 568 | ### Deactivation 569 | 570 | Miners may vote on deactivation of the extension block via the 28th BIP9 571 | softfork bit. The "deactivation" deployment's start time shall begin 3 years 572 | after the start time of extension blocks, with a miner activation threshold of 573 | 95%. The minimum locked-in period must be at least 26 retarget intervals (1 574 | year). 575 | 576 | By this point, a future extension block ruleset will likely have been 577 | developed, which is superior in terms of feature-set and scalability (see also: 578 | [Rootstock][rsk] and/or [Mimblewimble][mw]). This enables updates for long-term 579 | scalability solutions with minimal baggage of supporting deprecated chains. 580 | 581 | After deactivation, it is expected by the community that exits from the 582 | extension block will still still be possible and secure according to the terms 583 | of the yet-to-be-designed soft-fork, but entrance into and transfer of funds 584 | within the extension block could be no longer permitted. 585 | 586 | We propose two possible solutions for deactivation, one of which will be 587 | selected in the final version of this document. 588 | 589 | #### Deactivation Option #1 590 | 591 | Upon activation of the 28th bit, the resolution output will return to being an 592 | output which anyone-can-spend as a consensus rule today. This 28th BIP9 bit (or 593 | another BIP9 bit in conjunction) can be overloaded to enable soft-fork 594 | activation to prevent this from actually being an anyone-can-spend in the 595 | future. This allows for enabling future extension block features without 596 | hard-forking the code. 597 | 598 | A social contract is understood whereby the funds in the extension block will 599 | be usable and redeemable in the general deactivation design below. If proper 600 | and safe withdrawals are not activated within the terms, users and exchanges 601 | can refuse to acknolwedge blocks with the bit set as a soft-fork. 602 | 603 | It is possible to do a direct upgrade of the extension block by using the same 604 | output set upon BIP9 activation of the 28th bit in conjunction with new rules 605 | on another bit (e.g. 27th bit activates the new chain conditionally upon the 606 | 28th bit also being activated, creating a direct migration into a new extension 607 | block without new transactions on the main-chain). 608 | 609 | It is understood that this soft-fork will be overloaded with enforcement of 610 | withdrawal/redemption of funds so that it requires the script terms to be 611 | parsed upon withdrawal. 612 | 613 | #### Deactivation Option #2 614 | 615 | Upon activation of the 28th bit, no further transactions are permitted inside 616 | the extension block. Withdrawals to the main-chain only via merkle proofs are 617 | only permitted. 618 | 619 | This requires code and specification for merkle-proof withdrawals to be 620 | specified and available today. 621 | 622 | #### Deactivation via Merkle Tree Proofs 623 | 624 | Redemption from the old extension block to the main-chain and new extension 625 | block can be migrated by way of merkle proofs to be designed in the future. 626 | Funds may be imported to the new extension block by hard-coding a UTXO merkle 627 | root into the implementation as a consensus rule, and verifying imported funds 628 | against a merkle path. 629 | 630 | To enable importing, nodes require only a copy of the current 32-byte merkle 631 | root of the deactivated extension block. 632 | 633 | This removes the necessity for full nodes to store a copy of the full UTXO set 634 | on disk, with a tradeoff of larger on-chain transactions when redeeming in the 635 | future. An alternative would be for all clients to maintain a record of the 636 | UTXO set and keep the full bitfield in memory. 637 | 638 | Since the TXO set is static (with only whether it is unspent or spent changing) 639 | as it is deactivated from new outputs, this is simpler than currently proposed 640 | designs for changing UTXOs: 641 | https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-October/011638.html 642 | 643 | #### Motivation 644 | 645 | While deactivation may be seen as a drawback, the primary benefit of this 646 | specification is _not_ an extension block with a BIP141-ruleset. Instead, it is 647 | that the ecosystem will have laid the groundwork for handling extension blocks. 648 | The future of the bitcoin protocol may include several different extension 649 | blocks with many different rulesets. 650 | 651 | ## Reference Implementation (WIP) 652 | 653 | https://github.com/bcoin-org/bcoin-extension-blocks 654 | 655 | ## Copyright 656 | 657 | This document is hereby placed in the public domain. 658 | 659 | [aux]: https://bitcointalk.org/index.php?topic=283746.0 660 | [ext]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013490.html 661 | [rsk]: https://uploads.strikinglycdn.com/files/90847694-70f0-4668-ba7f-dd0c6b0b00a1/RootstockWhitePaperv9-Overview.pdf 662 | [mw]: https://scalingbitcoin.org/papers/mimblewimble.txt 663 | --------------------------------------------------------------------------------