From c3f7e6fe566299a18384a266471e15630afa657e Mon Sep 17 00:00:00 2001 From: Sanket Kanjalkar Date: Mon, 1 Mar 2021 23:01:26 -0800 Subject: Change `witness` to signature As per my understanding, the value is committed in the signature(sighash msg) and is not being supplied as an additional witness --- bip-0118.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0118.mediawiki b/bip-0118.mediawiki index 1b2f27c..afbfde6 100644 --- a/bip-0118.mediawiki +++ b/bip-0118.mediawiki @@ -92,7 +92,7 @@ Any participant can take a transaction and rewrite it by changing the hash reference to the previous output, without invalidating the signatures. This allows transactions to be bound to any output that matches the -value committed to in the witness and whose witnessProgram, +value committed to in the signature and whose witnessProgram, combined with the spending transaction's witness returns true. Previously, all information in the transaction was committed in the -- cgit v1.2.3 From 4817829dc89697fe3a258a9b80e0e9819659aa75 Mon Sep 17 00:00:00 2001 From: 8go Date: Mon, 15 Mar 2021 21:28:48 +0000 Subject: BIP-85: Added Ian Coleman's Mnemonic Code Converter - Added Ian Coleman's Mnemonic Code Converter to the "Other Implementations" section - https://iancoleman.io/bip39/ is a nice tool to play around with and to derive test data for BIP-85 PS: Sorry that I did not include this in the previous PR #1083. I just found this this very moment, but I think it is worth while to include because it gives the user/reader an instant tool to play with and to see results of BIP-85. --- bip-0085.mediawiki | 2 ++ 1 file changed, 2 insertions(+) diff --git a/bip-0085.mediawiki b/bip-0085.mediawiki index 182404f..efbc268 100644 --- a/bip-0085.mediawiki +++ b/bip-0085.mediawiki @@ -102,6 +102,8 @@ OUTPUT * Coldcard Firmware: [https://github.com/Coldcard/firmware/pull/39] +* Ian Coleman's Mnemonic Code Converter: [https://github.com/iancoleman/bip39] and [https://iancoleman.io/bip39/] + ==Applications== The Application number defines how entropy will be used post processing. Some basic examples follow: -- cgit v1.2.3 From f5a3140f2188905b5c5ca4217341332f4857ff1f Mon Sep 17 00:00:00 2001 From: Jonas Nick Date: Tue, 16 Mar 2021 16:01:02 +0000 Subject: BIP8: remove redundant and conflicting sentence from param selection At the end of the param selection section it's explicitly stated that startheight _must_ be a multiple of 2016. --- bip-0008.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0008.mediawiki b/bip-0008.mediawiki index 59bbb99..02aaaa4 100644 --- a/bip-0008.mediawiki +++ b/bip-0008.mediawiki @@ -48,7 +48,7 @@ The following guidelines are suggested for selecting these parameters for a soft # '''name''' should be selected such that no two softforks, concurrent or otherwise, ever use the same name. For deployments described in a single BIP, it is recommended to use the name "bipN" where N is the appropriate BIP number. # '''bit''' should be selected such that no two concurrent softforks use the same bit. The bit chosen should not overlap with active usage (legitimately or otherwise) for other purposes. -# '''startheight''' should be set to some block height in the future. It should be rounded up to the next height which begins a retarget period for simplicity. If '''minimum_activation_height''' is not going to be set, then '''startheight''' should be set to a height when a majority of economic activity is expected to have upgraded to software including the activation parameters. Some allowance should be made for potential release delays. If '''minimum_activation_height''' is going to be set, then '''startheight''' can be set to be soon after software with parameters is expected to be released. This shifts the time for upgrading from before signaling begins to during the LOCKED_IN state. +# '''startheight''' should be set to some block height in the future. If '''minimum_activation_height''' is not going to be set, then '''startheight''' should be set to a height when a majority of economic activity is expected to have upgraded to software including the activation parameters. Some allowance should be made for potential release delays. If '''minimum_activation_height''' is going to be set, then '''startheight''' can be set to be soon after software with parameters is expected to be released. This shifts the time for upgrading from before signaling begins to during the LOCKED_IN state. # '''timeoutheight''' should be set to a block height when it is considered reasonable to expect the entire economy to have upgraded by, probably at least 1 year, or 52416 blocks (26 retarget intervals) after '''startheight'''. # '''threshold''' should be 1815 blocks (90% of 2016), or 1512 (75%) for testnet. # '''minimum_activation_height''' should be set to several retarget periods in the future if the '''startheight''' is to be very soon after software with parameters is expected to be released. '''minimum_activation_height''' should be set to a height when a majority of economic activity is expected to have upgraded to software including the activation parameters. This allows more time to be spent in the LOCKED_IN state so that nodes can upgrade. This may be set to 0 to have the LOCKED_IN state be a single retarget period. -- cgit v1.2.3 From e1def09d6d75877a447dcc418a85291c80803a33 Mon Sep 17 00:00:00 2001 From: Jonas Nick Date: Fri, 19 Mar 2021 08:20:52 +0000 Subject: BIP8: fix typo: 2 retarget intervals are 4032 blocks. --- bip-0008.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0008.mediawiki b/bip-0008.mediawiki index 02aaaa4..d357401 100644 --- a/bip-0008.mediawiki +++ b/bip-0008.mediawiki @@ -57,7 +57,7 @@ The following guidelines are suggested for selecting these parameters for a soft A later deployment using the same bit is possible as long as the startheight is after the previous one's timeoutheight or activation, but it is discouraged until necessary, and even then recommended to have a pause in between to detect buggy software. -'''startheight''', '''timeoutheight''', and '''minimum_activation_height''' must be an exact multiple of 2016 (ie, at a retarget boundary), and '''timeoutheight''' must be at least 4096 blocks (2 retarget intervals) after '''startheight'''. +'''startheight''', '''timeoutheight''', and '''minimum_activation_height''' must be an exact multiple of 2016 (ie, at a retarget boundary), and '''timeoutheight''' must be at least 4032 blocks (2 retarget intervals) after '''startheight'''. ===States=== -- cgit v1.2.3 From a516c135ab622dcf0a4ecf204476034cb086d287 Mon Sep 17 00:00:00 2001 From: Anthony Towns Date: Thu, 25 Mar 2021 15:36:51 +1000 Subject: BIP341/342: document current deployment status --- bip-0341.mediawiki | 4 +++- bip-0342.mediawiki | 4 ++++ 2 files changed, 7 insertions(+), 1 deletion(-) diff --git a/bip-0341.mediawiki b/bip-0341.mediawiki index 0f8d32a..1e579e1 100644 --- a/bip-0341.mediawiki +++ b/bip-0341.mediawiki @@ -294,7 +294,9 @@ Examples of preimage for sighashing for each of the sighash modes. == Deployment == -TODO +This BIP is deployed concurrently with [[bip-0342.mediawiki|BIP342]]. + +For Bitcoin signet, these BIPs are always active. == Backwards compatibility == As a soft fork, older software will continue to operate without modification. diff --git a/bip-0342.mediawiki b/bip-0342.mediawiki index 7e00a2e..1e36a54 100644 --- a/bip-0342.mediawiki +++ b/bip-0342.mediawiki @@ -133,6 +133,10 @@ In addition to changing the semantics of a number of opcodes, there are also som +==Deployment== + +This proposal is deployed identically to Taproot ([[bip-0341.mediawiki|BIP341]]). + ==Examples== ==Acknowledgements== -- cgit v1.2.3 From 1145b99735a40447329f33f75a52b28e39ed5746 Mon Sep 17 00:00:00 2001 From: MarcoFalke Date: Mon, 29 Mar 2021 13:52:28 +0200 Subject: BIP 325: Remove empty section "Acknowledgement" --- bip-0325.mediawiki | 4 ---- 1 file changed, 4 deletions(-) diff --git a/bip-0325.mediawiki b/bip-0325.mediawiki index 5a9f3f1..be4ad02 100644 --- a/bip-0325.mediawiki +++ b/bip-0325.mediawiki @@ -110,10 +110,6 @@ Other software need not add block signature validation code that they will not u Pull request at https://github.com/bitcoin/bitcoin/pull/18267 -== Acknowledgements == - -TODO - == References == # Original mailing list thread: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-March/016734.html -- cgit v1.2.3 From f45d7c578481540fd88436a53b4123e332355ded Mon Sep 17 00:00:00 2001 From: kiminuo <58662979+kiminuo@users.noreply.github.com> Date: Wed, 31 Mar 2021 10:22:39 +0200 Subject: Update bip-0174.mediawiki I, personally, find this easier to read. --- bip-0174.mediawiki | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/bip-0174.mediawiki b/bip-0174.mediawiki index 75fea0e..56d9cdb 100644 --- a/bip-0174.mediawiki +++ b/bip-0174.mediawiki @@ -74,13 +74,11 @@ Where: : Magic bytes which are ASCII for psbt '''Why use 4 bytes for psbt?''' The transaction format needed to start with a 5 byte header which uniquely identifies it. The first bytes were chosen to be the ASCII for psbt because that stands for -Partially Signed Bitcoin Transaction. followed by a separator of 0xFF -'''Why Use a separator after the magic bytes?''' The separator +Partially Signed Bitcoin Transaction. followed by a separator of 0xFF'''Why Use a separator after the magic bytes?''' The separator is part of the 5 byte header for PSBT. This byte is a separator of 0xff because this will cause any non-PSBT unserializer to fail to properly unserialize the PSBT as a normal transaction. Likewise, since the 5 byte header is fixed, no transaction -in the non-PSBT format will be able to be unserialized by a PSBT unserializer.. This integer must be serialized -in most significant byte order. +in the non-PSBT format will be able to be unserialized by a PSBT unserializer.. This integer must be serialized in most significant byte order. The currently defined global types are as follows: -- cgit v1.2.3 From 0f95720639c743df2546730a5549eb7ead610529 Mon Sep 17 00:00:00 2001 From: Anthony Towns Date: Wed, 24 Mar 2021 20:35:24 +1000 Subject: BIP341: bip9 speedy trial parameters --- bip-0341.mediawiki | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/bip-0341.mediawiki b/bip-0341.mediawiki index 1e579e1..c464b59 100644 --- a/bip-0341.mediawiki +++ b/bip-0341.mediawiki @@ -298,6 +298,16 @@ This BIP is deployed concurrently with [[bip-0342.mediawiki|BIP342]]. For Bitcoin signet, these BIPs are always active. +For Bitcoin mainnet, these BIPs will be deployed by "version bits" with the name "taproot" and bit 2, using BIP9 modified to use a lower threshold, and with an additional ''min_activation_height'' parameter and changing the state transition logic for LOCKED_IN to the following: + + case LOCKED_IN: + if (block.nHeight < min_activation_height) { + return LOCKED_IN; + } + return ACTIVE; + +For Bitcoin mainnet, the BIP9 starttime is epoch timestamp 1619222400 (midnight 24 April 2021 UTC), BIP9 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). + == Backwards compatibility == As a soft fork, older software will continue to operate without modification. Non-upgraded nodes, however, will consider all SegWit version 1 witness programs as anyone-can-spend scripts. -- cgit v1.2.3 From d582d0bd3162ac7a3f6f1aae46daf7eeb24b201e Mon Sep 17 00:00:00 2001 From: Anthony Towns Date: Thu, 8 Apr 2021 18:30:51 +1000 Subject: BIP341: document simplified bip9 states --- bip-0341.mediawiki | 26 ++++++++++++++++++++++++-- 1 file changed, 24 insertions(+), 2 deletions(-) diff --git a/bip-0341.mediawiki b/bip-0341.mediawiki index c464b59..ec26250 100644 --- a/bip-0341.mediawiki +++ b/bip-0341.mediawiki @@ -298,7 +298,29 @@ This BIP is deployed concurrently with [[bip-0342.mediawiki|BIP342]]. For Bitcoin signet, these BIPs are always active. -For Bitcoin mainnet, these BIPs will be deployed by "version bits" with the name "taproot" and bit 2, using BIP9 modified to use a lower threshold, and with an additional ''min_activation_height'' parameter and changing the state transition logic for LOCKED_IN to the following: +For Bitcoin mainnet, 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: + + case DEFINED: + if (GetMedianTimePast(block.parent) >= starttime) { + return STARTED; + } + return DEFINED; + + case STARTED: + int count = 0; + walk = block; + for (i = 0; i < 2016; i++) { + walk = walk.parent; + if (walk.nVersion & 0xE0000000 == 0x20000000 && (walk.nVersion >> bit) & 1 == 1) { + count++; + } + } + if (count >= threshold) { + return LOCKED_IN; + } else if (GetMedianTimePast(block.parent) >= timeout) { + return FAILED; + } + return STARTED; case LOCKED_IN: if (block.nHeight < min_activation_height) { @@ -306,7 +328,7 @@ For Bitcoin mainnet, these BIPs will be deployed by "version bits" with the name } return ACTIVE; -For Bitcoin mainnet, the BIP9 starttime is epoch timestamp 1619222400 (midnight 24 April 2021 UTC), BIP9 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 (expected approximately 12 November 2021). == Backwards compatibility == As a soft fork, older software will continue to operate without modification. -- cgit v1.2.3 From 754b77a915007e96fca3b9440e7ddd4498ccae83 Mon Sep 17 00:00:00 2001 From: Andrew Chow Date: Thu, 8 Apr 2021 13:34:18 -0400 Subject: BIP 174: Add test vectors for additional unsigned tx serialization There are some edge cases with unsigned tx serialization, so this adds test vectors for them. Specifically, an unsigned tx with witness serialization is invalid, a transaction with 0 inputs and 0 outputs is valid, and a transaction with 0 inputs and non-0 outputs is valid. --- bip-0174.mediawiki | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/bip-0174.mediawiki b/bip-0174.mediawiki index 75fea0e..8551d3c 100644 --- a/bip-0174.mediawiki +++ b/bip-0174.mediawiki @@ -830,6 +830,10 @@ The following are invalid PSBTs: ** Bytes in Hex: 
70736274ff0100730200000001301ae986e516a1ec8ac5b4bc6573d32f83b465e23ad76167d68b38e730b4dbdb0000000000ffffffff02747b01000000000017a91403aa17ae882b5d0d54b25d63104e4ffece7b9ea2876043993b0000000017a914b921b1ba6f722e4bfa83b6557a3139986a42ec8387000000000001011f00ca9a3b00000000160014d2d94b64ae08587eefc8eeb187c601e939f9037c00010016001462e9e982fff34dd8239610316b090cd2a3b747cb000100220020876bad832f1d168015ed41232a9ea65a1815d9ef13c0ef8759f64b5b2b278a6521010025512103b7ce23a01c5b4bf00a642537cdfabb315b668332867478ef51309d06d57f8a8751ae00
** Base64 String: 
cHNidP8BAHMCAAAAATAa6YblFqHsisW0vGVz0y+DtGXiOtdhZ9aLOOcwtNvbAAAAAAD/////AnR7AQAAAAAAF6kUA6oXrogrXQ1Usl1jEE5P/s57nqKHYEOZOwAAAAAXqRS5IbG6b3IuS/qDtlV6MTmYakLsg4cAAAAAAAEBHwDKmjsAAAAAFgAU0tlLZK4IWH7vyO6xh8YB6Tn5A3wAAQAWABRi6emC//NN2COWEDFrCQzSo7dHywABACIAIIdrrYMvHRaAFe1BIyqeploYFdnvE8Dvh1n2S1srJ4plIQEAJVEhA7fOI6AcW0vwCmQlN836uzFbZoMyhnR471EwnQbVf4qHUa4A
+* Case: PSBT with unsigned tx serialized with witness serialization format +** Bytes in Hex: 
70736274ff01007802000000000101268171371edff285e937adeea4b37b78000c0566cbb3ad64641713ca42171bf60000000000feffffff02d3dff505000000001976a914d0c59903c5bac2868760e90fd521a4665aa7652088ac00e1f5050000000017a9143545e6e33b832c47050f24d3eeb93c9c03948bc78700b32e1300000100fda5010100000000010289a3c71eab4d20e0371bbba4cc698fa295c9463afa2e397f8533ccb62f9567e50100000017160014be18d152a9b012039daf3da7de4f53349eecb985ffffffff86f8aa43a71dff1448893a530a7237ef6b4608bbb2dd2d0171e63aec6a4890b40100000017160014fe3e9ef1a745e974d902c4355943abcb34bd5353ffffffff0200c2eb0b000000001976a91485cff1097fd9e008bb34af709c62197b38978a4888ac72fef84e2c00000017a914339725ba21efd62ac753a9bcd067d6c7a6a39d05870247304402202712be22e0270f394f568311dc7ca9a68970b8025fdd3b240229f07f8a5f3a240220018b38d7dcd314e734c9276bd6fb40f673325bc4baa144c800d2f2f02db2765c012103d2e15674941bad4a996372cb87e1856d3652606d98562fe39c5e9e7e413f210502483045022100d12b852d85dcd961d2f5f4ab660654df6eedcc794c0c33ce5cc309ffb5fce58d022067338a8e0e1725c197fb1a88af59f51e44e4255b20167c8684031c05d1f2592a01210223b72beef0965d10be0778efecd61fcac6f79a4ea169393380734464f84f2ab300000000000000
+** Base64 String: 
cHNidP8BAHgCAAAAAAEBJoFxNx7f8oXpN63upLN7eAAMBWbLs61kZBcTykIXG/YAAAAAAP7///8C09/1BQAAAAAZdqkU0MWZA8W6woaHYOkP1SGkZlqnZSCIrADh9QUAAAAAF6kUNUXm4zuDLEcFDyTT7rk8nAOUi8eHALMuEwAAAQD9pQEBAAAAAAECiaPHHqtNIOA3G7ukzGmPopXJRjr6Ljl/hTPMti+VZ+UBAAAAFxYAFL4Y0VKpsBIDna89p95PUzSe7LmF/////4b4qkOnHf8USIk6UwpyN+9rRgi7st0tAXHmOuxqSJC0AQAAABcWABT+Pp7xp0XpdNkCxDVZQ6vLNL1TU/////8CAMLrCwAAAAAZdqkUhc/xCX/Z4Ai7NK9wnGIZeziXikiIrHL++E4sAAAAF6kUM5cluiHv1irHU6m80GfWx6ajnQWHAkcwRAIgJxK+IuAnDzlPVoMR3HyppolwuAJf3TskAinwf4pfOiQCIAGLONfc0xTnNMkna9b7QPZzMlvEuqFEyADS8vAtsnZcASED0uFWdJQbrUqZY3LLh+GFbTZSYG2YVi/jnF6efkE/IQUCSDBFAiEA0SuFLYXc2WHS9fSrZgZU327tzHlMDDPOXMMJ/7X85Y0CIGczio4OFyXBl/saiK9Z9R5E5CVbIBZ8hoQDHAXR8lkqASECI7cr7vCWXRC+B3jv7NYfysb3mk6haTkzgHNEZPhPKrMAAAAAAAAA
+ The following are valid PSBTs: * Case: PSBT with one P2PKH input. Outputs are empty @@ -864,6 +868,14 @@ The following are valid PSBTs: ** Bytes in Hex: 
70736274ff01009d0100000002710ea76ab45c5cb6438e607e59cc037626981805ae9e0dfd9089012abb0be5350100000000ffffffff190994d6a8b3c8c82ccbcfb2fba4106aa06639b872a8d447465c0d42588d6d670000000000ffffffff0200e1f505000000001976a914b6bc2c0ee5655a843d79afedd0ccc3f7dd64340988ac605af405000000001600141188ef8e4ce0449eaac8fb141cbf5a1176e6a088000000004f010488b21e039e530cac800000003dbc8a5c9769f031b17e77fea1518603221a18fd18f2b9a54c6c8c1ac75cbc3502f230584b155d1c7f1cd45120a653c48d650b431b67c5b2c13f27d7142037c1691027569c503100008000000080000000800001011f00e1f5050000000016001433b982f91b28f160c920b4ab95e58ce50dda3a4a220203309680f33c7de38ea6a47cd4ecd66f1f5a49747c6ffb8808ed09039243e3ad5c47304402202d704ced830c56a909344bd742b6852dccd103e963bae92d38e75254d2bb424502202d86c437195df46c0ceda084f2a291c3da2d64070f76bf9b90b195e7ef28f77201220603309680f33c7de38ea6a47cd4ecd66f1f5a49747c6ffb8808ed09039243e3ad5c1827569c5031000080000000800000008000000000010000000001011f00e1f50500000000160014388fb944307eb77ef45197d0b0b245e079f011de220202c777161f73d0b7c72b9ee7bde650293d13f095bc7656ad1f525da5fd2e10b11047304402204cb1fb5f869c942e0e26100576125439179ae88dca8a9dc3ba08f7953988faa60220521f49ca791c27d70e273c9b14616985909361e25be274ea200d7e08827e514d01220602c777161f73d0b7c72b9ee7bde650293d13f095bc7656ad1f525da5fd2e10b1101827569c5031000080000000800000008000000000000000000000220202d20ca502ee289686d21815bd43a80637b0698e1fbcdbe4caed445f6c1a0a90ef1827569c50310000800000008000000080000000000400000000
** Base64 String: 
cHNidP8BAJ0BAAAAAnEOp2q0XFy2Q45gflnMA3YmmBgFrp4N/ZCJASq7C+U1AQAAAAD/////GQmU1qizyMgsy8+y+6QQaqBmObhyqNRHRlwNQliNbWcAAAAAAP////8CAOH1BQAAAAAZdqkUtrwsDuVlWoQ9ea/t0MzD991kNAmIrGBa9AUAAAAAFgAUEYjvjkzgRJ6qyPsUHL9aEXbmoIgAAAAATwEEiLIeA55TDKyAAAAAPbyKXJdp8DGxfnf+oVGGAyIaGP0Y8rmlTGyMGsdcvDUC8jBYSxVdHH8c1FEgplPEjWULQxtnxbLBPyfXFCA3wWkQJ1acUDEAAIAAAACAAAAAgAABAR8A4fUFAAAAABYAFDO5gvkbKPFgySC0q5XljOUN2jpKIgIDMJaA8zx9446mpHzU7NZvH1pJdHxv+4gI7QkDkkPjrVxHMEQCIC1wTO2DDFapCTRL10K2hS3M0QPpY7rpLTjnUlTSu0JFAiAthsQ3GV30bAztoITyopHD2i1kBw92v5uQsZXn7yj3cgEiBgMwloDzPH3jjqakfNTs1m8fWkl0fG/7iAjtCQOSQ+OtXBgnVpxQMQAAgAAAAIAAAACAAAAAAAEAAAAAAQEfAOH1BQAAAAAWABQ4j7lEMH63fvRRl9CwskXgefAR3iICAsd3Fh9z0LfHK57nveZQKT0T8JW8dlatH1Jdpf0uELEQRzBEAiBMsftfhpyULg4mEAV2ElQ5F5rojcqKncO6CPeVOYj6pgIgUh9JynkcJ9cOJzybFGFphZCTYeJb4nTqIA1+CIJ+UU0BIgYCx3cWH3PQt8crnue95lApPRPwlbx2Vq0fUl2l/S4QsRAYJ1acUDEAAIAAAACAAAAAgAAAAAAAAAAAAAAiAgLSDKUC7iiWhtIYFb1DqAY3sGmOH7zb5MrtRF9sGgqQ7xgnVpxQMQAAgAAAAIAAAACAAAAAAAQAAAAA
+* Case: PSBT with global unsigned tx that has 0 inputs and 0 outputs +** Bytes in Hex: 
70736274ff01000a0000000000000000000000
+** Base64 String: 
cHNidP8BAAoAAAAAAAAAAAAAAA==
+ +* Case: PSBT with 0 inputs +** Bytes in Hex: 
70736274ff01004c020000000002d3dff505000000001976a914d0c59903c5bac2868760e90fd521a4665aa7652088ac00e1f5050000000017a9143545e6e33b832c47050f24d3eeb93c9c03948bc787b32e1300000000
+** Base64 String: 
cHNidP8BAEwCAAAAAALT3/UFAAAAABl2qRTQxZkDxbrChodg6Q/VIaRmWqdlIIisAOH1BQAAAAAXqRQ1RebjO4MsRwUPJNPuuTycA5SLx4ezLhMAAAAA
+ Fails Signer checks * Case: A Witness UTXO is provided for a non-witness input -- cgit v1.2.3 From ce5f89fe0ddd99a00bcd1457df407cccd60a9336 Mon Sep 17 00:00:00 2001 From: Anthony Towns Date: Thu, 8 Apr 2021 18:31:04 +1000 Subject: BIP341: add testnet3 parameters --- bip-0341.mediawiki | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/bip-0341.mediawiki b/bip-0341.mediawiki index ec26250..f682d96 100644 --- a/bip-0341.mediawiki +++ b/bip-0341.mediawiki @@ -298,7 +298,7 @@ This BIP is deployed concurrently with [[bip-0342.mediawiki|BIP342]]. For Bitcoin signet, these BIPs are always active. -For Bitcoin mainnet, 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 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: case DEFINED: if (GetMedianTimePast(block.parent) >= starttime) { @@ -330,6 +330,8 @@ For Bitcoin mainnet, these BIPs will be deployed by "version bits" with the name 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 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. + == Backwards compatibility == As a soft fork, older software will continue to operate without modification. Non-upgraded nodes, however, will consider all SegWit version 1 witness programs as anyone-can-spend scripts. -- cgit v1.2.3 From cda85c75c176ebeba4152a238998b4c54aa74e89 Mon Sep 17 00:00:00 2001 From: fresheneesz Date: Mon, 12 Apr 2021 08:26:18 -1000 Subject: Minor: linking BIPs in BIP9 --- bip-0009.mediawiki | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/bip-0009.mediawiki b/bip-0009.mediawiki index f90919a..b2d6741 100644 --- a/bip-0009.mediawiki +++ b/bip-0009.mediawiki @@ -19,9 +19,9 @@ This document specifies a proposed change to the semantics of the 'version' fiel ==Motivation== -BIP 34 introduced a mechanism for doing soft-forking changes without a predefined flag timestamp (or flag block height), instead relying on measuring miner support indicated by a higher version number in block headers. As it relies on comparing version numbers as integers however, it only supports one single change being rolled out at once, requiring coordination between proposals, and does not allow for permanent rejection: as long as one soft fork is not fully rolled out, no future one can be scheduled. +[https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki BIP 34] introduced a mechanism for doing soft-forking changes without a predefined flag timestamp (or flag block height), instead relying on measuring miner support indicated by a higher version number in block headers. As it relies on comparing version numbers as integers however, it only supports one single change being rolled out at once, requiring coordination between proposals, and does not allow for permanent rejection: as long as one soft fork is not fully rolled out, no future one can be scheduled. -In addition, BIP 34 made the integer comparison (nVersion >= 2) a consensus rule after its 95% threshold was reached, removing 231+2 values from the set of valid version numbers (all negative numbers, as nVersion is interpreted as a signed integer, as well as 0 and 1). This indicates another downside this approach: every upgrade permanently restricts the set of allowed nVersion field values. This approach was later reused in BIP 66 and BIP 65, which further removed nVersions 2 and 3 as valid options. As will be shown further, this is unnecessary. +In addition, BIP 34 made the integer comparison (nVersion >= 2) a consensus rule after its 95% threshold was reached, removing 231+2 values from the set of valid version numbers (all negative numbers, as nVersion is interpreted as a signed integer, as well as 0 and 1). This indicates another downside this approach: every upgrade permanently restricts the set of allowed nVersion field values. This approach was later reused in [https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki BIP 66] and [https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP 65], which further removed nVersions 2 and 3 as valid options. As will be shown further, this is unnecessary. ==Specification== @@ -195,7 +195,7 @@ If versionbits is being used, "version" MUST be within the versionbits range of Miners MAY clear or set bits in the block version WITHOUT any special "mutable" key, provided they are listed among the template's "vbavailable" and (when clearing is desired) NOT included as a bit in "vbrequired". Softfork deployment names listed in "rules" or as keys in "vbavailable" may be prefixed by a '!' character. -Without this prefix, GBT clients may assume the rule will not impact usage of the template as-is; typical examples of this would be when previously valid transactions cease to be valid, such as BIPs 16, 65, 66, 68, 112, and 113. +Without this prefix, GBT clients may assume the rule will not impact usage of the template as-is; typical examples of this would be when previously valid transactions cease to be valid, such as BIPs [https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki 16], [https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki 65], [https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki 66], [https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki 68], [https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki 112], and [https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki 113]. If a client does not understand a rule without the prefix, it may use it unmodified for mining. On the other hand, when this prefix is used, it indicates a more subtle change to the block structure or generation transaction; examples of this would be BIP 34 (because it modifies coinbase construction) and 141 (since it modifies the txid hashing and adds a commitment to the generation transaction). A client that does not understand a rule prefixed by '!' must not attempt to process the template, and must not attempt to use it for mining even unmodified. -- cgit v1.2.3 From 43b5f171dcf2b3cd8a2f1b0a71f0dfe31946f46a Mon Sep 17 00:00:00 2001 From: Jonas Nick Date: Tue, 13 Apr 2021 14:52:44 +0000 Subject: BIP 341/342: Add link to Bitcoin Core test vectors Also remove mention of non-existing examples. --- bip-0341.mediawiki | 4 +--- bip-0342.mediawiki | 2 ++ 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/bip-0341.mediawiki b/bip-0341.mediawiki index 0f8d32a..a1c45cc 100644 --- a/bip-0341.mediawiki +++ b/bip-0341.mediawiki @@ -284,9 +284,7 @@ The reason for this is to increase leaf entropy and prevent an observer from lea == Test vectors == -Examples with creation transaction and spending transaction pairs, valid and invalid. - -Examples of preimage for sighashing for each of the sighash modes. +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]. == Rationale == diff --git a/bip-0342.mediawiki b/bip-0342.mediawiki index 7e00a2e..fa27598 100644 --- a/bip-0342.mediawiki +++ b/bip-0342.mediawiki @@ -135,6 +135,8 @@ In addition to changing the semantics of a number of opcodes, there are also som ==Examples== +The Taproot ([[bip-0341.mediawiki|BIP341]]) test vectors also contain examples for Tapscript execution. + ==Acknowledgements== This document is the result of many discussions and contains contributions by a number of people. The authors wish to thank all those who provided valuable feedback and reviews, including the participants of the [https://github.com/ajtowns/taproot-review structured reviews]. -- cgit v1.2.3 From 93d1b1528592ca129109b4630c17fa5372e4048a Mon Sep 17 00:00:00 2001 From: Anthony Towns Date: Tue, 13 Apr 2021 10:45:02 +1000 Subject: BIP341: add brackets to avoid ambiguity due to precendence rules around bipwise ops --- bip-0341.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0341.mediawiki b/bip-0341.mediawiki index f682d96..5450a08 100644 --- a/bip-0341.mediawiki +++ b/bip-0341.mediawiki @@ -311,7 +311,7 @@ For Bitcoin mainnet and testnet3, these BIPs will be deployed by "version bits" walk = block; for (i = 0; i < 2016; i++) { walk = walk.parent; - if (walk.nVersion & 0xE0000000 == 0x20000000 && (walk.nVersion >> bit) & 1 == 1) { + if ((walk.nVersion & 0xE0000000) == 0x20000000 && ((walk.nVersion >> bit) & 1) == 1) { count++; } } -- cgit v1.2.3 From 593324754f0494070bb4a6a472e02080af5c3c0e Mon Sep 17 00:00:00 2001 From: fresheneesz Date: Wed, 14 Apr 2021 08:53:21 -1000 Subject: Changing BIP links in BIP9 to relative urls. --- bip-0009.mediawiki | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/bip-0009.mediawiki b/bip-0009.mediawiki index b2d6741..c9fcd6f 100644 --- a/bip-0009.mediawiki +++ b/bip-0009.mediawiki @@ -19,9 +19,9 @@ This document specifies a proposed change to the semantics of the 'version' fiel ==Motivation== -[https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki BIP 34] introduced a mechanism for doing soft-forking changes without a predefined flag timestamp (or flag block height), instead relying on measuring miner support indicated by a higher version number in block headers. As it relies on comparing version numbers as integers however, it only supports one single change being rolled out at once, requiring coordination between proposals, and does not allow for permanent rejection: as long as one soft fork is not fully rolled out, no future one can be scheduled. +[[bip-0034.mediawiki|BIP 34]] introduced a mechanism for doing soft-forking changes without a predefined flag timestamp (or flag block height), instead relying on measuring miner support indicated by a higher version number in block headers. As it relies on comparing version numbers as integers however, it only supports one single change being rolled out at once, requiring coordination between proposals, and does not allow for permanent rejection: as long as one soft fork is not fully rolled out, no future one can be scheduled. -In addition, BIP 34 made the integer comparison (nVersion >= 2) a consensus rule after its 95% threshold was reached, removing 231+2 values from the set of valid version numbers (all negative numbers, as nVersion is interpreted as a signed integer, as well as 0 and 1). This indicates another downside this approach: every upgrade permanently restricts the set of allowed nVersion field values. This approach was later reused in [https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki BIP 66] and [https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP 65], which further removed nVersions 2 and 3 as valid options. As will be shown further, this is unnecessary. +In addition, BIP 34 made the integer comparison (nVersion >= 2) a consensus rule after its 95% threshold was reached, removing 231+2 values from the set of valid version numbers (all negative numbers, as nVersion is interpreted as a signed integer, as well as 0 and 1). This indicates another downside this approach: every upgrade permanently restricts the set of allowed nVersion field values. This approach was later reused in [[bip-0066.mediawiki|BIP 66]] and [[bip-0065.mediawiki|BIP 65]], which further removed nVersions 2 and 3 as valid options. As will be shown further, this is unnecessary. ==Specification== @@ -195,7 +195,7 @@ If versionbits is being used, "version" MUST be within the versionbits range of Miners MAY clear or set bits in the block version WITHOUT any special "mutable" key, provided they are listed among the template's "vbavailable" and (when clearing is desired) NOT included as a bit in "vbrequired". Softfork deployment names listed in "rules" or as keys in "vbavailable" may be prefixed by a '!' character. -Without this prefix, GBT clients may assume the rule will not impact usage of the template as-is; typical examples of this would be when previously valid transactions cease to be valid, such as BIPs [https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki 16], [https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki 65], [https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki 66], [https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki 68], [https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki 112], and [https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki 113]. +Without this prefix, GBT clients may assume the rule will not impact usage of the template as-is; typical examples of this would be when previously valid transactions cease to be valid, such as BIPs [[bip-0016.mediawiki|16]], [[bip-0065.mediawiki|65]], [[bip-0066.mediawiki|66]], [[bip-0068.mediawiki|68]], [[bip-0112.mediawiki|112]], and [[bip-0113.mediawiki|113]]. If a client does not understand a rule without the prefix, it may use it unmodified for mining. On the other hand, when this prefix is used, it indicates a more subtle change to the block structure or generation transaction; examples of this would be BIP 34 (because it modifies coinbase construction) and 141 (since it modifies the txid hashing and adds a commitment to the generation transaction). A client that does not understand a rule prefixed by '!' must not attempt to process the template, and must not attempt to use it for mining even unmodified. -- cgit v1.2.3