[ { "instruction": "How would you explain 
 to someone who knows Bitcoin basics?",
    "input": "",
    "output": "BIP: 42\n  Layer: Consensus (soft fork)\n  Title: A finite monetary supply for Bitcoin\n  Authors: Pieter Wuille \n  Comments-Summary: Unanimously Recommended for implementation\n  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0042\n  Status: Deployed\n  Type: Specification\n  Assigned: 2014-04-01\n  License: PD\n
\n\n==Abstract==\n\nAlthough it is widely believed that Satoshi was an inflation-hating goldbug he never said this, and in fact programmed Bitcoin's money supply to grow indefinitely, forever. He modeled the monetary supply as 4 gold mines being discovered per mibillennium (1024 years), with equal intervals between them, each one being depleted over the course of 140 years.\n\nThis poses obvious problems, however. Prominent among them is the discussion on what to call 1 billion bitcoin, which symbol color to use for it, and when wallet clients should switch to it by default.\n\nTo combat this, this document proposes a controversial change: making Bitcoin's monetary supply finite.\n\n==Details==\n\nAs is well known, Satoshi was a master programmer whose knowledge of C++ was surpassed only by his knowledge of Japanese culture. The code below:\n\n int64_t nSubsidy = 50 * COIN;\n // Subsidy is cut in half every 210,000 blocks\n // which will occur approximately every 4 years.\n nSubsidy >>= (nHeight / 210000);\n\nis carefully written to rely on undefined behaviour in the C++ specification - perhaps so it can be hardware accelerated in future.\n\nThe block number is divided by 210000 (the \"apparent\" subsidy halving interval in blocks), and the result is used as input for a binary shift, applied to the original payout (50 BTC), expressed in base units. Thanks to the new-goldmine interval being exactly 64 times the halving interval, and 64 being the size in bits of the currency datatype, the cycle repeats itself every 64 halvings on all currently supported platforms.\n\nDespite the nice showoff of underhanded programming skills - we want Bitcoin to be well-specified. Otherwise, we're clearly in for a bumpy ride:\n\n\n\nNote that several other programming languages do not exhibit this behaviour, making new implementations likely to be slower and generally more bogus than Bitcoin Core. For example, Python unexpectedly returns 0 when shifting an integer beyond its size.\n\n==Other solutions==\n\n===Floating-point approximation===\n\nAn obvious solution would be to reimplement the shape of the subsidy curve using floating-point approximations, such as simulated annealing or quantitative easing, which have already proven their worth in consensus systems. Unfortunately, since the financial crisis everyone considers numbers with decimal points in them fishy, and integers are not well supported by Javascript.\n\n===Truncation===\n\nAn alternative solution would be to represent the total number of bitcoins as a string:\n\n \"21000000000000000000000\"\n\nand then use string manipulation to remove the rightmost zero every 4 years, give or take a leap-year:\n\n strSubsidy = strSubsidy.substr(0, strSubsidy.size() - 2);\n\nThis style relies less heavily on clever C++ and is more familiar to the Core Dev Team who are primarily PHP programmers.\n\n==Proposal==\n\nInstead, how about we stop thinking about long term issues when we'll all be dead (barring near lightspeed travel, cryogenic revival, or other technology— like cryptocurrency— which only exists in science fiction).\n\nA softfork (see BIP16, BIP34, BIP62) will take place on april 1st 2214, permanently setting the subsidy to zero. The result of this will be that the total currency supply will be limited to 42 halfmillion (including the genesis coinbase output, which is not actually spendable).\n\n==Implementation==\n\nAn implementation for the reference client can be found on https://github.com/bitcoin/bitcoin/pull/3842 .\n\n==Compatibility==\n\nGiven the moderate time frame over which this change is to be implemented, we expect all miners to choose to screw themselves and deploy this change before 2214.\n\nIf they don't, and a minority remains on the old code base, a fork may occur. Essentially, they'll be mining fool's gold after that time.\n\n==Acknowledgements==\n\nThanks to Gregory Maxwell for proposing this solution, and to Mike Hearn for insights into web development. Also thanks to \"ditto-b\" on github to implement a prototype ahead of time.\n\n==Copyright==\n\nThis document is placed in the public domain.", "category": "bips" }, { "instruction": "I'm trying to understand 
 - can you walk me through it?",
    "input": "",
    "output": "BIP: 143\n  Layer: Consensus (soft fork)\n  Title: Transaction Signature Verification for Version 0 Witness Program\n  Authors: Johnson Lau \n           Pieter Wuille \n  Status: Deployed\n  Type: Specification\n  Assigned: 2016-01-03\n  License: PD\n
\n\n== Abstract ==\nThis proposal defines a new transaction digest algorithm for signature verification in version 0 witness program, in order to minimize redundant data hashing in verification, and to cover the input value by the signature.\n\n== Motivation ==\nThere are 4 ECDSA signature verification codes in the original Bitcoin script system: CHECKSIG, CHECKSIGVERIFY, CHECKMULTISIG, CHECKMULTISIGVERIFY (“sigops”). According to the sighash type (ALL, NONE, SINGLE, ANYONECANPAY), a transaction digest is generated with a double SHA256 of a serialized subset of the transaction, and the signature is verified against this digest with a given public key. The detailed procedure is described in a Bitcoin Wiki article. [https://en.bitcoin.it/wiki/OP_CHECKSIG]\n\nUnfortunately, there are at least 2 weaknesses in the original SignatureHash transaction digest algorithm:\n\n* For the verification of each signature, the amount of data hashing is proportional to the size of the transaction. Therefore, data hashing grows in O(n2) as the number of sigops in a transaction increases. While a 1 MB block would normally take 2 seconds to verify with an average computer in 2015, a 1MB transaction with 5569 sigops may take 25 seconds to verify. This could be fixed by optimizing the digest algorithm by introducing some reusable “midstate”, so the time complexity becomes O(n). [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-2292 CVE-2013-2292][https://bitcointalk.org/?topic=140078 New Bitcoin vulnerability: A transaction that takes at least 3 minutes to verify][http://rusty.ozlabs.org/?p=522 The Megatransaction: Why Does It Take 25 Seconds?]\n* The algorithm does not involve the amount of Bitcoin being spent by the input. This is usually not a problem for online network nodes as they could request for the specified transaction to acquire the output value. For an offline transaction signing device (\"cold wallet\"), however, the unknowing of input amount makes it impossible to calculate the exact amount being spent and the transaction fee. To cope with this problem a cold wallet must also acquire the full transaction being spent, which could be a big obstacle in the implementation of lightweight, air-gapped wallet. By including the input value of part of the transaction digest, a cold wallet may safely sign a transaction by learning the value from an untrusted source. In the case that a wrong value is provided and signed, the signature would be invalid and no funding might be lost. [https://bitcointalk.org/index.php?topic=181734.0 SIGHASH_WITHINPUTVALUE: Super-lightweight HW wallets and offline data]\n\nDeploying the aforementioned fixes in the original script system is not a simple task. That would be either a hardfork, or a softfork for new sigops without the ability to remove or insert stack items. However, the introduction of segregated witness softfork offers an opportunity to define a different set of script semantics without disrupting the original system, as the unupgraded nodes would always consider such a transaction output is spendable by arbitrary signature or no signature at all. [https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki BIP141: Segregated Witness (Consensus layer)]\n\n== Specification ==\nA new transaction digest algorithm is defined, but only applicable to sigops in version 0 witness program:\n Double SHA256 of the serialization of:\n 1. nVersion of the transaction (4-byte little endian)\n 2. hashPrevouts (32-byte hash)\n 3. hashSequence (32-byte hash)\n 4. outpoint (32-byte hash + 4-byte little endian)\n 5. scriptCode of the input (serialized as scripts inside CTxOuts)\n 6. value of the output spent by this input (8-byte little endian)\n 7. nSequence of the input (4-byte little endian)\n 8. hashOutputs (32-byte hash)\n 9. nLocktime of the transaction (4-byte little endian)\n 10. sighash type of the signature (4-byte little endian)\n\nSemantics of the original sighash types remain unchanged, except the following:", "category": "bips" }, { "instruction": "Hey, I need to set up Bitcoin Operations Guide - what's the command line way to do that?", "input": "", "output": "# OP_CODESEPARATOR(s) after the last executed OP_CODESEPARATOR are not removed from the scriptCode (the last executed OP_CODESEPARATOR and any script before it are always removed);", "category": "bips" }, { "instruction": "What's the deal with SINGLE does not commit to the input index. When ANYONECANPAY is not set, the semantics are unchanged since hashPrevouts and outpoint together implicitly commit to the input index. When SINGLE is used with ANYONECANPAY, omission of the index commitment allows permutation of the input-output pairs, as long as each pair is located at an equivalent index. in Bitcoin? Explain it like I'm a friend.", "input": "", "output": "The items 1, 4, 7, 9, 10 have the same meaning as the original algorithm. \n\nThe item 5:\n*For P2WPKH witness program, the scriptCode is 0x1976a914{20-byte-pubkey-hash}88ac.\n*For P2WSH witness program,\n**if the witnessScript does not contain any OP_CODESEPARATOR, the scriptCode is the witnessScript serialized as scripts inside CTxOut.\n**if the witnessScript contains any OP_CODESEPARATOR, the scriptCode is the witnessScript but removing everything up to and including the last executed OP_CODESEPARATOR before the signature checking opcode being executed, serialized as scripts inside CTxOut. (The exact semantics is demonstrated in the examples below)\n\nThe item 6 is a 8-byte value of the amount of bitcoin spent in this input.\n\nhashPrevouts:\n*If the ANYONECANPAY flag is not set, hashPrevouts is the double SHA256 of the serialization of all input outpoints;\n*Otherwise, hashPrevouts is a uint256 of 0x0000......0000.\n\nhashSequence:\n*If none of the ANYONECANPAY, SINGLE, NONE sighash type is set, hashSequence is the double SHA256 of the serialization of nSequence of all inputs;\n*Otherwise, hashSequence is a uint256 of 0x0000......0000.\n\nhashOutputs:\n*If the sighash type is neither SINGLE nor NONE, hashOutputs is the double SHA256 of the serialization of all output amount (8-byte little endian) with scriptPubKey (serialized as scripts inside CTxOuts);\n*If sighash type is SINGLE and the input index is smaller than the number of outputs, hashOutputs is the double SHA256 of the output amount with scriptPubKey of the same index as the input;\n*Otherwise, hashOutputs is a uint256 of 0x0000......0000.In the original algorithm, a uint256 of 0x0000......0001 is committed if the input index for a SINGLE signature is greater than or equal to the number of outputs. In this BIP a 0x0000......0000 is committed, without changing the semantics.\n\nThe hashPrevouts, hashSequence, and hashOutputs calculated in an earlier verification may be reused in other inputs of the same transaction, so that the time complexity of the whole hashing process reduces from O(n2) to O(n).\n\nRefer to the reference implementation, reproduced below, for the precise algorithm:\n\n\n uint256 hashPrevouts;\n uint256 hashSequence;\n uint256 hashOutputs;\n\n if (!(nHashType & SIGHASH_ANYONECANPAY)) {\n CHashWriter ss(SER_GETHASH, 0);\n for (unsigned int n = 0; n < txTo.vin.size(); n++) {\n ss << txTo.vin[n].prevout;\n }\n hashPrevouts = ss.GetHash();\n }\n\n if (!(nHashType & SIGHASH_ANYONECANPAY) && (nHashType & 0x1f) != SIGHASH_SINGLE && (nHashType & 0x1f) != SIGHASH_NONE) {\n CHashWriter ss(SER_GETHASH, 0);\n for (unsigned int n = 0; n < txTo.vin.size(); n++) {\n ss << txTo.vin[n].nSequence;\n }\n hashSequence = ss.GetHash();\n }\n\n if ((nHashType & 0x1f) != SIGHASH_SINGLE && (nHashType & 0x1f) != SIGHASH_NONE) {\n CHashWriter ss(SER_GETHASH, 0);\n for (unsigned int n = 0; n < txTo.vout.size(); n++) {\n ss << txTo.vout[n];\n }\n hashOutputs = ss.GetHash();\n } else if ((nHashType & 0x1f) == SIGHASH_SINGLE && nIn < txTo.vout.size()) {\n CHashWriter ss(SER_GETHASH, 0);\n ss << txTo.vout[nIn];\n hashOutputs = ss.GetHash();\n }\n\n CHashWriter ss(SER_GETHASH, 0);\n // Version\n ss << txTo.nVersion;\n // Input prevouts/nSequence (none/all, depending on flags)\n ss << hashPrevouts;\n ss << hashSequence;\n // The input being signed (replacing the scriptSig with scriptCode + amount)\n // The prevout may already be contained in hashPrevout, and the nSequence\n // may already be contained in hashSequence.\n ss << txTo.vin[nIn].prevout;\n ss << static_cast(scriptCode);\n ss << amount;\n ss << txTo.vin[nIn].nSequence;\n // Outputs (none/one/all, depending on flags)\n ss << hashOutputs;\n // Locktime\n ss << txTo.nLockTime;\n // Sighash type\n ss << nHashType;\n\n return ss.GetHash();\n\n\n== Restrictions on public key type ==\nAs a default policy, only compressed public keys are accepted in P2WPKH and P2WSH. Each public key passed to a sigop inside version 0 witness program must be a compressed key: the first byte MUST be either 0x02 or 0x03, and the size MUST be 33 bytes. Transactions that break this rule will not be relayed or mined by default.\n\nSince this policy is preparation for a future softfork proposal, to avoid potential future funds loss, users MUST NOT use uncompressed keys in version 0 witness programs.\n\n== Example ==\n\nTo ensure consistency in consensus-critical behaviour, developers should test their implementations against all the tests below. More tests related to this proposal could be found under https://github.com/bitcoin/bitcoin/tree/master/src/test/data .\n\n=== Native P2WPKH ===\n\n The following is an unsigned transaction:\n 0100000002fff7f7881a8099afa6940d42d1e7f6362bec38171ea3edf433541db4e4ad969f0000000000eeffffffef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a0100000000ffffffff02202cb206000000001976a9148280b37df378db99f66f85c95a783a76ac7a6d5988ac9093510d000000001976a9143bde42dbee7e4dbe6a21b2d50ce2f0167faa815988ac11000000\n\n nVersion: 01000000\n txin: 02 fff7f7881a8099afa6940d42d1e7f6362bec38171ea3edf433541db4e4ad969f 00000000 00 eeffffff\n ef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a 01000000 00 ffffffff\n txout: 02 202cb20600000000 1976a9148280b37df378db99f66f85c95a783a76ac7a6d5988ac\n 9093510d00000000 1976a9143bde42dbee7e4dbe6a21b2d50ce2f0167faa815988ac\n nLockTime: 11000000\n\n The first input comes from an ordinary P2PK:\n scriptPubKey : 2103c9f4836b9a4f77fc0d81f7bcb01b7f1b35916864b9476c241ce9fc198bd25432ac value: 6.25\n private key : bbc27228ddcb9209d7fd6f36b02f7dfa6252af40bb2f1cbc7a557da8027ff866\n\n The second input comes from a P2WPKH witness program:\n scriptPubKey : 00141d0f172a0ecb48aee1be1f2687d2963ae33f71a1, value: 6\n private key : 619c335025c7f4012e556c2a58b2506e30b8511b53ade95ea316fd8c3286feb9\n public key : 025476c2e83188368da1ff3e292e7acafcdb3566bb0ad253f62fc70f07aeee6357\n\n To sign it with a nHashType of 1 (SIGHASH_ALL):\n\n hashPrevouts:\n dSHA256(fff7f7881a8099afa6940d42d1e7f6362bec38171ea3edf433541db4e4ad969f00000000ef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a01000000)\n = 96b827c8483d4e9b96712b6713a7b68d6e8003a781feba36c31143470b4efd37\n\n hashSequence:\n dSHA256(eeffffffffffffff)\n = 52b0a642eea2fb7ae638c36f6252b6750293dbe574a806984b8e4d8548339a3b\n\n hashOutputs:\n dSHA256(202cb206000000001976a9148280b37df378db99f66f85c95a783a76ac7a6d5988ac9093510d000000001976a9143bde42dbee7e4dbe6a21b2d50ce2f0167faa815988ac)\n = 863ef3e1a92afbfdb97f31ad0fc7683ee943e9abcf2501590ff8f6551f47e5e5\n\n hash preimage: 0100000096b827c8483d4e9b96712b6713a7b68d6e8003a781feba36c31143470b4efd3752b0a642eea2fb7ae638c36f6252b6750293dbe574a806984b8e4d8548339a3bef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a010000001976a9141d0f172a0ecb48aee1be1f2687d2963ae33f71a188ac0046c32300000000ffffffff863ef3e1a92afbfdb97f31ad0fc7683ee943e9abcf2501590ff8f6551f47e5e51100000001000000\n\n nVersion: 01000000\n hashPrevouts: 96b827c8483d4e9b96712b6713a7b68d6e8003a781feba36c31143470b4efd37\n hashSequence: 52b0a642eea2fb7ae638c36f6252b6750293dbe574a806984b8e4d8548339a3b\n outpoint: ef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a01000000\n scriptCode: 1976a9141d0f172a0ecb48aee1be1f2687d2963ae33f71a188ac\n amount: 0046c32300000000\n nSequence: ffffffff\n hashOutputs: 863ef3e1a92afbfdb97f31ad0fc7683ee943e9abcf2501590ff8f6551f47e5e5\n nLockTime: 11000000\n nHashType: 01000000\n\n sigHash: c37af31116d1b27caf68aae9e3ac82f1477929014d5b917657d0eb49478cb670\n signature: 304402203609e17b84f6a7d30c80bfa610b5b4542f32a8a0d5447a12fb1366d7f01cc44a0220573a954c4518331561406f90300e8f3358f51928d43c212a8caed02de67eebee01\n\n The serialized signed transaction is: 01000000000102fff7f7881a8099afa6940d42d1e7f6362bec38171ea3edf433541db4e4ad969f00000000494830450221008b9d1dc26ba6a9cb62127b02742fa9d754cd3bebf337f7a55d114c8e5cdd30be022040529b194ba3f9281a99f2b1c0a19c0489bc22ede944ccf4ecbab4cc618ef3ed01eeffffffef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a0100000000ffffffff02202cb206000000001976a9148280b37df378db99f66f85c95a783a76ac7a6d5988ac9093510d000000001976a9143bde42dbee7e4dbe6a21b2d50ce2f0167faa815988ac000247304402203609e17b84f6a7d30c80bfa610b5b4542f32a8a0d5447a12fb1366d7f01cc44a0220573a954c4518331561406f90300e8f3358f51928d43c212a8caed02de67eebee0121025476c2e83188368da1ff3e292e7acafcdb3566bb0ad253f62fc70f07aeee635711000000\n\n nVersion: 01000000\n marker: 00\n flag: 01\n txin: 02 fff7f7881a8099afa6940d42d1e7f6362bec38171ea3edf433541db4e4ad969f 00000000 494830450221008b9d1dc26ba6a9cb62127b02742fa9d754cd3bebf337f7a55d114c8e5cdd30be022040529b194ba3f9281a99f2b1c0a19c0489bc22ede944ccf4ecbab4cc618ef3ed01 eeffffff\n ef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a 01000000 00 ffffffff\n txout: 02 202cb20600000000 1976a9148280b37df378db99f66f85c95a783a76ac7a6d5988ac\n 9093510d00000000 1976a9143bde42dbee7e4dbe6a21b2d50ce2f0167faa815988ac\n witness 00\n 02 47304402203609e17b84f6a7d30c80bfa610b5b4542f32a8a0d5447a12fb1366d7f01cc44a0220573a954c4518331561406f90300e8f3358f51928d43c212a8caed02de67eebee01 21025476c2e83188368da1ff3e292e7acafcdb3566bb0ad253f62fc70f07aeee6357\n nLockTime: 11000000\n\n=== P2SH-P2WPKH ===\n\n\n The following is an unsigned transaction: 0100000001db6b1b20aa0fd7b23880be2ecbd4a98130974cf4748fb66092ac4d3ceb1a54770100000000feffffff02b8b4eb0b000000001976a914a457b684d7f0d539a46a45bbc043f35b59d0d96388ac0008af2f000000001976a914fd270b1ee6abcaea97fea7ad0402e8bd8ad6d77c88ac92040000\n\n nVersion: 01000000\n txin: 01 db6b1b20aa0fd7b23880be2ecbd4a98130974cf4748fb66092ac4d3ceb1a5477 01000000 00 feffffff\n txout: 02 b8b4eb0b00000000 1976a914a457b684d7f0d539a46a45bbc043f35b59d0d96388ac\n 0008af2f00000000 1976a914fd270b1ee6abcaea97fea7ad0402e8bd8ad6d77c88ac\n nLockTime: 92040000\n\n The input comes from a P2SH-P2WPKH witness program:\n scriptPubKey : a9144733f37cf4db86fbc2efed2500b4f4e49f31202387, value: 10\n redeemScript : 001479091972186c449eb1ded22b78e40d009bdf0089\n private key : eb696a065ef48a2192da5b28b694f87544b30fae8327c4510137a922f32c6dcf\n public key : 03ad1d8e89212f0b92c74d23bb710c00662ad1470198ac48c43f7d6f93a2a26873\n\n To sign it with a nHashType of 1 (SIGHASH_ALL):\n\n hashPrevouts:\n dSHA256(db6b1b20aa0fd7b23880be2ecbd4a98130974cf4748fb66092ac4d3ceb1a547701000000)\n = b0287b4a252ac05af83d2dcef00ba313af78a3e9c329afa216eb3aa2a7b4613a\n\n hashSequence:\n dSHA256(feffffff)\n = 18606b350cd8bf565266bc352f0caddcf01e8fa789dd8a15386327cf8cabe198\n\n hashOutputs:\n dSHA256(b8b4eb0b000000001976a914a457b684d7f0d539a46a45bbc043f35b59d0d96388ac0008af2f000000001976a914fd270b1ee6abcaea97fea7ad0402e8bd8ad6d77c88ac)\n = de984f44532e2173ca0d64314fcefe6d30da6f8cf27bafa706da61df8a226c83\n\n hash preimage: 01000000b0287b4a252ac05af83d2dcef00ba313af78a3e9c329afa216eb3aa2a7b4613a18606b350cd8bf565266bc352f0caddcf01e8fa789dd8a15386327cf8cabe198db6b1b20aa0fd7b23880be2ecbd4a98130974cf4748fb66092ac4d3ceb1a5477010000001976a91479091972186c449eb1ded22b78e40d009bdf008988ac00ca9a3b00000000feffffffde984f44532e2173ca0d64314fcefe6d30da6f8cf27bafa706da61df8a226c839204000001000000\n\n nVersion: 01000000\n hashPrevouts: b0287b4a252ac05af83d2dcef00ba313af78a3e9c329afa216eb3aa2a7b4613a\n hashSequence: 18606b350cd8bf565266bc352f0caddcf01e8fa789dd8a15386327cf8cabe198\n outpoint: db6b1b20aa0fd7b23880be2ecbd4a98130974cf4748fb66092ac4d3ceb1a547701000000\n scriptCode: 1976a91479091972186c449eb1ded22b78e40d009bdf008988ac\n amount: 00ca9a3b00000000\n nSequence: feffffff\n hashOutputs: de984f44532e2173ca0d64314fcefe6d30da6f8cf27bafa706da61df8a226c83\n nLockTime: 92040000\n nHashType: 01000000\n\n sigHash: 64f3b0f4dd2bb3aa1ce8566d220cc74dda9df97d8490cc81d89d735c92e59fb6\n signature: 3044022047ac8e878352d3ebbde1c94ce3a10d057c24175747116f8288e5d794d12d482f0220217f36a485cae903c713331d877c1f64677e3622ad4010726870540656fe9dcb01\n\n The serialized signed transaction is: 01000000000101db6b1b20aa0fd7b23880be2ecbd4a98130974cf4748fb66092ac4d3ceb1a5477010000001716001479091972186c449eb1ded22b78e40d009bdf0089feffffff02b8b4eb0b000000001976a914a457b684d7f0d539a46a45bbc043f35b59d0d96388ac0008af2f000000001976a914fd270b1ee6abcaea97fea7ad0402e8bd8ad6d77c88ac02473044022047ac8e878352d3ebbde1c94ce3a10d057c24175747116f8288e5d794d12d482f0220217f36a485cae903c713331d877c1f64677e3622ad4010726870540656fe9dcb012103ad1d8e89212f0b92c74d23bb710c00662ad1470198ac48c43f7d6f93a2a2687392040000\n nVersion: 01000000\n marker: 00\n flag: 01\n txin: 01 db6b1b20aa0fd7b23880be2ecbd4a98130974cf4748fb66092ac4d3ceb1a5477 01000000 1716001479091972186c449eb1ded22b78e40d009bdf0089 feffffff\n txout: 02 b8b4eb0b00000000 1976a914a457b684d7f0d539a46a45bbc043f35b59d0d96388ac\n 0008af2f00000000 1976a914fd270b1ee6abcaea97fea7ad0402e8bd8ad6d77c88ac\n witness 02 473044022047ac8e878352d3ebbde1c94ce3a10d057c24175747116f8288e5d794d12d482f0220217f36a485cae903c713331d877c1f64677e3622ad4010726870540656fe9dcb01 2103ad1d8e89212f0b92c74d23bb710c00662ad1470198ac48c43f7d6f93a2a26873\n nLockTime: 92040000\n\n=== Native P2WSH ===\n\nThis example shows how OP_CODESEPARATOR and out-of-range SIGHASH_SINGLE are processed:\n\n\n\n The following is an unsigned transaction:\n 0100000002fe3dc9208094f3ffd12645477b3dc56f60ec4fa8e6f5d67c565d1c6b9216b36e0000000000ffffffff0815cf020f013ed6cf91d29f4202e8a58726b1ac6c79da47c23d1bee0a6925f80000000000ffffffff0100f2052a010000001976a914a30741f8145e5acadf23f751864167f32e0963f788ac00000000\n\n nVersion: 01000000\n txin: 02 fe3dc9208094f3ffd12645477b3dc56f60ec4fa8e6f5d67c565d1c6b9216b36e 00000000 00 ffffffff\n 0815cf020f013ed6cf91d29f4202e8a58726b1ac6c79da47c23d1bee0a6925f8 00000000 00 ffffffff\n txout: 01 00f2052a01000000 1976a914a30741f8145e5acadf23f751864167f32e0963f788ac\n nLockTime: 00000000\n\n The first input comes from an ordinary P2PK:\n scriptPubKey: 21036d5c20fa14fb2f635474c1dc4ef5909d4568e5569b79fc94d3448486e14685f8ac value: 1.5625\n private key: b8f28a772fccbf9b4f58a4f027e07dc2e35e7cd80529975e292ea34f84c4580c\n signature: 304402200af4e47c9b9629dbecc21f73af989bdaa911f7e6f6c2e9394588a3aa68f81e9902204f3fcf6ade7e5abb1295b6774c8e0abd94ae62217367096bc02ee5e435b67da201 (SIGHASH_ALL)\n\n The second input comes from a native P2WSH witness program:\n scriptPubKey : 00205d1b56b63d714eebe542309525f484b7e9d6f686b3781b6f61ef925d66d6f6a0, value: 49\n witnessScript: 21026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880aeadab210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac\n <026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880ae> CHECKSIGVERIFY CODESEPARATOR <0255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465> CHECKSIG\n\n To sign it with a nHashType of 3 (SIGHASH_SINGLE):\n\n hashPrevouts:\n dSHA256(fe3dc9208094f3ffd12645477b3dc56f60ec4fa8e6f5d67c565d1c6b9216b36e000000000815cf020f013ed6cf91d29f4202e8a58726b1ac6c79da47c23d1bee0a6925f800000000)\n = ef546acf4a020de3898d1b8956176bb507e6211b5ed3619cd08b6ea7e2a09d41\n\n nVersion: 01000000\n hashPrevouts: ef546acf4a020de3898d1b8956176bb507e6211b5ed3619cd08b6ea7e2a09d41\n hashSequence: 0000000000000000000000000000000000000000000000000000000000000000\n outpoint: 0815cf020f013ed6cf91d29f4202e8a58726b1ac6c79da47c23d1bee0a6925f800000000\n scriptCode: (see below)\n amount: 0011102401000000\n nSequence: ffffffff\n hashOutputs: 0000000000000000000000000000000000000000000000000000000000000000 (this is the second input but there is only one output)\n nLockTime: 00000000\n nHashType: 03000000\n\n scriptCode: 4721026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880aeadab210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac\n ^^\n (please note that the not-yet-executed OP_CODESEPARATOR is not removed from the scriptCode)\n preimage: 01000000ef546acf4a020de3898d1b8956176bb507e6211b5ed3619cd08b6ea7e2a09d4100000000000000000000000000000000000000000000000000000000000000000815cf020f013ed6cf91d29f4202e8a58726b1ac6c79da47c23d1bee0a6925f8000000004721026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880aeadab210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac0011102401000000ffffffff00000000000000000000000000000000000000000000000000000000000000000000000003000000\n sigHash: 82dde6e4f1e94d02c2b7ad03d2115d691f48d064e9d52f58194a6637e4194391\n public key: 026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880ae\n private key: 8e02b539b1500aa7c81cf3fed177448a546f19d2be416c0c61ff28e577d8d0cd\n signature: 3044022027dc95ad6b740fe5129e7e62a75dd00f291a2aeb1200b84b09d9e3789406b6c002201a9ecd315dd6a0e632ab20bbb98948bc0c6fb204f2c286963bb48517a7058e2703\n\n scriptCode: 23210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac\n (everything up to the last executed OP_CODESEPARATOR, including that OP_CODESEPARATOR, are removed)\n preimage: 01000000ef546acf4a020de3898d1b8956176bb507e6211b5ed3619cd08b6ea7e2a09d4100000000000000000000000000000000000000000000000000000000000000000815cf020f013ed6cf91d29f4202e8a58726b1ac6c79da47c23d1bee0a6925f80000000023210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac0011102401000000ffffffff00000000000000000000000000000000000000000000000000000000000000000000000003000000\n sigHash: fef7bd749cce710c5c052bd796df1af0d935e59cea63736268bcbe2d2134fc47\n public key: 0255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465\n private key: 86bf2ed75935a0cbef03b89d72034bb4c189d381037a5ac121a70016db8896ec\n signature: 304402200de66acf4527789bfda55fc5459e214fa6083f936b430a762c629656216805ac0220396f550692cd347171cbc1ef1f51e15282e837bb2b30860dc77c8f78bc8501e503\n\n The serialized signed transaction is: 01000000000102fe3dc9208094f3ffd12645477b3dc56f60ec4fa8e6f5d67c565d1c6b9216b36e000000004847304402200af4e47c9b9629dbecc21f73af989bdaa911f7e6f6c2e9394588a3aa68f81e9902204f3fcf6ade7e5abb1295b6774c8e0abd94ae62217367096bc02ee5e435b67da201ffffffff0815cf020f013ed6cf91d29f4202e8a58726b1ac6c79da47c23d1bee0a6925f80000000000ffffffff0100f2052a010000001976a914a30741f8145e5acadf23f751864167f32e0963f788ac000347304402200de66acf4527789bfda55fc5459e214fa6083f936b430a762c629656216805ac0220396f550692cd347171cbc1ef1f51e15282e837bb2b30860dc77c8f78bc8501e503473044022027dc95ad6b740fe5129e7e62a75dd00f291a2aeb1200b84b09d9e3789406b6c002201a9ecd315dd6a0e632ab20bbb98948bc0c6fb204f2c286963bb48517a7058e27034721026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880aeadab210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac00000000\n\n\nThis example shows how unexecuted OP_CODESEPARATOR is processed, and SINGLE|ANYONECANPAY does not commit to the input index:\n\n\n\n The following is an unsigned transaction:\n 0100000002e9b542c5176808107ff1df906f46bb1f2583b16112b95ee5380665ba7fcfc0010000000000ffffffff80e68831516392fcd100d186b3c2c7b95c80b53c77e77c35ba03a66b429a2a1b0000000000ffffffff0280969800000000001976a914de4b231626ef508c9a74a8517e6783c0546d6b2888ac80969800000000001976a9146648a8cd4531e1ec47f35916de8e259237294d1e88ac00000000\n\n nVersion: 01000000\n txin: 02 e9b542c5176808107ff1df906f46bb1f2583b16112b95ee5380665ba7fcfc001 00000000 00 ffffffff\n 80e68831516392fcd100d186b3c2c7b95c80b53c77e77c35ba03a66b429a2a1b 00000000 00 ffffffff\n txout: 02 8096980000000000 1976a914de4b231626ef508c9a74a8517e6783c0546d6b2888ac\n 8096980000000000 1976a9146648a8cd4531e1ec47f35916de8e259237294d1e88ac\n nLockTime: 00000000\n\n The first input comes from a native P2WSH witness program:\n scriptPubKey: 0020ba468eea561b26301e4cf69fa34bde4ad60c81e70f059f045ca9a79931004a4d value: 0.16777215\n witnessScript:0063ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac\n 0 IF CODESEPARATOR ENDIF <0392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98> CHECKSIG\n\n The second input comes from a native P2WSH witness program:\n scriptPubKey: 0020d9bbfbe56af7c4b7f960a70d7ea107156913d9e5a26b0a71429df5e097ca6537 value: 0.16777215\n witnessScript:5163ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac\n 1 IF CODESEPARATOR ENDIF <0392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98> CHECKSIG\n\n To sign it with a nHashType of 0x83 (SINGLE|ANYONECANPAY):\n\n nVersion: 01000000\n hashPrevouts: 0000000000000000000000000000000000000000000000000000000000000000\n hashSequence: 0000000000000000000000000000000000000000000000000000000000000000\n outpoint: (see below)\n scriptCode: (see below)\n amount: ffffff0000000000\n nSequence: ffffffff\n hashOutputs: (see below)\n nLockTime: 00000000\n nHashType: 83000000\n\n outpoint: e9b542c5176808107ff1df906f46bb1f2583b16112b95ee5380665ba7fcfc00100000000\n scriptCode: 270063ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac\n (since the OP_CODESEPARATOR is not executed, nothing is removed from the scriptCode)\n hashOutputs: b258eaf08c39fbe9fbac97c15c7e7adeb8df142b0df6f83e017f349c2b6fe3d2\n preimage: 0100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000e9b542c5176808107ff1df906f46bb1f2583b16112b95ee5380665ba7fcfc00100000000270063ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98acffffff0000000000ffffffffb258eaf08c39fbe9fbac97c15c7e7adeb8df142b0df6f83e017f349c2b6fe3d20000000083000000\n sigHash: e9071e75e25b8a1e298a72f0d2e9f4f95a0f5cdf86a533cda597eb402ed13b3a\n public key: 0392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98\n private key: f52b3484edd96598e02a9c89c4492e9c1e2031f471c49fd721fe68b3ce37780d\n signature: 3045022100f6a10b8604e6dc910194b79ccfc93e1bc0ec7c03453caaa8987f7d6c3413566002206216229ede9b4d6ec2d325be245c5b508ff0339bf1794078e20bfe0babc7ffe683\n\n outpoint: 80e68831516392fcd100d186b3c2c7b95c80b53c77e77c35ba03a66b429a2a1b00000000\n scriptCode: 2468210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac\n (everything up to the last executed OP_CODESEPARATOR, including that OP_CODESEPARATOR, are removed)\n hashOutputs: 91ea93dd77f702b738ebdbf3048940a98310e869a7bb8fa2c6cb3312916947ca\n preimage: 010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000080e68831516392fcd100d186b3c2c7b95c80b53c77e77c35ba03a66b429a2a1b000000002468210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98acffffff0000000000ffffffff91ea93dd77f702b738ebdbf3048940a98310e869a7bb8fa2c6cb3312916947ca0000000083000000\n sigHash: cd72f1f1a433ee9df816857fad88d8ebd97e09a75cd481583eb841c330275e54\n public key: 0392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98\n private key: f52b3484edd96598e02a9c89c4492e9c1e2031f471c49fd721fe68b3ce37780d\n signature: 30440220032521802a76ad7bf74d0e2c218b72cf0cbc867066e2e53db905ba37f130397e02207709e2188ed7f08f4c952d9d13986da504502b8c3be59617e043552f506c46ff83\n\n The serialized signed transaction is:\n 01000000000102e9b542c5176808107ff1df906f46bb1f2583b16112b95ee5380665ba7fcfc0010000000000ffffffff80e68831516392fcd100d186b3c2c7b95c80b53c77e77c35ba03a66b429a2a1b0000000000ffffffff0280969800000000001976a914de4b231626ef508c9a74a8517e6783c0546d6b2888ac80969800000000001976a9146648a8cd4531e1ec47f35916de8e259237294d1e88ac02483045022100f6a10b8604e6dc910194b79ccfc93e1bc0ec7c03453caaa8987f7d6c3413566002206216229ede9b4d6ec2d325be245c5b508ff0339bf1794078e20bfe0babc7ffe683270063ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac024730440220032521802a76ad7bf74d0e2c218b72cf0cbc867066e2e53db905ba37f130397e02207709e2188ed7f08f4c952d9d13986da504502b8c3be59617e043552f506c46ff83275163ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac00000000\n nVersion: 01000000\n marker: 00\n flag: 01\n txin: 02 e9b542c5176808107ff1df906f46bb1f2583b16112b95ee5380665ba7fcfc001 00000000 00 ffffffff\n 80e68831516392fcd100d186b3c2c7b95c80b53c77e77c35ba03a66b429a2a1b 00000000 00 ffffffff\n txout: 02 8096980000000000 1976a914de4b231626ef508c9a74a8517e6783c0546d6b2888ac\n 8096980000000000 1976a9146648a8cd4531e1ec47f35916de8e259237294d1e88ac\n witness 02 483045022100f6a10b8604e6dc910194b79ccfc93e1bc0ec7c03453caaa8987f7d6c3413566002206216229ede9b4d6ec2d325be245c5b508ff0339bf1794078e20bfe0babc7ffe683 270063ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac\n 02 4730440220032521802a76ad7bf74d0e2c218b72cf0cbc867066e2e53db905ba37f130397e02207709e2188ed7f08f4c952d9d13986da504502b8c3be59617e043552f506c46ff83 275163ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac\n nLockTime: 00000000\n\n Since SINGLE|ANYONECANPAY does not commit to the input index, the signatures are still valid when the input-output pairs are swapped:\n 0100000000010280e68831516392fcd100d186b3c2c7b95c80b53c77e77c35ba03a66b429a2a1b0000000000ffffffffe9b542c5176808107ff1df906f46bb1f2583b16112b95ee5380665ba7fcfc0010000000000ffffffff0280969800000000001976a9146648a8cd4531e1ec47f35916de8e259237294d1e88ac80969800000000001976a914de4b231626ef508c9a74a8517e6783c0546d6b2888ac024730440220032521802a76ad7bf74d0e2c218b72cf0cbc867066e2e53db905ba37f130397e02207709e2188ed7f08f4c952d9d13986da504502b8c3be59617e043552f506c46ff83275163ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac02483045022100f6a10b8604e6dc910194b79ccfc93e1bc0ec7c03453caaa8987f7d6c3413566002206216229ede9b4d6ec2d325be245c5b508ff0339bf1794078e20bfe0babc7ffe683270063ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac00000000\n nVersion: 01000000\n marker: 00\n flag: 01\n txin: 02 80e68831516392fcd100d186b3c2c7b95c80b53c77e77c35ba03a66b429a2a1b 00000000 00 ffffffff\n e9b542c5176808107ff1df906f46bb1f2583b16112b95ee5380665ba7fcfc001 00000000 00 ffffffff\n txout: 02 8096980000000000 1976a9146648a8cd4531e1ec47f35916de8e259237294d1e88ac\n 8096980000000000 1976a914de4b231626ef508c9a74a8517e6783c0546d6b2888ac\n witness 02 4730440220032521802a76ad7bf74d0e2c218b72cf0cbc867066e2e53db905ba37f130397e02207709e2188ed7f08f4c952d9d13986da504502b8c3be59617e043552f506c46ff83 275163ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac\n 02 483045022100f6a10b8604e6dc910194b79ccfc93e1bc0ec7c03453caaa8987f7d6c3413566002206216229ede9b4d6ec2d325be245c5b508ff0339bf1794078e20bfe0babc7ffe683 270063ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac\n nLockTime: 00000000\n\n=== P2SH-P2WSH ===\n\nThis example is a P2SH-P2WSH 6-of-6 multisig witness program signed with 6 different SIGHASH types.\n\n\n\n The following is an unsigned transaction: 010000000136641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e0100000000ffffffff0200e9a435000000001976a914389ffce9cd9ae88dcc0631e88a821ffdbe9bfe2688acc0832f05000000001976a9147480a33f950689af511e6e84c138dbbd3c3ee41588ac00000000\n\n nVersion: 01000000\n txin: 01 36641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e 01000000 00 ffffffff\n txout: 02 00e9a43500000000 1976a914389ffce9cd9ae88dcc0631e88a821ffdbe9bfe2688ac\n c0832f0500000000 1976a9147480a33f950689af511e6e84c138dbbd3c3ee41588ac\n nLockTime: 00000000\n\n The input comes from a P2SH-P2WSH 6-of-6 multisig witness program:\n scriptPubKey : a9149993a429037b5d912407a71c252019287b8d27a587, value: 9.87654321\n redeemScript : 0020a16b5755f7f6f96dbd65f5f0d6ab9418b89af4b1f14a1bb8a09062c35f0dcb54\n witnessScript: 56210307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba32103b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b21034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a21033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f42103a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac162102d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b56ae\n\n hashPrevouts:\n dSHA256(36641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e01000000)\n = 74afdc312af5183c4198a40ca3c1a275b485496dd3929bca388c4b5e31f7aaa0\n\n hashSequence:\n dSHA256(ffffffff)\n = 3bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e70665044\n\n hashOutputs for ALL:\n dSHA256(00e9a435000000001976a914389ffce9cd9ae88dcc0631e88a821ffdbe9bfe2688acc0832f05000000001976a9147480a33f950689af511e6e84c138dbbd3c3ee41588ac)\n = bc4d309071414bed932f98832b27b4d76dad7e6c1346f487a8fdbb8eb90307cc\n\n hashOutputs for SINGLE:\n dSHA256(00e9a435000000001976a914389ffce9cd9ae88dcc0631e88a821ffdbe9bfe2688ac)\n = 9efe0c13a6b16c14a41b04ebe6a63f419bdacb2f8705b494a43063ca3cd4f708\n\n hash preimage for ALL: 0100000074afdc312af5183c4198a40ca3c1a275b485496dd3929bca388c4b5e31f7aaa03bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e7066504436641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e01000000cf56210307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba32103b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b21034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a21033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f42103a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac162102d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b56aeb168de3a00000000ffffffffbc4d309071414bed932f98832b27b4d76dad7e6c1346f487a8fdbb8eb90307cc0000000001000000\n nVersion: 01000000\n hashPrevouts: 74afdc312af5183c4198a40ca3c1a275b485496dd3929bca388c4b5e31f7aaa0\n hashSequence: 3bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e70665044\n outpoint: 36641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e01000000\n scriptCode: cf56210307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba32103b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b21034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a21033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f42103a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac162102d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b56ae\n amount: b168de3a00000000\n nSequence: ffffffff\n hashOutputs: bc4d309071414bed932f98832b27b4d76dad7e6c1346f487a8fdbb8eb90307cc\n nLockTime: 00000000\n nHashType: 01000000\n sigHash: 185c0be5263dce5b4bb50a047973c1b6272bfbd0103a89444597dc40b248ee7c\n public key: 0307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba3\n private key: 730fff80e1413068a05b57d6a58261f07551163369787f349438ea38ca80fac6\n signature: 304402206ac44d672dac41f9b00e28f4df20c52eeb087207e8d758d76d92c6fab3b73e2b0220367750dbbe19290069cba53d096f44530e4f98acaa594810388cf7409a1870ce01\n\n hash preimage for NONE: 0100000074afdc312af5183c4198a40ca3c1a275b485496dd3929bca388c4b5e31f7aaa0000000000000000000000000000000000000000000000000000000000000000036641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e01000000cf56210307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba32103b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b21034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a21033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f42103a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac162102d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b56aeb168de3a00000000ffffffff00000000000000000000000000000000000000000000000000000000000000000000000002000000\n nVersion: 01000000\n hashPrevouts: 74afdc312af5183c4198a40ca3c1a275b485496dd3929bca388c4b5e31f7aaa0\n hashSequence: 0000000000000000000000000000000000000000000000000000000000000000\n outpoint: 36641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e01000000\n scriptCode: cf56210307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba32103b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b21034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a21033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f42103a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac162102d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b56ae\n amount: b168de3a00000000\n nSequence: ffffffff\n hashOutputs: 0000000000000000000000000000000000000000000000000000000000000000\n nLockTime: 00000000\n nHashType: 02000000\n sigHash: e9733bc60ea13c95c6527066bb975a2ff29a925e80aa14c213f686cbae5d2f36\n public key: 03b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b\n private key: 11fa3d25a17cbc22b29c44a484ba552b5a53149d106d3d853e22fdd05a2d8bb3\n signature: 3044022068c7946a43232757cbdf9176f009a928e1cd9a1a8c212f15c1e11ac9f2925d9002205b75f937ff2f9f3c1246e547e54f62e027f64eefa2695578cc6432cdabce271502\n\n hash preimage for SINGLE: 0100000074afdc312af5183c4198a40ca3c1a275b485496dd3929bca388c4b5e31f7aaa0000000000000000000000000000000000000000000000000000000000000000036641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e01000000cf56210307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba32103b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b21034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a21033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f42103a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac162102d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b56aeb168de3a00000000ffffffff9efe0c13a6b16c14a41b04ebe6a63f419bdacb2f8705b494a43063ca3cd4f7080000000003000000\n nVersion: 01000000\n hashPrevouts: 74afdc312af5183c4198a40ca3c1a275b485496dd3929bca388c4b5e31f7aaa0\n hashSequence: 0000000000000000000000000000000000000000000000000000000000000000\n outpoint: 36641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e01000000\n scriptCode: cf56210307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba32103b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b21034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a21033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f42103a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac162102d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b56ae\n amount: b168de3a00000000\n nSequence: ffffffff\n hashOutputs: 9efe0c13a6b16c14a41b04ebe6a63f419bdacb2f8705b494a43063ca3cd4f708\n nLockTime: 00000000\n nHashType: 03000000\n sigHash: 1e1f1c303dc025bd664acb72e583e933fae4cff9148bf78c157d1e8f78530aea\n public key: 034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a\n private key: 77bf4141a87d55bdd7f3cd0bdccf6e9e642935fec45f2f30047be7b799120661\n signature: 3044022059ebf56d98010a932cf8ecfec54c48e6139ed6adb0728c09cbe1e4fa0915302e022007cd986c8fa870ff5d2b3a89139c9fe7e499259875357e20fcbb15571c76795403\n\n hash preimage for ALL|ANYONECANPAY: 010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000036641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e01000000cf56210307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba32103b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b21034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a21033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f42103a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac162102d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b56aeb168de3a00000000ffffffffbc4d309071414bed932f98832b27b4d76dad7e6c1346f487a8fdbb8eb90307cc0000000081000000\n nVersion: 01000000\n hashPrevouts: 0000000000000000000000000000000000000000000000000000000000000000\n hashSequence: 0000000000000000000000000000000000000000000000000000000000000000\n outpoint: 36641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e01000000\n scriptCode: cf56210307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba32103b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b21034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a21033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f42103a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac162102d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b56ae\n amount: b168de3a00000000\n nSequence: ffffffff\n hashOutputs: bc4d309071414bed932f98832b27b4d76dad7e6c1346f487a8fdbb8eb90307cc\n nLockTime: 00000000\n nHashType: 81000000\n sigHash: 2a67f03e63a6a422125878b40b82da593be8d4efaafe88ee528af6e5a9955c6e\n public key: 033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f4\n private key: 14af36970f5025ea3e8b5542c0f8ebe7763e674838d08808896b63c3351ffe49\n signature: 3045022100fbefd94bd0a488d50b79102b5dad4ab6ced30c4069f1eaa69a4b5a763414067e02203156c6a5c9cf88f91265f5a942e96213afae16d83321c8b31bb342142a14d16381\n\n hash preimage for NONE|ANYONECANPAY: 010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000036641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e01000000cf56210307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba32103b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b21034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a21033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f42103a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac162102d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b56aeb168de3a00000000ffffffff00000000000000000000000000000000000000000000000000000000000000000000000082000000\n nVersion: 01000000\n hashPrevouts: 0000000000000000000000000000000000000000000000000000000000000000\n hashSequence: 0000000000000000000000000000000000000000000000000000000000000000\n outpoint: 36641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e01000000\n scriptCode: cf56210307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba32103b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b21034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a21033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f42103a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac162102d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b56ae\n amount: b168de3a00000000\n nSequence: ffffffff\n hashOutputs: 0000000000000000000000000000000000000000000000000000000000000000\n nLockTime: 00000000\n nHashType: 82000000\n sigHash: 781ba15f3779d5542ce8ecb5c18716733a5ee42a6f51488ec96154934e2c890a\n public key: 03a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac16\n private key: fe9a95c19eef81dde2b95c1284ef39be497d128e2aa46916fb02d552485e0323\n signature: 3045022100a5263ea0553ba89221984bd7f0b13613db16e7a70c549a86de0cc0444141a407022005c360ef0ae5a5d4f9f2f87a56c1546cc8268cab08c73501d6b3be2e1e1a8a0882\n\n hash preimage for SINGLE|ANYONECANPAY: 010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000036641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e01000000cf56210307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba32103b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b21034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a21033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f42103a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac162102d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b56aeb168de3a00000000ffffffff9efe0c13a6b16c14a41b04ebe6a63f419bdacb2f8705b494a43063ca3cd4f7080000000083000000\n nVersion: 01000000\n hashPrevouts: 0000000000000000000000000000000000000000000000000000000000000000\n hashSequence: 0000000000000000000000000000000000000000000000000000000000000000\n outpoint: 36641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e01000000\n scriptCode: cf56210307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba32103b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b21034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a21033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f42103a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac162102d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b56ae\n amount: b168de3a00000000\n nSequence: ffffffff\n hashOutputs: 9efe0c13a6b16c14a41b04ebe6a63f419bdacb2f8705b494a43063ca3cd4f708\n nLockTime: 00000000\n nHashType: 83000000\n sigHash: 511e8e52ed574121fc1b654970395502128263f62662e076dc6baf05c2e6a99b\n public key: 02d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b\n private key: 428a7aee9f0c2af0cd19af3cf1c78149951ea528726989b2e83e4778d2c3f890\n signature: 30440220525406a1482936d5a21888260dc165497a90a15669636d8edca6b9fe490d309c022032af0c646a34a44d1f4576bf6a4a74b67940f8faa84c7df9abe12a01a11e2b4783\n\n The serialized signed transaction is: 0100000000010136641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e0100000023220020a16b5755f7f6f96dbd65f5f0d6ab9418b89af4b1f14a1bb8a09062c35f0dcb54ffffffff0200e9a435000000001976a914389ffce9cd9ae88dcc0631e88a821ffdbe9bfe2688acc0832f05000000001976a9147480a33f950689af511e6e84c138dbbd3c3ee41588ac080047304402206ac44d672dac41f9b00e28f4df20c52eeb087207e8d758d76d92c6fab3b73e2b0220367750dbbe19290069cba53d096f44530e4f98acaa594810388cf7409a1870ce01473044022068c7946a43232757cbdf9176f009a928e1cd9a1a8c212f15c1e11ac9f2925d9002205b75f937ff2f9f3c1246e547e54f62e027f64eefa2695578cc6432cdabce271502473044022059ebf56d98010a932cf8ecfec54c48e6139ed6adb0728c09cbe1e4fa0915302e022007cd986c8fa870ff5d2b3a89139c9fe7e499259875357e20fcbb15571c76795403483045022100fbefd94bd0a488d50b79102b5dad4ab6ced30c4069f1eaa69a4b5a763414067e02203156c6a5c9cf88f91265f5a942e96213afae16d83321c8b31bb342142a14d16381483045022100a5263ea0553ba89221984bd7f0b13613db16e7a70c549a86de0cc0444141a407022005c360ef0ae5a5d4f9f2f87a56c1546cc8268cab08c73501d6b3be2e1e1a8a08824730440220525406a1482936d5a21888260dc165497a90a15669636d8edca6b9fe490d309c022032af0c646a34a44d1f4576bf6a4a74b67940f8faa84c7df9abe12a01a11e2b4783cf56210307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba32103b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b21034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a21033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f42103a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac162102d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b56ae00000000\n\n\n=== No FindAndDelete ===\n\nThese examples show that FindAndDelete for the signature is not applied. The transactions are generated in an unconventional way. Instead of signing using a private key, the signatures are pre-determined as part of witnessScript. The public keys are generated with key recovery, using the fixed signatures and the sighash defined in this proposal. Therefore, the private keys are unknown.\n\n\n The following is an unsigned transaction: 010000000169c12106097dc2e0526493ef67f21269fe888ef05c7a3a5dacab38e1ac8387f14c1d000000ffffffff0101000000000000000000000000\n\n nVersion: 01000000\n txin: 01 69c12106097dc2e0526493ef67f21269fe888ef05c7a3a5dacab38e1ac8387f1 4c1d0000 00 ffffffff\n txout: 01 0100000000000000 00\n nLockTime: 00000000\n\n The input comes from a P2WSH witness program:\n scriptPubKey : 00209e1be07558ea5cc8e02ed1d80c0911048afad949affa36d5c3951e3159dbea19, value: 0.00200000\n redeemScript : OP_CHECKSIGVERIFY <0x30450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e01>\n ad4830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e01\n\n To sign it with a nHashType of 1 (SIGHASH_ALL):\n\n hashPrevouts:\n dSHA256(69c12106097dc2e0526493ef67f21269fe888ef05c7a3a5dacab38e1ac8387f14c1d0000)\n = b67c76d200c6ce72962d919dc107884b9d5d0e26f2aea7474b46a1904c53359f\n\n hashSequence:\n dSHA256(ffffffff)\n = 3bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e70665044\n\n hashOutputs:\n dSHA256(010000000000000000)\n = e5d196bfb21caca9dbd654cafb3b4dc0c4882c8927d2eb300d9539dd0b934228\n\n hash preimage: 01000000b67c76d200c6ce72962d919dc107884b9d5d0e26f2aea7474b46a1904c53359f3bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e7066504469c12106097dc2e0526493ef67f21269fe888ef05c7a3a5dacab38e1ac8387f14c1d00004aad4830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e01400d030000000000ffffffffe5d196bfb21caca9dbd654cafb3b4dc0c4882c8927d2eb300d9539dd0b9342280000000001000000\n\n nVersion: 01000000\n hashPrevouts: b67c76d200c6ce72962d919dc107884b9d5d0e26f2aea7474b46a1904c53359f\n hashSequence: 3bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e70665044\n outpoint: 69c12106097dc2e0526493ef67f21269fe888ef05c7a3a5dacab38e1ac8387f14c1d0000\n scriptCode: 4aad4830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e01\n amount: 400d030000000000\n nSequence: ffffffff\n hashOutputs: e5d196bfb21caca9dbd654cafb3b4dc0c4882c8927d2eb300d9539dd0b934228\n nLockTime: 00000000\n nHashType: 01000000\n\n sigHash: 71c9cd9b2869b9c70b01b1f0360c148f42dee72297db312638df136f43311f23\n signature: 30450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e 01\n pubkey: 02a9781d66b61fb5a7ef00ac5ad5bc6ffc78be7b44a566e3c87870e1079368df4c\n\n The serialized signed transaction is: 0100000000010169c12106097dc2e0526493ef67f21269fe888ef05c7a3a5dacab38e1ac8387f14c1d000000ffffffff01010000000000000000034830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e012102a9781d66b61fb5a7ef00ac5ad5bc6ffc78be7b44a566e3c87870e1079368df4c4aad4830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e0100000000\n\n nVersion: 01000000\n marker: 00\n flag: 01\n txin: 01 69c12106097dc2e0526493ef67f21269fe888ef05c7a3a5dacab38e1ac8387f1 4c1d0000 00 ffffffff\n txout: 01 0100000000000000 00\n witness: 03 4830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e01\n 2102a9781d66b61fb5a7ef00ac5ad5bc6ffc78be7b44a566e3c87870e1079368df4c\n 4aad4830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e01\n nLockTime: 00000000\n\n\n\n The following transaction is a OP_CHECKMULTISIGVERIFY version of the FindAndDelete examples: 010000000001019275cb8d4a485ce95741c013f7c0d28722160008021bb469a11982d47a6628964c1d000000ffffffff0101000000000000000007004830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e0148304502205286f726690b2e9b0207f0345711e63fa7012045b9eb0f19c2458ce1db90cf43022100e89f17f86abc5b149eba4115d4f128bcf45d77fb3ecdd34f594091340c0395960101022102966f109c54e85d3aee8321301136cedeb9fc710fdef58a9de8a73942f8e567c021034ffc99dd9a79dd3cb31e2ab3e0b09e0e67db41ac068c625cd1f491576016c84e9552af4830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e0148304502205286f726690b2e9b0207f0345711e63fa7012045b9eb0f19c2458ce1db90cf43022100e89f17f86abc5b149eba4115d4f128bcf45d77fb3ecdd34f594091340c039596017500000000\n\n redeemScript: OP_2 OP_CHECKMULTISIGVERIFY <30450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e01> <304502205286f726690b2e9b0207f0345711e63fa7012045b9eb0f19c2458ce1db90cf43022100e89f17f86abc5b149eba4115d4f128bcf45d77fb3ecdd34f594091340c03959601>\n hash preimage: 0100000039283953eb1e26994dde57b7f9362a79a8c523e2f8deba943c27e826a005f1e63bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e706650449275cb8d4a485ce95741c013f7c0d28722160008021bb469a11982d47a6628964c1d00009552af4830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e0148304502205286f726690b2e9b0207f0345711e63fa7012045b9eb0f19c2458ce1db90cf43022100e89f17f86abc5b149eba4115d4f128bcf45d77fb3ecdd34f594091340c0395960175400d030000000000ffffffffe5d196bfb21caca9dbd654cafb3b4dc0c4882c8927d2eb300d9539dd0b9342280000000001000000\n sighash: c1628a1e7c67f14ca0c27c06e4fdeec2e6d1a73c7a91d7c046ff83e835aebb72\n witness: 07 00\n 4830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e01\n 48304502205286f726690b2e9b0207f0345711e63fa7012045b9eb0f19c2458ce1db90cf43022100e89f17f86abc5b149eba4115d4f128bcf45d77fb3ecdd34f594091340c03959601\n 0102\n 2102966f109c54e85d3aee8321301136cedeb9fc710fdef58a9de8a73942f8e567c0\n 21034ffc99dd9a79dd3cb31e2ab3e0b09e0e67db41ac068c625cd1f491576016c84e\n 9552af4830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e0148304502205286f726690b2e9b0207f0345711e63fa7012045b9eb0f19c2458ce1db90cf43022100e89f17f86abc5b149eba4115d4f128bcf45d77fb3ecdd34f594091340c0395960175\n\n\nThe new serialization format is described in BIP144 [[bip-0144.mediawiki|BIP144: Segregated Witness (Peer Services)]]\n\n== Deployment ==\n\nThis proposal is deployed with Segregated Witness softfork (BIP 141)\n\n== Backward compatibility ==\n\nAs a soft fork, older software will continue to operate without modification. Non-upgraded nodes, however, will not see nor validate the witness data and will consider all witness programs, including the redefined sigops, as anyone-can-spend scripts.\n\n== Reference Implementation ==\n\nhttps://github.com/bitcoin/bitcoin/pull/8149\n\n== References ==\n\n\n\n== Copyright ==\n\nThis document is placed in the public domain.", "category": "bips" }, { "instruction": "Can you show me the CLI commands for 
?",
    "input": "",
    "output": "BIP: 121\n  Layer: Applications\n  Title: Proof of Payment URI scheme\n  Authors: Kalle Rosenbaum \n  Status: Closed\n  Type: Specification\n  Assigned: 2015-07-27\n
\n\n== Abstract ==\n\nThis is a proposal for a URI scheme to be used in the Proof of Payment\nprocess.\n\n== Motivation ==\n\nTo make a Proof of Payment, the party that wants the proof needs to\ntransfer a Proof of Payment request to the wallet software of the\nother party. To facilitate that transfer, a new URI scheme\nrepresenting the PoP request is proposed. This URI can then be encoded\nin QR images or be sent over NFC in order to transfer it to the wallet.\n\n== Specification ==\n\nThe specification is the same as BIP0021, with the following\ndifferences:\n\n* The URI scheme is btcpop instead of bitcoin\n* The path component, i.e. the address part, is always empty.\n* A mandatory p parameter whose value contains the destination for the PoP. This could for example be a https: URL or a mailto: URI.\n* A mandatory n parameter representing the nonce, base58 encoded.\n* An optional txid parameter containing the Base58 encoded hash of the transaction to prove.\n\nJust as in BIP0021, elements of the query component may contain\ncharacters outside the valid range. These must first be encoded\naccording to UTF-8, and then each octet of the corresponding UTF-8\nsequence must be percent-encoded as described in RFC 3986.\n\nAll parameters except p and n are hints to the\nwallet on which transaction to create a PoP for.\n\nThe extensibility of BIP0021 applies to this scheme as well. For\nexample, a date parameter or a toaddr parameter\nmight be useful. req-* parameters are also allowed and obey\nthe same rules as in BIP0021, clients not supporting a req-*\nparameter must consider the URI invalid.\n\n=== Keep URIs short ===\n\nImplementations should keep the URIs as short as possible. This is\nbecause it makes QR decoding more stable. A camera with a scratched\nlens or low resolution may run into problems scanning huge QR\ncodes. This is why the txid parameter is encoded in Base58\ninstead of the classic hex encoded string. We get away with 44\ncharacters instead of 64. Also, the nonce parameter is Base58\nencoded for the same reason.\n\n== Interpretation ==\n\n=== Transaction hints ===\n\nThe wallet processing the URI must use the hints in the PoP request to\nfilter its transaction set. The label, amount and\nmessage parameters must, if present in the URI, exactly match\nthe data associated with the original payment according to the\nfollowing table:\n\n{|\n| btcpop: URI parameter || bitcoin: URI parameter || BIP70 PaymentDetails data\n|-\n| label || label || memo\n|-\n| amount || amount || sum of outputs.amount\n|-\n| message || message || -\n|}\n\nThe txid parameter value must match the transaction hash of\nthe payment.\n\nAfter filtering, the resulting transaction set is displayed to the\nuser who selects one of them to prove. An implementation could also\nautomatically select a transaction in the filtered set, but\nthere must still be a way for the user to select freely among the\nmatching transactions. If the filtered set is empty, no transaction\nfits the hints and a message about that is presented to the user. If\nthe filtered set contains exactly one transaction, which is\npreferable, that transaction can be automatically selected.\n\nAs a fallback, there must also be a way for the user to select any\ntransaction from the wallet regardless of the transaction hints. This\ncan be useful if the metadata of the wallet is lost, possibly due to a\nrestore from backup.\n\n=== PoP destination p ===\n\nThe p parameter value is the destination where to send the\nPoP to. This destination is typically a https: URL or a\nhttp: URL, but it could be any type of URI, for example\nmailto:. To keep btcpop: URIs short, users should\nnot make their p parameter unnecessarily long.\n\n==== http: and https: URLs ====\n\nWallet implementations must support the http: and\nhttps: schemes in which case POST method must be\nused. The PoP is sent as a binary serialized transaction. The content\ntype of the POST request must be set to\napplication/bitcoin-pop\n\n== Examples ==\n\nSend PoP for a transaction with label \"video 42923\" to\nhttps://www.example.com/pop/352, using nonce\n0x73 0xd5 0x1a 0xbb 0xd8 0x9c:\n
\n btcpop:?p=https://www.example.com/pop/352&n=zgWTm8yH&label=video%2042923\n
\nSend PoP through mail using\nmailto:pop@example.com?subject=pop444, amount\nis 13370000 satoshis, nonce is 0x6f 0xe 0xfb 0x68 0x92 0xf9.\nNote that the ? before subject is OK according to RFC3986,\nsince the query part starts from the first ?:\n
\n btcpop:?p=mailto:pop@example.com?subject%3Dpop444&n=xJdKmEbr&amount=0.1337\n
\nSend PoP for transaction with id\ncca7507897abc89628f450e8b1e0c6fca4ec3f7b34cccf55f3f531c659ff4d79\nto pizza place at http://pizza.example.com/pop/laszlo111 using nonce 0xfc 0xcc 0x2c 0x35 0xf0 0xb8\n
\n btcpop:?p=http://pizza.example.com/pop/laszlo111&n=3AtNpVrPh&txid=Emt9MPvt1joznqHy5eEHkNtcuQuYWXzYJBQZN6BJm6NL\n
\n== Reference implementation ==\n\n[https://github.com/kallerosenbaum/poppoc PoP Demo server on GitHub]\n\n[https://github.com/kallerosenbaum/wallet PoP-enabled Mycelium fork on GitHub]\n\n== References ==\n\n[https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki BIP0021]: URI Scheme\n\n[https://github.com/bitcoin/bips/blob/master/bip-0120.mediawiki BIP0120]: Proof of Payment\n\n[https://www.ietf.org/rfc/rfc3986.txt RFC3986]: Uniform Resource Identifier (URI): Generic Syntax", "category": "bips" }, { "instruction": "I'm stuck with 
 - what should I check?",
    "input": "",
    "output": "BIP: 91\n  Layer: Consensus (soft fork)\n  Title: Reduced threshold Segwit MASF\n  Authors: James Hilliard \n  Status: Deployed\n  Type: Specification\n  Assigned: 2017-05-22\n  License: BSD-3-Clause OR CC0-1.0\n
\n\n==Abstract==\n\nThis document specifies a method to activate the existing BIP9 segwit deployment with a majority hashpower less than 95%.\n\n==Definitions==\n\n\"existing segwit deployment\" refer to the BIP9 \"segwit\" deployment using bit 1, between November 15th 2016 and November 15th 2017 to activate BIP141, BIP143 and BIP147.\n\n==Motivation==\n\nSegwit increases the blocksize, fixes transaction malleability, and makes scripting easier to upgrade as well as bringing many other [https://bitcoincore.org/en/2016/01/26/segwit-benefits/ benefits].\n\nThis BIP provides a way for a simple majority of miners to coordinate activation of the existing segwit deployment with less than 95% hashpower. For a number of reasons a complete redeployment of segwit is difficult to do until the existing deployment expires. This is due to 0.13.1+ having many segwit related features active already, including all the P2P components, the new network service flag, the witness-tx and block messages, compact blocks v2 and preferential peering. A redeployment of segwit will need to redefine all these things and doing so before expiry would greatly complicate testing.\n\n==Specification==\n\nWhile this BIP is active, all blocks must set the nVersion header top 3 bits to 001 together with bit field (1<<1) (according to the existing segwit deployment). Blocks that do not signal as required will be rejected.\n\n==Deployment==\n\nThis BIP will be deployed by a \"version bits\" with an 80%(this can be adjusted if desired) 269 block activation threshold and 336 block confirmation window BIP9 with the name \"segsignal\" and using bit 4.\n\nThis BIP will have a start time of midnight June 1st, 2017 (epoch time 1496275200) and timeout on midnight November 15th 2017 (epoch time 1510704000). This BIP will cease to be active when segwit (BIP141) is locked-in, active, or failed\n\n=== Reference implementation ===\n\n
\n// Deployment of SEGSIGNAL\nconsensus.vDeployments[Consensus::DEPLOYMENT_SEGSIGNAL].bit = 4;\nconsensus.vDeployments[Consensus::DEPLOYMENT_SEGSIGNAL].nStartTime = 1496275200; // June 1st, 2017.\nconsensus.vDeployments[Consensus::DEPLOYMENT_SEGSIGNAL].nTimeout = 1510704000; // November 15th, 2017.\nconsensus.vDeployments[Consensus::DEPLOYMENT_SEGSIGNAL].nOverrideMinerConfirmationWindow = 336; // ~2.33 days\nconsensus.vDeployments[Consensus::DEPLOYMENT_SEGSIGNAL].nOverrideRuleChangeActivationThreshold = 269; // 80%\n\nclass VersionBitsConditionChecker : public AbstractThresholdConditionChecker {\nprivate:\n    const Consensus::DeploymentPos id;\n\nprotected:\n    int64_t BeginTime(const Consensus::Params& params) const { return params.vDeployments[id].nStartTime; }\n    int64_t EndTime(const Consensus::Params& params) const { return params.vDeployments[id].nTimeout; }\n    int Period(const Consensus::Params& params) const {\n        if (params.vDeployments[id].nOverrideMinerConfirmationWindow > 0)\n            return params.vDeployments[id].nOverrideMinerConfirmationWindow;\n        return params.nMinerConfirmationWindow;\n    }\n    int Threshold(const Consensus::Params& params) const {\n        if (params.vDeployments[id].nOverrideRuleChangeActivationThreshold > 0)\n            return params.vDeployments[id].nOverrideRuleChangeActivationThreshold;\n        return params.nRuleChangeActivationThreshold;\n    }\n\n    bool Condition(const CBlockIndex* pindex, const Consensus::Params& params) const\n    {\n        return (((pindex->nVersion & VERSIONBITS_TOP_MASK) == VERSIONBITS_TOP_BITS) && (pindex->nVersion & Mask(params)) != 0);\n    }\n\npublic:\n    VersionBitsConditionChecker(Consensus::DeploymentPos id_) : id(id_) {}\n    uint32_t Mask(const Consensus::Params& params) const { return ((uint32_t)1) << params.vDeployments[id].bit; }\n};\n\n// SEGSIGNAL mandatory segwit signalling.\nif (VersionBitsState(pindex->pprev, chainparams.GetConsensus(), Consensus::DEPLOYMENT_SEGSIGNAL, versionbitscache) == THRESHOLD_ACTIVE &&\n    VersionBitsState(pindex->pprev, chainparams.GetConsensus(), Consensus::DEPLOYMENT_SEGWIT,    versionbitscache) == THRESHOLD_STARTED)\n{\n    bool fVersionBits = (pindex->nVersion & VERSIONBITS_TOP_MASK) == VERSIONBITS_TOP_BITS;\n    bool fSegbit = (pindex->nVersion & VersionBitsMask(chainparams.GetConsensus(), Consensus::DEPLOYMENT_SEGWIT)) != 0;\n    if (!(fVersionBits && fSegbit)) {\n        return state.DoS(0, error(\"ConnectBlock(): relayed block must signal for segwit, please upgrade\"), REJECT_INVALID, \"bad-no-segwit\");\n    }\n}\n
\n\nhttps://github.com/segsignal/bitcoin\n\n==Backwards Compatibility==\n\nThis deployment is compatible with the existing \"segwit\" bit 1 deployment scheduled between midnight November 15th, 2016 and midnight November 15th, 2017. Miners will need to upgrade their nodes to support segsignal otherwise they may build on top of an invalid block. While this bip is active users should either upgrade to segsignal or wait for additional confirmations when accepting payments.\n\n==Rationale==\n\nHistorically we have used IsSuperMajority() to activate soft forks such as BIP66 which has a mandatory signalling requirement for miners once activated, this ensures that miners are aware of new rules being enforced. This technique can be leveraged to lower the signalling threshold of a soft fork while it is in the process of being deployed in a backwards compatible way.\n\nBy orphaning non-signalling blocks during the BIP9 bit 1 \"segwit\" deployment, this BIP can cause the existing \"segwit\" deployment to activate without needing to release a new deployment.\n\n==References==\n\n*[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013714.html Mailing list discussion]\n*[https://github.com/bitcoin/bitcoin/blob/v0.6.0/src/main.cpp#L1281-L1283 P2SH flag day activation]\n*[[bip-0009.mediawiki|BIP9 Version bits with timeout and delay]]\n*[[bip-0016.mediawiki|BIP16 Pay to Script Hash]]\n*[[bip-0141.mediawiki|BIP141 Segregated Witness (Consensus layer)]]\n*[[bip-0143.mediawiki|BIP143 Transaction Signature Verification for Version 0 Witness Program]]\n*[[bip-0147.mediawiki|BIP147 Dealing with dummy stack element malleability]]\n*[[bip-0148.mediawiki|BIP148 Mandatory activation of segwit deployment]]\n*[[bip-0149.mediawiki|BIP149 Segregated Witness (second deployment)]]\n*[https://bitcoincore.org/en/2016/01/26/segwit-benefits/ Segwit benefits]\n\n==Copyright==\n\nThis document is dual licensed as BSD 3-clause, and Creative Commons CC0 1.0 Universal.", "category": "bips" }, { "instruction": "How do I troubleshoot 
 issues?",
    "input": "",
    "output": "BIP: 322\n  Layer: Applications\n  Title: Generic Signed Message Format\n  Authors: Karl-Johan Alm \n           Oliver Gugger \n  Status: Complete\n  Type: Specification\n  Assigned: 2018-09-10\n  License: CC0-1.0\n  Discussion: 2018-03-14: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-March/015818.html\n              2019-07-23: https://github.com/bitcoin/bitcoin/pull/16440\n              2022-01-13: https://github.com/bitcoin/bitcoin/pull/24058\n              2022-08-06: https://bitcointalk.org/index.php?topic=5408898.0\n              2024-05-04: https://groups.google.com/g/bitcoindev/c/RCi1Exs0ZvQ/m/vp6Xo36aBwAJ\n              2025-05-10: https://bitcoin.stackexchange.com/questions/126277/where-can-i-use-bip322-to-sign-a-message-to-verify-a-multisig-address\n              2026-04-20: https://groups.google.com/g/bitcoindev/c/qd6BNz9gxCk/m/k1fHq4RKAQAJ\n  Version: 1.0.0\n  Requires: 174, 340, 341\n
\n\n== Abstract ==\n\nA standard for interoperable signed messages based on the Bitcoin Script format, either for proving\navailability of funds, or for committing to a message as the intended recipient of funds sent to the\ninvoice address.\n\n== Motivation ==\n\nThe current message signing standard only works for P2PKH (1...) invoice addresses. We propose to\nextend and generalize the standard by using an approach based on Bitcoin Script. This ensures that\nany coins, no matter what script they are controlled by, can in principle be signed for. For easy\ninteroperability with existing signing hardware, we also define a signature message format that\nresembles a Bitcoin transaction (except that it contains an invalid input, so it cannot be spent on\nany real network).\n\nAdditionally, the current message signature format uses ECDSA signatures that do not commit to the\npublic key, meaning that they do not actually prove knowledge of any secret keys. (Indeed, valid\nsignatures can be tweaked by third parties to become valid signatures on certain related keys.)\n\nUltimately, no message signing protocol can actually prove control of funds, both because a signature\nis obsolete as soon as it is created, and because the possessor of a secret key may be willing to\nsign messages on others' behalf even if it would not sign actual transactions. No message signing\nprotocol can fix these limitations.\n\nFinally, this BIP only addresses the use case where a signer shows they will be able to control\nfunds sent to the invoice address. Proving that a signer sent a prior transaction is not possible\nusing this BIP.\n\n== Terminology ==\n\nIn the context of this BIP, whenever the word \"signature\" or similar is used, it refers to the\noutput of the signing process described below, and, depending on the script type of the\nmessage_challenge, is either a full transaction input witness stack, a full\ntransaction, or a PSBT packet that can be validated against a Bitcoin Script Interpreter. Such a\n\"signature\" may or may not contain an actual cryptographic (ECDSA or Schnorr) signature, depending\non what is required to satisfy the script corresponding to the message_challenge.\n\n== Types of Signatures ==\n\nThis BIP specifies three formats for signing messages: ''legacy'', ''simple'' and ''full''.\nAdditionally, a variant of the ''full'' format can be used to demonstrate control over a set of\nUTXOs.\n\n{| class=\"wikitable\"\n|- style=\"font-weight:bold;\"\n!\n! Compatible script types\n! Signature prefix\n! Signature format\n|-\n| Legacy\n| P2PKH, P2SH-P2WPKH1, P2WPKH1\n| n/a\n| compact, public key recoverable ECDSA signature, base64-encoded\n|-\n| Simple\n| P2WPKH, P2WSH2, P2TR2
\n| smp\n| witness stack, consensus-encoded and base64-encoded\n|-\n| Full\n| all\n| ful\n| full to_sign transaction, consensus-encoded and base64-encoded\n|-\n| Full (Proof of Funds)\n| all\n| pof\n| full finalized PSBT of the to_sign transaction, consensus-encoded and base64-encoded\n|}\n\n1: Possible on a technical level but SHOULD NOT be used anymore in the context of this\nBIP, see section [[#legacy|Legacy]] below.
\n2: Excluding time lock scripts.\n\nSigners MUST prefix the signature with the variant that was used to create the signature.\nTo support backward compatibility with implementations of this BIP before it was finalized, a\nverifier might assume the ''simple'' variant in the absence of a prefix.\n\n=== Legacy ===\n\nNew proofs SHOULD use the new format for all invoice address formats, including P2PKH.\n\nThe legacy format MAY be used, but MUST be restricted to the legacy P2PKH invoice address format.\n\n=== Simple ===\n\nA ''simple'' signature consists of a witness stack, consensus encoded as a vector of vectors of\nbytes, and base64-encoded, prefixed by the variant (smp). Validators should construct\nto_spend and to_sign as defined below, with default values for all fields\nexcept that\n\n\n\nand then proceed as they would for a full signature.\n\n=== Full ===\n\nFull signatures follow an analogous specification to the BIP325 challenges and solutions used by\nSignet.\n\nLet there be two virtual transactions to_spend and to_sign.\n\nThe to_spend transaction is:\n\n nVersion = 0\n nLockTime = 0\n vin[0].prevout.hash = 0000...000\n vin[0].prevout.n = 0xFFFFFFFF\n vin[0].nSequence = 0\n vin[0].scriptSig = OP_0 PUSH32[ message_hash ]\n vin[0].scriptWitness = []\n vout[0].nValue = 0\n vout[0].scriptPubKey = message_challenge\n\nwhere message_hash is a BIP340-tagged hash of the message, i.e., sha256_tag(m), where\ntag = BIP0322-signed-message and m is the message as-is without length\nprefix or null terminator, and message_challenge is the (public) key script to be\nproven.\n\nThe to_sign transaction is:\n\n nVersion = 0 or (FULL format only) as appropriate (e.g., 2 for time locks)\n nLockTime = 0 or (FULL format only) as appropriate (for time locks)\n vin[0].prevout.hash = to_spend.txid\n vin[0].prevout.n = 0\n vin[0].nSequence = 0 or (FULL format only) as appropriate (for time locks)\n vin[0].scriptSig = [] or (FULL format only) as appropriate (for non segwit-native transactions)\n vin[0].scriptWitness = message_signature\n vout[0].nValue = 0\n vout[0].scriptPubKey = OP_RETURN\n\nA ''full'' signature consists of the variant-prefixed (ful) base64-encoding of the\nto_sign transaction in standard network serialisation once it has been signed.\n\n=== Full (Proof of Funds) ===\n\nThe Proof of Funds variant extends the basic scheme: in addition to signing\na message under a single address's key, the signer proves control over an arbitrary set of UTXOs.\nThis UTXO set is chosen freely by the signer and MAY be associated with the signing address\n(the message_challenge). For example, it may consist of outputs paid to that address,\nbut any UTXOs the signer wants to show control over are permitted.\nIn any case, however, the UTXO list does not aim to prove completeness (e.g., it does NOT mean:\n\"these are all UTXOs that exist for an address\"), nor that they are unspent (e.g., a validator must\nconsult the blockchain to verify that).\n\nA signer may construct a proof of funds, demonstrating control of a set of UTXOs, by constructing a\nfull signature as above, with the following modifications.\n\n\n\nA ''full Proof of Funds'' signature consists of the variant-prefixed (pof)\nbase64-encoding of the finalized PSBT once it has been signed.\n\nUnlike an ordinary signature, validators of a proof of funds need access to the current UTXO set, to\nlearn that the claimed inputs exist on the blockchain and remain unspent.\nAn offline validator therefore can only attest to the cryptographic validity of the additional\ninputs' witness stack, but not its blockchain state.\nAn attested list of UTXOs can also never prove that there do not exist more UTXOs for a certain\naddress.\n\n== Detailed Specification ==\n\nFor all signature types, except legacy, the to_spend and to_sign\ntransactions must be valid transactions which pass all consensus checks, except of course that the\noutput with prevout 000...000:FFFFFFFF does not exist.\n\n=== Verification ===\n\nA validator is given as input an address ''A'' (which may be omitted in a proof-of-funds), signature\n''s'' and message ''m'', and outputs one of three states:\n\n\n\n==== Verification Process ====\n\nValidation consists of the following steps:", "category": "bips" }, { "instruction": "What are the best practices for Basic validation?", "input": "", "output": "## Compute the transaction to_spend from ''m'' and ''A''\n## Decode ''s'' as the transaction to_sign\n## If ''s'' was a full transaction or PSBT, confirm all fields are set as specified above; in particular that\n##* to_sign has at least one input and its first input spends the output of to_spend\n##* to_sign with more than one input has an appropriate Witness UTXO or Non-Witness UTXO for each input\n##** If (based on the input type) a Non-Witness UTXO is required but not provided, check if the first input with the same transaction ID has a Non-Witness UTXO set and use that; fail validation if no such Non-Witness UTXO can be found\n##* to_sign has exactly one output, as specified above\n## Confirm that the two transactions together satisfy all consensus rules, except for to_spend's missing input, and except that ''nSequence'' of to_sign's first input and ''nLockTime'' of to_sign are not checked.", "category": "bips" }, { "instruction": "Walk me through setting up Bitcoin Operations Guide step by step", "input": "", "output": "# (Optional) If the validator does not have a full script interpreter, it should check that it understands all scripts being satisfied. If not, it should stop here and output ''inconclusive''.", "category": "bips" }, { "instruction": "What commands would you run to work with Check the '''required rules''':?", "input": "", "output": "## All signatures MUST use the SIGHASH_ALL flag, unless the output type supports SIGHASH_DEFAULT, which then MAY be used alternatively (e.g., [[bip-0341.mediawiki|BIP341 P2TR]]).\n## The use of CODESEPARATOR or FindAndDelete is forbidden.\n## LOW_S, STRICTENC and NULLFAIL: valid ECDSA signatures must be strictly DER-encoded and have a low-S value; invalid ECDSA signature must be the empty push\n## MINIMALDATA: all pushes must be minimally encoded\n## CLEANSTACK: require that only a single stack element remains after evaluation\n## MINIMALIF: the argument of IF/NOTIF must be exactly 0x01 or empty push\n## If any of the above steps failed, the validator should stop and output the ''invalid'' state.", "category": "bips" }, { "instruction": "I want to understand Check the '''upgradeable rules''' from a technical perspective", "input": "", "output": "## The version of to_sign must be 0 or 2.\n## The use of NOPs reserved for upgrades is forbidden.\n## The use of Segwit versions greater than 1 is forbidden.\n## If any of the above steps failed, the validator should stop and output the ''inconclusive'' state.", "category": "bips" }, { "instruction": "Can you explain Let ''T'' be the nLockTime of to_sign and ''S'' be the nSequence of the first input of to_sign. Output the state ''valid at time T and age S''. like we're having a beer and talking Bitcoin?", "input": "", "output": "=== Signing ===\n\nSigners who control an address ''A'' who wish to sign a message ''m'' act as follows:\n\n
    \n
  1. \n They construct to_spend and to_sign as specified above, using the\n scriptPubKey of ''A'' for message_challenge and tagged hash of ''m'' as\n message_hash.\n
    2. \n
  2. \n Optionally, they may set nVersion/nLockTime of to_sign or nSequence of its first\n input.\n
    3. \n
  3. \n Optionally, they may add any additional inputs to to_sign that they wish to prove\n control of.\n
    4. \n
  4. \n They satisfy to_sign as they would any other transaction.\n
    5. \n
\n\nThey then encode their signature, choosing either ''simple'', ''full'' or ''full-pof'' as follows:\n\n\n\n=== PSBT-based signing ===\n\nA valid witness stack for a multisig address must be constructed by coordinating different signers\nto produce a partial signature each.\nThe coordination procedure is not specified by this BIP, but due to the use of PSBTs it should\nclosely resemble the coordination of signing a multisig transaction for publishing to the network.\n\nThe main difference is a new global PSBT field and the way a signer presents the transaction signing\nrequest to the user. The new global type is defined as follows:\n\n{| class=\"wikitable\"\n! Name\n! \n! \n! Description\n! \n! Description\n! Versions Requiring Inclusion\n! Versions Requiring Exclusion\n! Versions Allowing Inclusion\n|-\n| Generic Signed Message\n| PSBT_GLOBAL_GENERIC_SIGNED_MESSAGE = 0x09\n| None\n| No key data\n| \n| The UTF-8 encoded message to be signed.\n|\n|\n| 0, 2\n|}\n\n=== PSBT creator ===\n\nThe '''transaction creator''' of a BIP322 PSBT must follow these steps:\n\n
    \n
  1. \n They construct to_spend and to_sign as specified above, using the\n scriptPubKey of ''A'' for message_challenge and tagged hash of ''m'' as\n message_hash.\n
    2. \n
  2. \n Optionally, they may set nVersion/nLockTime of to_sign or nSequence of its first\n input.\n
    3. \n
  3. \n Optionally, they may add any additional inputs to to_sign that they wish to prove\n control of.\n
    4. \n
  4. \n They set the appropriate witness_utxo and non_witness_utxo fields of the\n first input, using the to_spend transaction as a non_witness_utxo or\n the first output of the to_spend transaction as witness_utxo.\n
    5. \n
  5. \n They set the appropriate witness_utxo and non_witness_utxo fields of\n each additional input.\n
    6. \n
  6. \n They set the appropriate PSBT input and global fields as required by the signers(s) to produce a\n partial signature.\n
    7. \n
  7. \n They set the PSBT_GLOBAL_GENERIC_SIGNED_MESSAGE field, using the full UTF-8-encoded\n message as the valuedata.\n
      \n
    1. \n There is no specified maximum length of an input's valuedata or a PSBT as a whole in\n [[bip-0174.mediawiki|BIP174]], but different signers might impose safety limits. It is\n recommended to use a maximum length of a few kilobytes to maximize compatibility. Very large\n messages should be committed to by hash instead.\n
      2. \n
    \n
    8. \n
\n\n=== PSBT signer ===\n\nA '''transaction signer''' of a BIP322 PSBT must follow these steps:\n\n
    \n
  1. \n They decode the base64-encoded PSBT as specified in [[bip-0174.mediawiki|BIP174]].\n
    2. \n
  2. \n If they detect the following properties (all must be true, otherwise this is NOT a BIP322 PSBT\n and they should treat it as an ordinary PSBT):\n
      \n
    1. \n The PSBT has the PSBT_GLOBAL_GENERIC_SIGNED_MESSAGE field set. Extract and use as\n message in the next steps.\n
      2. \n
    2. \n The first PSBT input has either a witness_utxo or a non_witness_utxo\n field set and the scriptPubKey can be extracted. Use that as\n message_challenge in the next steps.\n
      3. \n
    3. \n The first PSBT input has prevout.n = 0.\n
      4. \n
    4. \n The first PSBT input has prevout.hash = to_spend.txid where\n to_spend.txid is constructed using the rules described above using the\n message and message_challenge from the previous steps.\n
      5. \n
    5. \n The PSBT's unsigned transaction has a single output with a value of 0 and the\n scriptPubKey set to OP_RETURN (0x6a).\n
      6. \n
    \n
    3. \n
  3. \n If all of the above steps are true, the signer must inform the user about the message they are\n signing and the address they are signing for.\n
      \n
    1. \n Even though the message being signed is a transaction, the user interaction (e.g., the steps and\n messages shown on a hardware signing device's screen) should resemble the steps to sign a legacy\n message, not the steps for signing a transaction.\n
      2. \n
    2. \n Example: Instead of showing \"spending 0 satoshi from address <challenge_address>\" the\n device should show \"signing message <message> for address <challenge_address>\".\n
      3. \n
    \n
    4. \n
  4. \n Upon user approval, the signer adds a partial signature for each input it is capable of signing.\n
    5. \n
\n\n=== PSBT finalizer ===\n\nA '''transaction finalizer''' of a BIP322 PSBT must follow these steps:\n\n
    \n
  1. \n They decode the base64-encoded PSBT as specified in [[bip-0174.mediawiki|BIP174]].\n
    2. \n
  2. \n They finalize the PSBT as specified in [[bip-0174.mediawiki#input-finalizer|BIP174]].\n
    3. \n
  3. \n They then encode the signature following the same steps as described in [[#signing|Signing]]\n above.\n
    4. \n
\n\n== Compatibility ==\n\nThis specification is backwards-compatible with the legacy signmessage/verifymessage specification\nthrough the special case [[#legacy|as described above]].\nTo support backward compatibility with implementations of this BIP before it was finalized, a\nverifier might assume the ''simple'' variant in the absence of a prefix.\n\n== Reference implementation ==\n\n\n\n== Acknowledgements ==\n\nThanks to David Harding, Jim Posen, Kalle Rosenbaum, Pieter Wuille, Andrew Poelstra, Luke Dashjr,\nand many others for their feedback on the specification.\n\n== References ==\n\n
    \n
  1. \n Original mailing list thread:\n https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-March/015818.html\n
    2. \n
\n\n== Changelog ==\n\n* '''1.0.0''' (2026-04-15):\n** Mark Complete\n** Breaking change: Add human-readable prefix to encoded signature\n** Breaking change: format of \"Proof of Funds\" signatures to be base64-encoded finalized PSBT\n** Add new PSBT global field for PSBT-based signing\n* '''0.0.1''' (2018-09-10):\n** Proposed as draft\n\n== Copyright ==\n\nThis document is licensed under the Creative Commons CC0 1.0 Universal license.\n\n== Test vectors ==\n\nBasic test vectors for message hashing, transaction hashes and \"simple\" variant test cases can be\nfound in [[bip-0322/basic-test-vectors.json|basic-test-vectors.json]].\n\nGenerated test vectors for more \"simple\" and \"full\" variant test cases can be found in\n[[bip-0322/generated-test-vectors.json|generated-test-vectors.json]].\n\nThey were generated using [https://github.com/btcsuite/btcd/pull/2521 this code].", "category": "bips" }, { "instruction": "How would you explain 
 to someone who knows Bitcoin basics?",
    "input": "",
    "output": "BIP: 178\n  Layer: Applications\n  Title: Version Extended WIF\n  Authors: Karl-Johan Alm \n  Comments-Summary: Discouraged for implementation (one person)\n  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0178\n  Status: Draft\n  Type: Specification\n  Assigned: 2018-04-04\n  License: CC0-1.0\n
\n\n== Abstract ==\n\nAn extension to the Wallet Import Format (WIF) to specify what kind of bitcoin address the private key corresponds to.\n\n== Motivation ==\n\nThere are several types of bitcoin addresses which can all be associated with a given private key: P2PKH (legacy 1... format), P2SH-P2WPKH (SegWit public key inside P2SH), P2WPKH (bech32), etc.\n\nWhile private keys have a 1-byte suffix indicating whether the corresponding public key is compressed (0x01) or not (through suffix absence), there is no way of knowing what kind of bitcoin address were associated with the private key. As a result, when importing a private key, the wallet has to assume all kinds, and keep track of each possible alternative.\n\nBy extending the suffix, we can specify what kind of bitcoin address was associated with a given private key.\n\n== Specification ==\n\nCurrently, private keys are stored as a uint256 (private key data) followed by an optional uint8 (compressed flag). The latter is extended to specify the address types:\n\n{|class=\"wikitable\" style=\"text-align: center;\"\n|-\n!Value\n!Type\n!Compr\n!Clarification\n|-\n|No suffix||P2PKH_UNCOMPRESSED||No||Uncompressed legacy public key. Unknown public key format\n|-\n|0x01||P2PKH_COMPRESSED||Yes||Compressed legacy public key. Unknown public key format\n|-\n|0x10||P2PKH||Yes||Compressed legacy public key. Legacy public key format (1...)\n|-\n|0x11||P2WPKH||Yes||Bech32 format (native Segwit)\n|-\n|0x12||P2WPKH_P2SH||Yes||Segwit nested in BIP16 P2SH (3...)\n|}\n\nWhen a wallet imports a private key, it will have two outcomes:\n\n* the key is using one of the legacy types, in which case all types must be accounted for\n* the key is using one of the extended types, in which case the wallet need only track the specific corresponding address\n\nNote: the difference between `0x01` and `0x10` is that the former can correspond to any of the types above, whereas the latter *only* corresponds to a P2PKH (legacy non-segwit).\n\n== Compatibility ==\n\nThis proposal is not backwards compatible, in that software that does not recognize the new types will not understand the compressed flag. It would be trivial to change this, by keeping the 'uncompressed' state as it is (no suffix) and changing 'compressed' to be 'anything not 0', as opposed to 'the value 1'.\n\nThe proposal ''is'' backwards compatible in that new wallet software will always understand the old WIF format, however. It will, as it does today, assume that any kind of bitcoin address is possible, and will have to track all of them, as it has to today.\n\n== Acknowledgements ==\n\nThis BIP is based on the initial proposal by Thomas Voegtlin (thomasv at electrum dot org) on the Bitcoin Dev mailing listhttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-September/015007.html and the Electrum 3.0 implementationhttps://github.com/spesmilo/electrum/blob/82e88cb89df35288b80dfdbe071da74247351251/RELEASE-NOTES#L95-L108\n\n== Reference implementation ==\n\nThere is a partial implementation which adds, but does not use, the types described in this BIP here: https://github.com/bitcoin/bitcoin/pull/12869\n\n== References ==\n\n\n\n== Copyright ==\n\nThis document is licensed under the Creative Commons CC0 1.0 Universal license.", "category": "bips" }, { "instruction": "I'm trying to understand 
 - can you walk me through it?",
    "input": "",
    "output": "BIP: 110\n  Layer: Consensus (soft fork)\n  Title: Reduced Data Temporary Softfork\n  Authors: Dathon Ohm \n  Status: Draft\n  Type: Specification\n  Assigned: 2025-12-03\n  License: BSD-3-Clause\n  Discussion: https://groups.google.com/g/bitcoindev/c/nOZim6FbuF8\n
\n\n==Abstract==\n\nTemporarily limit the size of data fields at the consensus level, in order to correct distorted incentives caused by standardizing support for arbitrary data, and to refocus priorities on improving Bitcoin as money.\n\n==Copyright==\n\nThis document is licensed under the 3-clause BSD license.\n\n==Specification==\n\nBlocks during a temporary, one-year deployment are checked with these additional rules:", "category": "bips" }, { "instruction": "Hey, I need to set up Bitcoin Operations Guide - what's the command line way to do that?", "input": "", "output": "# New output scriptPubKeys exceeding 34 bytes are invalid, unless the first opcode is OP_RETURN, in which case up to 83 bytes are valid.", "category": "bips" }, { "instruction": "What's the deal with Bitcoin Operations Guide in Bitcoin? Explain it like I'm a friend.", "input": "", "output": "# OP_PUSHDATA* payloads and [[#script-argument-witness-items|script argument witness items]] exceeding 256 bytes are invalid, except for the redeemScript push in BIP16 scriptSigs.", "category": "bips" }, { "instruction": "Can you show me the CLI commands for Bitcoin Operations Guide?", "input": "", "output": "# Spending undefined witness (or Tapleaf) versions (ie, not Witness v0/BIP 141, Taproot/BIP 341, or P2A) is invalid. (Creating outputs with undefined witness versions is still valid.)", "category": "bips" }, { "instruction": "I'm stuck with Tapscripts executing the OP_IF or OP_NOTIF instruction (regardless of result) are invalid. - what should I check?", "input": "", "output": "Inputs spending UTXOs that were created before the activation height are exempt from the new rules.\nOnce the softfork expires, UTXOs of all heights are once again unrestricted.\n\n===GetBlockTemplate===\n\nThis deployment uses the GBT deployment name \"reduced_data\" as defined in [[bip-0009.mediawiki#getblocktemplate_changes|BIP 9]]. During mandatory signaling, the deployment's bit is included in \"vbrequired\".\n\n==Motivation==\n\nIn order to protect Bitcoin's intended function as the Internet's native money, the Bitcoin community has historically treated techniques for embedding arbitrary data into Bitcoin transactions with antagonism.\n\nSuch data embedding must be resisted at all times in order to ensure it doesn't become load-bearing and start to produce negative externalities, especially for node operators.\n\nStarting with the \"inscription\" hack first exploited in 2022, a trend has emerged around embedding arbitrary data into Bitcoin transactions, creating significant unnecessary burdens on node operators and diverting development focus and incentives away from Bitcoin's fundamental purpose of being sound, permissionless, borderless money.\n\nThis BIP aims to set Bitcoin back on the path to becoming the world's money by rejecting the standardization of data storage as a supported use case at the consensus level.\n\nIt achieves this by temporarily invalidating several of the most harmful methods of data abuse by consensus, while preserving all known monetary use cases.\n\nSpecifically, this proposal invalidates all methods of embedding contiguous arbitrary data larger than 256 bytes; it also invalidates large scriptPubKey and Tapleaf formats that are abused almost exclusively for data embedding; and finally, it restores, in consensus, the long-established 83-byte policy limit on OP_RETURN outputs.\n\nIn software development, it is a common practice to disable unsupported use cases, because not doing so quickly becomes unsustainable and causes development to grind to a standstill.\n\nActivation of these new rules thus sends a clear message that arbitrary data storage will continue to be actively resisted, and that such unsupported usage should not be permitted to derail network priorities.\n\nIt also reinforces Bitcoin's core function as a censorship-resistant payment system, because data storage competes unfairly with payments, making Bitcoin payments unnecessarily costly. This encourages reliance on third-party payment processors, making Bitcoin payments easier to censor.\n\nFinally, it improves decentralization of the node network by re-establishing the long-held commitment towards minimizing the cost (financial or otherwise) of operating a node.\n\nBitcoin should \"do one thing, and do it well\". By rejecting data storage, this BIP liberates Bitcoin developers from endless scope creep, enabling them to focus on what's really important: Bitcoin's success as money.\n\n==Rationale==\n\n===Specification nuance===\n\n'''Why limit scriptPubKeys to 34 bytes?'''\n\nUnspent scriptPubKeys (OP_RETURN excepted) must be stored indefinitely in the UTXO set, which nodes must store on fast media and cannot prune.\nFast storage (usually RAM) is much more costly per byte than slower, non-volatile storage, so as the UTXO set size increases, the burden on node operators increases, harming decentralization.\nThey are also a direct cost to the sender rather than the receiver.\nFor these reasons, modern usage is all 34 bytes or smaller in practice; actual spending conditions have been moved to the witness, and the scriptPubKey simply commits to them in advance with a hash.\nFurthermore, large scriptPubKeys, in addition to being a data embedding vector, can be abused to create malicious transactions and blocks (\"poison blocks\") that take a long time to validate.\nLarge scriptPubKeys, thus carrying a large abuse potential and no benefit, are invalidated by this BIP.\n\n'''What about OP_RETURN? Why not get rid of it entirely?'''\n\nOP_RETURN outputs are provably unspendable, and nodes do not need to store them in the UTXO set.\nHistorically, up to 83 bytes have been tolerated only to avoid unprovably unspendable spam in other output scripts, and with the possible exception of commitment schemes that use OP_RETURN in coinbase transaction outputs (notably Segwit), using OP_RETURN is not the optimal solution to any known use case.\nWith the advent of pay-to-contract and Taproot, it is now also possible to commit to external data in the Taptree, making even hypothetical use of OP_RETURN deprecated.\nHowever, to avoid breaking legacy protocols that still include such outputs, this proposal allows these outputs.\n\n'''Why limit other data to 256/257 bytes?'''\n\nWith modern compression, it is plausible to represent images in as few as 300-400 bytes. Images are likely the most harmful use case for data storage, as they have huge demand and supporting them can engender high fees and UTXO-set bloat, as well as content that a large majority of node operators might object to.\n\n256 bytes (2048 bits) is also more than sufficient for reasonably large numbers that might be potentially needed in legitimate cryptography, reinforcing Bitcoin's intended purpose as a monetary network.\n\n'''Won't spammers just spread their data over multiple fields?'''\n\nWhile it is impossible to fully prevent steganography, limiting data sizes ensures such abuses are non-contiguous and obfuscated within another intended meaning (script code, structure, etc).\nAs far as Bitcoin is concerned, the data has some meaning other than the spammers' misinterpretation, and any external code to \"reassemble\" the unintended data is responsible for producing it\n(it is possible to write code that transforms *any* data into any other data - what matters is that Bitcoin has a well-defined meaning that is distinct from the unsupported one).\nRequiring users to divide their files into chunks of at most 256 bytes, raising the cost both in fees and in effort, sends a clear message that data storage abuses in general are unwelcome rather than sanctioned or supported.\n\n\n'''What are \"script argument witness items\", referred to in rule 2?'''\n\nScript argument witness items are the witness stack elements that are placed on the script interpreter's stack as inputs before the script is executed - the witness equivalent of data pushes in scriptSigs.\n\nThe following witness stack elements are '''not''' script argument witness items, and are thus excluded from rule 2 (though some are limited/invalidated by other rules):\n\n* Some items are part of a spend that invokes the script interpreter, but are popped from the witness stack before the remaining elements are passed to it as inputs:\n** Witness scripts and Tapleaf scripts (not limited)\n** Control blocks (limited by rule 5)\n** Annexes (invalidated by rule 4)\n* Others are not part of a script-path spend at all, so the script interpreter is not invoked:\n** Taproot key path signatures (limited to exactly 64 or 65 bytes by BIP 341 signature validation)\n** Witness stacks in spends of undefined witness versions (invalidated by rule 3)\n\nAll '''other''' witness stack elements are script argument witness items, and are thus limited to 256 bytes by rule 2.\n\n'''Why are BIP16 redeemScripts, witness scripts, and Tapleaf scripts exempt from rule 2?'''\n\nBIP16 redeemScripts, witness scripts, and Tapleaf scripts are scripts, not data. Their contents are subject to the same OP_PUSHDATA* restrictions during execution.\nRestricting them is not only unnecessary, but would reduce the ability to make use of the intended script capabilities, and could impact legitimate real-world usage.\n\n'''Why make spending undefined witness/Tapleaf versions invalid?'''\n\nSince they are undefined, witness stacks spending these versions are completely unlimited currently to allow maximum flexibility in future upgrades.\nAny future upgrade, however, would need more than a year of coordination, so this softfork will not actually restrict it, and only safeguards against abuse in the meantime.\n\n'''Why not make it invalid to send to undefined witness versions?'''\n\nThis would require the senders of transactions to check the witness version prior to sending, and require additional coordination when a new witness version is intended to become used.\n\n'''Why not allow spending undefined witness versions with an empty witness?'''\n\nThis has no use case, but would require nodes to track these UTXOs in case of potential spending.\nBy making spending invalid, it is possible for nodes to store them instead in slow memory not needed until this softfork expires.\n(With proper planning, it also makes it possible for a future softfork making use of these witness versions to allow users to receive with an upgraded wallet even prior to activation of the upgrade.)\n\n'''Why make the Taproot annex invalid?'''\n\nThe annex is currently undefined data with unlimited size.\nIt exists for future upgrades, but has no legitimate usage today.\nAny future upgrade, however, would need more than a year of coordination, so this softfork will not actually restrict it, and only safeguards against abuse in the meantime.\n\n'''Why is the Taproot control block limited to 257 bytes instead of 256?'''\n\nThe control block is a series of hashes proving the Tapscript is part of the Taptree, plus a single byte with the leaf version and parity bit.\nSee BIP 341 for details.\n\n'''Why make OP_SUCCESS* invalid?'''\n\nOP_SUCCESS* is meant for future upgrades. See above regarding undefined witness versions.\n\n'''Why make OP_IF/OP_NOTIF invalid?'''\n\nOP_IF/OP_NOTIF originated in pre-Taproot Bitcoin script language as a way to execute different subscripts based on a condition.\nWith Taproot, the conditions can instead be evaluated off-chain, revealing only the intended verification execution path.\nFurthermore, when the conditions are met, the intent is that the keypath spend path should be used instead, avoiding publishing any scripts at all.\n\nOP_IF is not only redundant for Tapscript, it is also commonly abused today to inject spam that gets skipped at execution.\nWhile it is impossible to fully prevent steganography, closing this gap eliminates one common abuse today basically for free, and sends a message that such abuses are not welcome.\nThere are some potential experimental use cases for OP_IF in Tapscript. See the Tradeoffs section for more details.\n\n'''Why is the proposal so simple?'''\n\nA more complicated proposal could be envisioned that better balances innovation with safety, but implementing this properly would require extensive refactoring and review, delaying deployment when the change is already urgent.\nThe rules proposed herein have been intentionally kept very simple to minimise review time and avoid unnecessary risks of overlooking unexpected side effects.\n\n'''Why is this softfork temporary?'''\n\nThe impact of these restrictions would severely constrain future upgrades, potentially forcing them to be designed as a hardfork instead of a softfork.\nSome restrictions are also not ideal, but an improved limit would be more complicated to develop and test -\nby deploying these simpler restrictions now, we avoid making the perfect the enemy of the good enough, while still allowing for upgrading the limits to better variants in the future.\n\nOver the next year, interested developers can implement and propose a longer-term solution to address the needs of the protocol without the tradeoffs or blunt/simplified changes.\n\n===Tradeoffs===\n\n'''Are there any tradeoffs?'''\n\nYes:", "category": "bips" }, { "instruction": "How do I troubleshoot Bitcoin Operations Guide issues?", "input": "", "output": "# Limiting Taproot control blocks to 257 bytes directly constrains the size of the on-chain, consensus-enforced script tree. This could complicate or possibly even impede advanced smart contracting like BitVM, which relies on a large number of executable scripts. In the worst case scenario, these use cases may just need to wait until this softfork expires. As they are still in early development, testnet and sidechains should be sufficient for the next year while a more scalable rule is implemented.", "category": "bips" }, { "instruction": "What are the best practices for Bitcoin Operations Guide?", "input": "", "output": "# Upgrade hooks are not available for other softforks. As softforks adding new opcodes typically need at least a year to activate, this shouldn't be a practical issue.", "category": "bips" }, { "instruction": "Walk me through setting up Some wallet software such as Miniscript habitually creates Tapleaves containing OP_IF. To mitigate the risk of these funds being frozen for a year, this proposal exempts inputs that spend outputs that were created before activation, and provides a two-week grace period between lock-in and activation, to give users time to prepare. step by step", "input": "", "output": "'''Isn't the limit on Taproot control blocks too restrictive?'''\n\nPossibly.\nThe previous limit allows for 340,282,366,920,938,463,463,374,607,431,768,211,456 scripts, which is obviously way more than anyone could ever need.\n257 bytes allows for 128 scripts, which is sufficient for modern and complex transactions.\nHowever, it may prove too limiting for advanced off-chain functionality such as used by BitVM.\nThis is an unfortunate tradeoff that (if this softfork is accepted) we have chosen to accept in the short-term for the immediate benefits of this softfork.\nThe intent is to relax this restriction later, when this softfork expires, with a new approach allowing larger trees, yet to be developed.\n\nDo note that non-script (or non-Bitcoin-L1 scripts) usage of the taptree does not have this same limitation:\njust a single of the 128 leaves could very well be an extension of the merkle tree to greater depths than enforced by this softfork.\n\n'''Aren't Taptrees intended to be unbalanced?'''\n\nWhile it is true that optimal use of Taptrees may often be unbalanced to favour more-likely-executed scripts, this is optional, and the full capacity (in this case, 128 scripts) can still be used if needed.\nAdditionally, in ideal/ordinary circumstances, neither the Taptree nor a merkle branch through it is ever published:\nall counterparties ought to evaluate the conditions for spending off-chain and rebroadcast the transaction using the keypath spending.\nTapscripts are designed to be used when one or more parties is unreachable or uncooperative; their existence mainly only serves to deter intentional non-cooperation by making it pointless.\nAn exception to this is protocols employing a NUMS point to restrict an output to only being spendable via the script path.\n\n'''Is there any risk of funds being frozen or lost?'''\n\nIn theory, yes. This proposal goes to great pains to make sure it does not affect any known use cases, and it is reasonably certain that no one will be affected. However, there are a couple of experimental use cases involving pre-signed Taproot transactions that could end up being affected.\n\nSpecifically:\n\n* The restriction on OP_IF/OP_NOTIF could temporarily invalidate some edge-case Tapleaves produced by the current version of the Miniscript compiler. There are no verified uses of these constructions currently in production, but there are some popular wallets that could, in theory, produce them.\n* The restriction on Taptree depth will invalidate any Tapleaves deeper than 7 levels. Since Taptrees are usually designed with the more common spending conditions positioned higher in the tree, any funds encumbered by such a Taptree will almost certainly be easily spendable by Tapleaves higher up in the tree.\n\nIn both scenarios, funds are spendable either by other Tapleaves in the tree, or by the keypath (unless the keypath is provably invalidated using a NUMS point).\n\nFunds in either scenario could end up being frozen or lost ''only'' if ''all'' of the following conditions are met:\n\n* The UTXO is pay-to-Taproot (P2TR);\n* The UTXO is in a pre-signed transaction;\n* The UTXO being spent ''must'' be confirmed ''and'' spent during the temporary, one-year deployment of these new rules;\n* The Tapleaf the user selects to spend the UTXO contains an OP_IF/OP_NOTIF or exists at a depth greater than 7;\n* The keypath is unusable to spend the funds, AND there are no other suitable Tapleaves in the tree to spend the UTXO (in which case funds are frozen), OR there are other Tapleaves that ''can'' spend the UTXO in unexpected ways (in which case funds are lost).\n\nIn other words, funds are completely unaffected if:\n\n* They do not use Taproot;\n* They use Taproot in standard and well-supported ways;\n* UTXOs needed during the temporary deployment are confirmed before the fork activates;\n* UTXOs in pre-signed transactions do not lock funds using Tapleaves that violate the new rules;\n* UTXOs in pre-signed transactions that lock funds using Tapleaves that violate the new rules do not need to be confirmed ''and'' spent during the deployment;\n* UTXOs in pre-signed transactions that lock funds using Tapleaves that violate the new rules and need to be confirmed ''and'' spent during the deployment can be spent either via the keypath OR by other, expected Tapleaves in the tree.\n\nThis proposal does everything possible to try to avoid funds being frozen or lost, but ultimately it is impossible to prove that absolutely no one will be affected.\nIt is therefore up to the Bitcoin community to activate these new rules only if they feel that rejecting data storage is worth this tradeoff.\nTo prepare for activation, it is recommended that users begin migrating any affected funds now.\nIn the event that these new rules are activated, there will be at least a two-week period between lock-in and activation, during which all users will have the chance to migrate any remaining funds.\n\n\n===Alternatives / Alsos===\n'''Why not let the fee market manage data storage?'''\n\nThe fee market is designed to prioritize transactions based on economic urgency.\n\nHowever, the market for data storage on the blockchain is a completely different market from the market for payments, with completely different incentives.\n\nSpecifically, the fee for a monetary transaction incentivises a miner to include the transaction in a block, representing a one-time transfer of monetary value, i.e., a payment. The miner thus provides the one-time service of securing a payment, for a one-time fee.\n\nOnce the payment is secured, the payor does not receive any additional benefit from the Bitcoin network, besides the integrity of Bitcoin's transaction history (a service to which all node operators are happy to contribute, because Bitcoin would not function as money otherwise).\n\nConversely, the fee for a data storage transaction still goes only to the miner who includes the data in a block, but the burden of storing the data falls on all node operators, who never received even a part of the fee, yet are forced to continue downloading, storing, and serving the data forever.\n\nIn this case, the miner accepts a one-time fee, and in exchange, the priceless service of highly-available, uncensorable data storage is provided in perpetuity ''for free'' by node operators.\n\nThe problem becomes even worse when the data is objectionable to node operators, as this represents an even larger, unexpected cost for them.\n\n'''How about OP_RETURN2/\"blobspace\" making the data optional for nodes?'''\n\nThis has been attempted multiple times in the past.\nThere is perhaps no harm in trying yet again, and this proposal does not prevent doing so,\nbut ultimately these schemes depend on the cooperation of the sender, who usually wants to explicitly force the content on non-consenting node operators\n(or they would be using other existing distribution methods already).\nThese other ideas also do not solve the problem of objectionable content.\n\n'''Why not ban PUSHDATA opcodes/Eliminate the witness discount/Apply a length limit to the Annex rather than eliminating it/Add limits to overall witness or transaction sizes/Make the softfork permanent instead of temporary/Remove the witness discount/Make OP_RETURN cheaper?'''\n\nThese are all interesting ideas, but they all increase the complexity of the implementation, and this proposal was optimized to be simple and easy to review for fast deployment. If the community decides to do any of these things, this proposal encourages them to do so once it expires.\n\n'''Why not eliminate one or more of the restrictions?'''\n\nThis proposal, as is, represents the strongest possible rejection of the arbitrary data storage use case, while minimizing complexity. Loosening any of the rules would make it less effective at achieving this objective, for not much benefit.\n\n'''Shouldn't spam be fought in policy? Does this proposal affirm that policy is ineffective?'''\n\nIt remains true that policy is still the best place to fight spam.\nHowever, it is also true that policy cannot guarantee 100% effectiveness, particularly against bad actors who are mining.\nThis softfork minimises the impact of such malicious miners, closing the worst-case risks.\n\n'''Does this proposal solve spam completely?'''\n\nNo.\nIt is impossible to solve spam completely, and typically spam is best fought with policy/filters, not consensus.\nWhat this softfork does is require users wanting to store large unencrypted files in the blockchain to disguise the data as financial data and/or break it up into multiple data pushes. Obviously doing so is considered an abuse of bitcoin and should be avoided, but if it does happen, this BIP strengthens the argument that data storage is not a supported use case.\n\n'''Why doesn't this proposal address non-Bitcoin tokens?'''\n\nThere are a wide variety of non-Bitcoin tokens, mostly scams, that a significant portion of the community considers spam.\nHowever, these schemes are best countered in policy rather than consensus, and besides, this proposal does not aim to eliminate spam entirely.\n\n'''Is this a slippery slope? If we make rules against data today, will we start banning use cases we don't like tomorrow?'''\n\nNo.\nThese rules may be new at the consensus level, but they are merely enshrining long-standing principles of Bitcoin, as necessary to address a threat to the decentralization of the network and its usability for monetary purposes.\n\nThis softfork does not attempt to impose restrictions on monetary activity or the validity of monetary transactions themselves.\nBy restricting the data storage use case as much as possible, this proposal reinforces Bitcoin's guarantee of sound, permissionless money for the long-term.\nThis clear distinction between mitigating a systemic risk from non-monetary data abuse and interfering with actual monetary use cases provides a strong barrier against future overreach.\n\nThe explicitly temporary nature of the softfork further reinforces that this is a targeted intervention to mitigate a specific crisis, not a commitment or proposal of a new direction of development.\nIf no further action is taken by you, it will expire in a year.\nEven if a followup softfork is proposed for that time, you retain the right to reject it.\n\n'''Doesn't this proposal break user space?'''\nYes, this proposal intentionally breaks user space, specifically the data storage user space. This is necessary in order to communicate that data storage is not supported.\nPains have been taken to avoid breaking monetary use cases, and it is unlikely that any such use cases have been affected, but in theory they might be. See the Tradeoffs section for more details.\n\n==Backwards compatibility==\n\nThere are a couple of very unlikely scenarios in which funds could theoretically be frozen or lost. See the Tradeoffs section for more details.\n\nIf this proposal activates, the Miniscript compiler will need to be modified not to produce scripts that violate the new rules, at least while the new rules are active.\n\nUsers storing arbitrary data in the Bitcoin blockchain should start looking for other places to store their data, such as Nostr, IPFS, BitTorrent, cloud storage, etc, as the Bitcoin network will not support this use case going forward.\n\nAll other known use cases are not affected.\n\n==Reference implementation==\n\nhttps://github.com/bitcoinknots/bitcoin/compare/29.x-knots...dathonohm:bitcoin:uasf-modified-bip9\n\n==Deployment==\n\nThis deployment uses a modified version of BIP9 with the following parameters:\n\n* '''name''': reduced_data\n* '''bit''': 4\n* '''starttime''': 1764547200 (~December 1, 2025)\n* '''timeout''': NO_TIMEOUT\n* '''min_activation_height''': 0\n* '''max_activation_height''': 965664 (~September 1, 2026)\n* '''active_duration''': 52416 blocks (~1 year after activation)\n* '''threshold''': 1109/2016 (55%)\n\n===Deviations from BIP9===\n\nThis deployment deviates from standard BIP9 in five ways:\n\n'''Reduced threshold (55% instead of 95%)''': The standard BIP9 threshold of 95% is designed for permanent consensus changes where near-universal miner readiness is desirable. Since rejecting data storage is a matter of urgency, and since this softfork is temporary and expires after one year, a lower threshold is ideal.\n\n'''No timeout, using max_activation_height instead''': Standard BIP9 uses a time-based timeout that transitions to FAILED if the threshold is not reached. This deployment sets timeout to NO_TIMEOUT and instead uses a BIP8-like, height-based max_activation_height. The deployment transitions to LOCKED_IN at height 963648 (one retarget period before max_activation_height), then to ACTIVE at height 965664.\n\n'''Mandatory signaling period''': Similar to BIP8, this deployment enforces mandatory signaling during the retarget period immediately before mandatory lock-in (blocks 961632 to 963647; lock-in happens no later than block 963648). During this window, blocks that do not signal bit 4 are rejected as invalid. Mandatory signaling ends once the deployment reaches the LOCKED_IN state.\n\n'''Expiry via active_duration''': Standard BIP9 deployments are permanent once ACTIVE. This proposal includes an active_duration of 52416 blocks (~1 year), making the deployment temporary rather than permanent. After active_duration blocks, the state machine transitions from ACTIVE to EXPIRED, a new terminal state. Once EXPIRED, the rules cease to be enforced and UTXOs are once again unrestricted.\n\n'''State transitions''': The state machine follows this progression:", "category": "bips" }, { "instruction": "What commands would you run to work with Bitcoin Operations Guide?", "input": "", "output": "# LOCKED_IN: Entered at the start of the first retarget period where the threshold was reached in the previous period; mandatory signaling (blocks 961632-963647) ensures this happens no later than height 963648", "category": "bips" }, { "instruction": "I want to understand EXPIRED: Entered when block height >= activation_height + active_duration; rules no longer enforced (terminal state) from a technical perspective", "input": "", "output": "The FAILED state is never reached because timeout is disabled. EXPIRED is the final state; there are no transitions after it. Miner signaling after expiry has no effect because the deployment is no longer in the STARTED state, and miner signaling only governs the STARTED -> LOCKED_IN transition.\n\n==Credits==\n\nOriginal draft and advice: Luke-Jr", "category": "bips" }, { "instruction": "Can you explain 
 like we're having a beer and talking Bitcoin?",
    "input": "",
    "output": "BIP: 117\n  Layer: Consensus (soft fork)\n  Title: Tail Call Execution Semantics\n  Authors: Mark Friedenbach \n           Kalle Alm \n           BtcDrak \n  Status: Draft\n  Type: Specification\n  Assigned: 2017-08-25\n  License: CC-BY-SA-4.0\n  License-Code: MIT\n
\n\n==Abstract==\n\nBIP16 (Pay to Script Hash)[1] and BIP141 (Segregated Witness)[2] provide mechanisms by which script policy can be revealed at spend time as part of the execution witness.\nIn both cases only a single script can be committed to by the construct.\nWhile useful for achieving the goals of these proposals, they still require that all policies be specified within the confine of a single script, regardless of whether the policies are needed at the time of spend.\n\nThis BIP, in conjunction with BIP116 (MERKLEBRANCHVERIFY)[3] allows for a script to commit to a practically unbounded number of code pathways, and then reveal the actual code pathway used at spend time.\nThis achieves a form of generalized MAST[4] enabling decomposition of complex branching scripts into a set of non-branching flat execution pathways, committing to the entire set of possible pathways, and then revealing only the path used at spend time.\n\n==Copyright==\n\nThis BIP is licensed under a Creative Commons Attribution-ShareAlike license. All provided source code is licensed under the MIT license.\n\n==Specification==\n\nIf, at the end of script execution:\n\n* the execution state is non-clean, meaning\n*# the main stack has more than one item on it, or\n*# the main stack has exactly one item and the alt-stack is not empty;\n* the top-most element of the main stack evaluates as true when interpreted as a bool; and\n* the top-most element is not a single byte or is outside the inclusive range of 0x51 to 0x60,\n\nthen that top-most element of the main stack is popped and interpreted as a serialized script and executed,\nwhile the remaining elements of both stacks remain in place as inputs.\n\nIf the above conditions hold except for the last one, such that:\n\n* the top-most element ''is'' a single byte within the inclusive range of 0x51 (OP_1, meaning N=2) to 0x60 (OP_16, meaning N=17); and\n* other than this top-most element there are at least N additional elements on the main stack and alt stack combined,\n\nthen the top-most element of the main stack is dropped,\nand the N=2 (0x51) to 17 (0x60) further elements are popped from the main stack,\ncontinuing from the alt stack if the main stack is exhausted,\nand concatenated together in reverse order to form a serialized script,\nwhich is then executed with the remaining elements of both stacks remaining in place as inputs.\n\nThe presence of CHECKSIG or CHECKMULTISIG within the subscript do not count towards the global MAX_BLOCK_SIGOPS_COST limit,\nand the number of non-push opcodes executed in the subscript is not limited by MAX_OPS_PER_SCRIPT.\nExecution state, other than the above exceptions, carries over into the subscript,\nand termination of the subscript terminates execution of the script as a whole.\nThis is known as execution with tail-call semantics.\n\nOnly one such tail-call of a subscript is allowed per script execution context, and only from within a segwit redeem script.\nAlternatively stated, neither evaluation of witness stack nor execution of the scriptPubKey or scriptSig or P2SH redeem script results in tail-call semantics.\n\n==Motivation==\n\nBIP16 (Pay to Script Hash)[1] and BIP141 (Segregated Witness)[2] allow delayed revelation of a script's policy until the time of spend.\nHowever these approaches are limited in that only a single policy can be committed to in a given transaction output.\nIt is not possible to commit to multiple policies and then choose, at spend time, which to reveal.\n\nBIP116 (MERKLEBRANCHVERIFY)[3] allows multiple data elements to be committed to while only revealing those necessary at the time of spend.\nThe MERKLEBRANCHVERIFY opcode is only able to provide commitments to a preselected set of data values, and does not by itself allow for executing code.\n\nThis BIP generalizes the approach of these prior methods by allowing the redeem script to perform any type of computation necessary to place the policy script on the stack.\nThe policy script is then executed from the top of the data stack in a way similar to how BIP16 and BIP141 enable redeem scripts to be executed from the top of the witness stack.\nIn particular, using MERKLEBRANCHVERIFY[3] in the scriptPubKey or redeem script allows selection of the policy script that contains only the necessary conditions for validation of the spend.\nThis is a form of generalized MAST[4] where a stage of precomputation splits a syntax tree into possible execution pathways, which are then enumerated and hashed into a Merkle tree of policy scripts.\nAt spend time membership in this tree of the provided policy script is proven before execution recurses into the policy script.\n\n==Rationale==\n\nThis proposal is a soft-fork change to bitcoin's consensus rules because leaving a script that data-wise evaluates as true from its serialized form on the stack as execution terminates would result in the script validation returning true anyway.\nGiving the subscript a chance to terminate execution is only further constraining the validation rules.\nThe only scripts which would evaluate as false are the empty script, or a script that does nothing more than push empty/zero values to the stack.\nNone of these scripts have any real-world utility, so excluding them to achieve soft-fork compatibility doesn't come with any downsides.\n\nBy restricting ourselves to tail-call evaluation instead of a more general EVAL opcode we greatly simplify the implementation.\nTail-call semantics means that execution never returns to the calling script's context, and therefore no state needs to be saved or later restored.\nThe implementation is truly as simple as pulling the subscript off the stack, resetting a few state variables, and performing a jump back to the beginning of the script interpreter.\n\nThe restriction to allow only one layer of tail-call recursion is admittedly limiting, however the technical challenges to supporting multi-layer tail-call recursion are significant.\nA new metric would have to be developed to track script resource usage, for which transaction data witness size are only two factors.\nThis new weight would have to be relayed with transactions, used as the basis for fee calculation, validated in-line with transaction execution, and policy decided upon for DoS-banning peers that propagate violating transactions.\n\nHowever should these problems be overcome, dropping the single recursion constraint is itself a soft-fork for the same reason, applied inductively.\nAllowing only one layer of tail-call recursion allows us to receive the primary benefit of multi-policy commitments / generalized MAST,\nwhile leaving the door open to future generalized tail-call recursion if and when the necessary changes are made to resource accounting and p2p transaction distribution.\n\nThe global SIGOP limit and per-script opcode limits do not apply to the policy script\nbecause dynamic selection of the policy script makes it not possible for static analysis tools to verify these limits in general,\nand because performance improvements to libsecp256k1 and Bitcoin Core have made these limits no longer necessary as they once were.\nThe validation costs are still limited by the number of signature operations it is possible to encode within block size limits,\nand the maximum script size per input is limited to 10,000 + 17*520 = 18,840 bytes.\n\nTo allow for this drop of global and per-script limits,\ntail-call evaluation cannot be allowed for direct execution of the scriptPubKey,\nas such scripts are fetched from the UTXO and do not count towards block size limits of the block being validated.\nLikewise tail-call from P2SH redeem scripts is not supported due to quadratic blow-up vulnerabilities that are fixed in segwit.\n\n==Generalized MAST==\n\nWhen combined with BIP116 (MERKLEBRANCHVERIFY)[3], tail-call semantics allows for generalized MAST capabilities[4].\nThe script author starts with a full description of the entire contract they want to validate at the time of spend.\nThe possible execution pathways through the script are then enumerated, with conditional branches replaced by a validation of the condition and the branch taken.\nThe list of possible execution pathways is then put into a Merkle tree, with the flattened policy scripts as the leaves of this tree.\nThe final redeem script which funds are sent to is as follows:\n\n redeemScript: 2 MERKLEBRANCHVERIFY 2DROP DROP\n witness: ... \n\nWhere policyScript is the flattened execution pathway, proof is the serialized Merkle branch and path that proves the policyScript is drawn from the set used to construct the Merkle tree root, and arg1 through argN are the arguments required by policyScript.\nThe 2 indicates that a single leaf (1 << 1) follows, and the leaf value is not pre-hashed.\nThe 2DROP DROP is necessary to remove the arguments to MERKLEBRANCHVERIFY from the stack.\n\nThe above example was designed for clarity, but actually violates the CLEANSTACK rule of segwit v0 script execution.\nUnless the CLEANSTACK rule is dropped or modified in a new segwit output version, this would script would have to be modified to use the alt-stack, as follows:\n\n redeemScript: [TOALTSTACK]*N 2 MERKLEBRANCHVERIFY 2DROP DROP\n witness: ... \n\nWhere [TOALTSTACK]*N is the TOALTSTACK opcode repeated N times.\nThis moves arg1 through argN to the alt-stack in reverse order, such that arg1 is on the top of the alt-stack when execution of policyScript begins.\nThe policyScript would also have to be modified to fetch its arguments from the alt-stack, of course.\n\nIf the total set of policy scripts includes scripts that take a varying number of parameters, that too can be supported, within reasonable limits.\nThe following redeem script allows between 1 and 3 witness arguments in addition to the policy script and Merkle proof:\n\n witness: ... // N is between 1 and 3\n redeemScript: DEPTH TOALTSTACK // Save number of witness elements to alt-stack\n TOALTSTACK // Save 1st element (required) to alt-stack\n DEPTH 2 SUB // Calculate number of optional elements, ignoring policyScript and proof\n DUP IF SWAP TOALTSTACK 1SUB ENDIF // Save 2nd element (optional) to alt-stack, if it is present\n IF TOALTSTACK ENDIF // Save 3rd element (optional) to alt-stack, if it is present; consume counter\n 2 MERKLEBRANCHVERIFY 2DROP DROP\n alt-stack: ... \n\nBecause the number of witness elements is pushed onto the alt-stack, this enables policy scripts to verify the number of arguments passed, even though the size of the alt-stack is not usually accessible to script.\nThe following policy script for use with the above redeem script will only accept 2 witness elements on the alt-stack, preventing witness malleability:\n\n policyScript: FROMALTSTACK ...check arg1... FROMALTSTACK ...check&consume arg2/arg1&2... FROMALTSTACK 4 EQUAL\n\nThe number 4 is expected as that includes the policyScript and proof.\n\nThe verbosity of this example can be prevented by using a uniform number of witness elements as parameters for all policy subscripts, eliminating the conditionals and stack size counts.\nFuture script version upgrades should also consider relaxing CLEANSTACK rules to allow direct pass-through of arguments from the witness/redeem script to the policy script on the main stack.\n\n===Comparison with BIP114===\n\nBIP114 (Merkelized Abstract Syntax Tree)[5] specifies an explicit MAST scheme activated by BIP141 script versioning[2].\nUnlike BIP114, the scheme proposed by this BIP in conjunction with BIP116 (MERKLEBRANCHVERIFY)[3] implicitly enables MAST constructs using script itself to validate membership of the policy script in the MAST.\nThis has the advantage of requiring vastly fewer consensus code changes, as well as potentially enabling future script-based innovation without requiring any further consensus code changes at all, as the MAST scheme itself is programmable.\n\nFurthermore, by adding MERKLEBRANCHVERIFY and tail-call semantics to all script using the NOP-expansion space, BIP141 style script versioning is not required.\nThis removes a potentially significant hurdle to deployment by making this feature not dependent on resolving outstanding issues over address formats, how script version upgrades should be deployed, and consensus over what other features might go into a v1 upgrade.\n\n==Implementation==\n\nAn implementation of this BIP, including both consensus code changes and tests are available at the following Github repository:\n\n[https://github.com/maaku/bitcoin/tree/tail-call-semantics]\n\n==Deployment==\n\nThis BIP will be deployed by BIP8 (Version bits with lock-in by height)[9] with the name \"tailcall\" and using bit 3.\n\nFor Bitcoin mainnet, the BIP8 startheight will be at height M to be determined and BIP8 timeout activation will occur on height M + 50,400 blocks.\n\nFor Bitcoin testnet, the BIP8 startheight will be at height T to be determined and BIP8 timeout activation will occur on height T + 50,400 blocks.\n\nWe note that CLEANSTACK means that transactions which use this feature are already considered non-standard by the rules of the network, making deployment easier than was the case with, for example, with BIP68 (Relative lock-time using consensus-enforced sequence numbers)[6].\n\n==Compatibility==\n\nThe v0 segwit rules prohibit leaving anything on the stack, so for v0 parameters have to be passed on the alt stack for compatibility reasons.\n\n==References==\n\n[1] [https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki BIP16: Pay to Script Hash]\n\n[2] [https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki BIP141: Segregated Witness (Consensus Layer)]\n\n[3] [https://github.com/bitcoin/bips/blob/master/bip-0116.mediawiki BIP116: MERKLEBRANCHVERIFY]\n\n[4] \"[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-September/015028.html An explanation and justification of the tail-call and MBV approach to MAST]\", Mark Friedenbach, Bitcoin Development Mailing List, 20 September 2017.\n\n[5] [https://github.com/bitcoin/bips/blob/master/bip-0114.mediawiki BIP114: Merkelized Abstract Syntax Tree]\n\n[6] [https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP68: Relative lock-time using consensus-enforced sequence numbers]\n\n[9] [https://github.com/bitcoin/bips/blob/master/bip-0008.mediawiki BIP8: Version bits with lock-in by height]", "category": "bips" }, { "instruction": "How would you explain 
 to someone who knows Bitcoin basics?",
    "input": "",
    "output": "BIP: 136\n  Layer: Applications\n  Title: Bech32 Encoded Tx Position References\n  Authors: Велеслав \n           Jonas Schnelli \n           Daniel Pape \n  Status: Draft\n  Type: Informational\n  Assigned: 2017-07-09\n  License: BSD-2-Clause\n
\n\n== Introduction ==\n\n=== Abstract ===\nThis document proposes a convenient, human usable encoding to refer to a '''confirmed transaction position''' within the Bitcoin blockchain--known as '''\"TxRef\"'''. The primary purpose of this encoding is to allow users to refer to a confirmed transaction (and optionally, a particular outpoint index within the transaction) in a standard, reliable, and concise way.\n\n''Please note: Unlike a transaction ID, '''\"TxID\"''', where there is a strong cryptographic link between the ID and the actual transaction, a '''TxRef''' only provides a weak link to a particular transaction. A '''TxRef''' locates an offset within a blockchain for a transaction, that may - or may not - point to an actual transaction, which in fact may change with reorganisations. We recommend that '''TxRef'''s should be not used for positions within the blockchain having a maturity less than 100 blocks.''\n\nThe key words \"MUST\", \"MUST NOT\", \"REQUIRED\", \"SHALL\", \"SHALL NOT\", \"SHOULD\", \"SHOULD NOT\", \"RECOMMENDED\", \"MAY\", and \"OPTIONAL\" in this document are to be interpreted as described in [https://tools.ietf.org/html/rfc2119 RFC 2119].\n\n=== Copyright ===\n\nThis BIP is licensed under the 2-clause BSD license.\n\n=== Motivation ===\nSince the first version of Bitcoin, '''TxID'''s have been a core part of the consensus protocol and are routinely used to identify individual transactions between users.\n\nHowever, for many use-cases they have practical limitations:\n* '''TxID'''s are expensive for full nodes to lookup (requiring either a linear scan of the blockchain, or an expensive '''TxID''' index).\n* '''TxID'''s require third-party services for SPV wallets to lookup.\n* '''TxID'''s are 64 character HEX encoded values.\n\nIt is possible to reference transactions not only by their '''TxID''', but by their location within the blockchain itself. Rather than use the 64 character '''TxID''', an encoding of the position coordinates can be made friendly for occasional human transcription. In this document, we propose a standard for doing this.\n\n=== Examples ===\n\n{| class=\"wikitable\"\n|-\n! Block # !! Transaction # !! Outpoint # !! TxRef !! TxID\n|-\n| 0 || 0 || 0 || tx1:rqqq‑qqqq‑qwtv‑vjr || 4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b\n|-\n| 170 || 1 || 0 || tx1:r52q‑qqpq‑qpty‑cfg || f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16\n|-\n| 456789 || 1234 || 1 || tx1:y29u‑mqjx‑ppqq‑sfp2‑tt || 6fb8960f70667dc9666329728a19917937896fc476dfc54a3e802e887ecb4e82\n|}\n\n== Specification ==\n\nA '''confirmed transaction position reference''', or '''TxRef''', is a reference to a particular location within the blockchain, specified by the block height and a transaction index within the block, and optionally, an outpoint index within the transaction.\n\n''Please Note: All values in this specification are encoded in little-endian format.''\n\n=== TxRef Considerations ===\nIt is possible for a '''TxRef''' to reference a transaction that doesn't really exist because:\n\n* The specified block hasn't yet been mined.\n* The transaction index is greater than the total number of transactions included within the specified block.\n* The optional outpoint index is greater than the total outpoints contained within the transaction.\n\nTherefore, implementers must be careful not to display '''TxRef'''s to users prematurely:\n\n* Applications MUST NOT display '''TxRef'''s for transactions with less than 6 confirmations.\n* Application MUST show a warning for '''TxRef'''s for transactions with less than 100 confirmations.\n** This warning SHOULD state that in the case of a large reorganisation, the '''TxRef'''s displayed may point to a different transaction, or to no transaction at all.\n\n=== TxRef Format ===\n\n'''TxRef''' MUST use the '''Bech32m''''''Why use Bech32 Encoding for Confirmed Transaction References?''' The error detection and correction properties of this encoding format make it very attractive. We expect that it will be reasonable for software to correct a maximum of two characters; however, we haven’t specified this yet. encoding as defined in [https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki BIP-0173] and later refined in [https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki BIP-0350]. The Bech32m encoding consists of:\n\n==== Human-Readable Part ====\n\nThe '''HRP''' can be thought of as a label. We have chosen labels to distinguish between Main, Test, and Regtest networks:\n* Mainnet: '''\"tx\"'''.\n* Testnet: '''\"txtest\"'''.\n* Regtest: '''\"txrt\"'''.\n\n==== Separator ====\n\nThe separator is the character '''\"1\"'''.\n\n==== Data Part ====\n\nThe data part for a '''TxRef''' consists of the transaction's block height, transaction index within the block, and optionally, an outpoint index. Specific encoding details for the data are given below.\n\n''Please note: other specifications, such as [https://w3c-ccg.github.io/did-spec/ the Decentralized Identifiers spec], have implicitly encoded the information contained within the HRP elsewhere. In this case they may choose to not include the HRP as specified here.''\n\n==== Readability ====\n\nTo increase portability and readability, additional separator characters SHOULD be added to the '''TxRef''':\n\n* A Colon'''Why add a colon here?''' This allows it to conform better with W3C URN/URL standards. '''\":\"''' added after the separator character '1'.\n* Hyphens'''Why hyphens within the TxRef?''' As '''TxRef'''s are short, we expect that they will be quoted via voice or written by hand. The inclusion of hyphens every 4 characters breaks up the string and means people don't lose their place so easily. '''\"-\"''' added after every 4 characters beyond the colon.\n\n=== Encoding ===\n\nEncoding a '''TxRef''' requires 4 or 5 pieces of data: a magic code denoting which network is being used; a version number (currently always 0); the block height of the block containing the transaction; the index of the transaction within the block; and optionally, the index of the outpoint within the transaction. Only a certain number of bits are supported for each of these values, see the following table for details.\n\n{| class=\"wikitable\"\n!\n!Description\n!Possible Data Type\n!'''# of Bits used'''\n!Values\n|-\n| style=\"background: #99DDFF; color: black; text-align : center;\" | Magic Code\n|Chain Namespacing Code\n|uint8\n| style=\"background: #99DDFF; color: black; text-align : center;\" | 5\n|'''3''': Mainnet
'''4''': Mainnet with Outpoint
'''6''': Testnet
'''7''': Testnet with Outpoint
'''0''': Regtest
'''1''': Regtest with Outpoint\n|-\n| style=\"background: #DDDDDD; color: black; text-align : center;\" | Version\n|For Future Use\n|uint8\n| style=\"background: #DDDDDD; color: black; text-align : center;\" | 1\n|Must be '''0'''\n|-\n| style=\"background: #EEDD88; color: black; text-align : center;\" | Block
Height\n|The Block Height of the Tx\n|uint32\n| style=\"background: #EEDD88; color: black; text-align : center;\" | 24\n|Block 0 to Block 16777215\n|-\n| style=\"background: #FFAABB; color: black; text-align : center;\" | Transaction
Index\n|The index of the Tx inside the block\n|uint16, uint32\n| style=\"background: #FFAABB; color: black; text-align : center;\" | 15\n|Tx 0 to Tx 32767\n|-\n| style=\"background: #BBCC33; color: black; text-align : center;\" | Outpoint
Index\n|The index of the Outpoint inside the Tx\n|uint16, uint32\n| style=\"background: #BBCC33; color: black; text-align : center;\" | 15\n|Outpoint 0 to Outpoint 32767\n|}\n\n==== Magic Notes ====\nThe magic code provides namespacing between chains:\n\n* For Mainnet the magic code is: '''0x3''', leading to an '''\"r\"''' character when encoded.\n* For Mainnet with Outpoint Encoded the magic code is: '''0x4''', leading to a '''\"y\"''' character when encoded.\n* For Testnet the magic code is: '''0x6''', leading to an '''\"x\"''' character when encoded.\n* For Testnet with Outpoint Encoded the magic code is: '''0x7''', leading to an '''\"8\"''' character when encoded.\n* For Regtest the magic code is: '''0x0''', leading to a '''\"q\"''' character when encoded.\n* For Regtest with Outpoint Encoded the magic code is: '''0x1''', leading to a '''\"p\"''' character when encoded.\n\n==== Encoding Example ====\n\nWe want to encode a '''TxRef''' that refers to Transaction #1234 of Block #456789 on the Mainnet chain. We use this data in preparation for the Bech32 encoding algorithm:\n\n{| class=\"wikitable\"\n!\n!Decimal
Value\n!Binary
Value\n!'''# of Bits
used'''\n!Bit Indexes and Values\n|-\n| style=\"background: #99DDFF; color: black; text-align : center;\" | Magic
Code\n| style=\"background: #99DDFF; color: black; text-align : center;\" | 3\n|00000011\n| style=\"background: #99DDFF; color: black; text-align : center;\" | 5\n|(mc04, mc03, mc02, mc01, mc00) = (0, 0, 0, 1, 1)\n|-\n| style=\"background: #DDDDDD; color: black; text-align : center;\" | Version\n| style=\"background: #DDDDDD; color: black; text-align : center;\" | 0\n|00000000\n| style=\"background: #DDDDDD; color: black; text-align : center;\" | 1\n|(v0) = (0)\n|-\n| style=\"background: #EEDD88; color: black; text-align : center;\" | Block
Height\n| style=\"background: #EEDD88; color: black; text-align : center;\" | 456789\n|00000110
11111000
01010101\n| style=\"background: #EEDD88; color: black; text-align : center;\" | 24\n|(bh23, bh22, bh21, bh20, bh19, bh18, bh17, bh16) = (0, 0, 0, 0, 0, 1, 1, 0)
(bh15, bh14, bh13, bh12, bh11, bh10, bh09, bh08) = (1, 1, 1, 1, 1, 0, 0, 0)
(bh07, bh06, bh05, bh04, bh03, bh02, bh01, bh00) = (0, 1, 0, 1, 0, 1, 0, 1)\n|-\n| style=\"background: #FFAABB; color: black; text-align : center;\" | Transaction
Index\n| style=\"background: #FFAABB; color: black; text-align : center;\" | 1234\n|00000100
11010010\n| style=\"background: #FFAABB; color: black; text-align : center;\" | 15\n|(ti14, ti13, ti12, ti11, ti10, ti09, ti08) = (0, 0, 0, 0, 1, 0, 0)
(ti07, ti06, ti05, ti04, ti03, ti02, ti01, ti00) = (1, 1, 0, 1, 0, 0, 1, 0)\n|}\n\nAs shown in the last column, we take the necessary bits of each binary value and copy them into nine unsigned chars illustrated in the next table. We only set the lower five bits of each unsigned char as the bech32 algorithm only uses those bits.\n\n{| class=\"wikitable\" style=\"text-align: center\"\n!\n!\n!style=\"width:2em\"|7\n!style=\"width:2em\"|6\n!style=\"width:2em\"|5\n!style=\"width:2em\"|4\n!style=\"width:2em\"|3\n!style=\"width:2em\"|2\n!style=\"width:2em\"|1\n!style=\"width:2em\"|0\n!\n!Decimal
Value\n!Bech32
Character\n|-\n| || || || || || || || || || || || ||\n|-\n| rowspan=\"2\" | data[0] || Index\n|na\n|na\n|na\n| style=\"background: #99DDFF; color: black; text-align : center;\" | mc04\n| style=\"background: #99DDFF; color: black; text-align : center;\" | mc03\n| style=\"background: #99DDFF; color: black; text-align : center;\" | mc02\n| style=\"background: #99DDFF; color: black; text-align : center;\" | mc01\n| style=\"background: #99DDFF; color: black; text-align : center;\" | mc00\n|\n|\n|\n|-\n|Value\n|0\n|0\n|0\n|0\n|0\n|0\n|1\n|1\n|\n|3\n|r\n|-\n| || || || || || || || || || || ||\n|-\n| rowspan=\"2\" | data[1] || Index\n|na\n|na\n|na\n| style=\"background: #EEDD88; color: black; text-align : center;\" | bh03\n| style=\"background: #EEDD88; color: black; text-align : center;\" | bh02\n| style=\"background: #EEDD88; color: black; text-align : center;\" | bh01\n| style=\"background: #EEDD88; color: black; text-align : center;\" | bh00\n| style=\"background: #DDDDDD; color: black; text-align : center;\" | v0\n|\n|\n|\n|-\n|Value\n|0\n|0\n|0\n|0\n|1\n|0\n|1\n|0\n|\n|10\n|2\n|-\n| || || || || || || || || || || ||\n|-\n| rowspan=\"2\" | data[2] || Index\n|na\n|na\n|na\n| style=\"background: #EEDD88; color: black; text-align : center;\" | bh08\n| style=\"background: #EEDD88; color: black; text-align : center;\" | bh07\n| style=\"background: #EEDD88; color: black; text-align : center;\" | bh06\n| style=\"background: #EEDD88; color: black; text-align : center;\" | bh05\n| style=\"background: #EEDD88; color: black; text-align : center;\" | bh04\n|\n|\n|\n|-\n|Value\n|0\n|0\n|0\n|0\n|0\n|1\n|0\n|1\n|\n|5\n|9\n|-\n| || || || || || || || || || || ||\n|-\n| rowspan=\"2\" | data[3] || Index\n|na\n|na\n|na\n| style=\"background: #EEDD88; color: black; text-align : center;\" | bh13\n| style=\"background: #EEDD88; color: black; text-align : center;\" | bh12\n| style=\"background: #EEDD88; color: black; text-align : center;\" | bh11\n| style=\"background: #EEDD88; color: black; text-align : center;\" | bh10\n| style=\"background: #EEDD88; color: black; text-align : center;\" | bh09\n|\n|\n|\n|-\n|Value\n|0\n|0\n|0\n|1\n|1\n|1\n|0\n|0\n|\n|28\n|u\n|-\n| || || || || || || || || || || ||\n|-\n| rowspan=\"2\" | data[4] || Index\n|na\n|na\n|na\n| style=\"background: #EEDD88; color: black; text-align : center;\" | bh18\n| style=\"background: #EEDD88; color: black; text-align : center;\" | bh17\n| style=\"background: #EEDD88; color: black; text-align : center;\" | bh16\n| style=\"background: #EEDD88; color: black; text-align : center;\" | bh15\n| style=\"background: #EEDD88; color: black; text-align : center;\" | bh14\n|\n|\n|\n|-\n|Value\n|0\n|0\n|0\n|1\n|1\n|0\n|1\n|1\n|\n|27\n|m\n|-\n| || || || || || || || || || || ||\n|-\n| rowspan=\"2\" | data[5] || Index\n|na\n|na\n|na\n| style=\"background: #EEDD88; color: black; text-align : center;\" | bh23\n| style=\"background: #EEDD88; color: black; text-align : center;\" | bh22\n| style=\"background: #EEDD88; color: black; text-align : center;\" | bh21\n| style=\"background: #EEDD88; color: black; text-align : center;\" | bh20\n| style=\"background: #EEDD88; color: black; text-align : center;\" | bh19\n|\n|\n|\n|-\n|Value\n|0\n|0\n|0\n|0\n|0\n|0\n|0\n|0\n|\n|0\n|q\n|-\n| || || || || || || || || || || ||\n|-\n| rowspan=\"2\" | data[6] || Index\n|na\n|na\n|na\n| style=\"background: #FFAABB; color: black; text-align : center;\" | ti04\n| style=\"background: #FFAABB; color: black; text-align : center;\" | ti03\n| style=\"background: #FFAABB; color: black; text-align : center;\" | ti02\n| style=\"background: #FFAABB; color: black; text-align : center;\" | ti01\n| style=\"background: #FFAABB; color: black; text-align : center;\" | ti00\n|\n|\n|\n|-\n|Value\n|0\n|0\n|0\n|1\n|0\n|0\n|1\n|0\n|\n|18\n|j\n|-\n| || || || || || || || || || || ||\n|-\n| rowspan=\"2\" | data[7] || Index\n|na\n|na\n|na\n| style=\"background: #FFAABB; color: black; text-align : center;\" | ti09\n| style=\"background: #FFAABB; color: black; text-align : center;\" | ti08\n| style=\"background: #FFAABB; color: black; text-align : center;\" | ti07\n| style=\"background: #FFAABB; color: black; text-align : center;\" | ti06\n| style=\"background: #FFAABB; color: black; text-align : center;\" | ti05\n|\n|\n|\n|-\n|Value\n|0\n|0\n|0\n|0\n|0\n|1\n|1\n|0\n|\n|6\n|x\n|-\n| || || || || || || || || || || ||\n|-\n| rowspan=\"2\" | data[8] || Index\n|na\n|na\n|na\n| style=\"background: #FFAABB; color: black; text-align : center;\" | ti14\n| style=\"background: #FFAABB; color: black; text-align : center;\" | ti13\n| style=\"background: #FFAABB; color: black; text-align : center;\" | ti12\n| style=\"background: #FFAABB; color: black; text-align : center;\" | ti11\n| style=\"background: #FFAABB; color: black; text-align : center;\" | ti10\n|\n|\n|\n|-\n|Value\n|0\n|0\n|0\n|0\n|0\n|0\n|0\n|1\n|\n|1\n|p\n|}\n\nThe Bech32 algorithm encodes the nine unsigned chars above and computes a checksum of those chars and encodes that as well--this gives a six character checksum (in this case, '''utt3p0''') which is appended to the final '''TxRef'''. The final '''TxRef''' given is: '''tx1:r29u-mqjx-putt-3p0''' and is illustrated in the following table:\n\nTxRef character indexes and descriptions\n{| class=\"wikitable\" style=\"text-align: top\"\n!style=\"width:2em\"|Index\n!style=\"width:2em\"|0\n!style=\"width:2em\"|1\n!style=\"width:2em\"|2\n!style=\"width:2em\"|3\n!style=\"width:2em\"|4\n!style=\"width:2em\"|5\n!style=\"width:2em\"|6\n!style=\"width:2em\"|7\n!style=\"width:2em\"|8\n!style=\"width:2em\"|9\n!style=\"width:2em\"|10\n!style=\"width:2em\"|11\n!style=\"width:2em\"|12\n!style=\"width:2em\"|13\n!style=\"width:2em\"|14\n!style=\"width:2em\"|15\n!style=\"width:2em\"|16\n!style=\"width:2em\"|17\n!style=\"width:2em\"|18\n!style=\"width:2em\"|19\n!style=\"width:2em\"|20\n!style=\"width:2em\"|21\n|-\n|Char:\n| style=\"background: #BBCCEE; color: black; text-align : center;\" | t\n| style=\"background: #BBCCEE; color: black; text-align : center;\" | x\n| style=\"background: #FFCCCC; color: black; text-align : center;\" | 1\n| style=\"background: #CCDDAA; color: black; text-align : center;\" | :\n| style=\"background: #EEEEBB; color: black; text-align : center;\" | r\n| style=\"background: #EEEEBB; color: black; text-align : center;\" | 2\n| style=\"background: #EEEEBB; color: black; text-align : center;\" | 9\n| style=\"background: #EEEEBB; color: black; text-align : center;\" | u\n| style=\"background: #CCDDAA; color: black; text-align : center;\" | -\n| style=\"background: #EEEEBB; color: black; text-align : center;\" | m\n| style=\"background: #EEEEBB; color: black; text-align : center;\" | q\n| style=\"background: #EEEEBB; color: black; text-align : center;\" | j\n| style=\"background: #EEEEBB; color: black; text-align : center;\" | x\n| style=\"background: #CCDDAA; color: black; text-align : center;\" | -\n| style=\"background: #EEEEBB; color: black; text-align : center;\" | p\n| style=\"background: #EEEEBB; color: black; text-align : center;\" | u\n| style=\"background: #EEEEBB; color: black; text-align : center;\" | t\n| style=\"background: #EEEEBB; color: black; text-align : center;\" | t\n| style=\"background: #CCDDAA; color: black; text-align : center;\" | -\n| style=\"background: #EEEEBB; color: black; text-align : center;\" | 3\n| style=\"background: #EEEEBB; color: black; text-align : center;\" | p\n| style=\"background: #EEEEBB; color: black; text-align : center;\" | 0\n|}\n\n==== Outpoint Index ====\n\nSome uses of '''TxRef''' may want to refer to a specific outpoint of the transaction. In the previous example, since we did not specify the outpoint index, the '''TxRef''' '''tx1:r29u-mqjx-putt-3p0''' implicitly references the first (index 0) outpoint of the 1234th transaction in the 456789th block in the blockchain.\n\nIf instead, for example, we want to reference the second (index 1) outpoint, we need to change the magic code from '''3''' to '''4''' and would include the following in the data to be encoded:\n\n{| class=\"wikitable\"\n!\n!Decimal
Value\n!Binary
Value\n!'''# of Bits
used'''\n!Bit Indexes and Values\n|-\n| style=\"background: #99DDFF; color: black; text-align : center;\" | Magic
Code\n| style=\"background: #99DDFF; color: black; text-align : center;\" | 4\n|00000100\n| style=\"background: #99DDFF; color: black; text-align : center;\" | 5\n|(mc04, mc03, mc02, mc01, mc00) = (0, 0, 1, 0, 0)\n|-\n| style=\"background: #BBCC33; color: black; text-align : center;\" | Outpoint Index\n| style=\"background: #BBCC33; color: black; text-align : center;\" | 1\n|00000000 00000001\n| style=\"background: #BBCC33; color: black; text-align : center;\" | 15\n|(op14, op13, op12, op11, op10, op09, op08) = (0, 0, 0, 0, 0, 0, 0)
(op07, op06, op05, op04, op03, op02, op01, op00) = (0, 0, 0, 0, 0, 0, 0, 1)\n|}\n\n{| class=\"wikitable\" style=\"text-align: center\"\n!\n!\n!style=\"width:2em\"|7\n!style=\"width:2em\"|6\n!style=\"width:2em\"|5\n!style=\"width:2em\"|4\n!style=\"width:2em\"|3\n!style=\"width:2em\"|2\n!style=\"width:2em\"|1\n!style=\"width:2em\"|0\n!\n!Decimal
Value\n!Bech32
Character\n|-\n| || || || || || || || || || || || ||\n|-\n| rowspan=\"2\" | data[0] || Index\n|na\n|na\n|na\n| style=\"background: #99DDFF; color: black; text-align : center;\" | mc04\n| style=\"background: #99DDFF; color: black; text-align : center;\" | mc03\n| style=\"background: #99DDFF; color: black; text-align : center;\" | mc02\n| style=\"background: #99DDFF; color: black; text-align : center;\" | mc01\n| style=\"background: #99DDFF; color: black; text-align : center;\" | mc00\n|\n|\n|\n|-\n|Value\n|0\n|0\n|0\n|0\n|0\n|1\n|0\n|0\n|\n|4\n|y\n|-\n| || || || || || || || || || || ||\n|-\n| rowspan=\"2\" | data[9] || Index\n|na\n|na\n|na\n| style=\"background: #BBCC33; color: black; text-align : center;\" | op04\n| style=\"background: #BBCC33; color: black; text-align : center;\" | op03\n| style=\"background: #BBCC33; color: black; text-align : center;\" | op02\n| style=\"background: #BBCC33; color: black; text-align : center;\" | op01\n| style=\"background: #BBCC33; color: black; text-align : center;\" | op00\n|\n|\n|\n|-\n|Value\n|0\n|0\n|0\n|0\n|0\n|0\n|0\n|1\n|\n|1\n|p\n|-\n| || || || || || || || || || || ||\n|-\n| rowspan=\"2\" | data[10] || Index\n|na\n|na\n|na\n| style=\"background: #BBCC33; color: black; text-align : center;\" | op09\n| style=\"background: #BBCC33; color: black; text-align : center;\" | op08\n| style=\"background: #BBCC33; color: black; text-align : center;\" | op07\n| style=\"background: #BBCC33; color: black; text-align : center;\" | op06\n| style=\"background: #BBCC33; color: black; text-align : center;\" | op05\n|\n|\n|\n|-\n|Value\n|0\n|0\n|0\n|0\n|0\n|0\n|0\n|0\n|\n|0\n|q\n|-\n| || || || || || || || || || || ||\n|-\n| rowspan=\"2\" | data[11] || Index\n|na\n|na\n|na\n| style=\"background: #BBCC33; color: black; text-align : center;\" | op14\n| style=\"background: #BBCC33; color: black; text-align : center;\" | op13\n| style=\"background: #BBCC33; color: black; text-align : center;\" | op12\n| style=\"background: #BBCC33; color: black; text-align : center;\" | op11\n| style=\"background: #BBCC33; color: black; text-align : center;\" | op10\n|\n|\n|\n|-\n| Value\n|0\n|0\n|0\n|0\n|0\n|0\n|0\n|0\n|\n|0\n|q\n|}\n\nAfter Bech32 encoding all twelve unsigned chars above, we get the checksum: '''sfp2tt'''. The final '''TxRef''' given is: '''tx1:y29u-mqjx-ppqq-sfp2-tt''' and is illustrated in the following table:\n\nTxRef character indexes and descriptions\n{| class=\"wikitable\" style=\"text-align: top\"\n!style=\"width:2em\"|Index\n!style=\"width:2em\"|0\n!style=\"width:2em\"|1\n!style=\"width:2em\"|2\n!style=\"width:2em\"|3\n!style=\"width:2em\"|4\n!style=\"width:2em\"|5\n!style=\"width:2em\"|6\n!style=\"width:2em\"|7\n!style=\"width:2em\"|8\n!style=\"width:2em\"|9\n!style=\"width:2em\"|10\n!style=\"width:2em\"|11\n!style=\"width:2em\"|12\n!style=\"width:2em\"|13\n!style=\"width:2em\"|14\n!style=\"width:2em\"|15\n!style=\"width:2em\"|16\n!style=\"width:2em\"|17\n!style=\"width:2em\"|18\n!style=\"width:2em\"|19\n!style=\"width:2em\"|20\n!style=\"width:2em\"|21\n!style=\"width:2em\"|22\n!style=\"width:2em\"|23\n!style=\"width:2em\"|24\n!style=\"width:2em\"|25\n|-\n|Char:\n| style=\"background: #BBCCEE; color: black; text-align : center;\" | t\n| style=\"background: #BBCCEE; color: black; text-align : center;\" | x\n| style=\"background: #FFCCCC; color: black; text-align : center;\" | 1\n| style=\"background: #CCDDAA; color: black; text-align : center;\" | :\n| style=\"background: #EEEEBB; color: black; text-align : center;\" | y\n| style=\"background: #EEEEBB; color: black; text-align : center;\" | 2\n| style=\"background: #EEEEBB; color: black; text-align : center;\" | 9\n| style=\"background: #EEEEBB; color: black; text-align : center;\" | u\n| style=\"background: #CCDDAA; color: black; text-align : center;\" | -\n| style=\"background: #EEEEBB; color: black; text-align : center;\" | m\n| style=\"background: #EEEEBB; color: black; text-align : center;\" | q\n| style=\"background: #EEEEBB; color: black; text-align : center;\" | j\n| style=\"background: #EEEEBB; color: black; text-align : center;\" | x\n| style=\"background: #CCDDAA; color: black; text-align : center;\" | -\n| style=\"background: #EEEEBB; color: black; text-align : center;\" | p\n| style=\"background: #EEEEBB; color: black; text-align : center;\" | p\n| style=\"background: #EEEEBB; color: black; text-align : center;\" | q\n| style=\"background: #EEEEBB; color: black; text-align : center;\" | q\n| style=\"background: #CCDDAA; color: black; text-align : center;\" | -\n| style=\"background: #EEEEBB; color: black; text-align : center;\" | s\n| style=\"background: #EEEEBB; color: black; text-align : center;\" | f\n| style=\"background: #EEEEBB; color: black; text-align : center;\" | p\n| style=\"background: #EEEEBB; color: black; text-align : center;\" | 2\n| style=\"background: #CCDDAA; color: black; text-align : center;\" | -\n| style=\"background: #EEEEBB; color: black; text-align : center;\" | t\n| style=\"background: #EEEEBB; color: black; text-align : center;\" | t\n|}\n\n\n=== Decoding ===\n\nThe Bech32 spec defines 32 valid characters as its \"alphabet\". All non-Bech32-alphabet characters present in a '''TxRef''' after the Bech32 separator character MUST be ignored/removed when parsing (except for terminating characters). We do not wish to expect the users to keep their '''TxRef'''s in good form and '''TxRef'''s may contains hyphens, colons, invisible spaces, uppercase or random characters. We expect users to copy, paste, write by-hand, write in a mix of character sets, etc. Parsers SHOULD attempt to correct for these and other common errors, reporting to the user any '''TxRef'''s that violate a proper Bech32 encoding.\n\nAs of early 2021, '''TxRef''' has been in limited use for a couple of years and it is possible that there are some '''TxRef'''s in use which were created with the original specification of Bech32 before the Bech32m refinement was codified. Due to this possibility, a '''TxRef''' parser SHOULD be able to decode both Bech32m and Bech32 encoded '''TxRef'''s. In such a case, a '''TxRef''' parser SHOULD display or somehow notify the user that they are using an obsolete '''TxRef''' and that they should upgrade it to the Bech32m version. Additionally, the parser MAY also display the Bech32m version.\n\n== Rationale ==\n\n\n\n== Reference implementations ==\n\nC Reference Implementation (supports magic codes 0x3 and 0x6): https://github.com/jonasschnelli/bitcoin_txref_code\n\nGo Reference Implementation (supports magic codes 0x3 and 0x6): https://github.com/kulpreet/txref\n\nC++ Reference Implementation (supports magic codes 0x3, 0x4, 0x6, 0x7, 0x0 and 0x1): https://github.com/dcdpr/libtxref/\n\nJava Reference Implementation (supports magic codes 0x3, 0x4, 0x6, 0x7, 0x0 and 0x1): https://github.com/dcdpr/libtxref-java/\n\n== Appendices ==\n\n=== Test Examples ===\n\nThe following examples show values for various combinations on mainnet and testnet; encoding block height, transaction index, and an optional output index.\n\n==== TxRef ====\nThe following list gives properly encoded mainnet '''TxRef'''s and the decoded hex values (block height, transaction index)\n\n* tx1:rqqq-qqqq-qwtv-vjr: (0x0, 0x0)\n* tx1:rqqq-qqll-lj68-7n2: (0x0, 0x7FFF)\n* tx1:r7ll-llqq-qats-vx9: (0xFFFFFF, 0x0)\n* tx1:r7ll-llll-lp6m-78v: (0xFFFFFF, 0x7FFF)\n\nThe following list gives properly encoded testnet '''TxRef'''s and the decoded hex values (block height, transaction index)\n\n* txtest1:xqqq-qqqq-qrrd-ksa: (0x0, 0x0)\n* txtest1:xqqq-qqll-lljx-y35: (0x0, 0x7FFF)\n* txtest1:x7ll-llqq-qsr3-kym: (0xFFFFFF, 0x0)\n* txtest1:x7ll-llll-lvj6-y9j: (0xFFFFFF, 0x7FFF)\n\nThe following list gives valid (sometimes strangely formatted) '''TxRef'''s and the decoded values (block height, transaction index)*\n* tx1:r29u-mqjx-putt-3p0: (456789, 1234)\n* TX1R29UMQJXPUTT3P0: (456789, 1234)\n* tx1 r29u mqjx putt 3p0: (456789, 1234)\n* tx1!r29u/mqj*x-putt^^3p0: (456789, 1234)\n\nThe following list gives invalid '''TxRef'''s and the reason for their invalidity.\n* tx1:t7ll-llll-lcq3-aj4: Magic 0xB instead of 0x3.\n* tx1:rlll-llll-lu9m-00x: Version 1 instead of 0.\n* tx1:r7ll-llll-lqfu-gss2: Valid Bech32, but ten 5 bit unsigned chars instead of nine.\n* tx1:r7ll-llll-rt5h-wz: Valid Bech32, but eight 5 bit unsigned chars instead of nine.\n* tx1:r7ll-LLLL-lp6m-78v: Invalid Bech32 due to mixed case. Would decode correctly otherwise.\n\n==== TxRef with Outpoints ====\nThe following list gives properly encoded mainnet '''TxRef'''s with Outpoints and the decoded values (block height, transaction index, outpoint index)\n\n* tx1:yqqq-qqqq-qqqq-rvum-0c: (0x0, 0x0, 0x0)\n* tx1:yqqq-qqll-lqqq-en8x-05: (0x0, 0x7FFF, 0x0)\n* tx1:y7ll-llqq-qqqq-ggjg-w6: (0xFFFFFF, 0x0, 0x0)\n* tx1:y7ll-llll-lqqq-jhf4-wk: (0xFFFFFF, 0x7FFF, 0x0)\n\n* tx1:yqqq-qqqq-qpqq-pw4v-kq: (0x0, 0x0, 0x1)\n* tx1:yqqq-qqll-lpqq-m3w3-kv: (0x0, 0x7FFF, 0x1)\n* tx1:y7ll-llqq-qpqq-22ml-hz: (0xFFFFFF, 0x0, 0x1)\n* tx1:y7ll-llll-lpqq-s4qz-hw: (0xFFFFFF, 0x7FFF, 0x1)\n\n* tx1:y29u-mqjx-ppqq-sfp2-tt: (456789, 1234, 1)\n\n\nThe following list gives properly encoded testnet '''TxRef'''s with Outpoints and the decoded values (block height, transaction index, outpoint index)\n\n* txtest1:8qqq-qqqq-qqqq-d5ns-vl: (0x0, 0x0, 0x0)\n* txtest1:8qqq-qqll-lqqq-htgd-vn: (0x0, 0x7FFF, 0x0)\n* txtest1:87ll-llqq-qqqq-xsar-da: (0xFFFFFF, 0x0, 0x0)\n* txtest1:87ll-llll-lqqq-u0x7-d3: (0xFFFFFF, 0x7FFF, 0x0)\n\n* txtest1:8qqq-qqqq-qpqq-0k68-48: (0x0, 0x0, 0x1)\n* txtest1:8qqq-qqll-lpqq-4fp6-4t: (0x0, 0x7FFF, 0x1)\n* txtest1:87ll-llqq-qpqq-yj55-59: (0xFFFFFF, 0x0, 0x1)\n* txtest1:87ll-llll-lpqq-7d0f-5f: (0xFFFFFF, 0x7FFF, 0x1)\n\n* txtest1:829u-mqjx-ppqq-73wp-gv: (456789, 1234, 1)\n\n\n=== TxRef Payload Value Choices: ===\nSome calculations showing why we chose these particular bit-length of the block height and transaction index.\n\n==== Block Height Value: ====\n24 bits: value can be between 0, and 0xFFFFFF (16777216 blocks).\n\n* In early April, 2021, there have been 677700 blocks\n* There are roughly (365 days * 24 hours * 6 blocks / hour) = 52560 blocks every year, implying about (16777216 - 677700) / 52560 = 306 more years of addressable blocks.\n* Some time before year 2327 this specification should be extended.\n\n==== Tx Position Value: ====\n15 bits: value can be between 0x0, and 0x7FFF (32768 transactions).\n\n*The ''realistic'' smallest Tx is 83 Bytes for maximum 12047 tx in a block.\n**4B version + 1B tx_in count + 36B previous_output + 1B script length + 0B signature script + 4B sequence + 1B tx_out count + 8B amount + 1B script length + 23B pubkey script + 4B lock_time = 83B\n*The ''extreme'' smallest Tx is 60 Bytes for maximum 16665 tx in a block.\n**4B version + 1B tx_in count + 36B previous_output + 1B script length + 0B signature script + 4B sequence + 1B tx_out count + 8B amount + 1B script length + 0B pubkey script + 4B lock_time = 60B\n\n== Acknowledgements ==\nSpecial Thanks to Pieter Wuille and Greg Maxwell for Bech32, a wonderful user-facing data encoding.", "category": "bips" }, { "instruction": "I'm trying to understand '''NOTICE: This document is a work in progress and is not complete, implemented, or otherwise suitable for deployment.''' - can you walk me through it?", "input": "", "output": "
\n  BIP: 62\n  Layer: Consensus (soft fork)\n  Title: Dealing with malleability\n  Authors: Pieter Wuille \n  Status: Closed\n  Type: Specification\n  Assigned: 2014-03-12\n  License: BSD-2-Clause\n
\n\n==Abstract==\n\nThis document specifies proposed changes to the Bitcoin transaction validity rules in order to make malleability of transactions impossible (at least when the sender doesn't choose to avoid it).\n\n==Copyright==\n\nThis BIP is licensed under the 2-clause BSD license.\n\n==Motivation==\n\nAs of february 2014, Bitcoin transactions are malleable in multiple ways. This means a (valid) transaction can be modified in-flight, without invalidating it, but without access to the relevant private keys.\n\nThis is a problem for multiple reasons:\n* The sender may not recognize his own transaction after being modified.\n* The sender may create transactions that spend change created by the original transaction. In case the modified transaction gets mined, this becomes invalid.\n* Modified transactions are effectively double-spends which can be created without malicious intent (of the sender), but can be used to make other attacks easier.\n\nSeveral sources of malleability are known:", "category": "bips" }, { "instruction": "Hey, I need to set up Bitcoin Operations Guide - what's the command line way to do that?", "input": "", "output": "# '''Non-DER encoded ECDSA signatures''' Right now, the Bitcoin reference client uses OpenSSL to validate signatures. As OpenSSL accepts more than serializations that strictly adhere to the DER standard, this is a source of malleability. Since v0.8.0, non-DER signatures are no longer relayed already.", "category": "bips" }, { "instruction": "What's the deal with Bitcoin Operations Guide in Bitcoin? Explain it like I'm a friend.", "input": "", "output": "# '''Non-push operations in scriptSig''' Any sequence of script operations in scriptSig that results in the intended data pushes, but is not just a push of that data, results in an alternative transaction with the same validity.", "category": "bips" }, { "instruction": "Can you show me the CLI commands for Bitcoin Operations Guide?", "input": "", "output": "# '''Push operations in scriptSig of non-standard size type''' The Bitcoin scripting language has several push operators (OP_0, single-byte pushes, data pushes of up to 75 bytes, OP_PUSHDATA1, OP_PUSHDATA2, OP_PUSHDATA4). As the latter ones have the same result as the former ones, they result in additional possibilities.", "category": "bips" }, { "instruction": "I'm stuck with Bitcoin Operations Guide - what should I check?", "input": "", "output": "# '''Zero-padded number pushes''' In cases where scriptPubKey opcodes use inputs that are interpreted as numbers, they can be zero padded.", "category": "bips" }, { "instruction": "How do I troubleshoot Bitcoin Operations Guide issues?", "input": "", "output": "# '''Inherent ECDSA signature malleability''' ECDSA signatures themselves are already malleable: taking the negative of the number S inside (modulo the curve order) does not invalidate it.", "category": "bips" }, { "instruction": "What are the best practices for Bitcoin Operations Guide?", "input": "", "output": "# '''Superfluous scriptSig operations''' Adding extra data pushes at the start of scripts, which are not consumed by the corresponding scriptPubKey, is also a source of malleability.", "category": "bips" }, { "instruction": "Walk me through setting up Bitcoin Operations Guide step by step", "input": "", "output": "# '''Inputs ignored by scripts''' If a scriptPubKey starts with an OP_DROP, for example, the last data push of the corresponding scriptSig will always be ignored.", "category": "bips" }, { "instruction": "What commands would you run to work with Bitcoin Operations Guide?", "input": "", "output": "# '''Sighash flags based masking''' Sighash flags can be used to ignore certain parts of a script when signing.", "category": "bips" }, { "instruction": "I want to understand '''New signatures by the sender''' The sender (or anyone with access to the relevant private keys) is always able to create new signatures that spend the same inputs to the same outputs. from a technical perspective", "input": "", "output": "The first six and part of the seventh can be fixed by extra consensus rules, but the last two can't. Not being able to fix #7 means that even with these new consensus rules, it will always be possible to create outputs whose spending transactions will all be malleable. However, when restricted to using a safe set of output scripts, extra consensus rules can make spending transactions optionally non-malleable (if the spender chooses to; as he can always bypass #8 and #9 himself).\n\n==Specification==\n\n===New rules===\n\nSeven extra rules are introduced, to combat exactly the seven first sources of malleability listed above:", "category": "bips" }, { "instruction": "Can you explain Bitcoin Operations Guide like we're having a beer and talking Bitcoin?", "input": "", "output": "# '''Canonically encoded ECDSA signatures''' An ECDSA signature passed to OP_CHECKSIG, OP_CHECKSIGVERIFY, OP_CHECKMULTISIG or OP_CHECKMULTISIGVERIFY must be encoded using strict DER encoding. To provide a compact way to deliberately create an invalid signature for OP_CHECKSIG and OP_CHECKMULTISIG, an empty byte array (i.e., the result of OP_0) is also allowed. Doing a verification with a non-DER signature makes the entire script evaluate to False (not just the signature verification). See reference: [[#der-encoding|DER encoding]].", "category": "bips" }, { "instruction": "How would you explain Bitcoin Operations Guide to someone who knows Bitcoin basics?", "input": "", "output": "# '''Non-push operations in scriptSig''' Only data pushes are allowed in scriptSig. Evaluating any other operation makes the script evaluate to false. See reference: [[#push-operators|Push operators]].", "category": "bips" }, { "instruction": "I'm trying to understand Bitcoin Operations Guide - can you walk me through it?", "input": "", "output": "# '''Push operations in scriptSig of non-standard size type''' The smallest possible push operation must be used when possible. Pushing data using an operation that could be encoded in a shorter way makes the script evaluate to false. See reference: [[#push-operators|Push operators]].", "category": "bips" }, { "instruction": "Hey, I need to set up Bitcoin Operations Guide - what's the command line way to do that?", "input": "", "output": "# '''Zero-padded number pushes''' Any time a script opcode consumes a stack value that is interpreted as a number, it must be encoded in its shortest possible form. 'Negative zero' is not allowed. See reference: [[#numbers|Numbers]].", "category": "bips" }, { "instruction": "What's the deal with Bitcoin Operations Guide in Bitcoin? Explain it like I'm a friend.", "input": "", "output": "# '''Inherent ECDSA signature malleability''' We require that the S value inside ECDSA signatures is at most the curve order divided by 2 (essentially restricting this value to its lower half range). See reference: [[#low-s-values-in-signatures|Low S values in signatures]].", "category": "bips" }, { "instruction": "Can you show me the CLI commands for Bitcoin Operations Guide?", "input": "", "output": "# '''Superfluous scriptSig operations''' scriptPubKey evaluation will be required to result in a single non-zero value. If any extra data elements remain on the stack, the script evaluates to false.", "category": "bips" }, { "instruction": "I'm stuck with '''Inputs ignored by scripts''' The (unnecessary) extra stack element consumed by OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY must be the empty byte array (the result of OP_0). Anything else makes the script evaluate to false. - what should I check?", "input": "", "output": "===Block validity===\n\nTo introduce these new rules in the network, we add both v3 blocks and v3 transactions. v2 is skipped for transactions to keep the version numbers between transaction and block rules in sync. v2 transactions are treated identically to v1 transactions.\nThe same mechanism as in BIP 0034 is used to introduce v3 blocks. When 75% of the past 1000 blocks are v3, a new consensus rule is activated:\n* All transactions in v3 blocks are required to follow rules #1-#2.\n* v3 (and higher) transactions in v3 blocks are required to follow rules #3-#7 as well.\n\nWhen 95% of the past 1000 blocks are v3 or higher, v2 blocks become invalid entirely. Note however that v1 (and v2) transactions remain valid forever.\n\n===References===\n\nBelow is a summary of the effects on signatures, their encoding and data pushes.\n\n====Low S values in signatures====\n\nThe value S in signatures must be between 0x1 and 0x7FFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF 5D576E73 57A4501D DFE92F46 681B20A0 (inclusive). If S is too high, simply replace it by S' = 0xFFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141 - S.\n\nSignatures produced by the OpenSSL library are not guaranteed to be consistent with this constraint. Version 0.9.3 of the reference client provides [https://github.com/bitcoin/bitcoin/blob/v0.9.3/src/key.cpp#L202-L227 an example] for detection and correction.\n\nThe constraints on the value R are unchanged w.r.t. ECDSA, and values can be between 0x1 and 0xFFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364140 (inclusive).\n\n====DER encoding====\nFor reference, here is how to encode signatures correctly in DER format.\n\n0x30 [total-length] 0x02 [R-length] [R] 0x02 [S-length] [S] [sighash-type]\n* total-length: 1-byte length descriptor of everything that follows, excluding the sighash byte.\n* R-length: 1-byte length descriptor of the R value that follows.\n* R: arbitrary-length big-endian encoded R value. It cannot start with any 0x00 bytes, unless the first byte that follows is 0x80 or higher, in which case a single 0x00 is required.\n* S-length: 1-byte length descriptor of the S value that follows.\n* S: arbitrary-length big-endian encoded S value. The same rules apply as for R.\n* sighash-type: 1-byte hashtype flag (only 0x01, 0x02, 0x03, 0x81, 0x82 and 0x83 are allowed).\nThis is already enforced by the reference client as of version 0.8.0 (only as relay policy, not as a consensus rule).\n\nThis rule, combined with the low S requirement above, results in S-length being at most 32 (and R-length at most 33), and the total signature size being at most 72 bytes (and on average 71.494 bytes).\n\n====Push operators====\n\n* Pushing an empty byte sequence must use OP_0.\n* Pushing a 1-byte sequence of byte 0x01 through 0x10 must use OP_n.\n* Pushing the byte 0x81 must use OP_1NEGATE.\n* Pushing any other byte sequence up to 75 bytes must use the normal data push (opcode byte n, with n the number of bytes, followed n bytes of data being pushed).\n* Pushing 76 to 255 bytes must use OP_PUSHDATA1.\n* Pushing 256 to 520 bytes must use OP_PUSHDATA2.\n* OP_PUSHDATA4 can never be used, as pushes over 520 bytes are not allowed, and those below can be done using other operators.\n* Any other operation is not considered to be a push.\n\n====Numbers====\n\nThe native data type of stack elements is byte arrays, but some operations interpret arguments as integers. The used encoding is little endian with an explicit sign bit (the highest bit of the last byte). The shortest encodings for numbers are (with the range boundaries encodings given in hex between ()).\n* 0: OP_0; (00)\n* 1..16: OP_1..OP_16; (51)..(60)\n* -1: OP_1NEGATE; (79)\n* -127..-2 and 17..127: normal 1-byte data push; (01 FF)..(01 82) and (01 11)..(01 7F)\n* -32767..-128 and 128..32767: normal 2-byte data push; (02 FF FF)..(02 80 80) and (02 80 00)..(02 FF 7F)\n* -8388607..-32768 and 32768..8388607: normal 3-byte data push; (03 FF FF FF)..(03 00 80 80) and (03 00 80 00)..(03 FF FF 7F)\n* -2147483647..-8388608 and 8388608..2147483647: normal 4-byte data push; (04 FF FF FF FF)..(04 00 00 80 80) and (04 00 00 80 00)..(04 FF FF FF 7F)\n* Any other numbers cannot be encoded.\n\nIn particular, note that zero could be encoded as (01 80) (negative zero) if using the non-shortest form is allowed.\n\n==Compatibility==\n\n'''Relay of transactions''' A new node software version is released which makes v3 transactions standard, and relays them when their scriptSigs satisfy the above rules. Relaying of v1 transactions is unaffected. A v1 transaction spending an output created by a v3 transaction is also unaffected.\n\n'''Wallet updates''' As v3 transactions are non-standard currently, it is not possible to start creating them immediately. Software can be checked to confirm to the new rules of course, but using v3 should only start when a significant part of the network's nodes has upgraded to compatible code. Its intended meaning is \"I want this transaction protected from malleability\", and remains a choice of the wallet software.", "category": "bips" }, { "instruction": "How do I troubleshoot 
 issues?",
    "input": "",
    "output": "BIP: 68\n  Layer: Consensus (soft fork)\n  Title: Relative lock-time using consensus-enforced sequence numbers\n  Authors: Mark Friedenbach \n           BtcDrak \n           Nicolas Dorier \n           kinoshitajona \n  Status: Deployed\n  Type: Specification\n  Assigned: 2015-05-28\n
\n\n==Abstract==\n\nThis BIP introduces relative lock-time (RLT) consensus-enforced semantics of the sequence number field to enable a signed transaction input to remain invalid for a defined period of time after confirmation of its corresponding outpoint.\n\n==Motivation==\n\nBitcoin transactions have a sequence number field for each input. The original idea appears to have been that a transaction in the mempool would be replaced by using the same input with a higher sequence value. Although this was not properly implemented, it assumes miners would prefer higher sequence numbers even if the lower ones were more profitable to mine. However, a miner acting on profit motives alone would break that assumption completely. The change described by this BIP repurposes the sequence number for new use cases without breaking existing functionality. It also leaves room for future expansion and other use cases.\n\nThe transaction nLockTime is used to prevent the mining of a transaction until a certain date. nSequence will be repurposed to prevent mining of a transaction until a certain age of the spent output in blocks or timespan. This, among other uses, allows bi-directional payment channels as used in [https://github.com/ElementsProject/lightning/raw/master/doc/miscellaneous/deployable-lightning.pdf Hashed Timelock Contracts (HTLCs)] and [https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki#Bidirectional_Payment_Channels BIP112].\n\n==Specification==\n\nThis specification defines the meaning of sequence numbers for transactions with an nVersion greater than or equal to 2 for which the rest of this specification relies on.\n\nAll references to median-time-past (MTP) are as defined by BIP113.\n\nIf bit (1 << 31) of the sequence number is set, then no consensus meaning is applied to the sequence number and can be included in any block under all currently possible circumstances.\n\nIf bit (1 << 31) of the sequence number is not set, then the sequence number is interpreted as an encoded relative lock-time.\n\nThe sequence number encoding is interpreted as follows:\n\nBit (1 << 22) determines if the relative lock-time is time-based or block based: If the bit is set, the relative lock-time specifies a timespan in units of 512 seconds granularity. The timespan starts from the median-time-past of the output’s previous block, and ends at the MTP of the previous block. If the bit is not set, the relative lock-time specifies a number of blocks.\n\nThe flag (1<<22) is the highest order bit in a 3-byte signed integer for use in bitcoin scripts as a 3-byte PUSHDATA with OP_CHECKSEQUENCEVERIFY (BIP 112).\n\nThis specification only interprets 16 bits of the sequence number as relative lock-time, so a mask of 0x0000ffff MUST be applied to the sequence field to extract the relative lock-time. The 16-bit specification allows for a year of relative lock-time and the remaining bits allow for future expansion.\n\n\n\nFor time based relative lock-time, 512 second granularity was chosen because bitcoin blocks are generated every 600 seconds. So when using block-based or time-based, the same amount of time can be encoded with the available number of bits. Converting from a sequence number to seconds is performed by multiplying by 512 = 2^9, or equivalently shifting up by 9 bits.\n\nWhen the relative lock-time is time-based, it is interpreted as a minimum block-time constraint over the input's age. A relative time-based lock-time of zero indicates an input which can be included in any block. More generally, a relative time-based lock-time n can be included into any block produced 512 * n seconds after the mining date of the output it is spending, or any block thereafter.\nThe mining date of the output is equal to the median-time-past of the previous block which mined it.\n\nThe block produced time is equal to the median-time-past of its previous block.\n\nWhen the relative lock-time is block-based, it is interpreted as a minimum block-height constraint over the input's age. A relative block-based lock-time of zero indicates an input which can be included in any block. More generally, a relative block lock-time n can be included n blocks after the mining date of the output it is spending, or any block thereafter.\n\nThe new rules are not applied to the nSequence field of the input of the coinbase transaction.\n\n==Implementation==\n\nA reference implementation is provided by the following pull request\n\nhttps://github.com/bitcoin/bitcoin/pull/7184\n\n
\nenum {\n    /* Interpret sequence numbers as relative lock-time constraints. */\n    LOCKTIME_VERIFY_SEQUENCE = (1 << 0),\n};\n\n/* Setting nSequence to this value for every input in a transaction\n * disables nLockTime. */\nstatic const uint32_t SEQUENCE_FINAL = 0xffffffff;\n\n/* Below flags apply in the context of BIP 68*/\n/* If this flag set, CTxIn::nSequence is NOT interpreted as a\n * relative lock-time. */\nstatic const uint32_t SEQUENCE_LOCKTIME_DISABLE_FLAG = (1 << 31);\n\n/* If CTxIn::nSequence encodes a relative lock-time and this flag\n * is set, the relative lock-time has units of 512 seconds,\n * otherwise it specifies blocks with a granularity of 1. */\nstatic const uint32_t SEQUENCE_LOCKTIME_TYPE_FLAG = (1 << 22);\n\n/* If CTxIn::nSequence encodes a relative lock-time, this mask is\n * applied to extract that lock-time from the sequence field. */\nstatic const uint32_t SEQUENCE_LOCKTIME_MASK = 0x0000ffff;\n\n/* In order to use the same number of bits to encode roughly the\n * same wall-clock duration, and because blocks are naturally\n * limited to occur every 600s on average, the minimum granularity\n * for time-based relative lock-time is fixed at 512 seconds.\n * Converting from CTxIn::nSequence to seconds is performed by\n * multiplying by 512 = 2^9, or equivalently shifting up by\n * 9 bits. */\nstatic const int SEQUENCE_LOCKTIME_GRANULARITY = 9;\n\n/**\n * Calculates the block height and previous block's median time past at\n * which the transaction will be considered final in the context of BIP 68.\n * Also removes from the vector of input heights any entries which did not\n * correspond to sequence locked inputs as they do not affect the calculation.\n */\nstatic std::pair CalculateSequenceLocks(const CTransaction &tx, int flags, std::vector* prevHeights, const CBlockIndex& block)\n{\n    assert(prevHeights->size() == tx.vin.size());\n\n    // Will be set to the equivalent height- and time-based nLockTime\n    // values that would be necessary to satisfy all relative lock-\n    // time constraints given our view of block chain history.\n    // The semantics of nLockTime are the last invalid height/time, so\n    // use -1 to have the effect of any height or time being valid.\n    int nMinHeight = -1;\n    int64_t nMinTime = -1;\n\n    // tx.nVersion is signed integer so requires cast to unsigned otherwise\n    // we would be doing a signed comparison and half the range of nVersion\n    // wouldn't support BIP 68.\n    bool fEnforceBIP68 = static_cast(tx.nVersion) >= 2\n                      && flags & LOCKTIME_VERIFY_SEQUENCE;\n\n    // Do not enforce sequence numbers as a relative lock time\n    // unless we have been instructed to\n    if (!fEnforceBIP68) {\n        return std::make_pair(nMinHeight, nMinTime);\n    }\n\n    for (size_t txinIndex = 0; txinIndex < tx.vin.size(); txinIndex++) {\n        const CTxIn& txin = tx.vin[txinIndex];\n\n        // Sequence numbers with the most significant bit set are not\n        // treated as relative lock-times, nor are they given any\n        // consensus-enforced meaning at this point.\n        if (txin.nSequence & CTxIn::SEQUENCE_LOCKTIME_DISABLE_FLAG) {\n            // The height of this input is not relevant for sequence locks\n            (*prevHeights)[txinIndex] = 0;\n            continue;\n        }\n\n        int nCoinHeight = (*prevHeights)[txinIndex];\n\n        if (txin.nSequence & CTxIn::SEQUENCE_LOCKTIME_TYPE_FLAG) {\n            int64_t nCoinTime = block.GetAncestor(std::max(nCoinHeight-1, 0))->GetMedianTimePast();\n            // NOTE: Subtract 1 to maintain nLockTime semantics\n            // BIP 68 relative lock times have the semantics of calculating\n            // the first block or time at which the transaction would be\n            // valid. When calculating the effective block time or height\n            // for the entire transaction, we switch to using the\n            // semantics of nLockTime which is the last invalid block\n            // time or height.  Thus we subtract 1 from the calculated\n            // time or height.\n\n            // Time-based relative lock-times are measured from the\n            // smallest allowed timestamp of the block containing the\n            // txout being spent, which is the median time past of the\n            // block prior.\n            nMinTime = std::max(nMinTime, nCoinTime + (int64_t)((txin.nSequence & CTxIn::SEQUENCE_LOCKTIME_MASK) << CTxIn::SEQUENCE_LOCKTIME_GRANULARITY) - 1);\n        } else {\n            nMinHeight = std::max(nMinHeight, nCoinHeight + (int)(txin.nSequence & CTxIn::SEQUENCE_LOCKTIME_MASK) - 1);\n        }\n    }\n\n    return std::make_pair(nMinHeight, nMinTime);\n}\n\nstatic bool EvaluateSequenceLocks(const CBlockIndex& block, std::pair lockPair)\n{\n    assert(block.pprev);\n    int64_t nBlockTime = block.pprev->GetMedianTimePast();\n    if (lockPair.first >= block.nHeight || lockPair.second >= nBlockTime)\n        return false;\n\n    return true;\n}\n\nbool SequenceLocks(const CTransaction &tx, int flags, std::vector* prevHeights, const CBlockIndex& block)\n{\n    return EvaluateSequenceLocks(block, CalculateSequenceLocks(tx, flags, prevHeights, block));\n}\n\nbool CheckSequenceLocks(const CTransaction &tx, int flags)\n{\n    AssertLockHeld(cs_main);\n    AssertLockHeld(mempool.cs);\n\n    CBlockIndex* tip = chainActive.Tip();\n    CBlockIndex index;\n    index.pprev = tip;\n    // CheckSequenceLocks() uses chainActive.Height()+1 to evaluate\n    // height based locks because when SequenceLocks() is called within\n    // ConnectBlock(), the height of the block *being*\n    // evaluated is what is used.\n    // Thus if we want to know if a transaction can be part of the\n    // *next* block, we need to use one more than chainActive.Height()\n    index.nHeight = tip->nHeight + 1;\n\n    // pcoinsTip contains the UTXO set for chainActive.Tip()\n    CCoinsViewMemPool viewMemPool(pcoinsTip, mempool);\n    std::vector prevheights;\n    prevheights.resize(tx.vin.size());\n    for (size_t txinIndex = 0; txinIndex < tx.vin.size(); txinIndex++) {\n        const CTxIn& txin = tx.vin[txinIndex];\n        CCoins coins;\n        if (!viewMemPool.GetCoins(txin.prevout.hash, coins)) {\n            return error(\"%s: Missing input\", __func__);\n        }\n        if (coins.nHeight == MEMPOOL_HEIGHT) {\n            // Assume all mempool transactions are confirmed in the next block\n            prevheights[txinIndex] = tip->nHeight + 1;\n        } else {\n            prevheights[txinIndex] = coins.nHeight;\n        }\n    }\n\n    std::pair lockPair = CalculateSequenceLocks(tx, flags, &prevheights, index);\n    return EvaluateSequenceLocks(index, lockPair);\n}\n
\n\n==Acknowledgments==\n\nCredit goes to Gregory Maxwell for providing a succinct and clear description of the behavior of this change, which became the basis of this BIP text.\n\nThis BIP was edited by BtcDrak, Nicolas Dorier and kinoshitajona.\n\n==Deployment==\n\nThis BIP is to be deployed by \"versionbits\" BIP9 using bit 0.\n\nFor Bitcoin '''mainnet''', the BIP9 '''starttime''' will be midnight 1st May 2016 UTC (Epoch timestamp 1462060800) and BIP9 '''timeout''' will be midnight 1st May 2017 UTC (Epoch timestamp 1493596800).\n\nFor Bitcoin '''testnet''', the BIP9 '''starttime''' will be midnight 1st March 2016 UTC (Epoch timestamp 1456790400) and BIP9 '''timeout''' will be midnight 1st May 2017 UTC (Epoch timestamp 1493596800).\n\nThis BIP must be deployed simultaneously with BIP112 and BIP113 using the same deployment mechanism.\n\n==Compatibility==\n\nThe only use of sequence numbers by the Bitcoin Core reference client software is to disable checking the nLockTime constraints in a transaction. The semantics of that application are preserved by this BIP.\n\nAs can be seen from the specification section, a number of bits are undefined by this BIP to allow for other use cases by setting bit (1 << 31) as the remaining 31 bits have no meaning under this BIP. Additionally, bits (1 << 23) through (1 << 30) inclusive have no meaning at all when bit (1 << 31) is unset.\n\nAdditionally, this BIP specifies only 16 bits to actually encode relative lock-time meaning a further 6 are unused (1 << 16 through 1 << 21 inclusive). This allows the possibility to increase granularity by soft-fork, or for increasing the maximum possible relative lock-time in the future.\n\nThe most efficient way to calculate sequence number from relative lock-time is with bit masks and shifts:\n\n
\n    // 0 <= nHeight <= 65,535 blocks (1.25 years)\n    nSequence = nHeight;\n    nHeight = nSequence & 0x0000ffff;\n\n    // 0 <= nTime < 33,554,431 seconds (1.06 years)\n    nSequence = (1 << 22) | (nTime >> 9);\n    nTime = (nSequence & 0x0000ffff) << 9;\n
\n\n==References==\n\nBitcoin mailing list discussion: https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07864.html\n\nBIP9: https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki\n\nBIP112: https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki\n\nBIP113: https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki\n\nHashed Timelock Contracts (HTLCs): https://github.com/ElementsProject/lightning/raw/master/doc/miscellaneous/deployable-lightning.pdf", "category": "bips" }, { "instruction": "What are the best practices for 
?",
    "input": "",
    "output": "BIP: 141\n  Layer: Consensus (soft fork)\n  Title: Segregated Witness (Consensus layer)\n  Authors: Eric Lombrozo \n           Johnson Lau \n           Pieter Wuille \n  Status: Deployed\n  Type: Specification\n  Assigned: 2015-12-21\n  License: PD\n
\n\n==Abstract==\n\nThis BIP defines a new structure called a \"witness\" that is committed to blocks separately from the transaction merkle tree. This structure contains data required to check transaction validity but not required to determine transaction effects. In particular, scripts and signatures are moved into this new structure.\n\nThe witness is committed in a tree that is nested into the block's existing merkle root via the coinbase transaction for the purpose of making this BIP soft fork compatible. A future hard fork can place this tree in its own branch.\n\n==Motivation==\n\nThe entirety of the transaction's effects are determined by output consumption (spends) and new output creation. Other transaction data, and signatures in particular, are only required to validate the blockchain state, not to determine it.\n\nBy removing this data from the transaction structure committed to the transaction merkle tree, several problems are fixed:", "category": "bips" }, { "instruction": "Walk me through setting up '''Nonintentional malleability becomes impossible'''. Since signature data is no longer part of the transaction hash, changes to how the transaction was signed are no longer relevant to transaction identification. As a solution of transaction malleability, this is superior to the canonical signature approach ([https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki BIP62]): step by step", "input": "", "output": "#* It prevents involuntary transaction malleability for any type of scripts, as long as all inputs are signed (with at least one CHECKSIG or CHECKMULTISIG operation)\n#* In the case of an m-of-n CHECKMULTISIG script, a transaction is malleable only with agreement of m private key holders (as opposed to only 1 private key holder with BIP62)\n#* It prevents involuntary transaction malleability due to unknown ECDSA signature malleability\n#* It allows creation of unconfirmed transaction dependency chains without counterparty risk, an important feature for offchain protocols such as the Lightning Network", "category": "bips" }, { "instruction": "What commands would you run to work with Bitcoin Operations Guide?", "input": "", "output": "# '''Transmission of signature data becomes optional'''. It is needed only if a peer is trying to validate a transaction instead of just checking its existence. This reduces the size of SPV proofs and potentially improves the privacy of SPV clients as they can download more transactions using the same bandwidth.", "category": "bips" }, { "instruction": "I want to understand '''Some constraints could be bypassed with a soft fork''' by moving part of the transaction data to a structure unknown to current protocol, for example: from a technical perspective", "input": "", "output": "#* Size of witness could be ignored / discounted when calculating the block size, effectively increasing the block size to some extent\n#* Hard coded constants, such as maximum data push size (520 bytes) or sigops limit could be reevaluated or removed\n#* New script system could be introduced without any limitation from the existing script semantic. For example, a new transaction digest algorithm for transaction signature verification is described in [https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki BIP143]\n\n==Specification==\n\n=== Transaction ID ===\n\nA new data structure, witness, is defined. Each transaction will have 2 IDs.\n\nDefinition of txid remains unchanged: the double SHA256 of the traditional serialization format:\n\n [nVersion][txins][txouts][nLockTime]\n\nA new wtxid is defined: the double SHA256 of the new serialization with witness data:\n\n [nVersion][marker][flag][txins][txouts][witness][nLockTime]\n\nFormat of nVersion, txins, txouts, and nLockTime are same as traditional serialization.\n\nThe marker MUST be a 1-byte zero value: 0x00.\n\nThe flag MUST be a 1-byte non-zero value. Currently, 0x01 MUST be used.\n\nThe witness is a serialization of all witness fields of the transaction. Each txin is associated with a witness field. A witness field starts with a var_int to indicate the number of stack items for the txin. It is followed by stack items, with each item starts with a var_int to indicate the length. Witness data is NOT script.\n\nA non-witness program (defined hereinafter) txin MUST be associated with an empty witness field, represented by a 0x00. If all txins are not witness program, a transaction's wtxid is equal to its txid.\n\n=== Commitment structure ===\n\nA new block rule is added which requires a commitment to the wtxid. The wtxid of coinbase transaction is assumed to be 0x0000....0000.\n\nA witness root hash is calculated with all those wtxid as leaves, in a way similar to the hashMerkleRoot in the block header.\n\nThe commitment is recorded in a scriptPubKey of the coinbase transaction. It must be at least 38 bytes, with the first 6-byte of 0x6a24aa21a9ed, that is:\n\n 1-byte - OP_RETURN (0x6a)\n 1-byte - Push the following 36 bytes (0x24)\n 4-byte - Commitment header (0xaa21a9ed)\n 32-byte - Commitment hash: Double-SHA256(witness root hash|witness reserved value)\n\n 39th byte onwards: Optional data with no consensus meaning\n\nand the coinbase's input's witness must consist of a single 32-byte array for the witness reserved value.\n\nIf there are more than one scriptPubKey matching the pattern, the one with highest output index is assumed to be the commitment.\n\nIf all transactions in a block do not have witness data, the commitment is optional.\n\n=== Witness program ===\n\nA scriptPubKey (or redeemScript as defined in BIP16/P2SH) that consists of a 1-byte push opcode (one of OP_0,OP_1,OP_2,...,OP_16) followed by a direct data push between 2 and 40 bytes gets a new special meaning. The value of the first push is called the \"version byte\". The following byte vector pushed is called the \"witness program\".\nIn more detail, this means a scriptPubKey or redeemScript which consists of (in order):\n* First, byte 0x00 (OP_0) or any byte between 0x51 (OP_1) and 0x60 (OP_16) inclusive (the version byte).\n* Then, a byte ''L'' between 0x02 (push of 2 bytes) and 0x28 (push of 40 bytes) inclusive.\n* Finally, ''L'' arbitrary bytes (the witness program).\n\nThere are two cases in which witness validation logic are triggered. Each case determines the location of the witness version byte and program, as well as the form of the scriptSig:", "category": "bips" }, { "instruction": "Can you explain Bitcoin Operations Guide like we're having a beer and talking Bitcoin?", "input": "", "output": "# Triggered by a scriptPubKey that is exactly a push of a version byte, plus a push of a witness program. The scriptSig must be exactly empty or validation fails. (''\"native witness program\"'')", "category": "bips" }, { "instruction": "How would you explain Triggered when a scriptPubKey is a P2SH script, and the BIP16 redeemScript pushed in the scriptSig is exactly a push of a version byte plus a push of a witness program. The scriptSig must be exactly a push of the BIP16 redeemScript or validation fails. (''\"P2SH witness program\"'') to someone who knows Bitcoin basics?", "input": "", "output": "If the version byte is 0, and the witness program is 20 bytes (''L = 20''):\n* It is interpreted as a pay-to-witness-public-key-hash (P2WPKH) program.\n* The witness must consist of exactly 2 items (≤ 520 bytes each). The first one a signature, and the second one a public key.\n* The HASH160 of the public key must match the 20-byte witness program.\n* After normal script evaluation, the signature is verified against the public key with CHECKSIG operation. The verification must result in a single TRUE on the stack.\n\nIf the version byte is 0, and the witness program is 32 bytes (''L = 32''):\n* It is interpreted as a pay-to-witness-script-hash (P2WSH) program.\n* The witness must consist of an input stack to feed to the script, followed by a serialized script (witnessScript).\n* The witnessScript (≤ 10,000 bytes) is popped off the initial witness stack. SHA256 of the witnessScript must match the 32-byte witness program.\n* The witnessScript is deserialized, and executed after normal script evaluation with the remaining witness stack (≤ 520 bytes for each stack item).\n* The script must not fail, and result in exactly a single TRUE on the stack.\n\nIf the version byte is 0, but the witness program is neither 20 nor 32 bytes, the script must fail.For example, a scriptPubKey with OP_0 followed by a 40-byte non-zero data push will fail due to incorrect program size. However, a scriptPubKey with OP_0 followed by a 41-byte non-zero data push will pass, since it is not considered to be a witness program\n\nIf the version byte is 1 to 16, no further interpretation of the witness program or witness stack happens, and there is no size restriction for the witness stack. These versions are reserved for future extensions.For backward compatibility, for any version byte from 0 to 16, the script must fail if the witness program has a CastToBool value of zero. However, having a hash like this is a successful preimage attack against the hash function, and the risk is negligible.\n\n=== Other consensus critical limits ===\n\n==== Block size ====\n\nBlocks are currently limited to 1,000,000 bytes (1MB) total size. We change this restriction as follows:\n\n''Block weight'' is defined as ''Base size'' * 3 + ''Total size''. (rationaleRationale of using a single composite constraint, instead of two separate limits such as 1MB base data and 3MB witness data: Using two separate limits would make mining and fee estimation nearly impossible. Miners would need to solve a complex non-linear optimization problem to find the set of transactions that maximize fees given both constraints, and wallets would not be able to know what to pay as it depends on which of the two conditions is most constrained by the time miners try to produce blocks with their transactions in. Another problem with such an approach is freeloading. Once a set of transactions hit the base data 1MB constraint, up to 3MB extra data could be added to the witness by just minimally increasing the fee. The marginal cost for extra witness space effectively becomes zero in that case.)\n\n''Base size'' is the block size in bytes with the original transaction serialization without any witness-related data, as seen by a non-upgraded node.\n\n''Total size'' is the block size in bytes with transactions serialized as described in [[bip-0144.mediawiki|BIP144]], including base data and witness data.\n\nThe new rule is ''block weight'' ≤ 4,000,000.\n\n==== Sigops ====\n\nSigops per block is currently limited to 20,000. We change this restriction as follows:\n\nSigops in the current pubkey script, signature script, and P2SH check script are counted at 4 times their previous value.\nThe sigop limit is likewise quadrupled to ≤ 80,000.\n\nEach P2WPKH input is counted as 1 sigop. In addition, opcodes within a P2WSH witnessScript are counted identically as previously within the P2SH redeemScript. That is, CHECKSIG is counted as only 1 sigop. When preceded by OP_1 to OP_16 CHECKMULTISIG is counted as 1 to 16 sigops respectively, otherwise it is counted as 20 sigops. This rule applies to both native witness program and P2SH witness program.\n\n=== Additional definitions ===\n\nThe following definitions are not used for consensus limits, but are suggested to provide language consistent with the terminology introduced above.\n\n==== Transaction size calculations ====\n\n''Transaction weight'' is defined as ''Base transaction size'' * 3 + ''Total transaction size'' (ie. the same method as calculating ''Block weight'' from ''Base size'' and ''Total size'').\n\n''Virtual transaction size'' is defined as ''Transaction weight'' / 4 (rounded up to the next integer).\n\n''Base transaction size'' is the size of the transaction serialised with the witness data stripped.\n\n''Total transaction size'' is the transaction size in bytes serialized as described in [[bip-0144.mediawiki|BIP144]], including base data and witness data.\n\n=== New script semantics ===\n\nDespite that the script language for P2WPKH and P2WSH looks very similar to pre-segregated witness script, there are several notable differences. Users MUST NOT assume that a script spendable in pre-segregated witness system would also be spendable as a P2WPKH or P2WSH script. Before large-scale deployment in the production network, developers should test the scripts on testnet with the default relay policy turned on, and with a small amount of money after BIP141 is activated on mainnet.\n\nA major difference at consensus level is described in [https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki BIP143], as a new transaction digest algorithm for signature verification in version 0 witness program.\n\nThree relay and mining policies are also included in the first release of segregated witness at reference implementation version 0.13.1. Softforks based on these policies are likely to be proposed in the near future. To avoid indefinite delay in transaction confirmation and permanent fund loss in a potential softfork, users MUST observe the new semantics carefully:", "category": "bips" }, { "instruction": "I'm trying to understand Bitcoin Operations Guide - can you walk me through it?", "input": "", "output": "# Only compressed public keys are accepted in P2WPKH and P2WSH (See [https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki#Restrictions_on_public_key_type BIP143])", "category": "bips" }, { "instruction": "Hey, I need to set up Bitcoin Operations Guide - what's the command line way to do that?", "input": "", "output": "# The argument of OP_IF/NOTIF in P2WSH must be minimalhttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-August/013014.html", "category": "bips" }, { "instruction": "What's the deal with Signature(s) must be null vector(s) if an OP_CHECKSIG or OP_CHECKMULTISIG is failed (for both pre-segregated witness script and P2WSH. See [https://github.com/bitcoin/bips/blob/master/bip-0146.mediawiki BIP146]) in Bitcoin? Explain it like I'm a friend.", "input": "", "output": "== Examples ==\n\n=== P2WPKH ===\n\nThe following example is a version 0 pay-to-witness-public-key-hash (P2WPKH):\n\n witness: \n scriptSig: (empty)\n scriptPubKey: 0 <20-byte-key-hash>\n (0x0014{20-byte-key-hash})\n\nThe '0' in scriptPubKey indicates the following push is a version 0 witness program. The length of the witness program indicates that it is a P2WPKH type. The witness must consist of exactly 2 items. The HASH160 of the pubkey in witness must match the witness program.\n\nThe signature is verified as\n\n CHECKSIG\n\nComparing with a traditional P2PKH output, the P2WPKH equivalent occupies 3 less bytes in the scriptPubKey, and moves the signature and public key from scriptSig to witness.\n\n=== P2WPKH nested in BIP16 P2SH ===\n\nThe following example is the same P2WPKH, but nested in a BIP16 P2SH output.\n\n witness: \n scriptSig: <0 <20-byte-key-hash>>\n (0x160014{20-byte-key-hash})\n scriptPubKey: HASH160 <20-byte-script-hash> EQUAL\n (0xA914{20-byte-script-hash}87)\n\nThe only item in scriptSig is hashed with HASH160, compared against the 20-byte-script-hash in scriptPubKey, and interpreted as:\n\n 0 <20-byte-key-hash>\n\nThe public key and signature are then verified as described in the previous example.\n\nComparing with the previous example, the scriptPubKey is 1 byte bigger and the scriptSig is 23 bytes bigger. Although a nested witness program is less efficient, its payment address is fully transparent and backward compatible for all Bitcoin reference client since version 0.6.0.\n\n=== P2WSH ===\n\nThe following example is an 1-of-2 multi-signature version 0 pay-to-witness-script-hash (P2WSH).\n\n witness: 0 <1 2 CHECKMULTISIG>\n scriptSig: (empty)\n scriptPubKey: 0 <32-byte-hash>\n (0x0020{32-byte-hash})\n\nThe '0' in scriptPubKey indicates the following push is a version 0 witness program. The length of the witness program indicates that it is a P2WSH type. The last item in the witness (the \"witnessScript\") is popped off, hashed with SHA256, compared against the 32-byte-hash in scriptPubKey, and deserialized:\n\n 1 2 CHECKMULTISIG\n\nThe script is executed with the remaining data from witness:\n\n 0 1 2 CHECKMULTISIG\n\nP2WSH allows maximum script size of 10,000 bytes, as the 520-byte push limit is bypassed.\n\nThe scriptPubKey occupies 34 bytes, as opposed to 23 bytes of BIP16 P2SH. The increased size improves security against possible collision attacks, as 280 work is not infeasible anymore (By the end of 2015, 284 hashes have been calculated in Bitcoin mining since the creation of Bitcoin). The spending script is same as the one for an equivalent BIP16 P2SH output but is moved to witness.\n\n=== P2WSH nested in BIP16 P2SH ===\n\nThe following example is the same 1-of-2 multi-signature P2WSH script, but nested in a BIP16 P2SH output.\n\n witness: 0 <1 2 CHECKMULTISIG>\n scriptSig: <0 <32-byte-hash>>\n (0x220020{32-byte-hash})\n scriptPubKey: HASH160 <20-byte-hash> EQUAL\n (0xA914{20-byte-hash}87)\n\nThe only item in scriptSig is hashed with HASH160, compared against the 20-byte-hash in scriptPubKey, and interpreted as:\n\n 0 <32-byte-hash>\n\nThe P2WSH witnessScript is then executed as described in the previous example.\n\nComparing with the previous example, the scriptPubKey is 11 bytes smaller (with reduced security) while witness is the same. However, it also requires 35 bytes in scriptSig.\n\n=== Extensible commitment structure ===\n\nThe new commitment in coinbase transaction is a hash of the witness root hash and a witness reserved value. The witness reserved value currently has no consensus meaning, but in the future allows new commitment values for future softforks. For example, if a new consensus-critical commitment is required in the future, the commitment in coinbase becomes:\n\n Double-SHA256(Witness root hash|Hash(new commitment|witness reserved value))\n\nFor backward compatibility, the Hash(new commitment|witness reserved value) will go to the coinbase witness, and the witness reserved value will be recorded in another location specified by the future softfork. Any number of new commitment could be added in this way.\n\nAny commitments that are not consensus-critical to Bitcoin, such as merge-mining, MUST NOT use the witness reserved value to preserve the ability to do upgrades of the Bitcoin consensus protocol.\n\nThe optional data space following the commitment also leaves room for metadata of future softforks, and MUST NOT be used for other purpose.\n\n=== Trust-free unconfirmed transaction dependency chain ===\n\nSegregated witness fixes the problem of transaction malleability fundamentally, which enables the building of unconfirmed transaction dependency chains in a trust-free manner.\n\nTwo parties, Alice and Bob, may agree to send certain amount of Bitcoin to a 2-of-2 multisig output (the \"funding transaction\"). Without signing the funding transaction, they may create another transaction, time-locked in the future, spending the 2-of-2 multisig output to third account(s) (the \"spending transaction\"). Alice and Bob will sign the spending transaction and exchange the signatures. After examining the signatures, they will sign and commit the funding transaction to the blockchain. Without further action, the spending transaction will be confirmed after the lock-time and release the funding according to the original contract. It also retains the flexibility of revoking the original contract before the lock-time, by another spending transaction with shorter lock-time, but only with mutual-agreement of both parties.\n\nSuch setups are not possible with BIP62 as the malleability fix, since the spending transaction could not be created without both parties first signing the funding transaction. If Alice reveals the funding transaction signature before Bob does, Bob is able to lock up the funding indefinitely without ever signing the spending transaction.\n\nUnconfirmed transaction dependency chain is a fundamental building block of more sophisticated payment networks, such as duplex micropayment channel and the Lightning Network, which have the potential to greatly improve the scalability and efficiency of the Bitcoin system.\n\n== Future extensions ==\n\n=== Compact fraud proof for SPV nodes ===\n\nBitcoin right now only has two real security models. A user either runs a full-node which validates every block with all rules in the system, or a SPV (Simple Payment Verification) client which only validates the headers as a proof of publication of some transactions. The Bitcoin whitepaper suggested that SPV nodes may accept alerts from full nodes when they detect an invalid block, prompting the SPV node to download the questioned blocks and transactions for validation. This approach, however, could become a DoS attack vector as there is virtually no cost to generate a false alarm. An alarm must come with a compact, yet deterministic fraud proof.\n\nIn the current Bitcoin protocol, it is possible to generate compact fraud proof for almost all rules except a few:", "category": "bips" }, { "instruction": "Can you show me the CLI commands for Bitcoin Operations Guide?", "input": "", "output": "# It is not possible to prove a miner has introduced too many Bitcoins in the coinbase transaction outputs without showing the whole block itself and all input transactions.", "category": "bips" }, { "instruction": "I'm stuck with Bitcoin Operations Guide - what should I check?", "input": "", "output": "# It is not possible to prove the violation of any block specific constraints, such as size and sigop limits, without showing the whole block (and all input transactions in the case of sigop limit)", "category": "bips" }, { "instruction": "How do I troubleshoot It is not possible to prove the spending of a non-existing input without showing all transaction IDs in the blockchain way back to the genesis block. issues?", "input": "", "output": "Extra witness data can be committed that allows short proofs of block invalidity that SPV nodes can quickly verify:", "category": "bips" }, { "instruction": "What are the best practices for Bitcoin Operations Guide?", "input": "", "output": "# Sum trees for transaction fee can be committed making it possible to construct short proofs that the miner does not add excessive fees to the coinbase transaction. Similar for the block size and sigop count limit.", "category": "bips" }, { "instruction": "Walk me through setting up Backlinks for the outputs spent by the transaction's inputs can be provided. These backlinks consist of a block hash and an offset that thin clients can easily query and check to verify that the outputs exist. step by step", "input": "", "output": "These commitments could be included in the extensible commitment structure through a soft fork and will be transparent to nodes that do not understand such new rules.\n\n=== New script system ===\n\nSince a version byte is pushed before a witness program, and programs with unknown versions are always considered as anyone-can-spend script, it is possible to introduce any new script system with a soft fork. The witness as a structure is not restricted by any existing script semantics and constraints, the 520-byte push limit in particular, and therefore allows arbitrarily large scripts and signatures.\n\nExamples of new script systems include Schnorr signatures, which reduce the size of multisig transactions dramatically; Lamport signatures, which are quantum computing resistant; and Merklized abstract syntax trees, which allow very compact witnesses for conditional scripts with extreme complexity.\n\n=== Per-input lock-time and relative-lock-time ===\n\nCurrently there is only one nLockTime field in a transaction and all inputs must share the same value. [https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP68] enables per-input relative-lock-time using the nSequence field, however, with a limited lock-time period and resolution.\n\nWith a soft fork, it is possible to introduce a separate witness structure to allow per-input lock-time and relative-lock-time, and a new script system that could sign and manipulate the new data (like [https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP65] and [https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki BIP112]).\n\n== Backward compatibility ==\n\nAs a soft fork, older software will continue to operate without modification. Non-upgraded nodes, however, will not see nor validate the witness data and will consider all witness programs as anyone-can-spend scripts (except a few edge cases where the witness programs are equal to 0, which the script must fail). Wallets should always be wary of anyone-can-spend scripts and treat them with suspicion. Non-upgraded nodes are strongly encouraged to upgrade in order to take advantage of the new features.\n\n'''What a non-upgraded wallet can do'''\n\n* Receiving bitcoin from non-upgraded and upgraded wallets\n* Sending bitcoin to non-upgraded and upgraded wallets with traditional P2PKH address (without any benefit of segregated witness)\n* Sending bitcoin to upgraded wallets using a P2SH address\n* Sending bitcoin to upgraded wallets using a native witness program through [https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki BIP70] payment protocol\n\n'''What a non-upgraded wallet cannot do'''\n\n* Validating segregated witness transaction. It assumes such a transaction is always valid\n\n== Deployment ==\n\nThis BIP will be deployed by \"version bits\" BIP9 with the name \"segwit\" and using bit 1.\n\nFor Bitcoin mainnet, the BIP9 starttime will be midnight 15 November 2016 UTC (Epoch timestamp 1479168000) and BIP9 timeout will be midnight 15 November 2017 UTC (Epoch timestamp 1510704000).\n\nFor Bitcoin testnet, the BIP9 starttime will be midnight 1 May 2016 UTC (Epoch timestamp 1462060800) and BIP9 timeout will be midnight 1 May 2017 UTC (Epoch timestamp 1493596800).\n\n== Credits ==\n\nSpecial thanks to Gregory Maxwell for originating many of the ideas in this BIP and Luke-Jr for figuring out how to deploy this as a soft fork.\n\n== Footnotes ==\n\n\n\n== Reference Implementation ==\n\nhttps://github.com/bitcoin/bitcoin/pull/8149\n\n== References ==\n\n*[[bip-0016.mediawiki|BIP16 Pay to Script Hash]]\n*[[bip-0143.mediawiki|BIP143 Transaction Signature Verification for Version 0 Witness Program]]\n*[[bip-0144.mediawiki|BIP144 Segregated Witness (Peer Services)]]\n*[[bip-0173.mediawiki|BIP173 Base32 address format for native v0-16 witness outputs]]\n\n== Copyright ==\n\nThis document is placed in the public domain.", "category": "bips" }, { "instruction": "What commands would you run to work with 
?",
    "input": "",
    "output": "BIP: 330\n  Layer: Peer Services\n  Title: Transaction announcements reconciliation\n  Authors: Gleb Naumenko \n           Pieter Wuille \n  Status: Draft\n  Type: Specification\n  Assigned: 2019-09-25\n  License: CC0-1.0\n  License-Code: MIT\n
\n\n==Abstract==\n\nThis document specifies a P2P protocol extension for reconciliation of transaction announcements between 2 nodes, which is a building block for efficient transaction relay protocols (e.g., [https://arxiv.org/pdf/1905.10518.pdf Erlay]). This is a step towards increasing the connectivity of the network for almost no bandwidth cost.\n\n==Motivation==\n\nCurrently in the Bitcoin network, every 32-byte transaction ID is announced in at least one direction between every pair of connected peers, via INV messages. This results in high cost of announcing transactions: ''O(nodes * connections_per_node)''.\n\nA reconciliation-based protocol which uses the technique suggested in this document can have better scaling properties than INV-based flooding.\n\nIncreasing the connectivity of the network makes the network more robust to partitioning attacks; thus, improving the bandwidth scaling of transaction relay to ''O(nodes)'' (and without a high constant overhead) would allow us to improve the security of the network by increasing connectivity. It would also reduce the bandwidth required to run a Bitcoin node and potentially enable more users to run full nodes.\n\n===Erlay===\n\n[https://arxiv.org/pdf/1905.10518.pdf Erlay] is an example of a high-level transaction relay protocol which employs set reconciliation for bandwidth efficiency.\n\nNote that what we are going to describe here is a modified version from the protocol (it is different from what is presented in the paper).\n\nErlay uses both flooding (announcing using INV messages to all peers) and reconciliation to announce transactions.\nFlooding is expensive, so Erlay seeks to use it only when necessary to facilitate rapid relay over a small subset of connections.\n\nEfficient set reconciliation is meant to deliver transactions to those nodes which didn't receive a transaction via flooding, and also just make sure remaining connections are in sync (directly connected pairs of nodes are aware they have nothing to learn from each other).\n\nEfficient set reconciliation works as follows:\n1) every node keeps a reconciliation set for each peer, in which transactions are placed which would have been announced using INV messages absent this protocol\n2) once in a while every node chooses a peer from its reconciliation queue to reconcile with, resulting in both sides learning the transactions known to the other side\n3) after every reconciliation round, the corresponding reconciliation set is cleared\n\nA more detailed description of a set reconciliation round can be found below.\n\nErlay allows us to:\n* save a significant portion of the bandwidth consumed by a node\n* increase network connectivity for almost no bandwidth or latency cost\n* keep transaction propagation latency at the same level\n\nThis document proposes a P2P-layer extension which is required to enable efficient reconciliation-based protocols (like Erlay) for transaction relay.\n\n==Specification==\n\n===New data structures===\n\nSeveral new data structures are introduced to the P2P protocol first, to aid with efficient transaction relay.\n\n====32-bit short transaction IDs====\n=\nShort IDs are computed as follows:\n* Let ''salt1'' and ''salt2'' be the entropy contributed by both sides; see the \"sendtxrcncl\" message further for details how they are exchanged.\n* Sort the two salts such that ''salt1 ≤ salt2'' (which side sent what doesn't matter).\n* Compute ''h = TaggedHash(\"Tx Relay Salting\", salt1, salt2)'', where the two salts are encoded in 64-bit little-endian byte order, and TaggedHash is specified by [https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki BIP-340].\n* Let ''k0'' be the 64-bit integer obtained by interpreting the first 8 bytes of ''h'' in little-endian byte order.\n* Let ''k1'' be the 64-bit integer obtained by interpreting the second 8 bytes of ''h'' in little-endian byte order.\n* Let ''s = SipHash-2-4((k0,k1),wtxid)'', where ''wtxid'' is the transaction hash including witness data as defined by BIP141.\n* The short ID is equal to ''1 + (s mod 0xFFFFFFFF)''.\n\nThis results in approximately uniformly distributed IDs in the range ''[1..0xFFFFFFFF]'', which is a requirement for using them as elements in 32-bit sketches. See the next paragraph for details.\n\n====Short transaction ID sketches====\n\nReconciliation-based relay uses [https://www.cs.bu.edu/~reyzin/code/fuzzy.html PinSketch] BCH-based secure sketches as introduced by the [https://www.cs.bu.edu/~reyzin/fuzzy.html Fuzzy Extractors paper]. They are a form of set checksums with the following properties:\n* Sketches have a predetermined capacity, and when the number of elements in the set does not exceed the capacity, it is always possible to recover the entire set from the sketch by decoding the sketch. A sketch of nonzero b-bit elements with capacity c can be stored in bc bits.\n* A sketch of the [https://en.wikipedia.org/wiki/Symmetric_difference symmetric difference] between the two sets (i.e., all elements that occur in one but not both input sets), can be obtained by combining the sketches of those sets.\n\nThe sketches used here consists of elements of the [https://en.wikipedia.org/wiki/Finite_field finite field] ''GF(232)''. Specifically, we represent finite field elements as polynomials in ''x'' over ''GF(2)'' modulo ''x327 + x3 + x2 + 1''. To map integers to finite field elements, simply treat each bit ''i'' (with value ''2i'') in the integer as the coefficient of ''xi'' in the polynomial representation. For example the integer ''101 = 26 + 25 + 22 + 1'' is mapped to field element ''x6 + x5 + x2 + 1''. These field elements can be added and multiplied together, but the specifics of that are out of scope for this document.\n\nA short ID sketch with capacity ''c'' consists of a sequence of ''c'' field elements. The first is the sum of all short IDs in the set, the second is the sum of the 3rd powers of all short IDs, the third is the sum of the 5th powers etc., up to the last element with is the sum of the ''(2c-1)''th powers. These elements are then encoded as 32-bit integers in little endian byte order, resulting in a ''4c''-byte serialization.\n\nThe following Python 3.2+ code implements the creation of sketches: 
\nFIELD_BITS = 32\nFIELD_MODULUS = (1 << FIELD_BITS) + 0b10001101\n\ndef mul2(x):\n    \"\"\"Compute 2*x in GF(2^FIELD_BITS)\"\"\"\n    return (x << 1) ^ (FIELD_MODULUS if x.bit_length() >= FIELD_BITS else 0)\n\ndef mul(x, y):\n    \"\"\"Compute x*y in GF(2^FIELD_BITS)\"\"\"\n    ret = 0\n    for bit in [(x >> i) & 1 for i in range(x.bit_length())]:\n        ret, y = ret ^ bit * y, mul2(y)\n    return ret\n\ndef create_sketch(shortids, capacity):\n    \"\"\"Compute the bytes of a sketch for given shortids and given capacity.\"\"\"\n    odd_sums = [0 for _ in range(capacity)]\n    for shortid in shortids:\n        squared = mul(shortid, shortid)\n        for i in range(capacity):\n            odd_sums[i] ^= shortid\n            shortid = mul(shortid, squared)\n    return b''.join(elem.to_bytes(4, 'little') for elem in odd_sums)\n
\n\nThe [https://github.com/sipa/minisketch/ minisketch] library implements the construction, merging, and decoding of these sketches efficiently.\n\n===Intended Protocol Flow===\n\nSet reconciliation primarily consists of the transmission and decoding of a reconciliation set sketch upon request.\n\nSince sketches are based on the WTXIDs, the negotiation and support of Erlay should be enabled only if both peers signal [https://github.com/bitcoin/bips/blob/master/bip-0339.mediawiki BIP-339] support.\n\n[[File:bip-0330/recon_scheme_merged.png|framed|center|Protocol flow]]\n\n====Sketch extension====\n\nIf a node is unable to reconstruct the set difference from the received sketch, the node then makes a request for sketch extension. The peer would then send an extension, which is a sketch of a higher capacity (allowing to decode more differences) over the same transactions minus the sketch part which was already sent initially (to save bandwidth).\nTo allow this optimization, the initiator is supposed to locally store a sketch received initially.\nThis optimization is possible because extending a sketch is just concatenating new elements to an array.\n\n===New messages===\nSeveral new protocol messages are added: sendtxrcncl, reqrecon, sketch, reqsketchext, reconcildiff. This section describes their serialization, contents, and semantics.\n\nIn what follows, all integers are serialized in little-endian byte order. Boolean values are encoded as a single byte that must be 0 or 1 exactly. Arrays are serialized with the CompactSize prefix that encodes their length, as is common in other P2P messages.\n\n====sendtxrcncl====\nThe sendtxrcncl message announces support for the reconciliation protocol. It is expected to be only sent once, and ignored by nodes that don't support it.\n\nShould be sent before \"verack\" and accompanied by \"wtxidrelay\" (in any order).\n\nIf \"sendtxrcncl\" was sent after \"verack\", the sender should be disconnected.\n\nIf \"sendtxrcncl\" was sent before \"verack\", but by \"verack\" the \"wtxidrelay\" message was not received,\n\"sendtxrcncl\" should be ignored. The connection should proceed normally, but as if reconciliation\nwas not supported.\n\nMust not be sent if peer specified no support for transaction relay (fRelay=0) in \"version\".\nOtherwise, the sender should be disconnected.\n\nIts payload consists of:\n{|class=\"wikitable\"\n! Data type !! Name !! Description\n|-\n| uint32 || version || Sender must set this to 1 currently, otherwise receiver should ignore the message. v1 is the lowest protocol version, everything below that is a protocol violation.\n|-\n| uint64 || salt || The salt used in the short transaction ID computation.\n|}\n\nAfter both peers have confirmed support by sending \"sendtxrcncl\", the initiator of the P2P connection assumes the role of reconciliation initiator (will send \"reqrecon\" messages) and the other peer assumes the role of reconciliation responder (will respond to \"reqrecon\" messages).\n\"reqrecon\" messages can only be sent by the reconciliation initiator.\n\n====reqrecon====\nThe reqrecon message initiates a reconciliation round.\n\n{|class=\"wikitable\"\n! Data type !! Name !! Description\n|-\n| uint16 || set_size || Size of the sender's reconciliation set, used to estimate set difference.\n|-\n| uint16 || q || Coefficient used to estimate set difference. Multiplied by PRECISION=(2^15) - 1 and rounded up by the sender and divided by PRECISION by the receiver.\n|}\n\nUpon receipt of a \"reqrecon\" message, the receiver:\n* Constructs and sends a \"sketch\" message (see below), with a sketch of certain ''capacity=f(set_size, local_set_size, q)'' (the exact function is suggested below), where ''local_set_size'' represents size of the receiver's reconciliation set.\n* Makes a snapshot of their current reconciliation set, and clears the set itself. The snapshot is kept until a \"reconcildiff\" message is received by the node.\n\nNo new \"reqrecon\" message can be sent until a \"reconcildiff\" message is sent.\n\n====sketch====\nThe sketch message is used to communicate a sketch required to perform set reconciliation.\n\n{|class=\"wikitable\"\n! Data type !! Name !! Description\n|-\n| byte[] || skdata || The sketch of the sender's reconciliation snapshot\n|}\n\nThe sketch message may be received in two cases.\n\n1. Initial sketch. Upon receipt of a \"sketch\" message, a node computes the difference sketch by combining the received sketch with a sketch computed locally for a corresponding reconciliation set. The receiving node then tries to decode the difference sketch and based on the result:\n* If the decoding failed, the receiving node requests an extension sketch by sending a \"reqsketchext\" message. Alternatively, the node may terminate the reconciliation right away by sending a \"reconcildiff\" message is sent with the failure flag set (success=false).\n* If the decoding succeeded, a \"reconcildiff\" message with success=true.\nThe receiver also makes snapshot of their current reconciliation set, and clears the set itself. The snapshot is kept until a \"reconcildiff\" message is sent by the node. It is needed to enable sketch extension.\n\n2. Sketch extension. By combining the sketch extension with the initially received sketch, an extended sketch is obtained. The receiving node then computes the extended difference sketch by combining the received extended sketch with an extended sketch computed locally over a corresponding reconciliation set snapshot. The receiving node then tries to decode the extended difference sketch and based on the result:\n* If the decoding failed, the receiving node terminates the reconciliation right away by sending a \"reconcildiff\" message is sent with the failure flag set (success=false).\n* If the decoding succeeded, a \"reconcildiff\" message with success=true.\n\nIn either cases, a \"reconcildiff\" with success=false should also be accompanied with announcing all transactions from the reconciliation set (or set snapshot if failed after extension) as a fallback to flooding.\nA \"reconcildiff\" with success=true should contain unknown short IDs of the transactions from the decoded difference, corresponding to the transactions missing on the sender's side. Known short IDs from the difference correspond to what the receiver of the message is missing, and they should be announced via an \"inv\" message.\n\n====reqsketchext====\nThe reqsketchext message is used by reconciliation initiator to signal that initial set reconciliation has failed and a sketch extension is needed to find set difference.\n\nIt has an empty payload.\n\nUpon receipt of a \"reqsketchext\" message, a node responds to it with a \"sketch\" message, which contains a sketch extension: a sketch (of the same transactions sketched initially) of higher capacity without the part sent initially.\n\n====reconcildiff====\nThe reconcildiff message is used by reconciliation initiator to announce transactions which are found to be missing during set reconciliation on the sender's side.\n\n{|class=\"wikitable\"\n! Data type !! Name !! Description\n|-\n| uint8 || success || Indicates whether sender of the message succeeded at set difference decoding.\n|-\n| uint32[] || ask_shortids || The short IDs that the sender did not have.\n|}\n\nUpon receipt a \"reconcildiff\" message with ''success=1'' (reconciliation success), a node sends an \"inv\" message for the transactions requested by 32-bit IDs (first vector) containing their wtxids (with parent transactions occurring before their dependencies).\nIf ''success=0'' (reconciliation failure), receiver should announce all transactions from the reconciliation set via an \"inv\" message.\nIn both cases, transactions the sender of the message thinks the receiver is missing are announced via an \"inv\" message.\nThe regular \"inv\" deduplication should apply.\n\nThe snapshot of the corresponding reconciliation set is cleared by the sender and the receiver of the message.\n\nThe sender should also send their own \"inv\" message along with the reconcildiff message to announce transactions which are missing on the receiver's side.\n\n==Local state==\n\nThis BIP suggests a stateful protocol and it requires storing several variables at every node to operate properly.\n\n====Reconciliation salt====\nWhen negotiating reconciliation support, peers send each other their contribution to the reconciliation salt (see how we construct short IDs above). These salts (or just the resulting salt) should be stored on both sides of the connection.\n\n====Reconciliation sets====\nEvery node stores a set of wtxids for every peer which supports transaction reconciliation, representing the transactions which would have been sent according to the regular flooding protocol.\nIncoming transactions are added to sets when those transactions are received (if they satisfy the policies such as minimum fee set by a peer).\nA reconciliation set is moved to the corresponding set snapshot after the transmission of the initial sketch.\n\n====Reconciliation set snapshot====\nAfter transmitting the initial sketch (either sending or receiving of the reconcildiff message), every node should store the snapshot of the current reconciliation set, and clear the set.\nThis is important to make sketch extension more stable (extension should be computed over the set snapshot). Otherwise, extension would contain transactions received after sending out the initial sketch.\nThe snapshot is cleared after the end of the reconciliation round (sending or receiving of the reconcildiff message).\n\n====Sketch capacity estimation and q-coefficient====\n\nEarlier we suggested that upon receiving a reconciliation request, a node should estimate the sketch capacity it should send: ''capacity=f(set_size, local_set_size, q)''.\n\nWe suggest the following function: ''capacity=|set_size - local_set_size| + q * min(set_size, local_set_size) + c''.\n\nIntuitively, ''q'' represents the discrepancy in sets: the closer the sets are, the lower optimal ''q'' is.\nPer the Erlay paper, ''q'' should be derived as an optimal ''q'' value for the previous reconciliation with a given peer, once the actual set sizes and set difference are known.\nFor example, if in previous round ''set_size=30'' and ''local_set_size=20'', and the *actual* difference was ''12'', then a node should compute ''q'' as following:\n''q=(12 - |30-20|) / min(30, 20)=0.1''\n\nThe derivation of ''q'' can be changed according to the version of the protocol. For example, a static value could be chosen for simplicity. However, we suggest that ''q'' remains a parameter sent in every reconciliation request to enable future compatibility with more sophisticated (non-static) choices of this parameter.\n\nAs for the ''c'' parameter, it is suggested to use ''c=1'' to avoid sending empty sketches and reduce the overhead caused by under-estimations.\n\n==Backward compatibility==\n\nOlder clients remain fully compatible and interoperable after this change.\n\nClients which do not implement this protocol remain fully compatible after this change using existing protocols, because transaction announcement reconciliation is used only for peers that negotiate support for it.\n\n==Rationale==\n\n====Why use PinSketch for set reconciliation?====\n\nPinSketch is more bandwidth efficient than IBLT, especially for the small differences in sets we expect to operate over.\nPinSketch is as bandwidth efficient as CPISync, but PinSketch has quadratic decoding complexity, while CPISync have cubic decoding complexity. This makes PinSketch significantly faster.\n\n====Why use 32-bit short transaction IDs?====\n\nTo use Minisketch in practice, transaction IDs should be shortened (ideally, not more than 64 bits per element).\nA small number of bits per transaction also allows saving extra bandwidth and make operations over sketches faster.\nAccording to our estimates, 32 bits provides low collision rate in a non-adversarial model (which is enabled by using independent salts per-link).\n\n====Why use sketch extensions instead of bisection?====\n\nBisection is an alternative to sketch extensions, per which a second sketch with the same initial capacity is computed over half of the txID space.\nDue to the linearity of sketches, transmitting just this one allows a reconciliation initiator to compute the sketch of the same capacity of another half. Two sketches allow the initiator to reconstruct twice as many differences as was allowed by an initial sketch.\n\nIn practice this allows the initiator to amortize the bandwidth overhead of initial reconciliation failure, similarly to extension sketches, making the overhead negligible.\n\nThe main benefit of sketch extensions is a much simpler implementation. Implementing bisection is hard (see [https://github.com/naumenkogs/bitcoin/commit/b5c92a41e4cc0599504cf838d20212f1a403e573 implementation]) because, in the end, we have to operate with two sketches and handle scenarios where one sketch decoded and another sketch failed.\n\nIt becomes even more difficult if in the future we decide to allow more than one extension/bisection. Bisection in this case have to be recursive (and spawn 4/8/16/... sketches), while for extensions we always end up with one extended sketch.\n\nSketch extensions are also more flexible: extending a sketch of capacity 10 with 4 more means just computing a sketch of capacity 14 and sending the extension, while for bisection increasing the capacity to something different than 10*2/10*4/10*8/... is sophisticated implementation-wise.\n\nThe only advantage of bisection is that it doesn't require computing sketches of higher capacities (exponential cost). We believe that since\nthe protocol is currently designed to operate in the conditions where sketches usually have at most the capacity of 20, this efficiency is not crucial.\n\n==Implementation==\n\nhttps://github.com/bitcoin/bitcoin/pull/21515\n\n==Acknowledgments==\n\nA large fraction of this proposal was done during designing Erlay with Gregory Maxwell, Sasha Fedorova and Ivan Beschastnikh.\nWe would like to thank Suhas Daftuar for contributions to the design and BIP structure.\nWe would like to thank Ben Woosley for contributions to the high-level description of the idea.\n\n==Copyright==\n\nThis document is licensed under the Creative Commons CC0 1.0 Universal license.", "category": "bips" }, { "instruction": "I want to understand 
 from a technical perspective",
    "input": "",
    "output": "BIP: 329\n  Layer: Applications\n  Title: Wallet Labels Export Format\n  Authors: Craig Raw \n  Status: Draft\n  Type: Informational\n  Assigned: 2022-08-23\n  License: BSD-2-Clause\n
\n\n==Abstract==\n\nThis document specifies a format for the export of labels that may be attached to various common types of records in a wallet.\n\n==Copyright==\n\nThis BIP is licensed under the BSD 2-clause license.\n\n==Motivation==\n\nThe export and import of funds across different Bitcoin wallet applications is well defined through standards such as BIP39, BIP32, BIP44 etc.\nThese standards are well supported and allow users to move easily between different wallets.\nThere is, however, no defined standard to transfer any labels the user may have applied to the transactions, addresses, public keys, inputs, outputs, xpubs or spscans in their wallet.\nThe UTXO model that Bitcoin uses makes these labels particularly valuable as they may indicate the source of funds, whether received externally or as a result of change from a prior transaction.\nIn both cases, care must be taken when spending to avoid undesirable leaks of private information.\n\nLabels provide valuable guidance in this regard, and have even become mandatory when spending in several Bitcoin wallets.\nAllowing users to import and export their labels in a standardized way ensures that they do not experience lock-in to a particular wallet application.\nIn addition, many wallets allow unspent outputs to be frozen or made unspendable within the wallet. Since this wallet-related metadata is similar to labels and not captured elsewhere, it is also included in this format.\n\n==Rationale==\n\nWhile there is currently no widely accepted format for exporting and importing labels, there are existing formats in use.\nSLIP-0015[https://github.com/satoshilabs/slips/blob/master/slip-0015.md SLIP-0015] defines a format for exporting address and output labels, but requires encryption using a private key associated with the wallet seed, and thus cannot be used independently by coordinator wallets which cannot access private keys.\nThe Electrum wallet imports and exports address and transaction labels in a JSON format which could be used with other record types, but the format used is not self describing making record type identification difficult.\n\n==Specification==\n\nIn order to be lightweight, human readable and well structured, this BIP uses a JSON format.\nFurther, the JSON Lines format is used (also called newline-delimited JSON)[https://jsonlines.org/ jsonlines.org].\nThis allows a document to be split, streamed, or incrementally added to, and limits the potential for formatting errors to invalidate an entire import.\nIt is also a convenient format for command-line processing, which is often line-oriented.\n\nFurther to the JSON Lines specification, an export of labels from a wallet must be a UTF-8 encoded text file, containing one record per line consisting of a valid JSON object.\nLines are separated by \\n. Multiline values are not permitted.\nEach JSON object must contain 3 or 4 key/value pairs, defined as follows:\n\n{| class=\"wikitable\"\n|-\n! Key\n! Description\n|-\n| type\n| One of tx, addr, pubkey, input, output, xpub or spscan\n|-\n| ref\n| Reference to the transaction, address, public key, input, output, extended public key or silent payments scan key expression\n|-\n| label\n| The label applied to the reference\n|-\n| origin\n| Optional key origin information referencing the wallet associated with the label\n|-\n| spendable\n| One of true or false, denoting if an output should be spendable by the wallet\n|}\n\nThe reference is defined for each type as follows:\n\n{| class=\"wikitable\"\n|-\n! Type\n! Description\n! Example\n|-\n| tx\n| Transaction id in hexadecimal format\n| f91d0a8a78462bc59398f2c5d7a84fcff491c26ba54c4833478b202796c8aafd\n|-\n| addr\n| Address in base58 or bech32 format\n| bc1q34aq5drpuwy3wgl9lhup9892qp6svr8ldzyy7c\n|-\n| pubkey\n| 32, 33 or 65 byte public key in hexadecimal format\n| 0283409659355b6d1cc3c32decd5d561abaac86c37a353b52895a5e6c196d6f448\n|-\n| input\n| Transaction id and input index separated by a colon\n| f91d0a8a78462bc59398f2c5d7a84fcff491c26ba54c4833478b202796c8aafd:0\n|-\n| output\n| Transaction id and output index separated by a colon\n| f91d0a8a78462bc59398f2c5d7a84fcff491c26ba54c4833478b202796c8aafd:1\n|-\n| xpub\n| Extended public key as defined by BIP32\n| xpub661MyMwAqRbcFtXgS5sYJABqqG9YLmC4Q1Rdap9gSE8Nq...\n|-\n| spscan\n| Key expression for the single argument form of a silent payments output descriptor as defined by BIP392\n| spscan1q5zs2pg9q5zs2pg9q5zs2pg9q5zs2pg9q5zs2pg9q5...\n|}\n\nEach JSON object must contain both type and ref properties. The label, origin and spendable properties are optional. If the label or spendable properties are omitted, the importing wallet should not alter these values. The spendable property should only appear where type is output.\n\nIf present, the optional origin property must contain an abbreviated output descriptor (as defined by BIP380[https://github.com/bitcoin/bips/blob/master/bip-0380.mediawiki BIP-0380]) describing a BIP32 compatible originating wallet, including all key origin information but excluding any actual keys, any child path elements, or a checksum.\nThis property should be used to disambiguate transaction labels from different wallets contained in the same export, particularly when exporting multiple accounts derived from the same seed.\n\nCare should be taken when exporting due to the privacy sensitive nature of the data.\nEncryption in transit over untrusted networks is highly recommended, and encryption at rest should also be considered.\nUnencrypted exports should be deleted as soon as possible.\nFor security reasons no private key types are defined.\n\n==Importing==\n\n* An importing wallet may ignore records it does not store, and truncate labels if necessary. A suggested default for maximum label length is 255 characters, and an importing wallet should consider warning the user if truncation is applied.\n* Wallets importing public key records may derive addresses from them to match against known wallet addresses.\n* Wallets importing extended public keys may match them against signers, for example in a multisig setup.\n\n==Backwards Compatibility==\n\nThe nature of this format makes it naturally extensible to handle other record types.\nHowever, importing wallets complying to this specification should ignore types not defined here.\n\n==Test Vectors==\n\nThe following fragment represents a wallet label export:\n
\n{ \"type\": \"tx\", \"ref\": \"f91d0a8a78462bc59398f2c5d7a84fcff491c26ba54c4833478b202796c8aafd\", \"label\": \"Transaction\", \"origin\": \"wpkh([d34db33f/84'/0'/0'])\" }\n{ \"type\": \"addr\", \"ref\": \"bc1q34aq5drpuwy3wgl9lhup9892qp6svr8ldzyy7c\", \"label\": \"Address\" }\n{ \"type\": \"pubkey\", \"ref\": \"0283409659355b6d1cc3c32decd5d561abaac86c37a353b52895a5e6c196d6f448\", \"label\": \"Public Key\" }\n{ \"type\": \"input\", \"ref\": \"f91d0a8a78462bc59398f2c5d7a84fcff491c26ba54c4833478b202796c8aafd:0\", \"label\": \"Input\" }\n{ \"type\": \"output\", \"ref\": \"f91d0a8a78462bc59398f2c5d7a84fcff491c26ba54c4833478b202796c8aafd:1\", \"label\": \"Output\", \"spendable\": false }\n{ \"type\": \"xpub\", \"ref\": \"xpub661MyMwAqRbcFtXgS5sYJABqqG9YLmC4Q1Rdap9gSE8NqtwybGhePY2gZ29ESFjqJoCu1Rupje8YtGqsefD265TMg7usUDFdp6W1EGMcet8\", \"label\": \"Extended Public Key\" }\n{ \"type\": \"spscan\", \"ref\": \"spscan1q5zs2pg9q5zs2pg9q5zs2pg9q5zs2pg9q5zs2pg9q5zs2pg9q5zsq9q6qjevn2kmdrnpuxt0v6h2kr2a2epkr0g6nk55ftf0xcxtddazgkrth3e\", \"label\": \"Silent Payments Scan Key Expression\" }\n{ \"type\": \"tx\", \"ref\": \"f546156d9044844e02b181026a1a407abfca62e7ea1159f87bbeaa77b4286c74\", \"label\": \"Account #1 Transaction\", \"origin\": \"wpkh([d34db33f/84'/0'/1'])\" }\n
\n\n==Additional Fields==\n\nIf the goal is solely to move labels between cooperating wallets,\nthen the above values are the minimum needed. However, wallet data\nexports can serve other purposes. Many values associated with\naddresses, transactions and outputs are already on hand for the\nwallet generating the export, and yet would be hard or impossible\nfor importing tools to reconstruct.\n\nAll of the following values are optional for the exporter to provide,\nbut should be given if they are readily available.\n\n=== Transactions ===\n\n* height: An integer giving the block height where this fully confirmed transaction can be found. For transactions that are confirmed by less than 6 blocks, omit this field or provide a value of zero. (Background: Until it is fully confirmed, the \"height\" of a transaction is in flux and may vary due to chain reorgs. However, the consumer of the labels, may not know the current block height, so it cannot know if the height is \"real\" (firm, fixed) or just transitory. Therefore, it is important to omit the height unless the generating wallet considers the transaction to be confirmed.)\n\n* time: ISO-8601 formatted timestamp of the block given by the \"height\" field, preferably in UTC, although ISO-8601 can represent local times. Example: 2025-01-23T11:40:35Z.\n\n* fee: Integer giving the number of Satoshis that went to the miner for this transaction.\n\n* value: Signed integer giving the number of Satoshis that came into the wallet by this transaction. Will be negative when sats leave the wallet. Could be zero if it is a consolidation transaction that moves from old UTXO to new.\n\n* rate: Exchange rate at time of transaction. This is the value of a Bitcoin, expressed in another currency, at the time of the transaction, based on user preferences for data source. Multiple currencies can be given. Keys are ISO 4217 currency codes where possible. Example: \"rate\": { \"USD\": 105620.00 }\n\n=== Address, Inputs, and Outputs ===\n\n* keypath: The data needed to build full descriptor down to the specific address. This extends origin with the final two components that are unhardened (in the typical case, assuming BIP-84). Provide string /1/123 for wpkh([d34db33f/84'/0'/0'/1/123]). If the first character is not /, then it should be interpreted as a full descriptor, independent of origin (if any).\n\n=== Inputs and Outputs ===\n\n* value: Integer with the number of Satoshis (nValue) of the input or output.\n\n* fmv: Fair market value of the input/output relative to some other currency, typically fiat. The value should be a mapping, from currency code to decimal number. Example: \"fmv\": { \"USD\": 1233.45 }. Most situations will have only a single currency value, and it represents the real price of the goods/services expressed in some fiat currency. This is not an exchange *rate*, but an absolute value. By dividing by the value (above), it is possible to calculate an effective change rate for the transaction.\n\n* height and time: Same definition as defined in Transactions.\n\n=== Address ===\n\n* heights: a list of block heights that contain any activity related to this address, include outputs that deposit to the address, and transactions that spend UTXOs of this address. Omit heights for transactions that are not fully confirmed. An empty array indicates the address is unused for confirmed transactions.\n\n== Comment on Types in JSON ==\n\nJSON can serialize a number of basic types, including string, integer\nand boolean (true/false). Decimal values (123.45) can\nalso be serialized, but some parsing libraries may interpret them as floating\npoint values, which is generally not what we want in financial applications.\nWhen hand-crafting JSON data, be careful not to write \"false\" (with quotes),\nsince that is a string with 5 characters and not a boolean.\n\n==Reference Implementation==\n\n* [https://github.com/Labelbase/python-bip329 Python-BIP329 package]\n\n==References==\n\n", "category": "bips" }, { "instruction": "Can you explain 
 like we're having a beer and talking Bitcoin?",
    "input": "",
    "output": "BIP: 39\n  Layer: Applications\n  Title: Mnemonic code for generating deterministic keys\n  Authors: Marek Palatinus \n           Pavol Rusnak \n           Aaron Voisine \n           Sean Bowe \n  Comments-Summary: Unanimously Discourage for implementation\n  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0039\n  Status: Deployed\n  Type: Specification\n  Assigned: 2013-09-10\n  License: MIT\n
\n\n==Abstract==\n\nThis BIP describes the implementation of a mnemonic code or mnemonic sentence --\na group of easy to remember words -- for the generation of deterministic wallets.\n\nIt consists of two parts: generating the mnemonic and converting it into a\nbinary seed. This seed can be later used to generate deterministic wallets using\nBIP-0032 or similar methods.\n\n==Copyright==\n\nThis BIP falls under the MIT License.\n\n==Motivation==\n\nA mnemonic code or sentence is superior for human interaction compared to the\nhandling of raw binary or hexadecimal representations of a wallet seed. The\nsentence could be written on paper or spoken over the telephone.\n\nThis guide is meant to be a way to transport computer-generated randomness with\na human-readable transcription. It's not a way to process user-created\nsentences (also known as brainwallets) into a wallet seed.\n\n==Generating the mnemonic==\n\nThe mnemonic must encode entropy in a multiple of 32 bits. With more entropy\nsecurity is improved but the sentence length increases. We refer to the\ninitial entropy length as ENT. The allowed size of ENT is 128-256 bits.\n\nFirst, an initial entropy of ENT bits is generated. A checksum is generated by\ntaking the first ENT / 32 bits of its SHA256 hash. This checksum is\nappended to the end of the initial entropy. Next, these concatenated bits\nare split into groups of 11 bits, each encoding a number from 0-2047, serving\nas an index into a wordlist. Finally, we convert these numbers into words and\nuse the joined words as a mnemonic sentence.\n\nThe following table describes the relation between the initial entropy\nlength (ENT), the checksum length (CS), and the length of the generated mnemonic\nsentence (MS) in words.\n\n
\nCS = ENT / 32\nMS = (ENT + CS) / 11\n\n|  ENT  | CS | ENT+CS |  MS  |\n+-------+----+--------+------+\n|  128  |  4 |   132  |  12  |\n|  160  |  5 |   165  |  15  |\n|  192  |  6 |   198  |  18  |\n|  224  |  7 |   231  |  21  |\n|  256  |  8 |   264  |  24  |\n
\n\n==Wordlist==\n\nAn ideal wordlist has the following characteristics:\n\na) smart selection of words\n - the wordlist is created in such a way that it's enough to type the first four\n letters to unambiguously identify the word\n\nb) similar words avoided\n - word pairs like \"build\" and \"built\", \"woman\" and \"women\", or \"quick\" and \"quickly\"\n not only make remembering the sentence difficult but are also more error\n prone and more difficult to guess\n\nc) sorted wordlists\n - the wordlist is sorted which allows for more efficient lookup of the code words\n (i.e. implementations can use binary search instead of linear search)\n - this also allows trie (a prefix tree) to be used, e.g. for better compression\n\nThe wordlist can contain native characters, but they must be encoded in UTF-8\nusing Normalization Form Compatibility Decomposition (NFKD).\n\n==From mnemonic to seed==\n\nA user may decide to protect their mnemonic with a passphrase. If a passphrase is not\npresent, an empty string \"\" is used instead.\n\nTo create a binary seed from the mnemonic, we use the PBKDF2 function with a mnemonic\nsentence (in UTF-8 NFKD) used as the password and the string \"mnemonic\" + passphrase (again\nin UTF-8 NFKD) used as the salt. The iteration count is set to 2048 and HMAC-SHA512 is used as\nthe pseudo-random function. The length of the derived key is 512 bits (= 64 bytes).\n\nThis seed can be later used to generate deterministic wallets using BIP-0032 or\nsimilar methods.\n\nThe conversion of the mnemonic sentence to a binary seed is completely independent\nfrom generating the sentence. This results in a rather simple code; there are no\nconstraints on sentence structure and clients are free to implement their own\nwordlists or even whole sentence generators, allowing for flexibility in wordlists\nfor typo detection or other purposes.\n\nAlthough using a mnemonic not generated by the algorithm described in \"Generating the\nmnemonic\" section is possible, this is not advised and software must compute a\nchecksum for the mnemonic sentence using a wordlist and issue a warning if it is\ninvalid.\n\nThe described method also provides plausible deniability, because every passphrase\ngenerates a valid seed (and thus a deterministic wallet) but only the correct one\nwill make the desired wallet available.\n\n==Wordlists==\n\nSince the vast majority of BIP39 wallets supports only the English wordlist,\nit is '''strongly discouraged''' to use non-English wordlists for generating\nthe mnemonic sentences.\n\nIf you still feel your application really needs to use a localized wordlist,\nuse one of the following instead of inventing your own.\n\n* [[bip-0039/bip-0039-wordlists.md|Wordlists]]\n\n==Test vectors==\n\nThe test vectors include input entropy, mnemonic and seed. The\npassphrase \"TREZOR\" is used for all vectors.\n\nhttps://github.com/trezor/python-mnemonic/blob/master/vectors.json\n\nAlso see https://github.com/bip32JP/bip32JP.github.io/blob/master/test_JP_BIP39.json\n\n(Japanese wordlist test with heavily normalized symbols as passphrase)\n\n==Reference Implementation==\n\nReference implementation including wordlists is available from\n\nhttp://github.com/trezor/python-mnemonic", "category": "bips" }, { "instruction": "How would you explain 
 to someone who knows Bitcoin basics?",
    "input": "",
    "output": "BIP: 38\n  Layer: Applications\n  Title: Passphrase-protected private key\n  Authors: Mike Caldwell \n           Aaron Voisine \n  Comments-Summary: Unanimously Discourage for implementation\n  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0038\n  Status: Deployed\n  Type: Specification\n  Assigned: 2012-11-20\n  License: PD\n
\n\n==Abstract==\nA method is proposed for encrypting and encoding a passphrase-protected Bitcoin private key record in the form of a 58-character Base58Check-encoded printable string. Encrypted private key records are intended for use on paper wallets and physical Bitcoins. Each record string contains all the information needed to reconstitute the private key except for a passphrase, and the methodology uses salting and ''scrypt'' to resist brute-force attacks.\n\nThe method provides two encoding methodologies - one permitting any known private key to be encrypted with any passphrase, and another permitting a shared private key generation scheme where the party generating the final key string and its associated Bitcoin address (such as a physical bitcoin manufacturer) knows only a string derived from the original passphrase, and where the original passphrase is needed in order to actually redeem funds sent to the associated Bitcoin address.\n\nA 32-bit hash of the resulting Bitcoin address is encoded in plaintext within each encrypted key, so it can be correlated to a Bitcoin address with reasonable probability by someone not knowing the passphrase. The complete Bitcoin address can be derived through successful decryption of the key record.\n\n==Motivation==\nThe motivation to make this proposal stems from observations of the way physical bitcoins and paper wallets are used.\n\nAn issuer of physical bitcoins must be trustworthy and trusted. Even if trustworthy, users are rightful to be skeptical about a third party with theoretical access to take their funds. A physical bitcoin that cannot be compromised by its issuer is always more intrinsically valuable than one that can.\n\nA two-factor physical bitcoin solution is highly useful to individuals and organizations wishing to securely own bitcoins without any risk of electronic theft and without the responsibility of climbing the technological learning curve necessary to produce such an environment themselves. Two-factor physical bitcoins allow a secure storage solution to be put in a box and sold on the open market, greatly enlarging the number of people who are able to securely store bitcoins.\n\nExisting methodologies for creating two-factor physical bitcoins are limited and cumbersome. At the time of this proposal, a user could create their own private key, submit the public key to the physical bitcoin issuer, and then receive a physical bitcoin that must be kept together with some sort of record of the user-generated private key, and finally, must be redeemed through a tool. The fact that the physical bitcoin must be kept together with a user-produced private key negates much of the benefit of the physical bitcoin - the user may as well just print and maintain a private key.\n\nA standardized password-protected private key format makes acquiring and redeeming two-factor physical bitcoins simpler for the user. Instead of maintaining a private key that cannot be memorized, the user may choose a passphrase of their choice. The passphrase may be much shorter than the length of a typical private key, short enough that they could use a label or engraver to permanently commit their passphrase to their physical Bitcoin piece once they have received it. By adopting a standard way to encrypt a private key, we maximize the possibility that they'll be able to redeem their funds in the venue of their choice, rather than relying on an executable redemption tool they may not wish to download.\n\nPassword and passphrase-protected private keys enable new practical use cases for sending bitcoins from person to person. Someone wanting to send bitcoins through postal mail could send a password-protected paper wallet and give the recipient the passphrase over the phone or e-mail, making the transfer safe from interception of either channel. A user of paper wallets or Bitcoin banknote-style vouchers (\"cash\") could carry funded encrypted private keys while leaving a copy at home as an element of protection against accidental loss or theft. A user of paper wallets who leaves bitcoins in a bank vault or safety deposit box could keep the password at home or share it with trusted associates as protection against someone at the bank gaining access to the paper wallets and spending from them. The foreseeable and unforeseeable use cases for password-protected private keys are numerous.\n\n==Copyright==\nThis proposal is hereby placed in the public domain.\n\n==Rationale==\n:'' '''User story:''' As a Bitcoin user who uses paper wallets, I would like the ability to add encryption, so that my Bitcoin paper storage can be two factor: something I have plus something I know.''\n:'' '''User story:''' As a Bitcoin user who would like to pay a person or a company with a private key, I do not want to worry that any part of the communication path may result in the interception of the key and theft of my funds. I would prefer to offer an encrypted private key, and then follow it up with the password using a different communication channel (e.g. a phone call or SMS).''\n:'' '''User story:''' (EC-multiplied keys) As a user of physical bitcoins, I would like a third party to be able to create password-protected Bitcoin private keys for me, without them knowing the password, so I can benefit from the physical bitcoin without the issuer having access to the private key. I would like to be able to choose a password whose minimum length and required format does not preclude me from memorizing it or engraving it on my physical bitcoin, without exposing me to an undue risk of password cracking and/or theft by the manufacturer of the item.''\n:'' '''User story:''' (EC-multiplied keys) As a user of paper wallets, I would like the ability to generate a large number of Bitcoin addresses protected by the same password, while enjoying a high degree of security (highly expensive scrypt parameters), but without having to incur the scrypt delay for each address I generate.''\n\n==Specification==\nThis proposal makes use of the following functions and definitions:\n\n*'''AES256Encrypt, AES256Decrypt''': the simple form of the well-known AES block cipher without consideration for initialization vectors or block chaining. Each of these functions takes a 256-bit key and 16 bytes of input, and deterministically yields 16 bytes of output.\n*'''SHA256''', a well-known hashing algorithm that takes an arbitrary number of bytes as input and deterministically yields a 32-byte hash.\n*'''scrypt''': A well-known key derivation algorithm. It takes the following parameters: (string) password, (string) salt, (int) n, (int) r, (int) p, (int) length, and deterministically yields an array of bytes whose length is equal to the length parameter.\n*'''ECMultiply''': Multiplication of an elliptic curve point by a scalar integer with respect to the secp256k1 elliptic curve.\n*'''G, N''': Constants defined as part of the secp256k1 elliptic curve. G is an elliptic curve point, and N is a large positive integer.\n*'''Base58Check''': a method for encoding arrays of bytes using 58 alphanumeric characters commonly used in the Bitcoin ecosystem.\n\n===Prefix===\nIt is proposed that the resulting Base58Check-encoded string start with a '6'. The number '6' is intended to represent, from the perspective of the user, \"a private key that needs something else to be usable\" - an umbrella definition that could be understood in the future to include keys participating in multisig transactions, and was chosen with deference to the existing prefix '5' most commonly observed in Wallet Import Format which denotes an unencrypted private key.\n\nIt is proposed that the second character ought to give a hint as to what is needed as a second factor, and for an encrypted key requiring a passphrase, the uppercase letter P is proposed.\n\nTo keep the size of the encrypted key down, no initialization vectors (IVs) are used in the AES encryption. Rather, suitable values for IV-like use are derived using scrypt from the passphrase and from using a 32-bit hash of the resulting Bitcoin address as salt.\n\n===Proposed specification===\n\n* Object identifier prefix: 0x0142 (non-EC-multiplied) or 0x0143 (EC-multiplied). These are constant bytes that appear at the beginning of the Base58Check-encoded record, and their presence causes the resulting string to have a predictable prefix.\n* How the user sees it: 58 characters always starting with '6P'\n** Visual cues are present in the third character for visually identifying the EC-multiply and compress flag.\n* Count of payload bytes (beyond prefix): 37\n** 1 byte (''flagbyte''):\n*** 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.\n*** 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.\n*** 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.\n*** 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.\n*** remaining bits are reserved for future use and must all be 0 to comply with this version of the specification.\n** 4 bytes: SHA256(SHA256(expected_bitcoin_address))[0...3], used both for typo checking and as salt\n**16 bytes: Contents depend on whether EC multiplication is used.\n**16 bytes: lasthalf: An AES-encrypted key material record (contents depend on whether EC multiplication is used)\n* Range in base58check encoding for non-EC-multiplied keys without compression (prefix 6PR):\n** Minimum value: 6PRHv1jg1ytiE4kT2QtrUz8gEjMQghZDWg1FuxjdYDzjUkcJeGdFj9q9Vi (based on 01 42 C0 plus thirty-six 00's)\n** Maximum value: 6PRWdmoT1ZursVcr5NiD14p5bHrKVGPG7yeEoEeRb8FVaqYSHnZTLEbYsU (based on 01 42 C0 plus thirty-six FF's)\n* Range in base58check encoding for non-EC-multiplied keys with compression (prefix 6PY):\n** Minimum value: 6PYJxKpVnkXUsnZAfD2B5ZsZafJYNp4ezQQeCjs39494qUUXLnXijLx6LG (based on 01 42 E0 plus thirty-six 00's)\n** Maximum value: 6PYXg5tGnLYdXDRZiAqXbeYxwDoTBNthbi3d61mqBxPpwZQezJTvQHsCnk (based on 01 42 E0 plus thirty-six FF's)\n* Range in base58check encoding for EC-multiplied keys without compression (prefix 6Pf):\n** Minimum value: 6PfKzduKZXAFXWMtJ19Vg9cSvbFg4va6U8p2VWzSjtHQCCLk3JSBpUvfpf (based on 01 43 00 plus thirty-six 00's)\n** Maximum value: 6PfYiPy6Z7BQAwEHLxxrCEHrH9kasVQ95ST1NnuEnnYAJHGsgpNPQ9dTHc (based on 01 43 00 plus thirty-six FF's)\n* Range in base58check encoding for EC-multiplied keys with compression (prefix 6Pn):\n** Minimum value: 6PnM2wz9LHo2BEAbvoGpGjMLGXCom35XwsDQnJ7rLiRjYvCxjpLenmoBsR (based on 01 43 20 plus thirty-six 00's)\n** Maximum value: 6PnZki3vKspApf2zym6Anp2jd5hiZbuaZArPfa2ePcgVf196PLGrQNyVUh (based on 01 43 20 plus thirty-six FF's)\n\n====Encryption when EC multiply flag is not used====\nEncrypting a private key without the EC multiplication offers the advantage that any known private key can be encrypted. The party performing the encryption must know the passphrase.\n\nEncryption steps:", "category": "bips" }, { "instruction": "I'm trying to understand Bitcoin Operations Guide - can you walk me through it?", "input": "", "output": "# Compute the Bitcoin address (ASCII), and take the first four bytes of SHA256(SHA256()) of it. Let's call this \"addresshash\".", "category": "bips" }, { "instruction": "Hey, I need to set up Derive a key from the passphrase using scrypt - what's the command line way to do that?", "input": "", "output": "#*Parameters: ''passphrase'' is the passphrase itself encoded in UTF-8 and normalized using Unicode Normalization Form C (NFC). salt is ''addresshash'' from the earlier step, n=16384, r=8, p=8, length=64 (n, r, p are provisional and subject to consensus)\n#*Let's split the resulting 64 bytes in half, and call them ''derivedhalf1'' and ''derivedhalf2''.", "category": "bips" }, { "instruction": "What's the deal with Bitcoin Operations Guide in Bitcoin? Explain it like I'm a friend.", "input": "", "output": "# Do AES256Encrypt(block = bitcoinprivkey[0...15] xor derivedhalf1[0...15], key = derivedhalf2), call the 16-byte result ''encryptedhalf1''", "category": "bips" }, { "instruction": "Can you show me the CLI commands for Do AES256Encrypt(block = bitcoinprivkey[16...31] xor derivedhalf1[16...31], key = derivedhalf2), call the 16-byte result ''encryptedhalf2''?", "input": "", "output": "The encrypted private key is the Base58Check-encoded concatenation of the following, which totals 39 bytes without Base58 checksum:\n* 0x01 0x42 + ''flagbyte'' + ''salt'' + ''encryptedhalf1'' + ''encryptedhalf2''\n\nDecryption steps:", "category": "bips" }, { "instruction": "I'm stuck with Bitcoin Operations Guide - what should I check?", "input": "", "output": "# Derive ''derivedhalf1'' and ''derivedhalf2'' by passing the passphrase and ''addresshash'' into scrypt function.", "category": "bips" }, { "instruction": "How do I troubleshoot Bitcoin Operations Guide issues?", "input": "", "output": "# Decrypt ''encryptedhalf1'' and ''encryptedhalf2'' using AES256Decrypt, merge them to form the encrypted private key.", "category": "bips" }, { "instruction": "What are the best practices for Bitcoin Operations Guide?", "input": "", "output": "# Convert that private key into a Bitcoin address, honoring the compression preference specified in ''flagbyte'' of the encrypted key record.", "category": "bips" }, { "instruction": "Walk me through setting up Hash the Bitcoin address, and verify that ''addresshash'' from the encrypted private key record matches the hash. If not, report that the passphrase entry was incorrect. step by step", "input": "", "output": "====Encryption when EC multiply mode is used====\nEncrypting a private key with EC multiplication offers the ability for someone to generate encrypted keys knowing only an EC point derived from the original passphrase and some salt generated by the passphrase's owner, and without knowing the passphrase itself. Only the person who knows the original passphrase can decrypt the private key. A code known as an ''intermediate code'' conveys the information needed to generate such a key without knowledge of the passphrase.\n\nThis methodology does not offer the ability to encrypt a known private key - this means that the process of creating encrypted keys is also the process of generating new addresses. On the other hand, this serves a security benefit for someone possessing an address generated this way: if the address can be recreated by decrypting its private key with a passphrase, and it's a strong passphrase one can be certain only he knows himself, then he can safely conclude that nobody could know the private key to that address.\n\nThe person who knows the passphrase and who is the intended beneficiary of the private keys is called the ''owner''. He will generate one or more \"intermediate codes\", which are the first factor of a two-factor redemption system, and will give them to someone else we'll call ''printer'', who generates a key pair with an intermediate code can know the address and encrypted private key, but cannot decrypt the private key without the original passphrase.\n\nAn intermediate code should, but is not required to, embed a printable \"lot\" and \"sequence\" number for the benefit of the user. The proposal forces these lot and sequence numbers to be included in any valid private keys generated from them. An owner who has requested multiple private keys to be generated for him will be advised by applications to ensure that each private key has a unique lot and sequence number consistent with the intermediate codes he generated. These mainly help protect ''owner'' from potential mistakes and/or attacks that could be made by ''printer''.\n\nThe \"lot\" and \"sequence\" number are combined into a single 32 bit number. 20 bits are used for the lot number and 12 bits are used for the sequence number, such that the lot number can be any decimal number between 0 and 1048575, and the sequence number can be any decimal number between 0 and 4095. For programs that generate batches of intermediate codes for an ''owner'', it is recommended that lot numbers be chosen at random within the range 100000-999999 and that sequence numbers are assigned starting with 1.\n\nSteps performed by ''owner'' to generate a single intermediate code, if lot and sequence numbers are being included:", "category": "bips" }, { "instruction": "What commands would you run to work with Bitcoin Operations Guide?", "input": "", "output": "# Encode the lot and sequence numbers as a 4 byte quantity (big-endian): lotnumber * 4096 + sequencenumber. Call these four bytes ''lotsequence''.", "category": "bips" }, { "instruction": "I want to understand Derive a key from the passphrase using scrypt from a technical perspective", "input": "", "output": "#* Parameters: ''passphrase'' is the passphrase itself encoded in UTF-8 and normalized using Unicode Normalization Form C (NFC). salt is ''ownersalt''. n=16384, r=8, p=8, length=32.\n#* Call the resulting 32 bytes ''prefactor''.\n#* Take SHA256(SHA256(''prefactor'' + ''ownerentropy'')) and call this ''passfactor''. The \"+\" operator is concatenation.", "category": "bips" }, { "instruction": "Can you explain Bitcoin Operations Guide like we're having a beer and talking Bitcoin?", "input": "", "output": "# Compute the elliptic curve point G * ''passfactor'', and convert the result to compressed notation (33 bytes). Call this ''passpoint''. Compressed notation is used for this purpose regardless of whether the intent is to create Bitcoin addresses with or without compressed public keys.", "category": "bips" }, { "instruction": "How would you explain Convey ''ownersalt'' and ''passpoint'' to the party generating the keys, along with a checksum to ensure integrity. to someone who knows Bitcoin basics?", "input": "", "output": "#* The following Base58Check-encoded format is recommended for this purpose: magic bytes \"2C E9 B3 E1 FF 39 E2 51\" followed by ''ownerentropy'', and then ''passpoint''. The resulting string will start with the word \"passphrase\" due to the constant bytes, will be 72 characters in length, and encodes 49 bytes (8 bytes constant + 8 bytes ''ownerentropy'' + 33 bytes ''passpoint''). The checksum is handled in the Base58Check encoding. The resulting string is called ''intermediate_passphrase_string''.\n\nIf lot and sequence numbers are not being included, then follow the same procedure with the following changes:\n* ''ownersalt'' is 8 random bytes instead of 4, and ''lotsequence'' is omitted. ''ownerentropy'' becomes an alias for ''ownersalt''.\n* The SHA256 conversion of ''prefactor'' to ''passfactor'' is omitted. Instead, the output of scrypt is used directly as ''passfactor''.\n* The magic bytes are \"2C E9 B3 E1 FF 39 E2 53\" instead (the last byte is 0x53 instead of 0x51).\n\nSteps to create new encrypted private keys given ''intermediate_passphrase_string'' from ''owner'' (so we have ''ownerentropy'', and ''passpoint'', but we do not have ''passfactor'' or the passphrase):", "category": "bips" }, { "instruction": "I'm trying to understand Set ''flagbyte''. - can you walk me through it?", "input": "", "output": "#* Turn on bit 0x20 if the Bitcoin address will be formed by hashing the compressed public key (optional, saves space, but many Bitcoin implementations aren't compatible with it)\n#* Turn on bit 0x04 if ''ownerentropy'' contains a value for ''lotsequence''. (While it has no effect on the keypair generation process, the decryption process needs this flag to know how to process ''ownerentropy'')", "category": "bips" }, { "instruction": "Hey, I need to set up Bitcoin Operations Guide - what's the command line way to do that?", "input": "", "output": "# Generate 24 random bytes, call this ''seedb''. Take SHA256(SHA256(''seedb'')) to yield 32 bytes, call this ''factorb''.", "category": "bips" }, { "instruction": "What's the deal with Bitcoin Operations Guide in Bitcoin? Explain it like I'm a friend.", "input": "", "output": "# ECMultiply ''passpoint'' by ''factorb''. Use the resulting EC point as a public key and hash it into a Bitcoin address using either compressed or uncompressed public key methodology (specify which methodology is used inside ''flagbyte''). This is the generated Bitcoin address, call it ''generatedaddress''.", "category": "bips" }, { "instruction": "Can you show me the CLI commands for Now we will encrypt ''seedb''. Derive a second key from ''passpoint'' using scrypt?", "input": "", "output": "#*Parameters: ''passphrase'' is ''passpoint'' provided from the first party (expressed in binary as 33 bytes). ''salt'' is ''addresshash'' + ''ownerentropy'', n=1024, r=1, p=1, length=64. The \"+\" operator is concatenation.\n#*Split the result into two 32-byte halves and call them ''derivedhalf1'' and ''derivedhalf2''.", "category": "bips" }, { "instruction": "I'm stuck with Bitcoin Operations Guide - what should I check?", "input": "", "output": "# Do AES256Encrypt(block = (seedb[0...15] xor derivedhalf1[0...15]), key = derivedhalf2), call the 16-byte result ''encryptedpart1''", "category": "bips" }, { "instruction": "How do I troubleshoot Do AES256Encrypt(block = ((encryptedpart1[8...15] + seedb[16...23]) xor derivedhalf1[16...31]), key = derivedhalf2), call the 16-byte result ''encryptedpart2''. The \"+\" operator is concatenation. issues?", "input": "", "output": "The encrypted private key is the Base58Check-encoded concatenation of the following, which totals 39 bytes without Base58 checksum:\n* 0x01 0x43 + ''flagbyte'' + ''addresshash'' + ''ownerentropy'' + ''encryptedpart1''[0...7] + ''encryptedpart2''\n\n=====Confirmation code=====\nThe party generating the Bitcoin address has the option to return a ''confirmation code'' back to ''owner'' which allows ''owner'' to independently verify that he has been given a Bitcoin address that actually depends on his passphrase, and to confirm the lot and sequence numbers (if applicable). This protects ''owner'' from being given a Bitcoin address by the second party that is unrelated to the key derivation and possibly spendable by the second party. If a Bitcoin address given to ''owner'' can be successfully regenerated through the confirmation process, ''owner'' can be reasonably assured that any spending without the passphrase is infeasible. This confirmation code is 75 characters starting with \"cfrm38\".\n\nTo generate it, we need ''flagbyte'', ''ownerentropy'', ''factorb'', ''derivedhalf1'' and ''derivedhalf2'' from the original encryption operation.", "category": "bips" }, { "instruction": "What are the best practices for Bitcoin Operations Guide?", "input": "", "output": "# The first byte is 0x02 or 0x03. XOR it by (derivedhalf2[31] & 0x01), call the resulting byte ''pointbprefix''.", "category": "bips" }, { "instruction": "Walk me through setting up Bitcoin Operations Guide step by step", "input": "", "output": "# Do AES256Encrypt(block = (pointb[1...16] xor derivedhalf1[0...15]), key = derivedhalf2) and call the result ''pointbx1''.", "category": "bips" }, { "instruction": "What commands would you run to work with Bitcoin Operations Guide?", "input": "", "output": "# Do AES256Encrypt(block = (pointb[17...32] xor derivedhalf1[16...31]), key = derivedhalf2) and call the result ''pointbx2''.", "category": "bips" }, { "instruction": "I want to understand Concatenate ''pointbprefix'' + ''pointbx1'' + ''pointbx2'' (total 33 bytes) and call the result ''encryptedpointb''. from a technical perspective", "input": "", "output": "The result is a Base58Check-encoded concatenation of the following:\n* 0x64 0x3B 0xF6 0xA8 0x9A + ''flagbyte'' + ''addresshash'' + ''ownerentropy'' + ''encryptedpointb''\n\nA confirmation tool, given a passphrase and a confirmation code, can recalculate the address, verify the address hash, and then assert the following: \"It is confirmed that Bitcoin address ''address'' depends on this passphrase\". If applicable: \"The lot number is ''lotnumber'' and the sequence number is ''sequencenumber''.\"\n\nTo recalculate the address:", "category": "bips" }, { "instruction": "Can you explain Bitcoin Operations Guide like we're having a beer and talking Bitcoin?", "input": "", "output": "# Derive ''passfactor'' using scrypt with ''ownerentropy'' and the user's passphrase and use it to recompute ''passpoint''", "category": "bips" }, { "instruction": "How would you explain Bitcoin Operations Guide to someone who knows Bitcoin basics?", "input": "", "output": "# Derive decryption key for ''pointb'' using scrypt with ''passpoint'', ''addresshash'', and ''ownerentropy''", "category": "bips" }, { "instruction": "I'm trying to understand Bitcoin Operations Guide - can you walk me through it?", "input": "", "output": "# Derive ''passfactor'' using scrypt with ''ownersalt'' and the user's passphrase and use it to recompute ''passpoint''", "category": "bips" }, { "instruction": "Hey, I need to set up Bitcoin Operations Guide - what's the command line way to do that?", "input": "", "output": "# Derive decryption key for ''seedb'' using scrypt with ''passpoint'', ''addresshash'', and ''ownerentropy''", "category": "bips" }, { "instruction": "What's the deal with Bitcoin Operations Guide in Bitcoin? Explain it like I'm a friend.", "input": "", "output": "# Decrypt ''encryptedpart2'' using AES256Decrypt to yield the last 8 bytes of ''seedb'' and the last 8 bytes of ''encryptedpart1''.", "category": "bips" }, { "instruction": "Can you show me the CLI commands for Bitcoin Operations Guide?", "input": "", "output": "# Multiply ''passfactor'' by ''factorb'' mod N to yield the private key associated with ''generatedaddress''.", "category": "bips" }, { "instruction": "I'm stuck with Bitcoin Operations Guide - what should I check?", "input": "", "output": "# Convert that private key into a Bitcoin address, honoring the compression preference specified in the encrypted key.", "category": "bips" }, { "instruction": "How do I troubleshoot Hash the Bitcoin address, and verify that ''addresshash'' from the encrypted private key record matches the hash. If not, report that the passphrase entry was incorrect. issues?", "input": "", "output": "==Backwards compatibility==\nBackwards compatibility is minimally applicable since this is a new standard that at most extends Wallet Import Format. It is assumed that an entry point for private key data may also accept existing formats of private keys (such as hexadecimal and Wallet Import Format); this draft uses a key format that cannot be mistaken for any existing one and preserves auto-detection capabilities.\n\n==Suggestions for implementers of proposal with alt-chains==\nIf this proposal is accepted into alt-chains, it is requested that the unused flag bytes not be used for denoting that the key belongs to an alt-chain.\n\nAlt-chain implementers should exploit the address hash for this purpose. Since each operation in this proposal involves hashing a text representation of a coin address which (for Bitcoin) includes the leading '1', an alt-chain can easily be denoted simply by using the alt-chain's preferred format for representing an address. Alt-chain implementers may also change the prefix such that encrypted addresses do not start with \"6P\".\n\n==Discussion item: scrypt parameters==\nThis proposal leaves the scrypt parameters up in the air. The following items are proposed for consideration:\n\nThe main goal of scrypt is to reduce the feasibility of brute force attacks. It must be assumed that an attacker will be able to use an efficient implementation of scrypt. The parameters should force a highly efficient implementation of scrypt to wait a decent amount of time to slow attacks.\n\nOn the other hand, an unavoidably likely place where scrypt will be implemented is using slow interpreted languages such as javascript. What might take milliseconds on an efficient scrypt implementation may take seconds in javascript.\n\nIt is believed, however, that someone using a javascript implementation is probably dealing with codes by hand, one at a time, rather than generating or processing large batches of codes. Thus, a wait time of several seconds is acceptable to a user.\n\nA private key redemption process that forces a server to consume several seconds of CPU time would discourage implementation by the server owner, because they would be opening up a denial of service avenue by inviting users to make numerous attempts to invoke the redemption process. However, it's also feasible for the server owner to implement his redemption process in such a way that the decryption is done by the user's browser, offloading the task from his own server (and providing another reason why the chosen scrypt parameters should be tolerant of javascript-based decryptors).\n\nThe preliminary values of 16384, 8, and 8 are hoped to offer the following properties:\n* Encryption/decryption in javascript requiring several seconds per operation\n* Use of the parallelization parameter provides a modest opportunity for speedups in environments where concurrent threading is available - such environments would be selected for processes that must handle bulk quantities of encryption/decryption operations. Estimated time for an operation is in the tens or hundreds of milliseconds.\n\n==Reference implementation==\nAdded to alpha version of Casascius Bitcoin Address Utility for Windows available at:\n\n* https://github.com/casascius/Bitcoin-Address-Utility\n\nClick \"Tools\" then \"PPEC Keygen\" (provisional name)\n\n==Test vectors==\n\n===No compression, no EC multiply===\n\nTest 1:\n*Passphrase: TestingOneTwoThree\n*Encrypted: 6PRVWUbkzzsbcVac2qwfssoUJAN1Xhrg6bNk8J7Nzm5H7kxEbn2Nh2ZoGg\n*Unencrypted (WIF): 5KN7MzqK5wt2TP1fQCYyHBtDrXdJuXbUzm4A9rKAteGu3Qi5CVR\n*Unencrypted (hex): CBF4B9F70470856BB4F40F80B87EDB90865997FFEE6DF315AB166D713AF433A5\n\nTest 2:\n*Passphrase: Satoshi\n*Encrypted: 6PRNFFkZc2NZ6dJqFfhRoFNMR9Lnyj7dYGrzdgXXVMXcxoKTePPX1dWByq\n*Unencrypted (WIF): 5HtasZ6ofTHP6HCwTqTkLDuLQisYPah7aUnSKfC7h4hMUVw2gi5\n*Unencrypted (hex): 09C2686880095B1A4C249EE3AC4EEA8A014F11E6F986D0B5025AC1F39AFBD9AE\n\nTest 3:\n*Passphrase ϓ␀𐐀💩 (\\u03D2\\u0301\\u0000\\U00010400\\U0001F4A9; [http://codepoints.net/U+03D2 GREEK UPSILON WITH HOOK], [http://codepoints.net/U+0301 COMBINING ACUTE ACCENT], [http://codepoints.net/U+0000 NULL], [http://codepoints.net/U+10400 DESERET CAPITAL LETTER LONG I], [http://codepoints.net/U+1F4A9 PILE OF POO])\n*Encrypted key: 6PRW5o9FLp4gJDDVqJQKJFTpMvdsSGJxMYHtHaQBF3ooa8mwD69bapcDQn\n*Bitcoin Address: 16ktGzmfrurhbhi6JGqsMWf7TyqK9HNAeF\n*Unencrypted private key (WIF): 5Jajm8eQ22H3pGWLEVCXyvND8dQZhiQhoLJNKjYXk9roUFTMSZ4\n* ''Note:'' The non-standard UTF-8 characters in this passphrase should be NFC normalized to result in a passphrase of 0xcf9300f0909080f09f92a9 before further processing\n\n===Compression, no EC multiply===\n\nTest 1:\n*Passphrase: TestingOneTwoThree\n*Encrypted: 6PYNKZ1EAgYgmQfmNVamxyXVWHzK5s6DGhwP4J5o44cvXdoY7sRzhtpUeo\n*Unencrypted (WIF): L44B5gGEpqEDRS9vVPz7QT35jcBG2r3CZwSwQ4fCewXAhAhqGVpP\n*Unencrypted (hex): CBF4B9F70470856BB4F40F80B87EDB90865997FFEE6DF315AB166D713AF433A5\n\nTest 2:\n*Passphrase: Satoshi\n*Encrypted: 6PYLtMnXvfG3oJde97zRyLYFZCYizPU5T3LwgdYJz1fRhh16bU7u6PPmY7\n*Unencrypted (WIF): KwYgW8gcxj1JWJXhPSu4Fqwzfhp5Yfi42mdYmMa4XqK7NJxXUSK7\n*Unencrypted (hex): 09C2686880095B1A4C249EE3AC4EEA8A014F11E6F986D0B5025AC1F39AFBD9AE\n\n===EC multiply, no compression, no lot/sequence numbers===\n\nTest 1:\n*Passphrase: TestingOneTwoThree\n*Passphrase code: passphrasepxFy57B9v8HtUsszJYKReoNDV6VHjUSGt8EVJmux9n1J3Ltf1gRxyDGXqnf9qm\n*Encrypted key: 6PfQu77ygVyJLZjfvMLyhLMQbYnu5uguoJJ4kMCLqWwPEdfpwANVS76gTX\n*Bitcoin address: 1PE6TQi6HTVNz5DLwB1LcpMBALubfuN2z2\n*Unencrypted private key (WIF): 5K4caxezwjGCGfnoPTZ8tMcJBLB7Jvyjv4xxeacadhq8nLisLR2\n*Unencrypted private key (hex): A43A940577F4E97F5C4D39EB14FF083A98187C64EA7C99EF7CE460833959A519\n\nTest 2:\n*Passphrase: Satoshi\n*Passphrase code: passphraseoRDGAXTWzbp72eVbtUDdn1rwpgPUGjNZEc6CGBo8i5EC1FPW8wcnLdq4ThKzAS\n*Encrypted key: 6PfLGnQs6VZnrNpmVKfjotbnQuaJK4KZoPFrAjx1JMJUa1Ft8gnf5WxfKd\n*Bitcoin address: 1CqzrtZC6mXSAhoxtFwVjz8LtwLJjDYU3V\n*Unencrypted private key (WIF): 5KJ51SgxWaAYR13zd9ReMhJpwrcX47xTJh2D3fGPG9CM8vkv5sH\n*Unencrypted private key (hex): C2C8036DF268F498099350718C4A3EF3984D2BE84618C2650F5171DCC5EB660A\n\n===EC multiply, no compression, lot/sequence numbers===\n\nTest 1:\n*Passphrase: MOLON LABE\n*Passphrase code: passphraseaB8feaLQDENqCgr4gKZpmf4VoaT6qdjJNJiv7fsKvjqavcJxvuR1hy25aTu5sX\n*Encrypted key: 6PgNBNNzDkKdhkT6uJntUXwwzQV8Rr2tZcbkDcuC9DZRsS6AtHts4Ypo1j\n*Bitcoin address: 1Jscj8ALrYu2y9TD8NrpvDBugPedmbj4Yh\n*Unencrypted private key (WIF): 5JLdxTtcTHcfYcmJsNVy1v2PMDx432JPoYcBTVVRHpPaxUrdtf8\n*Unencrypted private key (hex): 44EA95AFBF138356A05EA32110DFD627232D0F2991AD221187BE356F19FA8190\n*Confirmation code: cfrm38V8aXBn7JWA1ESmFMUn6erxeBGZGAxJPY4e36S9QWkzZKtaVqLNMgnifETYw7BPwWC9aPD\n*Lot/Sequence: 263183/1\n\nTest 2:\n*Passphrase (all letters are Greek - test UTF-8 compatibility with this): ΜΟΛΩΝ ΛΑΒΕ\n*Passphrase code: passphrased3z9rQJHSyBkNBwTRPkUGNVEVrUAcfAXDyRU1V28ie6hNFbqDwbFBvsTK7yWVK\n*Encrypted private key: 6PgGWtx25kUg8QWvwuJAgorN6k9FbE25rv5dMRwu5SKMnfpfVe5mar2ngH\n*Bitcoin address: 1Lurmih3KruL4xDB5FmHof38yawNtP9oGf\n*Unencrypted private key (WIF): 5KMKKuUmAkiNbA3DazMQiLfDq47qs8MAEThm4yL8R2PhV1ov33D\n*Unencrypted private key (hex): CA2759AA4ADB0F96C414F36ABEB8DB59342985BE9FA50FAAC228C8E7D90E3006\n*Confirmation code: cfrm38V8G4qq2ywYEFfWLD5Cc6msj9UwsG2Mj4Z6QdGJAFQpdatZLavkgRd1i4iBMdRngDqDs51\n*Lot/Sequence: 806938/1", "category": "bips" }, { "instruction": "What are the best practices for 
?",
    "input": "",
    "output": "BIP: 17\n  Layer: Consensus (soft fork)\n  Title: OP_CHECKHASHVERIFY (CHV)\n  Authors: Luke Dashjr \n  Status: Closed\n  Type: Specification\n  Assigned: 2012-01-18\n  License: BSD-2-Clause\n
\n\n==Abstract==\n\nThis BIP describes a new opcode (OP_CHECKHASHVERIFY) for the Bitcoin scripting system, and a new 'standard' transaction type that uses it to enables the receiver of bitcoins to specify the transaction type needed to re-spend them.\n\n==Copyright==\n\nThis BIP is licensed under the BSD 2-clause license.\n\n==Motivation==\n\nThe purpose of pay-to-script-hash is to move the responsibility for supplying the conditions to redeem a transaction from the sender of the funds to the redeemer.\n\nThe benefit is allowing a sender to fund any arbitrary transaction, no matter how complicated, using a fixed-length 20-byte hash that is short enough to scan from a QR code or easily copied and pasted.\n\n==Specification==\n\nOP_CHECKHASHVERIFY will re-define the existing OP_NOP2 opcode, and will function as follows when executed:\n\n* First, hash the end of the prior script (in the general case, scriptSig; if no prior script, a null string is hashed) beginning from the last evaluated OP_CODESEPARATOR onward (or from the beginning of the script, if no OP_CODESEPARATOR was present)\n* Then, compare this with the item on the top of the stack (if there is none, the script fails immediately)\n* If the hashes match, do nothing, proceed as if an OP_NOP; if they do not match, the script fails immediately.\n* Note that in the case of a matched hash, the top stack item (the hash being compared with) is not popped off the stack. This is for backward compatibility.\n\nThis opcode reassignment shall be applied when validating transactions in blocks only with timestamps after February 23, 2012 (see the Backwards Compatibility section for details).\n\nA new standard transaction type that is relayed and included in mined blocks is defined:\n\n [20-byte-hash-value] OP_CHECKHASHVERIFY OP_DROP\n\n[20-byte-hash-value] shall be the push-20-bytes-onto-the-stack opcode (0x14) followed by exactly 20 bytes.\n\nThis new transaction type is redeemed by a standard scriptSig:\n\n ...signatures... OP_CODESEPARATOR {script}\n\nTransactions that redeem these pay-to-script outpoints are only considered standard if they contain exactly one OP_CODESEPARATOR and the appended ''script'' is, itself, one of the other standard transaction types.\n\n==Example==\n\nFor example, the scriptPubKey and corresponding scriptSig for a one-signature-required transaction is:\n\n scriptSig: [signature] OP_CODESEPARATOR [pubkey] OP_CHECKSIG\n scriptPubKey: [20-byte-hash of {[pubkey] OP_CHECKSIG} ] OP_CHECKHASHVERIFY OP_DROP\n\n2-of-3:\n\n scriptSig: [signatures...] OP_CODESEPARATOR 2 [pubkey1] [pubkey2] [pubkey3] 3 OP_CHECKMULTISIG\n scriptPubKey: [20-byte-hash of {2 [pubkey1] [pubkey2] [pubkey3] 3 OP_CHECKMULTISIG} ] OP_CHECKHASHVERIFY OP_DROP\n\n==Rationale==\n\nThis BIP replaces BIP 12 and BIP 16, which propose evaluating a Script from the stack after verifying its hash.\n\nThe Motivation for this BIP (and BIP 13, the pay-to-script-hash address type) is somewhat controversial; several people feel that it is unnecessary, and complex/multisignature transaction types should be supported by simply giving the sender the complete {serialized script}. The author believes that this BIP will minimize the changes needed to all of the supporting infrastructure that has already been created to send funds to a base58-encoded-20-byte bitcoin addresses, allowing merchants and exchanges and other software to start supporting multisignature transactions sooner.\n\nThere is a 1-confirmation attack on old implementations, but it is expensive and difficult in practice. The attack is:", "category": "bips" }, { "instruction": "Walk me through setting up Bitcoin Operations Guide step by step", "input": "", "output": "# Attacker creates a pay-to-script-hash transaction that is valid as seen by old software, but invalid for new implementation, and sends themselves some coins using it.", "category": "bips" }, { "instruction": "What commands would you run to work with Bitcoin Operations Guide?", "input": "", "output": "# Attacker also creates a standard transaction that spends the pay-to-script transaction, and pays the victim who is running old software.", "category": "bips" }, { "instruction": "I want to understand Attacker mines a block that contains both transactions. from a technical perspective", "input": "", "output": "If the victim accepts the 1-confirmation payment, then the attacker wins because both transactions will be invalidated when the rest of the network overwrites the attacker's invalid block.\n\nThe attack is expensive because it requires the attacker create a block that they know will be invalidated by the rest of the network. It is difficult because creating blocks is difficult and users should not accept 1-confirmation transactions for higher-value transactions.\n\n==Backwards Compatibility==\n\nThese transactions are non-standard to old implementations, which will (typically) not relay them nor include them in blocks.\n\nOld implementations will not validate that the {script}'s hash value matches when they validate blocks created by software that fully support this BIP.\n\nAvoiding a block-chain split by malicious pay-to-script transactions requires careful handling of one case:\n\n* A pay-to-script-hash transaction that is invalid for new clients/miners but valid for old clients/miners.\n\nTo gracefully upgrade and ensure no long-lasting block-chain split occurs, more than 50% of miners must support full validation of the new transaction type and must switch from the old validation rules to the new rules at the same time.\n\nTo judge whether or not more than 50% of hashing power supports this BIP, miners are asked to upgrade their software and put the string \"p2sh/CHV\" in the input of the coinbase transaction for blocks that they create.\n\nOn February 8, 2012, the block-chain will be examined to determine the number of blocks supporting pay-to-script-hash for the previous 7 days. If at least 60% contain \"p2sh/CHV\" in their coinbase, then all blocks with timestamps after 23 Feb 2012, 00:00:00 GMT shall have their pay-to-script-hash transactions validated.\n\nIf a majority of hashing power does not support the new validation rules, then rollout will be postponed (or rejected if it becomes clear that a majority will never be achieved).\n\nOP_NOP2 is used, so existing OP_EVAL (BIP 12) transactions in the block chain can still be redeemed.\n\n==Reference Implementation==\n\n[https://gitorious.org/~Luke-Jr/bitcoin/luke-jr-bitcoin/commits/checkhashverify Validation, sending, and receiving for bitcoind git master]\n\n[https://gitorious.org/~Luke-Jr/bitcoin/luke-jr-bitcoin/commits/checkhashverify_backport Validation only for 0.3.19+]\n\n==See Also==\n\n* The [[bip-0013.mediawiki|Address format for Pay to Script Hash BIP]]\n* [[bip-0011.mediawiki|M-of-N Multisignature Transactions (BIP 11)]]\n* Example BIP 17 transaction chain: [http://blockexplorer.com/tx/b8fd633e7713a43d5ac87266adc78444669b987a56b3a65fb92d58c2c4b0e84d a] [http://blockexplorer.com/tx/eb3b82c0884e3efa6d8b0be55b4915eb20be124c9766245bcc7f34fdac32bccb b] [http://blockexplorer.com/tx/055707ce7fea7b9776fdc70413f65ceec413d46344424ab01acd5138767db137 c] [http://blockexplorer.com/tx/6d36bc17e947ce00bb6f12f8e7a56a1585c5a36188ffa2b05e10b4743273a74b d]", "category": "bips" }, { "instruction": "Can you explain 
 like we're having a beer and talking Bitcoin?",
    "input": "",
    "output": "BIP: 99\n  Title: Motivation and deployment of consensus rule changes ([soft/hard]forks)\n  Authors: Jorge Timón \n  Status: Closed\n  Type: Informational\n  Assigned: 2015-06-20\n  License: PD\n  Discussion: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008936.html\n
\n\n==Abstract==\n\nThis BIP attempts to create a taxonomy of the different types of\nconsensus forks and proposes a deployment mechanism for each of them.\n\n==Motivation==\n\nThe security assumptions of p2p consensus-based systems like Bitcoin are\nnot always well-understood, and the best upgrade mechanisms to the\nconsensus validation rules may vary depending on the type of change being deployed.\nDiscussing such changes without a uniform view on the deployment\npaths often leads to misunderstandings and unnecessarily delays the\ndeployment of changes.\n\n==Definitions==\n\n;Software fork\n: A copy of an existing project. In free software, this can be done without the permission of the original project's maintainers.\n\n;Consensus fork\n: A divergence in the implementation of the verification consensus rules can impede the expected eventual convergence of the network in a single chain that has the most proof of work and also satisfies the rules. This can be intentional or be caused by a bug in consensus validation reimplementations.\n\n;Softfork\n: A consensus fork wherein everything that was previously invalid remains invalid while blocks that would have previously considered valid become invalid. A hashrate majority of miners can impose the new rules. They have some deployment advantages like backward compatibility.\n\n;Hardfork\n: A consensus fork that makes previously invalid blocks valid. Hardforks require all users to upgrade.\n\n;Libconsensus\n: a theoretical piece of software that contains the specifications that define the validity of a block for a given state and chain parameters (ie it may act differently on, for example, regtest).\n\n;Libbitcoinconsensus\n: the existing implementation is a library that is compiled by default with Bitcoin Core master and exposes a single C function named bitcoinconsensus_verify_script(). Although it has a deterministic build and implements the most complex rules (most of the cryptography, which is itself heavily based on libsecp256k1 after #REPLACE_libsecp256k1_PR), it is still not a complete specification of the consensus rules. Since libconsensus doesn't manage the current state but only the validation of the next block given that state, it is known that this long effort of encapsulation and decoupling will eventually finish, and that the person who moves the last line\n\n==Taxonomy of consensus forks==\n\n===Accidental consensus fork===\n\nSoftware forks are very different in nature from consensus rules forks. No software\nmaintainer has special powers over consensus rules changes. There's\nmany good reasons (experimentation, lack of features, independent\ndevelopment, diversity, etc) to fork the Bitcoin Core software and it's good\nthat there's many alternative implementations of the protocol (forks\nof Bitcoin Core or written from scratch).\n\nBut sometimes a bug in the reimplementation of the consensus\nvalidation rules can prevent users of alternative implementation from\nfollowing the longest (most work) valid chain. This can result in\nthose users losing coins or being defrauded, making reimplementations\nof the consensus validation rules very risky. Note that a natural\nlanguage specification of those rules doesn't help since the\nconsensus is not determined by such specification but by the software\nthat the majority of the network runs. That's why \"the implementation\nis the specification\".\n\nBut Bitcoin Core contains many more things than just consensus\nvalidation and it would be unreasonable for all alternative\nimplementations to depend on it. Bitcoin Core should not be the\nspecification. That's why the consensus validation is being separated\ninto a libbitcoinconsensus library with a C API easily accessible from\nany language. This makes alternative implementations much more secure\nwithout burdening them with specific design choices made by Bitcoin\nCore. It is to be noted that sharing the same code for consensus\nvalidation doesn't prevent alternative implementations from\nindependently changing their consensus rules: they can always fork\nthe libbitcoinconsensus project (once it is in a separate repository).\n\nHopefully libbitcoinconsensus will remove this type of consensus fork\nwhich - being accidental - obviously doesn't need a deployment plan.\n\n====11/12 March 2013 Chain Fork====\n\nThere is a precedent of an accidental consensus fork at height 225430.\nWithout entering into much detail (see https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki), the situation was different from\nwhat's being described from the alternative implementation risks (today alternative implementation\nstill usually rely in different degrees on Bitcoin Core trusted proxies, which\nis very reasonable considering the lack of a complete libconsensus).\nThe two conflicting consensus validation implementations were two\ndifferent versions of Bitcoin Core (Bitcoin-qt at the time): 0.8\nagainst all versions prior to it. Most miners had been fast on\nupgrading to 0.8 and they were also fast on downgrading to 0.7 as an\nemergency when they were asked to by the developers community.\n\nA short summary would be that BDB was being\nabandoned in favor of levelDB, and - at the same time - the miner's\npolicy block size limit was being lift (it was not a consensus rule,\nnot even enforced via softfork). Even after testing, a case where\nlevelDB couldn't correctly validate certain bigger blocks only appeared after\ndeployment in production. Fortunately this was handled very well and\nrapidly by the whole worldwide community and nobody is unhappy about\nthe solution.\n\nBut there's some philosophical disagreements on the terms of what the\nsolution was: we can add a pedantic note on that.\nIf \"the implementation is the specification\", then those\nlevelDB-specific limitations were part of the consensus rules.\nThen additional rules were necessary and any alternative\nimplementation (including 0.8) would have to implement it. Then a\nplanned consensus fork to migrate all Bitcoin-qt 0.7- users could\nremove those additional consensus restrictions.\nHad libconsensus being implemented without depending on levelDB,\nthose additional restrictions wouldn't have been part of \"the specification\"\nand this would just have been a bug in the\nconsensus rules, just a consensus-critical bug in a set of\nimplementations, concretely all satoshi-bitcoin-0.7-or-less (which\nhappened to be a huge super majority of the users), but other\nimplementations (like libbitcoin) would be free from such bug and\nimplementing the correct libconsensus specification. But since the\nbuggy implementation was a super-majority, the solution would have\nbeen to instantly (from a specific block) change the rules to not let\nthe super-majority deviate from the specification and then have\nanother consensus fork to remove them. Two theoretical consensus forks\ninstead of one but the first one deployed practically for free. The\npractical result would have been identical and only the definitions\nchange. This means discussing something that went uncontroversially\nwell further is \"philosophical bike-shed\" (TM).\n\n===Unilateral softforks===\n\nIf it is in their best interest of miners to softfork it should be\nassumed that they may likely enforce it. In some cases, even against the will of a\nsuper-majority of users. This is practically an attack on the network\nand the only solution is to carefully design the incentives so that\nthe case is simply impossible. If that fails, miners should still\nconsider the risk of motivating a schism hardfork before attempting\nsuch a consensus fork. A deployment plan for this case is also\nunnecessary.\n\n===Schism hardforks===\n\nFundamental disagreements and controversies are part of social\nsystems, like the one defined as the human participants in the Bitcoin\nnetwork. Without judging the motivation of the rule discrepancies or\nwhat rules were in place first, we're defining schismhttps://en.wikipedia.org/wiki/Schism hardforks as\nthose in which - for whatever reason - users are consciously going to validate 2\ndifferent sets of consensus rules. Since they will validate different\nrulesets, they will end up following 2 different chains for at least\nsome time, maybe forever.\n\nOne possible result observed in the past\nis that one of the chains rapidly disappears, but nothing indicates\nthat this must always be the case.\n\nWhile 2 chains coexist, they can be considered two different\ncurrencies.\nWe could say that bitcoin becomes bitcoinA and bitcoinB. The implications for market\ncapitalization are completely unpredictable,\n\nmaybe mc(bitcoinA) = mc(bitcoinB) = mc(old_bitcoin),\n\nmaybe mc(bitcoinA) + mc(bitcoinB) = mc(old_bitcoin),\n\nmaybe mc(bitcoinA) + mc(bitcoinB) = 1000 * mc(old_bitcoin),\n\nmaybe mc(bitcoinA) + mc(bitcoinB) = 0,\n\n...\n\nSchism hardforks have been compared to one type of altcoins called\n\"spinoffs\"https://bitcointalk.org/index.php?topic=563972.0 that distribute all or part of its initial seigniorage to\nbitcoin owners at a given block height.\n\nThis is very disruptive and hopefully will never be needed. But if\nit's needed the best deployment path is just to activate the rule\nchanges after certain block height in the future. On the other hand,\nit is healthy decentralization-wise that many independent software\nprojects are ready to deploy a schism hardfork.\n\nIn all of the following examples there's clearly a confrontation that\nis being resolved using an intentional consensus hardfork.\n\n====ASIC-reset hardfork====\n\nImagine ASIC production has been consolidated to a single company and\ndistribution is simply not happening: the company is keeping them to\nmine itself. For that or another reason, a single entity controls\n40%+ of the hashrate and there's no hope for an spontaneous\nimprovement in decentralization. Such an untenable centralization could\nbe fixed (with great risks) by switching the hash function used in the\nproof of work, effectively \"pressing the restart button\" on the ASIC\nmarket. The next function should be simple to implement in ASIC as\nwell so that the market can more easily develop as a healthy and\ncompetitive one (as opposed to what the \"ASIC-hard\" proponents would\nwant), but that's another story...]\n\nSince in this case the confrontation is clearly against the current\nminers any notion of \"miners' voting\" is utterly irrelevant.\n\n====Anti-Block-creator hardfork====\n\nThere's less extreme cases where changing the pow function would not\nbe necessary. For example, let's imagine a bright future where\ncommoditized ASICs are running in millions home-heaters all over the\nworld, but the block size has been completely removed and the network has devolved to a\nvery centralized system where only 2 big pools have the resources to\nfully validate full blocks and create block templates with competitive levels of\ntransaction fees. In that case, changing the pow function would be a\nterrible waste and a risk that could be avoided. A hardfork restoring\na block size limit could help fixing this situation. Please don't\ntake it as an argument for or against raising the block size limit:\nit's just an example. But in this case, again, those 2 big pools\nwould probably be against the fork and, again, their voting is\nirrelevant.\n\nLike in the previous example, miners are expected to oppose and they\nhave to be ignored.\n\n====Anti-cabal hardfork====\n\nLet's imagine BIP66 had a crypto backdoor\nthat nobody noticed and allows an evil developer cabal to steal\neveryone's coins. The users and non-evil developers could join, fork\nlibconsensus and use the forked version in their respective bitcoin\nimplementations.\nShould miner's \"vote\" be required to express their consent? What if some miners\nare part of the cabal? In the unlikely event that most miners are\npart of such an evil cabal, changing the pow function may be\nrequired. In other cases, mining \"vote\" doesn't have much value\neither since this kind of hardfork would not qualify as\nuncontroversial anyway.\n\n===Uncontroversial consensus upgrades===\n\n\"Uncontroversial\" is something tough to define in this context. What\nif a single user decides he won't upgrade no matter what and\nhe doesn't even attempt to explain his decision? Obviously, such\na user should be just ignored. But what if the circumstances are\nslightly different? What if they're 2, 10 users? where's the line.\nIt is possible that we can never have a better definition than \"I know\nit when I see it\" [citation needed].\n\n====Uncontroversial softforks====\n\nIf a majority of miners adopts a softfork, users will follow that\nchain, even without understanding the new rules. For them is like\nif blocks are created in a certain way or certain valid transactions\nare being rejected by miners for some reason. For old nodes it just\nlooks like the new rules are policy rules rather than consensus rules.\nThis greatly reduces the deployment risks, making softforks the\npreferred consensus rules upgrade mechanism.\n\nThe first precedent of a softfork was the introduction of P2SH\ndocumented in BIP16. There were competing proposals, but BIP12 had\nclear disadvantage and BIP17 was considered a less tested but\nfunctionally equivalent version by most of the reviewers. Although it\nwas later discovered that BIP16 had unnecessary limitations and BIP17\nis now considered superior, this probably still qualified for our\nvague concept of \"uncontroversial\".\n\nAt the time, there was no \"mining voting\" implementation and it was\nsimply deployed using the timestamp of the blocks at some time in the\nfuture as the activation trigger. This can't guarantee the assumption\nthat most miners have upgraded before enforcing the new rules and\nthat's why the voting mechanism and first used for BIP30 and BIP66.\nThe current voting threshold for softfork enforcement is 95%. There's\nalso a 75% threshold for miners to activate it as a policy rule, but\nit should be safe for miners to activate such a policy from the start\nor later than 75%, as long as they enforce it as consensus rule after 95%.\n\nThe current miners' voting mechanism can be modified to allow for\nchanges to be deployed in parallel, the rejection of a concrete\nsoftfork without getting locked for the deployment of the next one,\nand also a more efficient use of the version field in block\nheadershttps://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki. BIP65 is expected to be deployed with the improved\nmechanism.\n\n====Uncontroversial hardforks====\n\nSome consensus changes require all participants to upgrade their software\nbefore the new rules can be safely activated or they will face serious\nrisk of following the wrong chain and being defrauded. Even if the\nexact same mechanism used for softforks would be more risky in these\ncases, that doesn't mean that this type of changes cannot be deployed\nin an uncontroversial and safe manner.\n\nThe simplest approach is to select a block height far enough in the\nfuture that everybody has plenty of time to change their software.\nBut if you're aiming for universal adoption, that includes miners'\nadoption, so it seems reasonable to use a mining voting on top of\nthat. In this case there's only one relevant threshold and it could\nbe different from the softfork one. Probably 100% is too strict,\nsince it would allow a relatively small miner to attack the network\nand block a consensus upgrade. Something between 99% and 95% is\nprobably a sensible choice for this parameter.\n\n====Uncontroversial emergency hardforks====\n\nEmergency forks may not have time to consult miners and have to be\ndeployed simply by choosing a block height not so far in the future.\n\nBut emergency forks could be prepared ahead of time. For example, an\nintermediary version of software could allow blocks\nthat are double the size of old blocks (after a certain height in the\nfuture) while still making miners reject bigger blocks as a softfork\nrule. Then miners can start the regular process for uncontroversial\nsoftfork (or a unilateral softfork if they're a majority) at any\npoint in the future if it is required, and both intermediary and new\nversions would be prepared for it (which would make deployment much\neasier). Other related consensus changes could be deployed in the\nmeantime (say, quadrupling the block size) making the emergency\nsoftfork unnecessary.\n\n==Code==\n\nThis BIP is complemented with a concrete code proposalhttps://github.com/jtimon/bitcoin/tree/hardfork-timewarp-0.11 for an\nuncontroversial hardfork which acts as a precedent and removes the\nperception that hardforks are impossible in Bitcoin. The deployment of\nthe proposal should not block any other potential hardforks (thus it\nwill required the version bits proposal to be implemented). The\nchange itself doesn't add much complexity to Bitcoin Core and is simple\nenough that is trivial to apply to diverse implementations (that\ncurrently can only use libbitcoinconsensus to validate script-related\nrules). The change has been already widely tested in many altcoins.\n\nThe chosen consensus change is the fix of the timewarp attack\ndiscovered and also fixed with a simple patch\nOriginal References:\nhttps://bitcointalk.org/index.php?topic=114751.0,\nhttps://bitcointalk.org/index.php?topic=43692.msg521772#msg521772;\nRebased patch:\nhttps://github.com/freicoin/freicoin/commit/beb2fa54745180d755949470466cbffd1cd6ff14\n\nby @ArtForz. This\nchange has been deployed by most altcoins that made any minimally\nmeaningful change to bitcoin and thus can be considered somewhat\ntested (in fact, most SHA256d altcoins that didn't implement it have\ndied or being forced to implement it as an emergency hardfork). When\ndeploying this change has been discussed, usually arguments in the\nlines of \"if we get to the point when this matters to bitcoin, we\nwould be already in serious trouble\" were used against it. This\nshouldn't be seen as a disadvantage in this context, since it means we\ncan safely activate the fix very far away in the future (say, 4 years\nworth of blocks).\n\n==Footnotes==\n\n\n\n==Attribution==\n\nIncorporated corrections and suggestions from: Andy Chase, Bryan Bishop,\nBtcdrak, Gavin Andresen, Gregory Sanders, Luke Dashjr, Marco Falke.\n\n==Copyright==\n\nThis document is placed in the public domain.", "category": "bips" }, { "instruction": "How would you explain 
 to someone who knows Bitcoin basics?",
    "input": "",
    "output": "BIP: 53\n  Layer: Consensus (soft fork)\n  Title: Disallow 64-byte transactions\n  Authors: Chris Stewart \n  Status: Draft\n  Type: Specification\n  Assigned: 2025-04-11\n  License: BSD-3-Clause\n
\n\n==Abstract==\n\nThis BIP describes the rationale for disallowing transactions that are serialized to 64 bytes without the transaction's witness.\nWe describe the weaknesses to the Merkle tree included in Bitcoin block headers, and various exploits for those weaknesses.\n\n==Specification==\n\nThis BIP disallows Bitcoin transactions that are serialized to 64 bytes in length without their witness.\n\n==Motivation==\n\nBitcoin block headers include a commitment to the set of transactions in a given\nblock, which is implemented by constructing a Merkle tree of transaction ids\n(double-SHA256 hash of a transaction) and including the root of the tree in the\nblock header. This in turn allows for proving to a Bitcoin light client that a\ngiven transaction is in a given block by providing a path through the tree to the\ntransaction. However, Bitcoin’s particular construction of the Merkle tree has\nseveral security weaknesses, including at least two forms of block malleability\nthat have an impact on the consensus logic of Bitcoin Core, and an attack on\nlight clients, where an invalid transaction could be ”proven” to appear in a block\nby doing substantially less work than a SHA256 hash collision would require.\nThis has been mitigated by Bitcoin Core's relay policy and the RPC interface since 2018[https://github.com/bitcoin/bitcoin/pull/11423/commits/7485488e907e236133a016ba7064c89bf9ab6da3 PR #11423 disallows transactions that are less than 82 bytes in size from Bitcoin Core relay and RPC interface][https://github.com/bitcoin/bitcoin/commit/8c5b3646b5afe8a61f5c66478d8e11f0d2ce5108 Reduces the minimum transaction size required for a transaction to be considered standard from 82 bytes to 65 bytes].\n\n=== Block malleability ===\n\n64-byte transactions introduce block malleability. Malicious peers can construct consensus valid and invalid 64-byte\ntransactions that have the same serialization as the concatenation of 2 hashes in the Merkle tree.\n\nAssume we have a valid Bitcoin block with 2 transactions in it with Txid0 and Txid1.\nThe Merkle root for this block is H(Txid0||Txid1).\nA malicious user could find a 64-byte transaction Tm that serializes to Txid0||Txid1.\nNext that user relays the block containing the malicious Tm rather than the\nvalid Bitcoin transactions that correspond to Txid0 and Txid1.\n\n==== Block malleability with consensus INVALID transactions ====\n\nThe peer receiving the malicious block marks the block as invalid, as Tm\nis not a valid transaction according to network consensus rules.\nOther peers on the network receive the valid block containing T0 and T1\nand add the block to their blockchain. Peers that receive the invalid block before the valid block\nwill never come to consensus with their peers due to the malicious user finding a collision\nwithin the block's Merkle root. Finding this collision is approximately 22 bits worth of work.[[bip-0053/2-BitcoinMerkle.pdf|to produce a block having a Merkle root that\nis a hash of a 64-byte quantity that deserializes validly, it’s enough\nto just do 8 bits of work to find a workable coinbase (which will hash to the first\n32 bytes), plus another ≈22 bits of work ((1/5) ∗224, so slightly less) to find\na workable second transaction that will hash to the second 32 bytes)– a very\nsmall amount of computation.]]\n\nThis attack vector was fixed in Bitcoin Core 0.6.2[https://bitcoin.org/en/alert/2012-05-14-dos#risks CVE-2012-2459], re-introduced in 0.13.x[https://github.com/bitcoin/bitcoin/pull/7225 #7225] and patched again in\n0.14[https://github.com/bitcoin/bitcoin/pull/9765 #9765].\n\n==== Block malleability with consensus VALID transactions ====\n\nProducing a valid Bitcoin transaction Tm that adheres to network consensus\nrules requires 224 bits of work[[bip-0053/2-BitcoinMerkle.pdf|Note that the first transaction in a block must be a coinbase, and as discussed\nabove, that largely constrains the first 32 bytes of the first transaction: only\nthe 4 version bytes are unconstrained. So it would take at least 28*8= 224 bits\nof work to find the first node in a given row of the tree that would match the\nfirst half of a coinbase, in addition to the amount of work required to grind the\nsecond half of the transaction to something meaningful (which is much easier –\nonly 16 bytes or so are constrained, so approximately 128 bits of work to find a collision). Of course, any of the rows in the Merkle tree could be used, but it nevertheless seems clear that this should be computationally infeasible.]].\nThis is computationally and financially expensive but theoretically possible. This can lead to a persistent chain split on the network.\n\n=== Attack on SPV clients ===\n\nBIP37[https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki BIP37]provides a partial Merkle tree format[https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki#partial-merkle-branch-format Partial Merkle Tree Format]\nthat allows you to verify that your Bitcoin transaction is included in a Merkle root embedded in a Bitcoin block header.\nNotably this format does not commit to the height of the Merkle tree.\n\nSuppose a (valid) 64-byte transaction T is included in a block with the property that the second 32 bytes (which\nare less constrained than the first 32 bytes) are constructed so that they collide\nwith the hash of some other fake, invalid transaction F. The attacker can fool the SPV client into believing that F\nwas included in a Bitcoin block rather than T with 81 bits[[bip-0053/2-BitcoinMerkle.pdf|An attacker who can do 81 bits of work (followed by another 40 bits of work, to\nconstruct the funding transaction whose coins will be spent by this one) is able\nto fool an SPV client in this way.]] of work. Disallowing 64-byte transactions reduces implementation complexity for SPV wallets[https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/43 The steps needed to make sure a Merkle proof for a 64-byte transaction is secure.].\n\n==Rationale==\n\n===SPV clients===\n\nAttacks on SPV clients could be mitigated by knowing the depth of the Merkle tree. Requiring SPV clients to request both the coinbase and payment transaction could mitigate this attack.\nTo produce a valid coinbase transaction at the same depth that our fake transaction F occurs at would require 224 bits of work.\nAs mentioned above, this is computationally and financially expensive, but theoretically possible. This design would increase the size\nof SPV proofs by 70%.[https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/29 Base proof: 80-byte header + 448-byte partial Merkle tree = 528 bytes. Proof with coinbase tx, assuming the coinbase tx is in the left half of the tree and the tx to prove is in the right half of the tree: 80-byte header + 416 bytes partial Merkle tree for coinbase tx + 416 bytes partial Merkle tree for tx = 912 bytes.]\n\n==Backward compatibility==\n\nThere have been 5 64-byte transactions that have occurred in the Bitcoin blockchain as of this\nwriting [[bip-0053/64byte-tx-mainnet.txt|64-byte transactions in the Bitcoin blockchain]]\nwith the last transaction 7f2efc6546011ad3227b2da678be0d30c7f4b08e2ce57b5edadd437f9e27a612[https://mempool.space/tx/7f2efc6546011ad3227b2da678be0d30c7f4b08e2ce57b5edadd437f9e27a612 Last 64-byte transaction in the Bitcoin blockchain]\noccurring at block height 419,606[https://mempool.space/block/000000000000000000308f1efc24419f34a3bafcc2b53c32dd57e4502865fd84 Block 419,606].\n\n====Pre-segwit 64-byte transactions====\n\nPre-segwit 64-byte transactions cannot spend a UTXO protected by a digital signature.[https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki After BIP66 was activated on the Bitcoin network, Bitcoin transactions cannot have a digital signature smaller than 9 bytes.]\nThe largest scriptSig a pre-segwit 64-byte transaction can have is 4 bytes.[https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/73]\n\nThere are 6[[bip-0053/non-standard-hashlock-utxos.txt|As of block `00000000000000000001194ae6be942619bf61aa70822b9643d01c1a441bf2b7` there exist 6 non-standard hashlock UTXOs that could theoretically have a 0-3 byte pre-image. None of them have a 0-3 byte pre-image.]]\nnon standard hashlock UTXOs in the Bitcoin blockchain. None of them have a 0-3 byte pre-image. This means they cannot be spent by a 64-byte transaction.\n\nPre-segwit 64-byte transactions that spend a non-standard UTXO that are inherently malleable.[https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#trust-free-unconfirmed-transaction-dependency-chain Details on how to malleate a pre-segwit transaction]\nPolicy rules such as CLEANSTACK, MINIMALDATA, PUSHONLY are not consensus rules. If a user has a way to confirm an already non-standard\n64-byte transaction - they can malleate the transaction by violating policy rules to change the size of the transaction to a size other than 64 bytes.\n\n====Segwit 64-byte transactions====\n\nThis BIP disallows single-input single-output segwit transactions that pay to a 2-byte witness program.[https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/73#p-4382-future-segwit-versions-10 BIP141 says witness programs can be 2 bytes in size, which makes the scriptPubKey a total of 4 bytes]\nThe only known use case[https://bitcoin.stackexchange.com/a/110664 Why do we have 2-byte witness programs? The original rationale for the lower end of the range of valid witness program lengths is that 2 bytes is enough to guarantee no ambiguity of how the program would be pushed (some 1-byte values can - and according to standardness, must - be pushed with OP_n, and dealing with those would have complicated the matter).]\nfor this type of transaction is ephemeral anchor outputs.[https://bitcoinops.org/en/topics/ephemeral-anchors/ What are ephemeral anchor outputs? This allows anyone on the network to use that output as the input to a child transaction. This allows anyone to create the fee-paying child, even if they don’t receive any of the other outputs from the parent transaction. This allows ephemeral anchors to function as fee sponsorship but without requiring any consensus changes.]\n\n==Reference implementation==\n\n\n/**\n * We want to enforce certain rules (specifically the 64-byte transaction check)\n * before we call CheckBlock to check the Merkle root. This allows us to enforce\n * malleability checks which may interact with other CheckBlock checks.\n * This is currently called both in AcceptBlock prior to writing the block to\n * disk and in ConnectBlock.\n * Note that as this function is called before merkle-tree checks, it must never return a\n * non-malleable error condition.\n */\nstatic bool ContextualBlockPreCheck(const CBlock& block, BlockValidationState& state, const ChainstateManager& chainman, const CBlockIndex* pindexPrev)\n{\n if (DeploymentActiveAfter(pindexPrev, chainman, Consensus::DEPLOYMENT_64BYTETX)) {\n for (const auto& tx : block.vtx) {\n if (::GetSerializeSize(TX_NO_WITNESS(tx)) == 64) {\n return state.Invalid(BlockValidationResult::BLOCK_MUTATED, \"64-byte-transaction\", strprintf(\"size of tx %s without witness is 64 bytes\", tx->GetHash().ToString()));\n }\n }\n }\n\n return true;\n}\n\n\nThe sample implementation is currently open here:\n\nhttps://github.com/bitcoin-inquisition/bitcoin/pull/24/files\n\n\n\n==Copyright==\nThis BIP is licensed under the [https://opensource.org/license/BSD-3-Clause BSD-3-Clause License].\n\n==Acknowledgements==\n\nSuhas Daftuar, AJ Towns, Sergio Demian Lerner, Greg Maxwell, Matt Corallo, Antoine Poinsot, Dave Harding and Eric Voskuil", "category": "bips" }, { "instruction": "I'm trying to understand 
 - can you walk me through it?",
    "input": "",
    "output": "BIP: 134\n  Layer: Consensus (hard fork)\n  Title: Flexible Transactions\n  Authors: Tom Zander \n  Status: Closed\n  Type: Specification\n  Assigned: 2016-07-27\n
\n\n==Abstract==\n\nThis BIP describes the next step in making Bitcoin's most basic element,\nthe transaction, more flexible and easier to extend. At the same time this\nfixes all known cases of malleability and resolves significant amounts of\ntechnical debt.\n\n==Summary==\n\nFlexible Transactions uses the fact that the first 4 bytes in a transaction\ndetermine the version and that the majority of the clients use a\nnon-consensus rule (a policy) to not accept transaction version numbers\nother than those specifically defined by Bitcoin.\nThis BIP chooses a new version number, 4, and defines that the data\nfollowing the bytes for the version is in a format called Compact Message\nFormat (CMF). CMF is a flexible, token based format where each token is a\ncombination of a name, a format and a value. Because the name is added we\ncan skip unused tokens and we can freely add new tokens in a simple manner\nin future. Soft fork upgrades will become much easier and cleaner this\nway.\n\nThis protocol upgrade cleans up past soft fork changes like BIP68 which\nreuse existing fields and do them in a better to maintain and easier\nto parse system. It creates the building blocks to allow new features to be\nadded much cleaner in the future.\n\nIt also shows to be possible to remove signatures from transactions with\nminimal upgrades of software and still maintain a coherent transaction\nhistory. Tests show that this can reduce space usage to about 75%.\n\n==Motivation==\n\nAfter 8 years of using essentially the same transaction version and layout\nBitcoin is in need of an upgrade and lessons learned in that time are\ntaking into account when designing it. The most important detail is that\nwe have seen a need for more flexibility. For instance when the 'sequence'\nfields were introduced in the old transaction format, and later deprecated\nagain, the end result was that all transactions still were forced to keep\nthose fields and grow the blockchain while they all were set to the default\nvalue.\n\nThe way towards that flexibility is to use a generic concept made popular\nvarious decades ago with the XML format. The idea is that we give each\nfield a name and this means that new fields can be added or optional fields\ncan be omitted from individual transactions. Some other ideas are the\nstandardization of data-formats (like integer and string encoding) so\nwe create a more consistent system.\nOne thing we shall not inherit from XML is its text-based format. Instead\nwe use the [https://github.com/bitcoinclassic/documentation/blob/master/spec/compactmessageformat.md Compact Message Format]\n(CMF) which is optimized to keep the size small and fast to parse.\n\nToken based file-formats are not new, systems like XML and HTMl use a\nsimilar system to allow future growth and they have been quite successful\nfor decades in part because of this property.\n\nNext to that this protocol upgrade will re-order the data-fields which\nallows us to cleanly fix the malleability issue which means that future\ntechnologies like Lightning Network will depend on this BIP being deployed.\n\nAt the same time, due to this re-ordering of data fields, it becomes very\neasy to remove signatures from a transaction without breaking its tx-id,\nwhich is great for future pruning features.\n\n=== Features ===\n\n* Fixes malleability\n* Linear scaling of signature checking\n* Very flexible future extensibility\n* Makes transactions smaller\n* Supports the Lightning Network\n\nAdditionally, in the v4 (flextrans) format we add the support for the\nfollowing proofs;\n* input amount. Including the amount means we sign this transaction only if the amount we are spending is the one provided. Wallets that do not have the full UTXO DB can safely sign knowing that if they were lied to about the amount being spent, their signature is useless.\n* scriptBase is the combined script of input and output, without signatures naturally. Providing this to a hardware wallet means it knows what output it is spending and can respond properly. Including it in the hash means its signature would be broken if we lied..\n* Double spent-proof. Should a node detect a double spent he can notify his peers about this fact. Instead of sending the entire transactions, instead he sends only a proof. The node needs to send two pairs of info that proves that in both transactions the CTxIn are identical.\n\n=== Tokens ===\n\nIn the compact message format we define tokens and in this specification we\ndefine how these tokens are named, where they can be placed and which are\noptional. To refer to XML, this specification would be the schema of\na transaction.\n\n[https://github.com/bitcoinclassic/documentation/blob/master/spec/compactmessageformat.md CMF]\ntokens are triplets of name, format (like PositiveInteger) and value.\nNames in this scope are defined much like an enumeration where the actual\ninteger value (id, below) is equally important to the written name.\nIf any token found that is not covered in the next table it will make the\ntransaction that contains it invalid.\n\n{| class=\"wikitable\"\n|-\n! Name !! id !! Format !! Default Value !! Description\n|-\n|TxEnd || 0 ||BoolTrue || Required ||A marker that is the end of the transaction\n|-\n|TxInPrevHash || 1 ||ByteArray|| Required ||TxId we are spending\n|-\n|TxPrevIndex || 2 ||Integer || 0 ||Index in prev tx we are spending (applied to previous TxInPrevHash)\n|-\n|TxInputStackItem || 3 ||ByteArray||   ||A 'push' of the input script\n|-\n|TxInputStackItemContinued||4||ByteArray|| &nsbp; ||Another section for the same input\n|-\n|TxOutValue || 5 ||Integer || Required ||Amount of Satoshis to transfer\n|-\n|TxOutScript || 6 ||ByteArray|| Required ||The output script\n|-\n|TxRelativeBlockLock|| 7 ||Integer || Optional ||Part of the input stating the amount of blocks (max 0XFFFF) after that input was mined, it can be mined\n|-\n|TxRelativeTimeLock || 8 ||Integer || Optional ||Part of the input stating the amount of time (max 0XFFFF) after that input was mined, it can be mined. 1 Unit is 512 seconds\n|-\n|CoinbaseMessage || 9 ||ByteArray|| Optional ||A message and some data for a coinbase transaction. Can't be used in combination with any TxIn\\* tags\n|-\n|NOP_1x || 1x ||  || Optional ||Values that will be ignored by anyone parsing the transaction\n|-\n|}\n\n\n=== Scripting changes ===\n\nIn Bitcoin transactions version 1, checking of signatures is performed by\nvarious opcodes. The OP_CHECKSIG, OP_CHECKMULTISIG and their equivalents\nthat immediately VERIFY. These are used to validate the cryptographic\nproofs that users have to provide in order to spend outputs.\n\nWe additionally have some hashing-types in like SIGHASH_SINGLE that all\nspecify slightly different subsections of what part of a transaction will\nbe hashed in order to be signed.\n\nFor transactions with version 4 we calculate a sha256 hash for signing an\nindividual input based on the following content;", "category": "bips" }, { "instruction": "Hey, I need to set up Bitcoin Operations Guide - what's the command line way to do that?", "input": "", "output": "# If the hash-type is 0 or 1 we hash the tx-id of the transaction. For other hash types we selectively ignore parts of the transaction exactly like it has always worked. With the caveat that we never serialize any signatures.", "category": "bips" }, { "instruction": "What's the deal with the hash-type as a var-int. in Bitcoin? Explain it like I'm a friend.", "input": "", "output": "=== Serialization order===\n\n\nTo keep in line with the name Flexible Transactions, there is very little\nrequirement to have a specific order. The only exception is cases where\nthere are optional values and reordering would make unclear what is meant.\n\nFor this reason the TxInPrevHash always has to be the first token to start\na new input. This is because the TxPrevIndex is optional. The tokens\nTxRelativeTimeLock and TxRelativeBlockLock are part of the input and\nsimilarly have to be set after the TxInPrevHash they belong to.\n\nSimilarly, the TxInputStackItem always has to be the first and can be\nfollowed by a number of TxInputStackItemContinued items.\n\nAt a larger scope we define 3 sections of a transaction.\n\n{| class=\"wikitable\"\n!Segment !! Tags !! Description\n|-\n|Transaction||all not elsewhere used||This section is used to make the TxId\n|-\n|Signatures||TxInputStackItem, TxInputStackItemContinued||The input-proofs\n|-\n|TxEnd||TxEnd|| \n|}\n\nThe TxId is calculated by taking the serialized transaction without the\nSignatures and the TxEnd and hashing that.\n\nTxEnd is there to allow a parser to know when one transaction in a stream\nhas ended, allowing the next to be parsed.\n\n=== Block-malleability ===\n\nThe effect of leaving the signatures out of the calculation of the\ntransaction-id implies that the signatures are also not used for the\ncalculation of the merkle tree. This means that changes in signatures\nwould not be detectable and open an attack vector.\n\nFor this reason the merkle tree is extended to include (append) the hash of\nthe v4 transactions. The merkle tree will continue to have all the\ntransactions' tx-ids but appended to that are the v4 hashes that include the\nsignatures as well. Specifically the hash is taken over a data-blob that\nis built up from:", "category": "bips" }, { "instruction": "Can you show me the CLI commands for The entire bytearray that makes up all of the transactions signatures. This is a serialization of all of the signature tokens, so the TxInputStackItem and TxInputStackItemContinued in the order based on the inputs they are associated with.?", "input": "", "output": "=== Future extensibility ===\n\nThe NOP_1x wildcard used in the table explaining tokens is actually a list\nof 10 values that currently are specified as NOP (no-operation) tags.\n\nAny implementation that supports the v4 transaction format should ignore\nthis field in a transaction. Interpreting and using the transaction as if\nthat field was not present at all.\n\nFuture software may use these fields to decorate a transaction with\nadditional data or features. Transaction generating software should not\ntrivially use these tokens for their own usage without cooperation and\ncommunication with the rest of the Bitcoin ecosystem as miners certainly\nhave the option to reject transactions that use unknown-to-them tokens.\n\nThe amount of tokens that can be added after number 19 is practically\nunlimited and they are currently specified to not be allowed in any\ntransaction and the transaction will be rejected if they are present.\nIn the future a protocol upgrade may chance that and specify meaning for\nany token not yet specified here. Future upgrades should thus be quite a\nlot smoother because there is no change in concepts or in format. Just new\ndata.\n\n==Backwards compatibility ==\n\nFully validating older clients will not be able to understand or validate\nversion 4 transactions and will need to be updated to restore that ability.\n\nSPV (simple payment validation) wallets need to be updated to receive or\ncreate the new transaction type.\n\nThis BIP introduces a new transaction format without changing or\ndeprecating the existing one or any of its practices. Therefore it is\nbackwards compatible for any existing data or parsing-code.\n\n==Reference Implementation==\n\nBitcoin Classic includes an implementation that is following this spec.\nThe spec-author rejects the notion of reference implementation. The\nspecification is always authoritative, the implementation is not.\n\nThe official spec can be found at;\nhttps://github.com/bitcoinclassic/documentation/blob/master/spec/transactionv4.md\n\n==Deployment==\n\nTo be determined\n\n==References==\n\n[https://github.com/bitcoinclassic/documentation/blob/master/spec/compactmessageformat.md] CMF\n\n==Copyright==\n\nCopyright (c) 2016 Tom Zander \n\nThis document is dual-licensed under the Creative-Commons BY-SA license v4.0\nand the Open Publication License v1.0 with the following licence-options:\n\nDistribution of substantively modified versions of this document is prohibited without the explicit permission of the copyright holder.\nDistribution of the work or derivative of the work in any standard (paper) book form is prohibited unless prior permission is obtained from the copyright holder.", "category": "bips" }, { "instruction": "I'm stuck with 
 - what should I check?",
    "input": "",
    "output": "BIP: 177\n  Title: Redefine Bitcoin's Base Unit\n  Authors: John Carvalho \n  Status: Draft\n  Type: Informational\n  Assigned: 2025-04-23\n  License: CC0-1.0\n
\n\n\n==Introduction==\n\n===Abstract===\n\nThis BIP proposes redefining the commonly recognized \"bitcoin\" unit so that the base unit becomes the primary reference unit. Under this proposal, one bitcoin is defined as that indivisible base unit, eliminating the convention of synthetic decimal places. By making the base unit the standard measure, this BIP aims to simplify user comprehension, reduce confusion, and align on-chain values directly with their displayed representation.\n\n===Motivation===\n\nThe current convention defines one bitcoin as 100,000,000 base units. This representation requires dealing with eight simulated decimal places, which can be confusing and foster the misconception that bitcoin is inherently decimal-based. In reality, Bitcoin’s ledger represents values as integral base units. The decimal point is merely a human-imposed abstraction.\n\nBy redefining the base unit as \"one bitcoin,\" this BIP aligns user perception with the protocol’s true nature. It reduces cognitive overhead, ensures users understand Bitcoin as counting discrete units, and ultimately improves educational clarity and user experience.\n\n===Specification===\n\n'''Redefinition of the Unit:'''\n\n* Internally, the base units remain unchanged.\n* Historically, 1 bitcoin = 100,000,000 base units. Under this proposal, \"1 bitcoin\" equals one base unit.\n* What was previously referred to as \"1 bitcoin\" now corresponds to 100 million bitcoins under the new definition.\n\n'''Terminology:'''\n\n* The informal terms \"satoshi\" or \"sat\" are deprecated.\n* All references, interfaces, and documentation SHOULD refer to the base unit simply as \"bitcoin.\"\n* The currency code \"BTC\" is unaffected by these changes, and continues to mean 100,000,000 base units.\n\n'''Display and Formatting:'''\n\n* Applications SHOULD allow users to toggle between the legacy BTC format (1 BTC = 100,000,000 base units) and the new integral format (1 bitcoin = 1 base unit).\n* Use of the ₿ symbol MAY be used to represent base-unit bitcoins but is OPTIONAL.\n\nExample 1:\n\n* Old display: 0.00010000 bitcoin\n* New display: ₿10,000 or 10,000 bitcoins or 0.00010000 BTC\n\nExample 2:\n\n* Old display: 10.23486 bitcoin\n* New display: ₿1,023,486,000 or 1,023,486,000 bitcoins or 10.23486 BTC\n\nExample 3:\n\n* Old display: 0.345 BTC\n* New display: No changes required or ₿34,500,000 or 34,500,000 bitcoins\n\nNOTE: Traditional number display abbreviations, like 2.5M for millions, are also optional.\n\n'''Conversion:'''\n\n* Ledger and consensus rules remain unchanged.\n* BTC as a currency code remains unchanged (1 BTC = 100,000,000 base units)\n* Implementations adopting this standard MUST multiply previously displayed bitcoin amounts by 100,000,000 to determine the new integer representation.\n\n===Rationale===\n\n'''Usability:'''\nInteger-only displays simplify mental arithmetic and reduce potential confusion or user error.\n\n'''Protocol Alignment:'''\nThe Bitcoin protocol inherently counts discrete units. Removing the artificial decimal format aligns user perception with Bitcoin’s actual integral design.\n\n'''Educational Clarity:'''\nPresenting integers ensures newcomers do not mistakenly assume that Bitcoin’s nature is decimal-based. It conveys Bitcoin’s true design from the start.\n\n'''Future-Proofing:'''\nAdopting the base unit as the primary measure ensures a consistent standard that can scale smoothly as Bitcoin adoption grows.\n\n'''Perception of Supply:'''\nWhile the total count of base units is roughly 2.1 quadrillion, this proposal does not alter supply in any way. The change is purely representational. Comparisons can be drawn to other currencies like the Japanese yen or Indonesian rupiah, where high unit counts are standard and not perceived as inflationary.\n\n===Addressing Alternative Approaches===\n\n'''Refuting the \"Bits\" Proposal''' \n([https://github.com/bitcoin/bips/blob/master/bip-0176.mediawiki BIP 176])\n\nAn alternative suggestion (BIP 176) proposes using \"bits\" to represent one-millionth of a bitcoin (100 satoshis). While this reduces the number of decimal places in certain contexts, it fails to fully address the core issues our BIP aims to solve:\n\n1. '''Persistent Decimal Mindset:'''\nUsing \"bits\" still retains a layered decimal approach, requiring users to think in terms of multiple denominations (BTC and bits). This shifts complexity rather than eliminating it.\n\n2. '''Inconsistent User Experience:'''\nUsers must learn to toggle between BTC for large amounts and bits for small amounts. Instead of providing a unified view of value, it fragments the user experience.\n\n3. '''Incomplete Alignment with the Protocol’s Nature:'''\nThe \"bits\" proposal does not realign the displayed value with the integral nature of Bitcoin’s ledger. It continues to rely on fractional units, masking the fundamental integer-based accounting that Bitcoin employs.\n\n4. '''Not Permanently Future-Proof:'''\nThough \"bits\" may simplify certain price ranges, future circumstances could demand additional denominations or scaling adjustments. Our integral approach resolves this problem entirely by making the base unit the standard measure, avoiding future fragmentation.\n\nIn essence, while BIP 176 attempts to simplify small amount representations, it only replaces one decimal representation with another. By redefining \"bitcoin\" as the base unit, this BIP eliminates reliance on decimal fractions and separate denominations entirely, offering a clearer, more intuitive, and ultimately more durable solution.\n\n===Handling the Terms “satoshi” and “sat”===\n\n'''Background'''\n\n“Satoshi” (or its shorthand “sat”) emerged organically some years ago, to honour Bitcoin’s creator and to give a friendly name to the 100-millionth \"fraction\" of a bitcoin. \nOver time “stacking sats” became a meme, and the term now appears in podcasts, apparel, and some wallet UIs.\n\nWhile culturally valuable, the term introduces an implicit second denomination layer that contradicts the goal of this BIP: a single base unit, called simply \"bitcoin\". Of course this BIP cannot stop anyone from using any colloquial term they prefer, but this document exists to specify how to display Bitcoin's only units as \"bitcoin\" correctly.\n\n===Backward Compatibility===\n\nNo consensus rules are altered, and on-chain data remains unchanged. Differences arise solely in display formats:\n\n* '''For Developers:''' Update GUIs, APIs, and documentation to present values as integers. Remove references to fractional Bitcoin. BTC units remain unchanged.\n\n* '''For Users:''' The actual value of holdings does not change. Transitional measures, such as dual displays or explanatory tooltips, can ease the adjustment period.\n\n===Security Considerations===\n\nA short-term risk of confusion exists as users adapt to the new representation. Users accustomed to decimals may misinterpret initial displays. To mitigate this:\n\n* Offer dual displays and tooltips during the transition.\n* Provide clear educational materials and coordinated messaging.\n* Use alerts or confirmations in applications if input values appear unexpectedly large or small.\n* Highlight the unchanging 21M BTC supply cap and equivalence to avoid misinterpretation as inflationary.\n\n===Reference Implementation===\n\nSome wallets, such as Bitkit, have successfully adopted integer-only displays, demonstrating the feasibility of this approach, without incident. Transitional features — like showing both old and new formats side-by-side — can help smooth the transition.\n\n===Test Vectors===\n\n* Old: 1.00000000 Bitcoin → New: ₿100,000,000 (or 100,000,000 bitcoins)\n* Old: 0.00010000 Bitcoin → New: ₿10,000 (or 10,000 bitcoins)\n* Old: 0.00500000 Bitcoin → New: ₿500,000 (or 500,000 bitcoins)\n* Old: 0.005 BTC → New: 0.005 BTC (or ₿500,000 or 500,000 bitcoins)\n\nAll formerly fractional representations now directly correspond to whole-number multiples of the base unit.\n\n===Implementation Timeline===\n\n'''Phase 1 (3-6 months):''' Introduce the concept, provide dual displays and educational materials. Begin pilot testing in willing wallet apps.\n\n'''Phase 2 (6-12 months):''' Prominent services adopt integer-only displays by default. Community coordination and media campaigns ensure consistency.\n\n'''Phase 3 (12+ months):''' Integer representation becomes standard. Documentation and user guides no longer reference decimal-based formats.\n\n===Conclusion===\n\nRedefining \"bitcoin\" as the smallest indivisible unit, and removing decimal-based representations, simplifies comprehension and aligns displayed values with the protocol’s integral accounting. While a transition period may be necessary, the long-term benefits include clearer communication, reduced confusion, and a more accurate understanding of Bitcoin’s fundamental design.\n\n===Copyright===\n\nThis BIP is licensed under CC0-1.0.", "category": "bips" }, { "instruction": "How do I troubleshoot RECENT CHANGES: issues?", "input": "", "output": "* (15 Feb 2021) Finalize specification\n* (28 Sep 2017) Adjust text to match test vectors\n* (19 Apr 2016) Define version 2 payment codes\n\n
\n  BIP: 47\n  Layer: Applications\n  Title: Reusable Payment Codes for Hierarchical Deterministic Wallets\n  Authors: Justus Ranvier \n  Comments-Summary: Unanimously Discourage for implementation\n  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0047\n  Status: Deployed\n  Type: Informational\n  Assigned: 2015-04-24\n
\n\n==Status==\n\nThis BIP can be considered final in terms of enabling compatibility with wallets that implement version 1 and version 2 reusable payment codes, however future developments of the reusable payment codes specification will not be distributed via the BIP process.\n\nThe Open Bitcoin Privacy Project RFC repo should be consulted for specifications related to version 3 or higher payment codes: https://github.com/OpenBitcoinPrivacyProject/rfc\n\n==Abstract==\n\nThis BIP defines a technique for creating a payment code which can be publicly advertised and associated with a real-life identity without creating the loss of security or privacy inherent to P2PKH address reuse.\n\nThis BIP is a particular application of BIP43 and is intended to supplement HD wallets which implement BIP44.\n\nThe key words \"MUST\", \"MUST NOT\", \"REQUIRED\", \"SHALL\", \"SHALL NOT\", \"SHOULD\", \"SHOULD NOT\", \"RECOMMENDED\", \"MAY\", and \"OPTIONAL\" in this document are to be interpreted as described in RFC 2119.\n\n==Motivation==\n\nPayment codes add identity information to transactions which is useful in a merchant-customer interaction while protecting the privacy of users. Payment codes provide the privacy benefits of Darkwallet-style Stealth Addresses to SPV clients without requiring the assistance of a trusted full node and while greatly reducing reliance on blockchain storage.\n\n==Path levels==\n\nWe define the following 3 levels in BIP32 path:\n\n\nm / purpose' / coin_type' / identity'\n\n\nThe child keys derived from an identity are used in different ways:\n\n\nm / purpose' / coin_type' / identity' / 0\n\n\nThe 0th (non-hardened) child is the notification key.\n\n\nm / purpose' / coin_type' / identity' / 0 through 2147483647\n\n\nThese (non-hardened) keypairs are used for ECDH to generate deposit addresses.\n\n\nm / purpose' / coin_type' / identity' / 0' through 2147483647'\n\n\nThese (hardened) keypairs are ephemeral payment codes.\n\nApostrophe in the path indicates that BIP32 hardened derivation is used.\n\nEach level has a special meaning, described in the chapters below.\n\n===Purpose===\n\nPurpose is a constant set to 47' (or 0x8000002F) following the BIP43 recommendation. It indicates that the subtree of this node is used according to this specification.\n\n===Coin type===\n\nThe coin type field is identical to the same field in BIP44\n\nHardened derivation is used at this level.\n\n===Identity===\n\nThe identity derivation level produces an extended public key and its associated extended private key.\n\nWhen the extended public key at this level is combined with the metadata specified in the Representation section below, the resulting entity is called a \"payment code.\"\n\nThis derivation level is equivalent to the Account level in BIP-44. Wallets SHOULD treat payment codes as intrinsically part of the BIP-44 account at the same index and create payment codes and accounts as pairs.\n\nFor example, the payment code created represented by (m / 47' / 0' / 0') is part of the account represented by (m / 44' / 0' / 0').\n\nThe second account in a wallet consists of the new account/payment code pair created by using an index of 1 in as the account/identity level of both paths.\n\nIncoming payments received via this specification are equivalent to payments received to BIP-44 addresses, and unspent outputs from both types of addresses can be used as inputs in the same outgoing transaction.\n\nHardened derivation is used at this level.\n\nExcept where noted, all keys derived from a payment code use the public derivation method.\n\n==Versions==\n\nPayment codes contain a version byte which identifies a specific set of behavior.\n\nUnless otherwise specified, payment codes of different versions are interoperable. If Alice uses a version x payment code, and Bob uses a version y payment code, they can still send and receive transactions between each other.\n\nCurrently specified versions:\n\n* Version 1\n** Address type: P2PKH\n** Notification type: address\n* Version 2\n** Address type: P2PKH\n** Notification type: bloom-multisig\n\n===Recommended Versions===\n\n* Wallets which have bloom filtering capabilities SHOULD create version 2 payment codes instead of version 1 payment codes.\n* Version 1 payment codes are only recommended for wallets which lack access to bloom filtering capability.\n\n==Version 1==\n\n===Representation===\n\n====Binary Serialization====\n\nA payment code contains the following elements:\n\n* Byte 0: version. required value: 0x01\n* Byte 1: features bit field. All bits must be zero except where specified elsewhere in this specification\n** Bit 0: Bitmessage notification\n** Bits 1-7: reserved\n* Byte 2: sign. required value: 0x02 or 0x03\n* Bytes 3 - 34: x value, must be a member of the secp256k1 group\n* Bytes 35 - 66: chain code\n* Bytes 67 - 79: reserved for future expansion, zero-filled unless otherwise noted\n\n====Base58 Serialization====\n\nWhen a payment code is presented to the user, it SHOULD be presented encoded in Base58Check form.\n\n* The version byte is: 0x47 (produces a \"P\" as the first character of the serialized form)\n* The payload is the binary serialization of the payment code\n\n===Protocol===\n\nIn the following examples, Alice and Bob are identities with a corresponding payment codes. Alice initiates a Bitcoin transaction, and Bob is the recipient of the transaction.\n\nIt is assumed that Alice can easily obtain Bob's payment code via a suitable method outside the scope of the payment code protocol.\n\n====Definitions====\n\n* Payment code: an extended public key and associated metadata which is associated with a particular identity/account\n* Notification address: the P2PKH address associated with the 0th public key derived from a payment code\n* Notification transaction: a transaction which sends an output to a notification address which includes an embedded payment code\n* Designated input: the first input in the notification transaction which exposes an secp256k1 pubkey in either its signature script, or in the redeem script or pubkey script of the output being spent\n* Designated pubkey: the first secp256k1 pubkey pushed to the stack during script execution for the designated input\n* Outpoint: the specific output of a previous transaction which is being spent. See the Reference section for the binary serialization\n\n====Notification Transaction====\n\nPrior to the first time Alice initiates a transaction to Bob, Alice MUST inform Bob of her payment code via the following procedure:\n\nNote: this procedure is used if Bob uses a version 1 payment code (regardless of the version of Alice's payment code). If Bob's payment code is not version 1, see the appropriate section in this specification.", "category": "bips" }, { "instruction": "What are the best practices for Alice constructs a transaction which sends a small quantity of bitcoins to Bob's notification address (notification transaction)?", "input": "", "output": "## The inputs selected for this transaction MUST NOT be easily associated with Alice's notification address", "category": "bips" }, { "instruction": "Walk me through setting up Alice derives a unique shared secret using ECDH: step by step", "input": "", "output": "## Alice selects the private key corresponding to the designated pubkey: 
a
\n## Alice selects the public key associated with Bob's notification address: 
B, where B = bG
\n## Alice calculates a secret point: 
S = aB
\n## Alice calculates a 64 byte blinding factor: 
s = HMAC-SHA512(o, x)
\n### \"x\" is the x value of the secret point\n### \"o\" is the outpoint being spent by the designated input", "category": "bips" }, { "instruction": "What commands would you run to work with Alice renders her payment code (P) unreadable to anyone except Bob:?", "input": "", "output": "## Replace the x value with x': 
x' = x XOR (first 32 bytes of s)
\n## Replace the chain code with c': 
c' = c XOR (last 32 bytes of s)
", "category": "bips" }, { "instruction": "I want to understand Bitcoin Operations Guide from a technical perspective", "input": "", "output": "# When a transaction is received, the client examines it to determine if it contains a standard OP_RETURN output with an 80 byte payload (notification transactions).", "category": "bips" }, { "instruction": "Can you explain If the first byte of the payload in a notification transaction is 0x01: like we're having a beer and talking Bitcoin?", "input": "", "output": "## Bob selects the designated pubkey: 
A, where A = aG
\n## Bob selects the private key associated with his notification address: 
b
\n## Bob calculates a secret point: 
S = bA
\n## Bob calculates the blinding factor: 
s = HMAC-SHA512(x, o)
\n### \"x\" is the x value of the secret point\n### \"o\" is the outpoint being spent by the designated input.\n## Bob interprets the 80 byte payload as a payment code, except:\n### Replace the x value with x': 
x' = x XOR (first 32 bytes of s)
\n### Replace the chain code with c': 
c' = c XOR (last 32 bytes of s)
\n## If the updated x value is a member of the secp256k1 group, the payment code is valid.\n## If the updated x value is not a member of the secp256k1 group, the payment code is ignored.\n\nNow that Bob's client has received Alice's payment code, it is possible for Alice to send payments (up to 232 payments) to Bob.\n\nAlice will never again need to send a notification transaction to Bob.\n\nBitcoins received via notification transactions require special handling in order to avoid privacy leaks:", "category": "bips" }, { "instruction": "How would you explain Bitcoin Operations Guide to someone who knows Bitcoin basics?", "input": "", "output": "# The value of outputs received to notification addresses MUST NOT be displayed to the user as part of their spendable balance.", "category": "bips" }, { "instruction": "I'm trying to understand Bitcoin Operations Guide - can you walk me through it?", "input": "", "output": "# Outputs received to notification addresses MUST NOT be used as inputs for any transaction that involve ECDH calculations using any of the user's payment codes.", "category": "bips" }, { "instruction": "Hey, I need to set up Bitcoin Operations Guide - what's the command line way to do that?", "input": "", "output": "# Outputs received to notification addresses MAY be passed through a mixing service before being added to the user's spendable balance.", "category": "bips" }, { "instruction": "What's the deal with Outputs received to notification addresses MAY be donated to miners using dust-b-gone or an equivalent procedure. in Bitcoin? Explain it like I'm a friend.", "input": "", "output": "=====Standard Notification Transaction Scripts=====\n\nAlice SHOULD use an input script in one of the following standard forms to expose a public key, and compliant applications SHOULD recognize all of these forms.\n\n* P2PK (pay to pubkey)\n* P2PKH (pay to pubkey hash)\n* Multisig (bare multisig, without P2SH)\n* a script which spends any of the above script forms via P2SH (pay to script hash)\n\nCompatible wallets MAY provide a method for a user to manually specify the public key associated with a notification transaction in order to recover payment codes sent via non-standard notification transactions.\n\n=====Post-Notification Privacy Considerations=====\n\nIncautious handling of change outputs from notification transactions may cause unintended loss of privacy.\n\nThe recipient of a transaction which spends a change output from a prior notification transaction will learn about the potential connection between the sender and the recipient of the notification transaction.\n\nThe following actions are recommended to reduce this risk:\n\n* Wallets which support mixing SHOULD mix change outputs from notification transactions prior to spending them\n* Wallets which do not support mixing MAY simulate mixing by creating a transaction which spends the change output to the next external BIP44 address\n\n====Sending====", "category": "bips" }, { "instruction": "Can you show me the CLI commands for Each time Alice wants to initiate a transaction to Bob, Alice derives a unique P2PKH address for the transaction using ECDH as follows:?", "input": "", "output": "## Alice selects the 0th private key derived from her payment code: 
a
\n## Alice selects the next unused public key derived from Bob's payment code, starting from zero: 
B, where B = bG
\n### The \"next unused\" public key is based on an index specific to the Alice-Bob context, not global to either Alice or Bob\n## Alice calculates a secret point: 
S = aB
\n## Alice calculates a scalar shared secret using the x value of S: 
s = SHA256(Sx)
\n### If the value of s is not in the secp256k1 group, Alice MUST increment the index used to derive Bob's public key and try again.\n## Alice uses the scalar shared secret to calculate the ephemeral public key used to generate the P2PKH address for this transaction: 
B' = B + sG
\n\n", "category": "bips" }, { "instruction": "I'm stuck with Bob is watching for incoming payments on B' ever since he received the notification transaction from Alice. - what should I check?", "input": "", "output": "## Bob calculates n shared secrets with Alice, using the 0th public key derived from Alice's payment code, and private keys 0 - n derived from Bob's payment code, where n is his desired lookahead window.\n## Bob calculates the ephemeral deposit addresses using the same procedure as Alice: 
B' = B + sG
\n## Bob calculate the private key for each ephemeral address as: 
b' = b + s
\n\n\n\n====Refunds====\n\nBecause Bob learns Alice's payment code as part of the process of receiving a payment, Bob has all the information he needs in order to send a refund to Alice.\n\nA refund transaction is identical to a payment transactions, with only the roles of the participants switches.\n\nBob MUST send a notification transaction to Alice prior to the first time he sends funds to Alice, even if he has received transactions from her in the past.\n\n\n\n====Anonymous Payments====\n\nIf Alice does not want her payment to Bob to be associated with her identity, she generates an ephemeral payment code to use for the transaction.\n\n* Ephemeral payment codes are the hardened children of a payment code, starting from an index of zero.\n* An ephemeral payment code SHOULD only be used for a single outgoing payment.\n* The notification address of an ephemeral payment code MUST be monitored for notification transactions in order to detect incoming refund payments\n* The correspondence between BIP44 accounts and ephemeral payment codes is 1:many\n\n====Cold Storage====\n\n* Unlike traditional watching-only wallets, those associated with payment codes held in cold storage can not detect incoming payments immediately.\n* When the watching-only wallet detects an incoming notification transaction, it packages the transaction in an implementation-specific format suitable for transfer to the offline device.\n* The offline device recovers the payment code, then pre-generates a large number of relevant keypairs (example: 10000) in order to minimize the need for air gap round trips.\n* The offline device then packages the relevant public keys in an implementation-specific format suitable for transfer to the online device.\n* The online device can then watch for incoming payments using a suitable lookahead window.\n* If the lookahead window reaches the end of the pre-generated public keys, the user must generate more keys on the offline device and transfer them to the online device.\n\n====Wallet Recovery====\n\nNormal operation of a payment code-enabled wallet can be performed by an SPV client and does not require access to a complete copy of the blockchain.\n\nRecovering a wallet from a seed, however, does require access to a fully-indexed blockchain.\n\nThe required data may be obtained from copy of the blockchain under the control of the user, or via a publicly-queryable blockchain explorer.\n\nWhen querying a public blockchain explorer, wallets SHOULD connect to the explorer through Tor (or equivalent) and SHOULD avoid grouping queries in a manner that associates ephemeral addresses with each other.\n\nPreviously-spendable funds will generally not be lost or become inaccessible after a recovery from a seed, but all information regarding previous outgoing payments will be lost.\n\nIn order to recover received funds from a seed, the wallet must obtain every notification it has ever received to its notification address, including all spent transactions. It then re-establishes its lookahead window for each subchain by scanning every derived address sequentially until it locates a contiguous block of unused addresses of a user-specified length.\n\nThe metadata which a wallet must store to properly process outgoing transactions consists of:", "category": "bips" }, { "instruction": "How do I troubleshoot A list of every payment code to which the identity has sent a notification transaction. issues?", "input": "", "output": "## This list is lost if a wallet must be recovered from a seed.\n## The recovered wallet MUST send notification transactions as if it was a newly-created wallet", "category": "bips" }, { "instruction": "What are the best practices for The index value corresponding to the next unused pubkey for each payment code on the previous list?", "input": "", "output": "## This value can be recovered by checking each ephemeral deposit address in sequence for transactions.\n## Wallets MAY use a lookahead window capable of detecting gaps in the address sequence during this recovery operation.", "category": "bips" }, { "instruction": "Walk me through setting up The index value of the next unused ephemeral payment code. step by step", "input": "", "output": "## Recovering all incoming funds associated with ephemeral payment codes with 100% certainty requires exhausting the entire 232 address space of potential ephemeral payment codes.\n### In most cases, less than 100% certainty is acceptable as long as a fallback \"deep scan\" is available as an option to the user.\n## The wallet checks the notification address for each ephemeral payment code for notification transactions in order to recover associated funds.\n## Since most ephemeral payment codes will not receive a refund transaction wallets SHOULD use a large lookahead window for this recovery operation.\n## The recovered value MUST be chosen as a number higher than any ephemeral payment code which has received a notification transaction.\n\n===Wallet Sharing===\n\nWallets using payment codes generally should not be shared across multiple devices, given the need to synchronize metadata between each instance.\n\nIf wallets are shared between devices without a synchronization mechanism, undesirable address reuse can occur.\n\nWallets may perform an OPTIONAL check for existing transactions to an ephemeral deposit addresses prior to sending a transaction by checking a local copy of the blockchain or querying a public blockchain explorer via Tor or equivalent.\n\n===Alternate Notification Methods===\n\nIn order to ensure that no funds will be lost in the event the recipient must recover their wallet from a seed, the sender MUST send a notification transaction the first time the sender interacts with a particular recipient.\n\nA recipient MAY choose to designate alternate notification methods which the sender may use in addition to a notification transaction.\n\nIf the recipient specifies an alternate notification method, a compliant implementation MAY refrain from continually monitoring the notification address and SHOULD check the notification address periodically to detect payments sent by users who can not employ the alternate method.\n\nA recipient specifies their preference for alternate notification by setting the appropriate bits in the feature byte of their payment code.\n\n===Bitmessage Notification===\n\nA recipient which prefers to receive notifications via Bitmessage indicates this preference by:\n\n* Setting bit 0 of the features byte to 1\n* Setting byte 67 of the serialized payment code to the desired Bitmessage address version\n* Setting byte 68 of the serialized payment code to the desired Bitmessage stream number\n\nThe sender uses this information to construct a valid notification Bitmessage address:", "category": "bips" }, { "instruction": "What commands would you run to work with Bitcoin Operations Guide?", "input": "", "output": "# If the combination of B and B` do not form a valid Bitmessage address, increment n by one and try again", "category": "bips" }, { "instruction": "I want to understand Use the address version, signing key, encryption key, and stream number to construct a Bitmessage address per the Bitmessage protocol from a technical perspective", "input": "", "output": "The sender transmits their payment code in base58 form to the calculated Bitmessage address.\n\nIn order to use Bitmessage notification, the recipient must have a Bitmessage client which listens at the address which the senders will derive and is capable of relaying received payment codes to the Bitcoin wallet.\n\n==Version 2==\n\nVersion 2 payment codes behave identifically to version 1 payment codes, except as modified below.\n\n===Representation===\n\n====Binary Serialization====\n\n* Byte 0: version. required value: 0x02\n\n===Protocol===\n\n====Definitions====\n\n* Notification change output: the change output from a notification transaction which resides in the sender's wallet, but can be automatically located by the intended recipient\n* Payment code identifier: a 33 byte representation of a payment code constructed by prepending 0x02 to the SHA256 hash of the binary serialization of the payment code\n\n====Notification Transaction====\n\nNote: this procedure is used if Bob uses a version 2 payment code (regardless of the version of Alice's payment code). If Bob's payment code is not version 2, see the appropriate section in this specification.", "category": "bips" }, { "instruction": "Can you explain Bitcoin Operations Guide like we're having a beer and talking Bitcoin?", "input": "", "output": "# Construct a notification transaction as per the version 1 instructions, except do not create the output to Bob's notification address", "category": "bips" }, { "instruction": "How would you explain Create a notification change address as follows: to someone who knows Bitcoin basics?", "input": "", "output": "## Obtain the pubkey corresponding to the next change address\n## Construct a multisig output in the form:\n
OP_1   OP_2 OP_CHECKMULTISIG
\n\nThe relative ordering of the payment code identifier and change address pubkey in the above script MAY be randomized\n\nBob detects notification transactions by adding his payment code identifier to his bloom filter.", "category": "bips" }, { "instruction": "I'm trying to understand When the filter returns a notification transaction, the sender's payment code is unblinded using the same procedure as for version 1 notification transactions. - can you walk me through it?", "input": "", "output": "Alice's wallet should spend the notification change output at the next appropriate opportunity.\n\n==Test Vectors==\n\n* [[https://gist.github.com/SamouraiDev/6aad669604c5930864bd|BIP47 Reusable Payment Codes Test Vectors]]\n\n==Reference==\n\n* [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]]\n* [[bip-0043.mediawiki|BIP43 - Purpose Field for Deterministic Wallets]]\n* [[bip-0044.mediawiki|BIP44 - Multi-Account Hierarchy for Deterministic Wallets]]\n* [[https://bitcoin.org/en/developer-reference#outpoint|Outpoint]]\n* [[https://github.com/petertodd/dust-b-gone|dust-b-gone]]\n* [[https://en.bitcoin.it/wiki/Base58Check_encoding|Base58Check encoding]]\n* [[https://bitmessage.org/bitmessage.pdf|Bitmessage]]\n* [[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-April/007812.html|Mailing list discussion]]", "category": "bips" }, { "instruction": "Hey, I need to set up 
 - what's the command line way to do that?",
    "input": "",
    "output": "BIP: 101\n  Layer: Consensus (hard fork)\n  Title: Increase maximum block size\n  Authors: Gavin Andresen \n  Status: Closed\n  Type: Specification\n  Assigned: 2015-06-22\n
\n\n==Abstract==\n\nThis BIP proposes replacing the fixed one megabyte maximum block size with a maximum size that grows over time at a predictable rate.\n\n==Motivation==\n\nTransaction volume on the Bitcoin network has been growing, and will soon reach the one-megabyte-every-ten-minutes limit imposed by the one megabyte maximum block size. Increasing the maximum size reduces the impact of that limit on Bitcoin adoption and growth.\n\n==Specification==\n\nAfter deployment (see the Deployment section for details), the maximum allowed size of a block on the main network shall be calculated based on the timestamp in the block header.\n\nThe maximum size shall be 8,000,000 bytes at a timestamp of 2016-01-11 00:00:00 UTC (timestamp 1452470400), and shall double every 63,072,000 seconds (two years, ignoring leap years), until 2036-01-06 00:00:00 UTC (timestamp 2083190400). The maximum size of blocks in between doublings will increase linearly based on the block's timestamp. The maximum size of blocks after 2036-01-06 00:00:00 UTC shall be 8,192,000,000 bytes.\n\nExpressed in pseudo-code, using integer math, assuming that block_timestamp is after the activation time (as described in the Deployment section below):\n\n function max_block_size(block_timestamp):\n\n time_start = 1452470400\n time_double = 60*60*24*365*2\n size_start = 8000000\n if block_timestamp >= time_start+time_double*10\n return size_start * 2^10\n\n // Piecewise-linear-between-doublings growth:\n time_delta = block_timestamp - time_start\n doublings = time_delta / time_double\n remainder = time_delta % time_double\n interpolate = (size_start * 2^doublings * remainder) / time_double\n max_size = size_start * 2^doublings + interpolate\n\n return max_size\n\n==Deployment==\n\nDeployment shall be controlled by hash-power supermajority vote (similar to the technique used in BIP34), but the earliest possible activation time is 2016-01-11 00:00:00 UTC.\n\nActivation is achieved when 750 of 1,000 consecutive blocks in the best chain have a version number with the first, second, third, and thirtieth bits set (0x20000007 in hex). The activation time will be the timestamp of the 750'th block plus a two week (1,209,600 second) grace period to give any remaining miners or services time to upgrade to support larger blocks. If a supermajority is achieved more than two weeks before 2016-01-11 00:00:00 UTC, the activation time will be 2016-01-11 00:00:00 UTC.\n\nBlock version numbers are used only for activation; once activation is achieved, the maximum block size shall be as described in the specification section, regardless of the version number of the block.\n\n==Test network==\n\nTest network parameters are the same as the main network, except starting earlier with easier supermajority conditions and a shorter grace period:\n\n starting time: 1 Aug 2015 (timestamp 1438387200)\n activation condition: 75 of 100 blocks\n grace period: 24 hours\n\n==Rationale==\n\nThe initial size of 8,000,000 bytes was chosen after testing the current reference implementation code with larger block sizes and receiving feedback from miners on bandwidth-constrained networks (in particular, Chinese miners behind the Great Firewall of China).\n\nThe doubling interval was chosen based on long-term growth trends for CPU power, storage, and Internet bandwidth. The 20-year limit was chosen because exponential growth cannot continue forever. If long-term trends do not continue, maximum block sizes can be reduced by miner consensus (a soft-fork).\n\nCalculations are based on timestamps and not blockchain height because a timestamp is part of every block's header. This allows implementations to know a block's maximum size after they have downloaded it's header, but before downloading any transactions.\n\nThe deployment plan is taken from Jeff Garzik's proposed BIP100 block size increase, and is designed to give miners, merchants, and full-node-running-end-users sufficient time to upgrade to software that supports bigger blocks. A 75% supermajority was chosen so that one large mining pool does not have effective veto power over a blocksize increase. The version number scheme is designed to be compatible with Pieter's Wuille's proposed \"Version bits\" BIP, and to not interfere with any other consensus rule changes in the process of being rolled out.\n\n==Objections to this proposal==\n\nRaising the 1MB block size has been [https://www.google.com/webhp?#q=1mb+limit+site%3Abitcointalk.org discussed and debated for years].\n\n===Centralization of full nodes===\n\nThe number of fully-validating nodes reachable on the network has been steadily declining. Increasing the capacity of the network to handle transactions by increasing the maximum block size may accelerate that decline, meaning a less distributed network that is more vulnerable to disruption. The size of this effect is debatable; the author of this BIP believes that the decline in fully validating nodes on the network is largely due to the availability of convenient, attractive, secure, lightweight wallet software and the general trend away from computing on desktop computers to mobile phones and tablets.\n\nIncreasing the capacity of the network to handle transactions should enable increased adoption by users and businesses, especially in areas of the world where existing financial infrastructure is weak. That could lead to a more robust network with nodes running in more political jurisdictions.\n\n===Centralization of mining: costs===\n\nMiners benefit from low-latency, high-bandwidth connections because they increase their chances of winning a \"block race\" (two or more blocks found at approximately the same time). With the current peer-to-peer networking protocol, announcing larger blocks requires more bandwidth. If the costs grow high enough, the result will be a very small number of very large miners.\n\nThe limits proposed by this BIP are designed so that running a fully validating node has very modest costs, which, if current trends in the cost of technology continue, will become even less expensive over time.\n\n===Centralization of mining: big-block attacks===\n\n[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008820.html Simulations show] that with the current peer-to-peer protocol, miners behind high-latency or low-bandwidth links are at a disadvantage compared to miners connected to a majority of hashpower via low-latency, high-bandwidth links. Larger blocks increase the advantage of miners with high-bandwidth connections, although that advantage can be minimized with changes to the way new blocks are announced (e.g. http://bitcoinrelaynetwork.org/ ).\n\nIf latency and bandwidth to other miners were the only variable that affected the profitability of mining, and miners were driven purely by profit, the end result would be one miner running on one machine, where latency was zero and bandwidth was essentially infinite.\n\nHowever, many other factors influence miner profitability, including cost of electricity and labor and real estate, ability to use waste heat productively, access to capital to invest in mining equipment, etc. Increasing the influence of bandwidth in the mining profitability equation will not necessarily lead to more centralization.\n\n===Unspent Transaction Output Growth===\n\nThis BIP makes no attempt to restrict the approximately 100% per-year growth in unspent transaction outputs (see http://gavinandresen.ninja/utxo-uhoh for details), because the author believe that problem should be solved by a further restriction on blocks described in a separate BIP (perhaps an additional limit on how much the transactions in any block may increase the UTXO set size).\n\n==Long-term fee incentives==\n\nhttp://gavinandresen.ninja/block-size-and-miner-fees-again\n\n==Other solutions considered==\n\nThere have been dozens of proposals for increasing the block size over the years. Some notable ideas:\n\n===One-time increase===\n\nA small, quick one-time increase to, for example, 2MB blocks, would be the most conservative option.\n\nHowever, a one-time increase requires just as much care in testing and deployment as a longer-term fix. And the entire debate over how large or small a limit is appropriate would be repeated as soon as the new limit was reached.\n\n===Dynamic limit proposals===\n\nBIP 100 proposes a dynamic limit determined by miner preferences expressed in coinbase transactions, with limits on the rate of growth. It gives miners more direct control over the maximum block size, which some people see as an advantage over this proposal and some see as a disadvantage. It is more complex to implement, because the maximum allowed size for a block depends on information contained in coinbase transactions from previous blocks (which may not be immediately known if block contents are being fetched out-of-order in a 'headers-first' mode).\n\n[https://bitcointalk.org/index.php?topic=1078521.0 Meni Rosenfeld has proposed] that miners sacrifice mining reward to \"pay for\" bigger blocks, so there is an incentive to create bigger blocks only if transaction fees cover the cost of creating a larger block. This proposal is significantly more complex to implement, and it is not clear if a set of parameters for setting the cost of making a block bigger can be found that is not equivalent to a centrally-controlled network-wide minimum transaction fee.\n\n==Compatibility==\n\nThis is a hard-forking change to the Bitcoin protocol; anybody running code that fully validates blocks must upgrade before the activation time or they will risk rejecting a chain containing larger-than-one-megabyte blocks.\n\nSimplified Payment Verification software is not affected, unless it makes assumptions about the maximum depth of a transaction's merkle branch based on the minimum size of a transaction and the maximum block size.\n\n==Implementation==\n\nhttps://github.com/bitcoin/bitcoin/pull/6341", "category": "bips" }, { "instruction": "What's the deal with 
 in Bitcoin? Explain it like I'm a friend.",
    "input": "",
    "output": "BIP: 197\n  Layer: Applications\n  Title: Hashed Time-Locked Collateral Contract\n  Authors: Matthew Black \n           Tony Cai \n  Status: Draft\n  Type: Specification\n  Assigned: 2019-03-19\n  License: BSD-3-Clause OR CC0-1.0\n
\n\n==Abstract==\n\nThis BIP describes a script for generalized debt agreement contract based on Hashed Time-Lock Contract (BIP 199) transactions according to the Atomic Loans specification (https://arxiv.org/pdf/1901.05117.pdf). For more details visit https://atomicloans.io.\n\n==Summary==\n\nA Hashed Time-Locked Collateral Contract (HTLCC) consists of two scripts that permit a designated party (the \"borrower\") to lock funds on the Bitcoin chain for a specified amount of time as collateral in a debt agreement where the loan principal is denominated in a currency on another blockchain. We denote the blockchain on which the loan principal is issued the principal blockchain.\n\nThe purpose of each script is to enable the creation of a debt agreement between two parties (the \"borrower\" and the \"lender\"), where the collateral is locked in a P2SH, and can only be spent once the borrower repays the principal and interest in the debt agreement on the principal blockchain. In the case that the borrower does not repay, the borrower or lender can opt for liquidation of the collateral, which will involve the atomic swapping of collateral for the loan currency. In the case that at least one of the two parties don't opt for liquidation, then each party will be entitled to a percentage of the collateral, decided when the funds are initially locked in the P2SH.\n\nThese funds are locked into two scripts. Refundable Collateral and Seizable Collateral scripts. The funds sent to these scripts represent the percentage of collateral that each party is entitled to in the case that repayment fails, and the parties don't opt for liquidation.\n\nThe Refundable Collateral script takes the following form:\n\n OP_IF\n OP_SIZE OP_EQUALVERIFY [HASHOP] OP_EQUALVERIFY OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG\n OP_ELSE\n OP_IF\n [TIMEOUTOP] OP_DROP OP_SIZE OP_PUSHDATA(1) OP_EQUALVERIFY [HASHOP] OP_EQUALVERIFY OP_SIZE OP_EQUALVERIFY [HASHOP] OP_EQUALVERIFY OP_2 OP_2 OP_CHECKMULTISIG\n OP_ELSE\n [TIMEOUTOP] OP_DROP OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG\n OP_ENDIF\n OP_ENDIF\n\nThe Seizable Collateral script takes the following form:\n\n OP_IF\n OP_SIZE OP_EQUALVERIFY [HASHOP] OP_EQUALVERIFY OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG\n OP_ELSE\n OP_IF\n [TIMEOUTOP] OP_DROP OP_SIZE OP_EQUALVERIFY [HASHOP] OP_EQUALVERIFY OP_SIZE OP_EQUALVERIFY [HASHOP] OP_EQUALVERIFY OP_2 OP_2 OP_CHECKMULTISIG\n OP_ELSE\n OP_IF\n [TIMEOUTOP] OP_DROP OP_SIZE OP_EQUALVERIFY [HASHOP] OP_EQUALVERIFY OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG\n OP_ELSE\n [TIMEOUTOP] OP_DROP OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG\n OP_ENDIF\n OP_ENDIF\n OP_ENDIF\n\n[HASHOP] is either OP_SHA256 or OP_HASH160.\n\n[TIMEOUTOP] is either OP_CHECKSEQUENCEVERIFY or OP_CHECKLOCKTIMEVERIFY.\n\n===Interaction===\n\n* Alice (the \"borrower\") and Bob (the \"lender\") exchange public keys as well as two secret hashes A1, A2 created by Alice and three hashes B1, B2, B3 created by Bob. They then mutually agree upon a timeout threshold for the Loan Period, Liquidation Period, and Seizure Period. Alice constructs the script and P2SH address for the Refundable Collateral Contract and Seizable Collateral Contract. Bob constructs the script for the blockchain on which the loan principal will be issued - the principal blockchain.\n\n* Bob sends loan principal funds to the loan script on the principal blockchain\n\n* Alice sends funds to the Refundable Collateral P2SH address and the Seizable Collateral P2SH address. The amount of funds she sends to the two addresses will be determined beforehand off-chain between Alice and Bob.\n\n* Either\n** Bob accepts locking of collateral by Alice and reveals B1, allowing Alice to withdraw the loan amount on the principal blockchain.\n** Bob doesn't accept locking of collateral by Alice, and recovers the funds after the approve expiration while revealing B2, which allows Alice to refund the Refundable and Seizable collateral.\n\n** If Bob accepts the locking of collateral by Alice\n\n*** Either\n**** Alice repays the loan by the end of the Loan Period and Bob reveals the secret to Alice by revealing it in the loan repayment acceptance transaction; OR\n**** Alice defaults on the loan and Alice and Bob both opt for collateral liquidation, where any third-party is able to bid on the collateral. The winning bidder, Charlie, will subsequently receive the liquidated collateral by way of an Atomic Swap between the collateral funds (ie. BTC locked in both the Refundable Collateral P2SH and the Seizable Collateral P2SH) and the bid funds (ie. funds denominated in the loan currency, put forth by Charlie as part of his bid). This is done by both Alice and Bob signing a multisig and revealing A2 and B2; OR\n**** Alice defaults on the loan and at least one of Alice or Bob opts out of collateral liquidation, then Alice recovers the Refundable Collateral funds and Bob spends the Seizable Collateral funds.\n**** Alice defaults on the loan and at least one of Alice or Bob opts out of collateral liquidation. But Bob doesn't spend the Seizable Collateral funds, so Alice recovers both the Refundable Collateral funds and the Seizable Collateral funds.\n\n==Compatibility==\n\nBIP 197 is compatible with [https://github.com/ethereum/EIPs/pull/1850 ERC 1850] for [https://arxiv.org/pdf/1901.05117.pdf atomic loans] with Ethereum. Can be extended in the future to be compatible with other HTLC and smart contract compatible chains.\n\n==Motivation==\n\nIn many different protocols, the revealing of secrets is used as a settlement mechanism. HTLCC transactions are a safe way of exchanging secrets to advance the state of a debt agreement, due to the ability to recover a percentage of collateral funds from an uncooperative counterparty, and ensure principal + interest + liquidation fee is paid with a cooperative party.\n\n==Definitions==\n\nborrower: entity that locks collateral on the Bitcoin chain and receives loan amount on principal blockchain from lender following the approval of the borrower’s borrow request\n\nlender: entity that contributes funds to the Hashed Time-Locked Principal Contract (HTLPC) on the principal blockchain, to be borrowed by the borrower upon the locking of collateral on the Bitcoin chain and the lender’s approval\n\nrepay: when the borrower pays back the principal + interest before loanExpiration\n\ndefault: when the borrower fails to pay back the principal + interest before the loanExpiration\n\nsecret: random number chosen by the borrower or lender, revealed to allow the parties to change the state of the debt agreement\n\nsecretHash: hash of the secret, used in the construction of HTLCC\n\nSecretA1: secret generated by the borrower, used to prove that the borrower has withdrawn the loan\n\nSecretA2: secret generated by the borrower, used to allow the bidder to withdraw the liquidated collateral funds\n\nSecretB1: secret generated by the lender, used to accept the locking of collateral by borrower, enabling borrower to withdraw the loan amount\n\nSecretB2: secret generated by the lender, used to refund themselves in the event they aren't satisfied with borrower’slocking of collateral. Also used to accept borrower’s repayment of principal plus interest\n\nSecretB3: secret generated by the lender, used to allow the bidder to withdraw the liquidated collateral funds\n\nSecretC: secret generated by the bidder, used to accept the signatures of the borrower and lender for authorizing the liquidation of collateral\n\nloan expiration num: timestamp before which the borrower must repay the loan; or otherwise risk the liquidation or seizure of their collateral\n\nbidding expiration num: timestamp that determines the amount of time allocated to bidding before seizure period occurs\n\nseizure expiration num: timestamp that determines the amount of time during which the lender can seize funds within the Seizable Collateral P2SH, after which the borrower can refund their corresponding amount of the collateral they are entitled to (ie. either just the funds within the Refundable Collateral P2SH, or both the Refundable Collateral and Seizable Collateral in the event where the lender failed to seize).\n\n===Approve Period===\nDuring this time, the lender deploys the HTLPC on the principal blockchain. Following this, the borrower locks their collateral on the Bitcoin blockchain in a HTLCC. The lender then either reveals secretB1 to signify that they are satisfied with the collateral, and the borrower can withdraw the loan by revealing secretA1. If the lender is not satisfied with the collateral locked by the borrower, the lender can refunds their loan amount by revealing secretB2, which will subsequently allow the borrower to refund the collateral amount they deposited.\n\n===Loan Period===\nOnce the borrower has withdrawn the loan amount, the Loan Period begins. Once the Loan Period is finished, the borrower is expected to repay the loan. If they do, the lender can then accept the repayment by revealing secretB2, enabling the borrower to refund their collateral amount. In the case that the borrower defaults or does not repay the full principal plus interest amount, the lender can choose to not accept the loan repayment, and the parties can opt for liquidation of the collateral in the Bidding Period.\n\n===Bidding Period===\nIn the case of a default or the lender not accepting the borrower repayment, the lender and borrower can opt for liquidation of the collateral through the process of third party bidders bidding on the collateral. The Bidding Period can be initiated by either the lender or the borrower. Once the bidding timeout occurs, the lender and borrower must each provide a signature, followed by secretC revealed by the winning bidder once they have checked that the signature is proper. Finally, the lender and borrower must each reveal secretA2 and secretB3 to allow the collateral to be withdrawn by the winning bidder.\n\n===Seizure Period===\nIn the case that either the lender or borrower don’t accept the bid, the lender can seize a percentage of the collateral. The amount is dependent on the amount of collateral locked in the Seizable Collateral and Refundable Collateral script as described in this BIP. During this period, the borrower can also refund the funds locked in the Refundable Collateral script.\n\n===Refund Period===\nIn the case that the lender does not seize the collateral locked in the Seizable Collateral script, then the borrower can refund the funds locked in the Seizable Collateral script.\n\n==Rationale==\n\nThe rational for the following script checking the length of secrets pushed to the stack that are used with OP_SHA256 in the following script\n\n OP_SIZE OP_EQUALVERIFY\n\nis to ensure that the secret size is exactly a certain number of bytes long.\n\nThis is especially important when this script is used alongside the HTLPC on other chains like Ethereum where the sha256 opcode only takes up 32 bytes and disregards the rest, there is a need to ensure that the length on the Bitcoin side is 32 bytes.\n\n==Backwards Compatibility==\n\nAs this is a new standard for collateralized debt, there is no need for backward compatibility. Once this is accepted as a standard there are certain aspects of the contract that can be modified while still retaining backwards compatibility, such as removing the need to verify the size of the hash if being used with two blockchains with the same maximum block size, which would be backward compatible with the current script.\n\n==Implementation==\n\nhttps://github.com/AtomicLoans/chainabstractionlayer/blob/dev/packages/bitcoin-collateral-provider/lib/BitcoinCollateralProvider.js\n\n==Copyright==\n\nThis document is dual licensed as BSD 3-clause, and Creative Commons CC0 1.0 Universal.", "category": "bips" }, { "instruction": "Can you show me the CLI commands for 
?",
    "input": "",
    "output": "BIP: 13\n  Layer: Applications\n  Title: Address Format for pay-to-script-hash\n  Authors: Gavin Andresen \n  Status: Deployed\n  Type: Specification\n  Assigned: 2011-10-18\n
\n\n==Abstract==\n\nThis BIP describes a new type of Bitcoin address to support arbitrarily complex transactions. Complexity in this context is defined as what information is needed by the recipient to respend the received coins, in contrast to needing a single ECDSA private key as in current implementations of Bitcoin.\n\nIn essence, an address encoded under this proposal represents the encoded hash of a [https://en.bitcoin.it/wiki/Script script], rather than the encoded hash of an ECDSA public key.\n\n==Motivation==\n\nEnable \"end-to-end\" secure wallets and payments to fund escrow transactions or other complex transactions. Enable third-party wallet security services.\n\n==Specification==\n\nThe new bitcoin address type is constructed in the same manner as existing bitcoin addresses (see [https://en.bitcoin.it/Base58Check_encoding Base58Check encoding]):\n\n base58-encode: [one-byte version][20-byte hash][4-byte checksum]\n\nVersion byte is 5 for a main-network address, 196 for a testnet address.\nThe 20-byte hash is the hash of the script that will be used to redeem the coins.\nAnd the 4-byte checksum is the first four bytes of the double SHA256 hash of the version and hash.\n\n==Rationale==\n\nOne criticism is that bitcoin addresses should be deprecated in favor of a more user-friendly mechanism for payments, and that this will just encourage continued use of a poorly designed mechanism.\n\nAnother criticism is that bitcoin addresses are inherently insecure because there is no identity information tied to them; if you only have a bitcoin address, how can you be certain that you're paying who or what you think you're paying?\n\nFurthermore, truncating SHA256 is not an optimal checksum; there are much better error-detecting algorithms. If we are introducing a new form of Bitcoin address, then perhaps a better algorithm should be used.\n\nThis is one piece of the simplest path to a more secure bitcoin infrastructure. It is not intended to solve all of bitcoin's usability or security issues, but to be an incremental improvement over what exists today. A future BIP or BIPs should propose more user-friendly mechanisms for making payments, or for verifying that you're sending a payment to the Free Software Foundation and not Joe Random Hacker.\n\nAssuming that typing in bitcoin addresses manually will become increasingly rare in the future, and given that the existing checksum method for bitcoin addresses seems to work \"well enough\" in practice and has already been implemented multiple times, the Author believes no change to the checksum algorithm is necessary.\n\nThe leading version bytes are chosen so that, after base58 encoding, the leading character is consistent: for the main network, byte 5 becomes the character '3'. For the testnet, byte 196 is encoded into '2'.\n\n==Backwards Compatibility==\n\nThis proposal is not backwards compatible, but it fails gracefully-- if an older implementation is given one of these new bitcoin addresses, it will report the address as invalid and will refuse to create a transaction.\n\n==Reference Implementation==\n\nSee base58.cpp/base58.h at https://github.com/bitcoin/bitcoin/tree/master/src\n\n==See Also==\n\n* [[bip-0012.mediawiki|BIP 12: OP_EVAL, the original P2SH design]]\n* [[bip-0016.mediawiki|BIP 16: Pay to Script Hash (aka \"/P2SH/\")]]\n* [[bip-0017.mediawiki|BIP 17: OP_CHECKHASHVERIFY, another P2SH design]]", "category": "bips" }, { "instruction": "I'm stuck with 
 - what should I check?",
    "input": "",
    "output": "BIP: 36\n  Layer: Peer Services\n  Title: Custom Services\n  Authors: Stefan Thomas \n  Status: Closed\n  Type: Specification\n  Assigned: 2012-08-03\n  License: PD\n
\n\n==Abstract==\n\nThis BIP adds new fields to the version message which clients can use to announce custom services without polluting the limited 64-bit services field. It also makes some non-binding recommendations regarding the implementation of custom services.\n\n==Motivation==\n\nWe would like to encourage experimentation with custom services that extend the Bitcoin protocol with useful functionality. Examples include Distributed Hash Tables (DHT), distributed pools, lightweight client support protocols, directed message routing and support for custom transports. However, without a general framework for protocol extensions, these custom services are likely to collide in various ways. This BIP provides such a framework.\n\n==Specification==\n\nTwo new fields are added to the version command, after extra_height:\n\n{|class=\"wikitable\"\n! Field Size !! Description !! Data type !! Comments\n|-\n| 1+ || service_count || [[Protocol_specification#variable-length-integer|var_int]] || Number of extra services\n|-\n| ? || service_list || service[] || List of service definitions\n|}\n\nThe service definitions service[] are given in the following format:\n\n{|class=\"wikitable\"\n! Field Size !! Description !! Data type !! Comments\n|-\n| ? || service_name || [[#variable-length-string|var_str]] || Unique service identifier\n|-\n| 4 || service_version || uint32_t || Identifies service version being used by the node\n|-\n| ? || service_data || [[#variable-length-string|var_str]] || Additional service-specific data\n|}\n\nA node MUST NOT announce two services with the same service_name. If a remote node sends such a version message the client MAY disconnect.\n\nThe service_version is service-specific and can be any integer. Higher versions SHOULD be higher integers. When a service is standardized, it is assigned a NODE_* constant for use with the services field and future iterations of the protocol depend on the Bitcoin protocol version. Both the NODE_* flag and the custom service entry MAY be provided for the duration of a transitional period.\n\nServices SHOULD pass an empty string (0x00) as service_data and use a custom handshake to initialize their protocol, exchange information about capabilities etc. Note that to become a standardized service, a service MUST NOT rely on service_data since there is no corresponding mechanism for the standard services defined in the services field.\n\nHowever, services MAY use service_data if they do not intend to become standard services and need a simple way to transmit a small amount of initialization data. For example, a node offering a custom transport like UDP or WebSocket, may choose to announce this as a service and include the port number in service_data. The format for service_data is service-specific and may be any binary or ASCII data. For ease of debugging, a human-readable (ASCII) format is generally recommended.\n\n===Service identifier===\n\nEach service SHOULD choose a new identifier that is not used by any other service. To register a new identifier, add it to the [[Service identifiers]] wiki page along with the name of the maintainer and a way to contact them. Please do not register identifiers unless you are actually using them.\n\nService identifiers that are reserved or used by an accepted BIP MUST NOT be used except in the way specified by that BIP.\n\nService identifiers MUST be between five (5) and eleven (11) characters long. Service identifiers MUST use only ASCII characters, excluding: / * _ :\n\nValid examples:\n* MySampleSvc\n* smartserv\n* P-Pool\n\nValid, but discouraged examples:\n\n* MySVC 1.0 (use service_version to differentiate versions)\n* @@---. (identifiers should be pronounceable)\n* lightweight (avoid too generic names)\n\nInvalid examples:\n\n* Pppc (too short)\n* SuperService (too long)\n* Cool_Svc (invalid character)\n\n===Optional: Custom commands===\n\nBitcoin command names are limited to 12 characters. That doesn't leave a lot of space for both the service identifier and the service command. Therefore we recommend that all service commands SHOULD be represented by a single \"command\" on the Bitcoin network. This command SHOULD consist of the exact service identifier to avoid collisions with other services, prefixed by an underscore to avoid collisions with current or future Bitcoin protocol messages. For example: _MySampleSvc\n\nThe service-specific command name SHOULD then be specified in an extra header in the payload:\n\n{|class=\"wikitable\"\n! Field Size !! Description !! Data type !! Comments\n|-\n| 12 || subcommand || char[12] || ASCII string identifying the service command, NULL padded (non-NULL padding results in packet rejected)\n|-\n| ? || subpayload || uchar[] || The actual data\n|}\n\nThe length of subpayload is derived from the length of the total payload minus twelve (12) bytes for the subcommand. Implementations MUST NOT rely on this format to be used by unknown services. Clients SHOULD ignore any services or subcommands they don't explicitly understand.\n\nThe recommended way to refer to messages following this format in documentation is by the service identifier, followed by a colon, followed by the subcommand. For example, the subcommand search for the MySampleSvc service would be referred to as: MySampleSvc:search\n\nFull hexdump of an example MySampleSvc:search message:\n\n
\n0000   F9 BE B4 D9 5F 4D 79 53  61 6D 70 6C 65 53 76 63   ...._MySampleSvc\n0010   14 00 00 00 73 D5 56 77  73 65 61 72 63 68 00 00   ....s.Vwsearch..\n0020   00 00 00 00 12 34 56 78  9A BC DE F0               .....4Vx....\n\nMessage header:\n F9 BE B4 D9                                                                   - Main network magic bytes\n 5F 4D 79 53 61 6D 70 6C 65 53 76 63                                           - \"_MySampleSvc\" command\n 14 00 00 00                                                                   - Payload is 20 bytes long\n                                                                                 (includes 12 bytes for subcommand)\n 73 D5 56 77                                                                   - Checksum\n\nService header:\n 73 65 61 72 63 68 00 00 00 00 00 00                                           - \"search\" subcommand\n\nSearch message:\n 12 34 56 78 9A BC DE F0                                                       - Payload\n
\n\n==Standardization==\n\nCustom services may become standard parts of the protocol. Services which wish to become part of the Bitcoin protocol MUST fulfill the following criteria:\n\n* MUST NOT use service_data; Standard services have no corresponding field\n* MUST use a peer discovery mechanism which specifies one bit per node, same as the services field in addr messages\n* MUST NOT use any subcommands that conflict with current or planned Bitcoin protocol commands\n\nThe standardization process will usually take place as follows:", "category": "bips" }, { "instruction": "How do I troubleshoot Once the BIP is accepted, the service is assigned a NODE_* constant and the transitional period starts: issues?", "input": "", "output": "#* Clients MUST understand both the announcement of the service via the services field and via service_list and include both methods in their own version message.\n#* Clients MUST accept both the wrapped form messages like MySampleSvc:search as well as the corresponding non-namespaced messages like search. Clients MUST only send wrapped messages.\n#* During the transitional period the API of the service MUST NOT change.", "category": "bips" }, { "instruction": "What are the best practices for After the transitional period:?", "input": "", "output": "#* Clients MUST only announce the service via the services field.\n#* Clients MUST only send unwrapped messages.", "category": "bips" }, { "instruction": "Walk me through setting up Future changes to the service API now require a BIP and an increase in the Bitcoin protocol version. step by step", "input": "", "output": "This process of adding a service to the Bitcoin protocol should only be undertaken for services where there is a strong rationale for doing so. Services MAY also be standardized as custom services via a BIP while maintaining the custom service format.\n\n==Rationale==\n\nThis BIP aims to fulfill the following goals:\n\n* Minimize the risk of namespace collisions, ambiguities or other issues arising from conflicting custom services\n* Provide an easy upgrade path for custom services to become standardized services with their own NODE_* flag\n* Place minimum restrictions on custom service authors\n* Allow custom services to be created with minimum effort\n* Allow clients to support multiple/many custom services at once\n\nTo achieve these goals this BIP adds two new fields to the version message. It would have been possible to avoid changes to version by adding a new message instead. However, it makes sense to keep both types of service announcements in the same message so that the life cycle of standardized services and custom services remains exactly the same. This also simplifies detecting a service which is in the transition from a custom to a standardized service (and being announced using both methods.)\n\nFinally, this BIP defines both explicitly and implicitly some useful common nomenclature that can be used when discussing custom services, e.g. \"subcommand\", \"subpayload\", \"service identifier\" and the colon format for referring to subcommands.\n\n==Copyright==\n\nThis document is placed in the public domain.", "category": "bips" }, { "instruction": "What commands would you run to work with 
?",
    "input": "",
    "output": "BIP: 48\n  Layer: Applications\n  Title: Multi-Script Hierarchy for Multi-Sig Wallets\n  Authors: Fontaine \n  Status: Deployed\n  Type: Specification\n  Assigned: 2020-12-16\n  License: MIT\n
\n\n==Abstract==\n\nThis BIP defines a logical hierarchy for deterministic multi-sig wallets based on an algorithm\ndescribed in BIP-0067 (BIP67 from now on), BIP-0032 (BIP32 from now on), purpose scheme described in\nBIP-0043 (BIP43 from now on), and multi-account hierarchy described in\nBIP-0044 (BIP44 from now on).\n\nThis BIP is a particular application of BIP43.\n\n==Copyright==\n\nThis BIP falls under the MIT License.\n\n==Motivation==\n\nThe motivation of this BIP is to define the existing industry wide practice of utilizing m/48'\nderivation paths in hierarchical deterministic multi-sig wallets so that other developers may\nbenefit from a standard. This BIP allows for future script types to easily be appended to the\nspecification so that a new BIP is not required for every future script type.\n\nThe hierarchy proposed in this paper is quite comprehensive. It allows the handling of\nmultiple accounts, external and internal chains per account, multiple script types and\nmillions of addresses per chain.\n\nThis paper was inspired from BIP44.\n\n==Backwards compatibility==\n\nCurrently a number of wallets utilize the ‎m/48' derivation scheme for HD multi-sig accounts.\nThis BIP is intended to maintain the *existing* real world use of the ‎m/48' derivation.\nNo breaking changes are made so as to avoid \"loss of funds\" to existing users.\nWallets which currently support the ‎m/48' derivation will not need to make any changes\nto comply with this BIP.\n\n==Specification==\n\n===Key sorting===\n\nAny wallet that supports BIP48 inherently supports deterministic key sorting as per BIP67 so that all possible\nmulti-signature addresses/scripts are derived from deterministically sorted public keys.\n\n===Path levels===\n\nWe define the following 6 levels in BIP32 path:\n\n
\nm / purpose' / coin_type' / account' / script_type' / change / address_index\n
\n\nh or ' in the path indicates that BIP32 hardened derivation is used.\n\nEach level has a special meaning, described in the chapters below.\n\n===Purpose===\n\nPurpose is a constant set to 48' following the BIP43 recommendation.\nIt indicates that the subtree of this node is used according to this specification.\n\nHardened derivation is used at this level.\n\n===Coin type===\n\nOne master node (seed) can be used for multiple Bitcoin networks.\nSharing the same space for various networks has some disadvantages.\n\nAvoiding reusing addresses across networks and improving privacy issues.\n\nCoin type 0 for mainnet and 1 for testnet.\n\nHardened derivation is used at this level.\n\n===Account===\n\nThis level splits the key space into independent user identities, following the BIP44 pattern,\nso the wallet never mixes the coins across different accounts.\n\nUsers can use these accounts to organize the funds in the same\nfashion as bank accounts; for donation purposes (where all\naddresses are considered public), for saving purposes,\nfor common expenses etc.\n\nAccounts are numbered from index 0 in sequentially increasing manner.\nThis number is used as child index in BIP32 derivation.\n\nHardened derivation is used at this level.\n\n===Script===\n\nThis level splits the key space into two separate script_type(s). To provide\nforward compatibility for future script types this specification can be easily extended.\n\nCurrently the only script types covered by this BIP are Native Segwit (p2wsh) and\nNested Segwit (p2sh-p2wsh).\n\nThe following path represents Nested Segwit (p2sh-p2wsh) mainnet, account 0:\n1': Nested Segwit (p2sh-p2wsh) m/48'/0'/0'/1'
\n\nThe following path represents Native Segwit (p2wsh) mainnet, account 0:\n2': Native Segwit (p2wsh) m/48'/0'/0'/2'
\n\nThe recommended default for wallets is pay to witness script hash m/48'/0'/0'/2'.\n\n===Change===\n\nConstant 0 is used for external chain and constant 1 for internal chain (also\nknown as change addresses). External chain is used for addresses that are meant\nto be visible outside of the wallet (e.g. for receiving payments). Internal\nchain is used for addresses which are not meant to be visible outside of the\nwallet and is used for return transaction change.\n\nPublic derivation is used at this level.\n\n===Index===\n\nAddresses are numbered from index 0 in sequentially increasing manner.\nThis number is used as child index in BIP32 derivation.\n\nPublic derivation is used at this level.\n\n==Examples==\n\n{|\n|network\n|account\n|script\n|chain\n|address\n|path\n|-\n|mainnet\n|first\n|p2sh-p2wsh\n|external\n|first\n|m / 48' / 0' / 0' / 1' / 0 / 0\n|-\n|mainnet\n|first\n|p2wsh\n|external\n|first\n|m / 48' / 0' / 0' / 2' / 0 / 0\n|-\n|mainnet\n|first\n|p2wsh\n|external\n|second\n|m / 48' / 0' / 0' / 2' / 0 / 1\n|-\n|mainnet\n|first\n|p2wsh\n|change\n|first\n|m / 48' / 0' / 0' / 2' / 1 / 0\n|-\n|mainnet\n|first\n|p2wsh\n|change\n|second\n|m / 48' / 0' / 0' / 2' / 1 / 1\n|-\n|mainnet\n|second\n|p2wsh\n|external\n|first\n|m / 48' / 0' / 1' / 2' / 0 / 0\n|-\n|mainnet\n|second\n|p2wsh\n|external\n|second\n|m / 48' / 0' / 1' / 2' / 0 / 1\n|-\n|testnet\n|first\n|p2sh-p2wsh\n|external\n|first\n|m / 48' / 1' / 0' / 1' / 0 / 0\n|-\n|testnet\n|first\n|p2wsh\n|external\n|second\n|m / 48' / 1' / 0' / 2' / 0 / 1\n|-\n|testnet\n|first\n|p2wsh\n|change\n|first\n|m / 48' / 1' / 0' / 2' / 1 / 0\n|-\n|testnet\n|first\n|p2wsh\n|change\n|second\n|m / 48' / 1' / 0' / 2' / 1 / 1\n|-\n|testnet\n|second\n|p2wsh\n|external\n|first\n|m / 48' / 1' / 1' / 2' / 0 / 0\n|-\n|testnet\n|second\n|p2wsh\n|external\n|second\n|m / 48' / 1' / 1' / 2' / 0 / 1\n|-\n|testnet\n|second\n|p2wsh\n|change\n|first\n|m / 48' / 1' / 1' / 2' / 1 / 0\n|-\n|testnet\n|second\n|p2wsh\n|change\n|second\n|m / 48' / 1' / 1' / 2' / 1 / 1\n|}\n\n\n==Reference==\n\n* [[bip-0067.mediawiki|BIP67 - Deterministic Pay-to-script-hash multi-signature addresses through public key sorting]]\n* [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]]\n* [[bip-0043.mediawiki|BIP43 - Purpose Field for Deterministic Wallets]]\n* [[bip-0044.mediawiki|BIP44 - Multi-Account Hierarchy for Deterministic Wallets]]", "category": "bips" }, { "instruction": "I want to understand 
 from a technical perspective",
    "input": "",
    "output": "BIP: 15\n  Layer: Applications\n  Title: Aliases\n  Authors: Amir Taaki \n  Status: Closed\n  Type: Specification\n  Assigned: 2011-12-10\n
\n\n[[bip-0070.mediawiki|BIP 0070]] (payment protocol) may be seen as the alternative to Aliases.\n\nUsing vanilla bitcoin, to send funds to a destination, an address in the form 1Hd44nkJfNAcPJeZyrGC5sKJS1TzgmCTjjZ is needed. The problem with using addresses is that they are not easy to remember. An analogy can be thought if one were required to enter the IP address of their favourite websites if domain names did not exist.\n\nThis document aims to layout through careful argument, a bitcoin alias system. This is a big modification to the protocol that is not easily changed in the future and has big ramifications. There is impetus in getting it correct the first time. Aliases have to be robust and secure.\n\n== Schemes ==\n\nHere are a few different proposals and the properties of each system.\n\n=== FirstBits ===\n\nFirstBits is a proposal for using the blockchain as an address book.\n\nWhen bitcoins are sent to an address, that address becomes recorded in the blockchain. It is therefore known that this address exists or did exist by simply seeing that there was a payment to that address. FirstBits is a method to have a memorable alias. One first converts the address to lower-case, then takes the first few unique characters. This is your FirstBits alias.\n\nAs an example, brmlab hackerspace in Prague has an address for purchasing food or drink, or making donations:\n\n 1BRMLAB7nryYgFGrG8x9SYaokb8r2ZwAsX\n\nTheir FirstBits alias becomes:\n\n 1brmlab\n\nIt is enough information to be given the FirstBits alias ''1brmlab''. When someone wishes to make a purchase, without FirstBits, they either have to type out their address laboriously by hand, scan their QR code (which requires a mobile handset that this author does not own) or find their address on the internet to copy and paste into the client to send bitcoins. FirstBits alleviates this impracticality by providing an easy method to make payments.\n\nTogether with Vanitygen (vanity generator), it becomes possible to create memorable unique named addresses. Addresses that are meaningful, rather than an odd assemblage of letters and numbers but add context to the destination.\n\nHowever FirstBits has its own problems. One is that the possible aliases one is able to generate is limited by the available computing power available. It may not be feasible to generate a complete or precise alias that is wanted- only approximates may be possible. It is also computationally resource intensive which means a large expenditure of power for generating unique aliases in the future, and may not scale up to the level of individuals at home or participants with hand-held devices in an environment of ubiquitous computing.\n\nFirstBits scales extremely poorly as the network grows. Each indexer or lookup node needs to keep track of every bitcoin address ever in existence and provide a fast lookup from the aliases to those addresses. As the network grows linearly, the number of addresses should grow exponentially (assuming a networked effect of (n-1)*(n-2)/2) rapidly making this scheme unfeasible.\n\nLight clients of the partial merkle root types become dependent on a trusted third party for their alias lookups. The cost of storing every bitcoin address is too high considering their typical use-case on low-resource devices. This factor more than the others, means this scheme is sub-optimal and must be rejected.\n\n=== DNS TXT Records ===\n\nDNS allows TXT records to be created containing arbitrary data. In a bitcoin alias system, a custom format mutually agreed upon by a BIP standard would be used to store mappings to bitcoin addresses from domain names. How such a format would look is out of the scope of this document.\n\nAn issue is that it requires people who wish to create such mappings to be familiar with configuring DNS records, and be able to run the necessary toolsets to insert the correct data. Although not a huge concern, it is a usability issue.\n\nSecurity wise, DNS is unsafe and insecure by design. It is possible to spoof records by being on the same network as another host. A number of revisions to mitigate the issue under the guise of DNSSEC have been in the works since the 1990s and are still being rolled out.\n\nAs of Dec 2011, DNSSEC is still not yet a defacto standard on the internet. Should a participant in the bitcoin network wish to use DNS TXT records, they would in addition to having to configure DNS, be able to setup DNSSEC. This may not be feasible, especially where some registrars provide access to DNS through a web interface only.\n\nThe disadvantage of DNS TXT records is that updating a record takes time. This encourages people to not use new addresses per transaction which has certain security issues.\n\n=== Server Service ===\n\nAside from using DNS TXT records, another possibility is using the domain name system to lookup hosts and then contact a service running on a predefined port to get the bitcoin address.", "category": "bips" }, { "instruction": "Can you explain Client sends the funds to the address like we're having a beer and talking Bitcoin?", "input": "", "output": "The service would be responsible for providing the mechanisms for changing and storing the mappings on their service. A front-end web interface could be provided to users wishing to use the service and customise their accounts on the server.\n\nThis approach has the positive aspect of providing the best flexibility for the implementer to store the records however they wish in a database or plaintext file, and then serve them up quickly using a small server side daemon typically written in C. This approach is highly scalable.\n\nHowever this approach also suffers the problem of being reliant on DNS and hence also being vulnerable to spoofing. Hence DNSSEC is also required. This approach is slightly better than the DNS TXT records though since it makes inserting new users and modifying aliases very easy which allows people to run these server services more cheaply.\n\n=== HTTPS Web Service ===\n\nHTTPS provides an additional layer of security by encrypting the connection, providing much needed privacy for users. Together with using Certificate Authorities, it fixes the issue with using DNSSEC since an error would be thrown up were someone to try to spoof a domain name on the local network.\n\nWhen trying to send to:\n\n genjix@foo.org\n\nThe request is broken into the handle (genjix) and domain (foo.org) at the last occurrence of the @. The client then constructs a request that will query for the address.\n\n https://foo.org/bitcoin-alias/?handle=genjix\n\nbitcoin-alias has been chosen as the query suffix because it allows this system to co-exist easily within another web root without the fear of name clashes.\n\nThe query will then return an address which is used to make the payment.\n\n 1Hd44nkJfNAcPJeZyrGC5sKJS1TzgmCTjjZ\n\nThe details of whether a unique address is returned per query, whether an address is fetched from a pre-existing pool of addresses, and so on is an implementation detail unique to every server. How alias to address mappings are setup is dependent on the site which could have a web-interface and be providing a free service to users or be a private customised service serving pre-existing addresses. This is left up to sysop policy, and deliberately not defined here.\n\nA web service is trivial to setup and the cost is low. There are many free out of the box providers on the net that allows anyone with the most basic knowledge of web technologies to create their own website. By providing users with a package, anybody can quickly set themselves up with a bitcoin alias. It could be something as simple as a PHP script that the user edits with their custom settings and uploads themselves to their website.\n\nIt also scales reasonably- anybody wishing to run a naming service can attach a backend with a variety of database technologies then provide a web frontend for users to customise and create their own aliases.\n\nA naive implementation is provided below as an example.\n\n
\n// resolv.h\n#ifndef NOMRESOLV_H__\n#define NOMRESOLV_H__\n\n#include \n#include \"curl/curl.h\"\n\nusing std::string;\n\n/*\n\nThis class resolves against a server to lookup addresses.\nTo not conflict with the bitcoin addresses, we refer here to people's handles.\nA handle is of the form:\n\n   genjix@foo.org\n\nMost characters are valid for the username + password (and handled accordingly), but the domain follows usual web standards. It is possible to affix a path if needed,\n\n   genjix@bar.com/path/to/\n\n*/\n\nclass NameResolutionService\n{\npublic:\n    NameResolutionService();\n    ~NameResolutionService();\n\n    // Three main methods map to RPC actions.\n    string FetchAddress(const string& strHandle, string& strAddy);\n\nprivate:\n    // A POST block\n    class PostVariables\n    {\n    public:\n        PostVariables();\n        ~PostVariables();\n        // Add a new key, value pair\n        bool Add(const string& strKey, const string& strVal);\n        curl_httppost* operator()() const;\n    private:\n        // CURL stores POST blocks as linked lists.\n        curl_httppost *pBegin, *pEnd;\n    };\n\n    // Explodes user@domain => user, domain\n    static void ExplodeHandle(const string& strHandle, string& strNickname, string& strDomain);\n    // Perform the HTTP request. Returns true on success.\n    bool Perform();\n\n    // CURL error message\n    char pErrorBuffer[CURL_ERROR_SIZE];\n    // CURL response\n    string strBuffer;\n    // CURL handle\n    CURL *curl;\n};\n\n#endif\n
\n\n
\n// resolv.cpp\n#include \"resolv.h\"\n\n#include \n\n#include \"access.h\"\n\n// callback used to write response from the server\nstatic int writer(char *pData, size_t nSize, size_t nNmemb, std::string *pBuffer)\n{\n  int nResult = 0;\n  if (pBuffer != NULL)\n  {\n    pBuffer->append(pData, nSize * nNmemb);\n    // How much did we write?\n    nResult = nSize * nNmemb;\n  }\n  return nResult;\n}\n\nNameResolutionService::NameResolutionService()\n{\n    // Initialise CURL with our various options.\n    curl = curl_easy_init();\n    // This goes first in case of any problems below. We get an error message.\n    curl_easy_setopt(curl, CURLOPT_ERRORBUFFER, pErrorBuffer);\n    // fail when server sends >= 404\n    curl_easy_setopt(curl, CURLOPT_FAILONERROR, 1);\n    curl_easy_setopt(curl, CURLOPT_HEADER, 0);\n    curl_easy_setopt(curl, CURLOPT_FOLLOWLOCATION, 1);\n    curl_easy_setopt(curl, CURLOPT_POSTREDIR, CURL_REDIR_POST_302);\n    curl_easy_setopt(curl, CURLOPT_WRITEFUNCTION, writer);\n    curl_easy_setopt(curl, CURLOPT_USE_SSL, CURLUSESSL_TRY);\n    curl_easy_setopt(curl, CURLOPT_SSL_VERIFYPEER, 1);\n    // server response goes in strBuffer\n    curl_easy_setopt(curl, CURLOPT_WRITEDATA, &strBuffer);\n    pErrorBuffer[0] = '\\0';\n}\nNameResolutionService::~NameResolutionService()\n{\n    curl_easy_cleanup(curl);\n}\n\nvoid NameResolutionService::ExplodeHandle(const string& strHandle, string& strNickname, string& strDomain)\n{\n    // split address at @ furthest to the right\n    size_t nPosAtsym = strHandle.rfind('@');\n    strNickname = strHandle.substr(0, nPosAtsym);\n    strDomain = strHandle.substr(nPosAtsym + 1, strHandle.size());\n}\nbool NameResolutionService::Perform()\n{\n    // Called after everything has been setup. This actually does the request.\n    CURLcode result = curl_easy_perform(curl);\n    return (result == CURLE_OK);\n}\n\nstring NameResolutionService::FetchAddress(const string& strHandle, string& strAddy)\n{\n    // GET is defined for 'getting' data, so we use GET for the low risk fetching of people's addresses\n    if (!curl)\n        // For some reason CURL didn't start...\n        return pErrorBuffer;\n    // Expand the handle\n    string strNickname, strDomain;\n    ExplodeHandle(strHandle, strNickname, strDomain);\n    // url encode the nickname for get request\n    const char* pszEncodedNick = curl_easy_escape(curl, strNickname.c_str(), strNickname.size());\n    if (!pszEncodedNick)\n        return \"Unable to encode nickname.\";\n    // construct url for GET request\n    string strRequestUrl = strDomain + \"/bitcoin-alias/?handle=\" + pszEncodedNick;\n    // Pass URL to CURL\n    curl_easy_setopt(curl, CURLOPT_URL, strRequestUrl.c_str());\n    if (!Perform())\n        return pErrorBuffer;\n    // Server should respond with a JSON that has the address in.\n    strAddy = strBuffer;\n    return \"\";  // no error\n}\n\nNameResolutionService::PostVariables::PostVariables()\n{\n    // pBegin/pEnd *must* be null before calling curl_formadd\n    pBegin = NULL;\n    pEnd = NULL;\n}\nNameResolutionService::PostVariables::~PostVariables()\n{\n    curl_formfree(pBegin);\n}\nbool NameResolutionService::PostVariables::Add(const string& strKey, const string& strVal)\n{\n    // Copy strings to this block. Return true on success.\n    return curl_formadd(&pBegin, &pEnd, CURLFORM_COPYNAME, strKey.c_str(), CURLFORM_COPYCONTENTS, strVal.c_str(), CURLFORM_END) == CURL_FORMADD_OK;\n}\n\ncurl_httppost* NameResolutionService::PostVariables::operator()() const\n{\n    return pBegin;\n}\n\n\n\n// rpc.cpp\n...\n\nconst Object CheckMaybeThrow(const string& strJsonIn)\n{\n    // Parse input JSON\n    Value valRequest;\n    if (!read_string(strJsonIn, valRequest) || valRequest.type() != obj_type)\n        throw JSONRPCError(-32700, \"Parse error\");\n    const Object& request = valRequest.get_obj();\n    // Now check for a key called \"error\"\n    const Value& error  = find_value(request, \"error\");\n    // It's an error JSON! so propagate the error.\n    if (error.type() != null_type)\n        throw JSONRPCError(-4, error.get_str());\n    // Return JSON object\n    return request;\n}\n\nconst string CollectAddress(const string& strIn)\n{\n    // If the handle does not have an @ in it, then it's a normal base58 bitcoin address\n    if (strIn.find('@') == (size_t)-1)\n        return strIn;\n\n    // Open the lookup service\n    NameResolutionService ns;\n    // We established that the input string is not a BTC address, so we use it as a handle now.\n    string strHandle = strIn, strAddy;\n    string strError = ns.FetchAddress(strHandle, strAddy);\n    if (!strError.empty())\n        throw JSONRPCError(-4, strError);\n\n    const Object& request(CheckMaybeThrow(strAddy));\n    // Get the BTC address from the JSON\n    const Value& address = find_value(request, \"address\");\n    if (address.type() != str_type)\n        throw JSONRPCError(-32600, \"Server responded with malformed reply.\");\n    return address.get_str();\n}\n\n// Named this way to prevent possible conflicts.\nValue rpc_send(const Array& params, bool fHelp)\n{\n    if (fHelp || params.size() != 2)\n        throw runtime_error(\n            \"send  \\n\"\n            \" is a real and is rounded to the nearest 0.01\");\n\n    // Intelligent function which looks up address given handle, or returns address\n    string strAddy = CollectAddress(params[0].get_str());\n    int64 nAmount = AmountFromValue(params[1]);\n    // Do the send\n    CWalletTx wtx;\n    string strError = SendMoneyToBitcoinAddress(strAddy, nAmount, wtx);\n    if (!strError.empty())\n        throw JSONRPCError(-4, strError);\n    return wtx.GetHash().GetHex();\n}\n\n...\n
\n\n=== IP Transactions ===\n\nAn IP transaction is an old transaction format in bitcoin that is disabled and possibly could be deprecated. It involves being given an IP address to make payment to. Upon connecting to the node and requesting their public key using \"checkorder\", they will respond with a script in the form:\n\n OP_CHECKSIG\n\nSimilar to coinbase output transactions. IP transactions have the advantage of being able to contain additional metadata which can be useful in many transactions. Currently no authentication is done making the scheme insecure against man in the middle (MITM) attacks.\n\nThis proposal seeks to enable DNS lookups for IP transactions.\n\nThe \"checkorder\" message would contain a destination account, which could map to different isolated sets of keypairs/wallets running under the same host. The exact mapping from the checkorder reference info to the local system is implementation defined.\n\nBy using DNS lookups, the MITM problem with IP transactions could be mitigated by storing a public key in a DNS TXT record. This public key would be used for all future \"reply\" messages originating from that host. First time use would require a confirmation for acceptance of that public key; like with SSH. Should the \"reply\" message not match the accepted public key, then the host will be given an error.\n\n[[Category:BIP|E]]\n\n=== Namecoin ID ===\n\nThis proposal uses the Namecoin blockchain to associate an alias with a bitcoin address. Bitcoin queries a namecoin node. This retrieves the structured data containing the bitcoin address(es) associated with this alias.\n\nUsing a decentralised domain name system like Namecoin, means no external server or entity needs to be trusted unlike the other proposals listed here. This indicates a system with the advantage of having a high availability and ease of entry (no restrictions for users to create aliases).\n\nTwo examples are presented below. The first shows a simpler format, while the second shows several Bitcoin addresses in a structured format.\n\n $ namecoind name_show id/khal\n {\n \"bitcoin\" : \"1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T\"\n }\n\n $ namecoind name_show id/khal\n {\n \"bitcoin\" :\n {\n \"default\" : \"1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T\",\n \"donation\": \"1J3EKMfboca3SESWGrQKESsG1MA9yK6vN4\"\n }\n }\n\n'''More possibilities :'''\n\n* Allow to securely use '''unsecured channels'''\nYou can put an url and a bitcoin address that will be used to sign the result. It means that a query to this url will return a bitcoin address and a signature. Bitcoin can then check (with the verify_message function) that the returned address has not been replaced by another one.\n $ namecoind name_show id/khal\n {\n \"bitcoin\" :\n {\n \"url\" : \"http://merchant.com/bitcoin/getnewaddres/\",\n \"signedWith\" : \"1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T\"\n }\n }\n\n* Allow to get a different address each time, or per user, per order, etc\n $ namecoind name_show id/khal\n {\n \"bitcoin\" :\n {\n \"url\" : \"http://merchant.com/bitcoin/getaddres/{Your customer id}\",\n \"signedWith\" : \"1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T\",\n \"useOnce\": false\n }\n }\nIn the above example, bitcoin will ask the user for \"Your customer id\" and replace that value in the url before making the http request. The merchant will receive the request and give the user a payment address associated with that customer.\n\nAny text can be put into the brackets, allowing merchants to adapt it to all their needs.\n\n\n* Specification is extensible\n\nNew features can be added later to support uncovered cases.\n\n\nSee the specification of [http://dot-bit.org/Namespace:Identity Namecoin ID] for more information.", "category": "bips" }, { "instruction": "How would you explain 
 to someone who knows Bitcoin basics?",
    "input": "",
    "output": "BIP: 50\n  Title: March 2013 Chain Fork Post-Mortem\n  Authors: Gavin Andresen \n  Status: Deployed\n  Type: Informational\n  Assigned: 2013-03-20\n  License: PD\n
\n\n==What went wrong==\nA block that had a larger number of total transaction inputs than previously seen was mined and broadcasted. Bitcoin 0.8 nodes were able to handle this, but some pre-0.8 Bitcoin nodes rejected it, causing an unexpected fork of the blockchain. The pre-0.8-incompatible chain (from here on, the 0.8 chain) at that point had around 60% of the mining hash power ensuring the split did not automatically resolve (as would have occurred if the pre-0.8 chain outpaced the 0.8 chain in total work, forcing 0.8 nodes to reorganise to the pre-0.8 chain).\n\nIn order to restore a canonical chain as soon as possible, BTCGuild and Slush downgraded their Bitcoin 0.8 nodes to 0.7 so their pools would also reject the larger block. This placed majority hashpower on the chain without the larger block, thus eventually causing the 0.8 nodes to reorganise to the pre-0.8 chain.\n\nDuring this time there was at least [https://bitcointalk.org/index.php?topic=152348.0 one large double spend]. However, it was done by someone experimenting to see if it was possible and was not intended to be malicious.\n\n==What went right==\n* The split was detected very quickly.\n* The right people were online and available in IRC or could be contacted directly.\n* Marek Palatinus (Slush) and Michael Marsee (Eleuthria of BTCGuild) quickly downgraded their nodes to restore a pre-0.8 chain as canonical, despite the fact that this caused them to sacrifice significant amounts of money.\n* Deposits to the major exchanges and payments via BitPay were also suspended (and then un-suspended) very quickly.\n* Fortunately, the only attack on a merchant was done by someone who was not intending to actually steal money.\n\n==Root cause==\nBitcoin versions prior to 0.8 configure an insufficient number of Berkeley DB locks to process large but otherwise valid blocks. Berkeley DB locks have to be manually configured by API users depending on anticipated load. The manual says this:\n\n:The recommended algorithm for selecting the maximum number of locks, lockers, and lock objects is to run the application under stressful conditions and then review the lock system's statistics to determine the maximum number of locks, lockers, and lock objects that were used. Then, double these values for safety.\n\nWith the insufficiently high BDB lock configuration, it implicitly had become a network consensus rule determining block validity (albeit an inconsistent and unsafe rule, since the lock usage could vary from node to node).\n\nBecause max-sized blocks had been successfully processed on the testnet, it did not occur to anyone that there could be blocks that were smaller but require more locks than were available. Prior to 0.7 unmodified mining nodes self-imposed a maximum block size of 500,000 bytes, which further prevented this case from being triggered. 0.7 made the target size configurable and miners had been encouraged to increase this target in the week prior to the incident.\n\nBitcoin 0.8 did not use Berkeley DB. It switched to LevelDB instead, which did not implement the same locking limits as BDB. Therefore it was able to process the forking block successfully.\n\nNote that BDB locks are also required during processing of re-organizations. Versions prior to 0.8 may be unable to process some valid re-orgs.\n\nThis would be an issue even if the entire network was running version 0.7.2. It is theoretically possible for one 0.7.2 node to create a block that others are unable to validate, or for 0.7.2 nodes to create block re-orgs that peers cannot validate, because the contents of each node's blkindex.dat database is not identical, and the number of locks required depends on the exact arrangement of the blkindex.dat on disk (locks are acquired per-page).\n\n==Action items==\n\n===Immediately===\n\n'''Done''': Release a version 0.8.1, forked directly from 0.8.0, that, for the next two months has the following new rules:", "category": "bips" }, { "instruction": "I'm trying to understand Bitcoin Operations Guide - can you walk me through it?", "input": "", "output": "# Release a patch for older versions that implements the same rules, but also increases the maximum number of locks to 537,000", "category": "bips" }, { "instruction": "Hey, I need to set up Bitcoin Operations Guide - what's the command line way to do that?", "input": "", "output": "# Create a web page on bitcoin.org that will urge users to upgrade to 0.8.1, but will tell them how to set DB_CONFIG to 537,000 locks if they absolutely cannot.", "category": "bips" }, { "instruction": "What's the deal with Over the next 2 months, send a series of alerts to users of older versions, pointing to the web page. in Bitcoin? Explain it like I'm a friend.", "input": "", "output": "===Alert system===\n\n'''Done''': Review who has access to the alert system keys, make sure they all have contact information for each other, and get good timezone overlap by people with access to the keys.\n\n'''Done''': Implement a new bitcoind feature so services can get timely notification of alerts: -alertnotify= Run command when an AppliesToMe() alert is received.\n\n'''Done''': Pre-generate 52 test alerts, and set a time every week when they are broadcast on -testnet (so -alertnotify scripts can be tested in as-close-to-real-world conditions as possible).\n\nIdea from Michael Gronager: encourage merchants/exchanges (and maybe pools) to run new code behind a bitcoind running the network-majority version.\n\n===Safe mode===\n\n'''Done''': Perhaps trigger an alert if there is a long enough side chain detected, even if it is not the main chain. Pools could use this to automatically suspend payouts if a long side-chain suddenly appeared out of nowhere (it’s hard for an attacker to mine such a thing).\n\n===Testing===\n\nStart running bots on the testnet that grab some coins from a testnet faucet, generate large numbers of random transactions that split/recombine them and then send them back to the faucet. Randomized online testing on the testnet might have revealed the pathological block type earlier.\n\n===Double spending===\n\nA double spend attack was successful, despite that both sides of the chain heard about the transactions in the same order. The reason is most likely that the memory pools were cleared when the mining pool nodes were downgraded. A solution is for nodes to sync their mempools to each other at startup, however, this requires a memory pool expiry policy to be implemented as currently node restarts are the only way for unconfirmed transactions to be evicted from the system.\n\n===Resolution===\n\nOn 16 August, 2013 block 252,451 (0x0000000000000024b58eeb1134432f00497a6a860412996e7a260f47126eed07) was accepted by the main network, forking unpatched nodes off the network.\n\n==Copyright==\n\nThis document is placed in the public domain.", "category": "bips" }, { "instruction": "Can you show me the CLI commands for 
?",
    "input": "",
    "output": "BIP: 131\n  Layer: Consensus (hard fork)\n  Title: \"Coalescing Transaction\" Specification (wildcard inputs)\n  Authors: Chris Priest \n  Status: Closed\n  Type: Specification\n  Assigned: 2015-11-30\n  License: PD\n
\n\n==Abstract==\n\nThis specification defines a new type of transaction that supplements (not replaces)\nnormal \"non coalescing\" bitcoin transactions.\n\n==Motivation==\n\nNormal \"non-coalescing\" Bitcoin Transactions have one large inefficiency: When you want to spend\nfrom multiple inputs with the exact same scriptPubKey, you have to list each\ninput separately, along with the same signature multiple times, even though the signature expresses the same information.\nThis bloats the transaction size and makes it expensive to spend from small value inputs.\n\nBecause small value inputs are expensive to send, they remain in the UTXO pool\nwhich full nodes have to keep around. It is believed that long term increase of the UTXO\nset can have negative scaling consequences on the network.\n\nIf maximum blocksize is made to increase *slower* than the actual number of transactions bitcoin users are sending\nto the network, this problem is projected to get worse. In other words, as transaction\nfees increase, the minimum economical value of a spending a UTXO will increase.\n\n==Specification==\n\n=== Redefinition of Transaction version ===\n\nFirst, this BIP redefines the version field on transactions. The first four bytes\nare defined as the version number, while the last four bytes are defined as the\ntransaction type. Type \"0000\" denotes normal transactions, and \"0001\" defines\ncoalescing transaction.\n\nExamples:\n\nversion 1 transaction with normal inputs:\n version: 10000000\n\nversion 2 transaction with normal inputs:\n version: 20000000\n\nversion 2 transaction with coalescing inputs:\n version: 20000001\n\nEssentially the last bit in the version field is set to 1 to enable wildcard inputs for all\ninputs present in the transaction.\n\n=== Wildcard inputs ===\n\nA coalescing transaction is formulated the exact same way as a version 1 transaction\nwith one exception: each input is treated as a \"wildcard input\".\n\nA wildcard input being the value of all inputs with the exact same scriptPubKey\nin a block lower or equal to the block the wildcard input is confirmed into.\n\n== Changes needed to implement ==\n\nThe bitcoin code needs to be modified in three places in order to handle Coalescing Transactions.\n\n1. Full Node Coalescing validation - When a full node receives a coalescing transaction, it has to\naggregate the value of all the UTXOs in the blockchain older than the input\nwith the same scriptPubKey. If this value is greater than or equal to the\namount of all outputs, then that coalescing transaction is valid and can be propagated.\n\n2. Full Node Non-Coalescing validation - When a non-coalescing transaction comes in, the code needs to be modified\nto check if each input has not been spent by a coalescing transaction. If there exist any\ncoalescing transaction in the blockchain with the same scriptPubKey found in a block *after* that input,\nthen the UTXO has been spent and the transaction is invalid.\n\n3. Wallet - The user facing wallet portion of the reference client should notify\nthe user when their wallet contains many UTXOs that qualify it to benefit from\na coalescing transaction. Wallets should not simply replace non-coalescing transactions\nwith coalescing transactions in all instances.\n\n== Isn't this BIP bad because it encourage address re-use? ==\n\nAddress re-use comes in two forms: re-use by the ''sender'', and re-use by the ''receiver''.\n\nRe-use by the sender is basically using the same address for the change output. This is generally considered bad\nsince people looking through your transaction history can determine who you do business with. When\nyou generate a new address for every change, your privacy is conserved as it is impossible to know which\noutput is a recipient, and which output is the change output. This BIP has '''no effect''' on re-use\nby the sender.\n\nOn the other hand, address re-use by the ''receiver'' occurs under completely different circumstances.\nWhen you publish an address and have multiple people send to that address, you are engaging in address re-use\nfrom the receiver. This activity has historically been considered bad because it leads to re-using a private key.\nWhen you re-use a private key too many times, you run the risk of an attacker performing statistical analysis\non the multiple signatures, which can lead to an attacker finding out your private key.\n\nThis BIP introduces a way to spend multiple inputs ''without'' re-using the private key. In a sense, this BIP\nfixes the problem that makes address re-use bad for the receiver. After this BIP becomes implemented\nand deployed, address re-use by the receiver will no longer be considered bad form.\n\n==Copyright==\n\nThis document is placed in the public domain.", "category": "bips" }, { "instruction": "I'm stuck with 
 - what should I check?",
    "input": "",
    "output": "BIP: 94\n  Layer: Applications\n  Title: Testnet 4\n  Authors: Fabian Jahr \n  Status: Deployed\n  Type: Specification\n  Assigned: 2024-05-27\n  License: CC0-1.0\n  Discussion: https://gnusha.org/pi/bitcoindev/CADL_X_eXjbRFROuJU0b336vPVy5Q2RJvhcx64NSNPH-3fDCUfw@mail.gmail.com/\n              https://gnusha.org/pi/bitcoindev/a6e3VPsXJf9p3gt_FmNF_Up-wrFuNMKTN30-xCSDHBKXzXnSpVflIZIj2NQ8Wos4PhQCzI2mWEMvIms_FAEs7rQdL15MpC_Phmu_fnR9iTg=@protonmail.com/\n              https://github.com/bitcoin/bitcoin/pull/29775\n
\n\n== Abstract ==\n\nA new test network with the goal to replace Testnet 3. This network comes with small but important improvements of the consensus rules, that should make it impractical to attack the network using only CPU mining.\n\n== Motivation ==\n\nQuoting the original mailing list post from Jameson Lopphttps://gnusha.org/pi/bitcoindev/CADL_X_eXjbRFROuJU0b336vPVy5Q2RJvhcx64NSNPH-3fDCUfw@mail.gmail.com/:\n\n
\nTestnet3 has been running for 13 years. It's on block 2.5 million something and the block reward is down to ~0.014 TBTC, so mining is not doing a great job at distributing testnet coins anymore.\n\nThe reason the block height is insanely high is due to a rather amusing edge case bug that causes the difficulty to regularly get reset to 1, which causes a bit of havoc. If you want a deep dive into the quirk: https://blog.lopp.net/the-block-storms-of-bitcoins-testnet/\n\nTestnet3 is being actively used for scammy airdrops; those of us who tend to be generous with our testnet coins are getting hounded by non-developers chasing cheap gains.\n\nAs a result, TBTC is being actively bought and sold; one could argue that the fundamental principle of testnet coins having no value has been broken.\n
\n\nSince then the issue with block storms has been further demonstrated on Testnet 3 when three years' worth of blocks were mined in a few weeks while rendering the network practically unusable at the same time.\n\n== Specification ==\n\nTestnet 4 follows the same consensus rules as mainnet with the following three exceptions. Additionally, all soft forks that are active on mainnet as of May 2024 are enforced from genesis.\n\n=== 1. 20-minute Exception Rule ===\n\nThis rule was implemented in Testnet 3https://github.com/bitcoin/bitcoin/pull/686 and is preserved in Testnet 4.\n\n==== Rule Specification ====\n\n1. For any block except the first block in a difficulty period:\n a. If the block's timestamp is >20 minutes past the timestamp of the previous block\n b. Then the block MUST use the minimum difficulty value (nBits = 0x1d00ffff), regardless of the network's actual difficulty\n\n2. The first block of each difficulty period MUST use the actual network difficulty.\n\nThis rule enables CPU mining on testnet but has led to block stormshttps://blog.lopp.net/the-block-storms-of-bitcoins-testnet/ which rule #2 below addresses.\n\n=== 2. Block Storm Fix ===\n\nThis is a new rule to address block storms caused by the 20-minute exception.\n\n==== Problem Statement ====\n\nIn Mainnet and Testnet 3, the difficulty adjustment calculation uses the difficulty value of the last block in the previous period as its base. When the 20-minute exception is applied to this last block, it is mined at difficulty 1, causing the next period's difficulty to be constrained between 1-4, leading to block storms.\n\n==== Rule Specification ====\n\n1. For difficulty adjustment calculations between periods:\n a. The base difficulty value MUST be taken from the first block of the previous difficulty period\n b. NOT from the last block as in previous implementations\n\n2. The adjustment factor calculation remains unchanged:\n a. Multiplication factor based on the duration of the previous difficulty period\n b. Limited to no less than 1/4 and no more than 4x\n\nThis change ensures that the actual network difficulty is used for adjustment calculations rather than potentially manipulated values from the last block in a period.\n\n=== 3. Time Warp Attack Prevention ===\n\nThis rule prevents time warp attacks that could otherwise be used to amplify block stormsA perpetual block storm attack with entire difficulty periods being authored in less than 3.5 days that resets the difficulty to the minimum in the last block of every difficulty period would adjust to a new actual difficulty of 4 every period. An attacker that additionally leverages a time warp attack would start their attack by holding back timestamps until the latest block's timestamp is at least two weeks in the past, and then limiting their block rate to six blocks per second, incrementing the timestamp on every sixth block. Only on the last block they would use the current time, which both resets the difficulty to one per the 20-minute exception and would result in a difficulty adjustment keeping the difficulty at the minimum due to the elapsed time exceeding the target. This would allow lower the difficulty for all blocks to difficulty 1 instead of difficulty 4.\n\n==== Rule Specification ====\n\n1. For any block whose height modulo 2016 equals 0 (i.e., the first block of each difficulty period):\n a. The block's nTime field MUST be greater than or equal to the nTime field of the immediately prior block minus 600 seconds\n\n2. These blocks MUST still comply with existing Median-Time-Past nTime restrictions\n\nThis rule is based on The Great Consensus Cleanup proposalhttps://github.com/TheBlueMatt/bips/blob/cleanup-softfork/bip-XXXX.mediawiki and prevents miners from manipulating timestamps to artificially lower difficulty.\n\n== Rationale ==\n\nThe applied changes were the result of discussions on the mailing list and the PR. The selected changes try to strike a balance between minimal changes to the network (keeping it as close to mainnet as possible) while making it more robust against attackers that try to disrupt the network. Several alternative designs were considered:\n\n* For the block storm fix an alternative fix could have been to prevent the last block in a difficulty period from applying the existing difficulty exception. Both solutions were deemed acceptable and there was no clear preference among reviewers.\n* Removal of the 20-minute exception was discussed but dismissed since several reviewers insisted that it was a useful feature allowing non-standard transactions to be mined with just a CPU. The 20-minute exception also allows CPU users to move the chain forward (except on the first block that needs to be mined at actual difficulty) in case a large amount of hash power suddenly leaves the network. This would allow the chain to recover to a normal difficulty level faster if left stranded at high difficulty.\n* Increase of minimum difficulty was discussed but dismissed as it would categorically prevent participation in the network using a CPU miner (utilizing the 20-minute exception).\n* Increase of the delay in the 20-minute exception was suggested but did not receive significant support.\n* Re-enabling acceptnonstdtxn in bitcoin core by default was dismissed as it had led to confusion among layer-2s that had used testnet for transaction propagation tests and expected it to behave similarly to mainnet.\n* Motivating miners to re-org min difficulty blocks was suggested, but was considered out of scope for this BIP, since adoption of such a mining policy remains available after Testnet 4 is deployed. As 20-minute exception blocks only contribute work corresponding to difficulty one to the chaintip, and actual difficulty blocks should have a difficulty magnitudes higher, a block mined at actual difficulty could easily replace even multiple 20-minute exception blocks.\n* Persisting the real difficulty in the version field was suggested to robustly prevent exploits of the 20-minute exception while allowing it to be used on any block, but did not receive a sufficient level of support to justify the more invasive change.\n\nOne known downside of the chosen approach is that if the difficulty is gradually raised by a miner with significant hash rate, and this miner disappears, then each difficulty adjustment period requires one block at the actual difficulty.\n\nThis would cause the network to stall once per difficulty adjustment period until the real difficulty is adjusted downwards enough for the remaining hash rate to find this block in reasonable time.\n\n== Network Parameters ==\n\n=== Consensus Rules ===\n\nAll consensus rules active on mainnet at the time of this proposal are enforced from block 1, the newest of these rules being the Taproot softfork.\n\n=== Genesis Block ===\n\n* Message: 03/May/2024 000000000000000000001ebd58c244970b3aa9d783bb001011fbe8ea8e98e00e\n* Pubkey: 000000000000000000000000000000000000000000000000000000000000000000\n* Time stamp: 1714777860\n* Nonce: 393743547\n* Difficulty: 0x1d00ffff\n* Version: 1\n\nThe resulting genesis block hash is 00000000da84f2bafbbc53dee25a72ae507ff4914b867c565be350b0da8bf043, and the block hex is 0100000000000000000000000000000000000000000000000000000000000000000000004e7b2b9128fe0291db0693af2ae418b767e657cd407e80cb1434221eaea7a07a046f3566ffff001dbb0c78170101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff5504ffff001d01044c4c30332f4d61792f323032342030303030303030303030303030303030303030303165626435386332343439373062336161396437383362623030313031316662653865613865393865303065ffffffff0100f2052a010000002321000000000000000000000000000000000000000000000000000000000000000000ac00000000.\n\n=== Message Start ===\n\nThe message start is defined as 0x1c163f28. These four bytes were randomly generated and have no special meaning.\n\n=== Network Parameters ===\n\nThe default p2p port for Testnet 4 is `48333`.\n\n== Backwards Compatibility ==\n\nThe rules used by Testnet 4 are backwards compatible to the rules of Testnet 3. Existing software that implements support for Testnet 3 would only require addition of the network parameters (magic number, genesis block, etc.) to be able to follow Testnet 4.\n\nHowever, implementations that only implement Testnet 3's rules would accept a chain that violates Testnet 4's rules and are therefore susceptible to being forked off. It is recommended that any implementations check blocks in regard to all the new rules of Testnet 4 and reject blocks that fail to comply.\n\n== Reference implementation ==\n\nPull request at https://github.com/bitcoin/bitcoin/pull/29775\n\n== References ==\n\n\n\n== Copyright ==\n\nThis document is licensed under the Creative Commons CC0 1.0 Universal license.", "category": "bips" }, { "instruction": "How do I troubleshoot 
 issues?",
    "input": "",
    "output": "BIP: 73\n  Layer: Applications\n  Title: Use \"Accept\" header for response type negotiation with Payment Request URLs\n  Authors: Stephen Pair \n  Status: Deployed\n  Type: Specification\n  Assigned: 2013-08-27\n
\n\n==Abstract==\n\nThis BIP describes an enhancement to the payment protocol ([[bip-0070.mediawiki|BIP 70]])\nthat addresses the need for short URLs when scanning from QR codes. It\ngeneralizes the specification for the behavior of a payment request URL in a\nway that allows the client and server to negotiate the content of the\nresponse using the HTTP Accept: header field. Specifically, the client\ncan indicate to the server whether it prefers to receive a bitcoin URI or\na payment request.\n\nImplementation of this BIP does not require full payment request ([[bip-0070.mediawiki|BIP 70]]) support.\n\n==Motivation==\n\nThe payment protocol augments the bitcoin: uri scheme with an additional\n\"payment\" parameter that specifies a URL where a payment request can be\ndownloaded. This creates long URIs that, when rendered as a QR code, have\na high information density. Dense QR codes can be difficult to scan resulting\nin a more frustrating user experience. The goal is to create a standard that\nwould allow QR scanning wallets to use less dense QR codes. It also makes\ngeneral purpose QR code scanners more usable with bitcoin accepting\nwebsites.\n\n==Specification==\n\nQR scanning wallets will consider a non bitcoin URI scanned from a QR code to\nbe an end point where either a bitcoin URI or a payment request can be obtained.\n\nA wallet client uses the Accept: HTTP header to specify whether it can accept\na payment request, a URI, or both. A media type of text/uri-list specifies that\nthe client accepts a bitcoin URI. A media type of application/bitcoin-paymentrequest\nspecifies that the client can process a payment request. In the absence of an\nAccept: header, the server is expected to respond with text/html suitable for\nrendering in a browser. An HTML response will ensure that QR codes scanned\nby non Bitcoin wallet QR scanners are useful (they could render an HTML page\nwith a payment link that when clicked would open a wallet on the device).\n\nIt is not required that the client and server support the full semantics of an\nHTTP Accept header. If application/bitcoin-paymentrequest is specified in the\nheader, the server should send a payment request regardless of anything else\nspecified in the Accept header. If text/uri-list is specified (but not\napplication/bitcoin-paymentrequest), a valid Bitcoin URI should be returned. If\nneither is specified, the server can return an HTML page. When a uri-list is returned\nonly the first item in the list is used (and expected to be a bitcoin URI), any additional\nURIs should be ignored.\n\n==Compatibility==\n\nOnly QR scanning wallets that implement this BIP will be able to process QR\ncodes containing payment request URLs. There are two possible workarounds for QR\nscanning wallets that do not implement this BIP: 1) the server gives the user an\noption to change the QR code to a bitcoin: URI or 2) the user scans the code with\na generic QR code scanner.\n\nIn the second scenario, if the server responds with a webpage containing a link\nto a bitcoin URI, the user can complete the payment by clicking that link provided\nthe user has a wallet installed on their device and it supports bitcoin URIs. If the\nwallet/device does not have support for bitcoin URIs, the user can fall back on\naddress copy/paste.\n\nThis BIP should be fully compatible with BIP 70 assuming it is required that wallets\nimplementing BIP 70 make use of the Accept: HTTP header when retrieving a\npayment request.\n\n==Examples==\nThe first image below is of a bitcoin URI with an amount and payment request\nspecified (note, this is a fairly minimal URI as it does not contain a\nlabel and the request URL is of moderate size). The second image is a QR\ncode with only the payment request url specified.\n\n", "category": "bips" }, { "instruction": "What are the best practices for 
?",
    "input": "",
    "output": "BIP: 33\n  Layer: Peer Services\n  Title: Stratized Nodes\n  Authors: Amir Taaki \n  Status: Closed\n  Type: Specification\n  Assigned: 2012-05-15\n
\n\n== Abstract ==\n\nAs the Bitcoin network scales, roles are fast becoming specialised. In the beginning, a single Bitcoin user would perform the synonymous roles of miner, merchant and end-user. With the growth however of this system, these functions are being abstracted away to specialised services as a natural part of Bitcoin's growth.\n\nBitcoin's blockchain becomes more unwieldy for end users over time, negatively affecting the usability of Bitcoin clients. As it grows, it becomes ever more impractical to deal with on portable devices or low end machines. Several proposals have been put forward to deal with this such as lightweight (headers-only) clients and skipping validation for blocks before the last checkpoint. However these measures are at best stop-gap workarounds to stave off a growing problem.\n\nThis document will examine a proposal which will be termed ''stratized nodes'', a modification of an earlier concept termed ''blockchain service''.\n\n== History ==\n\nJan Moller created BCCAPI in 2011. BCCAPI allowed a user's client to delegate blockchain interaction to a remote server. This server would store and manage the blockchain while the user client would run queries against that server.\n\nThomasV later created Electrum server. BCCAPI's server backend was proprietary, and Electrum required a full Free Software stack. Electrum's server was an adhoc temporary replacement. As it grew and became used, issues started to appear in its design.\n\nMarek Palatinus (slush) drafted a new standard called Stratum to replace Electrum's server. Stratum has multiple transports and is usable as a blockchain server by merchants, miners and user-clients. Electrum moved to using a Stratum implementation first relying on ABE/bitcoind and more recently libbitcoin.\n\nStratum is unmaintained by Marek Palatinus, suffers from easy resource starvation and denial of service attacks, and is insecure. The proposal specified here is intended to replace the Stratum's role as a blockchain for user-clients. The proposal here is solely concerned with removing the onus of blockchain validation and lookups from user-clients to specialised services in a secure manner. Any secondary benefits or uses are purely incidental.\n\n== Overview ==\n\nDuring the initial handshake between Bitcoin nodes, a version packet is sent. version packets have a bitfield called services. Nodes can fill this field to tell the network how they behave and which services they support. NODE_NETWORK (1) means a node can be asked for full blocks for example.\n\nWe propose two more values of NODE_SERVICE (2) and NODE_STRATIZED (4).\n\n=== NODE_SERVICE ===\n\n* A blockchain service which supports the additional messages \"getoutputs\" and \"getspends\".\n* Does not respond to \"getdata\" messages by itself (unless NODE_NETWORK is specified)\n* If NODE_NETWORK is specified, then \"getdata\" for transactions will retrieve them not only from the memory pool but also check the blockchain if necessary.\n\n=== NODE_STRATIZED ===\n\n* A node which uses the stratized strategy specified in this document.\n* NODE_STRATIZED will relay inventories for accepted transactions.\n* Does not support \"getblocks\" as stratized nodes do not contain the entire blockchain.\n\nApart from the differences noted above, the nodes are otherwise unchanged in their behaviour from NODE_NETWORK.\n\n== Specification ==\n\n=== Initialisation ===\n\nFour new messages are defined which are represented below in C-like pseudocode.\n\n\"getoutputs\"\n
\nstruct decoded_address\n{\n    uint8_t payment_type;\n    uint8_t address_hash[16];\n};\n\nstruct get_outputs\n{\n    decoded_address dest;\n};\n
\n\n\"outputs\"\n
\nstruct point_t\n{\n    uint8_t hash[32];\n    uint32_t index;\n};\n\nstruct outputs\n{\n    decoded_address dest;\n    uint64_t number_outputs;  // variable uint\n    point_t outpoints[];\n};\n
\n\n\"getspend\"\n
\nstruct get_spend\n{\n    point_t outpoint;\n};\n
\n\n\"spend\"\n
\nstruct spend\n{\n    point_t outpoint, inpoint;\n};\n
\n\nThese four messages allow a node to discover the history of a Bitcoin address without needing direct access to the blockchain.\n\nA typical use case might look like:", "category": "bips" }, { "instruction": "Walk me through setting up Receive \"outputs\", and loop through each contained output point: step by step", "input": "", "output": "## Send \"getdata\" to download the transaction for that point.\n## Send \"getspend\" for each output point.", "category": "bips" }, { "instruction": "What commands would you run to work with Receive \"spend\":?", "input": "", "output": "## Send \"getdata\" to download the transaction for that input point.\n\nThis sequence allows the gradual but fast build up of history for an address.\n\n=== Updates ===\n\nNodes receive \"inv\" messages as normal from service nodes, issuing \"getdata\" to download the block or transaction data. From this they check for newly sent (in the input points) or received (in the output points) payments in the transaction data.\n\nNote that blocks must at minimum have their merkle root validated and transactions must be checked for uniqueness by stratized nodes.\n\n== Security ==\n\nThe concern here is that stratized nodes are at the mercy of blockchain services. This proposal deals with that issue by designing this protocol in such a way that the implementation can resolve the common history between multiple services.\n\nA stratized node will typically connect to 8 blockchain services. It will only accept an output, spend or inventory vector that has been sent by a common subset of all those services (6 in our example). This spreads the risk between all services, and does not make a node vulnerable to any one rogue blockchain service.\n\n== Privacy ==\n\nThe other strategy for thin clients termed ''headers-only'' or ''Simplified. Payment. Verification.'' have the same privacy issues as this proposal. SPV resolves this problem by sending out fake requests for transaction data which obfuscates the client data. By sending out a sufficient number of fake requests, privacy can be kept to a sufficient level.\n\n== Rationale ==\n\nNODE_SERVICE does not respond to \"getdata\" requests by itself (unless used in conjunction with NODE_NETWORK) to prevent starvation attacks. This allows a single trusted NODE_SERVICE architecture (possibly acting as a front-end to multiple backends) to service very many nodes while externalising the costs to the Bitcoin network.\n\nNODE_STRATIZED tries its best to maintain the facade and help upkeep the Bitcoin network (see relaying), but cannot support \"getblocks\" as it does not have the entire blockchain.\n\n== Backwards Compatibility ==\n\nThis proposal is an addon to the current Bitcoin network, and is completely backwards compatible.", "category": "bips" }, { "instruction": "I want to understand 
 from a technical perspective",
    "input": "",
    "output": "BIP: 20\n  Layer: Applications\n  Title: URI Scheme\n  Authors: Luke Dashjr \n  Status: Closed\n  Type: Specification\n  Assigned: 2011-01-10\n  License: BSD-2-Clause\n  Proposed-Replacement: 21\n
\n\nBIP 0020 is based off an earlier document by Nils Schneider. '''And has been replaced by BIP 0021'''\n\n==Abstract==\nThis BIP proposes a URI scheme for making Bitcoin payments.\n\n==Copyright==\nThis BIP is licensed under the BSD 2-clause license.\n\n==Motivation==\nThe purpose of this URI scheme is to enable users to easily make payments by simply clicking links on webpages or scanning QR Codes.\n\n==Specification==\n\n=== General rules for handling (important!) ===\n\nBitcoin clients MUST NOT act on URIs without getting the user's authorization.\nThey SHOULD require the user to manually approve each payment individually, though in some cases they MAY allow the user to automatically make this decision.\n\n=== Operating system integration ===\nGraphical bitcoin clients SHOULD register themselves as the handler for the \"bitcoin:\" URI scheme by default, if no other handler is already registered. If there is already a registered handler, they MAY prompt the user to change it once when they first run the client.\n\n=== BNF grammar ===\n\n(See also [[#simpler-syntax|a simpler representation of syntax]])\n\n bitcoinurn = \"bitcoin:\" bitcoinaddress [ \";version=\" bitcoinversion ] [ \"?\" bitcoinparams ]\n bitcoinaddress = base58 *base58\n bitcoinversion = \"1.0\"\n bitcoinparams = *bitcoinparam\n bitcoinparam = amountparam | labelparam | messageparam | sendparam | otherparam\n amountparam = \"amount=\" amount\n amount = amountdecimal | amounthex\n amountdecimal = *digit [ \".\" *digit ] [ \"X\" *digit ]\n amounthex = \"x\" *hexdigit [ \".\" *hexdigit ] [ \"X\" *hexdigit ]\n labelparam = \"label=\" *pchar\n messageparam = \"message=\" *pchar\n sendparam = \"send=\" *pchar\n otherparam = pchar *pchar \"=\" *pchar\n\n=== Query Keys ===\n\n*label: Label for that address (e.g. name of receiver)\n*address: bitcoin address\n*message: message that is shown to the user after scanning the QR code\n*size: amount of base bitcoin units ([[#transfer-amountsize|see below]])\n*send: used to send bitcoin, rather than to request them\n*(others): optional, for future extensions\n\n==== Transfer amount/size ====\n\nIf an amount is provided, it may be specified either in decimal or, when prefixed with a single \"x\" character, hexadecimal.\nThe number SHOULD be followed by \"X\" <digits> to signify an exponent to the base multiplier.\nThus, \"X8\" multiplies your number by 100,000,000.\nFor decimal values, this means the standard BTC unit.\nFor hexadecimal values, this means ᵇTBC units (which are equivalent to 42.94967296 BTC).\nIf exponent is omitted, implementations SHOULD assume X8 for decimal numbers, and X4 for hexadecimal numbers.\nI.e. amount=50.00 is treated as 50 BTC, and amount=x40 is treated as 40 TBC.\nWhen specifying bitcoin base units, \"X0\" SHOULD be used.\n\nBitcoin clients MAY display the amount in any format that is not intended to deceive the user.\nThey SHOULD choose a format that is foremost least confusing, and only after that most reasonable given the amount requested.\nFor example, so long as the majority of users work in BTC units, values should always be displayed in BTC by default, even if mBTC or TBC would otherwise be a more logical interpretation of the amount.\n\n== Rationale ==\n\n===Payment identifiers, not person identifiers===\nCurrent best practices are that a unique address should be used for every transaction.\nTherefore, a URI scheme should not represent an exchange of personal information, but a one-time payment.\n\n===Accessibility (URI scheme name)===\nShould someone from the outside happen to see such a URI, the URI scheme name already gives a description.\nA quick search should then do the rest to help them find the resources needed to make their payment.\nOther proposed names sound much more cryptic; the chance that someone googles that out of curiosity are much slimmer.\nAlso, very likely, what he will find are mostly technical specifications - not the best introduction to bitcoin.\n\n==Forward compatibility==\nWe want URIs generated in 2011 to still work in 2036: think about extensibility.\nOf course we can make only educated guesses about the future, but don't act as if there is none.\nThis should be the best we can do, but it should not be seen as set in stone.\nMake it possible for later generations to improve our work, to mend our errors, without breaking the URIs created now.\n\n== Appendix ==\n\n=== Simpler syntax ===\n\nThis section is non-normative and does not cover all possible syntax.\nPlease see the [[#bnf-grammar|BNF grammar]] above for the normative syntax.\n\n[foo] means optional, <bar> are placeholders\n\n
\n bitcoin:
[;version=1.0][?amount=][?label=
\n\n=== Examples ===\n\nJust the address:\n bitcoin:1NS17iag9jJgTHD1VXjvLCEnZuQ3rJED9L\n\nAddress with name:\n bitcoin:1NS17iag9jJgTHD1VXjvLCEnZuQ3rJED9L?label=Luke-Jr\n\nRequest 20.30 BTC to \"Luke-Jr\":\n bitcoin:1NS17iag9jJgTHD1VXjvLCEnZuQ3rJED9L?amount=20.3X8&label=Luke-Jr\n\nRequest 400 TBC:\n bitcoin:1NS17iag9jJgTHD1VXjvLCEnZuQ3rJED9L?amount=x400X4\n\nRequest 4000 TBC:\n bitcoin:1NS17iag9jJgTHD1VXjvLCEnZuQ3rJED9L?amount=x4X7\n\nRequest 5 uBTC:\n bitcoin:1NS17iag9jJgTHD1VXjvLCEnZuQ3rJED9L?amount=5X2\n\nRequest 50 BTC with message:\n bitcoin:1NS17iag9jJgTHD1VXjvLCEnZuQ3rJED9L?amount=50X8&label=Luke-Jr&message=Donation%20for%20project%20xyz\n\nSend 1 BTC:\n bitcoin:1NS17iag9jJgTHD1VXjvLCEnZuQ3rJED9L?amount=1X8&send=S4b3N3oGqDqR5jNuxEvDwf\n\nCharacters must be URI encoded properly.\n\n===Sending money via private key===\nTo send a payment to someone else first construct a new keypair. You may want to use a [[mini private key format]], or you may also use a full private key for more security depending on the amount being sent and how long you expect to pass before a claim. Now create and publish a transaction with an output of the amount you wish to send. Use this script in that output:\n\n
\n  OP_CHECKSIG\n
\n\nConstruct an address from the public key. Encode the URI as below:\n\n
\n bitcoin:
?send=\n
\n\nYou may optionally include amount or message fields as well. In a wallet to claim money sent this way search for an incoming transaction with the output script form above, where <address> matches the public key in the script. When you find the transaction create a claim transaction with an input script of this form:\n\n
\n \n
\n\nThis claims the money you were sent. Until your claim transaction has confirmed the sender may take their money back.\n\n== Reference Implementations ==\n=== Bitcoin clients ===\n* [[Spesmilo]] supports all valid Bitcoin URIs, with Windows and KDE integration\n\n=== Parsing amount ===\n==== ECMAScript ====\n
\n reAmount = /^(([\\d.]+)(X(\\d+))?|x([\\da-f]*)(\\.([\\da-f]*))?(X([\\da-f]+))?)$/i;\n function parseAmount(txt) {\n    var m = txt.match(reAmount);\n    return m[5] ? (\n        (\n            parseInt(m[5], 16) +\n            (m[7] ? (parseInt(m[7], 16) * Math.pow(16, -(m[7].length))) : 0)\n        ) * (\n            m[9] ? Math.pow(16, parseInt(m[9], 16)) : 0x10000\n        )\n    ) : (\n            m[2]\n        *\n            (m[4] ? Math.pow(10, m[4]) : 1e8)\n    );\n }\n
\n\n==== Python ====\n
\n m = re.match(r'^(([\\d.]+)(X(\\d+))?|x([\\da-f]*)(\\.([\\da-f]*))?(X([\\da-f]+))?)$', amount, re.IGNORECASE)\n if m.group(5):\n     amount = float(int(m.group(5), 16))\n     if m.group(7):\n         amount += float(int(m.group(7), 16)) * pow(16, -(len(m.group(7))))\n     if m.group(9):\n         amount *= pow(16, int(m.group(9), 16))\n     else:\n         amount *= 0x10000\n else:\n     amount = Decimal(m.group(2))\n     if m.group(4):\n         amount *= 10 ** int(m.group(4))\n     else:\n         amount *= 100000000\n
\n\n==== C# ====\n
\n Regex amountExpression = new Regex(@\"^(([\\d.]+)(X(\\d+))?|x([\\da-f]*)(\\.([\\da-f]*))?(X([\\da-f]+))?)$\", RegexOptions.IgnoreCase);\n Match match = amountExpression.Match(value);\n if (match.Success)\n {\n     if (match.Groups[5].Success)\n     {\n         long hexDecimal = 0;\n         if (match.Groups[7].Success)\n             hexDecimal = Convert.ToInt64(match.Groups[7].Value, 16) * (long)Math.Pow(16, -match.Groups[7].Length);\n\n         long hexExponent = 0x10000;\n         if (match.Groups[9].Success)\n             hexExponent = (long)Math.Pow(16, Convert.ToInt32(match.Groups[9].Value, 16));\n\n         Amount = (Convert.ToInt64(match.Groups[5].Value, 16) + hexDecimal) * hexExponent;\n     }\n     else\n     {\n         long decimalExponent = 100000000;\n         if (match.Groups[4].Success)\n             decimalExponent = (long)Math.Pow(10, int.Parse(match.Groups[4].Value));\n         Amount = (long)(decimal.Parse(match.Groups[2].Value) * decimalExponent);\n     }\n }\n
", "category": "bips" }, { "instruction": "Can you explain 
 like we're having a beer and talking Bitcoin?",
    "input": "",
    "output": "BIP: 80\n  Title: Hierarchy for Non-Colored Voting Pool Deterministic Multisig Wallets\n  Authors: Justus Ranvier \n           Jimmy Song \n  Status: Closed\n  Type: Informational\n  Assigned: 2014-08-11\n  License: PD\n
\n\n==Abstract==\n\nThis BIP defines a logical hierarchy for non-colored voting pool deterministic multisig wallets based on an algorithm described in BIP-0032 (BIP32 from now on) and purpose scheme described in BIP-0043 (BIP43 from now on).\n\nThis BIP is a particular application of BIP43 and is based on BIP44.\n\n==Motivation==\n\nThe hierarchy proposed in this paper allows the handling of multiple coins and multiple series from a single seed.\n\n==Path levels==\n\nWe define the following 4 levels in BIP32 path:\n\n
\nm / purpose' / coin_type' / series' / address_index\n
\n\nApostrophe in the path indicates that BIP32 hardened derivation is used.\n\nEach level has a special meaning, described in the chapters below.\n\n===Purpose===\n\nPurpose is a constant set following the BIP43 recommendation to: the ASCII value of \"80\" with the most significant bit set to indicate hardened derivation (0x80000050). It indicates that the subtree of this node is used according to this specification.\n\nHardened derivation is used at this level.\n\n===Coin type===\n\nOne master node (seed) can be used for unlimited number of independent cryptocoins such as Bitcoin, Litecoin or Namecoin. However, sharing the same space for various cryptocoins has some disadvantages.\n\nThis level creates a separate subtree for every cryptocoin, avoiding reusing addresses across cryptocoins and improving privacy issues.\n\nCoin type is a constant, set for each cryptocoin. The list of registered coin type constants should be obtained from BIP44.\n\nHardened derivation is used at this level.\n\n===Series===\n\nSeries are used by voting pools in order to implement FIFO cold storage. By directing deposits into multiple series, the private keys for most of the deposits can be kept offline, and a limited portion can be brought online to process withdrawals.\n\nHardened derivation is used at this level.\n\n===Index===\n\nPublic/private keypairs are numbered from index 0 in sequentially increasing manner. This number is used as child index in BIP32 derivation.\n\nPublic keys obtained at this level of the hierarchy are used to construct multisig deposit scripts, using a schema that is shared between the members as an out-of-band contract.\n\nPublic derivation is used at this level.\n\n==Compatible wallets==\n\n* [[https://github.com/btcsuite/btcwallet|btcwallet]] is the reference Bitcoin wallet for voting pools.\n\n==Copyright==\n\nThis document is placed in the public domain.\n\n==Reference==\n\n* [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]]\n* [[bip-0043.mediawiki|BIP43 - Purpose Field for Deterministic Wallets]]\n* [[bip-0044.mediawiki|BIP44 - Multi-Account Hierarchy for Deterministic Wallets]]", "category": "bips" }, { "instruction": "How would you explain 
 to someone who knows Bitcoin basics?",
    "input": "",
    "output": "BIP: 147\n  Layer: Consensus (soft fork)\n  Title: Dealing with dummy stack element malleability\n  Authors: Johnson Lau \n  Status: Deployed\n  Type: Specification\n  Assigned: 2016-09-02\n  License: PD\n
\n\n==Abstract==\n\nThis document specifies proposed changes to the Bitcoin transaction validity rules to fix a malleability vector in the extra stack element consumed by OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY.\n\n\n==Motivation==\n\nSignature malleability refers to the ability of any relay node on the network to transform the signature in transactions, with no access to the relevant private keys required. For non-segregated witness transactions, signature malleability will change the txid and invalidate any unconfirmed child transactions. Although the txid of segregated witness ([https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki BIP141]) transactions is not third party malleable, this malleability vector will change the wtxid and may reduce the efficiency of compact block relay ([https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki BIP152]).\n\nA design flaw in OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY causes them to consume an extra stack element (\"dummy element\") after signature validation. The dummy element is not inspected in any manner, and could be replaced by any value without invalidating the script. This document specifies a new rule to fix this signature malleability.\n\n\n==Specification==\n\nTo fix the dummy element malleability, a new consensus rule (\"NULLDUMMY\") is deployed to require that the dummy element MUST be the empty byte array. Anything else makes the script evaluate to false immediately. The NULLDUMMY rule applies to OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY in pre-segregated scripts, and also pay-to-witness-script-hash scripts described in BIP141.\n\n\n==Deployment==\n\nThis BIP will be deployed by \"version bits\" [https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki BIP9] using the same parameters for BIP141 and BIP143, with the name \"segwit\" and using bit 1.\n\nFor Bitcoin mainnet, the BIP9 starttime is midnight 15 November 2016 UTC (Epoch timestamp 1479168000) and BIP9 timeout is midnight 15 November 2017 UTC (Epoch timestamp 1510704000).\n\nFor Bitcoin testnet, the BIP9 starttime is midnight 1 May 2016 UTC (Epoch timestamp 1462060800) and BIP9 timeout is midnight 1 May 2017 UTC (Epoch timestamp 1493596800).\n\n\n==Compatibility==\n\nThe reference client has produced compatible signatures from the beginning, and the NULLDUMMY rule has been enforced as relay policy by the reference client since v0.10.0. There has been no transactions violating the requirement being added to the chain since at least August 2015.\n\nFor all scriptPubKey types in actual use, non-compliant signatures can trivially be converted into compliant ones, so there is no loss of functionality by this requirement. Users MUST pay extra attention to this new rule when designing exotic scripts.\n\n\n==Implementation==\n\nAn implementation for the reference client is available at https://github.com/bitcoin/bitcoin/pull/8636\n\n\n==Acknowledgements==\n\nPeter Todd is the original author of NULLDUMMY. This document is extracted from the previous [https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki BIP62] proposal, which was composed by Pieter Wuille and had input from various people.\n\n\n==Copyright==\n\nThis document is placed in the public domain.", "category": "bips" }, { "instruction": "I'm trying to understand 
 - can you walk me through it?",
    "input": "",
    "output": "BIP: 159\n  Layer: Peer Services\n  Title: NODE_NETWORK_LIMITED service bit\n  Authors: Jonas Schnelli \n  Status: Deployed\n  Type: Specification\n  Assigned: 2017-05-11\n  License: BSD-2-Clause\n
\n\n== Abstract ==\n\nDefine a service bit that allows pruned peers to signal their limited services.\n\n==Motivation==\n\nPruned peers can offer the same services as traditional peers, except that of serving all historical blocks.\nBitcoin right now only offers the NODE_NETWORK service bit to indicate that a peer can serve\nall historical blocks.", "category": "bips" }, { "instruction": "Hey, I need to set up Bitcoin Operations Guide - what's the command line way to do that?", "input": "", "output": "# Pruned peers can relay blocks, headers, transactions, and addresses, but they only guarantee serving a minimum number of historical blocks; thus, they should have a way to announce their service(s)", "category": "bips" }, { "instruction": "What's the deal with Peers no longer in initial block download should consider connecting some of their outbound connections to pruned peers, to allow other peers to bootstrap from non-pruned peers in Bitcoin? Explain it like I'm a friend.", "input": "", "output": "== Specification ==\n\n=== New service bit ===\n\nThis BIP proposes a new service bit\n\n{|class=\"wikitable\"\n|-\n| NODE_NETWORK_LIMITED || bit 10 (0x400) || If signaled, the peer MUST be capable of serving at least the last 288 blocks (~2 days).\n|}\n\nPruned/limited peers MUST NOT set a service bit that signals serving the complete block chain (e.g., NODE_NETWORK). Rationale: nodes that signal serving the complete block chain may also signal NODE_NETWORK_LIMITED.\n\nA safety buffer of 144 blocks to handle chain reorganizations SHOULD be taken into account when connecting to a peer signaling the NODE_NETWORK_LIMITED service bit.\n\n=== Address relay ===\n\nFull nodes following this BIP SHOULD relay address/services (addr message) from peers they would connect to (including peers signaling NODE_NETWORK_LIMITED).\n\n=== Counter-measures for peer fingerprinting ===\n\nPeers may have different prune depths (depending on their configuration, disk space, etc.), which can result in a fingerprinting weakness (finding the prune depth through getdata requests).\n\nPruned nodes should therefore avoid leaking the prune depth and SHOULD NOT serve blocks deeper than the signaled NODE_NETWORK_LIMITED threshold of 288 blocks.\n\n=== Risks ===\n\nPruned peers following this BIP may consume more outbound bandwidth.\n\nLight clients (and such) who are not checking the nServiceFlags (service bits) from a relayed addr-message may unwittingly connect to a pruned peer and ask for (filtered) blocks at a depth below the peer’s pruned depth. Light clients should therefore check the service bits and either (1) connect to peers signaling NODE_NETWORK_LIMITED that preferably do not also signal serving the full block chain, if they only require (filtered) blocks around the tip, or (2) connect to peers signaling serving the full block chain if they need data older than the latest 288 blocks. Light clients obtaining peer IPs through DNS seeds should use the DNS filtering option.\n\n== Compatibility ==\n\nThis proposal is backward compatible.\n\n== Reference implementation ==\n\n* https://github.com/bitcoin/bitcoin/pull/11740 (signaling)\n* https://github.com/bitcoin/bitcoin/pull/10387 (connection and relay)\n\n== Copyright ==\n\nThis BIP is licensed under the 2-clause BSD license.", "category": "bips" }, { "instruction": "Can you show me the CLI commands for 
?",
    "input": "",
    "output": "BIP: 118\n  Layer: Consensus (soft fork)\n  Title: SIGHASH_ANYPREVOUT for Taproot Scripts\n  Authors: Christian Decker \n           Anthony Towns \n  Comments-Summary: No comments yet.\n  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0118\n  Status: Draft\n  Type: Specification\n  Assigned: 2017-02-28\n  License: BSD-3-Clause\n  Requires: 340, 341, 342\n
\n\n== Introduction ==\n\n=== Abstract ===\n\nThis BIP describes a new type of public key for tapscript ([[bip-0342.mediawiki|BIP 342]]) transactions.\nIt allows signatures for these public keys to not commit to the exact UTXO being spent.\nThis enables dynamic binding of transactions to different UTXOs, provided they have compatible scripts.\n\n=== Copyright ===\n\nThis document is licensed under the 3-clause BSD license.\n\n=== Motivation ===\n\nOff-chain protocols make use of transactions that are not yet broadcast to the Bitcoin network in order to renegotiate the final state that should be settled on-chain.\nIn a number of cases it is desirable to respond to a given transaction being seen on-chain with a predetermined reaction in the form of another transaction.\nOften the same reaction is desired for a variety of different transactions that may be seen on-chain, but because the input signatures in the response transaction commit to the exact transaction that is being reacted to, this means a new signature must be created for every possible transaction one wishes to be able to react to.\n\nThis proposal introduces a new public key type'''Why a new public key type?'''\nNew public key types for tapscript can be introduced in a soft fork by specifying new rules for ''unknown public key types'' as specified in [[bip-0342.mediawiki|BIP 342]], as this only requires adding restrictions to the pre-existing signature opcodes.\nPossible alternative approaches would be to define new script opcodes, to use a different taproot leaf version, or to use a different set of SegWit outputs than those specified by [[bip-0341.mediawiki|BIP 341]]; however all of these approaches are more complicated, and are better reserved for other upgrades where the additional flexibility is actually needed.\nIn this case, we specify a new transaction digest, but retain the same elliptic curve and signature algorithm (ie, secp256k1 and [[bip-0340.mediawiki|BIP 340]]).\nthat modifies the behavior of the transaction digest algorithm used in the signature creation and verification, by excluding the commitment to the previous output (and, optionally, the witness script'''Why (and why not) commit to the witness script?'''\nThe [https://blockstream.com/eltoo.pdf eltoo] paper provides an example of why committing to the witness script is not always appropriate.\nIt uses script and the transaction nLockTime to make signatures asymmetric, so that a transaction with an earlier signature can be spent by a transaction with a later signature, but a transaction with a later signature cannot be spent by a transaction with an earlier signature.\nAs a result, a single signature for a third, even later transaction must be able to spend both the prior transactions, even though they have a different tapscript.\nOn the other hand, these cases also provide a good reason to have the option to commit to the script: because each transaction has a new script, committing to the script allows you to produce a signature that applies to precisely one of these transactions.\nIn the eltoo case, this allows you to have a signature for an update transaction that can be applied to any prior update, and a signature for a settlement transaction that applies only to the corresponding update transaction, while using the same key for both, which in turn allows for a more compact script.\n and value '''Why (and why not) commit to the input value?'''\nCommitting to the input value may provide additional safety that a signature can't be maliciously reused to claim funds that the signer does not intend to spend, so by default it seems sensible to commit to it. However, doing so prevents being able to use a single signature to consolidate a group of UTXOs with the same spending condition into a single UTXO which may be useful for some protocols, such as the proposal for [https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-January/002448.html layered commitments with eltoo].).\nRemoving this commitment allows dynamic rebinding of a signed transaction to another previous output that requires authorisation by the same key.\n\nThe dynamic rebinding is opt-in due to using a separate public key type, and the breadth of transactions the signature can be rebound to can be further restricted by using different keys, committing to the script being spent in the signature, using different amounts between UTXOs, using different nSequence values in the spending transaction, or using the codeseparator opcode to commit to the position in the script.\n\n== Specification ==\n\nThis BIP modifies the behaviour of the [[bip-0342.mediawiki|BIP 342]] signature opcodes'''What about key path spends?'''\nThis proposal only supports ANYPREVOUT signatures via script path spends, and does not support ANYPREVOUT signatures for key path spends.\nThis is for two reasons: first, not supporting key path spends allows this proposal to be independent of the core changes included in [[bip-0341.mediawiki|BIP 341]] and [[bip-0342.mediawiki|BIP 342]]; second, it allows addresses to opt-in or opt-out of ANYPREVOUT support while remaining indistinguishable prior to being spent.\n (CHECKSIG, CHECKSIGVERIFY, and CHECKSIGADD) for public keys that have a length of 33 bytes and a first byte of 0x01 or the public key which is precisely the single byte vector 0x01'''Use of 0x01 public key type'''\nBecause OP_0 leaves an empty vector on the stack it would not satisfy [[bip-0342.mediawiki|BIP 342]]'s rules for unknown public key types. As such, it is convenient to use one of OP_1..OP_16 or OP_1NEGATE as a way to reference the taproot internal key.\nTo keep things as simple as possible, we use the first of these, and add the same byte as a prefix to allow ANYPREVOUT signatures for explicitly specified keys.\n.\nThese keys are termed '''BIP 118 public keys'''.\n\n==== Rules for signature opcodes ====\n\nThe [[bip-0342.mediawiki|BIP 342]] rules for signature opcodes are modified by removing keys with the first byte 0x01 and length of either 1-byte or 33-bytes from the list of unknown public key types, and adding the following rule prior to the handling of unknown public key types:\n\n* If the public key is the single byte 0x01, or if the public key is 33 bytes and the first byte of the public key is 0x01, it is considered to be a BIP 118 public key:\n** If the signature is not the empty vector, the signature is validated according to the [[bip-0341.mediawiki|BIP 341]] signing validation rules with the public key, allowable hash_type values, and transaction digest modified as defined below.\n\n==== Public key ====\n\nTo convert the 1-byte BIP 118 public key for use with [[bip-0340.mediawiki|BIP 340]], use the 32-byte taproot internal key, p, as defined in [[bip-0341.mediawiki|BIP 341]].\n\nTo convert a 33-byte BIP 118 public key for use with [[bip-0340.mediawiki|BIP 340]], remove the 0x01 prefix and use the remaining 32 bytes.\n\n==== Signature message ====\n\nWe define the functions ''Msg118(hash_type)'' and ''Ext118(hash_type)'' which compute the message being signed as a byte array.\n\nThe parameter ''hash_type'' is an 8-bit unsigned value, reusing values defined in [[bip-0341.mediawiki|BIP 341]], with the addition that the values 0x41, 0x42, 0x43, 0xc1, 0xc2, and 0xc3 are also valid for BIP 118 public keys.\n\nWe define the following constants using bits 6 and 7 of hash_type:\n\n* SIGHASH_ANYPREVOUT = 0x40\n* SIGHASH_ANYPREVOUTANYSCRIPT = 0xc0\n\nThe following restrictions apply and cause validation failure if violated:\n* Using any undefined ''hash_type'' (not ''0x00'', ''0x01'', ''0x02'', ''0x03'', ''0x41'', ''0x42'', ''0x43'', ''0x81'', ''0x82'', ''0x83'', ''0xc1'', ''0xc2'', or ''0xc3'').\n* Using SIGHASH_SINGLE without a \"corresponding output\" (an output with the same index as the input being verified).\n\nIf these restrictions are not violated, ''Msg118(hash_type)'' evaluates as follows.\n\nIf ''hash_type & 0x40 == 0'', then ''Msg118(hash_type) = SigMsg(hash_type, 1)'', where ''SigMsg'' is as defined in [[bip-0341.mediawiki|BIP 341]].\n\nIf ''hash_type & 0x40 != 0'', then ''Msg118(hash_type)'' 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 items are encoded in little-endian.\n\n* Control:\n** ''hash_type'' (1).\n* Transaction data:\n** ''nVersion'' (4): the ''nVersion'' of the transaction.\n** ''nLockTime'' (4): the ''nLockTime'' of the transaction.\n** If ''hash_type & 3'' does not equal SIGHASH_NONE or SIGHASH_SINGLE:\n*** ''sha_outputs'' (32): the SHA256 of the serialization of all outputs in CTxOut format.\n* Data about this input:\n** ''spend_type'' (1): equal to 2 if no annex is present, or 3 otherwise (the original witness stack has two or more witness elements, and the first byte of the last element is ''0x50'')\n** If ''hash_type & 0xc0'' is SIGHASH_ANYPREVOUT:\n*** ''amount'' (8): value of the previous output spent by this input.\n*** ''scriptPubKey'' (35): ''scriptPubKey'' of the previous output spent by this input, serialized as script inside CTxOut. Its size is always 35 bytes.\n** ''nSequence'' (4): ''nSequence'' of this input.\n** If an annex is present (the lowest bit of ''spend_type'' is set):\n*** ''sha_annex'' (32): the SHA256 of ''(compact_size(size of annex) || annex)'', where ''annex'' includes the mandatory ''0x50'' prefix.\n* Data about this output:\n** If ''hash_type & 3'' equals SIGHASH_SINGLE:\n*** ''sha_single_output'' (32): the SHA256 of the corresponding output in CTxOut format.\n\nSimilarly, ''Ext118(hash_type)'' evaluates to the concatenation of the following data, in order:\n\n* Extension:\n** If ''hash_type & 0xc0'' is not SIGHASH_ANYPREVOUTANYSCRIPT:\n*** ''tapleaf_hash'' (32): the tapleaf hash as defined in [[bip-0341.mediawiki|BIP 341]]\n** ''key_version'' (1): a constant value ''0x01'' representing that this is a signature for a BIP 118 public key.\n** ''codesep_pos'' (4): the opcode position of the last executed OP_CODESEPARATOR 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.\n\nTo verify a signature ''sig'' for a BIP 118 public key ''p'':\n\n* If the ''sig'' is 64 bytes long, return ''Verify(p, hashTapSigHash(0x00 || Msg118(0x00) || Ext118(0x00)), sig)''\n* If the ''sig'' is 65 bytes long, return ''sig[64] ≠ 0x00 and Verify(p, hashTapSighash(0x00 || Msg118(sig[64]) || Ext118(sig[64])), sig[0:64])''.\n* Otherwise, fail.\n\n''Verify'' is as defined in [[bip-0340.mediawiki|BIP 340]].\n\nThe key differences from [[bip-0342.mediawiki|BIP 342]] signature verification are:\n\n* In all cases, key_version is set to the constant value 0x01 instead of 0x00.'''Why change key_version?''' Changing key_version ensures that if the same private key is used to generate both a [[bip-0342.mediawiki|BIP 342]] key and a BIP 118 public key, that a signature for the [[bip-0342.mediawiki|BIP 342]] key is not also valid for the BIP 118 public key (and vice-versa).\n* If SIGHASH_ANYPREVOUT is set, the digest is calculated as if SIGHASH_ANYONECANPAY was set, except outpoint is not included in the digest.\n* If SIGHASH_ANYPREVOUTANYSCRIPT is set, the digest is calculated as if SIGHASH_ANYONECANPAY was set, except outpoint, amount, scriptPubKey and tapleaf_hash are not included in the digest.\n\n== Security ==\n\n==== Signature replay ====\n\nBy design, SIGHASH_ANYPREVOUT and SIGHASH_ANYPREVOUTANYSCRIPT introduce additional potential for signature replay (that is they allow the same signature to be reused on a different transaction) when compared to SIGHASH_ALL and SIGHASH_ANYONECANPAY signatures.\n\nBoth SIGHASH_ALL and SIGHASH_ANYONECANPAY signatures prevent signature replay by committing to one or more inputs, so replay of the signature is only possible if the same input can be spent multiple times, which is not possible on the Bitcoin blockchain (due to enforcement of [[bip-0030.mediawiki|BIP 30]]).\nWith SIGHASH_ANYPREVOUT signature replay is possible for different UTXOs with the same scriptPubKey and the same value, while with SIGHASH_ANYPREVOUTANYSCRIPT signature replay is possible for any UTXOs that reuse the same BIP 118 public key in one of their potential scripts.\n\nAs a consequence, implementers MUST ensure that BIP 118 public keys are only reused when signature replay cannot cause loss of funds (eg due to other features of the protocol or other constraints on the transaction), or when such a loss of funds is acceptable.\n\n==== Malleability ====\n\nUse of SIGHASH_ANYPREVOUT or SIGHASH_ANYPREVOUTANYSCRIPT may introduce additional malleability vectors.\n\nIn particular, a transaction authenticated using only ANYPREVOUT signatures is malleable to anyone able to provide an alternate input satisfied by the signature -- an input changed in this way would produce a new, valid transaction paying the same recipient, but with a different txid.\nDepending on the changes to the inputs, this might conflict with the original transaction (if some inputs remain shared) or might result in a double-payment to the recipient (if they do not).\n\nFurther, for a chain of transactions using the same scriptPubKey and value, and only authenticated via ANYPREVOUT signatures (as envisioned in eltoo for failure cases), it may be possible for any third party to malleate the transactions (and their txids) without having access to any of the private keys, particularly by omitting intermediate transactions.\n\nThis form of malleation can be dealt with by the child transactions also using ANYPREVOUT signatures -- when a parent transaction is malleated, its children can be adjusted to reference the new txid as the input and the ANYPREVOUT signatures remain valid.\n\nHowever child transactions that are authorised by a SIGHASH_ALL or SIGHASH_ANYONECANPAY signature will need new signatures if their inputs are malleated in this way.\nThis risk may be mitigated somewhat by using [[bip-0068.mediawiki|BIP 68]]/[[bip-0112.mediawiki|BIP 112]] relative time locks before spending a UTXO that had been authorised via an ANYPREVOUT signature with SIGHASH_ALL or SIGHASH_ANYONECANPAY: a relative timelock can ensure that the inputs have enough confirmations that they can only be replaced in the event of a large block reorg.\nNote that this approach has drawbacks: relative timelocks prevent fee-bumping via child-pays-for-parent, and have the obvious drawback of making the funds temporarily unusable until the timelock expires.\n\n==== Privacy considerations ====\n\nIt is expected that ANYPREVOUT signatures will only be rarely used in practice.\nProtocol and wallet designers should aim to have their transactions use Taproot key path spends whenever possible, both for efficiency reasons due to the lower transaction weight, but also for privacy reasons to avoid third parties being able to distinguish their transactions from those of other protocols.\n\nTransactions that do use ANYPREVOUT signatures will therefore reveal information about the transaction, potentially including that cooperation was impossible, or what protocol or software was used (due to the details of the script).\n\nIn order to maximise privacy, it is therefore recommended that protocol designers only use BIP 118 public keys in scripts that will be spent using at least one ANYPREVOUT signature, and either use key path spends or alternate scripts in the taproot merkle tree for any spends that can be authorised without ANYPREVOUT signatures.\nFollowing this recommendation may require additional script branches, which may mean disregarding this recommendation may result in a better tradeoff between cost and privacy in some circumstances.\n\n== Rationale ==\n\n\n\n== Deployment ==\n\nTODO\n\nThis may be deployed as a soft-fork either concurrent with, or subsequent to the deployment of [[bip-0340.mediawiki|BIP 340]], [[bip-0341.mediawiki|BIP 341]] and [[bip-0342.mediawiki|BIP 342]].\n\n== Backwards compatibility ==\n\nAs a soft fork, older software will continue to operate without modification.\nNodes that have not upgraded to support [[bip-0341.mediawiki|BIP 341]] will see all taproot witness programs as anyone-can-spend scripts, and nodes that have upgraded to support [[bip-0341.mediawiki|BIP 341]] and [[bip-0342.mediawiki|BIP 342]] but not BIP 118 will simply treat any non-empty signature against a BIP 118 public key as valid.\nAs such, nodes are strongly encourage to upgrade in order to fully validate signatures for the new public key type.\n\nNon-upgraded wallets can receive and send bitcoin from non-upgraded and upgraded wallets using SegWit version 0 programs, traditional pay-to-pubkey-hash, etc.\nDepending on the implementation, non-upgraded wallets may be able to send to SegWit version 1 programs if they support sending to [[bip-0350.mediawiki|BIP350]] Bech32m addresses and do not prevent the transaction from being broadcast due to considering the outputs non-standard.\n\n== Revisions ==\n\nApart from being based on Taproot rather than SegWit v0, the main differences to prior revisions of this BIP are:\n\n* The sighash flag has been renamed from \"NOINPUT\" to \"ANYPREVOUT\" to reflect that while any prevout may potentially be used with the signature, some aspects of the input are still committed to, namely the input nSequence value, and (optionally) the spending conditions and amount.\n* Previously NOINPUT would have worked for direct public key spends (assuming deployment was fleshed out in a way similar to BIP 141 P2WPKH and P2WSH), however this proposal only applies to signatures via tapscript, and not direct key path spends. This means that addresses must opt-in to the ability to be spent by a SIGHASH_ANYPREVOUT or SIGHASH_ANYPREVOUTANYSCRIPT signature by including an appropriate tapscript path when the address is created.\n* NOINPUT signatures do not commit to the output's spending conditions either via scriptPubKey or the redeem/witness script. This behaviour is preserved when SIGHASH_ANYPREVOUTANYSCRIPT is used, but when SIGHASH_ANYPREVOUT is used, the signature now commits to scriptPubKey and the tapscript.\n* NOINPUT signatures did commit to the input's amount. This behaviour is preserved when SIGHASH_ANYPREVOUT is used, but not when SIGHASH_ANYPREVOUTANYSCRIPT is used.\n* OP_CODESEPARATOR in script will affect both SIGHASH_ANYPREVOUT and SIGHASH_ANYPREVOUTANYSCRIPT signatures, whereas it would not have in the previous draft.\n\n== Acknowledgements ==\n\nThe SIGHASH_NOINPUT flag was first proposed by Joseph Poon in [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012460.html February 2016], after being mentioned in the original [http://lightning.network/lightning-network-paper.pdf Lightning paper] by Joseph Poon and Thaddeus Dryja.\nThis document is the result of discussions with many people and had direct input from Greg Maxwell, Jonas Nick, Pieter Wuille and others.", "category": "bips" }, { "instruction": "I'm stuck with 
 - what should I check?",
    "input": "",
    "output": "BIP: 10\n  Layer: Applications\n  Title: Multi-Sig Transaction Distribution\n  Authors: Alan Reiner \n  Status: Closed\n  Type: Informational\n  Assigned: 2011-10-28\n
\n\nA multi-signature transaction is one where a certain number of Bitcoins are \"encumbered\" with more than one recipient address. The subsequent transaction that spends these coins will require each party involved (or some subset, depending on the script), to see the proposed transaction and sign it with their private key. This necessarily requires collaboration between all parties -- to propose a distribution of encumbered funds, collect signatures from all necessary participants, and then broadcast the completed transaction.\n\nThis BIP describes a way standardize the encoding of proposal transactions, to assist with signature collection and broadcast (which includes regular, 1-of-1 transactions requiring signatures from an offline computer). The goal is to encourage a standard that guarantees interoperability of all programs that implement it.\n\n\n==Motivation==\n\nThe enabling of multi-signature transactions in Bitcoin will introduce a great deal of extra functionality to the users of the network, but also a great deal of extra complexity. Executing a multi-signature tx will be a multi-step process, and will potentially get worse with multiple clients, each implementing this process differently. By providing an efficient, standardized technique, we can improve the chance that developers will adopt compatible protocols and not bifurcate the user-base based on client selection.\n\nIn addition to providing a general encoding scheme for transaction signing/collection, it does not require the signing device to hold any blockchain information (all information needed for verification and signing is part of the encoding). This enables the existence of very lightweight devices that can be used for signing since they do not need the blockchain -- only a minimal set of Bitcoin tools and an ECDSA module. Therefore, BIP 0010 has benefit beyond just multi-signature transactions.\n\n==Specification==\n\nThis BIP proposes the following process, with terms in quotes referring to recommended terminology that should be encouraged across all implementations.", "category": "bips" }, { "instruction": "How do I troubleshoot Bitcoin Operations Guide issues?", "input": "", "output": "# One party will initiate this process by creating a \"Distribution Proposal\", which could be abbreviated DP, or TxDP", "category": "bips" }, { "instruction": "What are the best practices for Bitcoin Operations Guide?", "input": "", "output": "# The user creating the TxDP (the preparer) will create the transaction as they would like to see it spent, but with blank TxIn scripts (where the signatures scripts will eventually go).", "category": "bips" }, { "instruction": "Walk me through setting up Bitcoin Operations Guide step by step", "input": "", "output": "# The proposed transaction will be spending a set of unspent TxOuts available in the blockchain. The full transactions containing these TxOuts will be serialized and included, as well. This so that the values of the TxIns can be verified before signing (the prev-tx-hash is part of the data being signed, but the value is not). By including the full tx, the signing party can verify that the tx matches the OutPoint hash, and then verify input values, all without any access to the blockchain.", "category": "bips" }, { "instruction": "What commands would you run to work with Bitcoin Operations Guide?", "input": "", "output": "# The TxDP will have an \"DP ID\" or \"Unsigned ID\" which is the hash of the proposed transaction with blanked scripts, in Base58. This is a specific naming convention to make sure it is not confused with the actual transaction ID that it will have after it is broadcast (the transaction ID cannot be determined until after all signatures are collected). The final Tx ID can be referred to as its \"Broadcast ID\", in order to distinguish it from the pre-signed ID.", "category": "bips" }, { "instruction": "I want to understand Bitcoin Operations Guide from a technical perspective", "input": "", "output": "# The TxDP will have a potentially-unordered list of sig-pubkey pairs which represent collected signatures. If you receive a TxDP missing only your signature, you can broadcast it as soon as you sign it.", "category": "bips" }, { "instruction": "Can you explain Bitcoin Operations Guide like we're having a beer and talking Bitcoin?", "input": "", "output": "# Identical TxDP objects with different signatures can be easily combined. This allows one party to send out all the requests for signatures at once, and combine them all when they are received (instead of having to \"pass it around\".", "category": "bips" }, { "instruction": "How would you explain For cases where the TxDP might be put into a file or sent via email, it should use .txdp or .btcdp suffix to someone who knows Bitcoin basics?", "input": "", "output": "Anyone adopting BIP 0010 for multi-sig transactions will use the following format (without indentation):\n\n
\n '-----BEGIN-TRANSACTION-TXDPID-------'\n (\"_TXDIST_\") (magicBytes) (base58Txid) (varIntTxSize)\n    (serializedTxListInHex_Line1)\n    (serializedTxListInHex_Line2)\n    (serializedTxListInHex_Line3)\n    ...\n (\"_TXINPUT_\") (00) (InputValue)\n    (\"_SIG_\") (AddrBase58) (SigBytes) (SigHexPart0)\n    (SigHexRemainingLines)\n    (\"_SIG_\") (AddrBase58) (SigBytes) (SigHexPart0)\n    (SigHexRemainingLines)\n (\"_TXINPUT_\") (01) (InputValue)\n    (\"_SIG_\") (AddrBase58) (SigBytes) (SigHexPart0)\n    (SigHexRemainingLines)\n (\"_TXINPUT_\") (02) (InputValue)\n '-------END-TRANSACTION-TXDPID-------'\n
\n\nThe following is an example TxDP from Armory, produced while running on the test network. Its DPID is 3fX59xPj:\n\n\n -----BEGIN-TRANSACTION-3fX59xPj-------------------------------------------------\n _TXDIST_fabfb5da_3fX59xPj_00a0\n 010000000292807c8e70a28c687daea2998d6273d074e56fa8a55a0b10556974cf2b526e61000000\n 0000ffffffffe3c1ee0711611b01af3dee55b1484f0d6b65d17dce4eff0e6e06242e6cf457e10000\n 000000ffffffff02b0feea0b000000001976a91457996661391fa4e95bed27d7e8fe47f47cb8e428\n 88ac00a0acb9030000001976a914dc504e07b1107110f601fb679dd3f56cee9ff71e88ac00000000\n 0100000001eb626e4f73d88f415a8e8cb32b8d73eed47aa1039d0ed2f013abdc741ce6828c010000\n 008c493046022100b0da540e4924518f8989a9da798ca2d9e761b69a173b8cc41a3e3e3c6d77cd50\n 022100ecfa61730e58005338420516744ef680428dcfc05022dec70a851365c8575b190141042dc5\n be3afa5887aee4a377032ed014361b0b9b61eb3ea6b8a8821bfe13ee4b65cd25d9630e4f227a53e8\n bf637f85452c9981bcbd64ef77e22ce97b0f547c783effffffff0200d6117e030000001976a914cf\n f580fd243f64f0ad7bf69faf41c0bf42d86d8988ac00205fa0120000001976a9148d573ef6984fd9\n f8847d420001f7ac49b222a24988ac000000000100000001f2782db40ae147398a31cff9c7cc3423\n 014a073a92e463741244330cc304168f000000008c493046022100c9311b9eef0cc69219cb96838f\n dd621530a80c46269a00dccc66498bc03ccf7a0221003742ee652a0a76fd28ad81aa73bb7f7a0a6a\n 81850af58f62d9a184d10e5eec30014104f815e8ef4cad584e04974889d7636e8933803d2e72991d\n b5288c9e953c2465533905f98b7b688898c7c1f0708f2e49f0dd0abc06859ffed5144e8a1018a4e8\n 63ffffffff02008c8647000000001976a914d4e211215967f8e3744693bf85f47eb4ee9567fc88ac\n 603d4e95010000001976a914e9a6b50901c1969d2b0fd43a3ccfa3fef3291efe88ac00000000\n _TXINPUT_00_150.00000000\n _SIG_mzUYGfqGpyXmppYpmWJ31Y4zTxR4ZCod22_00_008c\n 4930460221007699967c3ec09d072599558d2e7082fae0820206b63aa66afea124634ed11a080221\n 0003346f7e963e645ecae2855026dc7332eb7237012539b34cd441c3cef97fbd4d01410497d5e1a0\n 0e1db90e893d1f2e547e2ee83b5d6bf4ddaa3d514e6dc2d94b6bcb5a72be1fcec766b8c382502caa\n 9ec09fe478bad07d3f38ff47b2eb42e681c384cc\n _TXINPUT_01_12.00000000\n _SIG_mzvaN8JUhHLz3Gdec1zBRxs5rNaYLQnbD1_01_008c\n 49304602210081554f8b08a1ad8caa69e34f4794d54952dac7c5efcf2afe080985d6bd5b00770221\n 00dea20ca3dbae1d15ec61bec57b4b8062e7d7c47614aba032c5a32f651f471cfd014104c30936d2\n 456298a566aa76fefeab8a7cb7a91e8a936a11757c911b4c669f0434d12ab0936fc13986b156156f\n 9b389ed244bbb580112be07dbe23949a4764dffb\n -------END-TRANSACTION-3fX59xPj-------------------------------------------------\n\n\nIn this transaction, there are two inputs, one of 150 BTC and the other of 12 BTC. This transaction combines 162 BTC to create two outputs, one of 160 BTC, one 1.9995 BTC, and a tx fee of 0.0005. In this TxDP, both inputs have been signed, and thus could broadcast immediately.\n\nThe style of communication is taken directly from PGP/GPG, which uses blocks of ASCII like this to communicate encrypted messages and signatures. This serialization is compact, and will be interpreted the same in all character encodings. It can be copied inline into an email, or saved in a text file. The advantage over the analogous PGP encoding is that there are some human readable elements to it, for users that wish to examine the TxDP packet manually, instead of requiring a program to parse the core elements of the TxDP.\n\nA party receiving this TxDP can simply add their signature to the appropriate _TXINPUT_ line. If that is the last signature required, they can broadcast it themselves. Any software that implements this standard should be able to combine multiple TxDPs into a single TxDP. However, even without the programmatic support, a user could manually combine them by copying the appropriate _SIG_ lines between serializations, though it is not the recommended method for combining TxDPs.\n\n== Changelog ==\n\n* 2014-11-26:\n** Withdrawn after Armory stopped using BIP10 and no other projects were known to implement support (see [https://github.com/bitcoin/bips/pull/125 bips#125]).\n* 2011-10-28:\n** Original Draft published.\n\n== Reference Implementation ==\n\nThis proposal was implemented and tested in the older versions of ''Armory'' Bitcoin software for use in offline-wallet transaction signing (as a 1-of-1 transaction). Implementation can be found in https://github.com/etotheipi/BitcoinArmory/blob/v0.91-beta/armoryengine/Transaction.py under the class PyTxDistProposal. However, as of version 0.92 released in July 2014, Armory no longer uses this proposal for offline wallet transaction signing and has moved on to a new format.", "category": "bips" }, { "instruction": "I'm trying to understand 
 - can you walk me through it?",
    "input": "",
    "output": "BIP: 93\n  Layer: Applications\n  Title: codex32: Checksummed SSSS-aware BIP32 seeds\n  Authors: Leon Olsson Curr and Pearlwort Sneed \n           Andrew Poelstra \n  Status: Draft\n  Type: Informational\n  Assigned: 2023-02-13\n  License: BSD-3-Clause\n  Discussion: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/021469.html\n
\n\n==Introduction==\n\n===Abstract===\n\nThis document proposes a checksummed base32 format, \"codex32\", and a standard for backing up and restoring the master seed of a\n[https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki BIP-0032] hierarchical deterministic wallet using it.\nIt includes an encoding format, a BCH error-correcting checksum, and optional Shamir's secret sharing algorithms for share generation and secret recovery.\nSecret data can be encoded directly, or split into up to 31 shares.\nA minimum threshold of shares, which can be between 2 and 9, is needed to recover the secret, whereas without sufficient shares, no information about the secret is recoverable.\n\n===Copyright===\n\nThis document is licensed under the 3-clause BSD license.\n\n===Motivation===\n\nBIP-0032 master seed data is the source entropy used to derive all private keys in an HD wallet.\nSafely storing this secret data is the hardest and most important part of self-custody.\nHowever, there is a tension between security, which demands limiting the number of backups, and resilience, which demands widely replicated backups.\nEncrypting the seed does not change this fundamental tradeoff, since it leaves essentially the same problem of how to back up the encryption key(s).\n\nTo allow users freedom to make this tradeoff, we use Shamir's secret sharing, which guarantees that any number of shares less than the threshold leaks no information about the secret.\nThis approach allows increasing safety by widely distributing the generated shares, while also providing security against the compromise of one or more shares (as long as fewer than the threshold have been compromised).\n\n[https://github.com/satoshilabs/slips/blob/master/slip-0039.md SLIP-0039] has essentially the same motivations as this standard.\nHowever, unlike SLIP-0039,\n\n* this standard aims to be simple enough for hand computation\n* we use the bech32 alphabet rather than a word list, resulting in fixed-length compact encodings\n* we do not support multi-level secret sharing (splitting of shares), although it is technically possible and may be added in a future BIP\n* because of the need to support hand computation, we '''do not''' support passphrases or key hardening\n\nUsers who demand a higher level of security for particular secrets, or have a general distrust in digital electronic devices, have the option of using hand computation to backup and restore secret data in an interoperable manner.\nIn particular, all computations can be done with simple lookup tables.\n'''It is therefore possible to compute and verify checksums, and to split and recover seeds, entirely using pen and paper.'''\nFor long-lived rarely-used seeds, the ability to hand-verify checksums has a significant benefit even for users who do not care to do any other part of this process by hand.\nIt means that they can verify the integrity (against non-malicious tampering) of their shares regularly, say, on an annual basis, without needing to continually expose secret data to new hardware.\n\nThe ability to compute properties by hand comes from our choice of a small field and our use of linear error correcting codes.\nIt does not come with any reduction in security, as long as users use high-quality randomness.\nNote that hand computation is optional, the particular details of hand computation are outside the scope of this standard, and implementers do not need to be concerned with this possibility.\n\n[https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki BIP-0039] serves the same purpose as this standard: encoding master seeds for storage by users.\nHowever, BIP-0039 has no error-correcting ability, cannot sensibly be extended to support secret sharing, has no support for versioning or other metadata, and has many technical design decisions that make implementation and interoperability difficult (for example, the use of SHA-512 to derive seeds, or the use of 11-bit words).\n\n==Specification==\n\nWe first describe the general checksummed base32'''Why use base32 at all?''' The lack of mixed case makes it more\nefficient to read out loud, write, type or to put into QR codes. format called\n''codex32'' and then define a BIP-0032 master seed encoding using it.\n\n===codex32===\n\nA codex32 string is similar to a bech32 string defined in [https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki BIP-0173].\nIt reuses the base-32 character set from BIP-0173, and consists of:\n\n* A human-readable part, which is the string \"ms\" (or \"MS\").\n* A separator, which is always \"1\".\n* A data part which is in turn subdivided into:\n** A threshold parameter, which MUST be a single digit between \"2\" and \"9\", or the digit \"0\".\n*** If the threshold parameter is \"0\" then the share index, defined below, MUST have a value of \"s\" (or \"S\").\n** An identifier consisting of 4 bech32 characters.\n** A share index, which is any bech32 character. Note that a share index value of \"s\" (or \"S\") is special and denotes the unshared secret (see section \"Unshared Secret\").\n** A payload which is a sequence of up to 74 bech32 characters. (However, see '''Long codex32 Strings''' below for an exception to this limit.)\n** A checksum which consists of 13 bech32 characters as described below.\n\nAs with bech32 strings, a codex32 string MUST be entirely uppercase or entirely lowercase.\nNote that per BIP-0173, the lowercase form is used when determining a character's value for checksum purposes.\nIn particular, given an all uppercase codex32 string, we still use lowercase ms as the human-readable part during checksum construction.\nFor presentation, lowercase is usually preferable, but uppercase SHOULD be used for handwritten codex32 strings.\nIf a codex32 string is encoded in a QR code, it SHOULD use the uppercase form, as this is encoded more compactly.\n\n====Checksum====\n\nThe last thirteen characters of the data part form a checksum and contain no information.\nValid strings MUST pass the criteria for validity specified by the Python 3 code snippet below.\nThe function ms32_verify_checksum must return true when its argument is the data part as a list of integers representing the characters converted using the bech32 character table from BIP-0173.\n\nTo construct a valid checksum given the data-part characters (excluding the checksum), the ms32_create_checksum function can be used.\n\n\nMS32_CONST = 0x10ce0795c2fd1e62a\n\ndef ms32_polymod(values):\n GEN = [\n 0x19dc500ce73fde210,\n 0x1bfae00def77fe529,\n 0x1fbd920fffe7bee52,\n 0x1739640bdeee3fdad,\n 0x07729a039cfc75f5a,\n ]\n residue = 0x23181b3\n for v in values:\n b = (residue >> 60)\n residue = (residue & 0x0fffffffffffffff) << 5 ^ v\n for i in range(5):\n residue ^= GEN[i] if ((b >> i) & 1) else 0\n return residue\n\ndef ms32_verify_checksum(data):\n if len(data) >= 96: # See Long codex32 Strings\n return ms32_verify_long_checksum(data)\n if len(data) <= 93:\n return ms32_polymod(data) == MS32_CONST\n return False\n\ndef ms32_create_checksum(data):\n if len(data) > 80: # See Long codex32 Strings\n return ms32_create_long_checksum(data)\n values = data\n polymod = ms32_polymod(values + [0] * 13) ^ MS32_CONST\n return [(polymod >> 5 * (12 - i)) & 31 for i in range(13)]\n\nThis implements a [https://en.wikipedia.org/wiki/BCH_code BCH code] that\nguarantees detection of '''any error affecting at most 8 characters'''\nand has less than a 3 in 1020 chance of failing to detect more\nrandom errors.\n\n====Error Correction====\n\nA codex32 string without a valid checksum MUST NOT be used.\nThe checksum is designed to be an error correcting code that can correct up to 4 character substitutions, up to 8 unreadable characters (called erasures), or up to 13 consecutive erasures.\nImplementations SHOULD provide the user with a corrected valid codex32 string if possible.\nHowever, implementations SHOULD NOT automatically proceed with a corrected codex32 string without user confirmation of the corrected string, either by prompting the user, or returning a corrected string in an error message and allowing the user to repeat their action.\nWe do not specify how an implementation should implement error correction. However, we recommend that:\n\n* Implementations make suggestions to substitute non-bech32 characters with bech32 characters in some situations, such as replacing \"B\" with \"8\", \"O\" with \"0\", \"I\" with \"l\", etc.\n* Implementations interpret \"?\" as an erasure.\n* Implementations optionally interpret other non-bech32 characters, or characters with incorrect case, as erasures.\n* If a string with 8 or fewer erasures can have those erasures filled in to make a valid codex32 string, then the implementation suggests such a string as a correction.\n* If a string consisting of valid bech32 characters in the proper case can be made valid by substituting 4 or fewer characters, then the implementation suggests such a string as a correction.\n\n===Unshared Secret===\n\nWhen the share index of a valid codex32 string (converted to lowercase) is the letter \"s\", we call the string a codex32 secret.\n\nThe secret is decoded by converting the payload to bytes:\n\n* Translate the characters to 5 bits values using the bech32 character table from BIP-0173, most significant bit first.\n* Re-arrange those bits into groups of 8 bits. Any incomplete group at the end MUST be 4 bits or less, and is discarded.\n\nNote that unlike the decoding process in BIP-0173, we do NOT require that the incomplete group be all zeros.\n\nFor an unshared secret, the threshold parameter (the first character of the data part) is ignored (beyond the fact it must be a digit for the codex32 string to be valid).\nWe recommend using the digit \"0\" for the threshold parameter in this case.\nThe 4 character identifier also has no effect beyond aiding users in distinguishing between multiple different secrets in cases where they have more than one.\n\nThe function ms32_encode constructs a codex32 string when its argument is the converted data-part characters (excluding the checksum).\n\nTo validate a codex32 string and determine the data-part (excluding the checksum) as a list of 5-bit values, the ms32_decode function can be used.\n\n\nCHARSET = \"qpzry9x8gf2tvdw0s3jn54khce6mua7l\"\n\ndef ms32_encode(data):\n combined = data + ms32_create_checksum(data)\n return \"ms\" + \"1\" + ''.join([CHARSET[d] for d in combined])\n\ndef ms32_decode(codex):\n if ((any(ord(x) < 33 or ord(x) > 126 for x in codex)) or\n (codex.lower() != codex and codex.upper() != codex)):\n return None\n codex = codex.lower()\n pos = codex.rfind(\"1\")\n if pos < 2 or not (48 <= len(codex) <= 127):\n return None\n if not all(x in CHARSET for x in codex[pos+1:]):\n return None\n if codex[:pos] != \"ms\" or codex[pos+1].isalpha() or codex[pos+1] == \"0\" and codex[pos+6] != \"s\":\n return None\n data = [CHARSET.index(x) for x in codex[pos+1:]]\n if not ms32_verify_checksum(data):\n return None\n return data[:-13 if len(data) < 94 else -15] # See Long codex32 Strings\n\n\n===Master seed format===\n\nWhen the human-readable part of a valid codex32 secret (converted to lowercase) is the string \"ms\", we call it a codex32-encoded master seed or secret seed. The payload in this case is a direct encoding of a BIP-0032 HD master seed.\n\nA secret seed is a codex32 encoding of:\n\n* The human-readable part \"ms\" for master seed.\n* The data-part values:\n** A threshold parameter, which MUST be a single digit between \"2\" and \"9\", or the digit \"0\".\n** An identifier consisting of 4 bech32 characters.\n*** We do not define how to choose the identifier, beyond noting that it SHOULD be distinct for every master seed and share set the user may need to disambiguate.\n** The share index \"s\".\n** A conversion of the 16-to-64-byte BIP-0032 HD master seed to bech32:\n*** Start with the bits of the master seed, most significant bit per byte first.\n*** Re-arrange those bits into groups of 5, and pad with arbitrary bits at the end if needed.\n*** Translate those bits to characters using the bech32 character table from BIP-0173.\n** A valid checksum in accordance with the Checksum section.\n\n===Recovering Secret===\n\nWhen the share index of a valid codex32 string (converted to lowercase) is not the letter \"s\", we call the string a codex32 share.\nThe first character of the data part indicates the threshold of the share, and it is required to be a non-\"0\" digit.\n\nIn order to recover a secret, one needs a set of valid shares such that:\n\n* All shares have the same threshold value, the same identifier, and the same length.\n* All of the share index values are distinct.\n* The number of shares is exactly equal to the (common) threshold value.\n\nIf all the above conditions are satisfied, the ms32_recover function will return a codex32 secret when its argument is the list of codex32 shares with each share represented as a list of integers representing the characters converted using the bech32 character table from BIP-0173. \n\nBECH32_INV = [\n 0, 1, 20, 24, 10, 8, 12, 29, 5, 11, 4, 9, 6, 28, 26, 31,\n 22, 18, 17, 23, 2, 25, 16, 19, 3, 21, 14, 30, 13, 7, 27, 15,\n]\n\ndef bech32_mul(a, b):\n res = 0\n for i in range(5):\n res ^= a if ((b >> i) & 1) else 0\n a *= 2\n a ^= 41 if (32 <= a) else 0\n return res\n\ndef bech32_lagrange(l, x):\n n = 1\n c = []\n for i in l:\n n = bech32_mul(n, i ^ x)\n m = 1\n for j in l:\n m = bech32_mul(m, (x if i == j else i) ^ j)\n c.append(m)\n return [bech32_mul(n, BECH32_INV[i]) for i in c]\n\ndef ms32_interpolate(l, x):\n w = bech32_lagrange([s[5] for s in l], x)\n res = []\n for i in range(len(l[0])):\n n = 0\n for j in range(len(l)):\n n ^= bech32_mul(w[j], l[j][i])\n res.append(n)\n return res\n\ndef ms32_recover(shares):\n return ms32_interpolate(shares, 16)\n\n\n===Generating Shares===\n\nIf we already have ''k'' valid codex32 strings such that:\n\n* All strings have the same threshold value ''k'', the same identifier, and the same length\n* All of the share index values are distinct\n\nThen we can derive additional shares with the ms32_interpolate function by passing it a list of exactly ''k'' of these codex32 strings, together with a fresh share index distinct from all of the existing share indexes.\nThe newly derived share will have the provided share index.\n\nOnce a user has generated ''n'' shares, they may discard the codex32 secret (if it exists).\nThe ''n'' shares form a ''k'' of ''n'' Shamir's secret sharing scheme of a codex32 secret.\n\nThere are two ways to create an initial set of ''k'' valid codex32 strings, depending on whether the user already has an existing secret to split.\n\n====For a fresh secret====\n\nIn the case that the user wishes to generate a fresh secret, the user generates random initial shares, as follows:", "category": "bips" }, { "instruction": "Hey, I need to set up Choose a 4 bech32 character identifier - what's the command line way to do that?", "input": "", "output": "#* We do not define how to choose the identifier, beyond noting that it SHOULD be distinct for every secret the user may need to disambiguate", "category": "bips" }, { "instruction": "What's the deal with ''k'' many times, generate a random share by: in Bitcoin? Explain it like I'm a friend.", "input": "", "output": "## Take the next available letter from the bech32 alphabet, in alphabetical order, as a, c, d, ..., to be the share index\n## Set the first nine characters to be the prefix ms1, the threshold value ''t'', the 4-character identifier, and then the share index\n## Choose the next ceil(''bitlength / 5'') characters uniformly at random\n## Generate a valid checksum in accordance with the Checksum section, and append this to the resulting shares\n\nThe result will be ''k'' distinct shares, all with the same initial 8 characters, and a distinct share index as the 9th character.\n\nWith this set of ''k'' shares, new shares can be derived as discussed above. This process generates a fresh secret, whose value can be retrieved by running the recovery process on any ''k'' of these shares.\n\n====For an existing secret====\n\nBefore generating shares for an existing secret, it first must be codex32-encoded.\nThe conversion process consists of:", "category": "bips" }, { "instruction": "Can you show me the CLI commands for Choose a 4 bech32 character identifier?", "input": "", "output": "#* We do not define how to choose the identifier, beyond noting that it SHOULD be distinct for every set of shares the user may need to disambiguate", "category": "bips" }, { "instruction": "I'm stuck with Generate a valid checksum in accordance with the Checksum section - what should I check?", "input": "", "output": "Along with the codex32 secret, the user must generate ''k''-1 other codex32 shares, each with the same threshold value, the same identifier, and a distinct share index.\nThese shares should be generated as described in the \"fresh secret\" section.\n\nThe codex32 secret and the ''k''-1 codex32 shares form a set of ''k'' valid initial codex32 strings from which additional shares can be derived as described above.\n\n===Long codex32===\n\nThe 13 character checksum design only supports up to 80 data characters.\nExcluding the threshold, identifier and index characters, this limits the payload to 74 characters or 46 bytes.\nWhile this is enough to support the 32-byte advised size of BIP-0032 master seeds, BIP-0032 allows seeds to be up to 64 bytes in size.\nWe define a long codex32 format to support these longer seeds by defining an alternative checksum.\n\n\nMS32_LONG_CONST = 0x43381e570bf4798ab26\n\ndef ms32_long_polymod(values):\n GEN = [\n 0x3d59d273535ea62d897,\n 0x7a9becb6361c6c51507,\n 0x543f9b7e6c38d8a2a0e,\n 0x0c577eaeccf1990d13c,\n 0x1887f74f8dc71b10651,\n ]\n residue = 0x23181b3\n for v in values:\n b = (residue >> 70)\n residue = (residue & 0x3fffffffffffffffff) << 5 ^ v\n for i in range(5):\n residue ^= GEN[i] if ((b >> i) & 1) else 0\n return residue\n\ndef ms32_verify_long_checksum(data):\n return ms32_long_polymod(data) == MS32_LONG_CONST\n\ndef ms32_create_long_checksum(data):\n values = data\n polymod = ms32_long_polymod(values + [0] * 15) ^ MS32_LONG_CONST\n return [(polymod >> 5 * (14 - i)) & 31 for i in range(15)]\n\nThis implements a [https://en.wikipedia.org/wiki/BCH_code BCH code] that\nguarantees detection of '''any error affecting at most 8 characters'''\nand has less than a 3 in 1023 chance of failing to detect more\nrandom errors.\n\nA long codex32 string follows the same specification as a regular codex32 string with the following changes.\n\n* The payload is a sequence of between 75 and 103 bech32 characters.\n* The checksum consists of 15 bech32 characters as defined above.\n\nA codex32 string with a data part of 94 or 95 characters is never legal as a regular codex32 string is limited to 93 data characters and a long codex32 string is at least 96 data characters.\n\nGeneration of long shares and recovery of the long secret from long shares proceeds in exactly the same way as for regular shares with the ms32_interpolate function.\n\nThe long checksum is designed to be an error correcting code that can correct up to 4 character substitutions, up to 8 unreadable characters (called erasures), or up to 15 consecutive erasures.\nAs with regular checksums we do not specify how an implementation should implement error correction, and all our recommendations for error correction of regular codex32 strings also apply to long codex32 strings.\n\n==Rationale==\n\nThis scheme is based on the observation that the Lagrange interpolation of valid codewords in a BCH code will always be a valid codeword.\nThis means that derived shares will always have valid checksum, and a sufficient threshold of shares with valid checksums will derive a secret with a valid checksum.\n\nThe header system is also compatible with Lagrange interpolation, meaning all derived shares will have the same identifier and will have the appropriate share index.\nThis fact allows the header data to be covered by the checksum.\n\nThe checksum size and identifier size have been chosen so that the encoding of 128-bit master seeds and shares fit within 48 characters.\nThis is a standard size for many common seed storage formats, which has been popularized by the 12 four-letter word format of the BIP-0039 mnemonic.\n\nThe 13 character checksum is adequate to correct 4 errors in up to 93 characters (80 characters of data and 13 characters of the checksum).\nWe can correct up to 8 erasures (errors with known locations), and up to 13 consecutive errors (burst errors).\nBeyond that, our code is guaranteed to detect up to 8 errors.\nMore generally, any number of random errors will be detected with overwhelming (1 - 2^65) probability. However, the checksum does not protect against maliciously constructed errors.\nThese parameters are slightly better than those of the checksum used in SLIP-0039.\n\nFor 256-bit seeds and shares our strings are 74 characters, which fits into the 96 character format of the 24 four-letter word format of the BIP-0039 mnemonic, with plenty of room to spare.\n\nA longer checksum is needed to support up to 512-bit seeds, the longest seed length specified in BIP-0032, as the 13 character checksum isn't adequate for more than 80 data characters.\nWhile we could use the 15 character checksum for both cases, we prefer to keep the strings as short as possible for the more common cases of 128-bit and 256-bit master seeds.\nWe only guarantee to correct 4 characters no matter how long the string is.\nLonger strings mean more chances for transcription errors, so shorter strings are better.\n\nThe longest data part using the regular 13 character checksum is 93 characters and corresponds to a 368-bit secret.\nAt this length, the prefix MS1 is not covered by the checksum.\nThis is acceptable because the checksum scheme itself requires you to know that the MS1 prefix is being used in the first place.\nIf the prefix is damaged and a user is guessing that the data might be using this scheme, then the user can enter the available data explicitly using the suspected MS1 prefix.\n\n===Not BIP-0039 Entropy===\n\nInstead of encoding a BIP-0032 master seed, an alternative would be to encode BIP-0039 entropy.\nHowever this alternative approach is fraught with difficulties.\n\nOn approach would be to encode the BIP-0039 entropy along with the BIP-0039 checksum data.\nThis data can directly be recovered from the BIP-0039 mnemonic, and the process can be reversed if one knows the target language.\nHowever, for a 128-bit seed, there is a 4 bit checksum yielding 132 bits of data that needs to be encoded.\nThis exceeds the 130-bits of room that we have for storing 128 bit seeds.\nWe would have to compromise on the 48 character size, or the size of the headers, or the size of the checksum in order to add room for an additional character of data.\n\nThis approach would also eliminate our short cut generation of a fresh master secret from generating random shares.\nOne would be required to first generate BIP-0039 entropy, and then add a BIP-0039 checksum, before adding a Codex32 checksum and then generate other shares.\nIn particular, this process could no longer be performed by hand since it is effectively impossible to hand compute a BIP-0039 checksum.\n\nAn alternative approach is to discard the BIP-0039 checksum, since it is inadequate for error correction anyways, and rely on the Codex32 checksum.\nHowever, this approach ends up eliminating the benefits of BIP-0039 compatibility.\nWhile it is now possible to hand generate fresh shares, it is impossible to recover compatible BIP-0039 words by hand because, again, the BIP-0039 checksum is not hand computable.\nThe only way of generating the compatible BIP-0039 mnemonic is to use wallet software.\nBut if the wallet software is need to support this approach to decoding entropy, we may as well bypass all of the overhead of BIP-0039 and directly encode the entropy of a BIP-0032 master seed, which is what we do in our Codex32 proposal.\n\nBeyond the problems above, BIP-0039 does not define a single transformation from entropy to BIP-0032 master seed.\nInstead every different language has it own word list (or word lists) and each choice of word list yields a different transformation from entropy to master seed.\nWe would need to encode the choice of word list in our share's meta-data, which takes up even more room, and is difficult to specify due to the ever-evolving choice of word lists.\n\nAlternatively we could standardize on the choice of the English word list, something that is nearly a de facto standard, and simply be incompatible with BIP-0039 wallets of other languages.\nSuch a choice also risks users of BIP-0039 recovering their entropy from their language, encoding it in Codex32 and then failing to recover their wallet because the English word lists has replaced their language's word list.\n\nThe main advantage of this alternative approach would be that wallets could give users an option switch between backing up their entropy as a BIP-0039 mnemonic and in Codex32 format, but again, only if their language choice happens to be the English word list.\nIn practice, we do not expect users in switch back and forth between backup formats, and instead just generate a fresh master seed using Codex32.\n\nSeeing little value with BIP-0039 compatibility (English-only), all the difficulties with BIP-0039 language choice, not to mention the PBKDF2 overhead of using BIP-0039, we think it is best to abandon BIP-0039 and encode BIP-0032 master seeds directly.\nOur approach is semi-convertible with BIP-0039's 512-bit master seeds (in all languages, see Backwards Compatibility) and fully interconvertible with SLIP-39 encoded master seeds or any other encoding of BIP-0032 master seeds.\n\n==Backwards Compatibility==\n\ncodex32 is an alternative to BIP-0039 and SLIP-0039.\nIt is technically possible to derive the BIP32 master seed from seed words encoded in one of these schemes, and then to encode this seed in codex32.\nFor BIP-0039 this process is irreversible, since it involves hashing the original words.\nFurthermore, the resulting seed will be 512 bits long, which may be too large to be safely and conveniently handled.\n\nSLIP-0039 seed words can be reversibly converted to master seeds, so it is possible to interconvert between SLIP-0039 and codex32.\nHowever, SLIP-0039 '''shares''' cannot be converted to codex32 shares because the two schemes use a different underlying field.\n\nThe authors of this BIP do not recommend interconversion.\nInstead, users who wish to switch to codex32 should generate a fresh seed and sweep their coins.\n\n==Reference Implementation==\n\nOur [https://github.com/BlockstreamResearch/codex32 reference implementation repository] contains implementations in Rust and PostScript.\nThe inline code in this BIP text can be used as a Python reference.\n\n==Test Vectors==\n\n===Test vector 1===\n\nThis example shows the codex32 format, when used without splitting the secret into any shares.\nThe payload contains 26 bech32 characters, which corresponds to 130 bits. We truncate the last two bits in order to obtain a 128-bit master seed.\n\ncodex32 secret (bech32): ms10testsxxxxxxxxxxxxxxxxxxxxxxxxxx4nzvca9cmczlw\n\nMaster seed (hex): 318c6318c6318c6318c6318c6318c631\n\n* human-readable part: ms\n* separator: 1\n* k value: 0 (no secret splitting)\n* identifier: test\n* share index: s (the secret)\n* payload: xxxxxxxxxxxxxxxxxxxxxxxxxx\n* checksum: 4nzvca9cmczlw\n* master node xprv: xprv9s21ZrQH143K3taPNekMd9oV5K6szJ8ND7vVh6fxicRUMDcChr3bFFzuxY8qP3xFFBL6DWc2uEYCfBFZ2nFWbAqKPhtCLRjgv78EZJDEfpL\n\n===Test vector 2===\n\nThis example shows generating a new master seed using \"random\" shares, as well as deriving an additional share, using ''k''=2 and an identifier of NAME.\nAlthough codex32 strings are canonically all lowercase, it's also valid to use all uppercase.\n\nShare with index A: MS12NAMEA320ZYXWVUTSRQPNMLKJHGFEDCAXRPP870HKKQRM\n\nShare with index C: MS12NAMECACDEFGHJKLMNPQRSTUVWXYZ023FTR2GDZMPY6PN\n\n* Derived share with index D: MS12NAMEDLL4F8JLH4E5VDVULDLFXU2JHDNLSM97XVENRXEG\n* Recovered secret seed with index S: MS12NAMES6XQGUZTTXKEQNJSJZV4JV3NZ5K3KWGSPHUH6EVW\n* Master seed (hex): d1808e096b35b209ca12132b264662a5\n* master node xprv: xprv9s21ZrQH143K2NkobdHxXeyFDqE44nJYvzLFtsriatJNWMNKznGoGgW5UMTL4fyWtajnMYb5gEc2CgaKhmsKeskoi9eTimpRv2N11THhPTU\n\n===Test vector 3===\n\nThis example shows splitting an existing 128-bit master seed into \"random\" shares, using ''k''=3 and an identifier of cash.\nWe appended two zero bits in order to obtain 26 bech32 characters (130 bits of data) from the 128-bit master seed.\n\nMaster seed (hex): ffeeddccbbaa99887766554433221100\n\ncodex32-encoded master seed with index s: ms13cashsllhdmn9m42vcsamx24zrxgs3qqjzqud4m0d6nln\n\nShare with index a: ms13casha320zyxwvutsrqpnmlkjhgfedca2a8d0zehn8a0t\n\nShare with index c: ms13cashcacdefghjklmnpqrstuvwxyz023949xq35my48dr\n\n* Derived share with index d: ms13cashd0wsedstcdcts64cd7wvy4m90lm28w4ffupqs7rm\n* Derived share with index e: ms13casheekgpemxzshcrmqhaydlp6yhms3ws7320xyxsar9\n* Derived share with index f: ms13cashf8jh6sdrkpyrsp5ut94pj8ktehhw2hfvyrj48704\n* master node xprv: xprv9s21ZrQH143K266qUcrDyYJrSG7KA3A7sE5UHndYRkFzsPQ6xwUhEGK1rNuyyA57Vkc1Ma6a8boVqcKqGNximmAe9L65WsYNcNitKRPnABd\n\nAny three of the five shares among acdef can be used to recover the secret.\n\nNote that the choice to append two zero bits was arbitrary, and any of the following four codex32 secrets would have been valid choices.\nHowever, each choice would have resulted in a different set of derived shares.\n\n* ms13cashsllhdmn9m42vcsamx24zrxgs3qqjzqud4m0d6nln\n* ms13cashsllhdmn9m42vcsamx24zrxgs3qpte35dvzkjpt0r\n* ms13cashsllhdmn9m42vcsamx24zrxgs3qzfatvdwq5692k6\n* ms13cashsllhdmn9m42vcsamx24zrxgs3qrsx6ydhed97jx2\n\n===Test vector 4===\n\nThis example shows converting a 256-bit secret into a codex32 secret, without splitting the secret into any shares.\nWe appended four zero bits in order to obtain 52 bech32 characters (260 bits of data) from the 256-bit secret.\n\nMaster seed (hex): ffeeddccbbaa99887766554433221100ffeeddccbbaa99887766554433221100\n\n* codex32 secret: ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqqtum9pgv99ycma\n* master node xprv: xprv9s21ZrQH143K3s41UCWxXTsU4TRrhkpD1t21QJETan3hjo8DP5LFdFcB5eaFtV8x6Y9aZotQyP8KByUjgLTbXCUjfu2iosTbMv98g8EQoqr\n\nNote that the choice to append four zero bits was arbitrary, and any of the following sixteen codex32 secrets would have been valid:\n\n* ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqqtum9pgv99ycma\n* ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqpj82dp34u6lqtd\n* ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqzsrs4pnh7jmpj5\n* ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqrfcpap2w8dqezy\n* ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqy5tdvphn6znrf0\n* ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyq9dsuypw2ragmel\n* ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqx05xupvgp4v6qx\n* ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyq8k0h5p43c2hzsk\n* ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqgum7hplmjtr8ks\n* ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqf9q0lpxzt5clxq\n* ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyq28y48pyqfuu7le\n* ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqt7ly0paesr8x0f\n* ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqvrvg7pqydv5uyz\n* ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqd6hekpea5n0y5j\n* ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqwcnrwpmlkmt9dt\n* ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyq0pgjxpzx0ysaam\n\n===Test vector 5===\n\nThis example shows generating a new 512-bit master seed using \"random\" bech32 characters and appending a checksum.\nThe payload contains 103 bech32 characters, which corresponds to 515 bits. The last three bits are discarded when converting to a 512-bit master seed.\n\nThis is an example of a '''Long codex32''' string.\n\nk value (bech32): 0\n\nidentifier (bech32): 0C8V\n\npayload (bech32): M32ZXFGUHPCHTLUPZRY9X8GF2TVDW0S3JN54KHCE6MUA7LQPZYGSFJD6AN074RXVCEMLH8WU3TK925ACDEFGHJKLMNPQRSTUVWXY06F\n\n* checksum: HPV80UNDVARHRAK\n* codex32 secret: MS100C8VSM32ZXFGUHPCHTLUPZRY9X8GF2TVDW0S3JN54KHCE6MUA7LQPZYGSFJD6AN074RXVCEMLH8WU3TK925ACDEFGHJKLMNPQRSTUVWXY06FHPV80UNDVARHRAK\n* Master seed (hex): dc5423251cb87175ff8110c8531d0952d8d73e1194e95b5f19d6f9df7c01111104c9baecdfea8cccc677fb9ddc8aec5553b86e528bcadfdcc201c17c638c47e9\n* master node xprv: xprv9s21ZrQH143K4UYT4rP3TZVKKbmRVmfRqTx9mG2xCy2JYipZbkLV8rwvBXsUbEv9KQiUD7oED1Wyi9evZzUn2rqK9skRgPkNaAzyw3YrpJN\n\n===Invalid test vectors===\n\nThese examples have incorrect checksums.\n\n* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxve740yyge2ghq\n* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxve740yyge2ghp\n* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxxxlk3yepcstwr\n* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxx6pgnv7jnpcsp\n* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxxx0cpvr7n4geq\n* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxxxm5252y7d3lr\n* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxxrd9sukzl05ej\n* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxxxc55srw5jrm0\n* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxxxgc7rwhtudwc\n* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxx4gy22afwghvs\n* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxe8yfm0\n* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxvm597d\n* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxme084q0vpht7pe0\n* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxme084q0vpht7pew\n* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxqyadsp3nywm8a\n* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxzvg7ar4hgaejk\n* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxcznau0advgxqe\n* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxch3jrc6j5040j\n* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx52gxl6ppv40mcv\n* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx7g4g2nhhle8fk\n* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx63m45uj8ss4x8\n* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxy4r708q7kg65x\n\nThese examples use the wrong checksum for their given data sizes.\n\n* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxurfvwmdcmymdufv\n* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxcsyppjkd8lz4hx3\n* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxu6hwvl5p0l9xf3c\n* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxwqey9rfs6smenxa\n* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxv70wkzrjr4ntqet\n* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx3hmlrmpa4zl0v\n* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxrfggf88znkaup\n* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxpt7l4aycv9qzj\n* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxus27z9xtyxyw3\n* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxcwm4re8fs78vn\n\nThese examples have improper lengths.\nThey are either too short, too long, or would decode to byte sequence with an incomplete group greater than 4 bits.\n\n* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxw0a4c70rfefn4\n* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxk4pavy5n46nea\n* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxx9lrwar5zwng4w\n* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxr335l5tv88js3\n* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxvu7q9nz8p7dj68v\n* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxpq6k542scdxndq3\n* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxkmfw6jm270mz6ej\n* ms12fauxxxxxxxxxxxxxxxxxxxxxxxxxxzhddxw99w7xws\n* ms12fauxxxxxxxxxxxxxxxxxxxxxxxxxxxx42cux6um92rz\n* ms12fauxxxxxxxxxxxxxxxxxxxxxxxxxxxxxarja5kqukdhy9\n* ms12fauxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxky0ua3ha84qk8\n* ms12fauxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx9eheesxadh2n2n9\n* ms12fauxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx9llwmgesfulcj2z\n* ms12fauxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx02ev7caq6n9fgkf\n\nThis example uses a \"0\" threshold with a non-\"s\" index\n\n* ms10fauxxxxxxxxxxxxxxxxxxxxxxxxxxxx0z26tfn0ulw3p\n\nThis example has a threshold that is not a digit.\n\n* ms1fauxxxxxxxxxxxxxxxxxxxxxxxxxxxxxda3kr3s0s2swg\n\nThese examples do not begin with the required \"ms\" or \"MS\" prefix and/or are missing the \"1\" separator.\n\n* 0fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxuqxkk05lyf3x2\n* 10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxuqxkk05lyf3x2\n* ms0fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxuqxkk05lyf3x2\n* m10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxuqxkk05lyf3x2\n* s10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxuqxkk05lyf3x2\n* 0fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxhkd4f70m8lgws\n* 10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxhkd4f70m8lgws\n* m10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxx8t28z74x8hs4l\n* s10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxh9d0fhnvfyx3x\n\nThese examples all incorrectly mix upper and lower case characters.\n\n* Ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxuqxkk05lyf3x2\n* mS10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxuqxkk05lyf3x2\n* MS10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxuqxkk05lyf3x2\n* ms10FAUXsxxxxxxxxxxxxxxxxxxxxxxxxxxuqxkk05lyf3x2\n* ms10fauxSxxxxxxxxxxxxxxxxxxxxxxxxxxuqxkk05lyf3x2\n* ms10fauxsXXXXXXXXXXXXXXXXXXXXXXXXXXuqxkk05lyf3x2\n* ms10fauxsxxxxxxxxxxxxxxxxxxxxxxxxxxUQXKK05LYF3X2\n\n==Appendix==\n\n===Mathematical Companion===\n\nBelow we use the bech32 character set to denote values in GF[32].\nIn bech32, the letter Q denotes zero and the letter P denotes one.\nThe digits 0 and 2 through 9 do ''not'' denote their numeric values.\nThey are simply elements of GF[32].\n\nThe generating polynomial for our BCH code is as follows.\n\nWe extend GF[32] to GF[1024] by adjoining a primitive cube root of unity, ζ, satisfying ζ^2 = ζ + P.\n\nWe select β := G ζ which has order 93, and construct the product (x - β^i) for i in {17, 20, 46, 49, 52, 77, 78, 79, 80, 81, 82, 83, 84}.\nThe resulting polynomial is our generating polynomial for our 13 character checksum:\n\n x^13 + E x^12 + M x^11 + 3 x^10 + G x^9 + Q x^8 + E x^7 + E x^6 + E x^5 + L x^4 + M x^3 + C x^2 + S x + S\n\nFor our long checksum, we select γ := E + X ζ, which has order 1023, and construct the product (x - γ^i) for i in {32, 64, 96, 895, 927, 959, 991, 1019, 1020, 1021, 1022, 1023, 1024, 1025, 1026}.\nThe resulting polynomial is our generating polynomial for our 15 character checksum for long strings:\n\n x^15 + 0 x^14 + 2 x^13 + E x^12 + 6 x^11 + F x^10 + E x^9 + 4 x^8 + X x^7 + H x^6 + 4 x^5 + X x^4 + 9 x^3 + K x^2 + Y x^1 + H\n\n(Reminder: the character 0 does ''not'' denote the zero of the field.)", "category": "bips" }, { "instruction": "How do I troubleshoot 
 issues?",
    "input": "",
    "output": "BIP: 137\n  Layer: Applications\n  Title: Signatures of Messages using Private Keys\n  Authors: Christopher Gilliard \n  Status: Deployed\n  Type: Specification\n  Assigned: 2019-02-16\n  License: BSD-2-Clause\n
\n\n==Abstract==\n\nThis document describes a signature format for signing messages with Bitcoin private keys.\n\nThe specification is intended to describe the standard for signatures of messages that can be signed and verified between different clients that exist in the field today. Note: that a new signature format has been defined which has a number of advantages over this BIP, but to be backwards compatible with existing implementations this BIP will be useful. See BIP 322 [1] for full details on the new signature scheme.\n\nOne of the key problems in this area is that there are several different types of Bitcoin addresses and without introducing specific standards it is unclear which type of address format is being used. See [2]. This BIP will attempt to address these issues and define a clear and concise format for Bitcoin signatures.\n\n==Copyright==\n\nThis BIP is licensed under the 2-clause BSD license.\n\n==Motivation==\n\nSince Bitcoin private keys can not only be used to sign Bitcoin transactions, but also any other message, it has become customary to use them to sign various messages for differing purposes. Some applications of signing messages with a Bitcoin private key are as follows: proof of funds for collateral, credit worthiness, entrance to events, airdrops, audits as well as other applications. While there was no BIP written for how to digitally sign messages with Bitcoin private keys with P2PKH addresses it is a fairly well understood process, however with the introduction of Segwit (both in the form of P2SH and bech32) addresses, it is unclear how to distinguish a P2PKH, P2SH, or bech32 address from one another. This BIP proposes a standard signature format that will allow clients to distinguish between the different address formats.\n\n==Specification==\n\n===Background on ECDSA Signatures===\n\n(For readers who already understand how ECDSA signatures work, you can skip this section as this is only intended as background information.)\nElliptic Curve Digital Signature Algorithm or ECDSA is a cryptographic algorithm used by Bitcoin to ensure that funds can only be spent by their rightful owners.\n\nA few concepts related to ECDSA:\n\nprivate key: A secret number, known only to the person that generated it. A private key is essentially a randomly generated number. In Bitcoin, someone with the private key that corresponds to funds on the block chain can spend the funds. In Bitcoin, a private key is a single unsigned 256 bit integer (32 bytes).\n\npublic key: A number that corresponds to a private key, but does not need to be kept secret. A public key can be calculated from a private key, but not vice versa. A public key can be used to determine if a signature is genuine (in other words, produced with the proper key) without requiring the private key to be divulged. In Bitcoin, public keys are either compressed or uncompressed. Compressed public keys are 33 bytes, consisting of a prefix either 0x02 or 0x03, and a 256-bit integer called x. The older uncompressed keys are 65 bytes, consisting of constant prefix (0x04), followed by two 256-bit integers called x and y (2 * 32 bytes). The prefix of a compressed key allows for the y value to be derived from the x value.\n\nsignature: A number that proves that a signing operation took place. A signature is mathematically generated from a hash of something to be signed, plus a private key. The signature itself is two numbers known as r and s. With the public key, a mathematical algorithm can be used on the signature to determine that it was originally produced from the hash and the private key, without needing to know the private key. Signatures are either 73, 72, or 71 bytes long, with probabilities approximately 25%, 50% and 25% respectively, although sizes even smaller than that are possible with exponentially decreasing probability. Source [3].\n\n===Conventions with signatures used in Bitcoin===\n\nBitcoin signatures have the r and s values mentioned above, and a header. The header is a single byte and the r and s are each 32 bytes so a signature's size is 65 bytes. The header is used to specify information about the signature. It can be thought of as a bitmask with each bit in this byte having a meaning. The serialization format of a Bitcoin signature is as follows:\n\n[1 byte of header data][32 bytes for r value][32 bytes for s value]\n\nThe header byte has a few components to it. First, it stores something known as the recId. This value is stored in the least significant 2 bits of the header. If the header is between a value of 31 and 34, this indicates that it is a compressed address. If the header value is between 35 and 38 inclusive, it is a p2sh segwit address. If the header value is between 39 and 42, it is a bech32 address.\n\n===Procedure for signing/verifying a signature===\n\nAs noted above the signature is composed of three components, the header, r and s values. r/s can be computed with standard ECDSA library functions. Part of the header includes something called a recId. This is part of every ECDSA signature and should be generated by the ECDSA library. The recId is a number between 0 and 3 inclusive. The header is the recId plus a constant which indicates what type of Bitcoin address this is. For P2PKH address using an uncompressed public key this value is 27. For P2PKH address using compressed public key this value is 31. For P2SH-P2WPKH this value is 35 and for P2WPKH (version 0 witness) address this value is 39. So, you have the following ranges:\n* 27-30: P2PKH uncompressed\n* 31-34: P2PKH compressed\n* 35-38: Segwit P2SH\n* 39-42: Segwit Bech32\n\nTo verify a signature, the recId is obtained by subtracting this constant from the header value.\n\n===Sample Code for processing a signature===\n\nNote: this code is a modification of the BitcoinJ code which is written in java.\n\n public static ECKey signedMessageToKey(String message, String signatureBase64) throws SignatureException {\n byte[] signatureEncoded;\n try {\n signatureEncoded = Base64.decode(signatureBase64);\n } catch (RuntimeException e) {\n // This is what you get back from Bouncy Castle if base64 doesn't decode :(\n throw new SignatureException(\"Could not decode base64\", e);\n }\n // Parse the signature bytes into r/s and the selector value.\n if (signatureEncoded.length < 65)\n throw new SignatureException(\"Signature truncated, expected 65 bytes and got \" + signatureEncoded.length);\n int header = signatureEncoded[0] & 0xFF;\n // The header byte: 0x1B = first key with even y, 0x1C = first key with odd y,\n // 0x1D = second key with even y, 0x1E = second key with odd y\n if (header < 27 || header > 42)\n throw new SignatureException(\"Header byte out of range: \" + header);\n BigInteger r = new BigInteger(1, Arrays.copyOfRange(signatureEncoded, 1, 33));\n BigInteger s = new BigInteger(1, Arrays.copyOfRange(signatureEncoded, 33, 65));\n ECDSASignature sig = new ECDSASignature(r, s);\n byte[] messageBytes = formatMessageForSigning(message);\n // Note that the C++ code doesn't actually seem to specify any character encoding. Presumably it's whatever\n // JSON-SPIRIT hands back. Assume UTF-8 for now.\n Sha256Hash messageHash = Sha256Hash.twiceOf(messageBytes);\n boolean compressed = false;\n // this section is added to support new signature types\n if(header>= 39) // this is a bech32 signature\n {\n header -= 12;\n compressed = true;\n } // this is a segwit p2sh signature\n else if(header >= 35)\n {\n header -= 8;\n compressed = true;\n } // this is a compressed key signature\n else if (header >= 31) {\n compressed = true;\n header -= 4;\n }\n int recId = header - 27;\n ECKey key = ECKey.recoverFromSignature(recId, sig, messageHash, compressed);\n if (key == null)\n throw new SignatureException(\"Could not recover public key from signature\");\n return key;\n }\n\n==Backwards Compatibility==\n\nSince this format includes P2PKH keys, it is backwards compatible, but keep in mind some software has checks for ranges of headers and will report the newer segwit header types as errors.\n\n==Implications==\n\nMessage signing is an important use case and potentially underused due to the fact that, up until now, there has not been a formal specification for how wallets can sign messages using Bitcoin private keys. Bitcoin wallets should be interoperable and use the same conventions for determining a signature's validity. This BIP can also be updated as new signature formats emerge.\n\n==Acknowledgements==\n\n* Konstantin Bay - review\n* Holly Casaletto - review\n* James Bryrer - review\n\nNote that the background on ECDSA signatures was taken from en.bitcoin.it and code sample modified from BitcoinJ.\n\n==References==\n\n[1] - https://github.com/bitcoin/bips/blob/master/bip-0322.mediawiki\n\n[2] - https://github.com/bitcoin/bitcoin/issues/10542\n\n[3] - https://en.bitcoin.it/wiki/Elliptic_Curve_Digital_Signature_Algorithm", "category": "bips" }, { "instruction": "What are the best practices for 
?",
    "input": "",
    "output": "BIP: 75\n  Layer: Applications\n  Title: Out of Band Address Exchange using Payment Protocol Encryption\n  Authors: Justin Newton \n           Matt David \n           Aaron Voisine \n           James MacWhyte \n  Comments-Summary: Recommended for implementation (one person)\n  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0075\n  Status: Deployed\n  Type: Specification\n  Assigned: 2015-11-20\n  License: CC-BY-4.0\n
\n\n==Abstract==\n\nThis BIP is an extension to BIP 70 that provides two enhancements to the existing Payment Protocol.", "category": "bips" }, { "instruction": "Walk me through setting up It encrypts the PaymentRequest that is returned, before handing it off to the SSL/TLS layer to prevent man in the middle viewing of the Payment Request details. step by step", "input": "", "output": "The key words \"MUST\", \"MUST NOT\", \"REQUIRED\", \"SHALL\", \"SHALL NOT\", \"SHOULD\", \"SHOULD NOT\", \"RECOMMENDED\", \"MAY\", and\n\"OPTIONAL\" in this document are to be interpreted as described in RFC 2119.\n\n==Copyright==\n\n\n\nThis work is licensed under a [[http://creativecommons.org/licenses/by/4.0/|Creative Commons Attribution 4.0 International License]].\n\n==Definitions==\n{| class=\"wikitable\"\n| Sender || Entity wishing to transfer value that they control\n|-\n| Receiver || Entity receiving a value transfer\n|}\n\n==Motivation==\n\nThe motivation for defining this extension to the [[bip-0070.mediawiki|BIP70]] Payment Protocol is to allow two parties to exchange payment information in a permissioned and encrypted way, such that wallet address communication can become a more automated process. This extension also expands the types of PKI (public-key infrastructure) data that is supported, and allows it to be shared by both parties (with [[bip-0070.mediawiki|BIP70]], only the receiver could provide PKI information). This allows for automated creation of off-blockchain transaction logs that are human readable, now including information about the sender and not just the recipient.\n\nThe motivation for this extension to [[bip-0070.mediawiki|BIP70]] is threefold:", "category": "bips" }, { "instruction": "What commands would you run to work with Allow a sender of funds the option of sharing their identity with the receiver. This information could then be used to:?", "input": "", "output": "#* Make Bitcoin logs (wallet transaction history) more human readable\n#* Give the user the ability to decide whether or not they share their Bitcoin address and other payment details when requested\n#* Allow for an open standards based way for businesses to keep verifiable records of their financial transactions, to better meet the needs of accounting practices or other reporting and statutory requirements\n#* Automate the active exchange of payment addresses, so static addresses and BIP32 X-Pubs can be avoided to maintain privacy and convenience\n\nIn short we wanted to make Bitcoin more human, while at the same time improving transaction privacy.\n\n==Example Use Cases==\n\n1. Address Book\n\nA Bitcoin wallet developer would like to offer the ability to store an \"address book\" of payees, so users could send multiple payments to known entities without having to request an address every time. Static addresses compromise privacy, and address reuse is considered a security risk. BIP32 X-Pubs allow the generation of unique addresses, but watching an X-Pub chain for each person you wish to receive funds from is too resource-intensive for mobile applications, and there is always a risk of unknowingly sending funds to an X-Pub address after the owner has lost access to the corresponding private key.\n\nWith this BIP, Bitcoin wallets could maintain an \"address book\" that only needs to store each payee's public key. Adding an entry to one's address book could be done by using a Wallet Name, scanning a QR code, sending a URI through a text message or e-mail, or searching a public repository. When the user wishes to make a payment, their wallet would do all the work in the background to communicate with the payee's wallet to receive a unique payment address. If the payee's wallet has been lost, replaced, or destroyed, no communication will be possible, and the sending of funds to a \"dead\" address is prevented.\n\n2. Individual Permissioned Address Release\n\nA Bitcoin wallet developer would like to allow users to view a potential sending party's identifying information before deciding whether or not to share payment information with them. Currently, [[bip-0070.mediawiki|BIP70]] shares the receiver’s payment address and identity information with anyone who requests it.\n\nWith this BIP, Bitcoin wallets could use the sender’s identifying information to make a determination of whether or not to share their own information. This gives the receiving party more control over who receives their payment and identity information. Additionally, this could be used to automatically provide new payment addresses to whitelisted senders, or to protect users’ privacy from unsolicited payment requests.\n\n3. Using Store & Forward Servers\n\nA Bitcoin wallet developer would like to use a public Store & Forward service for an asynchronous address exchange. This is a common case for mobile and offline wallets.\n\nWith this BIP, returned payment information is encrypted with an ECDH-computed shared key before sending to a Store & Forward service. In this case, a successful attack against a Store & Forward service would not be able to read or modify wallet address or payment information, only delete encrypted messages.\n\n==Modifying BIP70 pki_type==\nThis BIP adds additional possible values for the pki_type variable in the PaymentRequest message. The complete list is now as follows:\n\n{| class=\"wikitable\"\n! pki_type !! Description\n|-\n| x509+sha256 || A x.509 certificate, as described in BIP70\n|-\n| pgp+sha256 || An [[https://en.wikipedia.org/wiki/Pretty_Good_Privacy#OpenPGP|OpenPGP]] certificate\n|-\n| ecdsa+sha256 || A [[https://en.bitcoin.it/wiki/Secp256k1|secp256k1]] [[https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm|ECDSA]] public key\n|}\n\n'''NOTE''': Although SHA1 was supported in BIP70, it has been deprecated and BIP75 only supports SHA256. The hashing algorithm is still specified in the values listed above for forward and backwards compatibility.\n\n==New Messages==\nUpdated [/bip-0075/paymentrequest.proto paymentrequest.proto] contains the existing PaymentRequest Protocol Buffer messages as well as the messages newly defined in this BIP.\n\n'''NOTE''': Public keys from both parties must be known to each other in order to facilitate encrypted communication. Although including both public keys in every message may get redundant, it provides the most flexibility as each message is completely self-contained.\n\n===InvoiceRequest===\nThe '''InvoiceRequest''' message allows a Sender to send information to the Receiver such that the Receiver can create and return a PaymentRequest.\n\n
\nmessage InvoiceRequest {\n        required bytes  sender_public_key = 1;\n        optional uint64 amount = 2 [default = 0];\n        optional string pki_type = 3 [default = \"none\"];\n        optional bytes  pki_data = 4;\n        optional string memo = 5;\n        optional string notification_url = 6;\n        optional bytes  signature = 7;\n}\n
\n\n{| class=\"wikitable\"\n! Field Name !! Description\n|-\n| sender_public_key || Sender's SEC-encoded EC public key\n|-\n| amount || amount is integer-number-of-satoshis (default: 0)\n|-\n| pki_type || none / x509+sha256 / pgp+sha256 / ecdsa+sha256 (default: \"none\")\n|-\n| pki_data || Depends on pki_type\n|-\n| memo || Human-readable description of invoice request for the receiver\n|-\n| notification_url || Secure (usually TLS-protected HTTP) location where an [[#encryptedprotocolmessage|EncryptedProtocolMessage]] SHOULD be sent when ready\n|-\n| signature || PKI-dependent signature\n|}\n\n===ProtocolMessageType Enum===\nThis enum is used in the newly defined [[#protocolmessage|ProtocolMessage]] and [[#encryptedprotocolmessage|EncryptedProtocolMessage]] messages to define the serialized message type. The '''ProtocolMessageType''' enum is defined in an extensible way to allow for new message type additions to the Payment Protocol.\n
\nenum ProtocolMessageType {\n    UNKNOWN_MESSAGE_TYPE = 0;\n    INVOICE_REQUEST = 1;\n    PAYMENT_REQUEST = 2;\n    PAYMENT = 3;\n    PAYMENT_ACK = 4;\n}\n
\n\n===ProtocolMessage===\nThe '''ProtocolMessage''' message is an encapsulating wrapper for any Payment Protocol message. It allows two-way, non-encrypted communication of Payment Protocol messages. The message also includes a status code and a status message that is used for error communication such that the protocol does not rely on transport-layer error handling.\n
\nmessage ProtocolMessage {\n    required uint64 version = 1\n    required uint64 status_code = 2;\n    required ProtocolMessageType message_type = 3;\n    required bytes serialized_message = 4;\n    optional string status_message = 5;\n    required bytes identifier = 6;\n}\n
\n\n{| class=\"wikitable\"\n! Field Name !! Description\n|-\n|version || Protocol version number (Currently 1)\n|-\n|status_code || Payment Protocol Status Code\n|-\n|message_type || Message Type of serialized_message\n|-\n|serialized_message || Serialized Payment Protocol Message\n|-\n|status_message || Human-readable Payment Protocol status message\n|-\n|identifier || Unique key to identify this entire exchange on the server. Default value SHOULD be SHA256(Serialized Initial InvoiceRequest + Current Epoch Time in Seconds as a String)\n|}\n\n===Versioning===\nThis BIP introduces version 1 of this protocol. All messages sent using these base requirements MUST use a value of 1 for the version number. Any future BIPs that modify this protocol (encryption schemes, etc) MUST each increment the version number by 1.\n\nWhen initiating communication, the version field of the first message SHOULD be set to the highest version number the sender understands. All clients MUST be able to understand all version numbers less than the highest number they support. If a client receives a message with a version number higher than they understand, they MUST send the message back to the sender with a status code of 101 (\"version too high\") and the version field set to the highest version number the recipient understands. The sender must then resend the original message using the same version number returned by the recipient or abort.\n\n===EncryptedProtocolMessage===\nThe '''EncryptedProtocolMessage''' message is an encapsulating wrapper for any Payment Protocol message. It allows two-way, authenticated and encrypted communication of Payment Protocol messages in order to keep their contents secret. The message also includes a status code and status message that is used for error communication such that the protocol does not rely on transport-layer error handling.\n
\nmessage EncryptedProtocolMessage {\n    required uint64 version = 1 [default = 1];\n    required uint64 status_code = 2 [default = 1];\n    required ProtocolMessageType message_type = 3;\n    required bytes encrypted_message = 4;\n    required bytes receiver_public_key = 5;\n    required bytes sender_public_key = 6;\n    required uint64 nonce = 7;\n    required bytes identifier = 8;\n    optional string status_message = 9;\n    optional bytes signature = 10;\n}\n
\n{| class=\"wikitable\"\n! Field Name !! Description\n|-\n| version || Protocol version number\n|-\n| status_code || Payment Protocol Status Code\n|-\n| message_type || Message Type of Decrypted encrypted_message\n|-\n| encrypted_message || AES-256-GCM Encrypted (as defined in BIP75) Payment Protocol Message\n|-\n| receiver_public_key || Receiver's SEC-encoded EC Public Key\n|-\n| sender_public_key || Sender's SEC-encoded EC Public Key\n|-\n| nonce || Microseconds since epoch\n|-\n| identifier || Unique key to identify this entire exchange on the server. Default value SHOULD be SHA256(Serialized Initial InvoiceRequest + Current Epoch Time in Seconds as a String)\n|-\n| status_message || Human-readable Payment Protocol status message\n|-\n| signature || DER-encoded Signature over the full EncryptedProtocolMessage with EC Key Belonging to Sender / Receiver, respectively\n|}\n\n==Payment Protocol Process with InvoiceRequests==\nThe full process overview for using '''InvoiceRequests''' in the Payment Protocol is defined below.\n

\nAll Payment Protocol messages MUST be encapsulated in either a [[#protocolmessage|ProtocolMessage]] or [[#encryptedprotocolmessage|EncryptedProtocolMessage]]. Once the process begins using [[#encryptedprotocolmessage|EncryptedProtocolMessage]] messages, all subsequent communications MUST use [[#encryptedprotocolmessage|EncryptedProtocolMessages]].\n

\nAll Payment Protocol messages SHOULD be communicated using [[#encryptedprotocolmessage|EncryptedProtocolMessage]] encapsulating messages with the exception that an [[#invoicerequest|InvoiceRequest]] MAY be communicated using the [[#protocolmessage|ProtocolMessage]] if the receiver's public key is unknown.\n

\n\nThe process of creating encrypted Payment Protocol messages is enumerated in [[#sending-encrypted-payment-protocol-messages-using-encryptedprotocolmessages|Sending Encrypted Payment Protocol Messages using EncryptedProtocolMessages]], and the process of decrypting encrypted messages can be found under [[#validating-and-decrypting-payment-protocol-messages-using-encryptedprotocolmessages|Validating and Decrypting Payment Protocol Messages using EncryptedProtocolMessages]].\n\nA standard exchange from start to finish would look like the following:", "category": "bips" }, { "instruction": "I want to understand The PaymentRequest is processed according to [[bip-0070.mediawiki|BIP70]], including optional Payment and PaymentACK messages encapsulated in EncryptedProtocolMessage messages. from a technical perspective", "input": "", "output": "'''NOTE:''' See [[#initial-public-key-retrieval-for-invoicerequest-encryption|Initial Public Key Retrieval for InvoiceRequest Encryption]] for possible options to retrieve Receiver's public key.\n\n\"Flow\n\n==Message Interaction Details==\n\n===HTTP Content Types for New Message Types===\nWhen communicated via '''HTTP''', the listed messages MUST be transmitted via TLS-protected HTTP using the appropriate Content-Type header as defined here per message:\n
\n{| class=\"wikitable\"\n! Message Type !! Content Type\n|-\n| ProtocolMessage || application/bitcoin-paymentprotocol-message\n|-\n| EncryptedProtocolMessage || application/bitcoin-encrypted-paymentprotocol-message\n|}\n\n===Payment Protocol Status Communication===\n\nEvery [[#protocolmessage|ProtocolMessage]] or [[#encryptedprotocolmessage|EncryptedProtocolMessage]] MUST include a status code which conveys information about the last message received, if any (for the first message sent, use a status of 1 \"OK\" even though there was no previous message). In the case of an error that causes the Payment Protocol process to be stopped or requires that message be retried, a ProtocolMessage or EncryptedProtocolMessage SHOULD be returned by the party generating the error. The content of the message MUST contain the same '''serialized_message''' or '''encrypted_message''' and identifier (if present) and MUST have the status_code set appropriately.\n

\nThe status_message value SHOULD be set with a human readable explanation of the status code.\n\n====Payment Protocol Status Codes====\n{| class=\"wikitable\"\n! Status Code !! Description\n|-\n| 1 || OK\n|-\n| 2 || Cancel\n|-\n| 100 || General / Unknown Error\n|-\n| 101 || Version Too High\n|-\n| 102 || Authentication Failed\n|-\n| 103 || Encrypted Message Required\n|-\n| 200 || Amount Too High\n|-\n| 201 || Amount Too Low\n|-\n| 202 || Amount Invalid\n|-\n| 203 || Payment Does Not Meet PaymentRequest Requirements\n|-\n| 300 || Certificate Required\n|-\n| 301 || Certificate Expired\n|-\n| 302 || Certificate Invalid for Transaction\n|-\n| 303 || Certificate Revoked\n|-\n| 304 || Certificate Not Well Rooted\n|-\n|}\n\n+==Canceling A Message==+\nIf a participant to a transaction would like to inform the other party that a previous message should be canceled, they can send the same message with a status code of 2 (\"Cancel\") and, where applicable, an updated nonce. How recipients make use of the \"Cancel\" message is up to developers. For example, wallet developers may want to offer users the ability to cancel payment requests they have sent to other users, and have that change reflected in the recipient's UI. Developers using the non-encrypted ProtocolMessage may want to ignore \"Cancel\" messages, as it may be difficult to authenticate that the message originated from the same user.\n\n===Transport Layer Communication Errors===\nCommunication errors MUST be communicated to the party that initiated the communication via the communication layer's existing error messaging facilities. In the case of TLS-protected HTTP, this SHOULD be done through standard HTTP Status Code messaging ([https://tools.ietf.org/html/rfc7231 RFC 7231 Section 6]).\n\n==Extended Payment Protocol Process Details==\nThis BIP extends the Payment Protocol as defined in [[bip-0070.mediawiki|BIP70]].\n\nFor the following we assume the Sender already knows the Receiver's public key, and the exchange is being facilitated by a Store & Forward server which requires valid signatures for authentication.\n\n'''nonce''' MUST be set to a non-repeating number '''and''' MUST be chosen by the encryptor. The current epoch time in microseconds SHOULD be used, unless the creating device doesn't have access to a RTC (in the case of a smart card, for example). The service receiving the message containing the '''nonce''' MAY use whatever method to make sure that the '''nonce''' is never repeated.\n\n===InvoiceRequest Message Creation===\n* Create an [[#invoicerequest|InvoiceRequest]] message\n* '''sender_public_key''' MUST be set to the public key of an EC keypair\n* '''amount''' is optional. If the amount is not specified by the [[#invoicerequest|InvoiceRequest]], the Receiver MAY specify the amount in the returned PaymentRequest. If an amount is specified by the [[#invoicerequest|InvoiceRequest]] and a PaymentRequest cannot be generated for that amount, the [[#invoicerequest|InvoiceRequest]] SHOULD return the same [[#invoicerequest|InvoiceRequest]] in a [[#protocolmessage|ProtocolMessage]] or [[#encryptedprotocolmessage|EncryptedProtocolMessage]] with the status_code and status_message fields set appropriately.\n* '''memo''' is optional. This MAY be set to a human readable description of the InvoiceRequest\n* Set '''notification_url''' to URL that the Receiver will submit completed PaymentRequest (encapsulated in an [[#encryptedprotocolmessage|EncryptedProtocolMessage]]) to\n* If NOT including certificate, set '''pki_type''' to \"none\"\n* If including certificate:\n** Set '''pki_type''' to \"x509+sha256\"\n** Set '''pki_data''' as it would be set in BIP-0070 ([https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki#Certificates Certificates])\n** Sign [[#invoicerequest|InvoiceRequest]] with signature = \"\" using the X509 Certificate's private key\n** Set '''signature''' value to the computed signature\n\n===InvoiceRequest Validation===\n* Validate '''sender_public_key''' is a valid EC public key\n* Validate '''notification_url''', if set, contains characters deemed valid for a URL (avoiding XSS related characters, etc).\n* If '''pki_type''' is None, [[#invoicerequest|InvoiceRequest]] is VALID\n* If '''pki_type''' is x509+sha256 and '''signature''' is valid for the serialized [[#invoicerequest|InvoiceRequest]] where signature is set to \"\", [[#invoicerequest|InvoiceRequest]] is VALID\n\n===Sending Encrypted Payment Protocol Messages using EncryptedProtocolMessages===\n* Encrypt the serialized Payment Protocol message using AES-256-GCM setup as described in [[#ecdh-point-generation-and-aes256-gcm-mode-setup|ECDH Point Generation and AES-256 (GCM Mode) Setup]]\n* Create [[#encryptedprotocolmessage|EncryptedProtocolMessage]] message\n* Set '''encrypted_message''' to be the encrypted value of the Payment Protocol message\n* '''version''' SHOULD be set to the highest version number the client understands (currently 1)\n* '''sender_public_key''' MUST be set to the public key of the Sender's EC keypair\n* '''receiver_public_key''' MUST be set to the public key of the Receiver's EC keypair\n* '''nonce''' MUST be set to the nonce used in the AES-256-GCM encryption operation\n* Set '''identifier''' to the identifier value received in the originating InvoiceRequest's ProtocolMessage or EncryptedProtocolMessage wrapper message\n* Set '''signature''' to \"\"\n* Sign the serialized [[#encryptedprotocolmessage|EncryptedProtocolMessage]] message with the communicating party's EC public key\n* Set '''signature''' to the result of the signature operation above\n\n'''SIGNATURE NOTE:''' [[#encryptedprotocolmessage|EncryptedProtocolMessage]] messages are signed with the public keys of the party transmitting the message. This allows a Store & Forward server or other transmission system to prevent spam or other abuses. For those who are privacy conscious and don't want the server to track the interactions between two public keys, the Sender can generate a new public key for each interaction to keep their identity anonymous.\n\n===Validating and Decrypting Payment Protocol Messages using EncryptedProtocolMessages===\n* The '''nonce''' MUST not be repeated. The service receiving the [[#encryptedprotocolmessage|EncryptedProtocolMessage]] MAY use whatever method to make sure that the nonce is never repeated.\n* Decrypt the serialized Payment Protocol message using AES-256-GCM setup as described in [[#ecdh-point-generation-and-aes256-gcm-mode-setup|ECDH Point Generation and AES-256 (GCM Mode) Setup]]\n* Deserialize the serialized Payment Protocol message\n\n===ECDH Point Generation and AES-256 (GCM Mode) Setup===\n'''NOTE''': AES-256-GCM is used because it provides authenticated encryption facilities, thus negating the need for a separate message hash for authentication.\n\n* Generate the '''secret point''' using [https://en.wikipedia.org/wiki/Elliptic_curve_Diffie–Hellman ECDH] using the local entity's private key and the remote entity's public key as inputs\n* Initialize [http://csrc.nist.gov/publications/nistpubs/800-90A/SP800-90A.pdf HMAC_DRBG]\n** Use '''SHA512(secret point's X value in Big-Endian bytes)''' for Entropy\n** Use the given message's '''nonce''' field for Nonce, converted to byte string (Big Endian)\n\n* Initialize AES-256 in GCM Mode\n** Initialize HMAC_DRBG with Security Strength of 256 bits\n** Use HMAC_DRBG.GENERATE(32) as the Encryption Key (256 bits)\n** Use HMAC_DRBG.GENERATE(12) as the Initialization Vector (IV) (96 bits)\n\n====AES-256 GCM Authentication Tag Use====\nThe 16 byte authentication tag resulting from the AES-GCM encrypt operation MUST be prefixed to the returned ciphertext. The decrypt operation will use the first 16 bytes of the ciphertext as the GCM authentication tag and the remainder of the ciphertext as the ciphertext in the decrypt operation.\n\n====AES-256 GCM Additional Authenticated Data====\nWhen either '''status_code''' OR '''status_message''' are present, the AES-256 GCM authenticated data used in both the encrypt and decrypt operations MUST be: STRING(status_code) || status_message. Otherwise, there is no additional authenticated data. This provides that, while not encrypted, the status_code and status_message are authenticated.\n\n===Initial Public Key Retrieval for InvoiceRequest Encryption===\nInitial public key retrieval for [[#invoicerequest|InvoiceRequest]] encryption via [[#encryptedprotocolmessage|EncryptedProtocolMessage]] encapsulation can be done in a number of ways including, but not limited to, the following:", "category": "bips" }, { "instruction": "Can you explain Bitcoin Operations Guide like we're having a beer and talking Bitcoin?", "input": "", "output": "# Wallet Name public key asset type resolution - DNSSEC-validated name resolution returns Base64 encoded DER-formatted EC public key via TXT Record [https://www.ietf.org/rfc/rfc5480.txt RFC 5480]", "category": "bips" }, { "instruction": "How would you explain Bitcoin Operations Guide to someone who knows Bitcoin basics?", "input": "", "output": "# Key Server lookup - Key Server lookup (similar to PGP's pgp.mit.edu) based on key server identifier (i.e., e-mail address) returns Base64 encoded DER-formatted EC public key [https://www.ietf.org/rfc/rfc5480.txt RFC 5480]", "category": "bips" }, { "instruction": "I'm trying to understand Bitcoin Operations Guide - can you walk me through it?", "input": "", "output": "# QR Code - Use of QR-code to encode SEC-formatted EC public key [https://www.ietf.org/rfc/rfc5480.txt RFC 5480]", "category": "bips" }, { "instruction": "Hey, I need to set up Address Service Public Key Exposure - what's the command line way to do that?", "input": "", "output": "==Payment / PaymentACK Messages with a HTTP Store & Forward Server==\nIf a Store & Forward server wishes to protect themselves from spam or abuse, they MAY enact whatever rules they deem fit, such as the following:\n\n* Once an InvoiceRequest or PaymentRequest is received, all subsequent messages using the same identifier must use the same Sender and Receiver public keys.\n* For each unique identifier, only one message each of type InvoiceRequest, PaymentRequest, and PaymentACK may be submitted. Payment messages may be submitted/overwritten multiple times. All messages submitted after a PaymentACK is received will be rejected.\n* Specific messages are only saved until they have been verifiably received by the intended recipient or a certain amount of time has passed, whichever comes first.\n\n

\nClients SHOULD keep in mind Receivers can broadcast a transaction without returning an ACK. If a Payment message needs to be updated, it SHOULD include at least one input referenced in the original transaction to prevent the Receiver from broadcasting both transactions and getting paid twice.\n\n==Public Key & Signature Encoding==\n* All x.509 certificates included in any message defined in this BIP MUST be DER [ITU.X690.1994] encoded.\n* All EC public keys ('''sender_public_key''', '''receiver_public_key''') in any message defined in this BIP MUST be [[SECP256k1|http://www.secg.org/sec2-v2.pdf]] ECDSA Public Key ECPoints encoded using [[SEC 2.3.3 Encoding|http://www.secg.org/sec1-v2.pdf]]. Encoding MAY be compressed.\n* All ECC signatures included in any message defined in this BIP MUST use the SHA-256 hashing algorithm and MUST be DER [ITU.X690.1994] encoded.\n* All OpenPGP certificates must follow [[https://tools.ietf.org/html/rfc4880|RFC4880]], sections 5.5 and 12.1.\n\n==Implementation==\nA reference implementation for a Store & Forward server supporting this proposal can be found here:\n\n[https://github.com/netkicorp/addressimo Addressimo]\n\nA reference client implementation can be found in the InvoiceRequest functional testing for Addressimo here:\n\n[https://github.com/netkicorp/addressimo/blob/master/functest/functest_bip75.py BIP75 Client Reference Implementation]\n\n==BIP70 Extension==\nThe following flowchart is borrowed from [[bip-0070.mediawiki|BIP70]] and expanded upon in order to visually describe how this BIP is an extension to [[bip-0070.mediawiki|BIP70]].\n\n\"Flowchart\n\n==Mobile to Mobile Examples==\n\n===Full Payment Protocol===\nThe following diagram shows a sample flow in which one mobile client is sending value to a second mobile client with the use of an InvoiceRequest, a Store & Forward server, PaymentRequest, Payment and PaymentACK. In this case, the PaymentRequest, Payment and PaymentACK messages are encrypted using [[#encryptedprotocolmessage|EncryptedProtocolMessage]] '''and''' the Receiver submits the transaction to the Bitcoin network.\n\n\"Payment\n\n===Encrypting Initial InvoiceRequest via EncryptedProtocolMessage===\nThe following diagram shows a sample flow in which one mobile client is sending value to a second mobile client using an [[#encryptedprotocolmessage|EncryptedProtocolMessage]] to transmit the InvoiceRequest using encryption, Store & Forward server, and PaymentRequest. In this case, all Payment Protocol messages are encrypting using [[#encryptedprotocolmessage|EncryptedProtocolMessage]] '''and''' the Sender submits the transaction to the Bitcoin network.\n\n\"Encrypted\n\n==References==\n\n* [[bip-0070.mediawiki|BIP70 - Payment Protocol]]\n* [https://en.wikipedia.org/wiki/Elliptic_curve_Diffie–Hellman ECDH]\n* [http://csrc.nist.gov/publications/nistpubs/800-90A/SP800-90A.pdf HMAC_DRBG]\n* [http://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf NIST Special Publication 800-38D - Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC]\n* [https://tools.ietf.org/html/rfc6979 RFC6979]\n* [https://en.bitcoin.it/wiki/Address_reuse Address Reuse]\n* [http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf FIPS 180-4 (Secure Hash Standard)]", "category": "bips" }, { "instruction": "What's the deal with 
 in Bitcoin? Explain it like I'm a friend.",
    "input": "",
    "output": "BIP: 23\n  Layer: API/RPC\n  Title: getblocktemplate - Pooled Mining\n  Authors: Luke Dashjr \n  Status: Deployed\n  Type: Specification\n  Assigned: 2012-02-28\n  License: BSD-2-Clause\n
\n\n==Abstract==\n\nThis BIP describes extensions to the getblocktemplate JSON-RPC call to enhance pooled mining.\n\n==Copyright==\n\nThis BIP is licensed under the BSD 2-clause license.\n\n==Specification==\n\nNote that all sections of this specification are optional extensions on top of [[bip-0022.mediawiki|BIP 22]].\n\n===Summary Support Levels===\n\nSomething can be said to have BIP 23 Level 1 support if it implements at least:\n* [http://www.ietf.org/rfc/rfc1945.txt RFC 1945]\n* [http://json-rpc.org/wiki/specification JSON-RPC 1.0]\n* [[bip-0022.mediawiki|BIP 22 (non-optional sections)]]\n* [[bip-0022.mediawiki#optional-long-polling|BIP 22 Long Polling]]\n* [[#basic-pool-extensions|BIP 23 Basic Pool Extensions]]\n* [[#mutations|BIP 23 Mutation \"coinbase/append\"]]\n* [[#submission-abbreviation|BIP 23 Submission Abbreviation \"submit/coinbase\"]]\n* [[#mutations|BIP 23 Mutation \"time/increment\"]] (only required for servers)\n\nIt can be said to have BIP 23 Level 2 support if it also implements:\n* [[#mutations|BIP 23 Mutation \"transactions/add\"]]\n* [[#block-proposals|BIP 23 Block Proposals]]\n\n===Basic Pool Extensions===\n\n{| class=\"wikitable\"\n! colspan=\"3\" | template request\n|-\n! Key !! Type !! Description\n|-\n| target || String || desired target for block template (may be ignored)\n|}\n\n{| class=\"wikitable\"\n!colspan=\"3\"| template\n|-\n! Key !! Type !! Description\n|-\n| expires || Number || how many seconds (beginning from when the server sent the response) this work is valid for, at most\n|-\n| target || String || the number which valid results must be less than, in big-endian hexadecimal\n|}\n\n===Block Proposal===\n\nServers may indicate support for proposing blocks by including a capability string in their original template:\n{| class=\"wikitable\"\n!colspan=\"3\"| template\n|-\n! Key !! Type !! Description\n|-\n| capabilities || Array of Strings || MAY contain \"proposal\" to indicate support for block proposal\n|-\n| reject-reason || String || Reason the proposal was invalid as-is (only applicable in response to proposals)\n|}\n\nIf supported, a miner MAY propose a block to the server for general validation at any point before the job expires.\nThis is accomplished by calling getblocktemplate with two keys:\n{| class=\"wikitable\"\n!colspan=3| getblocktemplate parameters\n|-\n! Key !! Type !! Description\n|-\n| data || String || MUST be hex-encoded block data\n|-\n| mode || String || MUST be \"proposal\"\n|-\n| workid || String || if the server provided a workid, it MUST be included with proposals\n|}\n\nThe block data MUST be validated and checked against the server's usual acceptance rules (excluding the check for a valid proof-of-work).\nIf it is found to be in violation of any of these rules, the server MUST return one of the following:\n* Null if it is acceptable as-is, with the same workid (if any) as provided. Note that this SHOULD NOT invalidate the old template's claim to the same workid.\n* A String giving the reason for the rejection (see [[bip-0022.mediawiki#appendix-example-rejection-reasons|example rejection reasons]]).\n* A \"delta\" block template (with changes needed); in this case, any missing keys are assumed to default to those in the proposed block or, if not applicable, the original block template it was based on. This template MAY also include a \"reject-reason\" key with a String of the reason for rejection.\n\nIt is RECOMMENDED that servers which merely need to track the proposed block for later share/* submissions, return a simple Object of the form:\n {\"workid\":\"new workid\"}\n\nClients SHOULD assume their proposed block will remain valid if the only changes they make are to the portion of the coinbase scriptSig they themselves provided (if any) and the time header.\nServers SHOULD NOT break this assumption without good cause.\n\n===Mutations===\n\n{| class=\"wikitable\"\n! colspan=\"3\" | template request\n|-\n! Key !! Type !! Description\n|-\n| nonces || Number || size of nonce range the miner needs; if not provided, the server SHOULD assume the client requires 232\n|}\n\n{| class=\"wikitable\"\n!colspan=3| template\n|-\n! Key !! Type !! Description\n|-\n| maxtime || Number || the maximum time allowed\n|-\n| maxtimeoff || Number || the maximum time allowed (as a moving offset from \"curtime\" - every second, the actual maxtime is incremented by 1; for example, \"maxtimeoff\":0 means \"time\" may be incremented by 1 every second)\n|-\n| mintime || Number || the minimum time allowed\n|-\n| mintimeoff || Number || the minimum time allowed (as a moving offset from \"curtime\")\n|-\n| mutable || Array of Strings || different manipulations that the server explicitly allows to be made\n|-\n| noncerange || String || two 32-bit integers, concatenated in big-endian hexadecimal, which represent the valid ranges of nonces the miner may scan\n|}\n\nIf the block template contains a \"mutable\" key, it is a list of these to signify modifications the miner is allowed to make:\n\n{| class=\"wikitable\"\n!colspan=2| mutations\n|-\n! Value !! Significance\n|-\n| coinbase/append\n| append the provided coinbase scriptSig\n|-\n| coinbase\n| provide their own coinbase; if one is provided, it may be replaced or modified (implied if \"coinbasetxn\" omitted)\n|-\n| generation\n| add or remove outputs from the coinbase/generation transaction (implied if \"coinbasetxn\" omitted)\n|-\n| time/increment\n| change the time header to a value after \"time\" (implied if \"maxtime\" or \"maxtimeoff\" are provided)\n|-\n| time/decrement\n| change the time header to a value before \"time\" (implied if \"mintime\" is provided)\n|-\n| time\n| modify the time header of the block\n|-\n| transactions/add (or \"transactions\")\n| add other valid transactions to the block (implied if \"transactions\" omitted from result)\n|-\n| prevblock\n| use the work with other previous-blocks; this implicitly allows removing transactions that are no longer valid (but clients SHOULD attempt to propose removal of any required transactions); it also implies adjusting \"height\" as necessary\n|-\n| version/force\n| encode the provide block version, even if the miner doesn't understand it\n|-\n| version/reduce\n| use an older block version than the one provided (for example, if the client does not support the version provided)\n|}\n\n===Submission Abbreviation===\n\n{| class=\"wikitable\"\n!colspan=3| template\n|-\n! Key !! Type !! Description\n|-\n| fulltarget || String || the number which full results should be less than, in big-endian hexadecimal (see \"share/*\" mutations)\n|-\n| mutable || Array of Strings || different manipulations that the server explicitly allows to be made, including abbreviations\n|}\n\nIf the block template contains a \"mutable\" key, it is a list of these to signify modifications the miner is allowed to make:\n\n{| class=\"wikitable\"\n!colspan=2| abbreviation mutations\n|-\n! Value !! Significance\n|-\n| submit/hash\n| each transaction being sent in a request, that the client is certain the server knows about, may be replaced by its hash in little-endian hexadecimal, prepended by a \":\" character\n|-\n| submit/coinbase\n| if the \"transactions\" provided by the server are used as-is with no changes, submissions may omit transactions after the coinbase (transaction count varint remains included with the full number of transactions)\n|-\n| submit/truncate\n| if the \"coinbasetxn\" and \"transactions\" provided by the server are used as-is with no changes, submissions may contain only the block header; if only the scriptSig of \"coinbasetxn\" is modified, the params Object MUST contain a \"coinbasesig\" key with the content, or a \"coinbaseadd\" with appended data (if only appending)\n|-\n| share/coinbase\n| same as \"submit/coinbase\", but only if the block hash is greater than \"fulltarget\"\n|-\n| share/merkle\n| if the block hash is greater than \"fulltarget\", the non-coinbase transactions may be replaced with a merkle chain connecting it to the root\n|-\n| share/truncate\n| same as \"submit/truncate\", but only if the block hash is greater than \"fulltarget\"\n|}\n\n==== Format of Data for Merkle-Only Shares ====\n\nThe format used for submitting shares with the \"share/merkle\" mutation shall be the 80-byte block header, the total number of transactions encoded in Bitcoin variable length number format, the coinbase transaction, and then finally the little-endian SHA256 hashes of each link in the merkle chain connecting it to the merkle root.\n\n===Logical Services===\n\n{| class=\"wikitable\"\n! colspan=\"3\" | template request\n|-\n! Key !! Type !! Description\n|-\n| capabilities || Array of Strings || miners which support this SHOULD provide a list including the String \"serverlist\"\n|}\n\n{| class=\"wikitable\"\n!colspan=3| template\n|-\n! Key !! Type !! Description\n|-\n| serverlist || Array of Objects || list of servers in this single logical service\n|}\n\nIf the \"serverlist\" parameter is provided, clients MAY choose to intelligently treat the server as part of a larger single logical service.\n\nEach host Object in the Array is comprised of the following fields:\n{| class=\"wikitable\"\n!colspan=3| serverlist element\n|-\n! Key !! Type !! Description\n|-\n| uri || String || URI of the individual server; if authentication information is omitted, the same authentication used for this request MUST be assumed\n|-\n| avoid || Number || number of seconds to avoid using this server\n|-\n| priority || Number || an integer priority of this host (default: 0)\n|-\n| sticky || Number || number of seconds to stick to this server when used\n|-\n| update || Boolean || whether this server may update the serverlist (default: true)\n|-\n| weight || Number || a relative weight for hosts with the same priority (default: 1)\n|}\n\nWhen choosing which actual server to get the next job from, URIs MUST be tried in order of their \"priority\" key, lowest Number first.\nWhere the priority of URIs is the same, they should be chosen from in random order, weighed by their \"weight\" key.\nWork proposals and submissions MUST be made to the same server that issued the job.\nClients MAY attempt to submit to other servers if, and only if, the original server cannot be reached.\nIf cross-server share submissions are desired, services SHOULD instead use the equivalent domain name system (DNS) features (RFCs [http://tools.ietf.org/html/rfc1794 1794] and [http://tools.ietf.org/html/rfc2782 2782]).\n\nUpdates to the Logical Service server list may only be made by the original server, or servers listed with the \"update\" key missing or true.\nClients MAY choose to advertise serverlist capability to servers with a false \"update\" key, but if so, MUST treat the server list provided as a subset of the current one, only considered in the context of this server.\nAt least one server with \"update\" privilege MUST be attempted at least once daily.\n\nIf the \"sticky\" key is provided, then when that server is used, it should be used consistently for at least that many seconds, if possible.\n\nA permanent change in server URI MAY be indicated with a simple \"serverlist\" parameter:\n \"serverlist\":[{\"uri\": \"http://newserver\"}]\n\nA temporary delegation to another server for 5 minutes MAY be indicated likewise:\n \"serverlist\":[{\"uri\": \"\", avoid: 300}, {\"uri\": \"http://newserver\", \"update\": false}]\n\n==Motivation==\n\nThere is reasonable concerns about mining currently being too centralized on pools, and the amount of control these pools hold.\nBy exposing the details of the block proposals to the miners, they are enabled to audit and possibly modify the block before hashing it.\n\nTo encourage widespread adoption, this BIP should be a complete superset of the existing centralized getwork protocol, so pools are not required to make substantial changes to adopt it.\n\n==Rationale==\nWhy allow servers to restrict the complete coinbase and nonce range?\n* This is necessary to provide a complete superset of JSON-RPC getwork functionality, so that pools may opt to enable auditing without significantly changing or increasing the complexity of their share validation or mining policies.\n* Since noncerange is optional (both for getwork and this BIP), neither clients nor servers are required to support it.\n\nWhy specify \"time/*\" mutations at all?\n* In most cases, these are implied by the mintime/mintimecur/maxtime/maxtimecur keys, but there may be cases that there are no applicable minimums/maximums.\n\nWhat is the purpose of the \"prevblock\" mutation?\n* There are often cases where a miner has processed a new block before the server. If the server allows \"prevblock\" mutation, the miner may begin mining on the new block immediately, without waiting for a new template.\n\nWhy must both \"mintime\"/\"maxtime\" and \"mintimeoff\"/\"maxtimeoff\" keys be defined?\n* In some cases, the limits may be unrelated to the current time (such as the Bitcoin network itself; the minimum is always a fixed median time)\n* In other cases, the limits may be bounded by other rules (many pools limit the time header to within 5 minutes of when the share is submitted to them).\n\nIs \"target\" really needed?\n* Some pools work with lower targets, and should not be expected to waste bandwidth ignoring shares that don't meet it.\n* Required to be a proper superset of getwork.\n* As mining hashrates grow, some miners may need the ability to request a lower target from their pools to be able to manage their bandwidth use.\n\nWhat is the purpose of the \"hash\" transaction list format?\n* Non-mining tools may wish to simply get a list of memory pool transactions.\n* Humans may wish to view their current memory pool.\n\n==Reference Implementation==\n\n* [http://gitorious.org/bitcoin/libblkmaker libblkmaker]\n* [https://gitorious.org/bitcoin/eloipool Eloipool]\n* [https://github.com/bitcoin/bitcoin/pull/936/files bitcoind]\n\n==See Also==\n* [[bip-0022.mediawiki|BIP 22: getblocktemplate - Fundamentals]]", "category": "bips" }, { "instruction": "Can you show me the CLI commands for 
?",
    "input": "",
    "output": "BIP: 14\n  Layer: Peer Services\n  Title: Protocol Version and User Agent\n  Authors: Amir Taaki \n           Patrick Strateman \n  Status: Deployed\n  Type: Specification\n  Assigned: 2011-11-10\n  Discussion: 2011-11-02: https://gnusha.org/pi/bitcoindev/1320268981.72296.YahooMailNeo@web121003.mail.ne1.yahoo.com/\n              2011-11-10: https://gnusha.org/pi/bitcoindev/1320959761.36702.YahooMailNeo@web121014.mail.ne1.yahoo.com/\n
\n\nIn this document, bitcoin will be used to refer to the protocol while Satoshi will refer to the current client in order to prevent confusion.\n\n== Past Situation ==\n\nBitcoin as a protocol began life with the Satoshi client. Now that the community is diversifying, a number of alternative clients with their own codebases written in a variety of languages (Java, Python, Javascript, C++) are rapidly developing their own feature-sets.\n\nEmbedded in the protocol is a version number. Primarily this version number is in the \"version\" and \"getblocks\" messages, but is also in the \"block\" message to indicate the software version that created that block. Currently this version number is the same version number as that of the client. This document is a proposal to separate the protocol version from the client version, together with a proposed method to do so.\n\n== Rationale ==\n\nWith non-separated version numbers, every release of the Satoshi client will increase its internal version number. Primarily this holds every other client hostage to a game of catch-up with Satoshi version number schemes. This plays against the decentralised nature of bitcoin, by forcing every software release to remain in step with the release schedule of one group of bitcoin developers.\n\nVersion bumping can also introduce incompatibilities and fracture the network. In order that the health of the network is maintained, the development of the protocol as a shared common collaborative process requires being split off from the implementation of that protocol. Neutral third entities to guide the protocol with representatives from all groups, present the chance for bitcoin to grow in a positive manner with minimal risks.\n\nBy using a protocol version, we set all implementations on the network to a common standard. Everybody is able to agree within their confines what is protocol and what is implementation-dependent. A user agent string is offered as a 'vanity-plate' for clients to distinguish themselves in the network.\n\nSeparation of the network protocol from the implementation, and forming development of said protocol by means of a mutual consensus among participants, has the democratic disadvantage when agreement is hard to reach on contentious issues. To mitigate this issue, strong communication channels and fast release schedules are needed, and are outside the scope of this document (concerning a process-BIP type).\n\nUser agents provide extra tracking information that is useful for keeping tabs on network data such as client implementations used or common architectures/operating-systems. In the rare case they may even provide an emergency method of shunning faulty clients that threaten network health- although this is strongly unrecommended and extremely bad form. The user agent does not provide a method for clients to work around and behave differently to different implementations, as this will lead to protocol fracturing.\n\nIn short:\n\n* Protocol version: way to distinguish between nodes and behave different accordingly.\n* User agent: simple informational tool. Protocol should not be modified depending on user agent.\n\n== Browser User-Agents ==\n\n[http://tools.ietf.org/html/rfc1945 RFC 1945] vaguely specifies a user agent to be a string of the product with optional comments.\n\n Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.6) Gecko/20100127 Gentoo Shiretoko/3.5.6\n\nUser agents are most often parsed by computers more than humans. The space delimited format, does not provide an easy, fast or efficient way for parsing. The data contains no structure indicating hierarchy in this placement.\n\nThe most immediate pieces of information there are the browser product, rendering engine and the build (Gentoo Shiretoko) together with version number. Various other pieces of information as included as comments such as desktop environment, platform, language and revision number of the build.\n\n== Proposal ==\n\nThe version field in \"version\" and \"getblocks\" packets will become the protocol version number. The version number in the \"blocks\" reflects the protocol version from when that block was created.\n\nThe currently unused sub_version_num field in \"version\" packets will become the new user-agent string.\n\nBitcoin user agents are a modified browser user agent with more structure to aid parsers and provide some coherence. In bitcoin, the software usually works like a stack starting from the core code-base up to the end graphical interface. Therefore the user agent strings codify this relationship.\n\nBasic format:\n\n /Name:Version/Name:Version/.../\n\nExample:\n\n /Satoshi:5.64/bitcoin-qt:0.4/\n /Satoshi:5.12/Spesmilo:0.8/\n\nHere bitcoin-qt and Spesmilo may use protocol version 5.0, however the internal codebase they use are different versions of the same software. The version numbers are not defined to any strict format, although this guide recommends:\n\n* Version numbers in the form of Major.Minor.Revision (2.6.41)\n* Repository builds using a date in the format of YYYYMMDD (20110128)\n\nFor git repository builds, implementations are free to use the git commitish. However the issue lies in that it is not immediately obvious without the repository which version precedes another. For this reason, we lightly recommend dates in the format specified above, although this is by no means a requirement.\n\nOptional -r1, -r2, ... can be appended to user agent version numbers. This is another light recommendation, but not a requirement. Implementations are free to specify version numbers in whatever format needed insofar as it does not include (, ), : or / to interfere with the user agent syntax.\n\nAn optional comments field after the version number is also allowed. Comments should be delimited by brackets (...). The contents of comments is entirely implementation defined although this BIP recommends the use of semi-colons ; as a delimiter between pieces of information.\n\nExample:\n\n /BitcoinJ:0.2(iPad; U; CPU OS 3_2_1)/AndroidBuild:0.8/\n\nReserved symbols are therefore: / : ( )\n\nThey should not be misused beyond what is specified in this section.\n\n* / separates the code-stack\n* : specifies the implementation version of the particular stack\n* ( and ) delimits a comment which optionally separates data using ;\n\n== Timeline ==\n\nWhen this document was published, the bitcoin protocol and Satoshi client versions were currently at 0.5 and undergoing changes. In order to minimise disruption and allow the undergoing changes to be completed, the next protocol version at 0.6 became peeled from the client version (also at 0.6). As of that time (January 2012), protocol and implementation version numbers are distinct from each other.", "category": "bips" }, { "instruction": "I'm stuck with 
 - what should I check?",
    "input": "",
    "output": "BIP: 111\n  Layer: Peer Services\n  Title: NODE_BLOOM service bit\n  Authors: Matt Corallo \n           Peter Todd \n  Status: Deployed\n  Type: Specification\n  Assigned: 2015-08-20\n  License: PD\n
\n\n== Abstract ==\n\nThis BIP extends BIP 37, Connection Bloom filtering, by defining a\nservice bit to allow peers to advertise that they support bloom filters\nexplicitly. It also bumps the protocol version to allow peers to\nidentify old nodes which allow bloom filtering of the connection despite\nlacking the new service bit.\n\n\n== Motivation ==\n\nBIP 37 did not specify a service bit for the bloom filter service, thus\nimplicitly assuming that all nodes that serve peers data support it.\nHowever, the connection filtering algorithm proposed in BIP 37, and\nimplemented in several clients today, has been shown to provide little\nto no privacyhttp://eprint.iacr.org/2014/763, as well as being a large DoS risk on some nodes[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-July/003044.html] is one example where the issues were found, though others independently discovered issues as well. Sample DoS exploit code available at https://github.com/petertodd/bloom-io-attack..\nThus, allowing node operators to disable connection bloom filtering is a\nmuch-needed feature.\n\n\n== Specification ==\n\nThe following protocol bit is added:\n\n
\n    NODE_BLOOM = (1 << 2)\n
\n\nNodes which support bloom filters should set that protocol bit.\nOtherwise it should remain unset. In addition the protocol version is\nincreased from 70002 to 70011 in the reference implementation. It is\noften the case that nodes which have a protocol version smaller than\n70011, but larger than 70000 support bloom filtered connections without\nthe NODE_BLOOM bit set, however clients which require bloom filtered\nconnections should avoid making this assumption.\n\nNODE_BLOOM is distinct from NODE_NETWORK, and it is legal to advertise\nNODE_BLOOM but not NODE_NETWORK (though there is little reason to do\nso now, some proposals may make this more useful in the future)\n\nIf a node does not support bloom filters but receives a \"filterload\",\n\"filteradd\", or \"filterclear\" message from a peer the node should\ndisconnect that peer immediately. For backwards compatibility, in\ninitial implementations, nodes may choose to only disconnect nodes which\nhave the new protocol version set and attempt to send a filter command.\n\nWhile outside the scope of this BIP it is suggested that DNS seeds and\nother peer discovery mechanisms support the ability to specify the\nservices required; current implementations simply check only that\nNODE_NETWORK is set.\n\n\n== Design rational ==\n\nA service bit was chosen as applying a bloom filter is a service.\n\nThe increase in protocol version is for backwards compatibility. In\ninitial implementations, old nodes which are not yet aware of NODE_BLOOM\nand use a protocol version < 70011 may still send filter messages to a\nnode without NODE_BLOOM. This feature may be removed after there are\nsufficient NODE_BLOOM nodes available and SPV clients have upgraded,\nallowing node operators to fully close the bloom-related DoS vectors.\n\n\n== Reference Implementation ==\n\nhttps://github.com/bitcoin/bitcoin/pull/6579\n\n\n== Copyright ==\n\nThis document is placed in the public domain.\n\n\n== References ==\n", "category": "bips" }, { "instruction": "How do I troubleshoot 
 issues?",
    "input": "",
    "output": "BIP: 88\n  Layer: Applications\n  Title: Hierarchical Deterministic Path Templates\n  Authors: Dmitry Petukhov \n  Status: Complete\n  Type: Informational\n  Assigned: 2020-06-23\n  License: BSD-2-Clause\n
\n\n==Abstract==\n\nThis document describes a format for the representation of the templates that specify\nthe constraints that can be imposed on BIP32 derivation paths.\n\nThe constraints specified by the templates allow to easily discern 'valid' paths,\nthat match the constraints, and 'invalid' paths, that exceed the constraints.\n\n==Copyright==\n\nThis BIP is licensed under the 2-clause BSD license.\n\n==Motivation==\n\nBIP32 derivation path format is universal, and a number of schemes for derivation were proposed\nin BIP43 and other documents, such as BIPs 44,45,49,84. The flexibility of the format also allowed\nindustry participants to implement custom derivation schemes that fit particular purposes,\nbut not necessarily useful in general.\n\nEven when existing BIPs for derivation schemes are used, their usage is not uniform across\nthe different wallets, in part because software vendors might have different considerations\nand priorities when making decisions about derivation paths. This creates friction for users,\nwhich might face problems when they try to access their coins using the wallet that derives\naddresses differently than the one they used before.\n\n===Known solutions===\n\nThe problem is common enough to warrant the creation of a dedicated website\n([https://walletsrecovery.org/ walletsrecovery.org]) that tracks paths used by different wallets.\n\nAt the time of writing, this website has used their own format to succinctly describe multiple\nderivation paths. As far as author knows, it was the only publicly used format to describe\npath templates before introduction of this BIP. The format was not specified anywhere beside\nthe main page of the website. It used | to denote alternative derivation indexes\n(example: m/|44'|49'|84'/0'/0') or whole alternative paths (m/44'/0'/0'|m/44'/1'/0').\n\nIt was not declared as a template format to use for processing by software, and seems to be\nan ad-hoc format only intended for illustration. In contrast to this ad-hoc format, the format\ndescribed in this BIP is intended for unambiguous parsing by software, and to be easily read by humans\nat the same time. Humans can visually detect the 'templated' parts of the path more easily than the use\nof | in the template could allow. Wider range of paths can be defined in a single template more\nsuccinctly and unambiguously.\n\n===Intended use and advantages===\n\nWallet software authors can use the proposed format to describe the derivation paths that\ntheir software uses. This can improve user experience when switching to different wallet\nsoftware, restoring access to old wallets, etc.\n\nUnrestricted derivation path usage might be unsafe in certain contexts. In particular, when \"change\"\noutputs of a transaction are sent to the addresses derived via paths unknown to the sender, the sender\nmight lose access to the whole change amount.\n\nA simplistic approach of hard-coding the checks for well-known paths into software and firmware leads\nto reduced interoperability. Vendors cannot choose custom paths that are appropriate for\ntheir particular, non-general-purpose applications, and are forced to shoehorn their solutions\ninto using well-known paths, or convince other vendors to support their custom paths. This approach\nscales poorly.\n\nA flexible approach proposed in this document is to define a standard notation for \"BIP32 path templates\"\nthat succinctly describes the constraints to impose on the derivation path.\n\nWide support for these path templates will increase interoperability and flexibility of solutions,\nand will allow vendors and individual developers to easily define their own custom restrictions.\nThis way, they will be able to deal with the risks of accidental or malicious use of unrestricted\nderivation paths in a more flexible and precise manner.\n\nWell-known path templates can be pre-configured by default on devices and applications,\nbut users can have an option to turn off the templates that are not relevant to their uses.\n\nHaving a standardized format for custom path templates will enable a common approach to be developed\nin the enforcement of application-specific path restrictions in devices and applications.\nOne example of such an approach might be for devices to allow application-specific profiles\nwith path templates and possibly other custom parameters. Care must be taken to prevent the accidental\ninstallation of malicious or incorrect profiles, though.\n\n==Specification==\n\nThe format for the template was chosen to make it easy to read, convenient and visually unambiguous.\n\nTemplate starts with optional prefix m/, and then one or more sections delimited by the slash character (/).\n\nImplementations MAY limit the maximum number of sections.\n\nEach section consists of ''index template'', optionally followed by the hardened marker: either an apostrophe (') or letter h.\n\nIndex template can be:\n\n* An integer value from 0 to 2147483647 (\"Unit index template\")\n* A single * character, which denotes any value from 0 to 2147483647 (\"Wildcard index template\")\n* The { character, followed by a number of ''index ranges'' delimited by commas (,), followed by } character (\"Ranged index template\")\n\nImplementations MAY limit the maximum number of index ranges within the Ranged index template.\n\nIf an index template is immediately followed by hardened marker, this means that all values specified in this index template is to be increased by 2147483648 for the purposes of matching.\n\nIndex range can be:\n\n* An integer value from 0 to 2147483647 (\"Unit range\")\n* An integer value from 0 to 2147483647, followed by the - character, followed by another integer value from 0 to 2147483647 (\"Non-unit range\")\n\nFor Non-unit range, value on the left side of the - character is the range_start, and the value on the right side of the - character is the range_end.\n\nFor Unit range, we say that range_start is equal to range_end, even though there is no start/end in the Unit range.\n\nUnit index template contains a single index range, which is the Unit range\n\nWildcard index template contains a single index range, and we say that its range_start is set to 0 and its range_end is set to 2147483647\n\nConstraints:", "category": "bips" }, { "instruction": "What are the best practices for Bitcoin Operations Guide?", "input": "", "output": "# To avoid ambiguity, an index range 0-2147483647 is not allowed, and MUST be specified as Wildcard index template instead", "category": "bips" }, { "instruction": "Walk me through setting up Bitcoin Operations Guide step by step", "input": "", "output": "# If there is more than one index range within the Ranged index template, range_start of the second and any subsequent range MUST be larger than the range_end of the preceding range.", "category": "bips" }, { "instruction": "What commands would you run to work with Bitcoin Operations Guide?", "input": "", "output": "# To avoid ambiguity, all representations of integer values larger than 0 MUST NOT start with character 0 (no leading zeroes allowed).", "category": "bips" }, { "instruction": "I want to understand Bitcoin Operations Guide from a technical perspective", "input": "", "output": "# If hardened marker appears within any section in the path template, all preceding sections MUST also specify hardened matching.", "category": "bips" }, { "instruction": "Can you explain Bitcoin Operations Guide like we're having a beer and talking Bitcoin?", "input": "", "output": "# To avoid ambiguity, if a hardened marker appears within any section in the path template, all preceding sections MUST also use the same hardened marker (either h or ').", "category": "bips" }, { "instruction": "How would you explain To avoid ambiguity, trailing slashes (for example, 1/2/) and duplicate slashes (for example, 0//1) MUST NOT appear in the template. to someone who knows Bitcoin basics?", "input": "", "output": "It may be desirable to have fully unambiguous encoding, where for each valid path template string, there is no other valid template string that matches the exact same set of paths. This would enable someone to compare templates for equality through a simple string equality check, without any parsing.\n\nTo achieve this, two extra rules are needed:\n\n* Within Ranged index template, subsequent range MUST NOT start with the value that is equal to the end of the previous range plus one. Thus, {1,2,3-5} is not allowed, and should be specified as {1-5} instead. This rule might make templates less convenient for frequent edits, though.\n\n* Only one type of hardened marker should be allowed (either h or ').\n\nInstead of requiring the second extra rule, implementations can simply replace one type of marker with another in the template strings before comparing them.\n\n==Full and partial templates==\n\nIf the template starts with m/, that means that this is the \"full\" template, that matches the whole path.\n\nIf the template does not start with m/, that means that this is a \"partial\" template, and it can be used to match a part of the path, in the contexts where this might be appropriate (for example, when constraints for the suffix of the path might be dynamic, while constraints for the prefix of the path are fixed).\n\nFull template can be combined with partial template, where partial template extends full template,\nresulting in new, longer full template.\n\nPartial template can be combined with another partial template, resulting in new, longer partial template.\n\nFull template can not be combined with another full template.\n\nImplementations MUST support parsing full templates and matching paths against full templates.\n\nImplementations MAY support parsing partial templates and matching portions of the paths against partial templates, as well as combining the templates.\n\n==Parsing result==\n\nThe result of successful parsing of a valid path template can be represented by a list of sections, where each section is a list of index ranges, where index range is a tuple of (range_start, range_end). The length of the list of sections is also referred to as the \"length of the template\".\n\n==Matching==\n\nThe matching is to be performed against a list of integer values that represent a BIP32 path (or a portion of BIP32 path, for partial templates). The length of this list is referred to as the \"length of the path\".\n\nNon-hardened indexes in this list should be represented by values from 0 to 2147483647.\n\nHardened indexes in this list should be represented by values from 2147483648 to 4294967295.\n\nThe matching algorithm:\n\n 1. If the length of the path differs from the length of the template, fail\n 2. For each value V at position N in the path:\n If for all index ranges within the section at position N in the template,\n value V is either less than range_start, or greater than range_end, fail\n 3. Otherwise, succeed\n\n==Formal specification==\n\nThe finite state machine (FSM) for the parser of the described template format,\nand the matching formula are specified in TLA+ specification language at https://github.com/dgpv/bip32_template_parse_tplaplus_spec\n\nThe specification can be used with TLC checker and accompanying script to generate test data for the implementations.\n\n==Implementations==\n\nWhile the formal specification specifies an FSM, which would be convenient for implementation without access to rich string handling facilities, when such facilities are available, the implementation might use the whole-string deconstruction approach where the templates are first split into sections, then sections are split into index templates, and then each index template are parsed individually.\n\nA FSM-based approach can be made close to the formal specification, though, and the test data generated with TLC checker would give much better coverage for a FSM based implementation. If the template string contains several errors, an implementation that uses deconstruction approach might detect some of these errors earlier than FSM-based implementation, and vise versa.\n\nAt the moment, three implementations exist:\n\n* FSM implementation in C: https://github.com/dgpv/bip32_template_c_implementation\n* FSM implementation in Python (micropython compatible): https://github.com/dgpv/bip32_template_python_implementation\n* non-FSM implementation in python: BIP32PathTemplate class in bitcointx.core.key module of python-bitcointx library (https://github.com/Simplexum/python-bitcointx)\n\n==Compatibility==\n\nThe full path template that only contains Unit index templates represents a fully valid BIP32 path.\n\nThere's no other path template standards that is known to the author currently.\n\nThere is a discussion on path templating for bitcoin script descriptors at https://github.com/bitcoin/bitcoin/issues/17190, which proposes the format xpub...{0,1}/*, of which the {0,1}/* part would correspond to the partial path template in the format of this BIP.\n\n==Examples==\n\nm/{44,49,84}'/0'/0'/{0-1}/{0-50000} specifies a full template that matches both external and internal chains of BIP44, BIP49 and BIP84 paths, with a constraint that the address index cannot be larger than 50000\n\nIts representation after parsing can be (using Python syntax, ignoring full/partial distinction):\n [[(2147483692, 2147483692), (2147483697, 2147483697), (2147483732, 2147483732)],\n [(2147483648, 2147483648)],\n [(2147483648, 2147483648)],\n [(0, 1)],\n [(0, 50000)]]\n\n{0-2,33,123}/* specifies a partial template that matches non-hardened values 0, 1, 2, 33, 123 as first index, and any non-hardened value at second index\n\nIts representation after parsing can be:\n [[(0, 2), (33, 33), (123, 123)], [(0, 2147483647)]]\n\n*h/0 specifies a partial template that matches any hardened index followed by non-hardened index 0\n\nIts representation after parsing can be:\n [[(2147483648, 4294967295)], [(0, 0)]]\n\n==Acknowledgements==\n\nSpecial thanks to Peter D. Gray, Dr. Maxim Orlovsky, Robert Spigler and others for their feedback on the specification, and to Janine (github:@Enegnei) for the help in preparing the draft.", "category": "bips" }, { "instruction": "I'm trying to understand 
 - can you walk me through it?",
    "input": "",
    "output": "BIP: 103\n  Layer: Consensus (hard fork)\n  Title: Block size following technological growth\n  Authors: Pieter Wuille \n  Status: Closed\n  Type: Specification\n  Assigned: 2015-07-21\n  License: BSD-2-Clause\n
\n\n==Abstract==\n\nThis BIP proposes a block size growth intended to accommodate for hardware and other technological improvements for the foreseeable future.\n\n==Copyright==\n\nThis BIP is licensed under the 2-clause BSD license.\n\n==Motivation==\n\nMany people want to see Bitcoin scale over time, allowing an increasing number of transactions on the block chain. It would come at an increased cost for the ecosystem (bandwidth, processing, and storage for relay nodes, as well as an impact on propagation speed of blocks on the network), but technology also improves over time. When all technologies depended on have improved as well as their availability on the market, there is no reason why Bitcoin's fundamental transaction rate cannot improve proportionally.\n\nCurrently, there is a consensus rule in place that limits the size of blocks to 1000000 bytes. Changing this requires a hard-forking change: one that will require every full node in the network to implement the new rules. The new chain created by those changed nodes will be rejected by old nodes, so this would effectively be a request to the ecosystem to migrate to a new and incompatible network. Doing this while controversy exists is dangerous to the network and the ecosystem.\n\nFurthermore, the effective space available is always constrained by a hash rate majority and its ability to process transactions. No hard forking change that relaxes the block size limit can be guaranteed to provide enough space for every possible demand - or even any particular demand - unless strong centralization of the mining ecosystem is expected. Because of that, the development of a fee market and the evolution towards an ecosystem that is able to cope with block space competition should be considered healthy. This does not mean the block size or its limitation needs to be constant forever. However, the purpose of such a change should be evolution with technological growth, and not kicking the can down the road because of a fear of change in economics.\n\nBitcoin's advantage over other systems does not lie in scalability. Well-designed centralized systems can trivially compete with Bitcoin's on-chain transactions in terms of cost, speed, reliability, convenience, and scale. Its power lies in transparency, lack of need for trust in network peers, miners, and those who influence or control the system. Wanting to increase the scale of the system is in conflict with all of those. Attempting to buy time with a fast increase is not wanting to face that reality, and treating the system as something whose scale trumps all other concerns. A long term scalability plan should aim on decreasing the need for trust required in off-chain systems, rather than increasing the need for trust in Bitcoin.\n\nIn summary, hard forks are extremely powerful, and we need to use them very responsibly as a community. They have the ability to fundamentally change the technology or economics of the system, and can be used to disadvantage those who expected certain rules to be immutable. They should be restricted to uncontroversial changes, or risk eroding the expectation of low trust needed in the system in the longer term. As the block size debate has been controversial so far - for good or bad reasons - this BIP aims for gradual change and its effects start far enough in the future.\n\n==Specification==\n\nThe block size limitation is replaced by the function below, applied to the median of the timestamps of the previous 11 blocks, or in code terms: the block size limit for pindexBlock is GetMaxBlockSize(pindexBlock->pprev->GetMedianTimePast()).\n\nThe sigop limit scales proportionally.\n\nIt implements a series of block size steps, one every ~97 days, between January 2017 and July 2063, each increasing the maximum block size by 4.4%. This allows an overall growth of 17.7% per year.\n\n
\nuint32_t GetMaxBlockSize(int64_t nMedianTimePast) {\n    // The first step is on January 1st 2017.\n    if (nMedianTimePast < 1483246800) {\n        return 1000000;\n    }\n    // After that, one step happens every 2^23 seconds.\n    int64_t step = (nMedianTimePast - 1483246800) >> 23;\n    // Don't do more than 11 doublings for now.\n    step = std::min(step, 175);\n    // Every step is a 2^(1/16) factor.\n    static const uint32_t bases[16] = {\n        // bases[i] == round(1000000 * pow(2.0, (i + 1) / 16.0))\n        1044274, 1090508, 1138789, 1189207,\n        1241858, 1296840, 1354256, 1414214,\n        1476826, 1542211, 1610490, 1681793,\n        1756252, 1834008, 1915207, 2000000\n    };\n    return bases[step & 15] << (step / 16);\n}\n
\n\n==Rationale==\n\nWaiting 1.5 years before the hard fork takes place should provide ample time to minimize the risk of a hard fork, if found uncontroversial.\n\nBecause every increase (including the first) is only 4.4%, risk from large market or technological changes is minimized.\n\nThe growth rate of 17.7% growth per year is consistent with the average growth rate of bandwidth the last years, which seems to be the bottleneck. If over time, this growth factor is beyond what the actual technology offers, the intention should be to soft fork a tighter limit.\n\nUsing a time-based check is very simple to implement, needs little context, is efficient, and is trivially reviewable. Using the \"median time past\" guarantees monotonic behaviour, as this median is required to be increasing, according to Bitcoin's existing consensus rules. Using the \"median time past\" of the block before means we know in advance what the limit of each block will be, without depending on the actual block's timestamp.\n\n==Compatibility==\n\nThis is a hard forking change, thus breaks compatibility with old fully-validating node. It should not be deployed without widespread consensus.\n\n==Acknowledgements==\n\nThanks to Gregory Maxwell and Wladimir J. van der Laan for their suggestions.", "category": "bips" }, { "instruction": "Hey, I need to set up 
 - what's the command line way to do that?",
    "input": "",
    "output": "BIP: 115\n  Layer: Consensus (soft fork)\n  Title: Generic anti-replay protection using Script\n  Authors: Luke Dashjr \n  Status: Closed\n  Type: Specification\n  Assigned: 2016-09-23\n  License: BSD-2-Clause\n
\n\n==Abstract==\n\nThis BIP describes a new opcode (OP_CHECKBLOCKATHEIGHT) for the Bitcoin scripting system that allows construction of transactions which are valid only on specific blockchains.\n\n==Copyright==\n\nThis BIP is licensed under the BSD 2-clause license.\n\n==Specification==\n\nOP_CHECKBLOCKATHEIGHT redefines the existing OP_NOP5 opcode.\n\nWhen this opcode is executed:\n\n* If the stack has fewer than 2 elements, the script fails.\n* If the top item on the stack cannot be interpreted as a minimal-length 32-bit CScriptNum, the script fails.\n* The top item on the stack is interpreted as a block height (ParamHeight).\n* If the blockchain (in the context of the execution) does not have ParamHeight blocks prior to the one including this transaction, the script fails (this failure must not be cached across blocks; it is equivalent to non-final status).\n* If ParamHeight specifies a block deeper than 52596 blocks in the chain (including negative values), the opcode completes successfully and script continues as normal.\n* The second-to-top item on the stack is interpreted as a block hash (ParamBlockHash).\n* If ParamBlockHash is longer than 28 bytes, the script fails.\n* If ParamBlockHash does not match the equivalent ending bytes of the block hash specified by ParamHeight, the script fails.\n\nOtherwise, script execution will continue as if a NOP had been executed.\n\n===Deployment===\n\nThis BIP will be deployed by \"version bits\" [[bip-0009.mediawiki|BIP9]] with the '''name''' \"cbah\" and using '''bit''' TBD.\n\nFor Bitcoin '''mainnet''', the BIP9 '''starttime''' will be TBD (Epoch timestamp TBD) and BIP9 '''timeout''' will be TBD (Epoch timestamp TBD).\n\nFor Bitcoin '''mainnet''', the BIP9 '''starttime''' will be TBD (Epoch timestamp TBD) and BIP9 '''timeout''' will be TBD (Epoch timestamp TBD).\n\n==Motivation==\n\n===Securely recovering from double spends===\n\nIn some circumstances, users may wish to spend received bitcoins before they have confirmed on the blockchain (Tx B1).\nHowever, if the transaction sending them those bitcoins (Tx A1) is double-spent, the wallet must re-issue their own transaction spending them (Tx B2).\nSo long as the double-spend of the incoming transaction (Tx A2) also pays the wallet, this can be managed by simply updating the outgoing transaction with the new outpoint and resigning.\nHowever, if the double-spend does not pay the wallet, the situation is presently irrecoverable:\nit must spend different, non-conflicting TXOs in Tx B2, which allows an attacker to then reorganise the chain (reversing the incoming transaction's double-spend) and confirm both of his transactions Tx B1 and Tx B2.\n\nBy adding OP_CHECKBLOCKATHEIGHT, the wallet can issue Tx B2 with a condition that the block confirming Tx A2 is in the history, thus eliminating this risk.\n\n===Replay protection in the event of a persistent blockchain split===\n\nIn the event of a persistent blockchain split, some mechanism is desired by which the UTXOs valid in either chain may be spent without the transaction being validly replayable on the other chain.\n\nThis can be guaranteed by choosing a block which exists only on either side of the split, and pinning (using OP_CHECKBLOCKATHEIGHT) common UTXOs to be spent only on chains based on that block.\n\n==Best practices for wallets==\n\nTo avoid unnecessary conflicts when a chain is reorganized, wallets should always avoid specifying the last 100 blocks when practical.\nWallets that use recent blocks when unavoidable SHOULD actively monitor the network and re-create transactions that are reorganised out with updated block hashes.\nUnless it conflicts with local/user security policies, wallets SHOULD retain the private key in memory to re-sign such transactions until the pinned block is at least 100 blocks deep into the chain.\n\nFor ordinary usage, wallets SHOULD specify the ParamBlockHash as 16 bytes.\n\n==Rationale==\n\nHow is this different from the transaction's lock-time?\n\n* The lock-time specifies a time or block height before a transaction becomes valid. OP_CHECKBLOCKATHEIGHT, on the other hand, specifies a specific block's hash.\n\nWhy are block heights required to be absolute, rather than relative?\n\n* A relative block height would allow for creation of transactions which are valid at block N, but not N+1. This is carefully avoided by Bitcoin to ensure that if any given block is reorganised out, non-malicious transactions can be simply re-confirmed in a later block.\n\nWhy are blocks older than 52596 deep in the chain not verified?\n\n* This is to avoid creating an infinite storage requirement from all full nodes which would be necessary to maintain all the block headers indefinitely. 52596 block headers requires a fixed size of approximately 4 MB.\n* In any case where you might want to specify a deeper block, you can also just as well specify a more recent one that descends from it.\n* It is assumed that 1 year is sufficient time to double-spend any common UTXOs on all blockchains of interest.\n* If a deeper check is needed, it can be softforked in. Making the check more shallow, on the other hand, is a hardfork.\n\nWhy is ParamBlockHash allowed to match less than the full block hash?\n\n* In a chain split, it is sufficient to check only a few bytes to avoid replay.\n* In all scenarios, it is likely sufficient to check only a minority of the full hash to avoid any realistic chance of replay.\n* Allowing less than the full hash to be specified saves space in transaction data.\n* Using a single byte can be combined with other opcodes (such as OP_LESSTHAN) to enable on-chain gambling logic.\n\nWhat if ParamBlockHash has leading zeros? Should this be prevented?\n\n* If leading zeros are included, they should be compared to the actual block hash. (If they were truncated, fewer bytes would be compared.)\n* It is unlikely that the leading zeros will ever be necessary for sufficient precision, so the additional space is not a concern.\n* Since all block hashes are in principle shorter than 29 bytes, ParamBlockHash may not be larger than 28 bytes.\n\nWhy is it safe to allow checking blocks as recently as the immediate previous block?\n\n* This should only be used when necessary (ie, the deeper block is not sufficient), and when the wallet can actively issue updates should the blockchain reorganise.\n* While this allows intentionally creating a transaction which may be invalid in a reorganization, the same can already be accomplished by creating double spends.\n\n==Backwards Compatibility==\n\nOP_NOP5 ought to be forbidden by policy by all miners for future extensions such as this, so old miners will under no circumstances produce blocks which would now be considered invalid under the new rules.\nHowever, miners must still upgrade to avoid accepting and building on top of such a possible invalid block as part of an attack.\n\nOld nodes will likely also not relay transactions using this opcode for the same extensibility reasons, but this is not important since the rule cannot be verified deterministically outside the context of a block.\n\n==Reference Implementation==\n\nhttps://github.com/bitcoin/bitcoin/compare/master...luke-jr:cbah", "category": "bips" }, { "instruction": "What's the deal with 
 in Bitcoin? Explain it like I'm a friend.",
    "input": "",
    "output": "BIP: 109\n  Layer: Consensus (hard fork)\n  Title: Two million byte size limit with sigop and sighash limits\n  Authors: Gavin Andresen \n  Status: Closed\n  Type: Specification\n  Assigned: 2016-01-28\n  License: PD\n
\n\n==Abstract==\n\nOne-time increase in total amount of transaction data permitted in a block from 1MB to 2MB, with limits on signature operations and hashing.\n\n==Motivation==", "category": "bips" }, { "instruction": "Can you show me the CLI commands for Mitigate potential CPU exhaustion attacks?", "input": "", "output": "==Specification==\n\n=== MAX_BLOCK_SIZE increased to 2,000,000 bytes ===\n\nThe maximum number of bytes in a canonically serialized block shall be increased from\n1,000,000 bytes to 2,000,000 bytes.\n\n=== Switch to accurately-counted sigop limit of 20,000 per block ===\n\nThe existing MAX_SIGOPS limit of 20,000 signature operations per block shall be retained,\nbut only ECDSA verifications actually performed to validate the block shall be counted.\n\nIn particular:\n\n* The coinbase scriptSig is not counted\n* Signature operations in un-executed branches of a Script are not counted\n* OP_CHECKMULTISIG evaluations are counted accurately; if the signature for a 1-of-20 OP_CHECKMULTISIG is satisfied by the public key nearest the top of the execution stack, it is counted as one signature operation. If it is satisfied by the public key nearest the bottom of the execution stack, it is counted as twenty signature operations.\n* Signature operations involving invalidly encoded signatures or public keys are not counted towards the limit\n\n=== Add a new limit of 1,300,000,000 bytes hashed to compute transaction signatures per block ===\n\nThe amount of data hashed to compute signature hashes is limited to 1,300,000,000 bytes per block. The same rules for counting are used as for counting signature operations.\n\n=== Activation: 75% hashpower support trigger, followed by 28-day 'grace period' ===\n\nSolo miners or mining pool operators express their support for this BIP by setting the fourth-highest-bit in the block's 32-bit version number (0x10000000 in hex). The first block with that bit set, a timestamp less than or equal to the expiration time, and with at least 750 out of 1000 blocks preceding it (with heights H-1000..H-1) with that bit set, shall define the beginning of a grace period. Blocks with timestamps greater than or equal to the triggering block's timestamp plus 28 days (60*60*24*28 seconds) shall be subject to the new limits.\n\nAs always, miners are expected to use their best judgement for what is best for the entire Bitcoin ecosystem when making decisions about what consensus-level changes to support.\n\n=== Expiration: 1-Jan-2018 ===\n\nIf this BIP is not triggered before 1-Jan-2018 00:00:00 GMT it should be considered withdrawn.\n\nMiners that support this BIP should set bit 0x10000000 in the block version until 1-Jan-2018. After that date, that bit can be safely re-used for future consensus rule upgrades.\n\n==Backward compatibility==\n\nFully validating older clients are not compatible with this change.\nThe first block exceeding the old limits on block size or inaccurately counted signature operations will partition older clients off the new network.\n\nSPV (simple payment validation) wallets are compatible with this change.\n\n==Rationale==\n\nIn the short term, an increase is needed to handle increasing transaction volume.\n\nThe limits on signature operations and amount of signature hashing done prevent possible CPU exhaustion attacks by \"rogue miners\" producing very expensive-to-validate two megabyte blocks. The signature hashing limit is chosen to be impossible to reach with any non-attack transaction or block, to minimize the impact on existing mining or wallet software.\n\nThe choices of constants for the deployment scheme were motivated by prior experience with upgrades to the Bitcoin consensus rules:\n\n* 0x10000000 was chosen to be compatible with the BIP 9 proposal for parallel deployment of soft forks\n* 75% was chosen instead of 95% to minimize the opportunity for a single large mining pool or miner to be able to veto an increase, either because of ideological opposition or threat of violence or extortion.\n* A four-week grace period after the voting period was chosen as a balance between giving people sufficient time to upgrade and keeping people's attention on the urgent need to upgrade.\n\n==Implementation==\n\nhttps://github.com/gavinandresen/bitcoin-git/tree/two_mb_bump\n\nSee also http://gavinandresen.ninja/a-guided-tour-of-the-2mb-fork\n\n==Copyright==\n\nThis work is placed in the public domain.", "category": "bips" }, { "instruction": "I'm stuck with 
 - what should I check?",
    "input": "",
    "output": "BIP: 151\n  Layer: Peer Services\n  Title: Peer-to-Peer Communication Encryption\n  Authors: Jonas Schnelli \n  Comments-Summary: Controversial; some recommendation, and some discouragement\n  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0151\n  Status: Closed\n  Type: Specification\n  Assigned: 2016-03-23\n  License: PD\n  Proposed-Replacement: 324\n
\n\n== Abstract ==\n\nThis BIP describes an alternative way that a peer can encrypt their communication between a selective subset of remote peers.\n\n== Motivation ==\n\n\nThe Bitcoin network does not encrypt communication between peers today. This opens up security issues (eg: traffic manipulation by others) and allows for mass surveillance / analysis of bitcoin users. Mostly this is negligible because of the nature of Bitcoin's trust model, however, for SPV nodes this can have significant privacy impacts [1] and could reduce the censorship-resistance of a peer.\n\nEncrypting peer traffic will make analysis and specific user targeting much more difficult than it currently is. Today it's trivial for a network provider or any other men-in-the-middle to identify a Bitcoin user and its controlled addresses/keys (and link with his Google profile, etc.). Just created and broadcasted transactions will reveal the amount and the payee to the network provider.\n\nThis BIP also describes a way that data manipulation (blocking commands by a intercepting TCP/IP node) would be identifiable by the communicating peers.\n\nAnalyzing the type of p2p communication would still be possible because of the characteristics (size, sending-interval, etc.) of the encrypted messages.\n\nEncrypting traffic between peers is already possible with VPN, tor, stunnel, curveCP or any other encryption mechanism on a deeper OSI level, however, most mechanisms are not practical for SPV or other DHCP/NAT environment and will require significant knowhow in how to setup such a secure channel.\n\n== Specification ==\n\nA peer that supports encryption must accept encryption requests from all peers.\n\nAn independent ECDH negotiation for both communication directions is required and therefore a bidirectional communication will use two symmetric cipher keys (one per direction).\n\nBoth peers must only send encrypted messages after a successful ECDH negotiation in ''both directions''.\n\nEncryption initialization must happen before sending any other messages to the responding peer (encinit message after a version message must be ignored).\n\n=== Symmetric Encryption Cipher Keys ===\n\nThe symmetric encryption cipher keys will be calculated with ECDH/HKDF by sharing the pubkeys of an ephemeral key. Once the ECDH secret is calculated on each side, the symmetric encryption cipher keys must be derived with HKDF [2] after the following specification:\n\n1. HKDF extraction\nPRK = HKDF_EXTRACT(hash=SHA256, salt=\"bitcoinecdh\", ikm=ecdh_secret|cipher-type).\n\n2. Derive Key1\nK_1 = HKDF_EXPAND(prk=PRK, hash=SHA256, info=\"BitcoinK1\", L=32)\n\n3. Derive Key2\nK_2 = HKDF_EXPAND(prk=PRK, hash=SHA256, info=\"BitcoinK2\", L=32)\n\nIt is important to include the cipher-type into the symmetric cipher key derivation to avoid weak-cipher-attacks.\n\n=== Session ID ===\n\nBoth sides must also calculate the 256bit session-id using SID = HKDF_EXPAND(prk=PRK, hash=SHA256, info=\"BitcoinSessionID\", L=32). The session-id can be used for linking the encryption-session to an identity check.\n\n=== The encinit message type ===\n\nTo request encrypted communication, the requesting peer generates an EC ephemeral-session-keypair and sends an encinit message to the responding peer and waits for an encack message. The responding node must do the same encinit/encack interaction for the opposite communication direction.\n\n{|class=\"wikitable\"\n! Field Size !! Description !! Data type !! Comments\n|-\n| 33bytes || ephemeral-pubkey || comp.-pubkey || The session pubkey from the requesting peer\n|-\n| 1bytes || symmetric key cipher type || int8 || symmetric key cipher type to use\n|}\n\nPossible symmetric key ciphers types\n{|class=\"wikitable\"\n! Number !! symmetric key ciphers type\n|-\n| 0 || chacha20-poly1305@openssh.com\n|}\n\n=== ChaCha20-Poly1305 Cipher Suite ===\n\nChaCha20 is a stream cipher designed by Daniel Bernstein [3]. It operates by permuting 128 fixed bits, 128 or 256 bits of key,\na 64 bit nonce and a 64 bit counter into 64 bytes of output. This output is used as a keystream, with any unused bytes simply discarded.\n\nPoly1305, also by Daniel Bernstein [4], is a one-time Carter-Wegman MAC that computes a 128 bit integrity tag given a message and a single-use\n256 bit secret key.\n\nThe chacha20-poly1305@openssh.com specified and defined by openssh [5] combines these two primitives into an authenticated encryption mode. The construction used is based on that proposed for TLS by Adam Langley [6], but differs in the layout of data passed to the MAC and in the addition of encryption of the packet lengths.\n\nK_1 must be used to only encrypt the payload size of the encrypted message to avoid leaking information by revealing the message size.\n\nK_2 must be used in conjunction with poly1305 to build an AEAD.\n\nOptimized implementations of ChaCha20-Poly1305 are very fast in general, therefore it is very likely that encrypted messages require less CPU cycles per byte than the current unencrypted p2p message format. A quick analysis by Pieter Wuille of the current ''standard implementations'' has shown that SHA256 requires more CPU cycles per byte than ChaCha20 & Poly1304.\n\n=== The encack message type ===\n\nThe responding peer accepts the encryption request by sending an encack message.\n\n{|class=\"wikitable\"\n! Field Size !! Description !! Data type !! Comments\n|-\n| 33bytes || ephemeral-pubkey || comp.-pubkey || The session pubkey from the responding peer\n|}\n\nAt this point, the shared secret key for the symmetric key cipher must be calculated by using ECDH (own privkey x remote pub key).\nPrivate keys will never be transmitted. The shared secret can only be calculated if an attacker knows at least one private key and the remote peer's public key.\n\n* '''The encinit/encack interaction must be done from both sides.'''\n* Each communication direction uses its own secret key for the symmetric cipher.\n* The second encinit request (from the responding peer) must use the same symmetric cipher type.\n* All unencrypted messages before the second encack response (from the responding peer) must be ignored.\n* After a successful encinit/encack interaction, the \"encrypted messages structure\" must be used. Non-encrypted messages from the requesting peer must lead to a connection termination.\n\nAfter a successful encinit/encack interaction from both sides, the messages format must use the \"encrypted messages structure\". Non-encrypted messages from the requesting peer must lead to a connection termination (can be detected by the 4 byte network magic in the unencrypted message structure).\n\n=== Encrypted Messages Structure ===\n\n{|class=\"wikitable\"\n! Field Size !! Description !! Data type !! Comments\n|-\n| 4 || length || uint32_t || Length of ciphertext payload in number of bytes\n|-\n| ? || ciphertext payload || ? || One or many ciphertext command & message data\n|-\n| 16 || MAC tag || ? || 128bit MAC-tag\n|}\n\nEncrypted messages do not have the 4byte network magic.\n\nThe maximum message length needs to be chosen carefully. The 4 byte length field can lead to a required message buffer of 4 GiB.\nProcessing the message before the authentication succeeds must not be done.\n\nThe 4byte sha256 checksum is no longer required because the AEAD.\n\nBoth peers need to track the message sequence number (uint32) of sent messages to the remote peer for building a 64 bit symmetric cipher IV. Sequence numbers are allowed to overflow to zero after 4294967295 (2^32-1).\n\nThe encrypted payload will result decrypted in one or many unencrypted messages:\n\n{|class=\"wikitable\"\n! Field Size !! Description !! Data type !! Comments\n|-\n| ? || command || varlen || ASCII string identifying the packet content, we are using varlen in the encrypted messages.\n|-\n| 4 || length || uint32_t || Length of plaintext payload\n|-\n| ? || payload || ? || The actual data\n|}\nIf more data is present, another message must be deserialized. There is no explicit amount-of-messages integer.\n\n\n=== Re-Keying ===\n\nA responding peer can inform the requesting peer over a re-keying with an encack message containing 33byte of zeros to indicate that all encrypted message following after this encack message will be encrypted with ''the next symmetric cipher key''.\n\nThe new symmetric cipher key will be calculated by SHA256(SHA256(session_id || old_symmetric_cipher_key)).\n\nRe-Keying interval is a peer policy with a minimum timespan of 10 seconds.\n\nThe Re-Keying must be done after every 1GB of data sent or received (recommended by RFC4253 SSH Transport).\n\n=== Risks ===\n\nThe encryption does not include an identity authentication scheme. This BIP does not cover a proposal to avoid MITM attacks during the encryption initialization.\n\nIdentity authentication will be covered in another BIP and will presume communication encryption after this BIP.\n\n== Compatibility ==\n\nThis proposal is backward compatible. Non-supporting peers will ignore the encinit messages.\n\n== Reference implementation ==\n\n== References ==\n\n* [1] https://e-collection.library.ethz.ch/eserv/eth:48205/eth-48205-01.pdf\n* [2] HKDF (RFC 5869) https://tools.ietf.org/html/rfc5869\n* [3] ChaCha20 https://cr.yp.to/chacha/chacha-20080128.pdf\n* [4] Poly1305 https://cr.yp.to/mac/poly1305-20050329.pdf\n* [5] https://github.com/openssh/openssh-portable/blob/05855bf2ce7d5cd0a6db18bc0b4214ed5ef7516d/PROTOCOL.chacha20poly1305\n* [6] \"ChaCha20 and Poly1305 based Cipher Suites for TLS\", Adam Langley https://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-03\n\n== Acknowledgements ==\n* Pieter Wuille and Gregory Maxwell for most of the ideas in this BIP.\n\n== Copyright ==\nThis work is placed in the public domain.", "category": "bips" }, { "instruction": "How do I troubleshoot 
 issues?",
    "input": "",
    "output": "BIP: 128\n  Layer: Applications\n  Title: Timelock-Recovery Storage Format\n  Authors: Oren Z \n  Status: Draft\n  Type: Specification\n  Assigned: 2026-02-05\n  License: BSD-2-Clause\n  Discussion: https://groups.google.com/g/bitcoindev/c/K1NpJp9_BYk\n
\n\n== Abstract ==\n\nThis document proposes a standard format for saving timelock-recovery plans, to allow different\nwallets to generate them, and different services to monitor/execute them.\n\n== Motivation ==\n\nPre-signed transactions are one way to create a recovery-plan, for use in case of seed loss or\ninheritance.\nThe most common example is a single pre-signed transaction with an nLocktime set to a\nfuture date, as explained in [[bip-0065.mediawiki|BIP-65]].\nOne limitation of this approach is that in the happy-flow scenario, when the seed is not lost,\nand the nLocktime is about to be reached, the user must access their wallet and spend\none of its UTXOs - in order to revoke the pre-signed transaction and prevent it from being able to\nmove the funds with no cancellation period.\nThis could be frustrating, for example, for users that split their seed over multiple geographic\nlocations.\n\n''Timelock-Recovery plans'' are a way to pre-sign a pair of transactions that eventually move the\nfunds to one or more secondary wallets - with a special nSequence relative-locktime\nin the second transaction, so that the user always has a cancellation-period.\n\nExecuting and monitoring a ''Timelock-Recovery plan'' thus requires more than broadcasting and\nmonitoring a single transaction. It also requires mechanisms for accelerating the first\ntransaction (which does not move most funds to the secondary wallet), for checking whether\nthe relative-timelock has passed, and a more nuanced handling of reorgs.\n\nThis BIP proposes a standard format for exporting ''Timelock-Recovery plans'' from the wallet that\ngenerated them, and importing them into apps/services for monitoring/execution.\n\n=== Comparison with Script-Based Wallets ===\n\nScript-based wallets are another way to create recovery mechanisms, and can use absolute and\nrelative locktimes using OP_CHECKLOCKTIMEVERIFY ([[bip-0065.mediawiki|BIP-65]]) and\nOP_CHECKSEQUENCEVERIFY ([[bip-0112.mediawiki|BIP-112]]).\nFor example, we can build a script that allows one main key to spend the funds at any time,\nand a secondary key to spend the funds only in transactions with nLocktime above a certain\ndate/block-height, or only in transactions with nSequence above a certain relative\ntime-gap/number-of-blocks.\nThis makes the secondary key useful only after an absolute date/block-height, or after\na relative time since the funds were received (each UTXO independently).\nThis approach does have some advantages over pre-signed transactions, for example the\nrecovery-mechanism automatically applies to new funds received into the wallet.\n\nHowever, script-based wallets have some disadvantages over a sequence of\npre-signed transactions:\n\n* Script-based wallets are harder to implement correctly by hardware wallets, and harder to backup properly (i.e. users may forget to backup wallet-descriptors even for basic multisig wallets).\n* As of the time of writing, scripts can limit when secondary-keys can be used, but not how they can be used: if the user doesn't touch the wallets' UTXOs for long-enough time, the secondary key will eventually become useable and could move the funds anywhere. This is true whether we measure the time in absolute terms (OP_CHECKLOCKTIMEVERIFY) or relative terms compared to when the wallets' UTXOs were created (OP_CHECKSEQUENCEVERIFY). This means that even in the happy-flow scenario of an untouched wallet, where no recovery is needed, the user must periodically \"renew\" the recovery-mechanism by spending the UTXO to a new wallet/address. This may be inconvenient in ultra-cold-storage scenarios (i.e. multisig with main keys hidden in different geographic locations). New opcode suggestions, such as OP_CHECKTEMPLATEVERIFY ([[bip-0119.mediawiki|BIP-119]]) and OP_CHECKCONTRACTVERIFY ([[bip-0443.mediawiki|BIP-443]]), discuss possible recovery-mechanisms in which in order for a secondary key to have full control over the funds, some onchain operations must be performed, with a required time-gap between them - giving the user enough time to revoke the whole process and move the funds elsewhere (assuming they still have the main key and the recovery-mechanism was triggered unintentionally). However, these suggestions are still in the discussion phase and even if ever implemented, their adoption may be slow.\n* New Bitcoiners today typically don't think of such recovery-mechanisms in advance, and start with a P2WPKH wallet. They can pre-sign transactions with this wallet, but to utilize script-based features they would need to create a new wallet and move the funds there - an operation that might seem intimidating for large amounts.\n\n== Specification ==\n\nA ''Timelock-Recovery plan'' consists of two transactions:\n\n* ''Alert Transaction'': A mostly-consolidation transaction that keeps most funds in the original wallet, except for a fee and a small fixed amount that goes to ''anchor-addresses'' - addresses which can be used to accelerate the ''Alert Transaction'' via CPFP. The majority of funds should remain on the original wallet, in a new previously-unused address which we call the ''alert-address''. We use the term ''Alert Transaction'' because monitoring the blockchain and looking for it should alert the user that the recovery-plan has been initiated (intentionally, unintentionally or maliciously).\n* ''Recovery Transaction'': The transaction that moves the funds from the alert-address UTXO from the ''Alert Transaction'' to one or more addresses of secondary wallets (each may receive a different amount). This transaction should have a special nSequence relative-locktime according to the size of cancellation-period requested by the user, following the rules of [[bip-0068.mediawiki|BIP-68]].\n\nWith a reliable tool to monitor the blockchain for the ''Alert Transaction''\nor the ''Alert Address'', the user can safely store online backups of the recovery plan's\nJSON file (or, even without a tool, by checking the blockchain manually from time to time).\nIf the presigned transactions leak and the ''Alert Transaction'' is broadcast\nunintentionally, the user has the cancellation period (expected to be at least a\nfew days) to prevent most funds from moving by sending them to a new address, thereby\ninvalidating the ''Recovery Transaction''.\n\nIt is important that the ''Alert Transaction'' will be non-malleable (e.g. by using\n[[bip-0140.mediawiki|BIP-140]]).\nIf a malleable ''Alert Transaction'' is used, a malicious miner could replace the\n''Alert Transaction'' with a similar transaction with a different txid,\nmaking the ''Recovery Transaction'' invalid (pointing to a non-existent UTXO).\n\nThe nLocktime of both transactions should not be higher than the current\nblock height.\n\nThe ''anchor-addresses'' mentioned above, which are used for CPFP acceleration, could possibly\nbe P2A addresses (described in [[bip-0433.mediawiki|BIP-433]]), or other addresses under the\nparticipants' control (i.e. addresses from the secondary wallets).\nAs of the time of writing, P2A is not widely adopted, and less-technical users may\nstruggle using them for CPFP acceleration - so we currently recommend using regular addresses.\n\n=== nSequence calculation ===\n\nUsers will specify the cancellation-period in whole days between 2-388.\n\nFollowing [[bip-0068.mediawiki|BIP-68]], the nSequence can represent a timespan in\nunits of 512 seconds, when bit (1 << 22) is set. An example calculation is provided below:\n\n\nn_sequence = (1 << 22) | round(cancellation_period_days * 24 * 60 * 60 / 512)\n\n\nUsers should be notified that the cancellation-period is not guaranteed to be exact (due to miners'\nmanipulation of block-timestamps).\n\nLess than 2 days of cancellation-period and partial-days are not supported, as they are not useful.\n\nMore than 388 days of cancellation-period will overflow the nSequence field bits\nallocated for the relative-locktime, and is not supported.\n\n=== JSON format ===\n\nFor simplicity, this BIP proposes that a ''Timelock-Recovery plan'' will be saved as a JSON\nobject.\n\nThe JSON object will have the following fields:\n\n* kind (mandatory): must be \"timelock-recovery-plan\".\n* id (mandatory): a non-empty string of up to 100 characters, to represent the plan uniquely (i.e. a UUID, or a server generated ID).\n* name (optional): a name for the plan, decided by the user. A string of up to 200 characters.\n* description (optional): a description for the plan, decided by the user. A string of up to 10,000 characters.\n* created_at (mandatory): an ISO 8601 timestamp of the plan creation time, including timezone offset ('Z' if the timezone is UTC).\n* plugin_version (optional): The version of the plugin that generated the plan. A string of up to 100 characters.\n* wallet_version (mandatory): The version of the wallet that generated the plan. A string of up to 100 characters.\n* wallet_name (mandatory): The human-readable name of the wallet app that generated the plan. A string of up to 100 characters.\n* wallet_kind (mandatory): The internal name of the wallet app that generated the plan. A string of up to 100 characters.\n* timelock_days (mandatory): The cancellation period in whole days. A number between 2 and 388.\n* anchor_amount_sats (mandatory): The amount in satoshis sent to each anchor address in the Alert Transaction. We recommend using 600 sats, which is above the dust limit.\n* anchor_addresses (mandatory): An array of up to 10,000 Bitcoin addresses that receive the anchor amount in the Alert Transaction. Each address is a string of up to 100 characters.\n* alert_address (mandatory): The Bitcoin address that receives the majority of funds in the Alert Transaction. A string of up to 100 characters.\n* alert_inputs (mandatory): An array of up to 2439 inputs spent by the Alert Transaction. Each input is a string in the format \"txid:vout\" where txid is a 64-character lowercase hexadecimal string and vout is a decimal number of up to 6 digits. The maximal length of 2439 is calculated from a standard transaction of 400,000 wu where each input contains at least 41 bytes.\n* alert_tx (mandatory): The raw Alert Transaction in uppercase hexadecimal format. A string of up to 800,000 characters.\n* alert_txid (mandatory): The transaction ID of the Alert Transaction. A 64-character lowercase hexadecimal string.\n* alert_fee (mandatory): The total fee paid by the Alert Transaction in satoshis. A non-negative integer.\n* alert_weight (mandatory): The weight of the Alert Transaction. A positive integer, not higher than 400,000.\n* recovery_tx (mandatory): The raw Recovery Transaction in uppercase hexadecimal format. A string of up to 800,000 characters.\n* recovery_txid (mandatory): The transaction ID of the Recovery Transaction. A 64-character lowercase hexadecimal string.\n* recovery_fee (mandatory): The total fee paid by the Recovery Transaction in satoshis. A non-negative integer.\n* recovery_weight (mandatory): The weight of the Recovery Transaction. A positive integer, not higher than 400,000.\n* recovery_outputs (mandatory): An array of up to 10,000 outputs from the Recovery Transaction. Each output is a tuple containing: [address, amount_sats, label?] where:\n** address is a mandatory Bitcoin address string (up to 100 characters).\n** amount_sats is a mandatory positive integer representing the amount in satoshis.\n** label is an optional string of up to 200 characters.\n* metadata (optional): A string of up to 10,000 characters for additional metadata, for example a digital-signature.\n* checksum (mandatory): A checksum for verifying the integrity of the plan. A string of 8 to 64 characters.\n\n=== Checksum Calculation ===\nNotice that besides the top-level JSON object, all the internal values are either primitive or\narrays.\nThis is intentional, so a conversion of the values to JSON strings will be deterministic.\n\nThe checksum is calculated by converting the top-level JSON object to an array of\n[key, value] pairs, sorting the array, stringifying, calculating the\nSHA256 hash of the result in lowercase hexadecimal format, and taking a prefix of at least 8\ncharacters.\n\n\"stringifying\" in this context means converting the array to a JSON string following\n[https://262.ecma-international.org/16.0/index.html#sec-json.stringify ECMAScript's JSON.stringify function specification]\n(without additional replacer or space arguments).\nThis specification covers special cases such as non-ascii characters and newlines.\n\nOptional fields without a value should not be included in the key-value pairs array.\nAlso, there should not be a key-value pair for the \"checksum\" field itself.\n\nCode example:\n\ndelete recoveryPlanJson.checksum; // In case the checksum was calculated previously and the object was then modified\nconst checksumData = new TextEncoder().encode(\n JSON.stringify(Object.entries(recoveryPlanJson).sort()),\n);\nconst checksum = new Uint8Array(await crypto.subtle.digest('SHA-256', checksumData));\nrecoveryPlanJson.checksum = Array.from(checksum).map(b => b.toString(16).padStart(2, '0')).join('').slice(0, 8);\n\n\nChecksum hex string should be at least 8 characters long. Wallets may choose to use a longer\nchecksum.\n\n== Rationale ==\n\nThe JSON object will contain the raw transactions, in addition to other information - some of\nwhich could technically be extracted from the raw transactions. This is intentional, to let\nfrontend UIs display the plan before uploading it to any service, without the need for\ncomplicated parsing in the frontend.\n\nBackend services that receive the JSON object for monitoring/execution are expected to validate\nthat the information is consistent with the raw transactions.\n\nAlso, if some wallet apps did not implement the specifications correctly, the services could\nwrite custom code based on the wallet_kind, wallet_version and\nplugin_version fields.\n\nServers may decide to put more restrictions on JSON objects, for example to refuse\nstoring very large transactions.\n\nNotice that the raw transactions (alert_tx and recovery_tx) are expected\nto be in uppercase hexadecimal format.\nThis is useful for frontend UIs to display them as QR codes, which are more compact when using\nuppercase-only alphanumeric characters.\n\n=== Monitoring Timelock-Recovery Plans ===\n\nChecking whether the Alert Transaction is valid is trivial, via the\ntestmempoolaccept RPC call in bitcoin core 0.17+.\n\nHowever, checking whether the Recovery Transaction is valid is more complex,\nsince it depends on a UTXO created by the Alert Transaction.\n\nThe testmempoolaccept RPC can receive a list of transactions in which the later\ntransactions may depend on earlier transactions - however in our case the\nRecovery Transaction has an nSequence relative-locktime, and therefore\ncalling testmempoolaccept 'alert-tx' 'recovery-tx' will fail, claiming that the\nAlert Transaction UTXO is not confirmed (and the required time window has not passed).\n\nWe recommend services that want to verify the entire Timelock-Recovery plan to parse\nthe Recovery Transaction and check its signatures manually, and reject complicated\nspending scripts. Discovering that the Recovery Transaction is invalid only at the\ntime of execution, could lead to funds being locked forever.\n\n== Reference Implementation ==\n\nJSON files can be generated using the Timelock Recovery plugin on\n[https://electrum.org Electrum Wallet]:\n\nhttps://github.com/spesmilo/electrum/tree/master/electrum/plugins/timelock_recovery\n\nDemo Video: https://drive.google.com/file/d/10uXRouQbH1kz_HC14WnmRnYHa3gPZY8l/preview\n\nExample JSON file:\n\n\n{\n \"kind\": \"timelock-recovery-plan\",\n \"id\": \"exported-692452189b301b561ed57cbe\",\n \"name\": \"Recovery Plan ac300e72-7612-497e-96b0-df2fdeda59ea\",\n \"description\": \"RITREK APP 1.1.0: Trezor Account #1\",\n \"created_at\": \"2025-11-24T12:39:53.532Z\",\n \"plugin_version\": \"1.0.1\",\n \"wallet_version\": \"1.0.1\",\n \"wallet_name\": \"RITREK Service\",\n \"wallet_kind\": \"RITREK BACKEND\",\n \"timelock_days\": 2,\n \"anchor_amount_sats\": 600,\n \"anchor_addresses\": [\n \"bc1qnda6x2gxdh3yujd2zjpsd7qzx3awxmlaf9wwlk\"\n ],\n \"alert_address\": \"bc1qj0f9sjenwyjs0u7mlgvptjp05z3syzq7mru3ep\",\n \"alert_inputs\": [\n \"a265a485df4c6417019b91379257eb387bceeda96f7bb6311794b8ed358cf104:0\",\n \"2f621c2151f33173983133cbc1000e3b603b8a18423b0379feffe8513171d5d3:0\"\n ],\n \"alert_tx\": \"0200000000010204F18C35EDB8941731B67B6FA9EDCE7B38EB579237919B0117644CDF85A465A20000000000FDFFFFFFD3D5713151E8FFFE79033B42188A3B603B0E00C1CB3331987331F351211C622F0000000000FDFFFFFF0258020000000000001600149B7BA329066DE24E49AA148306F802347AE36FFD205600000000000016001493D2584B33712507F3DBFA1815C82FA0A302081E02483045022100DCDBAE77C35EB4A0B3ED0DE5484206AB6B07041BE99B2BBAF0243C125916523C0220396959C3C52B2B1F9E472AEEE7C5D9540531B131C3221DE942754C6D0941397D012103C08FF3ADBA14B742646572BCA6F07AEB910666FB28E4DDDC40E33755E7C869D30248304502210089084472FDA3CF82D6ABC11BF1A5E77C9B423617C8B840F58C02746035B3BA6302203942AA1FA13F952F49FB114D48130A9AAF70151E7D09036D15734DB1F41A8B6001210397064EDED7DAD7D662290DC2847E87C5C27DA8865B89DDB58FDE9A006BA7DB3900000000\",\n \"alert_txid\": \"f1413fedadaf30697820bcd8f6a393fcc73ea00a15bea3253f89d5658690d2f7\",\n \"alert_fee\": 231,\n \"alert_weight\": 834,\n \"recovery_tx\": \"02000000000101F7D2908665D5893F25A3BE150AA03EC7FC93A3F6D8BC20786930AFADED3F41F101000000005201400001A6550000000000001600149B7BA329066DE24E49AA148306F802347AE36FFD0247304402204AFF87C2127F5697F300C6522067A8D5E5290CA8D140D2E5BCEF4A36606C5FE5022056673BEC5BB459DFFBD4D266EE95AEF0D701383ED80BD433A02C3C486A826D76012102774DBCD59F2D08EFF718BC09972ADC609FBC31C26B551B3E4EA30A1D43EEDB9700000000\",\n \"recovery_txid\": \"bc304610e8f282036345e87163d4cba5b16488a3bf2e4d738379d7bda3a0bca3\",\n \"recovery_fee\": 122,\n \"recovery_weight\": 437,\n \"recovery_outputs\": [\n [\n \"bc1qnda6x2gxdh3yujd2zjpsd7qzx3awxmlaf9wwlk\",\n 21926,\n \"My Backup Wallet\"\n ]\n ],\n \"metadata\": \"sig:825d6b3858c175c7fc16da3134030e095c4f9089c3c89722247eeedc08a7ef4f\",\n \"checksum\": \"92f8b3da\"\n}\n\n\n== Copyright ==\n\nThis document is licensed under the 2-clause BSD license.", "category": "bips" }, { "instruction": "What are the best practices for 
?",
    "input": "",
    "output": "BIP: 328\n  Layer: Applications\n  Title: Derivation Scheme for MuSig2 Aggregate Keys\n  Authors: Ava Chow \n  Status: Complete\n  Type: Informational\n  Assigned: 2024-06-04\n  License: CC0-1.0\n
\n\n==Abstract==\n\nThis document specifies how BIP 32 extended public keys can be constructed from a BIP 327 MuSig2\naggregate public key and how such keys should be used for key derivation.\n\n==Copyright==\n\nThis BIP is licensed under the Creative Commons CC0 1.0 Universal license.\n\n==Motivation==\n\nMultiple signers can create a single aggregate public key with MuSig2 that is indistinguishable\nfrom a random public key. The cosigners need a method for generating additional aggregate pubkeys\nto follow the best practice of using a new address for every payment.\n\nThe obvious method is for the cosigners to generate multiple public keys and produce a\nnew aggregate pubkey every time one is needed. This is similar to how multisig using Bitcoin script\nworks where all of the cosigners share their extended public keys and do derivation to produce\nthe multisig script. The same could be done with MuSig2 and instead of producing a multisig script,\nthe result would be a MuSig2 aggregate pubkey.\n\nHowever, it is much simpler to be able to derive from a single extended public key instead of having\nto derive from many extended public keys and aggregate them. As MuSig2 produces a normal looking\npublic key, the aggregate public can be used in this way. This reduces the storage and computation\nrequirements for generating new aggregate pubkeys.\n\n==Specification==\n\nA synthetic xpub can be created from a BIP 327 MuSig2 plain aggregate public key by setting\nthe depth to 0, the child number to 0, and attaching a chaincode with the byte string\n868087ca02a6f974c4598924c36b57762d32cb45717167e300622c7167e38965'''Where does this\nconstant chaincode come from?''' It is the SHA256 of the text MuSig2MuSig2MuSig2.\nThis fixed chaincode should be used by all such synthetic xpubs following this specification.\nUnhardened child public keys can be derived from the synthetic xpub as with any other xpub. Since\nthe aggregate public key is all that is necessary to produce the synthetic xpub, any aggregate\npublic key that will be used in this way shares the same privacy concerns as typical xpubs.\n\nFurthermore, as there is no aggregate private key, only unhardened derivation from the aggregate\npublic key is possible.\n\nWhen signing, all signers must compute the tweaks used in the BIP 32 derivation for the child key\nbeing signed for. The IL value computed in ''CKDpub'' is the tweak used at each\nderivation step. These are provided in the session context, each with a tweak mode of plain\n(''is_xonly_t = false''). When the ''Sign'' algorithm is used, the tweaks will be applied to the\npartial signatures.\n\n==Test Vectors==\n\n* Aggregate pubkey 0354240c76b8f2999143301a99c7f721ee57eee0bce401df3afeaa9ae218c70f23\n** Synthetic xpub xpub661MyMwAqRbcFt6tk3uaczE1y6EvM1TqXvawXcYmFEWijEM4PDBnuCXwwXEKGEouzXE6QLLRxjatMcLLzJ5LV5Nib1BN7vJg6yp45yHHRbm\n** Keys:\n*** 03935F972DA013F80AE011890FA89B67A27B7BE6CCB24D3274D18B2D4067F261A9\n*** 02F9308A019258C31049344F85F89D5229B531C845836F99B08601F113BCE036F9\n* Aggregate pubkey 0290539eede565f5d054f32cc0c220126889ed1e5d193baf15aef344fe59d4610c\n** Synthetic xpub xpub661MyMwAqRbcFt6tk3uaczE1y6EvM1TqXvawXcYmFEWijEM4PDBnuCXwwVk5TFJk8Tw5WAdV3DhrGfbFA216sE9BsQQiSFTdudkETnKdg8k\n** Keys:\n*** 02F9308A019258C31049344F85F89D5229B531C845836F99B08601F113BCE036F9\n*** 03DFF1D77F2A671C5F36183726DB2341BE58FEAE1DA2DECED843240F7B502BA659\n*** 023590A94E768F8E1815C2F24B4D80A8E3149316C3518CE7B7AD338368D038CA66\n* Aggregate pubkey 022479f134cdb266141dab1a023cbba30a870f8995b95a91fc8464e56a7d41f8ea\n** Synthetic xpub xpub661MyMwAqRbcFt6tk3uaczE1y6EvM1TqXvawXcYmFEWijEM4PDBnuCXwwUvaZYpysLX4wN59tjwU5pBuDjNrPEJbfxjLwn7ruzbXTcUTHkZ\n** Keys:\n*** 02DFF1D77F2A671C5F36183726DB2341BE58FEAE1DA2DECED843240F7B502BA659\n*** 023590A94E768F8E1815C2F24B4D80A8E3149316C3518CE7B7AD338368D038CA66\n*** 02F9308A019258C31049344F85F89D5229B531C845836F99B08601F113BCE036F9\n*** 03935F972DA013F80AE011890FA89B67A27B7BE6CCB24D3274D18B2D4067F261A9\n\n==Backwards Compatibility==\n\nOnce a synthetic xpub is created, it is fully backwards compatible with BIP 32 - only unhardened\nderivation can be done, and the signers will be able to produce a signature for any derived children.\n\n==Rationale==\n\n\n\n==Reference Implementation==\n\nA Python reference implementation is available in this BIP's [[bip-0328|Auxiliary Files]].\n\n==Acknowledgements==\n\nThanks to Pieter Wuille, Andrew Poelstra, Sanket Kanjalkar, Salvatore Ingala, and all others who\nparticipated in discussions on this topic.", "category": "bips" }, { "instruction": "Walk me through setting up 
 step by step",
    "input": "",
    "output": "BIP: 321\n  Layer: Applications\n  Title: URI Scheme\n  Authors: Matt Corallo \n  Status: Complete\n  Type: Specification\n  Assigned: 2024-11-15\n  License: BSD-2-Clause\n  Replaces: 21\n
\n\n== Copyright ==\n\nThis BIP is licensed under the BSD 2-clause license.\n\n== Abstract ==\n\nThis BIP proposes a URI scheme for describing Bitcoin payment instructions.\n\n== Motivation ==\n\nThe purpose of this URI scheme is to enable users to easily make payments by simply clicking links on webpages or scanning QR Codes.\n\nThis BIP is a modification and intended replacement of [[bip-0021.mediawiki|BIP 0021]] to add information about the modern usage of bitcoin: URIs (including standard query parameters and modern address types) as well as provide forward-looking guidance on how to incorporate new payment instructions. It further adds an optional extension to provide the payment initiator with proof of payment. BIP 21 was based on BIP 20, which was, in turn based on an earlier document by Nils Schneider.\n\n== Specification ==\n\n=== General rules for handling (important!) ===\n\nBitcoin clients MUST NOT act on URIs without getting the user's authorization.\nThey SHOULD require the user to manually approve each payment individually, though in some cases they MAY allow the user to automatically make this decision.\n\n=== Operating system integration ===\n\nGraphical bitcoin clients SHOULD register themselves as the handler for the \"bitcoin:\" URI scheme by default, if no other handler is already registered. If there is already a registered handler, they MAY prompt the user to change it once when they first run the client.\n\n=== General Format ===\n\nBitcoin URIs follow the general format for URIs as set forth in RFC 3986. The path component consists of a bitcoin address, and the query component provides additional payment options.\n\nElements of the query component may contain characters outside the valid range. These must first be encoded according to UTF-8, and then each octet of the corresponding UTF-8 sequence must be percent-encoded as described in RFC 3986.\n\n=== ABNF grammar ===\n\n bitcoinurn = \"bitcoin:\" [ bitcoinaddress ] [ \"?\" bitcoinparams ]\n bitcoinaddress = *base58 / *bech32 / *bech32m\n bitcoinparams = bitcoinparam [ \"&\" bitcoinparams ]\n bitcoinparam = [ amountparam / labelparam / messageparam / responseparam / otherparam / reqparam ]\n amountparam = \"amount=\" *digit [ \".\" *digit ]\n labelparam = \"label=\" *qchar\n messageparam = \"message=\" *qchar\n responseparam = [ \"req-\" ] \"pop=\" *qchar\n otherparam = qchar *qchar [ \"=\" *qchar ]\n reqparam = \"req-\" qchar *qchar [ \"=\" *qchar ]\n\nHere, \"qchar\" corresponds to valid characters of an RFC 3986 URI query component, excluding the \"=\" and \"&\" characters, which this BIP takes as separators.\n\nThe scheme component (\"bitcoin:\") is case-insensitive, and implementations must accept any combination of uppercase and lowercase letters. The query parameter keys are also case-insensitive. Query parameter values and bitcoin address fields may be case-sensitive depending on their content.\n\nMultiple query parameters with the same key MAY be included for query parameters representing payment instructions. Multiple query parameters with the same key MUST NOT be included for keys \"label\", \"message\", or \"pop\". Multiple query parameters with the same key for other keys MUST be allowed for unknown query parameters. Future query parameter keys may or may not allow for duplicate parameters.\n\n=== Bitcoin Address ===\n\nThe bitcoinaddress body MUST be either a base58 P2SH or P2PKH address, bech32 Segwit version 0 address, bech32m Segwit address, or empty. Future address formats SHOULD instead be placed in query keys as optional payment instructions to provide backwards compatibility during upgrade cycles. The bitcoinaddress part of the URI MAY be left empty if there is at least one payment instruction provided in a query parameter, allowing for recipients wishing to avoid a standard on-chain fallback.\n\n=== Query Keys ===\n\nThe following keys are defined generally and apply to any URI regardless of payment instructions:\n\n*label: Label for the recipient (e.g. name of receiver)\n*message: message that describes the transaction to the user ([[#examples|see examples below]])\n*pop: a URI which the Bitcoin Wallet may return to in order to provide the application which initiated the payment with proof that a payment was completed.\n\nThe following keys are currently defined for payment instructions of various forms:\n\n*lightning: Lightning BOLT 11 invoices\n*lno: Lightning BOLT12 offers\n*pay: [[bip-0351.mediawiki|BIP 351 Private Payment addresses]]\n*sp: [[bip-0352.mediawiki|BIP 352 Silent Payment addresses]]\n\nNew payment instructions using bech32 or bech32m encodings SHOULD reuse their address format's Human Readable Part as the parameter key.\n\n==== Transfer amount ====\n\nIf an amount is provided, it MUST be specified in decimal BTC.\nAll amounts MUST contain no commas and use a period (.) as the separating character to separate whole numbers and decimal fractions.\nI.e. amount=50.00 or amount=50 is treated as 50 BTC, and amount=50,000.00 is invalid.\n\n=== Proof of Payment ===\n\nThe URI MAY include a \"pop\" (or \"req-pop\") parameter whose value can be used to build a URI which the wallet application can, after payment completes, \"open\" to provide proof the payment was completed or other information about the payment.\n\nThe value of a \"pop\" (or \"req-pop\") parameter shall be a percent-encoded (per RFC 3986 section 2.1) URI prefix. The wallet application, if it supports providing payment information SHOULD percent-decode the provided URI once, append the query parameter key from which the payment instructions used were read, append a single =, and finally append the Payment Information to the resulting URI and open it with the default system handler for the URI. For payment instructions read from the body of the URI, \"onchain\" SHALL be used in place of the key.\n\nA wallet MUST validate that the provided URI's scheme is not (case-insensitive) \"http\", \"https\", \"file\", \"javascript\", \"mailto\" or any other scheme which will open in a web browser prior to opening it.\n\nIf a wallet will not open the pop scheme (either because it does not support returning payment information for the selected payment method or because it uses a URI scheme which should not be opened) and the parameter was passed as a \"req-pop\" parameter, the wallet MUST NOT initiate payment.\n\nFor payments made using an on-chain transaction, the Payment Information shall be the full (including witness data) Bitcoin transaction as it was broadcasted to the Bitcoin network, encoded in hex.\n\nFor payments made using a BOLT 11 invoice (communicated via the `lightning` parameter), the Payment Information shall be the hex-encoded payment preimage.\n\nOther payment schemes will define their own Payment Information format. This BIP may be updated from time to time with Payment Information formats for other payment schemes.\n\n== Rationale ==\n\n=== Payment identifiers, not person identifiers ===\n\nBest practices are that a unique address should be used for every transaction on-chain.\nTherefore, a URI which contains an on-chain payment address MUST NOT represent an exchange of personal information, but a one-time payment instruction. URIs which represent only reusable non-address-reusing payment instructions (like Lightning BOLT12 offers or Silent Payments) MAY be reused as a wallet sees fit.\n\n=== Proof of Payment ===\n\nOn many mobile operating systems (especially, or any operating system more generally), applications may \"open\" a bitcoin: URI in order to initiate a payment with the user's default wallet application. These payment-initiating applications may wish to learn about the completed payment.\n\nFor payments completed on-chain, this is largely addressed by having the payment-initiating application monitor the blockchain for payment completion, however for other payment schemes (e.g. lightning), no such global ledger of transactions exists. In that case, proof of payment must be provided via some other mechanism.\n\nIn order to avoid inadvertently revealing the sender's IP address or other information to the recipient, proof URIs must only be opened when they will simply switch to another locally-installed application (i.e. the application which initiated the payment). When clicking a URI from a website, the website should already have plenty of logic on its backend to process payment completion and a proof-of-payment callback is unnecessary.\n\n== Reference Implementation ==\n\nDocumentation: https://docs.rs/bitcoin-payment-instructions\n\nCode repository: https://github.com/rust-bitcoin/bitcoin-payment-instructions\n\n== Forward compatibility ==\n\nQuery parameter keys which are prefixed with a req- are considered required. If a client does not implement handling a query parameter which has a key prefixed with req-, it MUST consider the entire URI invalid. Any other query parameters which are not implemented, but which are not prefixed with a req-, can be safely ignored.\n\nAs future new address types should be added using query parameters rather than the `bitcoinaddress` field, URIs seamlessly support various payment instructions while senders only need to support legacy instructions. This allows old senders to pay newer recipients which offer more modern payment instruction formats.\n\n== Backward compatibility ==\n\nCompared to BIP 21, this document describes standard query parameters containing payment instructions, makes query parameters case-insensitive, allows bech32 and bech32m addresses in the `bitcoinaddress` field, and allows for URIs with an empty `bitcoinaddress` field. Use of bech32 and bech32m `bitcoinaddress` fields were long-since common practice in 2024, and the `lightning` query parameter storing BOLT 11 payment instructions became common practice in the year or three leading up to 2024. Inclusion of standard query parameters was added to provide guidance on query parameter usage going forward.\n\nAdditionally, this BIP describes the \"pop\" query parameter, which was unused and will be ignored by BIP 21 implementations.\n\nAny existing BIP 21 implementation should automatically be fully compliant with this BIP, as the changes only describe existing practice or impact future address format inclusion, with the one possible exception of query parameters being made case-insensitive. Note, however, that treating query parameters as case-insensitive is already common practice due to the use of mostly-uppercase URIs in QR codes.\n\n== Appendix ==\n\n=== Examples ===\n\n==== URIs ====\n\nJust the address:\n bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W\n\nAddress with recipient's name as label:\n bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?label=Luke-Jr\n\nRequest 20.30 BTC to \"Luke-Jr\":\n bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?amount=20.3&label=Luke-Jr\n\nRequest 50 BTC with message:\n bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?amount=50&label=Luke-Jr&message=Donation%20for%20project%20xyz\n\nRequest funds to be paid over lightning to a BOLT 11 invoice with a fallback to on-chain payments:\n bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?lightning=lnbc420bogusinvoice\n\nRequest funds to be paid over lightning to a BOLT 11 invoice with no fallback:\n bitcoin:?lightning=lnbc420bogusinvoice\n\nRequest funds to be paid over lightning to a BOLT 12 offer with no fallback:\n bitcoin:?lno=lno1bogusoffer\n\nRequest funds to be paid over lightning to a BOLT 12 offer or silent payments address with no fallback:\n bitcoin:?lno=lno1bogusoffer&sp=sp1qsilentpayment\n\nRequest funds to be paid to a silent payments address with no fallback:\n bitcoin:?sp=sp1qsilentpayment\n\nRequest funds to be paid to a silent payments address with a fallback:\n bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?sp=sp1qsilentpayment\n\nSome future version that has variables which are (currently) not understood and required and thus invalid:\n bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?req-somethingyoudontunderstand=50&req-somethingelseyoudontget=999\n\nSome future version that has variables which are (currently) not understood but not required and thus valid:\n bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?somethingyoudontunderstand=50&somethingelseyoudontget=999\n\nMultiple segwit addresses may be included for various versions of segwit, note that the human-readable part for all of them is `bc`\n bitcoin:?bc=bc1qufgy354j3kmvuch987xe4s40836x3h0lg8f5n2&bc=bc1p5swkugezn97763tl0yty6556856uug0q6jflljvep9m4p7339x5qzyrh4g\n\nMany QR codes utilize all-uppercase URIs, which should be handled fine\n BITCOIN:BC1QUFGY354J3KMVUCH987XE4S40836X3H0LG8F5N2?BC=BC1P5SWKUGEZN97763TL0YTY6556856UUG0Q6JFLLJVEP9M4P7339X5QZYRH4G\n BITCOIN:?BC=BC1QUFGY354J3KMVUCH987XE4S40836X3H0LG8F5N2&BC=BC1P5SWKUGEZN97763TL0YTY6556856UUG0Q6JFLLJVEP9M4P7339X5QZYRH4G\n\nA testnet segwit addresses must be included in the `tb` parameter\n bitcoin:?tb=tb1qghfhmd4zh7ncpmxl3qzhmq566jk8ckq4gafnmg\n\nCharacters must be URI encoded properly.\n\n==== Invalid URIs ====\n\nLabels must not appear twice:\n bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?label=Luke-Jr&label=Matt\n\nAmounts must not appear twice:\n bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?amount=42&amount=10\n\nAmounts must not appear twice even if they are the same:\n bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?amount=42&amount=42\n\nMultiple proof of payment URIs must not appear, even if they are sometimes prefixed with req-:\n bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?pop=callback%3a&req-pop=callback%3a\n\nA testnet segwit addresses must be included in the `tb` parameter, not the `bc` parameter.\n bitcoin:?bc=tb1qghfhmd4zh7ncpmxl3qzhmq566jk8ckq4gafnmg\n\n==== Proof of Payment ====\n\nIf the original URI is\n bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?pop=initiatingapp%3a\nthe wallet should perform the payment information callback by opening\n initiatingapp:onchain=$HEX_ENCODED_TRANSACTION\n\nIf the original URI is\n bitcoin:?lightning=lnbc420bogusinvoice&pop=callbackuri%3abody%3fpop=\nthe wallet should perform the proof-of-payment callback by opening\n callbackuri:body?pop=lightning=$HEX_ENCODED_PAYMENT_PREIMAGE\n\nIf the original URI is\n bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?lightning=lnbc420bogusinvoice&pop=app%3a%3f\nand the wallet pays on-chain, it should perform the payment information callback by opening\n app:?onchain=$HEX_ENCODED_TRANSACTION\nbut if the app pays using lightning, it should perform the proof-of-payment callback by opening\n app:?lightning=$HEX_ENCODED_PAYMENT_PREIMAGE\n\nIf the original URI is\n bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?pop=https%3aiwantyouripaddress.com\nthe wallet should make a payment as it normally would but MUST NOT interact with iwantyouripaddress.com\n\nIf the original URI is\n bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?req-pop=https%3aevilwebsite.com\nthe wallet MUST NOT make a payment", "category": "bips" }, { "instruction": "What commands would you run to work with 
?",
    "input": "",
    "output": "BIP: 112\n  Layer: Consensus (soft fork)\n  Title: CHECKSEQUENCEVERIFY\n  Authors: BtcDrak \n           Mark Friedenbach \n           Eric Lombrozo \n  Status: Deployed\n  Type: Specification\n  Assigned: 2015-08-10\n  License: PD\n
\n\n==Abstract==\n\nThis BIP describes a new opcode (CHECKSEQUENCEVERIFY) for the Bitcoin\nscripting system that in combination with BIP 68 allows execution\npathways of a script to be restricted based on the age of the output\nbeing spent.\n\n\n==Summary==\n\nCHECKSEQUENCEVERIFY redefines the existing NOP3 opcode.\nWhen executed, if any of the following conditions are true, the script interpreter will terminate with an error:\n\n* the stack is empty; or\n* the top item on the stack is less than 0; or\n* the top item on the stack has the disable flag (1 << 31) unset; and\n** the transaction version is less than 2; or\n** the transaction input sequence number disable flag (1 << 31) is set; or\n** the relative lock-time type is not the same; or\n** the top stack item is greater than the transaction input sequence (when masked according to the BIP68);\n\nOtherwise, script execution will continue as if a NOP had been executed.\n\nBIP 68 prevents a non-final transaction from being selected for inclusion in a block until the corresponding input has reached the specified age, as measured in block-height or block-time. By comparing the argument to CHECKSEQUENCEVERIFY against the nSequence field, we indirectly verify a desired minimum age of\nthe output being spent; until that relative age has been reached any script execution pathway including the CHECKSEQUENCEVERIFY will fail to validate, causing the transaction not to be selected for inclusion in a block.\n\n\n==Motivation==\n\nBIP 68 repurposes the transaction nSequence field meaning by giving\nsequence numbers new consensus-enforced semantics as a relative\nlock-time. However, there is no way to build Bitcoin scripts to make\ndecisions based on this field.\n\nBy making the nSequence field accessible to script, it becomes\npossible to construct code pathways that only become accessible some\nminimum time after proof-of-publication. This enables a wide variety\nof applications in phased protocols such as escrow, payment channels,\nor bidirectional pegs.\n\n\n===Contracts With Expiration Deadlines===\n\n====Escrow with Timeout====\n\nAn escrow that times out automatically 30 days after being funded can be\nestablished in the following way. Alice, Bob and Escrow create a 2-of-3\naddress with the following redeemscript.\n\n IF\n 2 3 CHECKMULTISIG\n ELSE\n \"30d\" CHECKSEQUENCEVERIFY DROP\n CHECKSIG\n ENDIF\n\nAt any time funds can be spent using signatures from any two of Alice,\nBob or the Escrow.\n\nAfter 30 days Alice can sign alone.\n\nThe clock does not start ticking until the payment to the escrow address\nconfirms.\n\n\n===Retroactive Invalidation===\n\nIn many instances, we would like to create contracts that can be revoked in case\nof some future event. However, given the immutable nature of the blockchain, it\nis practically impossible to retroactively invalidate a previous commitment that\nhas already confirmed. The only mechanism we really have for retroactive\ninvalidation is blockchain reorganization which, for fundamental security\nreasons, is designed to be very hard and very expensive to do.\n\nDespite this limitation, we do have a way to provide something functionally similar to retroactive invalidation while preserving irreversibility of past commitments\nusing CHECKSEQUENCEVERIFY. By constructing scripts with multiple branches of\nexecution where one or more of the branches are delayed we provide\na time window in which someone can supply an invalidation condition that allows the\noutput to be spent, effectively invalidating the would-be delayed branch and potentially discouraging\nanother party from broadcasting the transaction in the first place. If the invalidation\ncondition does not occur before the timeout, the delayed branch becomes spendable,\nhonoring the original contract.\n\nSome more specific applications of this idea:\n\n====Hash Time-Locked Contracts====\n\nHash Time-Locked Contracts (HTLCs) provide a general mechanism for off-chain contract negotiation. An execution pathway can be made to require knowledge of a secret (a hash preimage) that can be presented within an invalidation time window. By sharing the secret it is possible to guarantee to the counterparty that the transaction will never be broadcast since this would allow the counterparty to claim the output immediately while one would have to wait for the time window to pass. If the secret has not been shared, the counterparty will be unable to use the instant pathway and the delayed pathway must be used instead.\n\n====Bidirectional Payment Channels====\n\nScriptable relative locktime provides a predictable amount of time to respond in\nthe event a counterparty broadcasts a revoked transaction: Absolute locktime\nnecessitates closing the channel and reopen it when getting close to the timeout,\nwhereas with relative locktime, the clock starts ticking the moment the\ntransactions confirms in a block. It also provides a means to know exactly how\nlong to wait (in number of blocks) before funds can be pulled out of the channel\nin the event of a noncooperative counterparty.\n\n\n====Lightning Network====\n\nThe lightning network extends the bidirectional payment channel idea to allow for payments to be routed over multiple bidirectional payment channel hops.\n\nThese channels are based on an anchor transaction that requires a 2-of-2\nmultisig from Alice and Bob, and a series of revocable commitment\ntransactions that spend the anchor transaction. The commitment\ntransaction splits the funds from the anchor between Alice and Bob and\nthe latest commitment transaction may be published by either party at\nany time, finalising the channel.\n\nIdeally then, a revoked commitment transaction would never be able to\nbe successfully spent; and the latest commitment transaction would be\nable to be spent very quickly.\n\nTo allow a commitment transaction to be effectively revoked, Alice\nand Bob have slightly different versions of the latest commitment\ntransaction. In Alice's version, any outputs in the commitment\ntransaction that pay Alice also include a forced delay, and an\nalternative branch that allows Bob to spend the output if he knows that\ntransaction's revocation code. In Bob's version, payments to Bob are\nsimilarly encumbered. When Alice and Bob negotiate new balances and\nnew commitment transactions, they also reveal the old revocation code,\nthus committing to not relaying the old transaction.\n\nA simple output, paying to Alice might then look like:\n\n HASH160 EQUAL\n IF\n \n ELSE\n \"24h\" CHECKSEQUENCEVERIFY DROP\n \n ENDIF\n CHECKSIG\n\nThis allows Alice to publish the latest commitment transaction at any\ntime and spend the funds after 24 hours, but also ensures that if Alice\nrelays a revoked transaction, that Bob has 24 hours to claim the funds.\n\nWith CHECKLOCKTIMEVERIFY, this would look like:\n\n HASH160 EQUAL\n IF\n \n ELSE\n \"2015/12/15\" CHECKLOCKTIMEVERIFY DROP\n \n ENDIF\n CHECKSIG\n\nThis form of transaction would mean that if the anchor is unspent on\n2015/12/16, Alice can use this commitment even if it has been revoked,\nsimply by spending it immediately, giving no time for Bob to claim it.\n\nThis means that the channel has a deadline that cannot be pushed\nback without hitting the blockchain; and also that funds may not be\navailable until the deadline is hit. CHECKSEQUENCEVERIFY allows you\nto avoid making such a tradeoff.\n\nHashed Time-Lock Contracts (HTLCs) make this slightly more complicated,\nsince in principle they may pay either Alice or Bob, depending on whether\nAlice discovers a secret R, or a timeout is reached, but the same principle\napplies -- the branch paying Alice in Alice's commitment transaction gets a\ndelay, and the entire output can be claimed by the other party if the\nrevocation secret is known. With CHECKSEQUENCEVERIFY, a HTLC payable to\nAlice might look like the following in Alice's commitment transaction:\n\n HASH160 DUP EQUAL\n IF\n \"24h\" CHECKSEQUENCEVERIFY\n 2DROP\n \n ELSE\n EQUAL\n NOTIF\n \"2015/10/20 10:33\" CHECKLOCKTIMEVERIFY DROP\n ENDIF\n \n ENDIF\n CHECKSIG\n\nand correspondingly in Bob's commitment transaction:\n\n HASH160 DUP EQUAL\n SWAP EQUAL ADD\n IF\n \n ELSE\n \"2015/10/20 10:33\" CHECKLOCKTIMEVERIFY\n \"24h\" CHECKSEQUENCEVERIFY\n 2DROP\n \n ENDIF\n CHECKSIG\n\nNote that both CHECKSEQUENCEVERIFY and CHECKLOCKTIMEVERIFY are used in the\nfinal branch of above to ensure Bob cannot spend the output until after both\nthe timeout is complete and Alice has had time to reveal the revocation\nsecret.\n\nSee the [https://github.com/ElementsProject/lightning/blob/master/doc/miscellaneous/deployable-lightning.pdf Deployable Lightning] paper.\n\n\n====2-Way Pegged Sidechains====\n\nThe 2-way pegged sidechain requires a new REORGPROOFVERIFY opcode, the semantics of which are outside the scope of this BIP. CHECKSEQUENCEVERIFY is used to make sure that sufficient time has passed since the return peg was posted to publish a reorg proof:\n\n IF\n lockTxHeight nlocktxOut [] reorgBounty Hash160(<...>) REORGPROOFVERIFY\n ELSE\n withdrawLockTime CHECKSEQUENCEVERIFY DROP HASH160 p2shWithdrawDest EQUAL\n ENDIF\n\n\n==Specification==\n\nRefer to the reference implementation, reproduced below, for the precise\nsemantics and detailed rationale for those semantics.\n\n
\n/* Below flags apply in the context of BIP 68 */\n/* If this flag set, CTxIn::nSequence is NOT interpreted as a\n * relative lock-time. */\nstatic const uint32_t SEQUENCE_LOCKTIME_DISABLE_FLAG = (1 << 31);\n\n/* If CTxIn::nSequence encodes a relative lock-time and this flag\n * is set, the relative lock-time has units of 512 seconds,\n * otherwise it specifies blocks with a granularity of 1. */\nstatic const uint32_t SEQUENCE_LOCKTIME_TYPE_FLAG = (1 << 22);\n\n/* If CTxIn::nSequence encodes a relative lock-time, this mask is\n * applied to extract that lock-time from the sequence field. */\nstatic const uint32_t SEQUENCE_LOCKTIME_MASK = 0x0000ffff;\n\ncase OP_NOP3:\n{\n    if (!(flags & SCRIPT_VERIFY_CHECKSEQUENCEVERIFY)) {\n        // not enabled; treat as a NOP3\n        if (flags & SCRIPT_VERIFY_DISCOURAGE_UPGRADABLE_NOPS) {\n            return set_error(serror, SCRIPT_ERR_DISCOURAGE_UPGRADABLE_NOPS);\n        }\n        break;\n    }\n\n    if (stack.size() < 1)\n       return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);\n\n    // Note that elsewhere numeric opcodes are limited to\n    // operands in the range -2**31+1 to 2**31-1, however it is\n    // legal for opcodes to produce results exceeding that\n    // range. This limitation is implemented by CScriptNum's\n    // default 4-byte limit.\n    //\n    // Thus as a special case we tell CScriptNum to accept up\n    // to 5-byte bignums, which are good until 2**39-1, well\n    // beyond the 2**32-1 limit of the nSequence field itself.\n    const CScriptNum nSequence(stacktop(-1), fRequireMinimal, 5);\n\n    // In the rare event that the argument may be < 0 due to\n    // some arithmetic being done first, you can always use\n    // 0 MAX CHECKSEQUENCEVERIFY.\n    if (nSequence < 0)\n        return set_error(serror, SCRIPT_ERR_NEGATIVE_LOCKTIME);\n\n    // To provide for future soft-fork extensibility, if the\n    // operand has the disabled lock-time flag set,\n    // CHECKSEQUENCEVERIFY behaves as a NOP.\n    if ((nSequence & CTxIn::SEQUENCE_LOCKTIME_DISABLE_FLAG) != 0)\n        break;\n\n    // Compare the specified sequence number with the input.\n    if (!checker.CheckSequence(nSequence))\n        return set_error(serror, SCRIPT_ERR_UNSATISFIED_LOCKTIME);\n\n    break;\n}\n\nbool TransactionSignatureChecker::CheckSequence(const CScriptNum& nSequence) const\n{\n    // Relative lock times are supported by comparing the passed\n    // in operand to the sequence number of the input.\n    const int64_t txToSequence = (int64_t)txTo->vin[nIn].nSequence;\n\n    // Fail if the transaction's version number is not set high\n    // enough to trigger BIP 68 rules.\n    if (static_cast(txTo->nVersion) < 2)\n        return false;\n\n    // Sequence numbers with their most significant bit set are not\n    // consensus constrained. Testing that the transaction's sequence\n    // number do not have this bit set prevents using this property\n    // to get around a CHECKSEQUENCEVERIFY check.\n    if (txToSequence & CTxIn::SEQUENCE_LOCKTIME_DISABLE_FLAG)\n        return false;\n\n    // Mask off any bits that do not have consensus-enforced meaning\n    // before doing the integer comparisons\n    const uint32_t nLockTimeMask = CTxIn::SEQUENCE_LOCKTIME_TYPE_FLAG | CTxIn::SEQUENCE_LOCKTIME_MASK;\n    const int64_t txToSequenceMasked = txToSequence & nLockTimeMask;\n    const CScriptNum nSequenceMasked = nSequence & nLockTimeMask;\n\n    // There are two kinds of nSequence: lock-by-blockheight\n    // and lock-by-blocktime, distinguished by whether\n    // nSequenceMasked < CTxIn::SEQUENCE_LOCKTIME_TYPE_FLAG.\n    //\n    // We want to compare apples to apples, so fail the script\n    // unless the type of nSequenceMasked being tested is the same as\n    // the nSequenceMasked in the transaction.\n    if (!(\n        (txToSequenceMasked <  CTxIn::SEQUENCE_LOCKTIME_TYPE_FLAG && nSequenceMasked <  CTxIn::SEQUENCE_LOCKTIME_TYPE_FLAG) ||\n        (txToSequenceMasked >= CTxIn::SEQUENCE_LOCKTIME_TYPE_FLAG && nSequenceMasked >= CTxIn::SEQUENCE_LOCKTIME_TYPE_FLAG)\n    ))\n        return false;\n\n    // Now that we know we're comparing apples-to-apples, the\n    // comparison is a simple numeric one.\n    if (nSequenceMasked > txToSequenceMasked)\n        return false;\n\n    return true;\n}\n
\n\n==Reference Implementation==\n\nA reference implementation is provided by the following pull request:\n\nhttps://github.com/bitcoin/bitcoin/pull/7524\n\n\n==Deployment==\n\nThis BIP is to be deployed by \"versionbits\" BIP9 using bit 0.\n\nFor Bitcoin '''mainnet''', the BIP9 '''starttime''' will be midnight 1st May 2016 UTC (Epoch timestamp 1462060800) and BIP9 '''timeout''' will be midnight 1st May 2017 UTC (Epoch timestamp 1493596800).\n\nFor Bitcoin '''testnet''', the BIP9 '''starttime''' will be midnight 1st March 2016 UTC (Epoch timestamp 1456790400) and BIP9 '''timeout''' will be midnight 1st May 2017 UTC (Epoch timestamp 1493596800).\n\nThis BIP must be deployed simultaneously with BIP68 and BIP113 using the same deployment mechanism.\n\n==Credits==\n\nMark Friedenbach invented the application of sequence numbers to\nachieve relative lock-time, and wrote the reference implementation of\nCHECKSEQUENCEVERIFY.\n\nThe reference implementation and this BIP was based heavily on work\ndone by Peter Todd for the closely related BIP 65.\n\nBtcDrak authored this BIP document.\n\nThanks to Eric Lombrozo and Anthony Towns for contributing example use cases.\n\n\n==References==\n\n[https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki BIP 9] Versionbits\n\n[https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP 68] Relative lock-time through consensus-enforced sequence numbers\n\n[https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP 65] OP_CHECKLOCKTIMEVERIFY\n\n[https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki BIP 113] Median past block time for time-lock constraints\n\n[http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-July/000021.html HTLCs using OP_CHECKSEQUENCEVERIFY/OP_LOCKTIMEVERIFY and revocation hashes]\n\n[http://lightning.network/lightning-network-paper.pdf Lightning Network]\n\n[https://github.com/ElementsProject/lightning/blob/master/doc/miscellaneous/deployable-lightning.pdf Deployable Lightning]\n\n[http://diyhpl.us/diyhpluswiki/transcripts/sf-bitcoin-meetup/2015-02-23-scaling-bitcoin-to-billions-of-transactions-per-day/ Scaling Bitcoin to Billions of Transactions Per Day]\n\n[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010396.html Softfork deployment considerations]\n\n[https://web.archive.org/web/20210925124425/https://gist.github.com/sipa/bf69659f43e763540550 Version bits]\n\n[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-April/002433.html Jeremy Spilman Micropayment Channels]\n\n\n==Copyright==\n\nThis document is placed in the public domain.", "category": "bips" }, { "instruction": "I want to understand 
 from a technical perspective",
    "input": "",
    "output": "BIP: 66\n  Layer: Consensus (soft fork)\n  Title: Strict DER signatures\n  Authors: Pieter Wuille \n  Status: Deployed\n  Type: Specification\n  Assigned: 2015-01-10\n  License: BSD-2-Clause\n
\n\n==Abstract==\n\nThis document specifies proposed changes to the Bitcoin transaction validity rules to restrict signatures to strict DER encoding.\n\n==Copyright==\n\nThis BIP is licensed under the 2-clause BSD license.\n\n==Motivation==\n\nBitcoin's reference implementation currently relies on OpenSSL for signature validation, which means it is implicitly defining Bitcoin's block validity rules. Unfortunately, OpenSSL is not designed for consensus-critical behaviour (it does not guarantee bug-for-bug compatibility between versions), and thus changes to it can - and have - affected Bitcoin software.\n\nOne specifically critical area is the encoding of signatures. Until recently, OpenSSL's releases would accept various deviations from the DER standard and accept signatures as valid. When this changed in OpenSSL 1.0.0p and 1.0.1k, it made some nodes reject the chain.\n\nThis document proposes to restrict valid signatures to exactly what is mandated by DER, to make the consensus rules not depend on OpenSSL's signature parsing. A change like this is required if implementations would want to remove all of OpenSSL from the consensus code.\n\n==Specification==\n\nEvery signature passed to OP_CHECKSIG, OP_CHECKSIGVERIFY, OP_CHECKMULTISIG, or OP_CHECKMULTISIGVERIFY, to which ECDSA verification is applied, must be encoded using strict DER encoding (see further).\n\nThese operators all perform ECDSA verifications on pubkey/signature pairs, iterating from the top of the stack backwards. For each such verification, if the signature does not pass the IsValidSignatureEncoding check below, the entire script evaluates to false immediately. If the signature is valid DER, but does not pass ECDSA verification, opcode execution continues as it used to, causing opcode execution to stop and push false on the stack (but not immediately fail the script) in some cases, which potentially skips further signatures (and thus does not subject them to IsValidSignatureEncoding).\n\n===DER encoding reference===\n\nThe following code specifies the behaviour of strict DER checking. Note that this function tests a signature byte vector which includes the 1-byte sighash flag that Bitcoin adds, even though that flag falls outside of the DER specification, and is unaffected by this proposal. The function is also not called for cases where the length of sig is 0, in order to provide a simple, short and efficiently-verifiable encoding for deliberately invalid signatures.\n\nDER is specified in https://www.itu.int/rec/T-REC-X.690/en .\n\n
\nbool static IsValidSignatureEncoding(const std::vector &sig) {\n    // Format: 0x30 [total-length] 0x02 [R-length] [R] 0x02 [S-length] [S] [sighash]\n    // * total-length: 1-byte length descriptor of everything that follows,\n    //   excluding the sighash byte.\n    // * R-length: 1-byte length descriptor of the R value that follows.\n    // * R: arbitrary-length big-endian encoded R value. It must use the shortest\n    //   possible encoding for a positive integers (which means no null bytes at\n    //   the start, except a single one when the next byte has its highest bit set).\n    // * S-length: 1-byte length descriptor of the S value that follows.\n    // * S: arbitrary-length big-endian encoded S value. The same rules apply.\n    // * sighash: 1-byte value indicating what data is hashed (not part of the DER\n    //   signature)\n\n    // Minimum and maximum size constraints.\n    if (sig.size() < 9) return false;\n    if (sig.size() > 73) return false;\n\n    // A signature is of type 0x30 (compound).\n    if (sig[0] != 0x30) return false;\n\n    // Make sure the length covers the entire signature.\n    if (sig[1] != sig.size() - 3) return false;\n\n    // Extract the length of the R element.\n    unsigned int lenR = sig[3];\n\n    // Make sure the length of the S element is still inside the signature.\n    if (5 + lenR >= sig.size()) return false;\n\n    // Extract the length of the S element.\n    unsigned int lenS = sig[5 + lenR];\n\n    // Verify that the length of the signature matches the sum of the length\n    // of the elements.\n    if ((size_t)(lenR + lenS + 7) != sig.size()) return false;\n\n    // Check whether the R element is an integer.\n    if (sig[2] != 0x02) return false;\n\n    // Zero-length integers are not allowed for R.\n    if (lenR == 0) return false;\n\n    // Negative numbers are not allowed for R.\n    if (sig[4] & 0x80) return false;\n\n    // Null bytes at the start of R are not allowed, unless R would\n    // otherwise be interpreted as a negative number.\n    if (lenR > 1 && (sig[4] == 0x00) && !(sig[5] & 0x80)) return false;\n\n    // Check whether the S element is an integer.\n    if (sig[lenR + 4] != 0x02) return false;\n\n    // Zero-length integers are not allowed for S.\n    if (lenS == 0) return false;\n\n    // Negative numbers are not allowed for S.\n    if (sig[lenR + 6] & 0x80) return false;\n\n    // Null bytes at the start of S are not allowed, unless S would otherwise be\n    // interpreted as a negative number.\n    if (lenS > 1 && (sig[lenR + 6] == 0x00) && !(sig[lenR + 7] & 0x80)) return false;\n\n    return true;\n}\n
\n\n===Examples===\n\nNotation: P1 and P2 are valid, serialized, public keys. S1 and S2 are valid signatures using respective keys P1 and P2. S1' and S2' are non-DER but otherwise valid signatures using those same keys. F is any invalid but DER-compliant signature (including 0, the empty string). F' is any invalid and non-DER-compliant signature.", "category": "bips" }, { "instruction": "Can you explain 0 S1' F 2 P1 P2 2 CHECKMULTISIG NOT can succeed (unchanged) like we're having a beer and talking Bitcoin?", "input": "", "output": "Note that the examples above show that only additional failures are required by this change, as required for a soft forking change.\n\n==Deployment==\n\nWe reuse the double-threshold switchover mechanism from BIP 34, with the same thresholds, but for nVersion = 3. The new rules are in effect for every block (at height H) with nVersion = 3 and at least 750 out of 1000 blocks preceding it (with heights H-1000..H-1) also have nVersion = 3. Furthermore, when 950 out of the 1000 blocks preceding a block do have nVersion = 3, nVersion = 2 blocks become invalid, and all further blocks enforce the new rules.\n\n==Compatibility==\n\nThe requirement to have signatures that comply strictly with DER has been enforced as a relay policy by the reference client since v0.8.0, and very few transactions violating it are being added to the chain as of January 2015. In addition, every non-compliant signature can trivially be converted into a compliant one, so there is no loss of functionality by this requirement. This proposal has the added benefit of reducing transaction malleability (see BIP 62).\n\n==Implementation==\n\nAn implementation for the reference client is available at https://github.com/bitcoin/bitcoin/pull/5713\n\n==Acknowledgements==\n\nThis document is extracted from the previous BIP62 proposal, which had input from various people, in particular Greg Maxwell and Peter Todd, who gave feedback about this document as well.\n\n==Disclosures==\n\n* Subsequent to the network-wide adoption and enforcement of this BIP, the author [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009697.html disclosed] that strict DER signatures provided an indirect solution to a consensus bug he had previously discovered.", "category": "bips" }, { "instruction": "How would you explain 
 to someone who knows Bitcoin basics?",
    "input": "",
    "output": "BIP: 152\n  Layer: Peer Services\n  Title: Compact Block Relay\n  Authors: Matt Corallo \n  Comments-Summary: Unanimously Recommended for implementation\n  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0152\n  Status: Deployed\n  Type: Specification\n  Assigned: 2016-04-27\n  License: PD\n
\n\n==Abstract==\n\nCompact blocks on the wire as a way to save bandwidth for nodes on the P2P network.\n\nThe key words \"MUST\", \"MUST NOT\", \"REQUIRED\", \"SHALL\", \"SHALL NOT\", \"SHOULD\", \"SHOULD NOT\", \"RECOMMENDED\", \"MAY\", and \"OPTIONAL\" in this document are to be interpreted as described in RFC 2119.\n\n==Motivation==\n\nHistorically, the Bitcoin P2P protocol has not been very bandwidth efficient for block relay. Every transaction in a block is included when relayed, even though a large number of the transactions in a given block are already available to nodes before the block is relayed. This causes moderate inbound bandwidth spikes for nodes when receiving blocks, but can cause very significant outbound bandwidth spikes for some nodes which receive a block before their peers. When such spikes occur, buffer bloat can make consumer-grade internet connections temporarily unusable, and can delay the relay of blocks to remote peers who may choose to wait instead of redundantly requesting the same block from other, less congested, peers.\n\nThus, decreasing the bandwidth used during block relay is very useful for many individuals running nodes.\n\nWhile the goal of this work is explicitly not to reduce block transfer latency, it does, as a side effect reduce block transfer latencies in some rather significant ways. Additionally, this work forms a foundation for future work explicitly targeting low-latency block transfer.\n\n==Specification for version 1==\n\n===Intended Protocol Flow===\n\n\nThe protocol is intended to be used in two ways, depending on the peers and bandwidth available, as discussed [[#implementation-notes|later]]. The \"high-bandwidth\" mode, which nodes may only enable for a few of their peers, is enabled by setting the first boolean to 1 in a sendcmpct message. In this mode, peers send new block announcements with the short transaction IDs already (via a cmpctblock message), possibly even before fully validating the block (as indicated by the grey box in the image above). In some cases no further round-trip is needed, and the receiver can reconstruct the block and process it as usual immediately. When some transactions were not available from local sources (ie mempool), a getblocktxn/blocktxn roundtrip is necessary, bringing the best-case latency to the same 1.5*RTT minimum time that nodes take today, though with significantly less bandwidth usage.\n\nThe \"low-bandwidth\" mode is enabled by setting the first boolean to 0 in a sendcmpct message. In this mode, peers send new block announcements with the usual inv/headers announcements (as per BIP130, and after fully validating the block). The receiving peer may then request the block using a MSG_CMPCT_BLOCK getdata request, which will receive a response of the header and short transaction IDs. In some cases no further round-trip is needed, and the receiver can reconstruct the block and process it as usual, taking the same 1.5*RTT minimum time that nodes take today, though with significantly less bandwidth usage. When some transactions were not available from local sources (ie mempool), a getblocktxn/blocktxn roundtrip is necessary, bringing the latency to at least 2.5*RTT in this case, again with significantly less bandwidth usage than today. Because TCP often exhibits worse transfer latency for larger data sizes (as a multiple of RTT), total latency is expected to be reduced even when the full 2.5*RTT transfer mechanism is used.\n\n===New data structures===\nSeveral new data structures are added to the P2P network to relay compact blocks: PrefilledTransaction, HeaderAndShortIDs, BlockTransactionsRequest, and BlockTransactions.\n\nFor the purposes of this section, CompactSize refers to the variable-length integer encoding used across the existing P2P protocol to encode array lengths, among other things, in 1, 3, 5 or 9 bytes. Only CompactSize encodings which are minimally-encoded (ie the shortest length possible) are used by this spec. Any other CompactSize encodings are left with undefined behavior.\n\nSeveral uses of CompactSize below are \"differentially encoded\". For these, instead of using raw indexes, the number encoded is the difference between the current index and the previous index, minus one. For example, a first index of 0 implies a real index of 0, a second index of 0 thereafter refers to a real index of 1, etc.\n\n====PrefilledTransaction====\nA PrefilledTransaction structure is used in HeaderAndShortIDs to provide a list of a few transactions explicitly.\n\n{|\n|Field Name||Type||Size||Encoding||Purpose\n|-\n|index||CompactSize||1, 3 bytes||Compact Size, differentially encoded since the last PrefilledTransaction in a list||The index into the block at which this transaction is\n|-\n|tx||Transaction||variable||As encoded in \"tx\" messages sent in response to getdata MSG_TX||The transaction which is in the block at index index.\n|}\n\n====HeaderAndShortIDs====\nA HeaderAndShortIDs structure is used to relay a block header, the short transactions IDs used for matching already-available transactions, and a select few transactions which we expect a peer may be missing.\n\n{|\n|Field Name||Type||Size||Encoding||Purpose\n|-\n|header||Block header||80 bytes||First 80 bytes of the block as defined by the encoding used by \"block\" messages||The header of the block being provided\n|-\n|nonce||uint64_t||8 bytes||Little Endian||A nonce for use in short transaction ID calculations\n|-\n|shortids_length||CompactSize||1 or 3 bytes||As used to encode array lengths elsewhere||||The number of short transaction IDs in shortids (ie block tx count - prefilledtxn_length)\n|-\n|shortids||List of 6-byte integers||6*shortids_length bytes||Little Endian||The short transaction IDs calculated from the transactions which were not provided explicitly in prefilledtxn\n|-\n|prefilledtxn_length||CompactSize||1 or 3 bytes||As used to encode array lengths elsewhere||||The number of prefilled transactions in prefilledtxn (ie block tx count - shortids_length)\n|-\n|prefilledtxn||List of PrefilledTransactions||variable size*prefilledtxn_length||As defined by PrefilledTransaction definition, above||Used to provide the coinbase transaction and a select few which we expect a peer may be missing\n|}\n\n====BlockTransactionsRequest====\nA BlockTransactionsRequest structure is used to list transaction indexes in a block being requested.\n\n{|\n|Field Name||Type||Size||Encoding||Purpose\n|-\n|blockhash||Binary blob||32 bytes||The output from a double-SHA256 of the block header, as used elsewhere||The blockhash of the block which the transactions being requested are in\n|-\n|indexes_length||CompactSize||1 or 3 bytes||As used to encode array lengths elsewhere||||The number of transactions being requested\n|-\n|indexes||List of CompactSizes||1 or 3 bytes*indexes_length||Differentially encoded||The indexes of the transactions being requested in the block\n|}\n\n====BlockTransactions====\nA BlockTransactions structure is used to provide some of the transactions in a block, as requested.\n\n{|\n|Field Name||Type||Size||Encoding||Purpose\n|-\n|blockhash||Binary blob||32 bytes||The output from a double-SHA256 of the block header, as used elsewhere||The blockhash of the block which the transactions being provided are in\n|-\n|transactions_length||CompactSize||1 or 3 bytes||As used to encode array lengths elsewhere||||The number of transactions provided\n|-\n|transactions||List of Transactions||variable||As encoded in \"tx\" messages in response to getdata MSG_TX||The transactions provided\n|}\n\n====Short transaction IDs====\nShort transaction IDs are used to represent a transaction without sending a full 256-bit hash. They are calculated by:", "category": "bips" }, { "instruction": "I'm trying to understand Bitcoin Operations Guide - can you walk me through it?", "input": "", "output": "# Running SipHash-2-4 with the input being the transaction ID and the keys (k0/k1) set to the first two little-endian 64-bit integers from the above hash, respectively.", "category": "bips" }, { "instruction": "Hey, I need to set up Dropping the 2 most significant bytes from the SipHash output to make it 6 bytes. - what's the command line way to do that?", "input": "", "output": "===New messages===\nA new inv type (MSG_CMPCT_BLOCK == 4) and several new protocol messages are added: sendcmpct, cmpctblock, getblocktxn, and blocktxn.\n\n====sendcmpct====", "category": "bips" }, { "instruction": "What's the deal with Bitcoin Operations Guide in Bitcoin? Explain it like I'm a friend.", "input": "", "output": "# The sendcmpct message is defined as a message containing a 1-byte integer followed by a 8-byte integer where pchCommand == \"sendcmpct\".", "category": "bips" }, { "instruction": "Can you show me the CLI commands for Bitcoin Operations Guide?", "input": "", "output": "# The second integer SHALL be interpreted as a little-endian version number. Nodes sending a sendcmpct message MUST currently set this value to 1.", "category": "bips" }, { "instruction": "I'm stuck with Bitcoin Operations Guide - what should I check?", "input": "", "output": "# Upon receipt of a \"sendcmpct\" message with the first and second integers set to 1, the node SHOULD announce new blocks by sending a cmpctblock message.", "category": "bips" }, { "instruction": "How do I troubleshoot Bitcoin Operations Guide issues?", "input": "", "output": "# Upon receipt of a \"sendcmpct\" message with the first integer set to 0, the node SHOULD NOT announce new blocks by sending a cmpctblock message, but SHOULD announce new blocks by sending invs or headers, as defined by BIP130.", "category": "bips" }, { "instruction": "What are the best practices for Bitcoin Operations Guide?", "input": "", "output": "# Upon receipt of a \"sendcmpct\" message with the second integer set to something other than 1, nodes MUST treat the peer as if they had not received the message (as it indicates the peer will provide an unexpected encoding in cmpctblock, and/or other, messages). This allows future versions to send duplicate sendcmpct messages with different versions as a part of a version handshake for future versions. See Protocol Versioning section, below, for more info on the specifics of the version-negotiation mechanics.", "category": "bips" }, { "instruction": "Walk me through setting up Bitcoin Operations Guide step by step", "input": "", "output": "# Nodes MUST NOT send a request for a MSG_CMPCT_BLOCK object to a peer before having received a sendcmpct message from that peer.", "category": "bips" }, { "instruction": "What commands would you run to work with Bitcoin Operations Guide?", "input": "", "output": "# Upon receipt of a getdata containing a request for a MSG_CMPCT_BLOCK object with the hash of a block which was recently announced and is close to the tip of the best chain of the receiver and after having sent the requesting peer a sendcmpct message, nodes MUST respond with a cmpctblock message containing appropriate data representing the block being requested.", "category": "bips" }, { "instruction": "I want to understand Bitcoin Operations Guide from a technical perspective", "input": "", "output": "# Upon receipt of a getdata containing a request for a MSG_CMPCT_BLOCK object for which a cmpctblock message is not sent in response, a block message containing the requested block in non-compact form MUST be sent.", "category": "bips" }, { "instruction": "Can you explain Bitcoin Operations Guide like we're having a beer and talking Bitcoin?", "input": "", "output": "# The cmpctblock message is defined as a message containing a serialized HeaderAndShortIDs message and pchCommand == \"cmpctblock\".", "category": "bips" }, { "instruction": "How would you explain Bitcoin Operations Guide to someone who knows Bitcoin basics?", "input": "", "output": "# Upon receipt of a cmpctblock message after sending a sendcmpct message, nodes SHOULD calculate the short transaction ID for each unconfirmed transaction they have available (ie in their mempool) and compare each to each short transaction ID in the cmpctblock message.", "category": "bips" }, { "instruction": "I'm trying to understand Bitcoin Operations Guide - can you walk me through it?", "input": "", "output": "# After finding already-available transactions, nodes which do not have all transactions available to reconstruct the full block SHOULD request the missing transactions using a getblocktxn message.", "category": "bips" }, { "instruction": "Hey, I need to set up Bitcoin Operations Guide - what's the command line way to do that?", "input": "", "output": "# A node MUST NOT send a cmpctblock message unless they are able to respond to a getblocktxn message which requests every transaction in the block.", "category": "bips" }, { "instruction": "What's the deal with Bitcoin Operations Guide in Bitcoin? Explain it like I'm a friend.", "input": "", "output": "# The getblocktxn message is defined as a message containing a serialized BlockTransactionsRequest message and pchCommand == \"getblocktxn\".", "category": "bips" }, { "instruction": "Can you show me the CLI commands for Bitcoin Operations Guide?", "input": "", "output": "# The blocktxn message is defined as a message containing a serialized BlockTransactions message and pchCommand == \"blocktxn\".", "category": "bips" }, { "instruction": "I'm stuck with Upon receipt of a properly-formatted requested blocktxn message, nodes SHOULD attempt to reconstruct the full block by: - what should I check?", "input": "", "output": "## Taking the prefilledtxn transactions from the original cmpctblock and placing them in the marked positions.\n## For each short transaction ID from the original cmpctblock, in order, find the corresponding transaction either from the blocktxn message or from other sources and place it in the first available position in the block.", "category": "bips" }, { "instruction": "How do I troubleshoot Bitcoin Operations Guide issues?", "input": "", "output": "# The protocol version negotiation allows two nodes to agree on the versions of compact blocks which they will exchange. As it is only in a single field, it does not allow a node to support a specific version in only one direction (sending or receiving).", "category": "bips" }, { "instruction": "What are the best practices for Bitcoin Operations Guide?", "input": "", "output": "# Upon connection establishment, a node SHOULD send a burst of sendcmpct messages containing every version of compact block encodings for which they are willing to support sending cmpctblock and blocktxn messages, and receiving getblocktxn messages. These messages SHOULD be ordered in the order of the priority which the node wishes to receive cmpctblock/blocktxn messages, with the highest-priority version sendcmpct message sent first.", "category": "bips" }, { "instruction": "Walk me through setting up Bitcoin Operations Guide step by step", "input": "", "output": "# The encoding version used to send a cmpctblock or blocktxn message or to receive a getblocktxn message MUST be the second integer (version number) in the first sendcmpct message received for which a sendcmpct message with the same version number was sent.", "category": "bips" }, { "instruction": "What commands would you run to work with Bitcoin Operations Guide?", "input": "", "output": "# Nodes MUST NOT send a sendcmpct message which contains a version number other than the version number which has been negotiated for receiving cmpctblock/blocktxn messages after sending a request for a MSG_CMPCT_BLOCK object, sending a cmpctblock, getblocktxn, blocktxn, or pong message.", "category": "bips" }, { "instruction": "I want to understand Bitcoin Operations Guide from a technical perspective", "input": "", "output": "# As a node must send all sendcmpct messages which contain a novel version announcement before any other compact block-related messages, it is possible to determine which version of compact blocks will be used for each object received. It is, however, not possible to know which version will be used to encode the response to a request for a compact block object before any MSG_CMPCT_BLOCK-containing getdata, cmpctblock, getblocktxn, blocktxn, or ping/pong messages have been exchanged.", "category": "bips" }, { "instruction": "Can you explain Bitcoin Operations Guide like we're having a beer and talking Bitcoin?", "input": "", "output": "# Upon exchanging version/verack messages, a node immediately sends its list of sendcmpct announcements to the other side, with the version which it wants to receive sent first.", "category": "bips" }, { "instruction": "How would you explain Bitcoin Operations Guide to someone who knows Bitcoin basics?", "input": "", "output": "# Upon receiving the first sendcmpct announcement with a protocol version which is understood from the remote peer, a node will \"lock in\" the compact block encoding version which will be used to encode compact blocks to that peer.", "category": "bips" }, { "instruction": "I'm trying to understand Bitcoin Operations Guide - can you walk me through it?", "input": "", "output": "# The node then sets the current receive-protocol-version in use on the connection to that version, and uses it to decode new compact block messages.", "category": "bips" }, { "instruction": "Hey, I need to set up Bitcoin Operations Guide - what's the command line way to do that?", "input": "", "output": "# Upon receiving subsequent sendcmpct announcements with a protocol version which is understood from the remote peer (ie a version which has been announced using a sendcmpct in the other direction), a node will check if that protocol version is higher-receive-priority than the current receive-protocol-version in use on the connection, and switch to that version for decoding new compact block messages received.", "category": "bips" }, { "instruction": "What's the deal with Bitcoin Operations Guide in Bitcoin? Explain it like I'm a friend.", "input": "", "output": "# A node might wish to keep a flag for each peer which indicates compact block version negotiation is complete, which can be set upon receiving any compact block-related, or pong message.", "category": "bips" }, { "instruction": "Can you show me the CLI commands for The above implementation requires only a compile-time list of supported versions in some static priority order, two version fields per peer, and an optional negotiation-complete boolean per-peer.?", "input": "", "output": "==Specification for version 2==\nCompact blocks version 2 is almost identical to version 1, but supports segregated witness transactions (BIP 141 and BIP 144). The changes are:", "category": "bips" }, { "instruction": "I'm stuck with Bitcoin Operations Guide - what should I check?", "input": "", "output": "# The second integer (version number) inside sendcmpct is 2 instead of 1 (see Protocol Versioning section, above).", "category": "bips" }, { "instruction": "How do I troubleshoot Bitcoin Operations Guide issues?", "input": "", "output": "# Transactions inside cmpctblock messages (both those used as direct announcement and those in response to getdata) and in blocktxn should include witness data, using the same format as responses to getdata MSG_WITNESS_TX, specified in BIP144.", "category": "bips" }, { "instruction": "What are the best practices for Bitcoin Operations Guide?", "input": "", "output": "# Short transaction IDs sent to us in cmpctblock messages, and sent by us in getblocktxn messages, are computed using the same process as in version 1, but using the wtxid as defined in BIP 141 instead of the txid. Note that, though a node normally SHOULD, if a node does not include (ie must then include the short ID for) the coinbase transaction, it must be computed by encoding the transaction in witness format as defined by BIP 141.", "category": "bips" }, { "instruction": "Walk me through setting up As a result of the above requirements, implementers may wish to consider the potential for the introduction of delays in responses while remote peers validate blocks, avoiding delay-causing requests where possible. step by step", "input": "", "output": "==Justification==\n\n====Protocol design====\nThere have been many proposals to save wire bytes when relaying blocks. Many of them have a two-fold goal of reducing block relay time and thus rely on the use of significant processing power in order to avoid introducing additional worst-case RTTs. Because this work is not focused primarily on reducing block relay time, its design is much simpler (ie does not rely on set reconciliation protocols). Still, in testing at the time of writing, nodes are able to relay blocks without the extra getblocktxn/blocktxn RTT around 90% of the time. With a smart compact-block-announcement policy, it is thus expected that this work might allow blocks to be relayed between nodes in 0.5*RTT instead of 1.5*RTT at least 75% of the time.\n\n====Short transaction ID calculation====\n\nThere are several design goals for the Short ID calculation:\n* '''Performance''' The sender needs to compute short IDs for all block transactions, and the receiver for all mempool transactions they are being compared to. As we're easily talking about several thousand transactions, sub-microsecond processing per-transactions is needed.\n* '''Space''' cmpctblock messages are never optional in this protocol, and contain a short ID for each non-prefilled transaction in the block. Thus, the size of short IDs is directly proportional to the maximum bandwidth savings possible.\n* '''Collision resistance''' It should be hard for network participants to create transactions that cause collisions. If an attacker were able to cause such collisions, filling mempools (and, thus, blocks) with them would cause poor network propagation of new (or non-attacker, in the case of a miner) blocks.\n\nSipHash is a secure, fast, and simple 64-bit MAC designed for network traffic authentication and collision-resistant hash tables. We truncate the output from SipHash-2-4 to 48 bits (see next section) in order to minimize space. The resulting 48-bit hash is certainly not large enough to avoid intentionally created individual collisions, but by using the block hash as a key to SipHash, an attacker cannot predict what keys will be used once their transactions are actually included in a relayed block. We mix in a per-connection 64-bit nonce to obtain independent short IDs on every connection, so that even block creators cannot control where collisions occur, and random collisions only ever affect a small number of connections at any given time. The mixing is done using SHA256(block_header || nonce), which is slow compared to SipHash, but only done once per block. It also adds the ability for nodes to choose the nonce in a better than random way to minimize collisions, though that is not necessary for correct behaviour. Conversely, nodes can also abuse this ability to increase their ability to introduce collisions in the blocks they relay themselves. However, they can already cause more problems by simply refusing to relay blocks. That is inevitable, and this design only seeks to prevent network-wide misbehavior.\n\n====Random collision probability====\n\nThanks to the block-header-based SipHash keys, we can assume that the only collisions on links between honest nodes are random ones.\n\nFor each of the ''t'' block transactions, the receiver will compare its received short ID with that of a set of ''m'' mempool transactions. We assume that each of those ''t'' has a chance ''r'' to be included in that set of ''m''. If we use ''B'' bits short IDs, for each comparison between a received short ID and a mempool transaction, there is a chance of ''P = 1 - 1 / 2^B'' that a mismatch is detected as such.\n\nWhen comparing a given block transaction to the whole set of mempool transactions, there are 5 cases to distinguish:", "category": "bips" }, { "instruction": "What commands would you run to work with Bitcoin Operations Guide?", "input": "", "output": "# The receiver has at least two matches, one of which is correct. This has chance ''r * (1 - P^(m - 1))''.", "category": "bips" }, { "instruction": "I want to understand Bitcoin Operations Guide from a technical perspective", "input": "", "output": "# The receiver has at least two matches, both of which are incorrect. This has chance ''(1 - r) * (1 - P^m - m * (1 - P) * P^(m - 1))''.", "category": "bips" }, { "instruction": "Can you explain The receiver has exactly one match, but an incorrect one. This has chance ''(1 - r) * m * (1 - P) * P^(m - 1)''. like we're having a beer and talking Bitcoin?", "input": "", "output": "(note that these 5 numbers always add up to 100%)\n\nIn case 1, we're good. In cases 2, 3, or 4, we request the full transaction because we know we're uncertain. Only in case 5, we fail to reconstruct. The chance that case 5 does not occur in any of the ''t'' transactions in a block is ''(1 - (1 - r) * m * (1 - P) * P^(m - 1))^t''. This expression is well approximated by ''1 - (1 - r) * m * (1 - P) * t'' = ''1 - (1 - r) * m * t / 2^B''. Thus, if we want only one in F block transmissions between honest nodes to fail under the conservative ''r = 0'' assumption, we need ''log2(F * m * t)'' bits hash functions.\n\nThis means that ''B = 48'' bits short IDs suffice for blocks with up to ''t = 10000'' transactions, mempools up to ''m = 100000'' transactions, with failure to reconstruct at most one in ''F = 281474'' blocks. Since failure to reconstruct just means we fall back to normal inv/header based relay, it isn't necessary to avoid such failure completely. It just needs to be sufficiently rare they have a lower impact than random transmission failures (for example, network disconnection, node overloaded, ...).\n\n====Separate version for segregated witness====\n\nThe changes to transaction and block relay in BIP 144 introduce separate MSG_FILTERED_ versions of messages in getdata,\nallowing a receiver to choose individually where witness data is wanted.\n\nThis method is not useful for compact blocks because `cmpctblock` blocks can be sent unsolicitedly in high-bandwidth\nmode, so we need to negotiate at least whether those should include witness data up front. There is little use for a\nvalidating node that only sometimes processes witness data, so we may as well use that negotiation for everything and\nturn it into a separate protocol version. We also need a means to distinguish different versions of the same transaction\nwith different witnesses for correct reconstruction, so this also forces us to use wtxids instead of txids for short IDs\neverywhere in that case.\n\n==Backward compatibility==\n\nOlder clients remain fully compatible and interoperable after this change.\n\n==Implementation==\n\nhttps://github.com/bitcoin/bitcoin/pull/8068 for version 1.\nhttps://github.com/bitcoin/bitcoin/pull/8393 for version 2.\n\n==Acknowledgements==\n\nThanks to Gregory Maxwell for the initial suggestion as well as a lot of back-and-forth design and significant testing.\nThanks to Nicolas Dorier for the protocol flow diagram.\n\n==Copyright==\n\nThis document is placed in the public domain.", "category": "bips" }, { "instruction": "How would you explain 
 to someone who knows Bitcoin basics?",
    "input": "",
    "output": "BIP: 176\n  Title: Bits Denomination\n  Authors: Jimmy Song \n  Comments-Summary: No comments yet.\n  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0176\n  Status: Complete\n  Type: Informational\n  Assigned: 2017-12-12\n  License: BSD-2-Clause\n
\n\n== Abstract ==\nBits is presented here as the standard term for 100 (one hundred) satoshis or 1/1,000,000 (one one-millionth) of a bitcoin.\n\n== Motivation ==\nThe bitcoin price has grown over the years and once the price is past $10,000 USD or so, bitcoin amounts under $10 USD start having enough decimal places that it's difficult to tell whether the user is off by a factor of 10 or not. Switching the denomination to \"bits\" makes comprehension easier. For example, when BTC is $15,000 USD, $10.05 is a somewhat confusing 0.00067 BTC, versus 670 bits, which is a lot clearer.\n\nAdditionally, reverse comparisons are easier as 59 bits being $1 is easier to comprehend for most people than 0.000059 BTC being $1. Similar comparisons can be made to other currencies: 1 yen being 0.8 bits, 1 won being 0.07 bits and so on.\n\nPotential benefits of utilizing \"bits\" include:", "category": "bips" }, { "instruction": "I'm trying to understand Allows all UTXO amounts to need at most 2 decimal places, which can be easier to handle. - can you walk me through it?", "input": "", "output": "== Specification ==\nDefinition: 1 bit = 100 satoshis.\nPlural of \"bit\" is \"bits.\" The terms \"bit\" and \"bits\" are not proper nouns and thus should not be capitalized unless used at the start of a sentence, etc.\n\nAll bitcoin-denominated items are encouraged to also show the denomination in bits, either as the default or as an option.\n\n== Rationale ==\nAs bitcoin grows in price versus fiat currencies, it's important to give users the ability to quickly and accurately calculate prices for transactions, savings and other economic activities. \"Bits\" have been used as a denomination within the Bitcoin ecosystem for some time. The idea of this BIP is to formalize this name. Additionally, \"bits\" is likely the only other denomination that will be needed for Bitcoin as 0.01 bit = 1 satoshi, meaning that two decimal places will be sufficient to describe any current utxo.\n\nExisting terms used in bitcoin such as satoshi, milli-bitcoin (mBTC) and bitcoin (BTC) do not conflict as they operate at different orders of magnitude.\n\nThe term micro-bitcoin (µBTC) can continue to exist in tandem with the term \"bits.\"\n\n== Backwards Compatibility ==\nSoftware such as the Bitcoin Core GUI currently use the µBTC denomination and can continue to do so. There is no obligation to switch to \"bits.\"\n\nThe term \"bit\" has many different definitions, but the ones of particular note are these:\n\n* 1 bit = 1/8 dollar (e.g., that candy cost me 2 bits {or 1/4 dollar})\n* bit meaning some amount of data (e.g., the first bit of the version field is 0)\n* bit meaning strength of a cryptographic algorithm (e.g., 256-bit ECDSA is used in Bitcoin)\n\nThe first is a bit dated and isn't likely to confuse people dealing with Bitcoin. The second and third are computer science terms and context should be sufficient to figure out what the user of the word means.\n\n== Copyright ==\nThis BIP is licensed under the BSD 2-clause license.\n\n== Credit ==\nIt's hard to ascertain exactly who invented the term \"bits,\" but the term has been around for a while and the author of this BIP does not take any credit for inventing the term.", "category": "bips" }, { "instruction": "Hey, I need to set up 
 - what's the command line way to do that?",
    "input": "",
    "output": "BIP: 18\n  Layer: Consensus (soft fork)\n  Title: hashScriptCheck\n  Authors: Luke Dashjr \n  Status: Complete\n  Type: Specification\n  Assigned: 2012-01-27\n  License: BSD-2-Clause\n
\n\n==Abstract==\n\nThis BIP modifies the basic format of transaction inputs and outputs, replacing the current scriptSig and scriptPubKey (scripts executed to validate a transaction) with new contents: dataSig, scriptCheck, and hashScriptCheck.\n\n==Copyright==\n\nThis BIP is licensed under the BSD 2-clause license.\n\n==Motivation==\n\nThe purpose of pay-to-script-hash is to move the responsibility for supplying the conditions to redeem a transaction from the sender of the funds to the redeemer.\n\nThe benefit is allowing a sender to fund any arbitrary transaction, no matter how complicated, using a fixed-length 20-byte hash that is short enough to scan from a QR code or easily copied and pasted.\n\n==Specification==\n\nscriptSig and scriptPubKey are hereby deemed to be deprecated.\nBitcoin-compatible clients MUST still continue to support them for compatibility, but it should not be used for any new transaction types.\nServices and people which send Bitcoins SHOULD continue to support old pubkey-based addresses for the time being.\nServices and people which receive Bitcoins MAY continue to generate and use old pubkey-based addresses.\n\nTo replace these, there are 3 new elements:\n* dataSig is included in place of scriptSig in transaction inputs, and contains multiple serialized data elements\n* scriptCheck is the final element of dataSig, and is executed with the preceding dataSig elements preloaded onto the stack (the element immediately before scriptCheck is the top of the stack)\n* hashScriptCheck is included in place of scriptPubKey in transaction outputs, to specify the hash of the scriptCheck allowed to redeem it\n\ndataSig is to be encoded the same as a push-only script.\n\nhashScriptCheck must be encoded exactly so:\n\n 0xa9 0x14 (20-byte-hash-value) 0x87\n\nThis can be interpreted by legacy (pre-BIP 18) clients as the following script:\n\n OP_HASH160 [20-byte-hash-value] OP_EQUAL\n\nIf this template is not matched exactly OR the transaction is in a block with a timestamp before the hashScriptCheck activation date, validation MUST proceed in backward-compatibility mode, using scriptSig+scriptPubKey rather than dataSig+scriptCheck+hashScriptCheck.\n\nA hashScriptCheck-compliant input is valid only if:\n* dataSig MUST NOT contain any operations other than \"push data\" (it is data, not a script; no mixing scriptSig with hashScriptCheck)\n* scriptCheck MUST hash (using Bitcoin's Hash160 algorithm) to the output's hashScriptCheck.\n* scriptCheck MUST be executed with the dataSig-based stack specified above (ie, not including scriptCheck itself) to perform validation (this does not imply clients are required to validate transactions).\n* scriptCheck must not abort, and must leave a true value on the top of the stack. This is the current behaviour for scriptSig+scriptPubKey.\n\nThe new scriptCheck SHOULD be checked against \"standard transaction\" templates by miners.\n\nFor example, the hashScriptCheck and corresponding dataSig for a one-signature-required transaction is:\n\n scriptCheck: [pubkey] OP_CHECKSIG\n dataSig: [signature] {[pubkey] OP_CHECKSIG}\n hashScriptCheck: [20-byte-hash of {[pubkey] OP_CHECKSIG}]\n\n===Signature operation limits for scriptCheck===\n\nSignature operations in scriptCheck do not follow the same rules previously applied to scriptSig and scriptPubKey.\nInstead, they shall contribute to the maximum number allowed per block (20,000) as follows:", "category": "bips" }, { "instruction": "What's the deal with Bitcoin Operations Guide in Bitcoin? Explain it like I'm a friend.", "input": "", "output": "# OP_CHECKSIG and OP_CHECKSIGVERIFY count as 1 signature operation, whether or not they are evaluated.", "category": "bips" }, { "instruction": "Can you show me the CLI commands for Bitcoin Operations Guide?", "input": "", "output": "# OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY immediately preceded by OP_1 through OP_16 are counted as 1 to 16 signature operation, whether or not they are evaluated.", "category": "bips" }, { "instruction": "I'm stuck with All other OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY are counted as 20 signature operations. - what should I check?", "input": "", "output": "Examples:\n\n+3 signature operations:\n 2 [pubkey1] [pubkey2] [pubkey3] 3 OP_CHECKMULTISIG\n\n+22 signature operations\n OP_CHECKSIG OP_IF OP_CHECKSIGVERIFY OP_ELSE OP_CHECKMULTISIGVERIFY OP_ENDIF\n\n==Rationale==\n\nThis BIP replaces BIPs 12 and 17, which propose extensions to the Script system to allow scriptPubKey to outsource its verification.\nIt also replaces BIP 16, which is identical in terms of protocol, but suggests a specific implementation and does not deprecate scriptPubKey to maintain protocol consistency.\n\nThe Motivation for this BIP (and BIP 13, the pay-to-script-hash address type) is somewhat controversial; several people feel that it is unnecessary, and complex/multisignature transaction types should be supported by simply giving the sender the complete {serialized script}. The author believes that this BIP will minimize the changes needed to all of the supporting infrastructure that has already been created to send funds to a base58-encoded-20-byte bitcoin addresses, allowing merchants and exchanges and other software to start supporting multisignature transactions sooner.\n\nThe signature operation counting rules are intended to be easy and quick to implement by statically scanning scriptCheck.\nBitcoin imposes a maximum-number-of-signature-operations per block to prevent denial-of-service attacks on miners.\nIf there was no limit, a rogue miner might broadcast a block that required hundreds of thousands of ECDSA signature operations to validate, and it might be able to get a head start computing the next block while the rest of the network worked to validate the current one.\n\nThere is a 1-confirmation attack on old implementations, but it is expensive and difficult in practice. The attack is:", "category": "bips" }, { "instruction": "How do I troubleshoot Bitcoin Operations Guide issues?", "input": "", "output": "# Attacker creates a pay-to-script-hash transaction that is valid when interpreted as scriptPubKey, but contains an invalid scriptCheck, and sends themselves some coins using it.", "category": "bips" }, { "instruction": "What are the best practices for Bitcoin Operations Guide?", "input": "", "output": "# Attacker also creates a standard transaction that spends the pay-to-script transaction, and pays the victim who is running old software.", "category": "bips" }, { "instruction": "Walk me through setting up Attacker mines a block that contains both transactions. step by step", "input": "", "output": "If the victim accepts the 1-confirmation payment, then the attacker wins because both transactions will be invalidated when the rest of the network overwrites the attacker's invalid block.\n\nThe attack is expensive because it requires the attacker create a block that they know will be invalidated by the rest of the network. It is difficult because creating blocks is difficult and users should not accept 1-confirmation transactions for higher-value transactions.\n\n==Backwards Compatibility==\n\nhashScriptCheck transactions are non-standard to old implementations, which will (typically) not relay them nor include them in blocks.\n\nOld implementations will validate that scriptCheck's hash value matches when they validate blocks created by software that fully support this BIP, but will do no other validation.\n\nAvoiding a block-chain split by malicious pay-to-script transactions requires careful handling of one case:\n\n* A pay-to-script-hash transaction that is invalid for new clients/miners but valid for old clients/miners.\n\nTo gracefully upgrade and ensure no long-lasting block-chain split occurs, more than 50% of miners must support full validation of the new transaction type and must switch from the old validation rules to the new rules at the same time.\n\nTo judge whether or not more than 50% of hashing power supports this BIP, miners are asked to upgrade their software and put the string \"/P2SH/\" in the input of the coinbase transaction for blocks that they create.\n\nAt 00:00:00 UTC on 15 Mar 2012, the block-chain will be examined to determine the number of blocks supporting pay-to-script-hash for the previous 7 days. If 550 or more contain \"/P2SH/\" in their coinbase, then all blocks with timestamps after 00:00:00 UTC on 1 Apr 2012 shall have their pay-to-script-hash transactions fully validated. Approximately 1,000 blocks are created in a week; 550 should, therefore, be approximately 55% of the network supporting the new feature.\n\nIf a majority of hashing power does not support the new validation rules, then rollout will be postponed (or rejected if it becomes clear that a majority will never be achieved).\n\n==Forwards Compatibility ==\nThe first two bytes of hashScriptCheck specify the hash algorithm and length used to verify scriptCheck.\nThis BIP only allows Bitcoin's Hash160 algorithm, but leaves open the possibility of a future BIP implementing others.\n\n==Reference Implementation==\n\nhttps://github.com/gavinandresen/bitcoin-git/tree/pay_to_script_hash\n\n==See Also==\n\n* The [[bip-0013.mediawiki|Address format for Pay to Script Hash BIP]]\n* [[bip-0016.mediawiki|BIP 16 - Pay to Script Hash (aka \"/P2SH/\")]]\n* M-of-N Multisignature Transactions [[bip-0011.mediawiki|BIP 11]]", "category": "bips" }, { "instruction": "What commands would you run to work with 
?",
    "input": "",
    "output": "BIP: 146\n  Layer: Consensus (soft fork)\n  Title: Dealing with signature encoding malleability\n  Authors: Johnson Lau \n           Pieter Wuille \n  Status: Closed\n  Type: Specification\n  Assigned: 2016-08-16\n  License: PD\n
\n\n==Abstract==\n\nThis document specifies proposed changes to the Bitcoin transaction validity rules to fix signature malleability related to ECDSA signature encoding.\n\n\n==Motivation==\n\nSignature malleability refers to the ability of any relay node on the network to transform the signature in transactions, with no access to the relevant private keys required. For non-segregated witness transactions, signature malleability will change the txid and invalidate any unconfirmed child transactions. Although the txid of segregated witness ([https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki BIP141]) transactions is not third party malleable, this malleability vector will change the wtxid and may reduce the efficiency of compact block relay ([https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki BIP152]).\n\nSince the enforcement of Strict DER signatures ([https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki BIP66]), there are 2 remaining known sources of malleability in ECDSA signatures:", "category": "bips" }, { "instruction": "I want to understand '''Malleability of failing signature''': If a signature failed to validate in OP_CHECKSIG or OP_CHECKMULTISIG, a FALSE would be returned to the stack and the script evaluation would continue. The failing signature may take any value, as long as it follows all the rules described in BIP66. from a technical perspective", "input": "", "output": "This document specifies new rules to fix the aforesaid signature malleability.\n\n\n==Specification==\n\nTo fix signature encoding malleability, the following new rules are applied to pre-segregated witness and segregated witness scripts:\n\n\n===LOW_S===\n\nWe require that the S value inside ECDSA signatures is at most the curve order divided by 2 (essentially restricting this value to its lower half range). Every signature passed to OP_CHECKSIGIncluding pay-to-witness-public-key-hash (P2WPKH) described in BIP141, OP_CHECKSIGVERIFY, OP_CHECKMULTISIG, or OP_CHECKMULTISIGVERIFY, to which ECDSA verification is applied, MUST use a S value between 0x1 and 0x7FFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF 5D576E73 57A4501D DFE92F46 681B20A0 (inclusive) with strict DER encoding (see [https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki BIP66]).\n\nIf a signature passing to ECDSA verification does not pass the Low S value check and is not an empty byte array, the entire script evaluates to false immediately.\n\nA high S value in signature could be trivially replaced by S' = 0xFFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141 - S.\n\n\n===NULLFAIL===\n\nIf an OP_CHECKSIG is trying to return a FALSE value to the stack, we require that the relevant signature must be an empty byte array.\n\nIf an OP_CHECKMULTISIG is trying to return a FALSE value to the stack, we require that all signatures passing to this OP_CHECKMULTISIG must be empty byte arrays, even the processing of some signatures might have been skipped due to early termination of the signature verification.\n\nOtherwise, the entire script evaluates to false immediately.\n\n\n==Examples==\n\nThe following examples are the combined results of the LOW_S and NULLFAIL rules.Please note that due to implementation details in reference client v0.13.1, some signatures with S value higher than the half curve order might pass the LOW_S test. However, such signatures are certainly invalid, and will fail later due to NULLFAIL test.\n\nNotation:\n\n CO : curve order = 0xFFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141\n HCO : half curve order = CO / 2 = 0x7FFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF 5D576E73 57A4501D DFE92F46 681B20A0\n P1, P2 : valid, serialized, public keys\n S1L, S2L : valid low S value signatures using respective keys P1 and P2 (1 ≤ S ≤ HCO)\n S1H, S2H : signatures with high S value (otherwise valid) using respective keys P1 and P2 (HCO < S < CO)\n F : any BIP66-compliant non-empty byte array but not a valid signature\n\nThese scripts will return a TRUE to the stack as before:\n\n S1L P1 CHECKSIG\n 0 S1L S2L 2 P1 P2 2 CHECKMULTISIG\n\nThese scripts will return a FALSE to the stack as before:\n\n 0 P1 CHECKSIG\n 0 0 0 2 P1 P2 2 CHECKMULTISIG\n\nThese previously TRUE scripts will fail immediately under the new rules:\n\n S1H P1 CHECKSIG\n 0 S1H S2L 2 P1 P2 2 CHECKMULTISIG\n 0 S1L S2H 2 P1 P2 2 CHECKMULTISIG\n 0 S1H S2H 2 P1 P2 2 CHECKMULTISIG\n\nThese previously FALSE scripts will fail immediately under the new rules:\n\n F P1 CHECKSIG\n 0 S2L S1L 2 P1 P2 2 CHECKMULTISIG\n 0 S1L F 2 P1 P2 2 CHECKMULTISIG\n 0 F S2L 2 P1 P2 2 CHECKMULTISIG\n 0 S1L 0 2 P1 P2 2 CHECKMULTISIG\n 0 0 S2L 2 P1 P2 2 CHECKMULTISIG\n 0 F 0 2 P1 P2 2 CHECKMULTISIG\n 0 0 F 2 P1 P2 2 CHECKMULTISIG\n\n\n==Deployment==\n\nThis BIP will be deployed by \"version bits\" [https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki BIP9]. Details TBD.\n\nFor Bitcoin mainnet, the BIP9 starttime will be midnight TBD UTC (Epoch timestamp TBD) and BIP9 timeout will be midnight TBD UTC (Epoch timestamp TBD).\n\nFor Bitcoin testnet, the BIP9 starttime will be midnight TBD UTC (Epoch timestamp TBD) and BIP9 timeout will be midnight TBD UTC (Epoch timestamp TBD).\n\n\n==Compatibility==\n\nThe reference client has produced LOW_S compatible signatures since v0.9.0, and the LOW_S rule has been enforced as relay policy by the reference client since v0.11.1. As of August 2016, very few transactions violating the requirement are being added to the chain. For all scriptPubKey types in actual use, non-compliant signatures can trivially be converted into compliant ones, so there is no loss of functionality by these requirements.\n\nScripts with failing OP_CHECKSIG or OP_CHECKMULTISIG rarely happen on the chain. The NULLFAIL rule has been enforced as relay policy by the reference client since v0.13.1.\n\nUsers MUST pay extra attention to these new rules when designing exotic scripts.\n\n\n==Implementation==\n\nImplementations for the reference client is available at:\n\nhttps://github.com/bitcoin/bitcoin/blob/35fe0393f216aa6020fc929272118eade5628636/src/script/interpreter.cpp#L185\n\nand\n\nhttps://github.com/bitcoin/bitcoin/pull/8634\n\n\n==Footnotes==\n\n\n\n\n==Acknowledgements==\n\nThis document is extracted from the previous [https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki BIP62] proposal which had input from various people.\n\n\n==Copyright==\n\nThis document is placed in the public domain.", "category": "bips" }, { "instruction": "Can you explain 
 like we're having a beer and talking Bitcoin?",
    "input": "",
    "output": "BIP: 120\n  Layer: Applications\n  Title: Proof of Payment\n  Authors: Kalle Rosenbaum \n  Status: Closed\n  Type: Specification\n  Assigned: 2015-07-28\n
\n\n== Abstract ==\n\nThis BIP describes a system called Proof of Payment, PoP. It is used to prove that a wallet has the credentials that were used to sign a previously generated transaction. Or simply put, it lets you prove that you have made a payment.\n\n== Motivation ==\n\nThere are several scenarios in which it would be useful to prove that you have paid for something. For example:\n\n* A pre-paid hotel room where your PoP functions as a key to the door.\n* An online video rental service where you pay for a video and watch it on any device.\n* An ad-sign where you pay in advance for e.g. 2 weeks exclusivity. During this period you can upload new content to the sign whenever you like using PoP.\n* Log in to a pay site using a PoP.\n* A parking lot you pay for monthly and the car authenticates itself using PoP.\n* A lottery where all participants pay to the same address, and the winner is selected among the transactions to that address. You exchange the prize for a PoP for the winning transaction.\n\nWith Proof of Payment, these use cases can be achieved without any personal information (user name, password, e-mail address, etc) being involved.\n\n== Rationale ==\n\nDesirable properties:", "category": "bips" }, { "instruction": "How would you explain Bitcoin Operations Guide to someone who knows Bitcoin basics?", "input": "", "output": "# It should prove that you have enough credentials to unlock all the inputs of the proven transaction.", "category": "bips" }, { "instruction": "I'm trying to understand It should be easy to implement by wallets and servers to ease adoption. - can you walk me through it?", "input": "", "output": "Current methods of proving a payment:\n\n* In BIP0070, the PaymentRequest together with the transactions fulfilling the request makes some sort of proof. However, it does not meet 1, 2 or 4 and it obviously only meets 3 if the payment is made through BIP0070. Also, there's no standard way to request/provide the proof. If standardized it would probably meet 5.\n* Signing messages, chosen by the server, with the private keys used to sign the transaction. This could meet 1 and 2 but probably not 3. This is not standardized either. 4 Could be met if designed so.\n\nIf an input script type is P2SH, any satisfying script should do, just as if it was a payment. For M-of-N multisig scripts, that would mean that any set of M keys should be sufficient, not necessarily the same set of M keys that signed the transaction. This is important because strictly demanding the same set of M keys would defeat the purpose of a multisig address.\n\n== Specification ==\n\n=== Data structure ===\n\nA proof of payment for a transaction T, here called PoP(T), is used to prove that one has ownership of the credentials needed to unlock all the inputs of T. It has the exact same structure as a bitcoin transaction with the same inputs as T and in the same order as in T, but with each sequence number set to 0. There is exactly one output, here called the pop output, with value 0. The pop output must have the following format:\n\n OP_RETURN \n\n{|\n! Field !! Size [B] !! Description\n|-\n| <version> || 2 || Version, little endian, currently 0x01 0x00\n|-\n| <txid> || 32 || The transaction to prove\n|-\n| <nonce> || 6 || Random data\n|}\n\nThe lock_time of the PoP must be set to 499999999 to prevent the PoP from being included in a block, should it appear on the bitcoin p2p network. This is also the reason for setting the sequence numbers to 0, since sequence number of ffffffff would make lock_time ineffective. This specification demands that all input sequence numbers are 0, not just one of them, which would be sufficient to make lock_time effective. This is for simplicity reasons.\n\nAn illustration of the PoP data structure and its original payment is shown below.\n\n
\n  T\n +------------------------------------------------+\n |inputs                | outputs                 |\n |       Value,Sequence | Value,Script            |\n +------------------------------------------------+\n |input0 1,ffffffff     | 0,pay to A              |\n |input1 3,ffffffff     | 2,OP_RETURN  |\n |input2 4,ffffffff     | 1,pay to B              |\n |                      | 4,pay to C              |\n +------------------------------------------------+\n\n  PoP(T)\n +-------------------------------------------------------------+\n | inputs               | outputs                              |\n |       Value,Sequence | Value,Script                         |\n +-------------------------------------------------------------+\n |input0 1,00000000     | 0,OP_RETURN    |\n |input1 3,00000000     |                                      |\n |input2 4,00000000     |                                      |\n +-------------------------------------------------------------+\n | lock_time=499999999                                         |\n +-------------------------------------------------------------+\n
\n\nThe PoP is signed using the same signing process that is used for bitcoin transactions.\n\nThe purpose of the nonce is to make it harder to use a stolen PoP; Once the PoP has reached the server, that PoP is useless since the server will generate a new nonce for every PoP request.\n\n=== Process ===", "category": "bips" }, { "instruction": "Hey, I need to set up A proof of payment request is sent from the server to the wallet. The PoP request contains: - what's the command line way to do that?", "input": "", "output": "## a random nonce\n## a destination where to send the PoP, for example a https URL\n## data hinting the wallet which transaction to create a proof for. For example:\n##* txid, if known by the server\n##* PaymentRequest.PaymentDetails.merchant_data (in case of a BIP0070 payment)\n##* amount, label, message or other information from a BIP0021 URI", "category": "bips" }, { "instruction": "What's the deal with Bitcoin Operations Guide in Bitcoin? Explain it like I'm a friend.", "input": "", "output": "# The wallet identifies a transaction T, if possible. Otherwise it asks the user to select among the ones that match the hints in 1.iii.", "category": "bips" }, { "instruction": "Can you show me the CLI commands for The wallet displays the response in some way to the user.?", "input": "", "output": "'''Remarks:'''\n\n* The method of transferring the PoP request at step 1 is not specified here. Instead that is specified in separate specifications, see BIP0121.\n* The nonce must be randomly generated by the server for every new PoP request.\n\n=== Validating a PoP ===\n\nThe server needs to validate the PoP and reply with \"valid\" or \"invalid\". That process is outlined below. If any step fails, the validation is aborted and \"invalid\" is returned:", "category": "bips" }, { "instruction": "I'm stuck with Bitcoin Operations Guide - what should I check?", "input": "", "output": "# Check the format of the PoP. It must pass normal transaction checks, except that the inputs may already be spent.", "category": "bips" }, { "instruction": "How do I troubleshoot Bitcoin Operations Guide issues?", "input": "", "output": "# Check that there is exactly one output. This output must have value 0 and conform to the OP_RETURN output format outlined above.", "category": "bips" }, { "instruction": "What are the best practices for Bitcoin Operations Guide?", "input": "", "output": "# Check that the inputs of the PoP are exactly the same as in transaction T, except that the sequence numbers must all be 0. The ordering of the inputs must also be the same as in T.", "category": "bips" }, { "instruction": "Walk me through setting up Bitcoin Operations Guide step by step", "input": "", "output": "# Check that the txid in the PoP output is the transaction you actually want proof for. If you don’t know exactly what transaction you want proof for, check that the transaction actually pays for the product/service you deliver.", "category": "bips" }, { "instruction": "What commands would you run to work with Return \"valid\".?", "input": "", "output": "== Security considerations ==\n\n* Someone can intercept the PoP-request and change any parameter in it. These can be mitigated by using secure connections. Examples of tampered parameters:\n** Pop destination - Stealing your PoP.\n** label - Trick you to sign an unintended pop or set a label that your wallet doesn't have any record for, resulting in a broken service. Always check the PoP before signing.\n** nonce - Your pop will not validate on server.\n* Someone can steal a PoP, for example by tampering with the PoP request, and try to use the service hoping to get a matching nonce. Probability per try: 1/(2^48). The server should have a mechanism for detecting a brute force attack of this kind, or at least slow down the process by delaying the PoP request by some 100 ms or so.\n* Even if a wallet has no funds it might still be valuable as a generator for PoPs. This makes it important to keep the security of the wallet after it has been emptied.\n* Transaction malleability may cause the server to have a different transaction id for a payment than the client's wallet. In that case the wallet will not be able to prove the transaction to the server. Wallets should not rely on the transaction id of the outgoing transaction. Instead it should listen for the transaction on the network and put that in its list of transactions.\n\n== Reference implementation ==\n\n[https://github.com/kallerosenbaum/poppoc PoP Demo server on GitHub]\n\n[https://github.com/kallerosenbaum/wallet PoP-enabled Mycelium fork on GitHub]\n\n== References ==\n\n[https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki BIP0021]: URI Scheme\n\n[https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki BIP0070]: Payment Protocol\n\n[https://github.com/bitcoin/bips/blob/master/bip-0121.mediawiki BIP0121]: Proof of Payment URI scheme", "category": "bips" }, { "instruction": "I want to understand 
 from a technical perspective",
    "input": "",
    "output": "BIP: 19\n  Layer: Applications\n  Title: M-of-N Standard Transactions (Low SigOp)\n  Authors: Luke Dashjr \n  Status: Closed\n  Type: Specification\n  Assigned: 2012-01-30\n  License: BSD-2-Clause\n
\n\n==Abstract==\n\nThis BIP proposes M-of-N-signatures required transactions as a new 'standard' transaction type using the existing scripting system without significant modifications.\n\n==Copyright==\n\nThis BIP is licensed under the BSD 2-clause license.\n\n==Motivation==\n\nEnable secured wallets, escrow transactions, and other use cases where redeeming funds requires more than a single signature.\n\nA couple of motivating use cases:\n\n* A wallet secured by a \"wallet protection service\" (WPS). 2-of-2 signatures required transactions will be used, with one signature coming from the (possibly compromised) computer with the wallet and the second signature coming from the WPS. When sending protected bitcoins, the user's bitcoin client will contact the WPS with the proposed transaction and it can then contact the user for confirmation that they initiated the transaction and that the transaction details are correct. Details for how clients and WPS's communicate are outside the scope of this BIP. Side note: customers should insist that their wallet protection service provide them with copies of the private key(s) used to secure their wallets that they can safely store off-line, so that their coins can be spent even if the WPS goes out of business.\n\n* Three-party escrow (buyer, seller and trusted dispute agent). 2-of-3 signatures required transactions will be used. The buyer and seller and agent will each provide a public key, and the buyer will then send coins into a 2-of-3 CHECKMULTISIG transaction and send the seller and the agent the transaction id. The seller will fulfill their obligation and then ask the buyer to co-sign a transaction ( already signed by seller ) that sends the tied-up coins to him (seller).
If the buyer and seller cannot agree, then the agent can, with the cooperation of either buyer or seller, decide what happens to the tied-up coins. Details of how buyer, seller, and agent communicate to gather signatures or public keys are outside the scope of this BIP.\n\n==Specification==\n\nTwo new standard transaction types (scriptPubKey) that are relayed by clients and included in mined blocks.\n\nN-of-N (all signatures required):\n\n ( {pubkey} OP_CHECKSIGVERIFY )*n\n\nN-of-M (some signatures required):\n\n {pubkey} OP_CHECKSIG ( OP_SWAP {pubkey} OP_CHECKSIG OP_ADD )*(n-1) n OP_EQUAL\n\nBut only for n less than or equal to 3.\n\nThese transactions are redeemed using a standard scriptSig:\n ...signatures...\n\nThe current Satoshi bitcoin client does not relay or mine transactions with scriptSigs larger than 200 bytes; to accommodate 3-signature transactions, this will be increased to 500 bytes.\n\n===Templates===\nscriptPubKey:\n\n {pubkey} OP_CHECKSIGVERIFY {pubkey} OP_CHECKSIGVERIFY\n\n {pubkey} OP_CHECKSIGVERIFY {pubkey} OP_CHECKSIGVERIFY {pubkey} OP_CHECKSIGVERIFY\n\n {pubkey} OP_CHECKSIG OP_SWAP {pubkey} OP_CHECKSIG OP_ADD {n} OP_EQUAL\n\n {pubkey} OP_CHECKSIG OP_SWAP {pubkey} OP_CHECKSIG OP_ADD OP_SWAP {pubkey} OP_CHECKSIG OP_ADD {n} OP_EQUAL\n\nscriptSig:\n\n ...signatures... up to 500 bytes\n\n==Rationale==\n\nOP_CHECKMULTISIG is already an enabled opcode, and is the most straightforward way to support several important use cases.\nThis is already specified in [[bip-0011.mediawiki|BIP 0011]].\nHowever, each OP_CHECKMULTISIG counts toward the block limit as 20 sigops, which only allows 1000 total multisig transactions in a block.\nUsing OP_CHECKSIG only counts as 1 per signature, so can scale better.\n\n==Implementation==\n\nAll used operations are already supported by old clients and miners as a non-standard transaction type.", "category": "bips" }, { "instruction": "Can you explain like we're having a beer and talking Bitcoin?", "input": "", "output": "
\n  BIP: 127\n  Layer: Applications\n  Title: Simple Proof-of-Reserves Transactions\n  Authors: Steven Roose \n  Status: Draft\n  Type: Specification\n  Assigned: 2019-01-28\n  License: CC0-1.0\n
\n\n\n==Abstract==\n\nThis BIP describes a simple way to construct proof-of-reserves transactions.\nThis proposal formalizes a standard format for constructing such proofs, easing\ntheir construction with existing wallet infrastructure and enabling general\nproof-verification software. It relies on existing standards such as regular\nBitcoin transaction serialization/validation and the BIP 174 PSBT format.\nThe proposal also includes the description of a PSBT extension for a better\nuser experience.\n\n==Copyright==\n\nThis BIP is licensed under the Creative Commons CC0 1.0 Universal license.\n\n==Motivation==\n\nFrom the very early days in the history of Bitcoin, there have been companies\nmanaging bitcoins for their users. These users give up control over their coins\nin return for a certain service. Inevitably, there have been many cases of\ncompanies losing their users' bitcoins without timely disclosing such events to\nthe public. Proofs of Reserves are a way for companies managing large amounts\nof bitcoins to prove ownership over a given amount of funds. The regular proof\nof control helps to ensure that no significant loss has occurred.\n\nWhile the term proof-of-reserves is not new by any means, the procedure is not\nvery common among high-value custodian companies. One of the reasons for this\nis that every company that wants to perform a proof-of-reserves has to construct\nits own way to do so. Accordingly, their users have to understand the\nconstruction of the proof in order to be able to verify it. This raises the bar\nof entry both for custodians and for users.\n\n\n===What this BIP is not doing===\n\nThe proof-of-reserve construction described in this document has some known\nshortcomings, mostly with regards to its privacy properties. While there exists\nresearch about improved proof-of-reserves mechanisms that have much better\nprivacy propertiesDagher, Gaby G., Benedikt Bünz, Joseph Bonneau, Jeremy\nClark, and Dan Boneh. \"Provisions: Privacy-preserving proofs of solvency for\nBitcoin exchanges.\" (2015)., this BIP intentionally only formalizes\nthe de-facto existing method.\n\n\n==Specification==\n\nOur specification consists of two parts:", "category": "bips" }, { "instruction": "How would you explain a file format used to package a set of proofs and relevant metadata to someone who knows Bitcoin basics?", "input": "", "output": "The final construction should have the following properties:\n* flexible proof construction to support complex wallet infrastructures\n* easy integration with existing wallet solutions (both hardware and software wallets)\n* support for verification via a standard procedure, regardless of publisher of the proof\n* proof prevents reuse of proofs by other parties by committing to a message\n* allow validating that the issuer had the funds under his control at a certain block, regardless of what happened after that block\n\n===Proof Format===\n\nTo allow for maximal compatibility with existing systems, proofs are formatted as regular Bitcoin\ntransactions. However, one small adaptation to the transaction is made that has two functions:", "category": "bips" }, { "instruction": "I'm trying to understand link the proof to the issuer of the proof to prevent copying proofs from other custodians - can you walk me through it?", "input": "", "output": "The resulting construction is a Bitcoin transaction with the following\ncharacteristics:\n\n* The first input (the \"commitment input\")\n** MUST have the txid part of the previous outpoint set to the SHA-256 hash of the commitment message prefixed with \"Proof-of-Reserves: \"If the message is \"Some Message\", the txid part should be SHA-256(\"Proof-of-Reserves: Some Message\") with the string encoded as UTF-8. and index 0.\n* The remaining inputs\n** MUST have signatures that commit to the commitment input (e.g. using SIGHASH_ALL).\n* The transaction MUST have a single output that is the exact sum of all the inputs, assuming the commitment input to have 0 value; this means the transaction has no miner fee.\n\nThe existence of the first input (which is just a commitment hash) ensures\nthat this transaction is invalid and can never be confirmed.\n\n\n===Proof File Format===\n\nIn theory, the first part of the specification would be sufficient as a minimum\nviable standard. However, there are a number of motivations to extend the\nstandard with an extra layer of metadata:", "category": "bips" }, { "instruction": "Hey, I need to set up constructing and combining multiple proofs - what's the command line way to do that?", "input": "", "output": "#:Having thousands of UTXOs spread across different offline and online wallets could make it difficult to construct a single proof transaction with all UTXOs. Allowing multiple proof transactions with the same commitment message and block number gives extra flexibility to custodians with complex wallet infrastructure without making the combined proof less secure.", "category": "bips" }, { "instruction": "What's the deal with metadata for verification in Bitcoin? Explain it like I'm a friend.", "input": "", "output": "#:Not all systems that will be used for verification have access to a full index of all transactions. However, proofs should be easily verifiable even after some of the UTXOs used in the proof are no longer unspent. Metadata present in the proof allows for relatively efficient verification of proofs even if no transaction index is available.", "category": "bips" }, { "instruction": "Can you show me the CLI commands for potential future improvements?", "input": "", "output": "#:The extensible metadata format allows for amending the standard in the future. One potential improvement would be having UTXO set commitments. These would allow the proofs-of-reserves to come with accompanying proofs-of-inclusion of all used UTXOs in the UTXO set at the block of proof construction (making validation even more efficient).\n\nThe proposed proof-file format provides a standard way of combining multiple\nproofs and associated metadata. The specification of the format is in the\nProtocol Buffershttps://github.com/protocolbuffers/protobuf/ format.\n\n
\nsyntax = \"proto3\";\nimport \"google/protobuf/any.proto\";\n\nmessage OutputMeta {\n\t// Identify the outpoint.\n\tbytes txid = 1;\n\tuint32 vout = 2;\n\n\t// The block hash of the block where this output was created.\n\tbytes block_hash = 3;\n}\n\nmessage FinalProof {\n\t// The proof transaction.  Should be able to be parsed like a regular\n\t// Bitcoin transaction.\n\tbytes proof_tx = 1;\n\n\t// The metadata of the outputs used in the proof transaction.\n\trepeated OutputMeta output_metadata = 2;\n}\n\nmessage ProofOfReserves {\n\t// A version number for this format to enable extending it with\n\t// additional fields.\n\tuint32 version = 1;\n\n\t// The network magic for the network in which the proofs are valid.\n\t// 0xD9B4BEF9 for mainnet, 0x0709110B for testnet\n\t//TODO consider BIP44 coin type ids instead:\n\t// https://github.com/satoshilabs/slips/blob/master/slip-0044.md\n\tuint32 network_magic = 2;\n\n\t// The commitment message for this proof-of-reserves.\n\t// This message is global for all the proofs.\n\tstring message = 3;\n\n\t// The block at which this proof is supposed to be validated.\n\t// Verification should take into account unspentness of outputs at this\n\t// block height.\n\tbytes block_hash = 4;\n\n\t// The set of final proof transactions with their output metadata.\n\trepeated FinalProof final_proofs = 5;\n\n\t// Reserved field that can potentially be used by proof-construction tools.\n\t// It can be ignored for verification.\n\trepeated google.protobuf.Any pending_proofs = 6;\n}\n
\n\nThe last field, pending_proofs, leaves open some space in the same\nfile that can be used by proof-construction tools. This allows them to\nconstruct different proofs incrementally without having to switch between file\nformats.\n\n\n===PSBT (BIP 174) extension===\n\nThe \"commitment input\" detailed in the proof format section does not spend an\nexisting UTXO and thus shouldn't be signed (empty scriptSig and\nwitness). This can cause some problems when signing this type of transactions.\nFor example, hardware wallets often require the signer to provide information\nabout all inputs of transactions they are signing, such as the previous output\nor previous transaction; this data obviously doesn't exist for the commitment\ninputs.\n\nFor most existing devices, it's possible to circumvent these requirements by\nproviding dummy data or by instructing the device to ignore this specific\ninput. However, there is still a UX problem. Because the hardware wallet\ndevice doesn't recognize the transaction as a proof-of-reserves transaction it\nwill think it is signing a regular transaction that is spending all the money\nin the UTXOs. Most devices will ask for confirmation with a message along the\nlines of \"Are you sure you want to send XXX BTC to address [...]?\". This is\nnot the best user experience.\n\nAn addition to the BIP 174 PSBT format could help signing devices to recognize proof-of-reserve transactions.\nThe following field is added to the BIP 174 INPUT map:\n\n* Type: Proof-of-reserves commitment PSBT_IN_POR_COMMITMENT = 0x09\n** Key: None. The key must only contain the 1 byte type.\n*** {0x09}\n** Value: The UTF-8 encoded commitment message string for the proof-of-reserves.\n*** {porCommitment}\n\nWallets processing an input that has this field set\n* MUST make sure the txid of the previous outpoint is set to the SHA-256 hash of the prefixed commitment message string, as detailed above;\n* MUST assume the input value to be 0 (without requiring the previous output or transaction to be provided);\n* SHOULD display the commitment message to ask the user for confirmation before signing any inputs;\n* SHOULD only provide signatures with a signature hash that commits to this input;\n* SHOULD accept an empty scriptSig for this input (as if the scriptPubKey was OP_TRUE).\n\n\n==Compatibility==\n\nThe proof transaction specification is based on the Bitcoin transaction\nserialization protocol and will thus always be compatible with serializers\nthat can interpret Bitcoin transactions. The protobuf file format is custom\nto this BIP and has a version byte to enable updates while attempting to remain\nbackwards compatible.\n\n\n==Implementations==\n\nA proof-of-concept implementation of the PSBT extension in the\n[https://github.com/rust-bitcoin/rust-bitcoin rust-bitcoin] project can be\nfound in the psbt-por branch here:\nhttps://github.com/stevenroose/rust-bitcoin/tree/psbt-por\n\nA work-in-progress implementation of a tool that produces and verifies proofs\nin the described format can be found here:\nhttps://github.com/stevenroose/reserves\n\nAn implementation of the custom proof PSBTs is part of the [https://bitcoindevkit.org/ BDK], and can be found here: https://crates.io/crates/bdk-reserves\n\n== Footnotes ==\n\n", "category": "bips" }, { "instruction": "I'm stuck with 
 - what should I check?",
    "input": "",
    "output": "BIP: 324\n  Layer: Peer Services\n  Title: Version 2 P2P Encrypted Transport Protocol\n  Authors: Dhruv Mehta \n           Tim Ruffing \n           Jonas Schnelli \n           Pieter Wuille \n  Status: Deployed\n  Type: Specification\n  Assigned: 2019-03-08\n  License: BSD-3-Clause\n  Version: 1.0.2\n  Replaces: 151\n
\n\n== Introduction ==\n\n=== Abstract ===\nThis document proposes a new Bitcoin P2P transport protocol, which features opportunistic encryption, a mild bandwidth reduction, and the ability to negotiate upgrades before exchanging application messages.\n\n=== Copyright ===\nThis document is licensed under the 3-clause BSD license.\n\n=== Motivation ===\nBitcoin is a permissionless network whose purpose is to reach consensus over public data. Since all data relayed in the Bitcoin P2P network is inherently public, and the protocol lacks a notion of cryptographic identities, peers talk to each other over unencrypted and unauthenticated connections. Nevertheless, this plaintext nature of the current P2P protocol (referred to as v1 in this document) has severe drawbacks in the presence of attackers:\n\n* While the relayed data itself is public in nature, the associated metadata may reveal private information and hamper privacy of users. For example, a global passive attacker eavesdropping on all Bitcoin P2P connections can trivially identify the source and timing of a transaction.\n* Since connections are unauthenticated, they can be tampered with at a low cost and often even with a low risk of detection. For example, an attacker can alter specific bytes of a connection (such as node flags) on-the-fly without the need to keep any state.\n* The protocol is self-revealing. For example, deep packet inspection can identify a P2P connection trivially because connections start with a fixed sequence of magic bytes. The ability to detect connections enables censorship and facilitates the aforementioned attacks as well as other attacks which require the attacker to control the connections of victims, e.g., eclipse attacks targeted at miners.\n\nThis proposal for a new P2P protocol version (v2) aims to improve upon this by raising the costs for performing these attacks substantially, primarily through the use of unauthenticated, opportunistic transport encryption. In addition, the bytestream on the wire is made pseudorandom (i.e., indistinguishable from uniformly random bytes) to a passive eavesdropper.\n\n* Encryption, even when it is unauthenticated and only used when both endpoints support v2, impedes eavesdropping by forcing the attacker to become active: either by performing a persistent man-in-the-middle (MitM) attack, by downgrading connections to v1, or by spinning up their own nodes and getting honest nodes to make connections to them. Active attacks at scale are more resource intensive in general, but in the case of manual, deliberate connections (as opposed to automatic, random ones), they are also in principle detectable: even very basic checks, e.g., operators manually comparing protocol versions and session IDs (as supported by the proposed protocol), will expose the attacker.\n* Tampering, while already an inherently active attack, is costlier if the attacker is forced to maintain the state necessary for a full MitM interception.\n* A pseudorandom bytestream excludes identification techniques based on pattern matching, and makes it easier to shape the bytestream in order to mimic other protocols used on the Internet. This raises the cost of a connection censoring firewall, forcing them to either resort to a full MitM attack, or operate on a more obvious allowlist basis, rather than a blocklist basis.\n\n''' Why encrypt without authentication?'''\n\nAs we have argued above, unauthenticated encryption'''What does ''authentication'' mean in this context?''' Unfortunately, the term authentication in the context of secure channel protocols is ambiguous. It can refer to:\n* The encryption scheme guaranteeing that a message obtained via successful decryption was encrypted by someone having access to the (symmetric) encryption key, and not modified after encryption by a third party. The proposal in this document achieves that property through the use of an AEAD.\n* The communication protocol establishing that the communication partner's identity matches who we expect them to be, through some public key mechanism. The proposal in this document does '''not''' include such a mechanism. provides strictly better security than no encryption. Thus, all connections should use encryption, even if they are unauthenticated.\n\nWhen it comes to authentication, the situation is not as clear as for encryption. Due to Bitcoin's permissionless nature, authentication will always be restricted to specific scenarios (e.g., connections between peers belonging to the same operator), and whether some form of (possibly partially anonymous) authentication is desired depends on the specific requirements of the involved peers. As a consequence, we believe that authentication should be addressed separately (if desired), and this proposal aims to provide a solid technical basis for future protocol upgrades, including the addition of optional authentication (see [https://github.com/sipa/writeups/tree/main/private-authentication-protocols Private authentication protocols]).\n\n''' Why have a pseudorandom bytestream when traffic analysis is still possible? '''\n\nTraffic analysis, e.g., observing packet lengths and timing, as well as active attacks can still reveal that the Bitcoin v2 P2P protocol is in use. Nevertheless, a pseudorandom bytestream raises the cost of fingerprinting the protocol substantially, and may force some intermediaries to attack any protocol they cannot identify, causing collateral cost.\n\nA pseudorandom bytestream is not self-identifying. Moreover, it is unopinionated and thus a canonical choice for similar protocols. As a result, Bitcoin P2P traffic will be indistinguishable from traffic of other protocols which make the same choice (e.g., [https://gitlab.com/yawning/obfs4 obfs4] and a recently proposed [https://datatracker.ietf.org/doc/draft-cpbs-pseudorandom-ctls/ cTLS extension]). Moreover, traffic shapers and protocol wrappers (for example, making the traffic look like HTTPS or SSH) can further mitigate traffic analysis and active attacks but are out of scope for this proposal.\n\n''' Why not use a secure tunnel protocol? '''\n\nOur goal includes making opportunistic encryption ubiquitously available, as that provides the best defense against large-scale attacks. That implies protecting both the manual, deliberate connections node operators instruct their software to make, and the automatic connections Bitcoin nodes make with each other based on IP addresses obtained via gossip. While encryption per se is already possible with proxy networks or VPN protocols, these are not desirable or applicable for automatic connections at scale:\n* Proxy networks like Tor or I2P introduce a separate address space, independent of network topology, with a very low cost per address making eclipse attacks cheaper. In comparison, clearnet IPv4 and IPv6 networks make obtaining multiple network identities in distinct, well-known network partitions carry a non-trivial cost. Thus, it is not desirable to have a substantial portion of nodes be exclusively connected this way, as this would significantly reduce Eclipse attack costs.'''Why is it a bad idea to have nodes exclusively connected over Tor?''' See the [https://arxiv.org/abs/1410.6079 Bitcoin over Tor isn't a Good Idea] paper Additionally, Tor connections come with significant bandwidth and latency costs that may not be desirable for all network users.\n* VPN protocols like WireGuard or OpenVPN inherently define a private network, which requires manual configuration and therefore is not a realistic avenue for automatic connections.\n\nThus, to achieve our goal, we need a solution that has minimal costs, works without configuration, and is always enabled – on top of any network layer rather than be part of the network layer.\n\n''' Why not use a general-purpose transport encryption protocol? '''\n\nWhile it would be possible to rely on an off-the-shelf transport encryption protocol such as TLS or Noise, the specific requirements of the Bitcoin P2P network laid out above make these protocols an unsuitable choice.\n\nThe primary requirement which existing protocols fail to meet is a sufficiently modular treatment of encryption and authentication. As we argue above, whether and which form of authentication is desired in the Bitcoin P2P network will depend on the specific requirements of the involved peers (resulting in a mix of authenticated and unauthenticated connections), and thus the question of authentication should be decoupled from encryption. However, native support for a handful of standard authentication scenarios (e.g., using digital signatures and certificates) is at the core of the design of existing general-purpose transport encryption protocols. This focus on authentication would not provide clear benefits for the Bitcoin P2P network but would come with a large amount of additional complexity.\n\nIn contrast, our proposal instead aims for a simple modular design that makes it possible to address authentication separately. Our proposal provides a foundation for authentication by exporting a ''session ID'' that uniquely identifies the encrypted channel. After an encrypted channel has been established, the two endpoints are able to use any authentication protocol to confirm that they have the same session ID. (This is sometimes called ''channel binding'' because the session ID binds the encrypted channel to the authentication protocol.) Since in our proposal, any authentication needs to run after an encrypted connection has been established, the price we pay for this modularity is a possibly higher number of roundtrips as opposed to other protocols that perform authentication alongside the Diffie-Hellman key exchange.'''Do other protocols not support exporting a session ID?''' While [https://noiseprotocol.org/noise.html#channel-binding Noise] and [https://datatracker.ietf.org/doc/draft-ietf-kitten-tls-channel-bindings-for-tls13/ TLS (as a draft)] offer similar protocol extensions for exporting session IDs, using channel binding for authentication is not at the focus of their design and would not avoid the bulk of additional complexity due to the native support of authentication methods. However, the resulting increase in connection establishment latency is a not a concern for Bitcoin's long-lived connections, [https://www.dsn.kastel.kit.edu/bitcoin/ which typically live for hours or even weeks].\n\nBesides this fundamentally different treatment of authentication, further technical issues arise when applying TLS or Noise to our desired use case:\n\n* Neither offers a pseudorandom bytestream.\n* Neither offers native support for elliptic curve cryptography on the curve secp256k1 as otherwise used in Bitcoin. While using secp256k1 is not strictly necessary, it is the obvious choice is for any new asymmetric cryptography in Bitcoin because it minimizes the cryptographic hardness assumptions as well as the dependencies that Bitcoin software will need.\n* Neither offers shapability of the bytestream.\n* Both provide a stream-based interface to the application layer, whereas Bitcoin requires a packet-based interface, resulting in the need for an additional thin layer to perform packet serialization and deserialization.\n\nWhile existing protocols could be amended to address all of the aforementioned issues, this would negate the benefits of using them as off-the-shelf solution, e.g., the possibility to re-use existing implementations and security analyses.\n\n== Goals ==\n\nThis proposal aims to achieve the following properties:\n\n* Confidentiality against passive attacks: A passive attacker having recorded a v2 P2P bytestream (without timing and fragmentation information) must not be able to determine the plaintext being exchanged by the nodes.\n* Observability of active attacks: A session ID identifying the encrypted channel uniquely is derived deterministically from a Diffie-Hellman negotiation. An active man-in-the-middle attacker is forced to incur a risk of being detected as peer operators can compare session IDs manually, or using optional authentication methods possibly introduced in future protocol versions.\n* Pseudorandom bytestream: A passive attacker having recorded a v2 P2P bytestream (without timing information and fragmentation information) must not be able to distinguish it from a uniformly random bytestream.\n* Shapable bytestream: It should be possible to shape the bytestream to increase resistance to traffic analysis (for example, to conceal block propagation), or censorship avoidance.'''How can shapability help circumvent fragmentation-pattern based censoring?''' See [https://gitlab.torproject.org/legacy/trac/-/issues/20348#note_2229522 this Tor issue] as an example.\n* Forward secrecy: An eavesdropping attacker who compromises a peer's sessions secrets should not be able to decrypt past session traffic, except for the latest few packets.\n* Upgradability: The proposal provides an upgrade path using transport versioning which can be used to add features like authentication, PQC handshake upgrade, etc. in the future.\n* Compatibility: v2 clients will allow inbound v1 connections to minimize risk of network partitions.\n* Low overhead: the introduction of a new P2P transport protocol should not substantially increase computational cost or bandwidth for nodes that implement it, compared to the current protocol.\n\n== Specification ==\n\nThe specification consists of three parts:\n\n* The '''Transport layer''' concerns how to set up an encrypted connection between two nodes, capable of transporting application-level messages between them.\n* The '''Application layer''' concerns how to encode Bitcoin P2P messages and commands for transport by the Transport Layer.\n* The '''Signaling''' concerns how v2 nodes advertise their support for the v2 protocol to potential peers.\n\n=== Transport layer specification ===\n\nIn this section, we define the encryption protocol for messages between peers.\n\n==== Overview and design ====\n\nWe first give an informal overview of the entire protocol flow and packet encryption.\n\n'''Protocol flow overview'''\n\nGiven a newly established connection (typically TCP/IP) between two v2 P2P nodes, there are 3 phases the connection goes through. The first starts immediately, i.e. there are no v1 messages or any other bytes exchanged on the link beforehand. The two parties are called the '''initiator''' (who established the connection) and the '''responder''' (who accepted the connection).", "category": "bips" }, { "instruction": "How do I troubleshoot The '''Key exchange phase''', where nodes exchange data to establish shared secrets. issues?", "input": "", "output": "#* The initiator:\n#** Generates a random ephemeral secp256k1 private key and sends a corresponding 64-byte ElligatorSwift'''What is ElligatorSwift and why use it?''' The [https://eprint.iacr.org/2022/759.pdf SwiftEC paper] describes a method called ElligatorSwift which allows encoding elliptic curve points in a way that is indistinguishable from a uniformly distributed bitstream. While a random 256-bit string has about 50% chance of being a valid X coordinate on the secp256k1 curve, every 512-bit string is a valid ElligatorSwift encoding of a curve point, making the encoded point indistinguishable from random when using an encoder that can sample uniformly.'''How fast is ElligatorSwift?''' Our benchmarks show that ElligatorSwift encoded ECDH is about 50% more expensive than unencoded ECDH. Given the fast performance of ECDH and the low frequency of new connections, we found the performance trade-off acceptable for the pseudorandom bytestream and future censorship resistance it can enable.-encoded public key to the responder.\n#** May send up to 4095'''How was the limit of 4095 bytes garbage chosen?''' It is a balance between having sufficient freedom to hide information, and allowing it to be large enough so that the necessary 64 bytes of public key is small compared to it on the one hand, and bandwidth waste on the other hand. bytes of arbitrary data after their public key, called '''garbage''', providing a form of shapability and avoiding a recognizable pattern of exactly 64 bytes.'''Why does the affordance for garbage exist in the protocol?''' The garbage strings after the public keys are needed for shapability of the handshake. Neither peer can send decoy packets before having received at least the other peer's public key, i.e., neither peer can send more than 64 bytes before having received 64 bytes.\n#* The responder:\n#** Waits until one byte is received which does not match the 16 bytes consisting of the network magic followed by \"version\\x00\\x00\\x00\\x00\\x00\". If the first 16 bytes do match, the connection is treated as using the v1 protocol instead.'''What if a v2 initiator's public key starts accidentally with these 16 bytes?''' This is so unlikely (probability of ''2-128'') to happen randomly in the v2 protocol that the initiator does not need to specifically avoid it. The optional detection of wrong-network v1 peers has a probability of ''2-96'', which is still negligible compared to random network failures.Bitcoin Core versions <=0.4.0 and >=22.0 ignore valid P2P messages that are received prior to a VERSION message. Bitcoin Core versions between 0.4.0 and 22.0 assign a misbehavior score to the peer upon receiving such messages. v2 clients implementing this proposal will interpret any message other than VERSION received as the first message to be the initiation of a v2 connection, and will result in disconnection for v1 initiators that send any message type other than VERSION as the first message. We are not aware of any implementations where this could pose a problem.\n#** If the first 4 received bytes do not match the network magic, but the 12 bytes after that do match the version message encoding above, implementations may interpret this as a v1 peer of a different network, and disconnect them.\n#** Similarly generates a random ephemeral private key and sends a corresponding 64-byte ElligatorSwift-encoded public key to the initiator.\n#** Similarly may send up to 4095 bytes of garbage data after their public key.\n#* Both parties:\n#** Receive (the remainder of) the full 64-byte public key from the other side.\n#** Use X-only'''Why use X-only ECDH?''' Using only the X coordinate provides the same security as using a full encoding of the secret curve point but allows for more efficient implementation by avoiding the need for square roots to compute Y coordinates. ECDH to compute a shared secret from their private key and the exchanged public keys'''Why is the shared secret computation a function of the exact 64-byte public encodings sent?''' This makes sure that an attacker cannot modify the public key encoding used without modifying the rest of the stream. If a third party wants the ability to modify stream bytes, they need to perform a full MitM attack on the connection., and deterministically derive from the secret 4 '''encryption keys''' (two in each direction: one for packet lengths, one for content encryption), a '''session id''', and two 16-byte '''garbage terminators''''''What length is sufficient for garbage terminators?''' The length of the garbage terminators determines the probability of accidental termination of a legitimate v2 connection due to garbage bytes (sent prior to ECDH) inadvertently including the terminator. 16 byte terminators with 4095 bytes of garbage yield a negligible probability of such collision which is likely orders of magnitude lower than random connection failure on the Internet.'''What does a garbage terminator in the wild look like?'''
[[File:bip-0324/garbage_terminator.png|none|256px|A garbage terminator model TX-v2 in the wild... sent by the responder]]
\n (one in each direction) using HKDF-SHA256.\n#** Send their 16-byte garbage terminator.'''Why does the protocol need a garbage terminator?''' While it is in principle possible to use the first packet after the garbage directly as a terminator (scan until a valid packet follows), this would be significantly slower than just scanning for a fixed byte sequence, as it would require recomputing a Poly1305 tag after every received byte.\n#** Receive up to 4111 bytes, stopping when encountering the garbage terminator.\n#* At this point, both parties have the same keys, and all further communication proceeds in the form of '''encrypted packets'''.\n#** Encrypted packets have an '''ignore bit''', which makes them '''decoy packets''' if set. Decoy packets are to be ignored by the receiver apart from verifying they decrypt correctly. Either peer may send such decoy packets at any point from here on. These form the primary shapability mechanism in the protocol. How and when to use them is out of scope for this document.\n#** For each of the two directions, the first encrypted packet that will be sent in that direction (regardless of it being a decoy packet or not) will make use of the associated authenticated data (AAD) feature of the AEAD to authenticate the garbage that has been sent in that direction.'''Why does the protocol authenticate the garbage?''' Without garbage authentication, the garbage would be modifiable by a third party without consequences. We want to force any active attacker to have to maintain a full protocol state. In addition, such malleability without the consequence of connection termination could enable protocol fingerprinting.", "category": "bips" }, { "instruction": "What are the best practices for The '''Version negotiation phase''', where parties negotiate what transport version they will use, as well as data defined by that version.'''What features could be added in future protocol versions?''' Examples of features that could be added in future versions include post-quantum cryptography upgrades to the handshake, and optional authentication.?", "input": "", "output": "#* The responder:\n#** Sends a '''version packet''' with empty content, to indicate support for the v2 P2P protocol proposed by this document. Any other value for content is reserved for future versions.\n#* The initiator:\n#** Receives a packet, ignores its contents. The idea is that features added by future versions get negotiated based on what is supported by both parties. Since there is just one version so far, the contents here can simply be ignored. But in the future, receiving a non-empty contents here may trigger other behavior; we defer specifying the encoding for such version content until there is a need for it.'''How will future versions encode version numbers in the version packet?''' Future versions could, for example, specify that the contents of the version packet is to be interpreted as an integer version number (with empty representing 0), and if the minimum of both numbers is N, that being interpreted as choosing a \"v2.N\" protocol version. Alternatively, certain bytes of the version packet contents could be interpreted as a bitvector of optional features.\n#** Sends a '''version packet''' with empty content as well, to indicate support for the v2 P2P protocol.\n#* The responder:\n#** Receives a packet, ignores its contents.", "category": "bips" }, { "instruction": "Walk me through setting up The '''Application phase''', where the packets exchanged have contents to be interpreted as application data. step by step", "input": "", "output": "#* Whenever either peer has a message to send, it sends a packet with that application message as '''contents'''.\n\nTo avoid the recognizable pattern of first messages being at least 64 bytes, a future backwards-compatible upgrade to this protocol may allow both peers to send their public key + garbage + garbage terminator in multiple rounds, slicing those bytes up into messages arbitrarily, as long as progress is guaranteed.'''How can progress be guaranteed in a backwards-compatible way?''' In order to guarantee progress, it must be ensured that no deadlock occurs, i.e., no state is reached in which each party waits for the other party indefinitely. For example, any upgrade that adheres to the following conditions will guarantee progress:\n\n* The initiator must start by sending at least as many bytes as necessary to mismatch the magic/version 16 bytes prefix.\n* The responder must start sending after having received at least one byte that mismatches that 16-byte prefix.\n* As soon as either party has received the other peer's garbage terminator, or has received 4095 bytes of garbage, they must send their own garbage terminator. (When either of these conditions is met, the other party has nothing to respond with anymore that would be needed to guarantee progress otherwise.)\n* Whenever either party receives any nonzero number of bytes, while not having sent their garbage terminator completely yet, they must send at least one byte in response without waiting for more bytes.\n* After either party has sent their garbage terminator, they must transition to the version negotiation phase without waiting for more bytes.\n\nSince the protocol as specified here adheres to these conditions, any upgrade which also adheres to these conditions will be backwards-compatible.\n\nNote that the version negotiation phase does not need to wait for the key exchange phase to complete; version packets can be sent immediately after sending the garbage terminator. So the first two phases together, jointly called '''the handshake''', comprise just 1.5 roundtrips:\n\n* the initiator sends public key + garbage\n* the responder sends public key + garbage + garbage terminator + decoy packets (optional) + version packet\n* the initiator sends garbage terminator + decoy packets (optional) + version packet\n\n'''Packet encryption overview'''\n\nAll data on the wire after the garbage terminators takes the form of encrypted packets. Every packet encodes an encrypted variable-length byte array, called the '''contents''', as well as an '''ignore bit''' as mentioned before. The total size of a packet is 20 bytes plus the length of its contents.\n\nEach packet consists of:\n* A 3-byte encrypted '''length''' field, encoding the length of the '''contents''' (between ''0'' and ''224-1'''''Is ''224-1'' bytes sufficient as maximum content size?''' The current Bitcoin P2P protocol has no messages which support more than 4000000 bytes of application payload. By supporting up to ''224-1'' we can accommodate future evolutions needing more than 4 times that value. Hypothetical protocol changes that have even more data to exchange than that should probably use multiple separate messages anyway, because of the per-peer receive buffer sizes involved, and the inability to start processing a message before it is fully received. Of course, future versions of the transport protocol could change the size of the length field, if this were really needed., inclusive).\n* An authenticated encryption of the '''plaintext''', which consists of:\n** A 1-byte '''header''' which consists of transport layer protocol flags. Currently, only the highest bit is defined as the '''ignore bit'''. The other bits are ignored, but this may change in future versions'''Why is the header a part of the plaintext and not included alongside the length field?''' The packet length field is the minimum information that must be available before we can leverage the standard RFC8439 AEAD. Any other data, including metadata like the header being in the content encryption makes it easier to reason about the protocol security w.r.t. data being used before it is authenticated. If the ignore bit was not part of the content, another mechanism would be needed to authenticate it; for example, it could be fed as AAD to the AEAD cipher. We feel the complexity of such an approach outweighs the benefit of saving one byte per message..\n** The variable-length '''contents'''.\n\nThe encryption of the plaintext uses '''[https://en.wikipedia.org/wiki/ChaCha20-Poly1305 ChaCha20Poly1305]''''''Why is ChaCha20Poly1305 chosen as the basis for packet encryption?''' It is a very widely used authenticated encryption cipher (used among others in SSH, TLS 1.2, TLS 1.3, [https://en.wikipedia.org/wiki/QUIC QUIC], Noise, and [https://www.wireguard.com/protocol/ WireGuard]; in the latter it is currently even the only supported cipher), with very good performance in general purpose software implementations. While AES-based ciphers (including the winners in the [https://competitions.cr.yp.to/caesar.html CAESAR] competition in non-lightweight categories) perform significantly better on systems with AES hardware acceleration, they are also significantly slower in pure software implementations. We choose to optimize for the weakest hardware., an [https://en.wikipedia.org/wiki/Authenticated_encryption authenticated encryption with associated data] (AEAD) cipher specified in [https://datatracker.ietf.org/doc/html/rfc8439 RFC 8439]. Every packet's plaintext is treated as a separate AEAD message, with a different nonce for each.\n\nThe length must be dealt with specially, as it is needed to determine packet boundaries before the whole packet is received and authenticated. As we want a stream that is pseudorandom to a passive attacker, it still needs encryption. We use unauthenticated'''Why is the length encryption not separately authenticated?''' Informally, the relevant security goal we aim for is to hide the number of packets and their lengths (i.e., the packet boundaries) against a passive attacker that receives the bytestream without timing or fragmentation information. (A formal definition can be found for example in [https://himsen.github.io/pdf/thesis.pdf Hansen 2016 (Definition 22)] under the name \"boundary hiding against chosen-plaintext attacks (BH-CPA)\".) However, we do not aim to hide packet boundaries against active attackers because active attackers can always exploit the fact that the Bitcoin P2P protocol is largely query-response based: they can trickle the bytes on the stream one-by-one unmodified and observe when a response comes (see [https://himsen.github.io/pdf/thesis.pdf Hansen 2016 (Section 3.9)] for a in-depth discussion). With that in mind, we accept that an active (non-MitM) attacker is able to figure out some information about packet boundaries by flipping certain bits in the unauthenticated length field, and observing the other side disconnecting immediately or later. Thus, we choose to use unauthenticated encryption for the length data, which is sufficient to achieve boundary hiding against passive attackers, and saves 16 bytes of bandwidth per packet. '''ChaCha20''' encryption for this, with an independent key. Note that the plaintext length is still implicitly authenticated by the encryption of the plaintext, but this can only be verified after receiving the whole packet. This design is inspired by that of the ChaCha20Poly1305 cipher suite in [http://bxr.su/OpenBSD/usr.bin/ssh/PROTOCOL.chacha20poly1305 OpenSSH].'''How does packet encryption differ from the OpenSSH design?''' The differences are:\n* The length field is only 3 bytes instead of 4, as that is sufficient for our purposes.\n* Length encryption keeps drawing pseudorandom bytes from the same ChaCha20 cipher for multiple packets, rather than incrementing the nonce for every packet.\n* The Poly1305 authentication tag only covers the encrypted plaintext, and not the encrypted length field. This means that plaintext encryption uses the standard ChaCha20Poly1305 construction without any modifications, maximizing applicability of analysis and review of that cipher. The length encryption can be seen as a separate layer, using a separate key, and thus cannot affect any of the confidentiality or integrity guarantees of the plaintext encryption. On the other hand, this change w.r.t. OpenSSH also does not worsen any properties, as incorrect lengths will still trigger authentication failure for the overall packet (the plaintext length is implicitly authenticated by ChaCha20Poly1305).\n* A hash step is performed every 224'''How was the rekeying interval 224 chosen?''' Assuming a node sends only ping messages every 20 minutes (the timeout interval for post-[https://github.com/bitcoin/bips/blob/master/bip-0031.mediawiki BIP31] connections) on a connection, the node will transmit 224 packets in about 3.11 days. This means ''soft rekeying'' after a fixed number of packets automatically translates to an upper-bound of time interval for rekeying, while being much simpler to coordinate than an actual time-based rekeying regime. At the same time, doing it once every 224 messages is sufficiently infrequent that it has only negligible impact on performance. Furthermore, 224 times 3 bytes (the number of bytes consumed by each length encryption) is 672, which is a multiple of 64 minus 32. This means that at the end of 224 length encryptions, exactly 32 bytes of keystream data remain that can be used as next key. messages to rekey the encryption ciphers, in order to provide forward security.\n Because only fixed-length chunks (3-byte length fields) are encrypted, we do not need to treat all length chunks as separate messages. Instead, a single cipher (with the same nonce) is used for multiple consecutive length fields. This avoids wasting 61 pseudorandom bytes per packet, and makes the cost of having a separate cipher for length encryption negligible.'''Is it acceptable to use a less standard construction for length encryption?''' The fact that multiple (non-overlapping) bytes generated by a single ChaCha20 cipher are used for the encryption of multiple consecutive length fields is uncommon. We feel the performance cost gained by this deviation is worth it (especially for small packets, which are very common in Bitcoin's P2P protocol), given the low guarantees that are feasible for length encryption in the first place, and the result is still sufficient to provide pseudorandomness from the view of passive attackers. For plaintext encryption, we independently use a very standard construction, as the stakes for confidentiality and integrity there are much higher.\n\nIn order to provide forward security'''What value does forward security provide?''' Re-keying ensures [https://eprint.iacr.org/2001/035.pdf forward secrecy within a session], i.e., an attacker compromising the current session secrets cannot derive past encryption keys in the same session.'''Why have a cipher with forward secrecy but no periodical refresh of the ECDH key exchange?''' Our cipher ratchets encryption keys forward in order to protect messages encrypted under ''past'' encryption keys. In contrast, re-performing ECDH key exchange would protect messages encrypted under ''future'' encryption keys, i.e., it would re-establish security after the attacker had compromised one of the peers ''temporarily'' (e.g., the attacker obtains a memory dump). We do not believe protecting against that is a priority: an attacker that, for whatever reason, is capable of an attack that reveals encryption keys (or other session secrets) of a peer once is likely capable of performing the same attack again after peers have re-performed the ECDH key exchange. Thus, we do not believe the benefits of re-performing key exchange outweigh the additional complexity that comes with the necessary coordination between the peers. We note that the initiator could choose to close and re-open the entire connection to force a refresh of the ECDH key exchange, but that introduces other issues: a connection slot needs to be kept open at the responder side, it is not cryptographically guaranteed that really the same initiator will use it, and the observable TCP reset and handshake may create a detectable pattern., the encryption keys for both plaintext and length encryption are cycled every 224 messages, by switching to a new key that is generated by the key stream using the old key.\n\n==== Handshake: key exchange and version negotiation ====\n\nNext we specify the handshake of a connection in detail.\n\nAs explained before, these messages are sent to set up the connection:\n\n
\n ----------------------------------------------------------------------------------------------------\n | Initiator                         Responder                                                      |\n |                                                                                                  |\n | x, ellswift_X = ellswift_create()                                                                |\n |                                                                                                  |\n |    ---- ellswift_X + initiator_garbage (initiator_garbage_len bytes; max 4095) --->              |\n |                                                                                                  |\n |                                   y, ellswift_Y = ellswift_create()                              |\n |                                   ecdh_secret = v2_ecdh(                                         |\n |                                                     y, ellswift_X, ellswift_Y, initiating=False) |\n |                                   v2_initialize(initiator, ecdh_secret, initiating=False)        |\n |                                                                                                  |\n |    <--- ellswift_Y + responder_garbage (responder_garbage_len bytes; max 4095) +                 |\n |             responder_garbage_terminator (16 bytes) +                                            |\n |             v2_enc_packet(initiator, RESPONDER_TRANSPORT_VERSION, aad=responder_garbage) ----    |\n |                                                                                                  |\n | ecdh_secret = v2_ecdh(x, ellswift_Y, ellswift_X, initiating=True)                                |\n | v2_initialize(responder, ecdh_secret, initiating=True)                                           |\n |                                                                                                  |\n |     ---- initiator_garbage_terminator (16 bytes) +                                               |\n |              v2_enc_packet(responder, INITIATOR_TRANSPORT_VERSION, aad=initiator_garbage) --->   |\n |                                                                                                  |\n ----------------------------------------------------------------------------------------------------\n
\n\n===== Shared secret computation =====\n\nThe peers derive their shared secret through X-only ECDH, hashed together with the exactly 64-byte public keys' encodings sent over the wire.\n\n
\ndef v2_ecdh(priv, ellswift_theirs, ellswift_ours, initiating):\n    ecdh_point_x32 = ellswift_ecdh_xonly(ellswift_theirs, priv)\n    if initiating:\n        # Initiating, place our public key encoding first.\n        return sha256_tagged(\"bip324_ellswift_xonly_ecdh\", ellswift_ours + ellswift_theirs + ecdh_point_x32)\n    else:\n        # Responding, place their public key encoding first.\n        return sha256_tagged(\"bip324_ellswift_xonly_ecdh\", ellswift_theirs + ellswift_ours + ecdh_point_x32)\n
\n\nHere, sha256_tagged(tag, x) returns a tagged hash value SHA256(SHA256(tag) || SHA256(tag) || x) as in [https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki#specification BIP340].\n\n===== ElligatorSwift encoding of curve X coordinates =====\n\nThe functions ellswift_create and ellswift_ecdh_xonly encapsulate the construction of ElligatorSwift-encoded public keys, and the computation of X-only ECDH with\nElligatorSwift-encoded public keys.\n\nFirst we define a constant:\n* Let ''c = 0xa2d2ba93507f1df233770c2a797962cc61f6d15da14ecd47d8d27ae1cd5f852''.'''What is the ''c'' constant used in ''XSwiftEC''?''' The algorithm requires a constant ''√-3 (mod p)''; in other words, a number ''c'' such that ''-c2 mod p = 3''. There are two solutions to this equation, one which is itself a square modulo ''p'', and its negation. We choose the square one.\n\nTo define the needed functions, we first introduce a helper function, matching the XSwiftEC function from the [https://eprint.iacr.org/2022/759.pdf SwiftEC] paper, instantiated for the secp256k1 curve, with minor modifications. It maps pairs of integers ''(u, t)'' (both in range ''0..p-1'') to valid X coordinates on the curve. Note that the specification here does not attempt to be constant time, as it does not operate on secret data. In what follows, we use the notation from [https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki#specification BIP340].\n\n* ''XSwiftEC(u, t)'':\n** Alter the inputs to guarantee an X coordinate on the curve:'''Why do the inputs to the XSwiftEC algorithm need to be altered?''' This step deviates from the paper, which maps a negligibly small subset of inputs (around ''3/2256'') to the point at infinity. To avoid the need to deal with the case where a peer could craft encodings that intentionally trigger this edge case, we remap them to inputs that yield a valid X coordinate.\n*** If ''u mod p = 0'', let ''u = 1'' instead.\n*** If ''t mod p = 0'', let ''t = 1'' instead.\n*** If ''(u3 + t2 + 7) mod p = 0'', let ''t = 2t (mod p)'' instead.\n** Let ''X = (u3 + 7 - t2)/(2t) (mod p).'''''What does the division (/) sign in modular arithmetic refer to?''' Note that the division in these expressions corresponds to multiplication with the modular inverse modulo ''p'', i.e. ''a / b (mod p)'' with nonzero ''b'' is the unique solution ''x'' for which ''bx = a (mod p)''. It can be computed as ''abp-2 (mod p)'', but more efficient algorithms exist.\n** Let ''Y = (X + t)/(cu) (mod p)''.\n** For every ''x'' in ''{u + 4Y2, (-X/Y - u)/2, (X/Y - u)/2}'' (all ''mod p''; the order matters):\n*** If ''lift_x(x)'' succeeds, return ''x''. There is at least one such ''x''.\n\nTo find encodings of a given X coordinate ''x'', we first need the inverse of ''XSwiftEC''. The function ''XSwiftECInv(x, u, case)'' either returns ''t'' such that ''XSwiftEC(u, t) = x'', or ''None''. The ''case'' variable is an integer in range ''0..7'', which selects which of the up to 8 valid such ''t'' values to return:\n\n* ''XSwiftECInv(x, u, case)'':\n** If ''case & 2 = 0'':\n*** If ''lift_x(-x - u)'' succeeds, return ''None''.\n*** Let ''v = x''.\n*** Let ''s = -(u3 + 7)/(u2 + uv + v2) (mod p)''.\n** Else (''case & 2 = 2''):\n*** Let ''s = x - u (mod p)''.\n*** If ''s = 0'', return ''None''.\n*** Let ''r'' be the square root of ''-s(4(u3 + 7) + 3u2s) (mod p).'''''How to compute a square root mod ''p''?''' Due to the structure of ''p'', a candidate for the square root of ''a'' mod ''p'' can be computed as ''x = a(p+1)/4 mod p''. If ''a'' is not a square mod ''p'', this formula returns the square root of ''-a mod p'' instead, so it is necessary to verify that ''x2 mod p = a''. If that is the case ''-x mod p'' is a solution too, but we define \"the\" square root to be equal to that expression (the square root will therefore always be a square itself, as ''(p+1)/4'' is even). This algorithm is a specialization of the [https://en.wikipedia.org/wiki/Tonelli%E2%80%93Shanks_algorithm Tonelli-Shanks algorithm]. Return ''None'' if it does not exist.\n*** If ''case & 1 = 1'' and ''r = 0'', return ''None''.\n*** Let ''v = (r/s - u)/2''.\n** Let ''w'' be the square root of ''s (mod p)''. Return ''None'' if it does not exist.\n** If ''case & 5 = 0'', return ''-w(u(1 - c)/2 + v)''.\n** If ''case & 5 = 1'', return ''w(u(1 + c)/2 + v)''.\n** If ''case & 5 = 4'', return ''w(u(1 - c)/2 + v)''.\n** If ''case & 5 = 5'', return ''-w(u(1 + c)/2 + v)''.\n\nThe overall ''XElligatorSwift'' algorithm, matching the name used in the paper, then uses this inverse to randomly'''''Can the ElligatorSwift encoding be used to construct public key encodings that satisfy a certain structure (and not pseudorandom)?''' The algorithm chooses the first 32 bytes (i.e., the value ''u'') and then computes a corresponding ''t'' such that the mapping to the curve point holds. In general, picking ''u'' from a uniformly random distribution provides pseudorandomness. But we can also fix any of the 32 bytes in ''u'', and the algorithm will still find a corresponding ''t''. The fact that it is possible to fix the first 32 bytes, combined with the garbage bytes in the handshake, provides a limited but very simple method of parroting other protocols such as [https://tls13.xargs.org/ TLS 1.3], which can be deployed by one of the peers without explicit support from the other peer. More general methods of parroting, e.g., introduced by defining new protocol or a protocol upgrade, are not precluded. sample encodings of ''x'':\n\n* ''XElligatorSwift(x)'':\n** Loop:\n*** Let ''u'' be a random non-zero integer in range ''1..p-1'' inclusive.\n*** Let ''case'' be a random integer in range ''0..7'' inclusive.\n*** Compute ''t = XSwiftECInv(x, u, case)''.\n*** If ''t'' is not ''None'', return ''(u, t)''. Otherwise, restart loop.\n\nThis is used to define the ellswift_create algorithm used in the previous section; it generates a random private key, along with a uniformly sampled 64-byte ElligatorSwift-encoded public key corresponding to it:\n\n* ''ellswift_create()'':\n** Generate a random private key ''priv'' in range ''1..p-1''.\n** Let ''P = priv⋅G'', the corresponding public key point to ''priv''.\n** Let ''(u, t) = XElligatorSwift(x(P))'', an encoding of ''x(P)''.\n** ''ellswift_pub = bytes(u) || bytes(t)'', its encoding as 64 bytes.\n** Return ''(priv, ellswift_pub)''.\n\nFinally the ellswift_ecdh_xonly algorithm is:\n\n* ''ellswift_ecdh_xonly(ellswift_theirs, priv)'':\n** Let ''u = int(ellswift_theirs[:32]) mod p''.\n** Let ''t = int(ellswift_theirs[32:]) mod p''.\n** Return ''bytes(x(priv⋅lift_x(XSwiftEC(u, t))))''.'''Does it matter which point ''lift_x'' maps to?''' Either point is valid, as they are negations of each other, and negations do not affect the output X coordinate.\n\n===== Keys and session ID derivation =====\n\nThe authenticated encryption construction proposed here requires two 32-byte keys per communication direction. These (in addition to a session ID) are computed using HKDF'''Why use HKDF for deriving key material?''' The shared secret already involves a hash function to make sure the public key encodings contribute to it, which negates some of the need for HKDF already. We still use it as it is the standard mechanism for deriving many keys from a single secret, and its computational cost is low enough to be negligible compared to the rest of a connection setup. as specified in [https://tools.ietf.org/html/rfc5869 RFC 5869] with SHA256 as the hash function:\n\n
\ndef initialize_v2_transport(peer, ecdh_secret, initiating):\n    # Include NETWORK_MAGIC to ensure a connection between nodes on different networks will immediately fail\n    prk = HKDF_Extract(Hash=sha256, salt=b'bitcoin_v2_shared_secret' + NETWORK_MAGIC, ikm=ecdh_secret)\n\n    peer.session_id = HKDF_Expand(Hash=sha256, PRK=prk, info=b'session_id', L=32)\n\n    # Initialize the packet encryption ciphers.\n    initiator_L = HKDF_Expand(Hash=sha256, PRK=prk, info=b'initiator_L', L=32)\n    initiator_P = HKDF_Expand(Hash=sha256, PRK=prk, info=b'initiator_P', L=32)\n    responder_L = HKDF_Expand(Hash=sha256, PRK=prk, info=b'responder_L', L=32)\n    responder_P = HKDF_Expand(Hash=sha256, PRK=prk, info=b'responder_P', L=32)\n    garbage_terminators = HKDF_Expand(Hash=sha256, PRK=prk, info=b'garbage_terminators', L=32)\n    initiator_garbage_terminator = garbage_terminators[:16]\n    responder_garbage_terminator = garbage_terminators[16:]\n\n    if initiating:\n        peer.send_L = FSChaCha20(initiator_L)\n        peer.send_P = FSChaCha20Poly1305(initiator_P)\n        peer.send_garbage_terminator = initiator_garbage_terminator\n        peer.recv_L = FSChaCha20(responder_L)\n        peer.recv_P = FSChaCha20Poly1305(responder_P)\n        peer.recv_garbage_terminator = responder_garbage_terminator\n    else:\n        peer.send_L = FSChaCha20(responder_L)\n        peer.send_P = FSChaCha20Poly1305(responder_P)\n        peer.send_garbage_terminator = responder_garbage_terminator\n        peer.recv_L = FSChaCha20(initiator_L)\n        peer.recv_P = FSChaCha20Poly1305(initiator_P)\n        peer.recv_garbage_terminator = initiator_garbage_terminator\n\n    # To achieve forward secrecy we must wipe the key material used to initialize the ciphers:\n    memory_cleanse(ecdh_secret, prk, initiator_L, initiator_P, responder_L, responder_K)\n
\n\nThe session ID uniquely identifies the encrypted channel. v2 clients supporting this proposal may present the entire session ID (encoded as a hex string) to the node operator to allow for manual, out of band comparison with the peer node operator. Future transport versions may introduce optional authentication methods that compare the session ID as seen by the two endpoints in order to bind the encrypted channel to the authentication.\n\n===== Overall handshake pseudocode =====\n\nTo establish a v2 encrypted connection, the initiator generates an ephemeral secp256k1 keypair and sends an unencrypted ElligatorSwift encoding of the public key to the responding peer followed by unencrypted pseudorandom bytes initiator_garbage of length garbage_len < 4096.\n\n
\ndef initiate_v2_handshake(peer, garbage_len):\n    peer.privkey_ours, peer.ellswift_ours = ellswift_create()\n    peer.sent_garbage = rand_bytes(garbage_len)\n    send(peer, peer.ellswift_ours + peer.sent_garbage)\n
\n\nThe responder generates an ephemeral keypair for itself and derives the shared ECDH secret (using the first 64 received bytes) which enables it to instantiate the encrypted transport. It then sends 64 bytes of the unencrypted ElligatorSwift encoding of its own public key and its own responder_garbage also of length garbage_len < 4096. If the first 16 bytes received match the v1 prefix, the v1 protocol is used instead.\n\n
\nTRANSPORT_VERSION = b''\nNETWORK_MAGIC = b'\\xf9\\xbe\\xb4\\xd9' # Mainnet network magic; differs on other networks.\nV1_PREFIX = NETWORK_MAGIC + b'version\\x00\\x00\\x00\\x00\\x00'\n\ndef respond_v2_handshake(peer, garbage_len):\n    peer.received_prefix = b\"\"\n    while len(peer.received_prefix) < len(V1_PREFIX):\n        peer.received_prefix += receive(peer, 1)\n        if peer.received_prefix[-1] != V1_PREFIX[len(peer.received_prefix) - 1]:\n            peer.privkey_ours, peer.ellswift_ours = ellswift_create()\n            peer.sent_garbage = rand_bytes(garbage_len)\n            send(peer, ellswift_Y + peer.sent_garbage)\n            return\n    use_v1_protocol()\n
\n\nUpon receiving the encoded responder public key, the initiator derives the shared ECDH secret and instantiates the encrypted transport. It then sends the derived 16-byte initiator_garbage_terminator, optionally followed by an arbitrary number of decoy packets. Afterwards, it receives the responder's garbage (delimited by the garbage terminator). The responder performs very similar steps but includes the earlier received prefix bytes in the public key. Both the initiator and the responder set the AAD of the first encrypted packet they send after the garbage terminator (i.e., either an optional decoy packet or the version packet) to the garbage they have just sent, not including the garbage terminator.\n\n
\ndef complete_handshake(peer, initiating, decoy_content_lengths=[]):\n    received_prefix = b'' if initiating else peer.received_prefix\n    ellswift_theirs = receive(peer, 64 - len(received_prefix))\n    if not initiating and ellswift_theirs[4:16] == V1_PREFIX[4:16]:\n        # Looks like a v1 peer from the wrong network.\n        disconnect(peer)\n    ecdh_secret = v2_ecdh(peer.privkey_ours, ellswift_theirs, peer.ellswift_ours,\n                          initiating=initiating)\n    initialize_v2_transport(peer, ecdh_secret, initiating=True)\n    # Send garbage terminator\n    send(peer, peer.send_garbage_terminator)\n    # Optionally send decoy packets after garbage terminator.\n    aad = peer.sent_garbage\n    for decoy_content_len in decoy_content_lengths:\n        send(v2_enc_packet(peer, decoy_content_len * b'\\x00', aad=aad))\n        aad = b''\n    # Send version packet.\n    send(v2_enc_packet(peer, TRANSPORT_VERSION, aad=aad))\n    # Skip garbage, until encountering garbage terminator.\n    received_garbage = recv(peer, 16)\n    for i in range(4096):\n        if received_garbage[-16:] == peer.recv_garbage_terminator:\n            # Receive, decode, and ignore version packet.\n            # This includes skipping decoys and authenticating the received garbage.\n            v2_receive_packet(peer, aad=received_garbage[:-16])\n            return\n        else:\n            received_garbage += recv(peer, 1)\n    # Garbage terminator was not seen after 4 KiB of garbage.\n    disconnect(peer)\n
\n\n==== Packet encryption ====\n\nLastly, we specify the packet encryption cipher in detail.\n\n===== Existing cryptographic primitives =====\n\nPacket encryption is built on two existing primitives:\n\n* '''ChaCha20Poly1305''' is specified as AEAD_CHACHA20_POLY1305 in [https://datatracker.ietf.org/doc/html/rfc8439#section-2.8 RFC 8439 section 2.8]. It is an authenticated encryption protocol with associated data (AEAD), taking a 256-bit key, 96-bit nonce, and an arbitrary-length byte array of associated authenticated data (AAD). Due to the built-in authentication tag, ciphertexts are 16 bytes longer than the corresponding plaintext. In what follows:\n** aead_chacha20_poly1305_encrypt(key, nonce, aad, plaintext) refers to a function that takes as input a 32-byte array ''key'', a 12-byte array ''nonce'', an arbitrary-length byte array ''aad'', and an arbitrary-length byte array ''plaintext'', and returns a byte array ''ciphertext'', 16 bytes longer than the plaintext.\n** aead_chacha20_poly1305_decrypt(key, nonce, aad, ciphertext) refers to a function that takes as input a 32-byte array ''key'', a 12-byte array ''nonce'', an arbitrary-length byte array ''aad'', and an arbitrary-length byte array ''ciphertext'', and returns either a byte array ''plaintext'' (16 bytes shorter than the ciphertext), or ''None'' in case the ciphertext was not a valid ChaCha20Poly1305 encryption of any plaintext with the specified ''key'', ''nonce'', and ''aad''.\n* The '''ChaCha20 Block Function''' is specified in [https://datatracker.ietf.org/doc/html/rfc8439#section-2.3 RFC 8439 section 2.3]. It is a pseudorandom function (PRF) taking a 256-bit key, 96-bit nonce, and 32-bit counter, and outputs 64 pseudorandom bytes. It is the underlying building block on which ChaCha20 (and ultimately, ChaCha20Poly1305) is built. In what follows:\n** chacha20_block(key, nonce, count) refers to a function that takes as input a 32-byte array ''key'', a 12-byte array ''nonce'', and an integer ''count'' in range ''0..232-1'', and returns a byte array of length 64.\n\nThese will be used for plaintext encryption and length encryption, respectively.\n\n===== Rekeying wrappers: FSChaCha20Poly1305 and FSChaCha20 =====\n\nTo provide re-keying every 224 packets, we specify two wrappers.\n\nThe first is '''FSChaCha20Poly1305''', which represents a ChaCha20Poly1305 AEAD, which automatically changes the nonce after every message, and rekeys every 224 messages by encrypting 32 zero bytes'''Why is rekeying implemented in terms of an invocation of the AEAD?''' This means the FSChaCha20Poly1305 wrapper can be thought of as a pure layer around the ChaCha20Poly1305 AEAD. Actual implementations can take advantage of the fact that this formulation is equivalent to using byte 64 through 95 of the keystream output of the underlying ChaCha20 cipher as new key, avoiding the need for Poly1305 in the process., and using the first 32 bytes of the result. Each message will be used for one packet. Note that in our protocol, any FSChaCha20Poly1305 instance is always either exclusively encryption or exclusively decryption, as separate instances are used for each direction of the protocol. The nonce used for a message is composed of the 32-bit little-endian encoding of the number of messages with the current key, followed by the 64-bit little-endian encoding of the number of rekeyings performed. For rekeying, the first 32-bit integer is set to ''0xffffffff''.\n\n
\nREKEY_INTERVAL = 224\n\nclass FSChaCha20Poly1305:\n    \"\"\"Rekeying wrapper AEAD around ChaCha20Poly1305.\"\"\"\n\n    def __init__(self, initial_key):\n        self.key = initial_key\n        self.packet_counter = 0\n\n    def crypt(self, aad, text, is_decrypt):\n        nonce = ((self.packet_counter % REKEY_INTERVAL).to_bytes(4, 'little') +\n                 (self.packet_counter // REKEY_INTERVAL).to_bytes(8, 'little'))\n        if is_decrypt:\n            ret = aead_chacha20_poly1305_decrypt(self.key, nonce, aad, text)\n        else:\n            ret = aead_chacha20_poly1305_encrypt(self.key, nonce, aad, text)\n        if (self.packet_counter + 1) % REKEY_INTERVAL == 0:\n            rekey_nonce = b\"\\xFF\\xFF\\xFF\\xFF\" + nonce[4:]\n            self.key = aead_chacha20_poly1305_encrypt(self.key, rekey_nonce, b\"\", b\"\\x00\" * 32)[:32]\n        self.packet_counter += 1\n        return ret\n\n    def decrypt(self, aad, ciphertext):\n        return self.crypt(aad, ciphertext, True)\n\n    def encrypt(self, aad, plaintext):\n        return self.crypt(aad, plaintext, False)\n
\n\nThe second is '''FSChaCha20''', a (single) stream cipher which is used for the lengths of all packets. Encryption and decryption are identical here, so a single function crypt is exposed. It XORs the input with bytes generated using the ChaCha20 block function, rekeying every 224 chunks using the next 32 bytes of the block function output as new key. A ''chunk'' refers here to a single invocation of crypt. As explained before, the same cipher is used for 224 consecutive chunks, to avoid wasting cipher output. The nonce used for these batches of 224 chunks is composed of 4 zero bytes followed by the 64-bit little-endian encoding of the number of rekeyings performed. The block counter is reset to 0 after every rekeying.\n\n
\nclass FSChaCha20:\n    \"\"\"Rekeying wrapper stream cipher around ChaCha20.\"\"\"\n\n    def __init__(self, initial_key):\n        self.key = initial_key\n        self.block_counter = 0\n        self.chunk_counter = 0\n        self.keystream = b''\n\n    def get_keystream_bytes(self, nbytes):\n        while len(self.keystream) < nbytes:\n            nonce = ((0).to_bytes(4, 'little') +\n                     (self.chunk_counter // REKEY_INTERVAL).to_bytes(8, 'little'))\n            self.keystream += chacha20_block(self.key, nonce, self.block_counter)\n            self.block_counter += 1\n        ret = self.keystream[:nbytes]\n        self.keystream = self.keystream[nbytes:]\n        return ret\n\n    def crypt(self, chunk):\n        ks = self.get_keystream_bytes(len(chunk))\n        ret = bytes([ks[i] ^ chunk[i] for i in range(len(chunk))])\n        if ((self.chunk_counter + 1) % REKEY_INTERVAL) == 0:\n            self.key = self.get_keystream_bytes(32)\n            self.block_counter = 0\n        self.chunk_counter += 1\n        return ret\n
\n\n===== Overall packet encryption and decryption pseudocode =====\n\nEncryption and decryption of packets then follow by composing the ciphers from the previous section as building blocks.\n\n
\nLENGTH_FIELD_LEN = 3\nHEADER_LEN = 1\nIGNORE_BIT_POS = 7\n\ndef v2_enc_packet(peer, contents, aad=b'', ignore=False):\n    assert len(contents) <= 2**24 - 1\n    header = (ignore << IGNORE_BIT_POS).to_bytes(HEADER_LEN, 'little')\n    plaintext = header + contents\n    aead_ciphertext = peer.send_P.encrypt(aad, plaintext)\n    enc_contents_len = peer.send_L.encrypt(len(contents).to_bytes(LENGTH_FIELD_LEN, 'little'))\n    return enc_contents_len + aead_ciphertext\n
\n\n
\nCHACHA20POLY1305_EXPANSION = 16\n\ndef v2_receive_packet(peer, aad=b''):\n    while True:\n        enc_contents_len = receive(peer, LENGTH_FIELD_LEN)\n        contents_len = int.from_bytes(peer.recv_L.crypt(enc_contents_len), 'little')\n        aead_ciphertext = receive(peer, HEADER_LEN + contents_len + CHACHA20POLY1305_EXPANSION)\n        plaintext = peer.recv_P.decrypt(aad, aead_ciphertext)\n        if plaintext is None:\n            disconnect(peer)\n            break\n        # Only the first packet is expected to have non-empty AAD.\n        aad = b''\n        header = plaintext[:HEADER_LEN]\n        if not (header[0] & (1 << IGNORE_BIT_POS)):\n            return plaintext[HEADER_LEN:]\n
\n\n==== Performance ====\n\nEach v1 P2P message uses a double-SHA256 checksum truncated to 4 bytes. Roughly the same amount of computation power is required for encrypting and authenticating a v2 P2P message as proposed.\n\n=== Application layer specification ===\n==== v2 Bitcoin P2P message structure ====\nv2 Bitcoin P2P transport layer packets use the encrypted message structure shown above. An unencrypted application layer '''contents''' is composed of:\n\n{|class=\"wikitable\"\n! Field !! Size in bytes !! Comments\n|-\n| message_type || 1 or 13 || either a one byte ID in range ''1..255'' or b'\\x00' followed by a 12-byte ASCII message type (as in the v1 P2P protocol)\n|-\n| message_payload || message_length || message payload\n|}\n\nIf the first byte of message_type is b'\\x00', the following 12 bytes are interpreted as an ASCII message type (as in the v1 P2P protocol), trailing padded with b'\\x00' as necessary. If the first byte of message_type is in the range ''1..255'', it is interpreted as a message type ID. This structure results in smaller messages than the v1 protocol, as most messages sent/received will have a message type ID. We recommend reserving 1-byte type IDs for message types that are sent more than once per direction per connection.'''How do the lengths between v1 and v2 compare?''' For messages that use the 1-byte short message type ID, v2 packets use 3 bytes less per message than v1.'''Why not allow variable length long message type IDs?''' Allowing for variable length long IDs reduces the available 1-byte ID space by 12 (to encode the length itself) and incentivizes less descriptive message types. In addition, limiting message types to fixed lengths of 1 or 13 hampers traffic analysis.\n\nThe value of message_length is '''length''' minus the size of the message_type.\n\nThe following table lists currently defined message type IDs and the 12-byte ASCII message type (trimmed of trailing padding) that they are treated as equivalent to:\n\n{| class=\"wikitable\"\n|-\n!\n!0\n!1\n!2\n!3\n|-\n!+0\n|(12 bytes follow)||addr||block||blocktxn\n|-\n!+4\n|cmpctblock||feefilter||filteradd||filterclear\n|-\n!+8\n|filterload||getblocks||getblocktxn||getdata\n|-\n!+12\n|getheaders||headers||inv||mempool\n|-\n!+16\n|merkleblock||notfound||ping||pong\n|-\n!+20\n|sendcmpct||tx||getcfilters||cfilter\n|-\n!+24\n|getcfheaders||cfheaders||getcfcheckpt||cfcheckpt\n|-\n!+28\n|addrv2\n|-\n!≥29\n|| colspan=\"4\" | (undefined)\n|}\n\nWhen a message type has both a 1-byte encoding and a 13-byte encoding defined, peers that support receiving that message type should accept messages using either encoding (e.g., if the \"getblocktxn\" message type is supported, then both the 1-byte b'\\x0a' encoding and the 13-byte b'\\x00getblocktxn\\x00' should be supported, and behavior should not depend on which of the two encodings is received).\n\nAdditional message type IDs may be defined by other BIPs. They should be added to the [[bip-0324/message_type_ids.md|message type IDs table]] to ease coordination.\n\n=== Signaling specification ===\n==== Signaling v2 support ====\nPeers supporting the v2 transport protocol signal support by advertising the NODE_P2P_V2 = (1 << 11) service flag in addr relay. If met with immediate disconnection when establishing a v2 connection, clients implementing this proposal are encouraged to retry connecting using the v1 protocol.'''Why are v2 clients met with immediate disconnection encouraged to retry with a v1 connection?''' Service flags propagated through untrusted intermediaries using ADDR and ADDRV2 P2P messages and are OR'ed when received from multiple sources. An untrusted intermediary could falsely advertise a potential peer as supportive of v2 connections. Connection downgrades to v1 mitigate the risk of a network participant being blackholed via false advertising.\n\n\n== Test Vectors ==\n\nFor development and testing purposes, we provide a collection of test vectors in CSV format, and a naive, highly inefficient, [[bip-0324/reference.py|reference implementation]] of the relevant algorithms. This code is for demonstration purposes only:\n* [[bip-0324/ellswift_decode_test_vectors.csv|XElligatorSwift decoding vectors]] provide examples of ElligatorSwift-encoded public keys, and the X coordinate they map to.\n* [[bip-0324/xswiftec_inv_test_vectors.csv|XSwiftECInv vectors]] provide examples of ''(u, x)'' pairs, and the various ''t'' values that ''xswiftec_inv'' maps them to.\n* [[bip-0324/packet_encoding_test_vectors.csv|Packet encoding vectors]] illustrate the lifecycle of the authenticated encryption scheme proposed in this document.\n\n== Changelog ==\n\n * 1.0.2 (2026-01-30)\n * Add message type ID table in auxiliary file\n * 1.0.1 (2026-01-16)\n * Specify equivalence of 1-byte and 13-byte `message_type`\n * 1.0.0 (2024-07-10)\n * Marked as Final\n\n== Rationale and References ==\n\n\n== Acknowledgements ==\nThanks to everyone (last name order) that helped invent and develop the ideas in this proposal:\n\n* Matt Corallo\n* Lloyd Fournier\n* Gregory Maxwell\n* Anthony Towns", "category": "bips" }, { "instruction": "What commands would you run to work with 
?",
    "input": "",
    "output": "BIP: 71\n  Layer: Applications\n  Title: Payment Protocol MIME types\n  Authors: Gavin Andresen \n  Status: Deployed\n  Type: Specification\n  Assigned: 2013-07-29\n
\n\n==Abstract==\n\nThis BIP defines a MIME (RFC 2046) Media Type for Bitcoin payment\nrequest messages.\n\n==Motivation==\n\nWallet or server software that sends payment protocol messages over\nemail or http should follow Internet standards for properly\nencapsulating the messages.\n\n==Specification==\n\nThe Media Type (Content-Type in HTML/email headers) for bitcoin\nprotocol messages shall be:\n\n{|\n| Message || Type/Subtype\n|-\n| PaymentRequest || application/bitcoin-paymentrequest\n|-\n| Payment || application/bitcoin-payment\n|-\n| PaymentACK || application/bitcoin-paymentack\n|}\n\nPayment protocol messages are encoded in binary.\n\n==Example==\n\nA web server generating a PaymentRequest message to initiate the\npayment protocol would precede the binary message data with the\nfollowing headers:\n
\nContent-Type: application/bitcoin-paymentrequest\nContent-Transfer-Encoding: binary\n
", "category": "bips" }, { "instruction": "I want to understand 
 from a technical perspective",
    "input": "",
    "output": "BIP: 331\n  Layer: Peer Services\n  Title: Ancestor Package Relay\n  Authors: Gloria Zhao \n  Status: Draft\n  Type: Specification\n  Assigned: 2022-08-08\n  License: BSD-3-Clause\n  Discussion: 2022-05-17 https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020493.html [bitcoin-dev] post\n
\n\n==Abstract==\n\nPeer-to-peer protocol messages enabling nodes to request and relay the unconfirmed ancestor package\nof a given transaction, and to request and relay transactions in batches.\n\n==Motivation==\n\n===Propagate High Feerate Transactions===\n\nSince v0.13, Bitcoin Core has used ancestor packages instead of individual transactions to evaluate\nthe incentive compatibility of transactions in the mempool\n[https://github.com/bitcoin/bitcoin/pull/7594 Add tracking of ancestor packages] and\nselecting them for inclusion in blocks\n[https://github.com/bitcoin/bitcoin/pull/7600 Select transactions using feerate-with-ancestors].\nIncentive-compatible mempool and miner policies help create a fair, fee-based market for block\nspace. While miners maximize transaction fees in order to earn higher block rewards, non-mining\nusers participating in transaction relay reap many benefits from employing policies that result in a\nmempool with similar contents, including faster compact block relay and more accurate fee\nestimation. Additionally, users may take advantage of mempool and miner policy to bump the priority\nof their transactions by attaching high-fee descendants (Child Pays for Parent or CPFP).\n\nOnly individually considering transactions for submission to the mempool creates a limitation in\nthe node's ability to determine which transactions to include in the mempool, since it cannot take\ninto account descendants until all the transactions are in the mempool. Similarly, it cannot use a\ntransaction's descendants when considering which of two conflicting transactions to keep (Replace by\nFee or RBF).\n\nWhen a user's transaction does not meet a mempool's minimum feerate and they cannot create a\nreplacement transaction directly, their transaction will simply be rejected by this mempool or\nevicted if already included. They also cannot attach a descendant to pay for replacing a conflicting\ntransaction; it would be rejected for spending inputs that do not exist.\n\nThis limitation harms users' ability to fee-bump their transactions. Further, it presents security and complexity\nissues in contracting protocols which rely on presigned, time-sensitive transactions'''Examples of time-sensitive pre-signed transactions in L2 protocols.'''\n* [https://github.com/lightning/bolts/blob/master/03-transactions.md#htlc-timeout-and-htlc-success-transactions HTCL-Timeout in LN Penalty]\n* [https://github.com/revault/practical-revault/blob/master/transactions.md#cancel_tx Unvault Cancel in Revault]\n* [https://github.com/discreetlogcontracts/dlcspecs/blob/master/Transactions.md#refund-transaction Refund Transaction in Discreet Log Contracts]\n* [https://gist.github.com/instagibbs/60264606e181451e977e439a49f69fe1 Updates in Eltoo]\n* [https://github.com/ElementsProject/peerswap/blob/master/docs/peer-protocol.md#claim-transaction Claim Transactions in PeerSwap]\n to prevent cheating.\nIn other words, a key security assumption of many contracting protocols is that all parties can\npropagate and confirm transactions in a timely manner. Increasing attention has been brought to\n\"pinning attacks,\" a type of censorship in which the attacker uses mempool policy restrictions to\nprevent a transaction from being relayed or getting mined.\n'''Concerns for pinning attacks in L2 protocols'''\n* [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020458.html Greg Sanders, \"Bringing a nuke to a knife fight: Transaction introspection to stop RBF pinning\"]\n* [https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-April/002639.html Matt Corallo, \"RBF Pinning with Counterparties and Competing Interest\"]\n* [https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-June/002758.html Antoine Riard, \"Pinning : The Good, The Bad, The Ugly\"]\n* [https://github.com/t-bast/lightning-docs/blob/master/pinning-attacks.md Bastien Teinturier, \"Pinning Attacks\"]\n* [https://gist.github.com/instagibbs/60264606e181451e977e439a49f69fe1 Greg Sanders, \"Eltoo Pinning\"]\n\n\nThese transactions must meet a certain confirmation target to be effective, but their feerates\nare negotiated well ahead of broadcast time. If the forecast feerate was too low and no\nfee-bumping options are available, attackers can steal money from their counterparties. Always\noverestimating fees may sidestep this issue (but only while mempool traffic is low and\npredictable), but this solution is not guaranteed to work and wastes users' money. For some attacks,\nthe available defenses require nodes to have a bird's-eye view of Bitcoin nodes' mempools, which is\nan unreasonable security requirement.\n\nPart of the solution is to enable nodes to consider packages of transactions as a unit, e.g. one or\nmore low-fee ancestor transactions with a high-fee descendant, instead of separately. A package-aware\nmempool policy can help determine if it would actually be economically rational to accept a\ntransaction to the mempool if it doesn't meet fee requirements individually. Network-wide adoption\nof these policies would create a more purely-feerate-based market for block space and allow\ncontracting protocols to adjust fees (and therefore mining priority) at broadcast time.\n\nTheoretically, developing a safe and incentive-compatible package mempool acceptance policy is\nsufficient to solve this issue. Nodes could opportunistically accept packages (e.g. by trying\ncombinations of transactions rejected from their mempools), but this practice would likely be\ninefficient at best and open new Denial of Service attacks at worst. As such, this proposal\nsuggests adding new p2p messages enabling nodes to request and share package-validation-related\ninformation with one another, resulting in a more efficient and reliable way to propagate packages.\n\n===Handle Orphans Better===\n\nTxid-based transaction relay is problematic since a transaction's witness may be malleated without\nchanging its txid; a node cannot use txid to deduplicate transactions it has already downloaded\nor validated. Ideally, two nodes that both support BIP339 wtxid-based transaction relay shouldn't\never need to use txid-based transaction relay.\n\nA single use case of txid-based relay remains: handling \"orphan\" transactions that spend output(s)\nfrom an unconfirmed transaction the receiving node is unaware of. Orphan transactions are very\ncommon for new nodes that have just completed Initial Block Download and do not have an up-to-date\nmempool. Nodes also download transactions from multiple peers. If the peer from which a child\ntransaction was requested responds faster than the peer from which its parent was requested, that\nchild is seen as an orphan transaction.\n\nNodes may handle orphans by storing them in a cache and requesting any missing parent(s) by txid\n(prevouts specify txid, not wtxid). These parents may end up being orphans as well, if they also\nspend unconfirmed inputs that the node is unaware of. This method of handling orphans is problematic\nfor two reasons: it requires nodes to allocate memory for unvalidated data received on the p2p\nnetwork and it relies on txid-based relay between two wtxid-relay peers.\n\nThis proposal makes orphan resolution more efficient and no longer require txid-based relay.\n\n==Definitions==\n\nGiven any two transactions Tx0 and Tx1 where Tx1 spends an output of Tx0, Tx0 is a '''parent''' of\nTx1 and Tx1 is a '''child''' of Tx0.\n\nA transaction's '''ancestors''' include, recursively, its parents, the parents of its parents, etc.\nA transaction's '''descendants''' include, recursively, its children, the children of its children,\netc. A transaction's parent is its ancestor, but an ancestor is not necessarily a parent.\n\nA '''package''' is a list of transactions, representable by a connected Directed Acyclic\nGraph (a directed edge exists between a transaction that spends the output of another transaction).\nIn this proposal, a package is limited to unconfirmed transactions.\n\nAn '''ancestor package''' consists of an unconfirmed transaction with all of its unconfirmed\nancestors.\n\nIn a '''topologically sorted''' package, each parent appears somewhere in the list before its child.\n\n==Specification==\n\nAncestor Package Relay includes two parts: a package information round and a transaction data\ndownload round.\nThe package information round is used to help a receiver learn what transactions are in a package and\ndecide whether they want to download them. The transaction data round is used to help a node download\nmultiple transactions in one message instead of as separate messages.\n'''Why are package information and transaction data rounds both necessary?'''\n\nSeveral alternative designs were considered. One should measure alternative solutions based on the\nresources used to communicate (not necessarily trustworthy) information: We would like to minimize\nnetwork bandwidth, avoid downloading a transaction more than once, avoid downloading transactions\nthat are eventually rejected, and minimize storage allocated for not-yet-validated transactions.\n\n
\n\n'''No Package Information Round:''' One proposal is to just use the child's wtxid to refer to the\npackage and always send the entire package together, skipping the package information round.\nHowever, this protocol would make it very likely for honest nodes to redownload duplicate\ntransactions. See the following example, where the high-feerate ancestors were already downloaded\nand accepted individually.\n\n[[File:./bip-0331/no_package_info.png|600px]]\n
\n\n'''Package Information Only:''' Just having package information gives enough information for the\nreceiver to accept the packages. That is, rather than using \"getpkgtxns\" and \"pkgtxns\" messages,\nsend \"getdata\" and download the transactions individually. While this option is a potential fallback\nif batched transaction download fails for some reason, it shouldn't be used as the default because\nit always requires storage of unvalidated transactions.\n[[File:./bip-0331/package_info_only.png|1000px]]\n\n\nPackage relay is negotiated between two peers during the version handshake using a \"sendpackages\"\nmessage. The versions field within \"sendpackages\" is interpreted as a bitfield; peers may relay\nmultiple versions of packages. Package relay requires both peers to support wtxid-based relay\nbecause package transactions are referenced by their wtxids.\n'''Why do we need multiple versions? Why can't we just support arbitrary packages?'''\nAttempting to support arbitrary packages in mempool validation may result in very complex logic, new\nDenial of Service attack vectors, and policy limitations that could be leveraged to censor\ntransactions (aka \"pinning attacks\"). This protocol is extensible to support other types of\npackages based on future desired use cases. Future package information messages may describe\ndifferent types of packages and/or contain more information than a list of wtxids, e.g. feerate or\nrelationships between transactions.\n'''Why use a bitfield instead of a numbering system?'''\nIt should be possible to support some subset of the existing package types.\n\n[[File:./bip-0331/version_negotiation.png|400px]]\n\nNodes indicate support for batched transaction data round (\"getpkgtxns\", \"pkgtxns\", and\n\"MSG_PKGTXNS\") using the PKG_RELAY_PKGTXNS = (1 << 0) bit in their \"sendpackages\"\nmessages during version handshake. They indicate support for the ancestor package information\nround (\"ancpkginfo\", \"MSG_ANCPKGINFO\") using the PKG_RELAY_ANC = (1 << 1) bit in their\n\"sendpackages\" messages during version handshake.\n\n===Protocol Flow Examples===\n\nThis package relay protocol satisfies both use cases (orphan transaction handling and high-feerate\ntransaction paying for low-feerate ancestors).\n\n====Orphan Transaction Handling====\n\nUpon receiving an orphan transaction, a node may request ancestor package information delineating\nthe wtxids of the transaction's unconfirmed ancestors. This is done without using txid-based relay.\nThe package information can be used to request transaction data. As these transactions are dependent\nupon one another to be valid, the transactions can be requested and sent as a batch.\n\nContrast this protocol with legacy orphan handling, which requires requesting the missing\ntransactions by their txids and may require new round trips for each generation of missing parents.\n[[File:./bip-0331/orphan_handling_flow.png|1000px]]\n\n====Fee-Bumped Transactions====\n\nToo-low-feerate transactions (i.e. below the node's minimum mempool feerate) with high-feerate\ndescendants can also be relayed this way. If the peers are using BIP133 fee filters and a\nlow-feerate transaction is below the node's fee filter, the sender will not announce it. The\nhigh-feerate transaction will be sent by the sender, and received and handled as an orphan by the\nreceiver, the transactions are validated as a package, and so the protocol naturally works for this\nuse case.\n\nThis does not mean BIP133 is required for package relay to work, provided that nodes do not\nimmediately reject transactions previously found to be too low feerate. If the low-feerate\ntransaction was sent and rejected, the receiver should later re-request and accept it after learning\nthat it is the ancestor of another transaction, and that they meet the receiver's mempool policy\nrequirements when validated together.\n\n[[File:./bip-0331/package_cpfp_flow.png|600px]]\n\nThis protocol is receiver-initiated only; nodes do not proactively announce packages to their peers.\n'''Why no sender-initiated protocol?''' Sender-initiated package\nrelay can, theoretically, save a round trip by notifying the receiver ahead of time that they will\nprobably need to request and validate a group of transactions together in order for them to be\naccepted. As with any proactive communication, there is a chance that the receiver already knows\nthis information, so this network bandwidth may be wasted. Shortened latency is less significant\nthan wasted bandwidth.\n\nThe logic used to decide when to announce a package proactively determines whether it is a net\nincrease or decrease for overall bandwidth usage. However, it is difficult to design anything to\nsave bandwidth without any idea of what its bandwidth usage actually looks like in practice. No\nhistorical data is available, as one of the primary goals of this protocol is to enable\ncurrently-rejected transactions to propagate. After deploying receiver-initiated package relay, we\ncan observe its usage and then introduce a sender-initiated package relay protocol informed by data\ncollected from the p2p network.\n\n===Combined Hash===\n\nA \"combined hash\" serves as a unique \"package id\" for some list of transactions and helps provide a\nmeaningful but short \"notfound\" response to \"getpkgtxns.\"\n\nThe combined hash of a package of transactions is equal to the sha256 hash of each transaction's\nwtxid concatenated in lexicographical order.\n\n===New Messages===\n\nFour new protocol messages and two inv types are added.\n\n====sendpackages====\n\n{|\n| Field Name || Type || Size || Purpose\n|-\n|versions || uint64_t || 8 || Bit field that is 64 bits wide, denoting the package versions supported by the sender.\n|-\n|}", "category": "bips" }, { "instruction": "Can you explain Upon successful connection (\"verack\" sent by both peers), a node may relay packages with the peer if they did not set \"fRelay\" to false in the \"version\" message, both peers sent \"wtxidrelay\", and both peers sent \"sendpackages\" for matching version bit(s). Unknown bits (including versions==0) should be ignored. Peers should relay packages corresponding to versions that both sent \"sendpackages\" for.'''Is it ok to send \"sendpackages\" to a peer that specified fRelay=false in their \"version\" message?''' like we're having a beer and talking Bitcoin?", "input": "", "output": "Yes, this is allowed in order to reduce the number of negotiation steps. This means nodes can\nannounce features without first checking what the other peer has sent, and then apply negotiation\nlogic at the end based on what was sent and received. See [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020510.html this discussion].\n\n\n====ancpkginfo====\n{|\n| Field Name || Type || Size || Purpose\n|-\n|txns_length||CompactSize||1 or 3 bytes|| The number of transactions provided.\n|-\n|txns||List of wtxids||txns_length * 32|| The wtxids of each transaction in the package.\n|}", "category": "bips" }, { "instruction": "How would you explain The \"txns\" field should contain a list of wtxids which constitute the ancestor package of the last wtxid. For the receiver's convenience, the sender should - but is not required to - sort the wtxids in topological order. The topological sort can be achieved by sorting the transactions by mempool acceptance order (if parents are always accepted before children). Apart from the last wtxid which is used to learn which transaction the message corresponds to, there is no enforced ordering. Nodes should not disconnect or punish a peer who provides a list not sorted in topological order.'''Why not include feerate information to help the receiver decide whether these transactions are worth downloading?''' to someone who knows Bitcoin basics?", "input": "", "output": "A simple feerate is typically insufficient; the receiver must also know the dependency\nrelationships between transactions and their respective sizes.\n'''Should a peer be punished if they provide incorrect package info, e.g. a list of unrelated transactions?'''\nIdeally, there should be a way to enforce that peers are providing correct information to each\nother. However, two peers may have different views of what a transaction's unconfirmed ancestors\nare based on their chainstate. For example, during a reorg or when two blocks are found at the same\ntime, one peer may see a transaction as confirmed while the other peer does not.\nAs such, it is impossible to accurately enforce this without also knowing the peer's chainstate.\nIt was [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020493.html originally proposed]\nto include a block hash in \"ancpkginfo\" to avoid unwarranted disconnections. However, it does not\nmake much sense to stop or delay transaction data requests due to mismatched chainstates, and the\nchainstate may change again between package information and transaction data rounds. Instead,\ndifferences in chainstate should be handled at the validation level. The node has already spent\nnetwork bandwidth downloading these transactions; it should make a best effort to validate them.\nSee [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020558.html discussion].\n'''Why not require topological order?'''\nIt is not possible to determine whether a list of transactions is topologically sorted without first\nestablishing that the list contains a full ancestor package. It is not possible to determine whether\na list of transactions contains a full ancestor package without knowing what the chainstate is.\n", "category": "bips" }, { "instruction": "I'm trying to understand This inv type must only be used if both peers set PKG_RELAY_ANC in their \"sendpackages\" message. If a \"getdata\" message with type MSG_ANCPKGINFO is received from a peer with which this type of package relay was not negotiated, no response should be sent and the sender may be disconnected. - can you walk me through it?", "input": "", "output": "====getpkgtxns====\n\n{|\n| Field Name || Type || Size || Purpose\n|-\n|txns_length||CompactSize||1 or 3 bytes|| The number of transactions requested.\n|-\n|txns||List of wtxids||txns_length * 32|| The wtxids of each transaction in the package.\n|}", "category": "bips" }, { "instruction": "Hey, I need to set up This message must only be used if both peers set PKG_RELAY_PKGTXNS in their \"sendpackages\" message. If a \"getpkgtxns\" message is received from a peer with which this type of package relay was not negotiated, no response should be sent and the sender may be disconnected. - what's the command line way to do that?", "input": "", "output": "====pkgtxns====\n\n{|\n| Field Name || Type || Size || Purpose\n|-\n|txns_length||CompactSize||1 or 3 bytes|| The number of transactions provided.\n|-\n|txns||List of transactions||variable|| The transactions in the package.\n|}", "category": "bips" }, { "instruction": "What's the deal with This inv type must only be used if both peers set PKG_RELAY_PKGTXNS in their \"sendpackages\" message. in Bitcoin? Explain it like I'm a friend.", "input": "", "output": "==Compatibility==\n\nOlder clients remain fully compatible and interoperable after this change. Clients implementing this\nprotocol will only attempt to send and request packages if agreed upon during the version handshake.\n'''Will package relay cause non-package relay nodes to waste bandwidth on low-feerate transactions?'''\nIf a node supports package relay, it may accept low-feerate transactions (e.g. paying zero fees)\ninto its mempool, but non-package relay nodes would most likely reject them. To mitigate bandwidth\nwaste, a package relay node should not announce descendants of below-fee-filter transactions to\nnon-package relay peers.\n\n'''Is Package Erlay possible?'''\nA client using BIP330 reconciliation-based transaction relay (Erlay) is able to use package relay\nwithout interference. After reconciliation, any transaction with unconfirmed ancestors may have\nthose ancestors resolved using ancestor package relay.\n[[File:./bip-0331/package_erlay.png|700px]]\n\n\n==Extensibility==\n\nThis protocol can be extended to include more types of package information in the future, while\ncontinuing to use the same messages for transaction data download. One would define a new package\ninformation message (named \"*pkginfo\" in the diagram below), allocate its corresponding inv\ntype (named \"*PKGINFO\" in the diagram below), and specify how to signal support using the\nversions field of \"sendpackages\" (an additional bit named \"PKG_RELAY_*\" in the diagram below). A\nfuture version of package relay may allow a sender-initiated dialogue by specifying that the package\ninfo type inv type can be used in an \"inv\" message.\n
\n[[File:./bip-0331/sender_init_future_version.png|700px]]\n\n==Implementation==\n\nSample implementation for Bitcoin Core: https://github.com/bitcoin/bitcoin/pull/27742\n\nA prerequisite for implementing a safe\npackage relay protocol is a mempool acceptance policy that safely validates packages of\ntransactions.\n'''Package Mempool Acceptance Policy'''\nAccepting packages from peers should not significantly increase a node's DoS attack surface;\nprocessing packages should not permit waste or exhaustion of the node and network's resources.\nAdditionally, a sensible mempool acceptance policy should result in the most incentive-compatible\nsubset of the package in the mempool in order to avoid adding more pinning attacks or censorship\nvectors. For example, It should not be assumed that packages are CPFPs. An ancestor package may\ninclude a high-feerate parent and low-feerate child; the policy may choose to accept the parent but\nnot the child. If one or more transactions are policy-invalid, other transactions that are not\ndependent upon them should still be considered.\n\n\n==Acknowledgements==\n\nThank you to Suhas Daftuar, John Newbery, Anthony Towns, Martin Zumsande, and others for input on the design.\n\nThank you to Will Clark, Sergi Delgado, Fabian Jahr, John Newbery, Greg Sanders, Stéphan Vuylsteke, Pieter Wuille, and others for input on this document.\n\nMuch of this work is inspired by ideas and code by Suhas Daftuar and Antoine Riard.\n'''Prior Work on Package Relay'''\n* [https://gist.github.com/sdaftuar/8756699bfcad4d3806ba9f3396d4e66a Strawman Proposal]\n* [https://github.com/bitcoin/bitcoin/issues/14895 Package relay design questions]\n* [https://github.com/bitcoin/bitcoin/pull/16401 Add package acceptance logic to mempool]\n* [https://github.com/bitcoin/bitcoin/pull/19621 [RFC] Package-relay: sender-initiated]\n\n\n==References and Rationale==\n\n", "category": "bips" }, { "instruction": "Can you show me the CLI commands for 
?",
    "input": "",
    "output": "BIP: 125\n  Layer: Applications\n  Title: Opt-in Full Replace-by-Fee Signaling\n  Authors: David A. Harding \n           Peter Todd \n  Comments-Summary: No comments yet.\n  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0125\n  Status: Deployed\n  Type: Specification\n  Assigned: 2015-12-04\n  License: PD\n
\n\n==Abstract==\n\nMany nodes today will not replace any transaction in their mempool with\nanother transaction that spends the same inputs, making it difficult for\nspenders to adjust their previously-sent transactions to deal with\nunexpected confirmation delays or to perform other useful replacements.\n\nThe opt-in full Replace-by-Fee (opt-in full-RBF) signaling policy\ndescribed here allows spenders to add a signal to a transaction indicating\nthat they want to be able to replace that transaction in the future.\nIn response to this signal,\n\n* Nodes may allow transactions containing this signal to be replaced in their mempools.\n\n* The recipient or recipients of a transaction containing this signal may choose not to treat it as payment until it has been confirmed, eliminating the risk that the spender will use allowed replacements to defraud them.\n\nNodes and recipients may continue to treat transactions without the\nsignal the same way they treated them before, preserving the existing\nstatus quo.\n\n==Summary==\n\nThis policy specifies two ways a transaction can signal that it is\nreplaceable.\n\n* '''Explicit signaling:''' A transaction is considered to have opted in to allowing replacement of itself if any of its inputs have an nSequence number less than (0xffffffff - 1).\n\n* '''Inherited signaling:''' Transactions that don't explicitly signal replaceability are replaceable under this policy for as long as any one of their ancestors signals replaceability and remains unconfirmed.\n\n===Implementation Details===\n\nThe initial implementation expected in Bitcoin Core 0.12.0 uses the following rules:\n\nOne or more transactions currently in the mempool (original\ntransactions) will be replaced by a new transaction (replacement\ntransaction) that spends one or more of the same inputs if,", "category": "bips" }, { "instruction": "I'm stuck with The number of original transactions to be replaced and their descendant transactions which will be evicted from the mempool must not exceed a total of 100 transactions. - what should I check?", "input": "", "output": "The initial implementation may be seen in\n[https://github.com/bitcoin/bitcoin/pull/6871 Bitcoin Core PR#6871]\nand specifically the master branch commits from\n5891f870d68d90408aa5ce5b597fb574f2d2cbca to\n16a2f93629f75d182871f288f0396afe6cdc8504 (inclusive).\n\n===Receiving wallet policy===\n\nWallets that display unconfirmed transactions to users or that provide\ndata about unconfirmed transactions to automated systems should consider\ndoing one of the following:", "category": "bips" }, { "instruction": "How do I troubleshoot Ignoring the opt-in transaction until it has been confirmed. issues?", "input": "", "output": "Because descendant transactions may also be replaceable under this\npolicy through inherited signaling, any method used to process opt-in\nfull-RBF transactions should be inherited by any descendant transactions\nfor as long as any ancestor opt-in full-RBF transactions remain\nunconfirmed.\n\n===Spending wallet policy===\n\nWallets that don't want to signal replaceability should use either a max\nsequence number (0xffffffff) or a sequence number of (0xffffffff-1) when\nthey also want to use locktime; all known wallets currently do this.\nThey should also take care not to spend any unconfirmed transaction that\nsignals replaceability explicitly or through inherited signaling; most wallets also\ncurrently do this by not spending any unconfirmed transactions except\nfor those they created themselves.\n\nWallets that do want to make replacements should use explicit signaling\nand meet the criteria described above in the Implementation Details\nsection. A\n[https://en.bitcoin.it/wiki/Transaction_replacement Bitcoin Wiki page]\nhas been created to help wallet authors track deployed mempool policies\nrelating to transaction replacement.\n\nThe initial implementation makes use of P2P protocol reject messages for\nrejected replacements, allowing P2P clients to determine whether their\nreplacements were initially accepted by their peers. Standard P2P\nlightweight client practice of sending to some peers while listening for\nrelays from other peers should allow clients to determine whether the\nreplacement has propagated.\n\n==Motivation==\n\nSatoshi Nakamoto's original Bitcoin implementation provided the\nnSequence number field in each input to\n[https://github.com/trottier/original-bitcoin/blob/master/src/main.cpp#L434 allow replacement]\nof transactions containing that input within the\nmempool. When receiving replacements, nodes were supposed to replace\ntransactions whose inputs had lower sequence numbers with transactions\nthat had higher sequence numbers.\n\nIn that implementation, replacement transactions did not have to pay\nadditional fees, so there was no direct incentive for miners to\ninclude the replacement and no built-in rate limiting that prevented\noveruse of relay node bandwidth. Nakamoto\n[https://github.com/bitcoin/bitcoin/commit/05454818dc7ed92f577a1a1ef6798049f17a52e7#diff-118fcbaaba162ba17933c7893247df3aR522 removed replacement]\nfrom Bitcoin version 0.3.12, leaving only the\ncomment, \"Disable replacement feature for now\".\n\nReplacing transactions with higher-fee transactions provided a way for\nspenders to align their desires with miners, but by the time a\nReplace-by-Fee (RBF) patch was available to re-enable replacement, some\nreceivers had begun to expect that the first version of a transaction\nthey saw was highly likely to be the version of the transaction to be\nconfirmed, and so some users advocated that replacement should be\ndisallowed.\n\nTo address those concerns, a variation on RBF was created that\nrequired that the replacement transaction pay all of the same outputs as\nthe original transaction in equal or greater amount. This was called\nRBF First Seen Safe (RBF-FSS), and the original RBF became known as\nfull-RBF. Although agreeable to recipients who relied on the\nfirst-seen version of a transaction, each use of RBF-FSS required\nadding an extra input to a transaction, resulting in wallets being\nunable to use it if they had no spare inputs, a loss of privacy when\ninputs from different origins get used in the same transaction, and a\nwasteful increase in transaction byte size.\n\nOpt-in full-RBF uses Nakamoto's original semantics (with a slight\ntweak to allow locktime users to opt-out) to signal that replacement\nis possible, providing first-seen users with the ability to ignore\nthose transactions while also allowing for the efficiency benefits\nof full-RBF.\n\nThere are no known problematic interactions between opt-in full-RBF and\nother uses of nSequence. Specifically, opt-in full-RBF is compatible\nwith consensus-enforced locktime as provided in the Bitcoin 0.1\nimplementation, BIP68 (Relative lock-time using consensus-enforced\nsequence numbers), and BIP112 (CHECKSEQUENCEVERIFY).\n\n==Deployment==\n\nNow, and since Bitcoin's first release, 100% of the network hash rate\nmines transactions using opt-in full-RBF semantics (sequence less than\n(0xffffffff - 1)).\n\nOpt-in full-RBF as a default mempool replacement policy among nodes\nand miners is expected to become widespread as they upgrade to Bitcoin\nCore 0.12.0 (release expected Jan/Feb 2016) and similar node software\nsuch as Bitcoin LJR.\n\nActual replacement may be unreliable until two conditions have been satisfied:", "category": "bips" }, { "instruction": "What are the best practices for Enough hash rate has upgraded to support replacement, allowing for reasonable probability that a replacement can be mined.?", "input": "", "output": "==Backwards compatibility==\n\nAt the time opt-in RBF support was added/proposed, no known wallet created transactions by default with nSequence set below (0xffffffff - 1), so no known wallet explicitly signaled replaceability by default. Also no known popular wallet spent other users' unconfirmed transactions by default, so no known wallets signaled inherited replaceability.\n\n==See also==", "category": "bips" }, { "instruction": "Walk me through setting up 
 step by step",
    "input": "",
    "output": "BIP: 154\n  Layer: Peer Services\n  Title: Rate Limiting via peer specified challenges\n  Authors: Karl-Johan Alm \n  Status: Closed\n  Type: Specification\n  Assigned: 2017-04-12\n  License: BSD-2-Clause\n
\n\n==Abstract==\n\nAn anti-DoS system which provides additional service for peers which perform proof of work.\n\n==Definitions==\n\n* '''POW''' : a proof of work using some arbitrary algorithm, such as SHA256\n* '''challenge''' : a problem in the form of a POW specification and other data\n* '''solution''' : a set of inputs which solve a given challenge\n* '''free connection slot''' : an inbound connection slot that does not require POW\n* '''POW connection slot''' : an inbound connection slot that requires POW\n* '''SPH''' : Special Purpose Hardware, such as an ASIC chip\n* '''GPH''' : General Purpose Hardware, such as a desktop computer\n* '''Work''' : A measurement of optimized average resources (clock cycles, memory, ...) required to perform a single attempt at solving a given POW algorithm on GPH\n\n==Motivation==\n\nThe Bitcoin network has a maximum number of inbound and outbound connections (125).\nIt is trivial and relatively cheap to flood the network with connections via dummy\nnodes. Such an attack would result in (1) nodes evicting some other nodes in order to\nfacilitate the new connection, and (2) nodes' ability to connect to each other being\nseverely hampered. In this state, the network is vulnerable to e.g. a Sybil attack.\n\nWhile the network is under pressure as in the above case, nodes could allow incoming\nconnections anyway by requiring that the incoming peer performs some form of proof\nof work, to prove that they are not simply spamming the network. This would severely\nramp up the costs of a Sybil attack, as the attacker would now have to perform proof\nof work for each node, beyond the free slots.\n\nHowever, using the \"standard\" double-SHA256 POW algorithm in use by Bitcoin nodes to\ngenerate blocks means attackers can use special-purpose hardware to greatly accelerate\nthe POW solving process. To counter this, the proof weight would have to be raised,\nbut this would mean standard nodes would need to solve unacceptably costly challenges\nfor simple operation. Therefore, a different proof of work which is arguably less\nsensitive to special-purpose hardware implementations is introduced. As this is not\nconsensus sensitive, additional POW algorithms may be added in the future.\n\n==Specification==\n\nA peer that supports Proof of Work Rate Limiting defines two maximums:\n\n* max connections, from which the maximum inbound connections is calculated as nMaxConnections - (nMaxOutbound + nMaxFeeler)\n* POW connection slots, which define how many of the above inbound connections require a POW challenge\n\nThe peer must interpret two new network peer message types, challenge and solution.\n\nIn addition, the network handshake sequence must be altered slightly to facilitate the exchange of challenges and/or solutions:\n* when a node connects, it may send a solution message prior to the version\n* if it does, and\n** the solution satisfies the local node, it is given a connection, but if\n** the solution does not satisfy the local node (unknown, wrong, ...), a new challenge is sent and the connection is closed\n* if it does not, and it is marked as needing to do POW, a challenge is sent and the connection is closed\n\nThis means nodes will be disconnected after receiving the challenge. It is then up to the individual nodes whether they\nsolve the challenge and reconnect, or discard it and find a different peer (or wait for the peer to have an open free slot).\n\n===POW Identifiers===\n\nThere are two POW identifiers currently. When a new identifier is introduced, it should be added with an increment of 1\nto the last identifier in the list. When an identifier is deprecated, its status should be changed to Deprecated but it should\nretain its place in the list indefinitely.\n\n{|class=\"wikitable\"\n! ID !! Algorithm Name !! Work !! Param size !! Solution size !! Provably Secure !! SPH Resistance !! Status\n|-\n| 1 || sha256 || 11k cycles || 11+ bytes || 0, 4 or 8 bytes || Yes || Low || Active\n|-\n| 2 || cuckoo-cycle || ss 28: 150G cycles / ~48M RAM || 6+ bytes || 168 bytes || No || High || Active\n|}\n\n====sha256====\n\nProperties:\n\n{|class=\"wikitable\"\n! Property !! Value\n|-\n| Solution probability || sum((1/2)^i*(1-targetBE[i]))\n|}\n\nChallenge format:\n\n{|class=\"wikitable\"\n! Range !! Field Name !! Data Type !! Description\n|-\n| 0 || config_length || varint || Length of configuration part; always 9\n|-\n| 1..4 || target || uint32 || Difficulty target, in the form of a compact size (like nBits in blocks).\n|-\n| 5 || nonce_size || uint8 || Size of nonce in bytes; must be 0 (no nonce), 4 (uint32) or 8 (uint64)\n|-\n| 6..9 || nonce_offset || uint32 || Location of nonce value in target\n|-\n| 10.. || payload_length || varint || Length of the input data\n|-\n| .. || payload || byte array || Input data\n|}\n\nSolution format:\n\n{|class=\"wikitable\"\n! Range !! Field Name !! Data Type !! Description\n|-\n| 0.. || nonce || uint32/64, or data || Nonce value that satisfies challenge; for zero-byte nonces, this is variable data that is appended to the challenge payload before hashing\n|}\n\nNote: SHA256 works in two \"modes\".", "category": "bips" }, { "instruction": "What commands would you run to work with Bitcoin Operations Guide?", "input": "", "output": "# One is where the task is to insert a nonce into an existing data block so that the hash of the data block matches a given target; this is the conventional block proof of work behavior.", "category": "bips" }, { "instruction": "I want to understand The other is where the whole or parts of the data chunk are given as input (a \"big nonce\"). In this case, the internal nonce size is zero bytes, and the task is simply to check whether the hash of the data matches the target. If it does not, there is no way to find a solution except by getting different input from the generator (a successor algorithm). This mode is used when SHA256 is a predecessor to another algorithm. from a technical perspective", "input": "", "output": "Additional notes:\n\n* The initial nonce value (when present) for finding a suitable digest should be randomized, or a challenger may deliberately pick a challenge with \"poor\" outcomes to fool a node into spending more than predicted time solving.\n\n====cuckoo-cycle====\n\nProperties:\n\n{|class=\"wikitable\"\n! Property !! Value\n|-\n| Solution probability || ~1.0 for sizeshift=28, proofsize-min:-max=12:228\n|}\n\nChallenge format:\n\n{|class=\"wikitable\"\n! Range !! Field Name !! Data Type !! Description\n|-\n| 0 || config_length || varint || Length of configuration part; always 5\n|-\n| 1 || sizeshift || uint8 || Size shift; must be equal to 28, but may be variable in the future\n|-\n| 2..3 || proofsize-min || uint16 || Minimum number of edges in cycle; must be even and greater than or equal to 12 (recommended: 12)\n|-\n| 4..5 || proofsize-max || uint16 || Maximum number of edges in cycle; must be even, greater than or equal to proofsize-min, and smaller than or equal to 254 (recommended: 228)\n|-\n| 6 || payload_length || varint || Length of the input data; must be 76, but may be variable in the future\n|-\n| 7.. || payload || byte array || Input data\n|}\n\nSolution format:\n\n{|class=\"wikitable\"\n! Range !! Field Name !! Data Type !! Description\n|-\n| 0..3 || nonce || uint32 || Nonce which is appended to challenge payload to form solution graph\n|-\n| 4..171 || edges || uint32 array || 42 values which identify each of the 42 edges in the cycle\n|}\n\nAdditional notes:\n\n* The initial nonce value used for finding a graph with a suitable solution should be randomized, or a challenger may deliberately pick a challenge with \"poor\" outcomes to fool a node into spending more than predicted time solving.\n* Further information on the recommended challenge parameters can be found here: https://web.archive.org/web/20230207054058/http://bc-2.jp/cuckoo-profile.pdf\n\n===Purpose Identifiers===\n\nThere is only one Purpose Identifier currently. In the future, more Purpose Identifiers could be added for at-DoS-risk operations,\nsuch as bloom filters. When a new identifier is introduced, it should be added with an increment of 1 to the last identifier in the\nlist. When an identifier is deprecated, its status should be changed to Deprecated but it should retain its place in\nthe list indefinitely.\n\n{|class=\"wikitable\"\n! ID !! Purpose Name !! Description !! Status\n|-\n| 1 || connect || Establish peer to peer connection || Active\n|}\n\n===Challenges===\n\nChallenges consist of one or several chained POW identifiers with accompanying parameters, as well as indicators for the purpose of the challenge,\nand a signature that lets the node verify the challenge authenticity.\n\nAfter creating a challenge, the node signs it, delivers it to the peer, then discards it.\nWhen a node provides a solution to a challenge, the node verifies the signature and adds the challenge hash to a list of solved\nchallenges along with its expiration time. This list is pruned on each insertion, removing any expired challenges.\n\nIf nodes needed to keep track of unsolved challenges, an attacker could hypothetically swarm a node, causing a DoS by having it generate so many\nchallenges that it runs out of memory and crashes.\nBy signing and discarding challenges, a node only has to retain challenges that were solved, and which have not yet expired, effectively DoS-\nprotecting the node via the challenges themselves.\n\n===The challenge message type===\n\nA challenge consists of four parts: the POW specification, a purpose identifier, an expiration date, and a signature.\nThe POW specification contains a list of tuples containing a POW identifier and corresponding POW parameters.\n\n* Each POW identifier specifies a POW algorithm (see POW Identifiers)\n* The POW parameters define the inputs and requirements of the POW algorithm\n* The purpose identifier specifies the purpose of the challenge (see Purpose Identifiers)\n* The expiration date is a UNIX timestamp indicating when the challenge expires\n* The signed content should contain a signature of the hash SHA256(SHA256(pow-count || pow-id || pow-params || ... || purpose-id || expiration)), i.e. the hash of the entire challenge except for the signature length and data.\n\n{|class=\"wikitable\"\n! Field Size !! Description !! Data type !! Description\n|-\n| 1 byte || pow-count || uint8 || Number of POW algorithms in the range [1..255]\n|-\n| 4 bytes || pow-id || uint32 || The POW algorithm to solve the problem with\n|-\n| ? || pow-params || ? || The POW parameters and payload\n|-\n| ... || ... || ... || pow-id and pow-params for algorithms 2 and beyond\n|-\n| 4 bytes || purpose-id || uint32 || The purpose of the challenge\n|-\n| 8 bytes || expiration || int64 || Expiration UNIX timestamp\n|-\n| ? || sign-len || varint || The length of the signature\n|-\n| ? || sign || byte array || The signature data\n|}\n\nFor POW specifications with a pow-count > 1, the output of the succeeding POW algorithm will be appended to the input of the predecessor for all POW algorithms except the last one.\nNormally mid-layer (all but the last) POW algorithms have a zero-length input. Example implementing sha256(cuckoo-cycle):\n\n{|class=\"wikitable\"\n! Range !! Field Name !! Value !! Comment\n|-\n| 0 || pow-count || 2 || Two POW algorithms\n|-\n| 1..4 || pow-id || 1 || sha256\n|-\n| 5 || pow-params (config_length) || 9 ||\n|-\n| 6..9 || pow-params (target) || 0x207fffff || Resulting hash must be <= the compact hash 0x207fffff*\n|-\n| 10 || pow-params (nonce_size) || 0 || No nonce\n|-\n| 11..14 || pow-params (nonce_offset) || 0 || --\n|-\n| 15..18 || pow-params (payload_length) || 0 || 0 byte input (turns into 32 byte input from successor)\n|-\n| 19..22 || pow-id || 2 || cuckoo-cycle\n|-\n| 23 || pow-params (config_length) || 8 ||\n|-\n| 24 || pow-params (sizeshift) || 28\n|-\n| 25..26 || pow-params (proofsize-min) || 12 ||\n|-\n| 27..28 || pow-params (proofsize-max) || 228 ||\n|-\n| 29 || pow-params (payload_length) || 76 || 76 byte input\n|-\n| 30..105 || pow-params || (random data) || A randomized challenge of 76 bytes\n|-\n| 106..109 || purpose-id || 1 || Purpose is a peer-to-peer connection\n|-\n| 110..117 || expiration || 1491285696 || Expiration is April 4 2017, 15:01:36 (JST)\n|-\n| 118 || sign-len || 71 || 71 byte signature\n|-\n| 119..189 || sign || (signature) || Signature of above challenge\n|}\n\n(* Compact 0x207fffff = 0x7fffff0000000000000000000000000000000000000000000000000000000000.)\n\nThe above should be interpreted as SHA256(cuckoo-cycle(random data || nonce)) < 0x7fffff0000000000000000000000000000000000000000000000000000000000.\n* Run cuckoo-cycle on random data || nonce; increment nonce until solution is found, then\n** Run SHA256 on 32 byte digest from above; if less than 0x7fffff0000000000000000000000000000000000000000000000000000000000,\n*** Mark solved.\n* Otherwise loop back and increase nonce and continue finding solutions\n\n===The solution message type===\n\nA solution consists of two parts: the entire challenge, and solution parameters:\n* The challenge must match the given challenge up to and including the signature bytes\n* The solution parameters must form a valid solution to each POW step in the challenge\n\n{|class=\"wikitable\"\n! Field Size !! Description !! Data type !! Description\n|-\n| 1 byte || pow-count || uint8 || Number of POW algorithms in the range [1..255]\n|-\n| 4 bytes || pow-id || uint32 || The POW algorithm used to solve the problem\n|-\n| ? || pow-params || ? || The input to the POW solver for the above algorithm\n|-\n| ... || ... || ... || pow-id and pow-params for algorithms 2 and beyond\n|-\n| 4 bytes || purpose-id || uint32 || The purpose of the challenge\n|-\n| 8 bytes || expiration || int64 || Expiration UNIX timestamp\n|-\n| ? || sign-len || varint || The length of the signature\n|-\n| ? || sign || byte array || The signature data\n|-\n| ? || solution || ? || The solution to the challenge\n|}\n\nNote that the solution contains the parameters for the last algorithm only.\nFor each algorithm except the last one, the input is derived from the output of the successor.\nExample solution:\n\n{|class=\"wikitable\"\n! Range !! Name !! Value !! Description\n|-\n| 0 || length || 4 || The input to the innermost POW is 4 bytes in length\n|-\n| 1..4 || nonce32 || 0x12345 || The nonce used as input is 0x12345\n|}\n\nThe above example will provide a single nonce for the inner POW. For the SHA256(SHA256(challenge data || nonce32)) case, the solution would\nclaim that SHA256(SHA256(challenge data || 0x00012345)) solves the challenge.\n\n==Signing and Verifying Challenges==\n\nBelow is a suggestion for how to sign a challenge. The implementation generates a new, random key-pair at launch and uses that\nto sign all challenges until the node is shutdown.\n\n===Signing a Challenge===", "category": "bips" }, { "instruction": "Can you explain Bitcoin Operations Guide like we're having a beer and talking Bitcoin?", "input": "", "output": "# (first time) Create a new random key-pair key and pubkey and keep these around until shutdown", "category": "bips" }, { "instruction": "How would you explain Bitcoin Operations Guide to someone who knows Bitcoin basics?", "input": "", "output": "# Create a double-SHA256 sighash of the challenge in serialized form up until and including the expiration bytes", "category": "bips" }, { "instruction": "I'm trying to understand Bitcoin Operations Guide - can you walk me through it?", "input": "", "output": "# Fetch pubkey and declare failure if not defined (that means we never issued a challenge)", "category": "bips" }, { "instruction": "Hey, I need to set up Bitcoin Operations Guide - what's the command line way to do that?", "input": "", "output": "# Create a double-SHA256 sighash of the challenge provided with the solution up until and including the expiration bytes", "category": "bips" }, { "instruction": "What's the deal with Bitcoin Operations Guide in Bitcoin? Explain it like I'm a friend.", "input": "", "output": "# Verify sighash is not known, and add it to known hashes along with its expiration date for pruning purposes", "category": "bips" }, { "instruction": "Can you show me the CLI commands for Check that the solution solves the challenge?", "input": "", "output": "Note that a list of known hashes should be kept and pruned of expired challenges on verification. Otherwise nodes may reuse the same\nsolution repeatedly up until its expiration.\n\n==Difficulty and Cost==\n\n===Estimating Challenge Cost===\n\nNodes need to be able to make a judgement call on whether solving a given challenge is worth their efforts. If a challenge is expected to take\nso much time that it would expire before being solved (on average), it should be immediately discarded. Beyond this, a threshold should be\nestablished for nodes based on their \"value\" to the node, which is inversely proportional to the current number of connections as a function\nof uptime, with arbitrary modifiers (a whitelisted node or a node added via -addnode has a much higher threshold).\n\nIt is hard to obtain an accurate value for cycles_per_second, and as such a fixed value of 1700000000=1.7e9 may be used.\n\nGiven a threshold t, calculate the estimated work required to solve the challenge as follows:", "category": "bips" }, { "instruction": "I'm stuck with Bitcoin Operations Guide - what should I check?", "input": "", "output": "# Define p(alg) as the probability that an attempt at finding a solution given the algorithm alg succeeds", "category": "bips" }, { "instruction": "How do I troubleshoot For each proof of work pow in the POW specification: issues?", "input": "", "output": "## Let p ← p(pow), w ← w(pow)\n## Update Wc ← Wc + w_cycles, Wi ← Wi * 1/p, Wm ← Wm + w_ram", "category": "bips" }, { "instruction": "What are the best practices for If eta > t, discard challenge?", "input": "", "output": "Example: SHA256(cuckoo-cycle(...)) < 0x7fffff0000000000000000000000000000000000000000000000000000000000", "category": "bips" }, { "instruction": "Walk me through setting up Bitcoin Operations Guide step by step", "input": "", "output": "# w(cuckoo-cycle) = (1.5e11 cycles, 5e7 ram), w(sha256, 0x7fffff000...) = (11e3 cycles)", "category": "bips" }, { "instruction": "What commands would you run to work with Wc = 0, Wm = 1, Wi = 1?", "input": "", "output": "## p = p(cuckoo-cycle) = 1, w = w(cuckoo-cycle) = (1.5e11 cycles, 5e7 ram)\n## Wc = 0 + 1.5e11 = 1.5e11, Wi = 1 * 1 = 1, Wm = 1 + 5e7 = 5e7\n## p = p(sha256) = 1/2, w = w(sha256) = (11e3 cycles)\n## Wc = 1.5e11 + 11e3 ~= 1.5e11, Wi = 1 * 2 = 2, Wm = 5e7 + 0 = 5e7", "category": "bips" }, { "instruction": "I want to understand eta = (1.5e11 * 2) / cycles_per_second = 7.5e10 / 1.7e9 = 44.1 seconds from a technical perspective", "input": "", "output": "TODO: Determine how memory impacts threshold.\n\nTo avoid other nodes dropping our challenges due to early expiration, we use a fairly generous expiration based on the pressure value\n
\nexpiration = date() + 600 * (1 + pressure)\n
\nwhich means the expiration is 10 minutes for the weakest challenge, and gradually rises to 20 minutes for the hardest one.\n\n===Establishing Difficulty Parameters===\n\nThe difficulty setting for the network should change based on connection slot availability. The amount of pressure\non the network in the sense of connection slot availability is proportional to the number of established connections\nover the number of total available connections. This can be locally approximated by a node to the number of\nlocal connections compared to the local connection maximum.\n\nIn other words, the network pressure can be approximated by any node as connections / max and the difficulty\ncan be based on e.g. (connections - free) / pow_slots.\n\nThe challenge difficulty parameters can be set based on this, where 0.0 means \"low pressure\" and 1.0 means\n\"maximum pressure\". The GetPressure method below gives 0.0 at 67 connections (for a 50 POW slot set up), and hits the 1.0 mark at (nMaxConnections - nMaxOutbound - nMaxFeeler), incrementing by 0.02 for each new connection:\n
\nint nMaxInbound = nMaxConnections - (nMaxOutbound + nMaxFeeler + nPOWConnectionSlots);\nreturn ((double)GetNodeCount(CONNECTIONS_ALL) - nMaxInbound) / nPOWConnectionSlots;\n
\n\nAn example of difficulty for a SHA256(Cuckoo-Cycle) specification would be based on a desired probability of a random SHA256 digest matching a given target:\n
\nprob_target = 1 / (1 + pressure^2 * 15)\n
\nThis would result in probability targets according to the table below, for varying pressures (where the pressure is in the range [0..1]):\n\n{|class=\"wikitable\"\n! pressure !! prob_target !! solution time sha256(cc)\n|-\n| 0.0 || 1.00 || 00:45\n|-\n| 0.1 || 0.87 || 00:51\n|-\n| 0.2 || 0.63 || 01:11\n|-\n| 0.3 || 0.43 || 01:45\n|-\n| 0.4 || 0.29 || 02:32\n|-\n| 0.5 || 0.21 || 03:32\n|-\n| 0.6 || 0.16 || 04:46\n|-\n| 0.7 || 0.12 || 06:13\n|-\n| 0.8 || 0.09 || 07:54\n|-\n| 0.9 || 0.08 || 09:48\n|-\n| 1.0 || 0.06 || 11:55\n|-\n|}\n\n==Cuckoo Cycle==\n\nCuckoo Cycle[1] is a \"graph-theoretic proof-of-work system, based on finding small cycles or other structures in large random graphs.\"\n\nIt is memory hard, which greatly increases the complexity and cost of producing dedicated (special purpose) hardware, an ideal property for an anti-DoS system.\n\nThe implementation specifics of the algorithm are beyond the scope of this BIP, but the github repository[2] has several reference implementations in various languages.\n\n==Compatibility==\n\nThis proposal is backward compatible. Non-supporting peers will ignore the challenge message\nand be disconnected, as if they hit the peer connection limit as normal.\n\n==Reference implementation==\n\nhttps://github.com/kallewoof/bitcoin/pull/2 (https://github.com/kallewoof/bitcoin/tree/pow-connection-slots)\n\n==References==\n\n* [1] Cuckoo Cycle https://github.com/tromp/cuckoo/blob/master/doc/cuckoo.pdf?raw=true\n* [2] Cuckoo Cycle github https://github.com/tromp/cuckoo\n\n==Test vectors==\n\n===Cuckoo-Cycle===\n\nCuckoo Cycle header (76 bytes):\n
\n00..1f   68a639cb 3deab5b6 23054d60 e7856037 8afa0f31 4f08dec1 6cc4ec4f d9bef1ff\n20..3f   468af883 c6c9c3d5 4260087a 046d12a0 7cc3988f 9ff2957a 384de8ed db75b037\n40..4b   798d1073 214b7ea6 954f1b3a\n
\n\nExample solution nonce: 0 (00000000)\n\nSolution edges (16 number of 32-bit unsigned integers, read horizontally from top left):\n\n
\n550b1100 0fc89a00 45034401 ddfce701 08da0e02 6ccc5703 06fe8404 1d3f8504\n559e3e05 d41a9905 17075206 97cfa006 59e50d07 7bd71f07 13fe2607 14493007\n
\n\n===SHA256(Cuckoo-Cycle)===\n\nSHA256 target: 0x205fffff\n\nCuckoo Cycle header (76 bytes, same as above):\n
\n00..1f   68a639cb 3deab5b6 23054d60 e7856037 8afa0f31 4f08dec1 6cc4ec4f d9bef1ff\n20..3f   468af883 c6c9c3d5 4260087a 046d12a0 7cc3988f 9ff2957a 384de8ed db75b037\n40..4b   798d1073 214b7ea6 954f1b3a\n
\n\nExample solution nonce: 0 (00000000)\n\nSHA256 input (cuckoo-cycle nonce + solution):\n\n
\n00000000\n550b1100 0fc89a00 45034401 ddfce701 08da0e02 6ccc5703 06fe8404 1d3f8504\n559e3e05 d41a9905 17075206 97cfa006 59e50d07 7bd71f07 13fe2607 14493007\n
\n\nSHA256 hash: 262c8558c7c589b19b3d513abf5fcb15162745473e603f0146889ceff750bcc3\n\nMust be less than: 5fffff0000000000000000000000000000000000000000000000000000000000\n\n===Serialized challenge example===\n\n
\n020100000009ffff5f2000000000000002000000051c0c00e4004c68a639cb3deab5b623054d60e7\n8560378afa0f314f08dec16cc4ec4fd9bef1ff468af883c6c9c3d54260087a046d12a07cc3988f9f\nf2957a384de8eddb75b037798d1073214b7ea6954f1b3a01000000a49d0659000000004730450221\n0095fc5fafe2032097c4d12a8901401cda297aad614e16f23ec42d4b78955856c002206ab7ada4ac\n8f6fa9d5bd7cd06f9ba89587a28e14cea14e7f8f8d5ab851541791\n
\n\n{|class=\"wikitable\"\n! Hex !! Description\n|-\n| 0x02 || Two proofs of work\n|-\n| 0x01000000 || Proof of work ID = 1 (SHA256)\n|-\n| 0x09 || Config is 9 bytes\n|-\n| 0xffff5f20 || SHA256: Compact target = 0x205fffff\n|-\n| 0x00 || SHA256: Nonce size is 0 bytes\n|-\n| 0x00000000 || SHA256: Nonce offset is 0\n|-\n| 0x00 || Payload is 0 bytes\n|-\n| 0x02000000 || Proof of work ID = 2 (cuckoo-cycle)\n|-\n| 0x05 || Config is 5 bytes\n|-\n| 0x1c || Size shift is 28\n|-\n| 0x0c00 || Proof size min is 12\n|-\n| 0xe400 || Proof size max is 228\n|-\n| 0x4c || Payload is 76 bytes\n|-\n| 0x68a639cb3deab5b623054d60e7856037 || Payload\n|-\n| 0x8afa0f314f08dec16cc4ec4fd9bef1ff\n|-\n| 0x468af883c6c9c3d54260087a046d12a0\n|-\n| 0x7cc3988f9ff2957a384de8eddb75b037\n|-\n| 0x798d1073214b7ea6954f1b3a\n|-\n| 0x01000000 || Purpose ID = 1 (PURPOSE_CONNECT)\n|-\n| 0xa49d065900000000 || UNIX timestamp 1493605796\n|-\n| 0x47 || 71 byte signature\n|-\n| 0x304502210095fc5fafe2032097c4d12a || Signature data\n|-\n| 0x8901401cda297aad614e16f23ec42d4b\n|-\n| 0x78955856c002206ab7ada4ac8f6fa9d5\n|-\n| 0xbd7cd06f9ba89587a28e14cea14e7f8f\n|-\n| 0x8d5ab851541791\n|}\n\n===Serialized solution example===\n\n
\n020100000009ffff5f2000000000000002000000051c0c00e4004c68a639cb3deab5b623054d60e7\n8560378afa0f314f08dec16cc4ec4fd9bef1ff468af883c6c9c3d54260087a046d12a07cc3988f9f\nf2957a384de8eddb75b037798d1073214b7ea6954f1b3a01000000a49d0659000000004730450221\n0095fc5fafe2032097c4d12a8901401cda297aad614e16f23ec42d4b78955856c002206ab7ada4ac\n8f6fa9d5bd7cd06f9ba89587a28e14cea14e7f8f8d5ab8515417914400000000550b11000fc89a00\n45034401ddfce70108da0e026ccc570306fe84041d3f8504559e3e05d41a99051707520697cfa006\n59e50d077bd71f0713fe260714493007\n
\n\nNote that the first 187 bytes are identical to the challenge above.\n\n{|class=\"wikitable\"\n! Hex !! Description\n|-\n| 0x0201..1791 || Challenge\n|-\n| 0x44 || Solution is 68 bytes long\n|-\n| 0x00000000 || The cuckoo cycle nonce is 0\n|-\n| 0x550b11000fc89a0045034401ddfce701 || Cycle edges 0..3\n|-\n| 0x08da0e026ccc570306fe84041d3f8504 || Cycle edges 4..7\n|-\n| 0x559e3e05d41a99051707520697cfa006 || Cycle edges 8..11\n|-\n| 0x59e50d077bd71f0713fe260714493007 || Cycle edges 12..15\n|}\n\n===Cuckoo-Cycle Example 2===\n\nCuckoo Cycle header (76 bytes):\n
\n00..1f   3c1e3ee5 c799b7e9 92bcccbb 8985979d cb8dd229 b8d0db06 e677d00b b3a43c88\n20..3f   ef8596a7 7cbd1dda 23b0a0b8 4bdf6084 d7aa28dd bd5e91b5 11b3578c baf92707\n40..4b   c940b051 a0759b3f 80c5fb65\n
\n\nExample solution nonce: 4 (04000000)\n\nSolution edges (22 number of 32-bit unsigned integers, read horizontally from top left):\n\n
\n5a013700 7074ce00 e3dbeb00 e88f7901 06d71d02 984d3d02 091b5002 378a8e02\n90a6d202 b3c67003 757cb703 44d9cf03 297f2004 8e76a604 67e44a05 7b077405\n634f8405 23e88c05 0d887606 109d3e07 c4bdcd07 3db2d407\n
\n\n===SHA256(Cuckoo-Cycle)===\n\nSHA256 target: 0x2021642c\n\nCuckoo Cycle header (76 bytes, same as above):\n
\n00..1f   3c1e3ee5 c799b7e9 92bcccbb 8985979d cb8dd229 b8d0db06 e677d00b b3a43c88\n20..3f   ef8596a7 7cbd1dda 23b0a0b8 4bdf6084 d7aa28dd bd5e91b5 11b3578c baf92707\n40..4b   c940b051 a0759b3f 80c5fb65\n
\n\nExample solution nonce: 4 (04000000)\n\nSHA256 input (cuckoo-cycle nonce + solution):\n\n
\n04000000\n5a013700 7074ce00 e3dbeb00 e88f7901 06d71d02 984d3d02 091b5002 378a8e02\n90a6d202 b3c67003 757cb703 44d9cf03 297f2004 8e76a604 67e44a05 7b077405\n634f8405 23e88c05 0d887606 109d3e07 c4bdcd07 3db2d407\n
\n\nSHA256 hash: 08210561257e26776135ec1cb92cfe17f46803613c0bdc02043e5545b18556ce\n\nMust be less than: 21642c0000000000000000000000000000000000000000000000000000000000\n\n===Serialized challenge example===\n\n
\n0201000000092c64212000000000000002000000051c0c00e4004c3c1e3ee5c799b7e992bcccbb89\n85979dcb8dd229b8d0db06e677d00bb3a43c88ef8596a77cbd1dda23b0a0b84bdf6084d7aa28ddbd\n5e91b511b3578cbaf92707c940b051a0759b3f80c5fb650100000024aa0659000000004630440220\n0edfb5c4812a31d84cbbd4b24e631795435a0d16b57d37ef773735b8a87caa8a0220631d0b78b7f1\nd29c9e54a76f3457ff1a2ee19490ff027c528a896f4bf6aff577\n
\n\n{|class=\"wikitable\"\n! Hex !! Description\n|-\n| 0x02 || Two proofs of work\n|-\n| 0x01000000 || Proof of work ID = 1 (SHA256)\n|-\n| 0x09 || Config is 9 bytes\n|-\n| 0x2c642120 || SHA256: Compact target = 0x2021642c\n|-\n| 0x00 || SHA256: Nonce size is 0 bytes\n|-\n| 0x00000000 || SHA256: Nonce offset is 0\n|-\n| 0x00 || Payload is 0 bytes\n|-\n| 0x02000000 || Proof of work ID = 2 (cuckoo-cycle)\n|-\n| 0x05 || Config is 5 bytes\n|-\n| 0x1c || Size shift is 28\n|-\n| 0x0c00 || Proof size min is 12\n|-\n| 0xe400 || Proof size max is 228\n|-\n| 0x4c || Payload is 76 bytes\n|-\n| 0x3c1e3ee5c799b7e992bcccbb8985979d || Payload\n|-\n| 0xcb8dd229b8d0db06e677d00bb3a43c88\n|-\n| 0xef8596a77cbd1dda23b0a0b84bdf6084\n|-\n| 0xd7aa28ddbd5e91b511b3578cbaf92707\n|-\n| 0xc940b051a0759b3f80c5fb65\n|-\n| 0x01000000 || Purpose ID = 1 (PURPOSE_CONNECT)\n|-\n| 0x24aa065900000000 || UNIX timestamp 1493608996\n|-\n| 0x46 || 70 byte signature\n|-\n| 0x304402200edfb5c4812a31d84cbbd4b2 || Signature data\n|-\n| 0x4e631795435a0d16b57d37ef773735b8\n|-\n| 0xa87caa8a0220631d0b78b7f1d29c9e54\n|-\n| 0xa76f3457ff1a2ee19490ff027c528a89\n|-\n| 0x6f4bf6aff577\n|}\n\n===Serialized solution example===\n\n
\n0201000000092c64212000000000000002000000051c0c00e4004c3c1e3ee5c799b7e992bcccbb89\n85979dcb8dd229b8d0db06e677d00bb3a43c88ef8596a77cbd1dda23b0a0b84bdf6084d7aa28ddbd\n5e91b511b3578cbaf92707c940b051a0759b3f80c5fb650100000024aa0659000000004630440220\n0edfb5c4812a31d84cbbd4b24e631795435a0d16b57d37ef773735b8a87caa8a0220631d0b78b7f1\nd29c9e54a76f3457ff1a2ee19490ff027c528a896f4bf6aff5775c040000005a0137007074ce00e3\ndbeb00e88f790106d71d02984d3d02091b5002378a8e0290a6d202b3c67003757cb70344d9cf0329\n7f20048e76a60467e44a057b077405634f840523e88c050d887606109d3e07c4bdcd073db2d407\n
\n\nNote that the first 186 bytes are identical to the challenge above.\n\n{|class=\"wikitable\"\n! Hex !! Description\n|-\n| 0x0201..f577 || Challenge\n|-\n| 0x5c || Solution is 92 bytes long\n|-\n| 0x04000000 || The cuckoo cycle nonce is 4\n|-\n| 0x5a0137007074ce00e3dbeb00e88f7901 || Cycle edges 0..3\n|-\n| 0x06d71d02984d3d02091b5002378a8e02 || Cycle edges 4..7\n|-\n| 0x90a6d202b3c67003757cb70344d9cf03 || Cycle edges 8..11\n|-\n| 0x297f20048e76a60467e44a057b077405 || Cycle edges 12..15\n|-\n| 0x634f840523e88c050d887606109d3e07 || Cycle edges 16..19\n|-\n| 0xc4bdcd073db2d407 || Cycle edges 20..21\n|}\n\n==Copyright==\n\nThis BIP is licensed under the BSD 2-clause license.", "category": "bips" }, { "instruction": "Can you explain 
 like we're having a beer and talking Bitcoin?",
    "input": "",
    "output": "BIP: 16\n  Layer: Consensus (soft fork)\n  Title: Pay to Script Hash\n  Authors: Gavin Andresen \n  Status: Deployed\n  Type: Specification\n  Assigned: 2012-01-03\n
\n\n==Abstract==\n\nThis BIP describes a new \"standard\" transaction type for the Bitcoin scripting system, and defines additional validation rules that apply only to the new transactions.\n\n==Motivation==\n\nThe purpose of pay-to-script-hash is to move the responsibility for supplying the conditions to redeem a transaction from the sender of the funds to the redeemer.\n\nThe benefit is allowing a sender to fund any arbitrary transaction, no matter how complicated, using a fixed-length 20-byte hash that is short enough to scan from a QR code or easily copied and pasted.\n\n==Specification==\n\nA new standard transaction type that is relayed and included in mined blocks is defined:\n\n OP_HASH160 [20-byte-hash-value] OP_EQUAL\n\n[20-byte-hash-value] shall be the push-20-bytes-onto-the-stack opcode (0x14) followed by exactly 20 bytes.\n\nThis new transaction type is redeemed by a standard scriptSig:\n\n ...signatures... {serialized script}\n\nTransactions that redeem these pay-to-script outpoints are only considered standard if the ''serialized script'' - also referred to as the ''redeemScript'' - is, itself, one of the other standard transaction types.\n\nThe rules for validating these outpoints when relaying transactions or considering them for inclusion in a new block are as follows:", "category": "bips" }, { "instruction": "How would you explain Bitcoin Operations Guide to someone who knows Bitcoin basics?", "input": "", "output": "# 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.", "category": "bips" }, { "instruction": "I'm trying to understand {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. - can you walk me through it?", "input": "", "output": "These new rules should only be applied when validating transactions in blocks with timestamps >= 1333238400 (Apr 1 2012) [https://github.com/bitcoin/bitcoin/commit/8f188ece3c82c4cf5d52a3363e7643c23169c0ff Remove -bip16 and -paytoscripthashtime command-line arguments]. There are transactions earlier than 1333238400 in the block chain that fail these new validation rules. [https://web.archive.org/web/20141122040355/http://blockexplorer.com/tx/6a26d2ecb67f27d1fa5524763b49029d7106e91e3cc05743073461a719776192 Transaction 6a26d2ecb67f27d1fa5524763b49029d7106e91e3cc05743073461a719776192]. Older transactions must be validated under the old rules. (see the Backwards Compatibility section for details).\n\nFor example, the scriptPubKey and corresponding scriptSig for a one-signature-required transaction is:\n\n scriptSig: [signature] {[pubkey] OP_CHECKSIG}\n scriptPubKey: OP_HASH160 [20-byte-hash of {[pubkey] OP_CHECKSIG} ] OP_EQUAL\n\nSignature operations in the {serialized script} shall contribute to the maximum number allowed per block (20,000) as follows:", "category": "bips" }, { "instruction": "Hey, I need to set up Bitcoin Operations Guide - what's the command line way to do that?", "input": "", "output": "# OP_CHECKSIG and OP_CHECKSIGVERIFY count as 1 signature operation, whether or not they are evaluated.", "category": "bips" }, { "instruction": "What's the deal with Bitcoin Operations Guide in Bitcoin? Explain it like I'm a friend.", "input": "", "output": "# OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY immediately preceded by OP_1 through OP_16 are counted as 1 to 16 signature operation, whether or not they are evaluated.", "category": "bips" }, { "instruction": "Can you show me the CLI commands for All other OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY are counted as 20 signature operations.?", "input": "", "output": "Examples:\n\n+3 signature operations:\n {2 [pubkey1] [pubkey2] [pubkey3] 3 OP_CHECKMULTISIG}\n\n+22 signature operations:\n {OP_CHECKSIG OP_IF OP_CHECKSIGVERIFY OP_ELSE OP_CHECKMULTISIGVERIFY OP_ENDIF}\n\n==Rationale==\n\nThis BIP replaces BIP 12, which proposed a new Script opcode (\"OP_EVAL\") to accomplish everything in this BIP and more.\n\nThe Motivation for this BIP (and BIP 13, the pay-to-script-hash address type) is somewhat controversial; several people feel that it is unnecessary, and complex/multisignature transaction types should be supported by simply giving the sender the complete {serialized script}. The author believes that this BIP will minimize the changes needed to all of the supporting infrastructure that has already been created to send funds to a base58-encoded-20-byte bitcoin addresses, allowing merchants and exchanges and other software to start supporting multisignature transactions sooner.\n\nRecognizing one 'special' form of scriptPubKey and performing extra validation when it is detected is ugly. However, the consensus is that the alternatives are either uglier, are more complex to implement, and/or expand the power of the expression language in dangerous ways.\n\nThe signature operation counting rules are intended to be easy and quick to implement by statically scanning the {serialized script}. Bitcoin imposes a maximum-number-of-signature-operations per block to prevent denial-of-service attacks on miners. If there was no limit, a rogue miner might broadcast a block that required hundreds of thousands of ECDSA signature operations to validate, and it might be able to get a head start computing the next block while the rest of the network worked to validate the current one.\n\nThere is a 1-confirmation attack on old implementations, but it is expensive and difficult in practice. The attack is:", "category": "bips" }, { "instruction": "I'm stuck with Bitcoin Operations Guide - what should I check?", "input": "", "output": "# Attacker creates a pay-to-script-hash transaction that is valid as seen by old software, but invalid for new implementation, and sends themselves some coins using it.", "category": "bips" }, { "instruction": "How do I troubleshoot Bitcoin Operations Guide issues?", "input": "", "output": "# Attacker also creates a standard transaction that spends the pay-to-script-hash transaction, and pays the victim who is running old software.", "category": "bips" }, { "instruction": "What are the best practices for Attacker mines a block that contains both transactions.?", "input": "", "output": "If the victim accepts the 1-confirmation payment, then the attacker wins because both transactions will be invalidated when the rest of the network overwrites the attacker's invalid block.\n\nThe attack is expensive because it requires the attacker create a block that they know will be invalidated by the rest of the network. It is difficult because creating blocks is difficult and users should not accept 1-confirmation transactions for higher-value transactions.\n\n==Backwards Compatibility==\n\nThese transactions are non-standard to old implementations, which will (typically) not relay them or include them in blocks.\n\nOld implementations will validate that the {serialize script}'s hash value matches when they validate blocks created by software that fully support this BIP, but will do no other validation.\n\nAvoiding a block-chain split by malicious pay-to-script transactions requires careful handling of one case:\n\n* A pay-to-script-hash transaction that is invalid for new clients/miners but valid for old clients/miners.\n\nTo gracefully upgrade and ensure no long-lasting block-chain split occurs, more than 50% of miners must support full validation of the new transaction type and must switch from the old validation rules to the new rules at the same time.\n\nTo judge whether or not more than 50% of hashing power supports this BIP, miners are asked to upgrade their software and put the string \"/P2SH/\" in the input of the coinbase transaction for blocks that they create.\n\nOn February 1, 2012, the block-chain will be examined to determine the number of blocks supporting pay-to-script-hash for the previous 7 days. If 550 or more contain \"/P2SH/\" in their coinbase, then all blocks with timestamps after 15 Feb 2012, 00:00:00 GMT shall have their pay-to-script-hash transactions fully validated. Approximately 1,000 blocks are created in a week; 550 should, therefore, be approximately 55% of the network supporting the new feature.\n\nIf a majority of hashing power does not support the new validation rules, then rollout will be postponed (or rejected if it becomes clear that a majority will never be achieved).\n\n===520-byte limitation on serialized script size===\n\nAs a consequence of the requirement for backwards compatibility the serialized script is itself subject to the same rules as any other PUSHDATA operation, including the rule that no data greater than 520 bytes may be pushed to the stack. Thus it is not possible to spend a P2SH output if the redemption script it refers to is >520 bytes in length. For instance while the OP_CHECKMULTISIG opcode can itself accept up to 20 pubkeys, with 33-byte compressed pubkeys it is only possible to spend a P2SH output requiring a maximum of 15 pubkeys to redeem: 3 bytes + 15 pubkeys * 34 bytes/pubkey = 513 bytes.\n\n\n==Reference Implementation==\n\nhttps://gist.github.com/gavinandresen/3966071\n\n==See Also==\n\n* https://bitcointalk.org/index.php?topic=46538\n* The [[bip-0013.mediawiki|Address format for Pay to Script Hash BIP]]\n* M-of-N Multisignature Transactions [[bip-0011.mediawiki|BIP 11]]\n* [[bip-0016/qa.mediawiki|Quality Assurance test checklist]]\n\n== References ==\n\n", "category": "bips" }, { "instruction": "Walk me through setting up 
 step by step",
    "input": "",
    "output": "BIP: 49\n  Layer: Applications\n  Title: Derivation scheme for P2WPKH-nested-in-P2SH based accounts\n  Authors: Daniel Weigl \n  Comments-Summary: No comments yet.\n  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0049\n  Status: Deployed\n  Type: Specification\n  Assigned: 2016-05-19\n  License: PD\n
\n\n==Abstract==\n\nThis BIP defines the derivation scheme for HD wallets using the P2WPKH-nested-in-P2SH ([[bip-0141.mediawiki|BIP 141]]) serialization format for segregated witness transactions.\n\n==Motivation==\n\nWith the usage of P2WPKH-nested-in-P2SH ([[bip-0141.mediawiki#p2wpkh-nested-in-bip16-p2sh|BIP 141]]) transactions it is necessary to have a common derivation scheme.\nIt allows the user to use different HD wallets with the same masterseed and/or a single account seamlessly.\n\nThus the user needs to create dedicated segregated witness accounts, which ensures that only wallets compatible with this BIP\nwill detect the accounts and handle them appropriately.\n\n===Considerations===\nTwo generally different approaches are possible for current BIP44 capable wallets:\n\n1) Allow the user to use the same account(s) that they already use, but add segregated witness encoded addresses to it.\n\n1.1) Use the same public keys as defined in BIP44, but in addition to the normal P2PKH address also derive the P2SH address from it.\n\n1.2) Use the same account root, but branch off and derive different external and internal chain roots to derive dedicated public keys for the segregated witness addresses.\n\n2) Create dedicated accounts used only for segregated witness addresses.\n\nThe solutions from point 1 have a common disadvantage: if a user imports/recovers a BIP49-compatible wallet masterseed into/in a non-BIP49-compatible wallet, the account might show up but also it might miss some UTXOs.\n\nTherefore this BIP uses solution 2, which fails in a more visible way. Either the account shows up or not at all. The user does not have to check his balance after using the same seed in different wallets.\n\n\n==Specifications==\n\nThis BIP defines the two needed steps to derive multiple deterministic addresses based on a [[bip-0032.mediawiki|BIP 32]] root account.\n\n===Public key derivation===\n\nTo derive a public key from the root account, this BIP uses the same account-structure as defined in\n[[bip-0044.mediawiki|BIP 44]], but only uses a different purpose value to indicate the different transaction\nserialization method.\n\n
\nm / purpose' / coin_type' / account' / change / address_index\n
\n\nFor the `purpose`-path level it uses `49'`. The rest of the levels are used as defined in BIP44.\n\n\n===Address derivation===\n\nTo derive the P2SH address from the above calculated public key, we use the encapsulation defined in [[bip-0141.mediawiki#p2wpkh-nested-in-bip16-p2sh|BIP 141]]:\n\n witness: \n scriptSig: <0 <20-byte-key-hash>>\n (0x160014{20-byte-key-hash})\n scriptPubKey: HASH160 <20-byte-script-hash> EQUAL\n (0xA914{20-byte-script-hash}87)\n\n\n===Extended Key Version===\n\nWhen serializing extended keys, this scheme uses alternate version bytes. Extended public keys use 0x049d7cb2 to produce a \"ypub\" prefix, and private keys use 0x049d7878 to produce a \"yprv\" prefix. Testnet uses 0x044a5262 \"upub\" and 0x044a4e28 \"uprv.\"\n\nAdditional registered version bytes are listed in [[https://github.com/satoshilabs/slips/blob/master/slip-0132.md|SLIP-0132]].\n\n\n==Backwards Compatibility==\n\nThis BIP is not backwards compatible by design as described under [[#considerations|considerations]]. An incompatible wallet will not discover accounts at all and the user will notice that something is wrong.\n\n\n==Test vectors==\n\n
\n  masterseedWords = abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon about\n  masterseed = uprv8tXDerPXZ1QsVNjUJWTurs9kA1KGfKUAts74GCkcXtU8GwnH33GDRbNJpEqTvipfCyycARtQJhmdfWf8oKt41X9LL1zeD2pLsWmxEk3VAwd (testnet)\n\n  // Account 0, root = m/49'/1'/0'\n  account0Xpriv = uprv91G7gZkzehuMVxDJTYE6tLivdF8e4rvzSu1LFfKw3b2Qx1Aj8vpoFnHdfUZ3hmi9jsvPifmZ24RTN2KhwB8BfMLTVqaBReibyaFFcTP1s9n (testnet)\n  account0Xpub = upub5EFU65HtV5TeiSHmZZm7FUffBGy8UKeqp7vw43jYbvZPpoVsgU93oac7Wk3u6moKegAEWtGNF8DehrnHtv21XXEMYRUocHqguyjknFHYfgY (testnet)\n\n  // Account 0, first receiving private key = m/49'/1'/0'/0/0\n  account0recvPrivateKey = cULrpoZGXiuC19Uhvykx7NugygA3k86b3hmdCeyvHYQZSxojGyXJ\n  account0recvPrivateKeyHex = 0xc9bdb49cfbaedca21c4b1f3a7803c34636b1d7dc55a717132443fc3f4c5867e8\n  account0recvPublicKeyHex = 0x03a1af804ac108a8a51782198c2d034b28bf90c8803f5a53f76276fa69a4eae77f\n\n  // Address derivation\n  keyhash = HASH160(account0recvPublicKeyHex) = 0x38971f73930f6c141d977ac4fd4a727c854935b3\n  scriptSig = <0 > = 0x001438971f73930f6c141d977ac4fd4a727c854935b3\n  addressBytes = HASH160(scriptSig) = 0x336caa13e08b96080a32b5d818d59b4ab3b36742\n\n  // addressBytes base58check encoded for testnet\n  address = base58check(prefix | addressBytes) = 2Mww8dCYPUpKHofjgcXcBCEGmniw9CoaiD2 (testnet)\n
\n\n\n==Reference==\n\n* [[bip-0016.mediawiki|BIP16 - Pay to Script Hash]]\n* [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]]\n* [[bip-0043.mediawiki|BIP43 - Purpose Field for Deterministic Wallets]]\n* [[bip-0044.mediawiki|BIP44 - Multi-Account Hierarchy for Deterministic Wallets]]\n* [[bip-0141.mediawiki|BIP141 - Segregated Witness (Consensus layer)]]\n\n== Copyright ==\n\nThis document is placed in the public domain.", "category": "bips" }, { "instruction": "What commands would you run to work with 
?",
    "input": "",
    "output": "BIP: 347\n  Layer: Consensus (soft fork)\n  Title: OP_CAT in Tapscript\n  Authors: Ethan Heilman \n           Armin Sabouri \n  Status: Complete\n  Type: Specification\n  Assigned: 2023-12-11\n  License: BSD-3-Clause\n  Discussion: 2023-10-21: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022049.html [bitcoin-dev] Proposed BIP for OP_CAT\n  Version: 1.0.0\n  Requires: 340, 341, 342\n
\n\n==Abstract==\n\nThis BIP introduces OP_CAT as a tapscript opcode which allows the concatenation of two values on the stack. OP_CAT would be activated via a soft fork by redefining the opcode OP_SUCCESS126 (126 in decimal and 0x7e in hexadecimal). This is the same opcode value used by the original OP_CAT.\n\n== Copyright ==\n\nThis document is licensed under the 3-clause BSD license.\n\n==Specification==\n\nWhen evaluated, the OP_CAT instruction:", "category": "bips" }, { "instruction": "I want to understand and then pushes the concatenated value on the top of the stack. from a technical perspective", "input": "", "output": "Given the stack ''[x1, x2]'', where ''x2'' is at the top of the stack, OP_CAT will push ''x1 || x2'' onto the stack. By ''||'' we denote concatenation. OP_CAT fails if there are fewer than two values on the stack or if a concatenated value would have a combined size greater than the maximum script element size of 520 bytes.\n\nThis opcode would be activated via a soft fork by redefining the tapscript opcode OP_SUCCESS126 (126 in decimal and 0x7e in hexadecimal) to OP_CAT.\n\n==Motivation==\n\nBitcoin Tapscript lacks a general purpose way of combining objects on the stack, restricting the expressiveness and power of Tapscript. This prevents, among many other things, the ability to construct and evaluate merkle trees and other hashed data structures in Tapscript. OP_CAT, by adding a general purpose way to concatenate stack values, would overcome this limitation and greatly increase the functionality of Tapscript.\n\nOP_CAT aims to expand the toolbox of the tapscript developer with a simple, modular, and useful opcode in the spirit of Unix R. Pike and B. Kernighan, \"Program design in the UNIX environment\", 1983, https://harmful.cat-v.org/cat-v/unix_prog_design.pdf. To demonstrate the usefulness of OP_CAT below we provide a non-exhaustive list of some usecases that OP_CAT would enable:\n\n* Bitstream, a protocol for the atomic swap (fair exchange) of bitcoins for decryption keys, that enables decentralized file hosting systems paid in Bitcoin. While such swaps are currently possible on Bitcoin without OP_CAT, they require the use of complex and computationally expensive Verifiable Computation cryptographic techniques. OP_CAT would remove this requirement on Verifiable Computation, making such protocols far more practical to build in Bitcoin. R. Linus, \"BitStream: Decentralized File Hosting Incentivised via Bitcoin Payments\", 2023, https://robinlinus.com/bitstream.pdf\n* Tree signatures provide a multisignature script whose size can be logarithmic in the number of public keys and can encode spend conditions beyond n-of-m. For instance a transaction less than 1KB in size could support tree signatures with up to 4,294,967,296 public keys. This also enables generalized logical spend conditions. P. Wuille, \"Multisig on steroids using tree signatures\", 2015, https://blog.blockstream.com/en-treesignatures/\n* Post-Quantum Lamport signatures in Bitcoin transactions. Lamport signatures merely require the ability to hash and concatenate values on the stack. J. Rubin, \"[bitcoin-dev] OP_CAT Makes Bitcoin Quantum Secure [was CheckSigFromStack for Arithmetic Values]\", 2021, https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019233.html It has been proposed that if ECDSA is broken or a powerful computer was on the horizon, there might be an effort to protect ownership of bitcoins by allowing people to mark their taproot outputs as \"script-path only\" and then move their coins into such outputs with a leaf in the script tree requiring a Lamport signature. It is an open question if a tapscript commitment would preserve the quantum resistance of Lamport signatures. Beyond this question, the use of Lamport Signatures in taproot outputs is unlikely to be quantum resistant even if the script spend-path is made quantum resistant. This is because taproot outputs can also be spent with a key. An attacker with a sufficiently powerful quantum computer could bypass the taproot script spend-path by finding the discrete log of the taproot output and thus spending the output using the key spend-path. The use of \"Nothing Up My Sleeve\" (NUMS) points as described in [[bip-0341.mediawiki|BIP341]] to disable the key spend-path does not disable the key spend-path against a quantum attacker as NUMS relies on the hardness of finding discrete logs. We are not aware of any mechanism which could disable the key spend-path in a taproot output without a softfork change to taproot.\n* Non-equivocation contracts T. Ruffing, A. Kate, D. Schröder, \"Liar, Liar, Coins on Fire: Penalizing Equivocation by Loss of Bitcoins\", 2015, https://web.archive.org/web/20221023121048/https://publications.cispa.saarland/565/1/penalizing.pdf in tapscript provide a mechanism to punish equivocation/double spending in Bitcoin payment channels. OP_CAT enables this by enforcing rules on the spending transaction's nonce. The capability is a useful building block for payment channels and other Bitcoin protocols.\n* Vaults M. Moser, I. Eyal, and E. G. Sirer, Bitcoin Covenants, https://web.archive.org/web/20220203124718/https://fc16.ifca.ai/bitcoin/papers/MES16.pdf which are a specialized covenant that allows a user to block a malicious party who has compromised the user's secret key from stealing the funds in that output. As shown in A. Poelstra, \"CAT and Schnorr Tricks II\", 2021, https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-ii.html OP_CAT is sufficient to build vaults in Bitcoin.\n* Replicating CheckSigFromStack A. Poelstra, \"CAT and Schnorr Tricks I\", 2021, https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-i.html which would allow the creation of simple covenants and other advanced contracts without having to presign spending transactions, possibly reducing complexity and the amount of data that needs to be stored. Originally shown to work with Schnorr signatures, this result has been extended to ECDSA signatures R. Linus, \"Covenants with CAT and ECDSA\", 2023, https://gist.github.com/RobinLinus/9a69f5552be94d13170ec79bf34d5e85#file-covenants_cat_ecdsa-md.\n* OP_CAT would allow tapscript to perform arbitrary computation on stack elements larger than 32-bits such as signatures and public keys. While Collider Script E. Heilman, V. I. Kolobov, A. M. Levy, A. Poelstra, \"ColliderScript: Covenants in Bitcoin via 160-bit hash collisions\", 2024, https://eprint.iacr.org/2024/1802 showed that even without OP_CAT tapscript can perform arbitrary computation on stack elements larger than 32-bits, this approach is extremely computationally expensive. In practice, today's tapscript can only perform arbitrary computation on 32-bit stack elements. OP_CAT was not designed with this usecase in mind and OP_CAT an inefficient way to perform this task.\n* BitVMR. Linus, L. Aumayr, A. Zamyatin, A. Pelosi, Z. Avarikioti, M. Maffei \"BitVM2: Bridging Bitcoin to Second Layers\", 2025, https://bitvm.org/bitvm_bridge.pdf improvements. OP_CAT would enable BitVM2 to eliminating the trusted setup from its proof system allow BitVM2 to reduce the size of transactions it uses.\n\nOP_CAT was available in early versions of Bitcoin.\nIn 2010, a single commit disabled OP_CAT, along with another 15 opcodes.\nFolklore states that OP_CAT was removed in this commit because it enabled the construction of a script whose evaluation could have memory usage exponential in the size of the script.\nFor example, a script that pushed a 1-byte value on the stack and then repeated the opcodes OP_DUP, OP_CAT 40 times would result in a stack element whose size was greater than 1 terabyte assuming no maximum stack element size. As Bitcoin at that time had a maximum stack element size of 5000 bytes, the effect of this expansion was limited to 5000 bytes.\nThis is no longer an issue because tapscript enforces a maximum stack element size of 520 bytes.\n\n\n==Rationale==\n\nOur decision to reenable OP_CAT by redefining a tapscript OP_SUCCESSx opcode to OP_CAT was motivated to leverage the tapscript softfork opcode upgrade path introduced in [[bip-0342.mediawiki|BIP342]].\n\nWe specifically choose to use OP_SUCCESS126 rather than another OP_SUCCESSx as OP_SUCCESS126 uses the same opcode value (126 in decimal and 0x7e in hexadecimal) that was used for OP_CAT prior to it being disabled in Bitcoin. This removes a potential source of confusion that would exist if we had a opcode value different from the one used in the original OP_CAT opcode.\n\nWhile the OP_SUCCESSx opcode upgrade path could enable us to increase the stack element size while reenabling OP_CAT, we wanted to separate the decision to change the stack element size limit from the decision to reenable OP_CAT. This BIP takes no position in favor or against increasing the stack element size limit.\n\n==Backwards Compatibility==\n\nOP_CAT usage in a non-tapscript script will continue to trigger the SCRIPT_ERR_DISABLED_OPCODE. The only change would be to OP_CAT usage in tapscript. This change to tapscript would be activated as a soft fork that redefines an OP_SUCCESSx opcode (OP_SUCCESS126) to OP_CAT.\n\n==Reference implementation==\n\n
\ncase OP_CAT:\n{\n  if (stack.size() < 2)\n    return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);\n  valtype& vch1 = stacktop(-2);\n  valtype& vch2 = stacktop(-1);\n  if (vch1.size() + vch2.size() > MAX_SCRIPT_ELEMENT_SIZE)\n    return set_error(serror, SCRIPT_ERR_PUSH_SIZE);\n  vch1.insert(vch1.end(), vch2.begin(), vch2.end());\n  stack.pop_back();\n}\nbreak;\n
\n\n\nThe value of MAX_SCRIPT_ELEMENT_SIZE is 520.\n\nThis implementation is inspired by the original implementation of [https://github.com/bitcoin/bitcoin/blob/01cd2fdaf3ac6071304ceb80fb7436ac02b1059e/script.cpp#L381-L393 OP_CAT as it existed in the Bitcoin codebase] prior to the commit \"misc changes\" 4bd188cS. Nakamoto, \"misc changes\", Aug 25 2010, https://github.com/bitcoin/bitcoin/commit/4bd188c4383d6e614e18f79dc337fbabe8464c82#diff-27496895958ca30c47bbb873299a2ad7a7ea1003a9faa96b317250e3b7aa1fefR94 which disabled it:\n\n
\ncase OP_CAT:\n{\n    // (x1 x2 -- out)\n    if (stack.size() < 2)\n        return false;\n    valtype& vch1 = stacktop(-2);\n    valtype& vch2 = stacktop(-1);\n    vch1.insert(vch1.end(), vch2.begin(), vch2.end());\n    stack.pop_back();\n    if (stacktop(-1).size() > 5000)\n        return false;\n}\nbreak;\n
\n\nAn alternative implementation of OP_CAT can be found in Elements Roose S., Elements Project, \"Re-enable several disabled opcodes\", 2019, https://github.com/ElementsProject/elements/commit/13e1103abe3e328c5a4e2039b51a546f8be6c60a#diff-a0337ffd7259e8c7c9a7786d6dbd420c80abfa1afdb34ebae3261109d9ae3c19R740-R759.\n\n\n==Test Vectors==\n\nThe following test vectors use Bitcoin-core JSON script-test format.\n\n
\n[\n    [\n        \"78a11a1260c1101260\",\n        \"78a11a1260\",\n        \"c1101260\",\n        \"#SCRIPT# CAT EQUAL\",\n        \"#CONTROLBLOCK#\",\n        0.00000001\n    ],\n    \"\",\n    \"0x51 0x20 #TAPROOTOUTPUT#\",\n    \"P2SH,WITNESS,TAPROOT,OP_CAT\",\n    \"OK\",\n    \"TAPSCRIPT CATs 78a11a1260 and c1101260 together and checks it is EQUAL to stack element 78a11a1260c1101260\"\n],\n[\n    [\n        \"51\",\n        \"bbbb\",\n        \"01\",\n        \"#SCRIPT# IF CAT ELSE DROP ENDIF\",\n        \"#CONTROLBLOCK#\",\n        0.00000001\n    ],\n    \"\",\n    \"0x51 0x20 #TAPROOTOUTPUT#\",\n    \"P2SH,WITNESS,TAPROOT,OP_CAT\",\n    \"OK\",\n    \"TAPSCRIPT Tests CAT inside of an IF ELSE conditional (true IF)\"\n],\n[\n    [\n        \"\",\n        \"09ca7009ca7009ca7009ca7009ca70\",\n        \"#SCRIPT# CAT\",\n        \"#CONTROLBLOCK#\",\n        0.00000001\n    ],\n    \"\",\n    \"0x51 0x20 #TAPROOTOUTPUT#\",\n    \"P2SH,WITNESS,TAPROOT,OP_CAT\",\n    \"OK\",\n    \"TAPSCRIPT (['', 09ca7009ca7009ca7009ca7009ca70], CAT) Tests CAT succeeds when one of the two values to concatenate is of size zero\"\n],\n
\n\nA full test suite with additional vectors can be found at the Bitcoin [https://github.com/bitcoin/bitcoin/pull/29247 OP_CAT PR].\n\n==References==\n\n\n\n==Changelog==\n\n* __1.0.0__ (2026-03-01) - Marked as complete.\n* __0.3.1__ (2026-01-23) - Made compliant with [[bip-0003.md|BIP 3]], use cases added.\n* __0.3.0__ (2024-05-06) - Merged to BIP repo\n* __0.2.0__ (2024-04-24) - Assigned BIP number\n* __0.1.0__ (2023-12-11) - Initial draft posted\n\n\nMay 6, 2024\n\n==Acknowledgements==\n\nWe wish to acknowledge Dan Gould for encouraging and helping review this effort. We also want to thank Madars Virza, Jeremy Rubin, Andrew Poelstra, Bob Summerwill,\nTim Ruffing and Johan T. Halseth for their feedback, review and helpful comments.", "category": "bips" }, { "instruction": "Can you explain 
 like we're having a beer and talking Bitcoin?",
    "input": "",
    "output": "BIP: 113\n  Layer: Consensus (soft fork)\n  Title: Median time-past as endpoint for lock-time calculations\n  Authors: Thomas Kerin \n           Mark Friedenbach \n  Status: Deployed\n  Type: Specification\n  Assigned: 2015-08-10\n  License: PD\n
\n\n\n==Abstract==\n\nThis BIP is a proposal to redefine the semantics used in determining a\ntime-locked transaction's eligibility for inclusion in a block. The\nmedian of the last 11 blocks is used instead of the block's timestamp,\nensuring that it increases monotonically with each block.\n\n\n==Motivation==\n\nAt present, transactions are excluded from inclusion in a block if the\npresent time or block height is less than or equal to that specified\nin the locktime. Since the consensus rules do not mandate strict\nordering of block timestamps, this has the unfortunate outcome of\ncreating a perverse incentive for miners to lie about the time of\ntheir blocks in order to collect more fees by including transactions\nthat by wall clock determination have not yet matured.\n\nThis BIP proposes comparing the locktime against the median of the\npast 11 block's timestamps, rather than the timestamp of the block\nincluding the transaction. Existing consensus rules guarantee this\nvalue to monotonically advance, thereby removing the capability for\nminers to claim more transaction fees by lying about the timestamps of\ntheir block.\n\nThis proposal seeks to ensure reliable behaviour in locktime calculations\nas required by BIP65 (CHECKLOCKTIMEVERIFY) and matching the behavior of\nBIP68 (sequence numbers) and BIP112 (CHECKSEQUENCEVERIFY).\n\n\n==Specification==\n\nThe values for transaction locktime remain unchanged. The difference is only in\nthe calculation determining whether a transaction can be included. Instead of\nan unreliable timestamp, the following function is used to determine the current\nblock time for the purpose of checking lock-time constraints:\n\n enum { nMedianTimeSpan=11 };\n\n int64_t GetMedianTimePast(const CBlockIndex* pindex)\n {\n int64_t pmedian[nMedianTimeSpan];\n int64_t* pbegin = &pmedian[nMedianTimeSpan];\n int64_t* pend = &pmedian[nMedianTimeSpan];\n for (int i = 0; i < nMedianTimeSpan && pindex; i++, pindex = pindex->pprev)\n *(--pbegin) = pindex->GetBlockTime();\n std::sort(pbegin, pend);\n return pbegin[(pend - pbegin)/2];\n }\n\nLock-time constraints are checked by the consensus method IsFinalTx().\nThis method takes the block time as one parameter. This BIP proposes\nthat after activation calls to IsFinalTx() within consensus code use\nthe return value of `GetMedianTimePast(pindexPrev)` instead.\n\nThe new rule applies to all transactions, including the coinbase transaction.\n\nA reference implementation of this proposal is provided by the\nfollowing pull request:\n\nhttps://github.com/bitcoin/bitcoin/pull/6566\n\n\n==Deployment==\n\nThis BIP is to be deployed by \"versionbits\" BIP9 using bit 0.\n\nFor Bitcoin '''mainnet''', the BIP9 '''starttime''' will be midnight 1st May 2016 UTC (Epoch timestamp 1462060800) and BIP9 '''timeout''' will be midnight 1st May 2017 UTC (Epoch timestamp 1493596800).\n\nFor Bitcoin '''testnet''', the BIP9 '''starttime''' will be midnight 1st March 2016 UTC (Epoch timestamp 1456790400) and BIP9 '''timeout''' will be midnight 1st May 2017 UTC (Epoch timestamp 1493596800).\n\nThis BIP must be deployed simultaneously with BIP68 and BIP112 using the same deployment mechanism.\n\n\n==Acknowledgements==\n\nMark Friedenbach for designing and authoring the reference\nimplementation of this BIP.\n\nThanks go to Gregory Maxwell who came up with the original idea,\nin #bitcoin-wizards on 2013-07-16.\n\nThomas Kerin authored this BIP document.\n\n\n==Compatibility==\n\nTransactions generated using time-based lock-time will take\napproximately an hour longer to confirm than would be expected under\nthe old rules. This is not known to introduce any compatibility\nconcerns with existing protocols.\n\n\n==References==\n\n[https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki BIP9: Versionbits]\n\n[https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP65: OP_CHECKLOCKTIMEVERIFY]\n\n[https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP68: Consensus-enforced transaction replacement signaled via sequence numbers]\n\n[https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki BIP112: CHECKSEQUENCEVERIFY]\n\n[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010396.html Softfork deployment considerations]\n\n[https://gist.github.com/sipa/bf69659f43e763540550 Version bits]\n\n\n==Copyright==\n\nThis document is placed in the public domain.", "category": "bips" }, { "instruction": "How would you explain 
 to someone who knows Bitcoin basics?",
    "input": "",
    "output": "BIP: 43\n  Layer: Applications\n  Title: Purpose Field for Deterministic Wallets\n  Authors: Marek Palatinus \n           Pavol Rusnak \n  Status: Deployed\n  Type: Specification\n  Assigned: 2014-04-24\n
\n\n==Abstract==\n\nThis BIP introduces a \"Purpose Field\" for use in deterministic wallets\nbased on algorithm described in BIP-0032 (BIP32 from now on).\n\n==Motivation==\n\nAlthough Hierarchical Deterministic Wallet structure as described by BIP32\nis an important step in user experience and security of the cryptocoin wallets,\nthe BIP32 specification offers implementers too many degrees of freedom.\nMultiple implementations may claim they are BIP32 compatible, but in fact\nthey can produce wallets with different logical structures making them\nnon-interoperable. This situation unfortunately renders \"BIP32 compatible\"\nstatement rather useless.\n\n\n==Purpose==\n\nWe propose the first level of BIP32 tree structure to be used as \"purpose\".\nThis purpose determines the further structure beneath this node.\n\n
\nm / purpose' / *\n
\n\nApostrophe indicates that BIP32 hardened derivation is used.\n\nWe encourage different schemes to apply for assigning a separate BIP number\nand use the same number for purpose field, so addresses won't be generated\nfrom overlapping BIP32 spaces.\n\nPurpose codes from 10001 to 19999 are reserved for [[https://github.com/satoshilabs/slips|SLIPs]].\n\nExample: Scheme described in BIP44 should use 44' (or 0x8000002C) as purpose.\n\nNote that m / 0' / * is already taken by BIP32 (default account), which\npreceded this BIP.\n\nNot all wallets may want to support the full range of features and possibilities\ndescribed in these BIPs. Instead of choosing arbitrary subset of defined features\nand calling themselves BIPxx compatible, we suggest that software which needs\nonly a limited structure should describe such structure in another BIP and use\ndifferent \"purpose\" value.\n\n\n==Node serialization==\n\nBecause this scheme can be used to generate nodes for more cryptocurrencies\nat once, or even something totally unrelated to cryptocurrencies, there's no\npoint in using a special version magic described in section \"Serialization\nformat\" of BIP32. We suggest to use always 0x0488B21E for public and 0x0488ADE4\nfor private nodes (leading to prefixes \"xpub\" and \"xprv\" respectively).\n\n==Reference==\n\n* [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]]", "category": "bips" }, { "instruction": "I'm trying to understand 
 - can you walk me through it?",
    "input": "",
    "output": "BIP: 78\n  Layer: Applications\n  Title: A Simple Payjoin Proposal\n  Authors: Nicolas Dorier \n  Status: Deployed\n  Type: Specification\n  Assigned: 2019-05-01\n  License: BSD-2-Clause\n  Replaces: 79\n
\n\n==Introduction==\n\n===Abstract===\n\nThis document proposes a protocol for two parties\nto negotiate a coinjoin transaction during a payment between them.\n\n===Copyright===\n\nThis BIP is licensed under the 2-clause BSD license.\n\n===Motivation===\n\nWhen two parties (later referred to as sender and receiver) want to transact,\nmost of the time, the sender creates a transaction spending their own Unspent Transaction Outputs (UTXOs), signs\nit and broadcasts it on the network.\n\nThis simple model gave birth to several heuristics impacting the privacy of the parties and of the network as a whole.\n\n* Common input ownership heuristic: In most transactions, all the inputs belong to the same party.\n* Change identification from scriptPubKey type: If all inputs are spending UTXOs of a certain scriptPubKey type, then the change output is likely to have the same scriptPubKey type, too.\n* Change identification from round amount: If an output in the transaction has a round amount, it is likely an output belonging to the receiver.\n\nWe will designate these three heuristics as common-input, change-scriptpubkey, change-round-amount.\n\nThe problems we aim to solve are:\n* For the receiver, there is a missed opportunity to consolidate their own UTXOs or making payment in the sender's transaction.\n* For the sender, there are privacy leaks regarding their wallet that happen when someone applies the heuristics detailed above to their transaction.\n\nOur proposal gives an opportunity for the receiver to consolidate their UTXOs while also batching their own payments, without creating a new transaction. (Saving fees in the process)\nFor the sender, it allows them to invalidate the three heuristics above. With the receiver's involvement, the heuristics can even be poisoned. (ie, using the heuristics to intentionally mislead blockchain analysis)\n\nNote that the existence of this proposal is also improving the privacy of parties who are not using it by making the three heuristics unreliable to the network as a whole.\n\n=== Relation to BIP79 (Bustapay) ===\n\nAnother implementation proposal has been written: [[https://github.com/bitcoin/bips/blob/master/bip-0079.mediawiki|BIP79 Bustapay]].\n\nWe decided to deviate from it for several reasons:\n* It was not using PSBT, so if the receiver wanted to bump the fee, they would need the full UTXO set.\n* Inability to change the payment output to match scriptPubKey type.\n* Lack of basic versioning negotiation if the protocol evolves.\n* No standardization of error condition for proper feedback to the sender.\n\nOther than that, our proposal is very similar.\n\n==Specification==\n\n===Protocol===\n\nIn a payjoin payment, the following steps happen:\n\n* The receiver of the payment, presents a [[bip-0021.mediawiki|BIP 21 URI]] to the sender with a parameter pj= describing a payjoin endpoint.\n* The sender creates a signed, finalized PSBT with witness UTXO or previous transactions of the inputs. We call this PSBT the original.\n* The receiver replies back with a signed PSBT containing his own signed inputs/outputs and those of the sender. We call this PSBT Payjoin proposal.\n* The sender verifies the proposal, re-signs his inputs and broadcasts the transaction to the Bitcoin network. We call this transaction Payjoin transaction.\n
\n+----------+                        +--------+         +-----------------+\n| Receiver |                        | Sender |         | Bitcoin Network |\n+----+-----+                        +---+----+         +-------+---------+\n     |       +-----------------+        |                      |\n     +-------+ BIP21 with ?pj= +------->+                      |\n     |       +-----------------+        |                      |\n     |                                  |                      |\n     |        +---------------+         |                      |\n     +<-------+ Original PSBT +---------+                      |\n     |        +---------------+         |                      |\n     |                                  |                      |\n     |       +------------------+       |                      |\n     |       | Payjoin Proposal |       |                      |\n     +-------+      PSBT        +------>+                      |\n     |       +------------------+       |                      |\n     |                                  |   +--------------+   |\n     |                                  |---+ Payjoin      |   |\n     |                                  |   | transaction  +-->+\n     |                                  |   +--------------+   |\n     +                                  +                      +\n
\nThe original PSBT is sent in the HTTP POST request body, base64 serialized, with text/plain in the Content-Type HTTP header and Content-Length set correctly.\nThe payjoin proposal PSBT is sent in the HTTP response body, base64 serialized with HTTP code 200.\n\nTo ensure compatibility with web-wallets and browser-based-tools, all responses (including errors) must contain the HTTP header Access-Control-Allow-Origin: *.\n\nThe sender must ensure that the URL refers to a scheme or protocol using authenticated encryption, for example TLS with certificate validation, or a .onion link to a hidden service whose public key identifier has already been communicated via a TLS connection. Senders SHOULD NOT accept a URL representing an unencrypted or unauthenticated connection.\n\nThe original PSBT MUST:\n* Have all the witnessUTXO or nonWitnessUTXO information filled in.\n* Be finalized.\n* Not include fields unneeded for the receiver such as global xpubs or keypath information.\n* Be broadcastable.\n\nThe original PSBT MAY:\n* Have outputs unrelated to the payment for batching purpose.\n\nThe original PSBT SHOULD NOT:\n* Include mixed input types until September 2024. Mixed inputs were previously completely disallowed so this gives some grace period for receivers to update.\n\nThe payjoin proposal MUST:\n* Use all the inputs from the original PSBT.\n* Use all the outputs which do not belong to the receiver from the original PSBT.\n* Only finalize the inputs added by the receiver. (Referred later as additional inputs)\n* Only fill the witnessUTXO or nonWitnessUTXO for the additional inputs.\n\nThe payjoin proposal MAY:\n* Add, or replace the outputs belonging to the receiver unless output substitution is disabled.\n\nThe payjoin proposal SHOULD NOT:\n* Include mixed input types until September 2024. Mixed inputs were previously completely disallowed so this gives some grace period for senders to update.\n\nThe payjoin proposal MUST NOT:\n* Shuffle the order of inputs or outputs, the additional outputs or additional inputs must be inserted at a random index.\n* Decrease the absolute fee of the original transaction.\n\n===BIP21 payjoin parameters===\n\nThis proposal is defining the following new [[bip-0021.mediawiki|BIP 21 URI]] parameters:\n* pj=: Represents an http(s) endpoint which the sender can POST the original PSBT.\n* pjos=0: Signal to the sender that they MUST disallow [[#output-substitution|payment output substitution]]. (See [[#unsecured-payjoin|Unsecured payjoin server]])\n\nNote: the amount parameter is *not* required.\n\n===Optional parameters===\n\nWhen the payjoin sender posts the original PSBT to the receiver, he can optionally specify the following HTTP query string parameters:\n\n* v=, the version number of the payjoin protocol that the sender is using. The current version is 1.\n\nThis can be used in the future so the receiver can reject a payjoin if the sender is using a version which is not supported via an error HTTP 400, version-unsupported.\nIf not specified, the receiver will assume the sender is v=1.\n\nIf the receiver does not support the version of the sender, they should send an error with the list of supported versions:\n
\n{\n    \"errorCode\": \"version-unsupported\",\n    \"supported\" : [ 2, 3, 4 ],\n    \"message\": \"The version is not supported anymore\"\n}\n
\n\n* additionalfeeoutputindex=, if the sender is willing to pay for increased fee, this indicate output can have its value subtracted to pay for it.\n\nIf the additionalfeeoutputindex is out of bounds or pointing to the payment output meant for the receiver, the receiver should ignore the parameter. See [[#fee-output|fee output]] for more information.\n\n* maxadditionalfeecontribution=, if the sender is willing to pay for increased fee, an integer defining the maximum amount in satoshis that the sender is willing to contribute towards fees for the additional inputs. maxadditionalfeecontribution must be ignored if set to less than zero. See [[#fee-output|fee output]] for more information.\n\nNote that both maxadditionalfeecontribution= and additionalfeeoutputindex= must be specified and valid for the receiver to be allowed to decrease an output belonging to the sender.\nThis fee contribution can't be used to pay for anything else than additional input's weight.\n\n* minfeerate=, a decimal in satoshi per vbyte that the sender can use to constraint the receiver to not drop the minimum fee rate too much.\n\n* disableoutputsubstitution=, a boolean indicating if the sender forbids the receiver to substitute the receiver's output, see [[#output-substitution|payment output substitution]]. (default to false)\n\n===Receiver's well known errors===\n\nIf for some reason the receiver is unable to create a payjoin proposal, it will reply with a HTTP code different than 200.\nThe receiver is not constrained to specific set of errors, some are specified in this proposal.\n\nThe errors have the following format:\n
\n{\n    \"errorCode\": \"leaking-data\",\n    \"message\": \"Key path information or GlobalXPubs should not be included in the original PSBT.\"\n}\n
\n\nThe well-known error codes are:\n{| class=\"wikitable\"\n!Error code\n!Meaning\n|-\n|unavailable\n|The payjoin endpoint is not available for now.\n|-\n|not-enough-money\n|The receiver added some inputs but could not bump the fee of the payjoin proposal.\n|-\n|version-unsupported\n|This version of payjoin is not supported.\n|-\n|original-psbt-rejected\n|The receiver rejected the original PSBT.\n|}\n\nThe receiver is allowed to return implementation-specific errors which may assist the sender to diagnose any issue.\n\nHowever, it is important that error codes that are not well-known and that the message do not appear on the sender's software user interface.\nSuch error codes or messages could be used maliciously to phish a non-technical user.\nInstead those errors or messages can only appear in debug logs.\n\nIt is advised to hard code the description of the well known error codes into the sender's software.\n\n===Fee output===\n\nIn some situation, the sender might want to pay some additional fee in the payjoin proposal.\nIf such is the case, the sender must use both [[#optional-params|optional parameters]] additionalfeeoutputindex= and maxadditionalfeecontribution= to indicate which output and how much the receiver can subtract fee.\n\nThere are several cases where a fee output is useful:\n\n* The sender's original transaction's fee rate is at the minimum accepted by the network, aka minimum relay transaction fee rate, which is typically 1 satoshi per vbyte.\n\nIn such case, the receiver will need to increase the fee of the transaction after adding his own inputs to not drop below the minimum relay transaction fee rate.\n\n* The sender's wallet software is using round fee rate.\n\nIf the sender's fee rate is always round, then a blockchain analyst can easily spot the transactions of the sender involving payjoin by checking if, when removing a single input to the suspected payjoin transaction, the resulting fee rate is round.\nTo prevent this, the sender can agree to pay more fee so the receiver make sure that the payjoin transaction fee is also round.\n\n* The sender's transaction is time sensitive.\n\nWhen a sender picks a specific fee rate, the sender expects the transaction to be confirmed after a specific amount of time. But if the receiver adds an input without bumping the fee of the transaction, the payjoin transaction fee rate will be lower, and thus, longer to confirm.\n\nOur recommendation for maxadditionalfeecontribution= is originalPSBTFeeRate * 110.\n\n===Receiver's original PSBT checklist===\n\nThe receiver needs to do some check on the original PSBT before proceeding:\n\n* Non-interactive receivers (like a payment processor) need to check that the original PSBT is broadcastable. *\n* If the sender included inputs in the original PSBT owned by the receiver, the receiver must either return error original-psbt-rejected or make sure they do not sign those inputs in the payjoin proposal.\n* Make sure that the inputs included in the original transaction have never been seen before.\n** This prevents [[#probing-attack|probing attacks]].\n** This prevents reentrant payjoin, where a sender attempts to use payjoin transaction as a new original transaction for a new payjoin.\n\n*: Interactive receivers are not required to validate the original PSBT because they are not exposed to [[#probing-attack|probing attacks]].\n\n===Sender's payjoin proposal checklist===\n\nThe sender should check the payjoin proposal before signing it to prevent a malicious receiver from stealing money.\n\n* Verify that the absolute fee of the payjoin proposal is equals or higher than the original PSBT.\n* If the receiver's BIP21 signalled pjos=0, disable payment output substitution.\n* Verify that the transaction version, and the nLockTime are unchanged.\n* Check that the sender's inputs' sequence numbers are unchanged.\n* For each input in the proposal:\n** Verify that no keypaths are in the PSBT input\n** Verify that no partial signature has been filled\n** If it is one of the sender's inputs:\n*** Verify that input's sequence is unchanged.\n*** Verify the PSBT input is not finalized\n** If it is one of the receiver's inputs:\n*** Verify the PSBT input is finalized\n*** Verify that non_witness_utxo or witness_utxo are filled in.\n** Verify that the payjoin proposal inputs all specify the same sequence value.\n** Verify that all of sender's inputs from the original PSBT are in the proposal.\n* For each output in the proposal:\n** Verify that no keypaths are in the PSBT output\n** If the output is the [[#fee-output|fee output]]:\n*** The amount that was subtracted from the output's value is less than or equal to maxadditionalfeecontribution. Let's call this amount actual contribution.\n*** Make sure the actual contribution is only going towards fees: The actual contribution is less than or equals to the difference of absolute fee between the payjoin proposal and the original PSBT.\n*** Make sure the actual contribution is only paying for fees incurred by additional inputs: actual contribution is less than or equal to originalPSBTFeeRate * vsize(sender_input_type) * (count(payjoin_proposal_inputs) - count(original_psbt_inputs)). (see [[#fee-output|Fee output]] section)\n** If the output is the payment output and payment output substitution is allowed,\n*** Do not make any check\n** Else\n*** Make sure the output's value did not decrease.\n** Verify that all sender's outputs (ie, all outputs except the output actually paid to the receiver) from the original PSBT are in the proposal.\n* Once the proposal is signed, if minfeerate was specified, check that the fee rate of the payjoin transaction is not less than this value.\n\nThe sender must be careful to only sign the inputs that were present in the original PSBT and nothing else.\n\nNote:\n* The sender must allow the receiver to add/remove or modify the receiver's own outputs. (if payment output substitution is disabled, the receiver's outputs must not be removed or decreased in value)\n* The sender should allow the receiver to not add any inputs. This is useful for the receiver to change the payment output scriptPubKey type.\n* If the receiver added no inputs, the sender's wallet implementation should accept the payjoin proposal, but not mark the transaction as an actual payjoin in the user interface.\n\nOur method of checking the fee allows the receiver and the sender to batch payments in the payjoin transaction.\nIt also allows the receiver to pay the fee for batching adding his own outputs.\n\n==Rationale==\n\nThere are several consequences of our proposal:\n\n* The receiver can bump the fee of the original transaction.\n* The receiver can modify the outputs of the original PSBT.\n* The sender must provide the UTXO information (Witness or previous transaction) in the PSBT.\n\n===Respecting the minimum relay fee policy===\n\nTo be properly relayed, a Bitcoin transaction needs to pay at least 1 satoshi per virtual byte.\nWhen blocks are not full, the original transaction might already at the minimum relay fee rate (currently 1 satoshi per virtual byte), so if the receiver adds their own input, they need to make sure the fee is increased such that the rate does not drop below the minimum relay fee rate.\nIn such case, the sender must set both maxadditionalfeecontribution= and additionalfeeoutputindex=.\n\nSee the [[#fee-output|Fee output]] section for more information.\n\nWe also recommend the sender to set minfeerate=, as the sender's node policy might be different from the receiver's policy.\n\n===Defeating heuristics based on the fee calculation===\n\nMost wallets are creating a round fee rate (like 2 sat/b).\nIf the payjoin transaction's fee was not increased by the added size, then those payjoin transactions could easily be identifiable on the blockchain.\n\nNot only would those transactions stand out by not having a round fee (like 1.87 sat/b), but any suspicion of payjoin could be confirmed by checking if removing one input would create a round fee rate.\nIn such case, the sender must set both maxadditionalfeecontribution= and additionalfeeoutputindex=.\n\nThe recommended value maxadditionalfeecontribution= is explained in the [[#fee-output|Fee output]] section.\nWe also recommend the sender to set minfeerate=, as the sender's node policy might be different from the receiver's policy.\n\n===Receiver does not need to be a full node===\n\nBecause the receiver needs to bump the fee to keep the same fee rate as the original PSBT, it needs the input's UTXO information to know what is the original fee rate. Without PSBT, light wallets like Wasabi Wallet would not be able to receive a payjoin transaction.\n\nThe validation (policy and consensus) of the original transaction is optional: a receiver without a full node can decide to create the payjoin transaction and automatically broadcast the original transaction after a timeout of 1 minute, and only verify that it has been propagated in the network.\n\nHowever, non-interactive receivers (like a payment processor) need to verify the transaction to prevent UTXO probing attacks.\n\nThis is not a concern for interactive receivers like Wasabi Wallet, because those receivers can just limit the number of original PSBT proposals of a specific address to one. With such wallets, the attacker has no way to generate new deposit addresses to probe the UTXOs.\n\n===Spare change donation===\n\nSmall change inside wallets are detrimental to privacy. Mixers like Wasabi wallet, because of its protocol, eventually generate such [[https://docs.wasabiwallet.io/using-wasabi/ChangeCoins.html#first-round-coinjoin-change|small change]].\n\nA common way to protect your privacy is to donate those spare changes, to deposit them in an exchange or on your favorite merchant's store account. Those kind of transactions can easily be spotted on the blockchain: There is only one output.\n\nHowever, if you donate via payjoin, it will look like a normal transaction.\n\nOn top of this the receiver can poison analysis by randomly faking a round amount of satoshi for the additional output.\n\n===Payment output substitution===\n\nUnless disallowed by the sender explicitly via disableoutputsubstitution=true or by the BIP21 URL via the query parameter pjos=0, the receiver is free to decrease the amount or change the scriptPubKey output paying to himself.\nNote that if payment output substitution is disallowed, the receiver can still increase the amount of the output. (See [[#reference-impl|the reference implementation]])\n\nFor example, if the sender's scriptPubKey type is P2WPKH while the receiver's payment output in the original PSBT is P2SH, then the receiver can substitute the payment output to be P2WPKH to match the sender's scriptPubKey type.\n\n===Unsecured payjoin server===\n\nA receiver might run the payment server (generating the BIP21 invoice) on a different server than the payjoin server, which could be less trusted than the payment server.\n\nIn such case, the payment server can signal to the sender, via the BIP21 parameter pjos=0, that they MUST disallow [[#output-substitution|payment output substitution]].\nA compromised payjoin server could steal the hot wallet outputs of the receiver, but would not be able to re-route payment to himself.\n\n===Impacted heuristics===\n\nOur proposal of payjoin breaks the following blockchain heuristics:\n\n* Common inputs heuristics.\n\nBecause payjoin is mixing the inputs of the sender and receiver, this heuristic becomes unreliable.\n\n* Change identification from scriptPubKey type heuristics\n\nWhen Alice pays Bob, if Alice is using P2SH but Bob's deposit address is P2WPKH, the heuristic would assume that the P2SH output is the change address of Alice.\nThis is now however a broken assumption, as the payjoin receiver has the freedom to mislead analytics by purposefully changing the invoice's address in the payjoin transaction.\n\nSee [[#output-substitution|payment output substitution]].\n\n* Change identification from round change amount\n\nIf Alice pays Bob, she might be tempted to pay him a round amount, like 1.23000000 BTC. When this happens, blockchain analysis often identifies the output without the round amount as the change of the transaction.\n\nFor this reason, during a [[#spare-change|spare change]] case, the receiver may add an output with a rounded amount randomly.\n\n==Attack vectors==\n\n===On the receiver side: UTXO probing attack===\n\nWhen the receiver creates a payjoin proposal, they expose one or more inputs belonging to them.\n\nAn attacker could create multiple original transactions in order to learn the UTXOs of the receiver, while not broadcasting the payjoin proposal.\n\nWhile we cannot prevent this type of attack entirely, we implemented the following mitigations:\n\n* When the receiver detects an original transaction being broadcast, or if the receiver detects that the original transaction has been double spent, then they will reuse the UTXO that was exposed for the next payjoin.\n* While the exposed UTXO will be reused in priority to not leak other UTXOs, there is no strong guarantee about it. This prevents the attacker from detecting with certainty the next payjoin of the merchant to another peer.\n\nNote that probing attacks are only a problem for automated payment systems such as BTCPay Server. End-user wallets with payjoin capabilities are not affected, as the attacker can't create multiple invoices to force the receiver to expose their UTXOs.\n\n===On the sender side: Double payment risk for hardware wallets===\n\nFor a successful payjoin to happen, the sender needs to sign two transactions double spending each other: The original transaction and the payjoin proposal.\n\nThe sender's software wallet can verify that the payjoin proposal is legitimate by the sender's checklist.\n\nHowever, a hardware wallet can't verify that this is indeed the case. This means that the security guarantee of the hardware wallet is decreased. If the sender's software is compromised, the hardware wallet would sign two valid transactions, thus sending two payments.\n\nWithout payjoin, the maximum amount of money that could be lost by a compromised software is equal to one payment (via [[#output-substitution|payment output substitution]]).\nNote that the sender can disallow [[#output-substitution|payment output substitution]] by using the optional parameter disableoutputsubstitution=true.\n\nWith payjoin, the maximum amount of money that can be lost is equal to two payments.\n\n==Reference sender's implementation==\n\nHere is pseudo code of a sender implementation.\nRequestPayjoin takes the BIP21 URI of the payment, the wallet and the signedPSBT.\n\nThe signedPSBT represents a PSBT which has been fully signed, but not yet finalized.\nWe then prepare originalPSBT from the signedPSBT via the CreateOriginalPSBT function and get back the proposal.\n\nWhile we verify the proposal, we also import into it information about our own inputs and outputs from the signedPSBT.\nAt the end of this RequestPayjoin, the proposal is verified and ready to be signed.\n\nWe logged the different PSBT involved, and show the result in our [[#test-vectors|test vectors]].\n
\npublic async Task RequestPayjoin(\n    BIP21Uri bip21,\n    Wallet wallet,\n    PSBT signedPSBT,\n    PayjoinClientParameters optionalParameters)\n{\n    Log(\"Unfinalized signed PSBT\" + signedPSBT);\n    // Extracting the pj link.\n    var endpoint = bip21.ExtractPayjointEndpoint();\n    if (signedPSBT.IsAllFinalized())\n        throw new InvalidOperationException(\"The original PSBT should not be finalized.\");\n    PSBTOutput feePSBTOutput = null;\n\n    bool allowOutputSubstitution = !optionalParameters.DisableOutputSubstitution;\n    if (bip21.Parameters.Contains(\"pjos\") && bip21.Parameters[\"pjos\"] == \"0\")\n        allowOutputSubstitution = false;\n\n    if (optionalParameters.AdditionalFeeOutputIndex != null && optionalParameters.MaxAdditionalFeeContribution != null)\n        feePSBTOutput = signedPSBT.Outputs[optionalParameters.AdditionalFeeOutputIndex];\n    Script paymentScriptPubKey = bip21.Address == null ? null : bip21.Address.ScriptPubKey;\n    decimal originalFee = signedPSBT.GetFee();\n    PSBT originalPSBT = CreateOriginalPSBT(signedPSBT);\n    Transaction originalGlobalTx = signedPSBT.GetGlobalTransaction();\n    TxOut feeOutput = feePSBTOutput == null ? null : originalGlobalTx.Outputs[feePSBTOutput.Index];\n    var originalInputs = new Queue<(TxIn OriginalTxIn, PSBTInput SignedPSBTInput)>();\n    for (int i = 0; i < originalGlobalTx.Inputs.Count; i++)\n    {\n        originalInputs.Enqueue((originalGlobalTx.Inputs[i], signedPSBT.Inputs[i]));\n    }\n    var originalOutputs = new Queue<(TxOut OriginalTxOut, PSBTOutput SignedPSBTOutput)>();\n    for (int i = 0; i < originalGlobalTx.Outputs.Count; i++)\n    {\n      originalOutputs.Enqueue((originalGlobalTx.Outputs[i], signedPSBT.Outputs[i]));\n    }\n    // Add the client side query string parameters\n    endpoint = ApplyOptionalParameters(endpoint, optionalParameters);\n    Log(\"original PSBT\" + originalPSBT);\n    PSBT proposal = await SendOriginalTransaction(endpoint, originalPSBT, cancellationToken);\n    Log(\"payjoin proposal\" + proposal);\n    // Checking that the PSBT of the receiver is clean\n    if (proposal.GlobalXPubs.Any())\n    {\n        throw new PayjoinSenderException(\"GlobalXPubs should not be included in the receiver's PSBT\");\n    }\n    ////////////\n\n    if (proposal.CheckSanity() is List errors && errors.Count > 0)\n        throw new PayjoinSenderException($\"The proposal PSBT is not sane ({errors[0]})\");\n\n    var proposalGlobalTx = proposal.GetGlobalTransaction();\n    // Verify that the transaction version, and nLockTime are unchanged.\n    if (proposalGlobalTx.Version != originalGlobalTx.Version)\n        throw new PayjoinSenderException($\"The proposal PSBT changed the transaction version\");\n    if (proposalGlobalTx.LockTime != originalGlobalTx.LockTime)\n        throw new PayjoinSenderException($\"The proposal PSBT changed the nLocktime\");\n\n    HashSet sequences = new HashSet();\n    // For each inputs in the proposal:\n    foreach (PSBTInput proposedPSBTInput in proposal.Inputs)\n    {\n        if (proposedPSBTInput.HDKeyPaths.Count != 0)\n            throw new PayjoinSenderException(\"The receiver added keypaths to an input\");\n        if (proposedPSBTInput.PartialSigs.Count != 0)\n            throw new PayjoinSenderException(\"The receiver added partial signatures to an input\");\n        PSBTInput proposedTxIn = proposalGlobalTx.Inputs.FindIndexedInput(proposedPSBTInput.PrevOut).TxIn;\n        bool isOurInput = originalInputs.Count > 0 && originalInputs.Peek().OriginalTxIn.PrevOut == proposedPSBTInput.PrevOut;\n        // If it is one of our input\n        if (isOurInput)\n        {\n            OutPoint inputPrevout = ourPrevouts.Dequeue();\n            TxIn originalTxin = originalGlobalTx.Inputs.FromOutpoint(inputPrevout);\n            PSBTInput originalPSBTInput = originalPSBT.Inputs.FromOutpoint(inputPrevout);\n            // Verify that sequence is unchanged.\n            if (input.OriginalTxIn.Sequence != proposedTxIn.Sequence)\n                throw new PayjoinSenderException(\"The proposedTxIn modified the sequence of one of our inputs\")\n            // Verify the PSBT input is not finalized\n            if (proposedPSBTInput.IsFinalized())\n                throw new PayjoinSenderException(\"The receiver finalized one of our inputs\");\n            sequences.Add(proposedTxIn.Sequence);\n\n            // Fill up the info from the original PSBT input so we can sign and get fees.\n            proposedPSBTInput.NonWitnessUtxo = input.SignedPSBTInput.NonWitnessUtxo;\n            proposedPSBTInput.WitnessUtxo = input.SignedPSBTInput.WitnessUtxo;\n            // We fill up information we had on the signed PSBT, so we can sign it.\n            foreach (var hdKey in input.SignedPSBTInput.HDKeyPaths)\n            proposedPSBTInput.HDKeyPaths.Add(hdKey.Key, hdKey.Value);\n            proposedPSBTInput.RedeemScript = signedPSBTInput.RedeemScript;\n            proposedPSBTInput.RedeemScript = input.SignedPSBTInput.RedeemScript;\n        }\n        else\n        {\n            // Verify the PSBT input is finalized\n            if (!proposedPSBTInput.IsFinalized())\n                throw new PayjoinSenderException(\"The receiver did not finalized one of their input\");\n            // Verify that non_witness_utxo or witness_utxo are filled in.\n            if (proposedPSBTInput.NonWitnessUtxo == null && proposedPSBTInput.WitnessUtxo == null)\n                throw new PayjoinSenderException(\"The receiver did not specify non_witness_utxo or witness_utxo for one of their inputs\");\n            sequences.Add(proposedTxIn.Sequence);\n        }\n    }\n\n    // Verify that all of sender's inputs from the original PSBT are in the proposal.\n    if (originalInputs.Count != 0)\n        throw new PayjoinSenderException(\"Some of our inputs are not included in the proposal\");\n\n    // Verify that the payjoin proposal did not introduced mixed inputs' sequence.\n    if (sequences.Count != 1)\n        throw new PayjoinSenderException(\"Mixed sequence detected in the proposal\");\n\n    decimal newFee = proposal.GetFee();\n    decimal additionalFee = newFee - originalFee;\n    if (additionalFee < 0)\n      throw new PayjoinSenderException(\"The receiver decreased absolute fee\");\n    // For each outputs in the proposal:\n    foreach (PSBTOutput proposedPSBTOutput in proposal.Outputs)\n    {\n        // Verify that no keypaths is in the PSBT output\n        if (proposedPSBTOutput.HDKeyPaths.Count != 0)\n            throw new PayjoinSenderException(\"The receiver added keypaths to an output\");\n        if (originalOutputs.Count == 0)\n                continue;\n        var originalOutput = originalOutputs.Peek();\n        bool isOriginalOutput = originalOutput.OriginalTxOut.ScriptPubKey == proposedPSBTOutput.ScriptPubKey;\n        bool substitutedOutput = !isOriginalOutput &&\n                                allowOutputSubstitution &&\n                                originalOutput.OriginalTxOut.ScriptPubKey == paymentScriptPubKey;\n        if (isOriginalOutput || substitutedOutput)\n        {\n            originalOutputs.Dequeue();\n            if (originalOutput.OriginalTxOut == feeOutput)\n            {\n                var actualContribution = feeOutput.Value - proposedPSBTOutput.Value;\n                // The amount that was subtracted from the output's value is less than or equal to maxadditionalfeecontribution\n                if (actualContribution > optionalParameters.MaxAdditionalFeeContribution)\n                    throw new PayjoinSenderException(\"The actual contribution is more than maxadditionalfeecontribution\");\n                // Make sure the actual contribution is only paying fee\n                if (actualContribution > additionalFee)\n                    throw new PayjoinSenderException(\"The actual contribution is not only paying fee\");\n                // Make sure the actual contribution is only paying for fee incurred by additional inputs\n                // This assumes an additional input can be up to 110 bytes.\n                int additionalInputsCount = proposalGlobalTx.Inputs.Count - originalGlobalTx.Inputs.Count;\n                if (actualContribution > originalFeeRate * 110 * additionalInputsCount)\n                    throw new PayjoinSenderException(\"The actual contribution is not only paying for additional inputs\");\n            }\n            else if (allowOutputSubstitution && output.OriginalTxOut.ScriptPubKey == paymentScriptPubKey)\n            {\n                // That's the payment output, the receiver may have changed it.\n            }\n            else\n            {\n                if (originalOutput.OriginalTxOut.Value > proposedPSBTOutput.Value)\n                    throw new PayjoinSenderException(\"The receiver decreased the value of one of the outputs\");\n            }\n            // We fill up information we had on the signed PSBT, so we can sign it.\n            foreach (var hdKey in output.SignedPSBTOutput.HDKeyPaths)\n                proposedPSBTOutput.HDKeyPaths.Add(hdKey.Key, hdKey.Value);\n            proposedPSBTOutput.RedeemScript = output.SignedPSBTOutput.RedeemScript;\n        }\n    }\n    // Verify that all of sender's outputs from the original PSBT are in the proposal.\n    if (originalOutputs.Count != 0)\n    {\n        // The payment output may have been substituted\n        if (!allowOutputSubstitution ||\n            originalOutputs.Count != 1 ||\n            originalOutputs.Dequeue().OriginalTxOut.ScriptPubKey != paymentScriptPubKey)\n            {\n                throw new PayjoinSenderException(\"Some of our outputs are not included in the proposal\");\n            }\n    }\n\n    // After signing this proposal, we should check if minfeerate is respected.\n    Log(\"payjoin proposal filled with sender's information\" + proposal);\n    return proposal;\n}\n\n// Finalize the signedPSBT and remove confidential information\nPSBT CreateOriginalPSBT(PSBT signedPSBT)\n{\n    var original = signedPSBT.Clone();\n    original = original.Finalize();\n    foreach (var input in original.Inputs)\n    {\n        input.HDKeyPaths.Clear();\n        input.PartialSigs.Clear();\n        input.Unknown.Clear();\n    }\n    foreach (var output in original.Outputs)\n    {\n        output.Unknown.Clear();\n        output.HDKeyPaths.Clear();\n    }\n    original.GlobalXPubs.Clear();\n    return original;\n}\n
\n\n==Test vectors==\n\nA successful exchange with:\n\n{| class=\"wikitable\"\n!InputScriptType\n!Original PSBT Fee rate\n!maxadditionalfeecontribution\n!additionalfeeoutputindex\n|-\n|P2SH-P2WPKH\n|2 sat/vbyte\n|0.00000182\n|0\n|}\n\nUnfinalized signed PSBT\n
cHNidP8BAHMCAAAAAY8nutGgJdyYGXWiBEb45Hoe9lWGbkxh/6bNiOJdCDuDAAAAAAD+////AtyVuAUAAAAAF6kUHehJ8GnSdBUOOv6ujXLrWmsJRDCHgIQeAAAAAAAXqRR3QJbbz0hnQ8IvQ0fptGn+votneofTAAAAAAEBIKgb1wUAAAAAF6kU3k4ekGHKWRNbA1rV5tR5kEVDVNCHAQQWABTHikVyU1WCjVZYB03VJg1fy2mFMCICAxWawBqg1YdUxLTYt9NJ7R7fzws2K09rVRBnI6KFj4UWRzBEAiB8Q+A6dep+Rz92vhy26lT0AjZn4PRLi8Bf9qoB/CMk0wIgP/Rj2PWZ3gEjUkTlhDRNAQ0gXwTO7t9n+V14pZ6oljUBIgYDFZrAGqDVh1TEtNi300ntHt/PCzYrT2tVEGcjooWPhRYYSFzWUDEAAIABAACAAAAAgAEAAAAAAAAAAAEAFgAURvYaK7pzgo7lhbSl/DeUan2MxRQiAgLKC8FYHmmul/HrXLUcMDCjfuRg/dhEkG8CO26cEC6vfBhIXNZQMQAAgAEAAIAAAACAAQAAAAEAAAAAAA==
\n\nOriginal PSBT\n
cHNidP8BAHMCAAAAAY8nutGgJdyYGXWiBEb45Hoe9lWGbkxh/6bNiOJdCDuDAAAAAAD+////AtyVuAUAAAAAF6kUHehJ8GnSdBUOOv6ujXLrWmsJRDCHgIQeAAAAAAAXqRR3QJbbz0hnQ8IvQ0fptGn+votneofTAAAAAAEBIKgb1wUAAAAAF6kU3k4ekGHKWRNbA1rV5tR5kEVDVNCHAQcXFgAUx4pFclNVgo1WWAdN1SYNX8tphTABCGsCRzBEAiB8Q+A6dep+Rz92vhy26lT0AjZn4PRLi8Bf9qoB/CMk0wIgP/Rj2PWZ3gEjUkTlhDRNAQ0gXwTO7t9n+V14pZ6oljUBIQMVmsAaoNWHVMS02LfTSe0e388LNitPa1UQZyOihY+FFgABABYAFEb2Giu6c4KO5YW0pfw3lGp9jMUUAAA=
\n\npayjoin proposal\n
cHNidP8BAJwCAAAAAo8nutGgJdyYGXWiBEb45Hoe9lWGbkxh/6bNiOJdCDuDAAAAAAD+////jye60aAl3JgZdaIERvjkeh72VYZuTGH/ps2I4l0IO4MBAAAAAP7///8CJpW4BQAAAAAXqRQd6EnwadJ0FQ46/q6NcutaawlEMIcACT0AAAAAABepFHdAltvPSGdDwi9DR+m0af6+i2d6h9MAAAAAAQEgqBvXBQAAAAAXqRTeTh6QYcpZE1sDWtXm1HmQRUNU0IcAAQEggIQeAAAAAAAXqRTI8sv5ymFHLIjkZNRrNXSEXZHY1YcBBxcWABRfgGZV5ZJMkgTC1RvlOU9L+e2iEAEIawJHMEQCIGe7e0DfJaVPRYEKWxddL2Pr0G37BoKz0lyNa02O2/tWAiB7ZVgBoF4s8MHocYWWmo4Q1cyV2wl7MX0azlqa8NBENAEhAmXWPPW0G3yE3HajBOb7gO7iKzHSmZ0o0w0iONowcV+tAAAA
\n\npayjoin proposal filled with sender's information\n
cHNidP8BAJwCAAAAAo8nutGgJdyYGXWiBEb45Hoe9lWGbkxh/6bNiOJdCDuDAAAAAAD+////jye60aAl3JgZdaIERvjkeh72VYZuTGH/ps2I4l0IO4MBAAAAAP7///8CJpW4BQAAAAAXqRQd6EnwadJ0FQ46/q6NcutaawlEMIcACT0AAAAAABepFHdAltvPSGdDwi9DR+m0af6+i2d6h9MAAAAAAQEgqBvXBQAAAAAXqRTeTh6QYcpZE1sDWtXm1HmQRUNU0IcBBBYAFMeKRXJTVYKNVlgHTdUmDV/LaYUwIgYDFZrAGqDVh1TEtNi300ntHt/PCzYrT2tVEGcjooWPhRYYSFzWUDEAAIABAACAAAAAgAEAAAAAAAAAAAEBIICEHgAAAAAAF6kUyPLL+cphRyyI5GTUazV0hF2R2NWHAQcXFgAUX4BmVeWSTJIEwtUb5TlPS/ntohABCGsCRzBEAiBnu3tA3yWlT0WBClsXXS9j69Bt+waCs9JcjWtNjtv7VgIge2VYAaBeLPDB6HGFlpqOENXMldsJezF9Gs5amvDQRDQBIQJl1jz1tBt8hNx2owTm+4Du4isx0pmdKNMNIjjaMHFfrQABABYAFEb2Giu6c4KO5YW0pfw3lGp9jMUUIgICygvBWB5prpfx61y1HDAwo37kYP3YRJBvAjtunBAur3wYSFzWUDEAAIABAACAAAAAgAEAAAABAAAAAAA=
\n\n==Implementations==\n\n* [[https://github.com/BlueWallet/BlueWallet|BlueWallet]] is in the process of implementing the protocol.\n* [[https://github.com/btcpayserver/btcpayserver|BTCPay Server]] has implemented sender and receiver side of this protocol.\n* [[https://github.com/zkSNACKs/WalletWasabi/|Wasabi Wallet]] has merged sender's support.\n* [[https://github.com/JoinMarket-Org/joinmarket-clientserver|Join Market]] has implemented sender and receiver side of this protocol.\n* [[https://github.com/bitcoinjs/payjoin-client|JavaScript sender implementation]].\n\n==Backward compatibility==\n\nThe receivers advertise payjoin capabilities through [[bip-0021.mediawiki|BIP21's URI Scheme]].\n\nSenders not supporting payjoin will just ignore the pj variable and thus, will proceed to normal payment.\n\n==Special thanks==\n\nSpecial thanks to Kukks for developing the initial support to BTCPay Server, to junderw, AdamISZ, lukechilds, ncoelho, nopara73, lontivero, yahiheb, SomberNight, andrewkozlik, instagibbs, RHavar for all the feedback we received since our first implementation.\nThanks again to RHavar who wrote the [[bip-0079.mediawiki|BIP79 Bustapay]] proposal, this gave a good starting point for our proposal.", "category": "bips" }, { "instruction": "Hey, I need to set up 
 - what's the command line way to do that?",
    "input": "",
    "output": "BIP: 69\n  Layer: Applications\n  Title: Lexicographical Indexing of Transaction Inputs and Outputs\n  Authors: Kristov Atlas \n  Editor: Daniel Cousens \n  Status: Complete\n  Type: Informational\n  Assigned: 2015-06-12\n  License: PD\n
\n\n==Abstract==\n\nCurrently there is no standard for bitcoin wallet clients when ordering transaction inputs and outputs.\nAs a result, wallet clients often have a discernible blockchain fingerprint, and can leak private information about their users.\nBy contrast, a standard for non-deterministic sorting could be difficult to audit.\nThis document proposes deterministic lexicographical sorting, using hashes of previous transactions and output indices to sort transaction inputs, as well as values and scriptPubKeys to sort transaction outputs.\n\n==Copyright==\n\nThis BIP is in the public domain.\n\n==Motivation==\n\nCurrently, there is no clear standard for how wallet clients ought to order transaction inputs and outputs.\nSince wallet clients are left to their own devices to determine this ordering, they often leak information about their users’ finances.\nFor example, a wallet client might naively order inputs based on when addresses were added to a wallet by the user through importing or random generation.\nMany wallets will place spending outputs first and change outputs second, leaking information about both the sender and receiver’s finances to passive blockchain observers.\nSuch information should remain private not only for the benefit of consumers, but in higher order financial systems must be kept secret to prevent fraud.\nA researcher recently demonstrated this principle when he detected that Bitstamp leaked information when creating exchange transactions, enabling potential espionage among traders. [1]\n\nOne way to address these privacy weaknesses is by randomizing the order of inputs and outputs. [2]\nAfter all, the order of inputs and outputs does not impact the function of the transaction they belong to, making random sorting viable.\nUnfortunately, it can be difficult to prove that this sorting process is genuinely randomly sorted based on code or run-time analysis, especially if the software is closed source.\nA malicious software developer can abuse the ordering of inputs and outputs as a side channel of leaking information.\nFor example, if an attacker can patch a victim’s HD wallet client to order inputs and outputs based on the bits of a master private key, then the attacker can eventually steal all of the victim’s funds by monitoring the blockchain.\nNon-deterministic methods of sorting are difficult to audit because they are not repeatable.\n\nThe lack of standardization between wallet clients when ordering inputs and outputs can yield predictable quirks that characterize particular wallet clients or services.\nSuch quirks create unique fingerprints that a privacy attacker can employ through simple passive blockchain observation.\n\nThe solution is to create an algorithm for sorting transaction inputs and outputs that is deterministic.\nSince it is deterministic, it should also be unambiguous — that is, given a particular transaction, the proper order of inputs and outputs should be obvious.\nTo make this standard as widely applicable as possible, it should rely on information that is downloaded by both full nodes (with or without typical efficiency techniques such as pruning) and SPV nodes.\nIn order to ensure that it does not leak confidential data, it must rely on information that is publicly accessible through the blockchain.\nThe use of public blockchain information also allows a transaction to be sorted even when it is a multi-party transaction, such as in the example of a CoinJoin.\n\n==Specification==\n\n===Applicability===\n\nThis BIP applies to any transaction for which the order of its inputs and outputs does not impact the transaction’s function.\nCurrently, this refers to any transaction that employs the SIGHASH_ALL signature hash type, in which signatures commit to the exact order of inputs and outputs.\nTransactions that use SIGHASH_ANYONECANPAY and/or SIGHASH_NONE may include inputs and/or outputs that are not signed; however, compliant software should still emit transactions with lexicographically sorted inputs and outputs, even though they may later be modified by others.\n\nIn the event that future protocol upgrades introduce new signature hash types, compliant software should apply the lexicographical ordering principle analogously.\n\nWhile out of scope of this BIP, protocols that do require a specified order of inputs/outputs (e.g. due to use of SIGHASH_SINGLE) should consider the goals of this BIP and how best to adapt them to the specific needs of those protocols.\n\n===Lexicographical Ordering===\n\nLexicographical ordering is an algorithm for comparison used to sort two sets based on their cartesian order within their common superset.\nLexicographic order is also often known as alphabetical order, or dictionary order.\n\nCommon implementations include:\n\n* `std::lexicographical_compare` in C++ [5]\n* `cmp` in Python 2.7\n* `memcmp` in C [6]\n* `Buffer.compare` in Node.js [7]\n\nFor more information, see the wikipedia entry on Lexicographical order. [8]\n\nN.B. All comparisons do not need to operate in constant time since they are not processing secret information.\n\n===Transaction Inputs===\n\nTransaction inputs are defined by the hash of a previous transaction, the output index of a UTXO from that previous transaction, the size of an unlocking script, the unlocking script, and a sequence number. [3]\nFor sorting inputs, the hash of the previous transaction and the output index within that transaction are sufficient for sorting purposes; each transaction hash has an extremely high probability of being unique in the blockchain — this is enforced for coinbase transactions by BIP30 — and output indices within a transaction are unique.\nFor the sake of efficiency, transaction hashes should be compared first before output indices, since output indices from different transactions are often equivalent, while all bytes of the transaction hash are effectively random variables.\n\nPrevious transaction hashes (in reversed byte-order) are to be sorted in ascending order, lexicographically.\nIn the event of two matching transaction hashes, the respective previous output indices will be compared by their integer value, in ascending order.\nIf the previous output indices match, the inputs are considered equal.\n\nTransaction malleability will not negatively impact the correctness of this process.\nEven if a wallet client follows this process using unconfirmed UTXOs as inputs and an attacker modifies the blockchain’s record of the hash of the previous transaction, the wallet client will include the invalidated previous transaction hash in its input data, and will still correctly sort with respect to that invalidated hash.\n\n===Transaction Outputs===\n\nA transaction output is defined by its scriptPubKey and amount. [3]\nFor the sake of efficiency, amounts should be compared first for sorting, since they contain fewer bytes of information (8 bytes) compared to a standard P2PKH scriptPubKey (25 bytes). [4]\n\nTransaction output amounts (as 64-bit unsigned integers) are to be sorted in ascending order.\nIn the event of two matching output amounts, the respective output scriptPubKeys (as a byte-array) will be compared lexicographically, in ascending order.\nIf the scriptPubKeys match, the outputs are considered equal.\n\n===Examples===\n\nTransaction 0a6a357e2f7796444e02638749d9611c008b253fb55f5dc88b739b230ed0c4c3:\n\nInputs:\n\n 0: 0e53ec5dfb2cb8a71fec32dc9a634a35b7e24799295ddd5278217822e0b31f57[0]\n 1: 26aa6e6d8b9e49bb0630aac301db6757c02e3619feb4ee0eea81eb1672947024[1]\n 2: 28e0fdd185542f2c6ea19030b0796051e7772b6026dd5ddccd7a2f93b73e6fc2[0]\n 3: 381de9b9ae1a94d9c17f6a08ef9d341a5ce29e2e60c36a52d333ff6203e58d5d[1]\n 4: 3b8b2f8efceb60ba78ca8bba206a137f14cb5ea4035e761ee204302d46b98de2[0]\n 5: 402b2c02411720bf409eff60d05adad684f135838962823f3614cc657dd7bc0a[1]\n 6: 54ffff182965ed0957dba1239c27164ace5a73c9b62a660c74b7b7f15ff61e7a[1]\n 7: 643e5f4e66373a57251fb173151e838ccd27d279aca882997e005016bb53d5aa[0]\n 8: 6c1d56f31b2de4bfc6aaea28396b333102b1f600da9c6d6149e96ca43f1102b1[1]\n 9: 7a1de137cbafb5c70405455c49c5104ca3057a1f1243e6563bb9245c9c88c191[0]\n 10: 7d037ceb2ee0dc03e82f17be7935d238b35d1deabf953a892a4507bfbeeb3ba4[1]\n 11: a5e899dddb28776ea9ddac0a502316d53a4a3fca607c72f66c470e0412e34086[0]\n 12: b4112b8f900a7ca0c8b0e7c4dfad35c6be5f6be46b3458974988e1cdb2fa61b8[0]\n 13: bafd65e3c7f3f9fdfdc1ddb026131b278c3be1af90a4a6ffa78c4658f9ec0c85[0]\n 14: de0411a1e97484a2804ff1dbde260ac19de841bebad1880c782941aca883b4e9[1]\n 15: f0a130a84912d03c1d284974f563c5949ac13f8342b8112edff52971599e6a45[0]\n 16: f320832a9d2e2452af63154bc687493484a0e7745ebd3aaf9ca19eb80834ad60[0]\n\nOutputs:\n\n 0: 400057456 76a9144a5fba237213a062f6f57978f796390bdcf8d01588ac\n 1: 40000000000 76a9145be32612930b8323add2212a4ec03c1562084f8488ac\n\nTransaction 28204cad1d7fc1d199e8ef4fa22f182de6258a3eaafe1bbe56ebdcacd3069a5f\n\nInputs:\n\n 0: 35288d269cee1941eaebb2ea85e32b42cdb2b04284a56d8b14dcc3f5c65d6055[0]\n 1: 35288d269cee1941eaebb2ea85e32b42cdb2b04284a56d8b14dcc3f5c65d6055[1]\n\nOutputs:\n\n 0: 100000000 41046a0765b5865641ce08dd39690aade26dfbf5511430ca428a3089261361cef170e3929a68aee3d8d4848b0c5111b0a37b82b86ad559fd2a745b44d8e8d9dfdc0cac\n 1: 2400000000 41044a656f065871a353f216ca26cef8dde2f03e8c16202d2e8ad769f02032cb86a5eb5e56842e92e19141d60a01928f8dd2c875a390f67c1f6c94cfc617c0ea45afac\n\n==Discussion==\n\n* [[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008484.html|[Bitcoin-development] Lexicographical Indexing of Transaction Inputs and Outputs]]\n* [[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008487.html|[Bitcoin-development] [RFC] Canonical input and output ordering in transactions]]\n\n==References==\n\n* [[https://bitcoinmagazine.com/20273/bitstamp-exchange-activity-trackable-due-multisig-wallet-implementation/|1: Bitstamp Info Leak]]\n* [[https://github.com/OpenBitcoinPrivacyProject/wallet-ratings/blob/5a7e2e1555e91bb48edeca3aa710272777d98c2a/2015-1/criteria.md|2: OBPP Random Indexing as Countermeasure]]\n* [[https://github.com/aantonop/bitcoinbook/blob/develop/ch05.asciidoc|3: Mastering Bitcoin]]\n* [[https://en.bitcoin.it/wiki/Script|4: Bitcoin Wiki on Script]]\n* [[http://www.cplusplus.com/reference/algorithm/lexicographical_compare|5: std::lexicographical_compare]]\n* [[http://www.cplusplus.com/reference/cstring/memcmp|6: memcmp]]\n* [[https://nodejs.org/api/buffer.html#buffer_class_method_buffer_compare_buf1_buf2|7: Buffer.compare]]\n* [[https://en.wikipedia.org/wiki/Lexicographical_order|8: Lexicographical order]]\n\n==Implementations==\n\n* [[https://github.com/spesmilo/electrum/blob/2af670ea2b92e835919b745d94afcb8b4ec32fda/lib/transaction.py#L648|Electrum]]\n* [[https://github.com/bitcoinjs/bip69/blob/master/index.js|BitcoinJS]]\n* [[https://github.com/bitcoinjs/bip69/blob/master/test/fixtures.json|BitcoinJS Test Fixtures]]\n* [[https://www.npmjs.com/package/bip69|NodeJS]]\n* [[https://github.com/blockchain/My-Wallet-V3/blob/v3.8.0/src/transaction.js#L120-L142|Blockchain.info public beta]]\n* [[https://github.com/btcsuite/btcd/blob/master/btcutil/txsort/txsort.go|Btcsuite]]\n\n==Acknowledgements==\n\nDanno Ferrin <danno@numisight.com>, Sergio Demian Lerner <sergiolerner@certimix.com>, Justus Ranvier <justus@openbitcoinprivacyproject.org>, and Peter Todd <pete@petertodd.org> contributed to the design and motivations for this BIP.\nA similar proposal was submitted to the Bitcoin-dev mailing list independently by Rusty Russell <rusty@rustcorp.com.au>", "category": "bips" }, { "instruction": "What's the deal with 
 in Bitcoin? Explain it like I'm a friend.",
    "input": "",
    "output": "BIP: 339\n  Layer: Peer Services\n  Title: WTXID-based transaction relay\n  Authors: Suhas Daftuar \n  Status: Deployed\n  Type: Specification\n  Assigned: 2020-02-03\n  License: BSD-2-Clause\n
\n\n==Abstract==\n\nThis BIP describes two changes to the p2p protocol to support transaction relay\nbased on the BIP 141 wtxid of a transaction, rather than its txid.\n\n==Motivation==\n\nHistorically, the inv messages sent on the Bitcoin peer-to-peer network to\nannounce transactions refer to transactions by their txid, which is a hash of\nthe transaction that does not include the witness (see BIP 141). This has been\nthe case even since Segregated Witness (BIP 141/143/144) has been adopted by\nthe network.\n\nNot committing to the witness in transaction announcements creates\ninefficiencies: because a transaction's witness can be malleated without\naltering the txid, a node in receipt of a witness transaction that the node\ndoes not accept will generally still download that same transaction when\nannounced by other peers. This is because the alternative -- of not downloading\na given txid after rejecting a transaction with that txid -- would allow a\nthird party to interfere with transaction relay by malleating a transaction's\nwitness and announcing the resulting invalid transaction to nodes, preventing\nrelay of the valid version of the transaction as well.\n\nWe can eliminate this concern by using the wtxid in place of the txid when\nannouncing and fetching transactions.\n\n==Specification==", "category": "bips" }, { "instruction": "Can you show me the CLI commands for Bitcoin Operations Guide?", "input": "", "output": "# A new wtxidrelay message is added, which is defined as an empty message where pchCommand == \"wtxidrelay\".", "category": "bips" }, { "instruction": "I'm stuck with Bitcoin Operations Guide - what should I check?", "input": "", "output": "# The wtxidrelay message MUST be sent in response to a version message from a peer whose protocol version is >= 70016 and prior to sending a verack. A wtxidrelay message received after a verack message MUST be ignored or treated as invalid.", "category": "bips" }, { "instruction": "How do I troubleshoot Bitcoin Operations Guide issues?", "input": "", "output": "# A new inv type MSG_WTX (0x00000005) is added, for use in both inv messages and getdata requests, indicating that the hash being referenced is a transaction's wtxid. In the case of getdata requests, MSG_WTX implies that the transaction being requested should be serialized with witness as well, as described in BIP 144.", "category": "bips" }, { "instruction": "What are the best practices for Bitcoin Operations Guide?", "input": "", "output": "# After a node has received a wtxidrelay message from a peer, the node MUST use the MSG_WTX inv type when announcing transactions to that peer.", "category": "bips" }, { "instruction": "Walk me through setting up After a node has received a wtxidrelay message from a peer, the node SHOULD use a MSG_WTX getdata message to request any announced transactions. A node MAY still request transactions from that peer using MSG_TX getdata messages, such as for transactions not recently announced by that peer (like the parents of recently announced transactions). step by step", "input": "", "output": "==Backward compatibility==\n\nAs wtxid-based transaction relay is only enabled between peers that both support it, older clients remain fully compatible and interoperable after this change.\n\n==Implementation==\n\nhttps://github.com/bitcoin/bitcoin/pull/18044\n\n==Copyright==\n\nThis BIP is licensed under the 2-clause BSD license.", "category": "bips" }, { "instruction": "What commands would you run to work with 
?",
    "input": "",
    "output": "BIP: 2\n  Title: BIP process, revised\n  Authors: Luke Dashjr \n  Status: Closed\n  Type: Process\n  Assigned: 2016-02-03\n  License: BSD-2-Clause OR OPUBL-1.0\n  Replaces: 1\n  Proposed-Replacement: 3\n
\n\n==Abstract==\n\nA Bitcoin Improvement Proposal (BIP) is a design document providing information to the Bitcoin community, or describing a new feature for Bitcoin or its processes or environment. The BIP should provide a concise technical specification of the feature and a rationale for the feature.\n\nWe intend BIPs to be the primary mechanisms for proposing new features, for collecting community input on an issue, and for documenting the design decisions that have gone into Bitcoin. The BIP author is responsible for building consensus within the community and documenting dissenting opinions.\n\nBecause the BIPs are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal.\n\nThis particular BIP replaces BIP 1 with a more well-defined and clear process.\n\n==Copyright==\n\nThis BIP is dual-licensed under the Open Publication License and BSD 2-clause license.\n\n==BIP workflow==\n\nThe BIP process begins with a new idea for Bitcoin. Each potential BIP must have a champion -- someone who writes the BIP using the style and format described below, shepherds the discussions in the appropriate forums, and attempts to build community consensus around the idea. The BIP champion (a.k.a. Author) should first attempt to ascertain whether the idea is BIP-able.\nSmall enhancements or patches to a particular piece of software often don't require standardisation between multiple projects; these don't need a BIP and should be injected into the relevant project-specific development workflow with a patch submission to the applicable issue tracker.\nAdditionally, many ideas have been brought forward for changing Bitcoin that have been rejected for various reasons.\nThe first step should be to search past discussions to see if an idea has been considered before, and if so, what issues arose in its progression.\nAfter investigating past work, the best way to proceed is by posting about the new idea to the [https://groups.google.com/g/bitcoindev Bitcoin development mailing list].\n\nVetting an idea publicly before going as far as writing a BIP is meant to save both the potential author and the wider community time.\nAsking the Bitcoin community first if an idea is original helps prevent too much time being spent on something that is guaranteed to be rejected based on prior discussions (searching the internet does not always do the trick).\nIt also helps to make sure the idea is applicable to the entire community and not just the author. Just because an idea sounds good to the author does not mean it will work for most people in most areas where Bitcoin is used.\n\nOnce the champion has asked the Bitcoin community as to whether an idea has any chance of acceptance, a draft BIP should be presented to the [https://groups.google.com/g/bitcoindev Bitcoin development mailing list].\nThis gives the author a chance to flesh out the draft BIP to make it properly formatted, of high quality, and to address additional concerns about the proposal.\nFollowing a discussion, the proposal should be submitted to the [https://github.com/bitcoin/bips BIPs git repository] as a pull request.\nThis draft must be written in BIP style as described below, and named with an alias such as \"bip-johndoe-infinitebitcoins\" until an editor has assigned it a BIP number (authors MUST NOT self-assign BIP numbers).\n\nBIP authors are responsible for collecting community feedback on both the initial idea and the BIP before submitting it for review. However, wherever possible, long open-ended discussions on public mailing lists should be avoided. Strategies to keep the discussions efficient include: setting up a separate SIG mailing list for the topic, having the BIP author accept private comments in the early design phases, setting up a wiki page or git repository, etc. BIP authors should use their discretion here.\n\nIt is highly recommended that a single BIP contain a single key proposal or new idea. The more focused the BIP, the more successful it tends to be. If in doubt, split your BIP into several well-focused ones.\n\nWhen the BIP draft is complete, a BIP editor will assign the BIP a number, label it as Standards Track, Informational, or Process, and merge the pull request to the BIPs git repository.\nThe BIP editors will not unreasonably reject a BIP.\nReasons for rejecting BIPs include duplication of effort, disregard for formatting rules, being too unfocused or too broad, being technically unsound, not providing proper motivation or addressing backwards compatibility, or not in keeping with the Bitcoin philosophy.\nFor a BIP to be accepted it must meet certain minimum criteria.\nIt must be a clear and complete description of the proposed enhancement.\nThe enhancement must represent a net improvement.\nThe proposed implementation, if applicable, must be solid and must not complicate the protocol unduly.\n\nThe BIP author may update the draft as necessary in the git repository. Updates to drafts should also be submitted by the author as pull requests.\n\n===Transferring BIP Ownership===\n\nIt occasionally becomes necessary to transfer ownership of BIPs to a new champion. In general, we'd like to retain the original author as a co-author of the transferred BIP, but that's really up to the original author. A good reason to transfer ownership is because the original author no longer has the time or interest in updating it or following through with the BIP process, or has fallen off the face of the 'net (i.e. is unreachable or not responding to email). A bad reason to transfer ownership is because you don't agree with the direction of the BIP. We try to build consensus around a BIP, but if that's not possible, you can always submit a competing BIP.\n\nIf you are interested in assuming ownership of a BIP, send a message asking to take over, addressed to both the original author and the BIP editors. If the original author doesn't respond to email in a timely manner, the BIP editors will make a unilateral decision (it's not like such decisions can't be reversed :).\n\n===BIP Editors===\n\nThe current BIP editors are:\n\n* Bryan Bishop ([[mailto:kanzure@gmail.com|kanzure@gmail.com]])\n* Jon Atack ([[mailto:jon@atack.com|jon@atack.com]])\n* Luke Dashjr ([[mailto:luke_bipeditor@dashjr.org|luke_bipeditor@dashjr.org]])\n* Mark \"Murch\" Erhardt ([[mailto:murch@murch.one|murch@murch.one]])\n* Olaoluwa Osuntokun ([[mailto:laolu32@gmail.com|laolu32@gmail.com]])\n* Ruben Somsen ([[mailto:rsomsen@gmail.com|rsomsen@gmail.com]])\n\n===BIP Editor Responsibilities & Workflow===\n\nThe BIP editors subscribe to the Bitcoin development mailing list.\nOff-list BIP-related correspondence should be sent (or CC'd) to the BIP editors.\n\nFor each new BIP that comes in an editor does the following:\n\n* Read the BIP to check if it is ready: sound and complete. The ideas must make technical sense, even if they don't seem likely to be accepted.\n* The title should accurately describe the content.\n* The BIP draft must have been sent to the Bitcoin development mailing list for discussion.\n* Motivation and backward compatibility (when applicable) must be addressed.\n* The defined Layer header must be correctly assigned for the given specification.\n* Licensing terms must be acceptable for BIPs.\n\nIf the BIP isn't ready, the editor will send it back to the author for revision, with specific instructions.\n\nOnce the BIP is ready for the repository it should be submitted as a \"pull request\" to the [https://github.com/bitcoin/bips BIPs git repository] where it may get further feedback.\n\nThe BIP editor will:\n\n* Assign a BIP number in the pull request.\n\n* Merge the pull request when it is ready.\n\n* List the BIP in [[README.mediawiki]]\n\nThe BIP editors are intended to fulfill administrative and editorial responsibilities. The BIP editors monitor BIP changes, and update BIP headers as appropriate.\n\nBIP editors may also, at their option, unilaterally make and merge strictly-editorial changes to BIPs, such as correcting misspellings, fixing broken links, etc.\n\n==BIP format and structure==\n\n===Specification===\n\nBIPs should be written in mediawiki or markdown format.\n\nEach BIP should have the following parts:\n\n* Preamble -- Headers containing metadata about the BIP ([[#bip-header-preamble|see below]]).\n\n* Abstract -- A short (~200 word) description of the technical issue being addressed.\n\n* Copyright -- The BIP must be explicitly licensed under acceptable copyright terms ([[#bip-licensing|see below]]).\n\n* Specification -- The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Bitcoin platforms.\n\n* Motivation -- The motivation is critical for BIPs that want to change the Bitcoin protocol. It should clearly explain why the existing protocol is inadequate to address the problem that the BIP solves.\n\n* Rationale -- The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work. The rationale should provide evidence of consensus within the community and discuss important objections or concerns raised during discussion.\n\n* Backwards compatibility -- All BIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The BIP must explain how the author proposes to deal with these incompatibilities.\n\n* Reference implementation -- The reference implementation must be completed before any BIP is given status \"Final\", but it need not be completed before the BIP is accepted. It is better to finish the specification and rationale first and reach consensus on it before writing code. The final implementation must include test code and documentation appropriate for the Bitcoin protocol.\n\n====BIP header preamble====\n\nEach BIP must begin with an RFC 822 style header preamble. The headers must appear in the following order. Headers marked with \"*\" are optional and are described below. All other headers are required.\n\n
\n  BIP: \n* Layer: \n  Title: \n  Author: \n* Discussions-To: \n* Comments-Summary: \n  Comments-URI: \n  Status: \n  Type: \n  Created: \n  License: \n* License-Code: \n* Post-History: \n* Requires: \n* Replaces: \n* Superseded-By: \n
\n\nThe Layer header (only for Standards Track BIPs) documents which layer of Bitcoin the BIP applies to.\nSee [[bip-0123.mediawiki|BIP 123]] for definitions of the various BIP layers. Activation of this BIP implies activation of BIP 123.\n\nThe Author header lists the names and email addresses of all the authors/owners of the BIP.\nThe format of the Author header value must be\n\n Random J. User \n\nIf there are multiple authors, each should be on a separate line following RFC 2822 continuation line conventions.\n\nWhile a BIP is in private discussions (usually during the initial Draft phase), a Discussions-To header will indicate the mailing list or URL where the BIP is being discussed. No Discussions-To header is necessary if the BIP is being discussed privately with the author, or on the bitcoin email mailing lists.\n\nThe Type header specifies the type of BIP: Standards Track, Informational, or Process.\n\nThe Created header records the date that the BIP was assigned a number, while Post-History is used to record when new versions of the BIP are posted to bitcoin mailing lists.\nDates should be in yyyy-mm-dd format, e.g. 2001-08-14.\nPost-History is permitted to be a link to a specific thread in a mailing list archive.\n\nBIPs may have a Requires header, indicating the BIP numbers that this BIP depends on.\n\nBIPs may also have a Superseded-By header indicating that a BIP has been rendered obsolete by a later document; the value is the number of the BIP that replaces the current document. The newer BIP must have a Replaces header containing the number of the BIP that it rendered obsolete.\n\n====Auxiliary Files====\n\nBIPs may include auxiliary files such as diagrams. Auxiliary files should be included in a subdirectory for that BIP, or must be named BIP-XXXX-Y.ext, where \"XXXX\" is the BIP number, \"Y\" is a serial number (starting at 1), and \"ext\" is replaced by the actual file extension (e.g. \"png\").\n\n==BIP types==\n\nThere are three kinds of BIP:\n\n* A Standards Track BIP describes any change that affects most or all Bitcoin implementations, such as a change to the network protocol, a change in block or transaction validity rules, or any change or addition that affects the interoperability of applications using Bitcoin. Standards Track BIPs consist of two parts, a design document and a reference implementation.\n* An Informational BIP describes a Bitcoin design issue, or provides general guidelines or information to the Bitcoin community, but does not propose a new feature. Informational BIPs do not necessarily represent a Bitcoin community consensus or recommendation, so users and implementers are free to ignore Informational BIPs or follow their advice.\n* A Process BIP describes a process surrounding Bitcoin, or proposes a change to (or an event in) a process. Process BIPs are like Standards Track BIPs but apply to areas other than the Bitcoin protocol itself. They may propose an implementation, but not to Bitcoin's codebase; they often require community consensus; unlike Informational BIPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Bitcoin development. Any meta-BIP is also considered a Process BIP.\n\n==BIP status field==\n\n===Specification===\n\nThe typical paths of the status of BIPs are as follows:\n\n\n\nChampions of a BIP may decide on their own to change the status between Draft, Deferred, or Withdrawn.\nA BIP editor may also change the status to Deferred when no progress is being made on the BIP.\n\nA BIP may only change status from Draft (or Rejected) to Proposed, when the author deems it is complete, has a working implementation (where applicable), and has community plans to progress it to the Final status.\n\nBIPs should be changed from Draft or Proposed status, to Rejected status, upon request by any person, if they have not made progress in three years. Such a BIP may be changed to Draft status if the champion provides revisions that meaningfully address public criticism of the proposal, or to Proposed status if it meets the criteria required as described in the previous paragraph.\n\nA Proposed BIP may progress to Final only when specific criteria reflecting real-world adoption has occurred. This is different for each BIP depending on the nature of its proposed changes, which will be expanded on below. Evaluation of this status change should be objectively verifiable, and/or be discussed on the development mailing list.\n\nWhen a Final BIP is no longer relevant, its status may be changed to Replaced or Obsolete (which is equivalent to Replaced). This change must also be objectively verifiable and/or discussed.\n\nA process BIP may change status from Draft to Active when it achieves rough consensus on the mailing list. Such a proposal is said to have rough consensus if it has been open to discussion on the development mailing list for at least one month, and no person maintains any unaddressed substantiated objections to it. Addressed or obstructive objections may be ignored/overruled by general agreement that they have been sufficiently addressed, but clear reasoning must be given in such circumstances.\n\n====Progression to Final status====\n\nA soft-fork BIP strictly requires a clear miner majority expressed by blockchain voting (eg, using BIP 9). In addition, if the economy seems willing to make a \"no confidence\" hard-fork (such as a change in proof-of-work algorithm), the soft-fork does not become Final for as long as such a hard-fork might have majority support, or at most three months. Soft-fork BIPs may also set additional requirements for their adoption. Because of the possibility of changes to miner dynamics, especially in light of delegated voting (mining pools), it is highly recommended that a supermajority vote around 95% be required by the BIP itself, unless rationale is given for a lower threshold.\n\nA hard-fork BIP requires adoption from the entire Bitcoin economy, particularly including those selling desirable goods and services in exchange for bitcoin payments, as well as Bitcoin holders who wish to spend or would spend their bitcoins (including selling for other currencies) differently in the event of such a hard-fork. Adoption must be expressed by de facto usage of the hard-fork in practice (ie, not merely expressing public support, although that is a good step to establish agreement before adoption of the BIP). This economic adoption cannot be established merely by a super-majority, except by literally forcing the minority to accept the hard-fork (whether this is viable or not is outside the scope of this document).\n\nPeer services BIPs should be observed to be adopted by at least 1% of public listening nodes for one month.\n\nAPI/RPC and application layer BIPs must be implemented by at least two independent and compatible software applications.\n\nSoftware authors are encouraged to publish summaries of what BIPs their software supports to aid in verification of status changes. Good examples of this at the time of writing this BIP, can be observed in [https://github.com/bitcoin/bitcoin/blob/master/doc/bips.md Bitcoin Core's doc/bips.md file] as well as [https://github.com/bitcoin-wallet/bitcoin-wallet/blob/master/wallet/README.specs.md Bitcoin Wallet for Android's wallet/README.specs.md file].\n\nThese criteria are considered objective ways to observe the de facto adoption of the BIP, and are not to be used as reasons to oppose or reject a BIP. Should a BIP become actually and unambiguously adopted despite not meeting the criteria outlined here, it should still be updated to Final status.\n\n===Rationale===\n\nWhy is this necessary at all?\n\n* BIP 1 defines an ambiguous criteria for the Status field of BIPs, which is often a source of confusion. As a result, many BIPs with significant real-world use have been left as Draft or Proposed status longer than appropriate. By giving objective criteria to judge the progression of BIPs, this proposal aims to help keep the Status accurate and up-to-date.\n\nHow is the entire Bitcoin economy defined by people selling goods/services and holders?\n\n* For Bitcoin to function as a currency, it must be accepted as payment. Bitcoins have no value if you cannot acquire anything in exchange for them. If everyone accepting such payments requires a particular set of consensus rules, \"bitcoins\" are de facto defined by that set of rules - this is already the case today. If those consensus rules are expected to broaden (as with a hard-fork), those merchants need to accept payments made under the new set of rules, or they will reject \"bitcoins\" as invalid. Holders are relevant to the degree in that they choose the merchants they wish to spend their bitcoins with, and could also as a whole decide to sell under one set of consensus rules or the other, thus flooding the market with bitcoins and crashing the price.\n\nWhy aren't included in the economy?\n\n* Some entities may, to some degree, also be involved in offering goods and/or services in exchange for bitcoins, thus in that capacity (but not their capacity as ) be involved in the economy.\n* Miners are not included in the economy, because they merely *rely on* others to sell/spend their otherwise-worthless mined produce. Therefore, they must accept everyone else's direction in deciding the consensus rules.\n* Exchanges are not included in the economy, because they merely provide services of connecting the merchants and users who wish to trade. Even if all exchanges were to defect from Bitcoin, those merchants and users can always trade directly and/or establish their own exchanges.\n* Developers are not included in the economy, since they merely write code, and it is up to others to decide to use that code or not.\n\nBut they're doing something important and have invested a lot in Bitcoin! Shouldn't they be included in such an important decision?\n\n* This BIP does not aim to address what \"should\" be the basis of decisions. Such a statement, no matter how perfect in its justification, would be futile without some way to force others to use it. The BIP process does not aim to be a kind of forceful \"governance\" of Bitcoin, merely to provide a collaborative repository for proposing and providing information on standards, which people may voluntarily adopt or not. It can only hope to achieve accuracy in regard to the \"Status\" field by striving to reflect the reality of *how things actually are*, rather than *how they should be*.\n\nWhat if a single merchant wishes to block a hard-fork?\n\n* This BIP addresses only the progression of the BIP Status field, not the deployment of the hard-fork (or any other change) itself.\n* Regardless, one shop cannot operate in a vacuum: if they are indeed alone, they will soon find themselves no longer selling in exchange for bitcoin payments, as nobody else would exist willing to use the previous blockchain to pay them. If they are no longer selling, they cease to meet the criteria herein which enables their veto.\n\nHow about a small number of merchants (maybe only two) who sell products to each other?\n\n* In this scenario, it would seem the previous Bitcoin is alive and working, and that the hard-fork has failed. How to resolve such a split is outside the scope of this BIP.\n\nHow can economic agreement veto a soft-fork?\n\n* The group of miners is determined by the consensus rules for the dynamic-membership multi-party signature (for Bitcoin, the proof-of-work algorithm), which can be modified with a hard-fork. Thus, if the same conditions required to modify this group are met in opposition to a soft-fork, the miner majority supporting the soft-fork is effectively void because the economy can decide to replace them with another group of would-be miners who do not support the soft-fork.\n\nWhat happens if the economy decides to hard-fork away from a controversial soft-fork, more than three months later?\n\n* The controversial soft-fork, in this circumstance, changes from Final to Replaced status to reflect the nature of the hard-fork replacing the previous (final) soft-fork.\n\nWhat is the ideal percentage of listening nodes needed to adopt peer services proposals?\n\n* This is unknown, and set rather arbitrarily at this time. For a random selection of peers to have at least one other peer implementing the extension, 13% or more would be necessary, but nodes could continue to scan the network for such peers with perhaps some reasonable success. Furthermore, service bits exist to help identification upfront.\n\nWhy is it necessary for at least two software projects to release an implementation of API/RPC and application layer BIPs, before they become Final?\n\n* If there is only one implementation of a specification, there is no other program for which a standard interface is used with or needed.\n* Even if there are only two projects rather than more, some standard coordination between them exists.\n\nWhat if a BIP is proposed that only makes sense for a single specific project?\n\n* The BIP process exists for standardisation between independent projects. If something only affects one project, it should be done through that project's own internal processes, and never be proposed as a BIP in the first place.\n\n==BIP comments==\n\n===Specification===\n\nEach BIP should, in its preamble, link to a public wiki page with a summary tone of the comments on that page.\nReviewers of the BIP who consider themselves qualified, should post their own comments on this wiki page.\nThe comments page should generally only be used to post final comments for a completed BIP.\nIf a BIP is not yet completed, reviewers should instead post on the applicable development mailing list thread to allow the BIP author(s) to address any concerns or problems pointed out by the review.\n\nSome BIPs receive exposure outside the development community prior to completion, and other BIPs might not be completed at all. To avoid a situation where critical BIP reviews may go unnoticed during this period, reviewers may, at their option, still post their review on the comments page, provided they first post it to the mailing list and plan to later remove or revise it as applicable based on the completed version. Such revisions should be made by editing the previous review and updating the timestamp. Reviews made prior to the complete version may be removed if they are no longer applicable and have not been updated in a timely manner (eg, within one month).\n\nPages must be named after the full BIP number (eg, \"BIP 0001\") and placed in the \"Comments\" namespace.\nFor example, the link for BIP 1 will be https://github.com/bitcoin/bips/wiki/Comments:BIP-0001 .\n\nComments posted to this wiki should use the following format:\n\n --, \n\nBIPs may also choose to list a second forum for BIP comments, in addition to the BIPs wiki.\nIn this case, the second forum's URI should be listed below the primary wiki's URI.\n\nAfter some time, the BIP itself may be updated with a summary tone of the comments.\nSummary tones may be chosen from the following, but this BIP does not intend to cover all possible nuances and other summaries may be used as needed:\n\n* No comments yet.\n* Unanimously Recommended for implementation\n* Unanimously Discourage for implementation\n* Mostly Recommended for implementation, with some Discouragement\n* Mostly Discouraged for implementation, with some Recommendation\n\nFor example, the preamble to BIP 1 might be updated to include the line:\n\n Comments-Summary: No comments yet.\n Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0001\n https://some-other-wiki.org/BIP_1_Comments\n\nThese fields must follow the \"Discussions-To\" header defined in BIP 1 (if that header is not present, it should follow the position where it would be present; generally this is immediately above the Status header).\n\nTo avoid doubt: comments and status are unrelated metrics to judge a BIP, and neither should be directly influencing the other.\n\n===Rationale===\n\nWhat is the purpose of BIP comments?\n\n* Various BIPs have been adopted (the criteria required for \"Final\" Status) despite being considered generally inadvisable. Some presently regard BIPs as a \"good idea\" simply by virtue of them being assigned a BIP number. Due to the low barrier of entry for submission of new BIPs, it seems advisable for a way for reviewers to express their opinions on them in a way that is consumable to the public without needing to review the entire development discussion.\n\nWill BIP comments be censored or limited to particular participants/\"experts\"?\n\n* Participants should freely refrain from commenting outside of their area of knowledge or expertise. However, comments should not be censored, and participation should be open to the public.\n\n==BIP licensing==\n\n===Specification===\n\nNew BIPs may be accepted with the following licenses. Each new BIP must identify at least one acceptable license in its preamble. The License header in the preamble must be placed after the Created header. Each license must be referenced by their respective abbreviation given below.\n\nFor example, a preamble might include the following License header:\n\n License: BSD-2-Clause\n GNU-All-Permissive\n\nIn this case, the BIP text is fully licensed under both the OSI-approved BSD 2-clause license as well as the GNU All-Permissive License, and anyone may modify and redistribute the text provided they comply with the terms of *either* license. In other words, the license list is an \"OR choice\", not an \"AND also\" requirement.\n\nIt is also possible to license source code differently from the BIP text. An optional License-Code header is placed after the License header. Again, each license must be referenced by their respective abbreviation given below.\n\nFor example, a preamble specifying the optional License-Code header might look like:\n\n License: BSD-2-Clause\n GNU-All-Permissive\n License-Code: GPL-2.0+\n\nIn this case, the code in the BIP is not available under the BSD or All-Permissive licenses, but only under the terms of the GNU General Public License (GPL), version 2 or newer.\nIf the code were to be available under *only* version 2 exactly, the \"+\" symbol should be removed from the license abbreviation.\nFor a later version (eg, GPL 3.0), you would increase the version number (and retain or remove the \"+\" depending on intent).\n\n License-Code: GPL-2.0 # This refers to GPL v2.0 *only*, no later license versions are acceptable.\n License-Code: GPL-2.0+ # This refers to GPL v2.0 *or later*.\n License-Code: GPL-3.0 # This refers to GPL v3.0 *only*, no later license versions are acceptable.\n License-Code: GPL-3.0+ # This refers to GPL v3.0 *or later*.\n\nIn the event that the licensing for the text or code is too complicated to express with a simple list of alternatives, the list should instead be replaced with the single term \"Complex\". In all cases, details of the licensing terms must be provided in the Copyright section of the BIP.\n\nBIPs are not required to be *exclusively* licensed under approved terms, and may also be licensed under unacceptable licenses *in addition to* at least one acceptable license.\nIn this case, only the acceptable license(s) should be listed in the License and License-Code headers.\n\n====Recommended licenses====\n\n* BSD-2-Clause: [https://opensource.org/license/BSD-2-Clause OSI-approved BSD 2-clause license]\n* BSD-3-Clause: [https://opensource.org/license/BSD-3-Clause OSI-approved BSD 3-clause license]\n* CC0-1.0: [https://creativecommons.org/publicdomain/zero/1.0/ Creative Commons CC0 1.0 Universal]\n* FSFAP: [https://www.gnu.org/prep/maintain/html_node/License-Notices-for-Other-Files.html FSF All Permissive License]\n\nIn addition, it is recommended that literal code included in the BIP be dual-licensed under the same license terms as the project it modifies. For example, literal code intended for Bitcoin Core would ideally be dual-licensed under the MIT license terms as well as one of the above with the rest of the BIP text.\n\n====Not recommended, but acceptable licenses====\n\n* Apache-2.0: [https://www.apache.org/licenses/LICENSE-2.0 Apache License, version 2.0]\n* BSL-1.0: [https://www.boost.org/LICENSE_1_0.txt Boost Software License, version 1.0]\n* CC-BY-4.0: [https://creativecommons.org/licenses/by/4.0/ Creative Commons Attribution 4.0 International]\n* CC-BY-SA-4.0: [https://creativecommons.org/licenses/by-sa/4.0/ Creative Commons Attribution-ShareAlike 4.0 International]\n* MIT: [https://opensource.org/license/MIT The MIT License]\n* AGPL-3.0+: [https://www.gnu.org/licenses/agpl-3.0.en.html GNU Affero General Public License (AGPL), version 3 or newer]\n* FDL-1.3: [https://www.gnu.org/licenses/fdl-1.3.en.html GNU Free Documentation License, version 1.3]\n* GPL-2.0+: [https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html GNU General Public License (GPL), version 2 or newer]\n* LGPL-2.1+: [https://www.gnu.org/licenses/old-licenses/lgpl-2.1.en.html GNU Lesser General Public License (LGPL), version 2.1 or newer]\n\n====Not acceptable licenses====\n\nAll licenses not explicitly included in the above lists are not acceptable terms for a Bitcoin Improvement Proposal unless a later BIP extends this one to add them.\nHowever, BIPs predating the acceptance of this BIP were allowed under other terms, and should use these abbreviation when no other license is granted:\n\n* OPUBL-1.0: [https://opencontent.org/openpub/ Open Publication License, version 1.0]\n* PD: Released into the public domain\n\n===Rationale===\n\nBIP 1 allowed the Open Publication License or releasing into the public domain; was this insufficient?\n\n* The OPUBL-1.0 is generally regarded as obsolete, and not a license suitable for new publications.\n* Many are unfamiliar with the OPUBL-1.0 terms, and may just prefer to use the public domain rather than license under uncertain terms.\n* The OPUBL-1.0 license terms allowed for the author to prevent publication and derived works, which was widely considered inappropriate for Bitcoin standards.\n* Public domain is not universally recognised as a legitimate action, thus it is inadvisable.\n\nWhy are there software licenses included?\n\n* Some BIPs, especially consensus layer, may include literal code in the BIP itself which may not be available under the exact license terms of the BIP.\n* Despite this, not all software licenses would be acceptable for content included in BIPs.\n\nWhy is Public Domain no longer acceptable for new BIPs?\n\n* In some jurisdictions, public domain is not recognised as a legitimate legal action, leaving the BIP simply copyrighted with no redistribution or modification allowed at all.\n\n==Changes from BIP 1==\n\n* Acceptable licenses are entirely rechosen, allowing a wide variety of open licenses, while prohibiting the problematic older choices.\n* Accepted Status has been renamed to Proposed.\n* An implementation is now required (when applicable) before BIPs can proceed to Proposed Status.\n* BIP Comments are newly introduced.\n* The License preamble headers have been added.\n* The Layer header is included from BIP 123.\n* Non-image auxiliary files are permitted in the bip-XXXX subdirectory.\n* Email addresses are now required for authors.\n* The Post-History header may be provided as a link instead of a simple date.\n* The Resolution header has been dropped, as it is not applicable to a decentralised system where no authority exists to make final decisions.\n\n==See Also==\n\n* [[bip-0001.mediawiki|BIP 1: BIP Purpose and Guidelines]]\n* [[bip-0123.mediawiki|BIP 123: BIP Classification]]\n* [https://tools.ietf.org/html/rfc7282 RFC 7282: On Consensus and Humming in the IETF]", "category": "bips" }, { "instruction": "I want to understand 
 from a technical perspective",
    "input": "",
    "output": "BIP: 81\n  Title: Hierarchy for Colored Voting Pool Deterministic Multisig Wallets\n  Authors: Justus Ranvier \n           Jimmy Song \n  Status: Closed\n  Type: Informational\n  Assigned: 2014-08-11\n  License: PD\n
\n\n==Abstract==\n\nThis BIP defines a logical hierarchy for colored coin voting pool deterministic multisig wallets based on an algorithm described in BIP-0032 (BIP32 from now on) and purpose scheme described in BIP-0043 (BIP43 from now on).\n\nThis BIP is a particular application of BIP43 and is based on BIP44.\n\n==Motivation==\n\nThe hierarchy proposed in this paper allows the handling of multiple color definitions from a single seed.\n\n==Path levels==\n\nWe define the following 8 levels in BIP32 path:\n\n
\nm / purpose' / series' / (5 color definition levels) / address_index\n
\n\nApostrophe in the path indicates that BIP32 hardened derivation is used.\n\nEach level has a special meaning, described in the chapters below.\n\n===Purpose===\n\nPurpose is a constant set following the BIP43 recommendation to: the ASCII value of \"81\" with the most significant bit set to indicate hardened derivation (0x80000051). It indicates that the subtree of this node is used according to this specification.\n\nHardened derivation is used at this level.\n\n===Color Definition===\n\nIndex values which can be applied to a BIP32 node are limited to 4 bytes (32 bits).\n\nSince this is not sufficient to identify color definitions without a risk of collision, multiple levels are used.\n\nColor definitions are first shortened to 20 bytes using the Bitcoin hash160 function.\n\nThe resulting 20 bytes are split into five groups in little endian format, and where each group is used as the seed for the five levels of color definition levels\n\nPublic derivation is used at these levels, even when the index exceeds 2^31.\n\n===Index===\n\nPublic/private keypairs are numbered from index 0 in sequentially increasing manner. This number is used as child index in BIP32 derivation.\n\nPublic keys obtained at this level of the hierarchy are used to construct multisig deposit scripts, using a schema that is shared between the members as an out-of-band contract.\n\nPublic derivation is used at this level.\n\n==Compatible wallets==\n\n* [[https://github.com/btcsuite/btcwallet|btcwallet]] is the reference Bitcoin wallet for voting pools.\n\n==Copyright==\n\nThis document is placed in the public domain.\n\n==Reference==\n\n* [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]]\n* [[bip-0043.mediawiki|BIP43 - Purpose Field for Deterministic Wallets]]\n* [[bip-0044.mediawiki|BIP44 - Multi-Account Hierarchy for Deterministic Wallets]]\n* [[bip-0080.mediawiki|BIP80 - Hierarchy for Non-Colored Voting Pool Deterministic Multisig Wallets]]", "category": "bips" }, { "instruction": "Can you explain 
 like we're having a beer and talking Bitcoin?",
    "input": "",
    "output": "BIP: 140\n  Layer: Consensus (soft fork)\n  Title: Normalized TXID\n  Authors: Christian Decker \n  Status: Closed\n  Type: Specification\n  Assigned: 2015-10-14\n  License: PD\n
\n\n== Abstract ==\n\nThis BIP describes the use of normalized transaction IDs (NTXIDs) in order to eliminate transaction malleability, both in the third-party modification scenario as well as the participant modification scenario. The transaction ID is normalized by removing the signature scripts from transactions before computing its hash. The normalized transaction hashes are then used during the signature creation and signature verification of dependent transactions.\n\n== Motivation ==\n\nTransaction malleability refers to the fact that transactions can be modified, either by one of the signers by re-signing the transaction or a third-party by modifying the signature representation. This is a problem since any modification to the serialized representation also changes the hash of the transaction, which is used by spending transaction to reference the funds that are being transferred. If a transaction is modified and later confirmed by ending up in the blockchain all transactions that depended on the original transaction are no longer valid, and thus orphaned.\n\nBIPs 62[[https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki|BIP 62 - Dealing with malleability]] and 66[[https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki|BIP 66 - Strict DER signatures]] alleviate the problem of third-party modification by defining a canonical representation of the signatures. However, checking the canonical representation is complex and may not eliminate all sources of third-party malleability. Furthermore, these BIPs do not address modifications by one of the signers, i.e., re-signing the transaction, because signers can produce any number of signatures due to the random parameter in ECDSA.\n\nThis proposal eliminates malleability by removing the malleable signatures from the hash used to reference the outputs spent by a transaction. The new hash used to reference an output is called the ''normalized transaction ID''. The integrity of all data that is used to reference the output is guaranteed by the signature itself, and any modification that would change the normalized transaction ID would also invalidate the signature itself.\n\nBesides eliminating transaction malleability as a source of problems it also allows the use of transaction templates. Transaction templates simplify higher level protocols and allows new uses. They allow an unsigned template transaction to be used as a basis for a sequence of transaction and only once the sequence matches the signers' expectations they provide the necessary signatures for the template to become valid, thus opting in to the sequence.\n\n== Specification ==\n\nThe use of normalized transaction IDs is introduced as a softfork. The specification is divided into three parts:\n\n* Computation of the normalized transaction ID\n* Introduction of a new extensible signature verification opcode to enable softfork deployment\n* Changes to the UTXO tracking to enable normalized transaction ID lookup\n\n=== Normalized Transaction ID computation ===\n\nIn order to calculate the normalized transaction ID, the signature script is stripped from each input of the transaction of non-coinbase transactions and each input is normalized. Stripping the signature script is achieved by setting the script's length to 0 and removing the uchar[] array from the TxIn.[[https://en.bitcoin.it/wiki/Protocol_Specification#tx|Protocol Specification: TX]]\nInputs are then normalized by replacing the hash of each previous transaction with its normalized version if available, i.e., the normalized hash of the previous transaction that created the output being spent in the current transaction. Version 1 transactions do not have a normalized transaction ID hence the non-normalized transaction ID is used for input normalization.\n\nThe normalized transaction ID is then computed as the double SHA 256 hash of the normalized transaction matching the existing transaction ID computation. The normalized transaction ID remains unchanged even if the signatures of the transaction are replaced/malleated and describe a class of semantically identical transactions. In the following we use ''transaction instance ID'' to refer to the transaction ID computed on the transaction including signatures. Normalized transaction IDs for coinbase transactions are computed with the signature script in the coinbase input, in order to avoid hash collisions.\n\n=== OP_CHECKSIGEX ===\nThis BIP introduces a new opcode OP_CHECKSIGEX which replaces OP_NOP4. OP_CHECKSIGEX subsumes OP_CHECKSIGVERIFY and OP_CHECKMULTISIGVERIFY, and extends them by accepting a new VERSION parameter. The version parameter is a single integer pushed onto the stack before invoking OP_CHECKSIGEX and is used to group and evolve future versions of signature checking opcodes.\n\nWhen executed OP_CHECKSIGEX pops the version from the stack and then performs the signature check according to the specified version. If the verifying client does not support the specified version, i.e., the version was defined after the release of the client, the client must treat the OP_CHECKSIGEX as an OP_NOP.\n\n==== Version 1 ====\n\nThe first version of OP_CHECKSIGEX (VERSION=1) implements normalized transaction IDs and uses Schnorr signatures instead of the current ECDSA signatures.\n\nVersion 1 introduces the following new standard script format:\n\n m {pubkey}...{pubkey} n v OP_CHECKSIGEX\n\nwith matching scriptSig format:\n\n {signature}...{signature}\n\nThis is the standard ''m-of-n'' script defined in [https://github.com/bitcoin/bips/blob/master/bip-0011.mediawiki BIP 11] with an additional version parameter v and the new opcode. Singlesig transactions are encoded as ''1-of-1'' transactions.\n\nThe existing OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY have a bug[[https://bitcoin.org/en/developer-guide#multisig|Developer Documentation - Multisig]] that pops one argument too many from the stack. This bug is not reproduced in the implementation of OP_CHECKSIGEX, so the canonical solution of pushing a dummy value onto the stack is not necessary.\n\nThe normalization is achieved by normalizing the transaction before computing the signaturehash, i.e., the hash that is signed.\nThe transaction must be normalized by replacing all transaction IDs in the inputs by their normalized variants and stripping the signature scripts. The normalized transaction IDs are computed as described in the previous section. This normalization step is performed both when creating the signatures as well as when checking the signatures.\n\n=== Tracking Normalized Transaction IDs ===\n\nThe transaction version is bumped to 2. The new version signals to clients receiving the transaction that they should track the normalized transaction ID along with the transaction instance ID in the unspent transaction output (UTXO) set. Upon receiving a version 2 transaction the client computes the normalized transaction ID, annotates the outputs with it, and adds them into the UTXO set indexed by the transaction instance ID as before. Transactions continue using the transaction instance ID to reference the outputs, but while checking the signature they may get normalized. All network messages continue to use the transaction instance ID to reference the transaction, specifically inv, getdata, tx and block messages still use transaction instance IDs, not the normalized transaction IDs.\n\nOutputs created by version 1 transactions are not annotated with the normalized transaction ID, and when normalizing the hashes in transaction inputs referencing version 1 outputs are not modified.\n\n== Rationale ==\n\n=== Normalization ===\nNormalized transaction IDs are provably non-malleable since no data is included in the signaturehash whose integrity is not also proven in the signature, thus any modification causing the hash to change will also invalidate the signature.\nNormalized transactions are secure as they still use cryptographic hashes over all the semantic information of the transaction, i.e., the inputs, outputs and metadata, thus it is still computationally infeasible to cause a hash collision between transactions.\n\nThere are a number of advantages to using normalized transaction IDs:\n\n* Like BIP 62 and BIP 66 it solves the problem of third-parties picking transactions out of the network, modifying them and reinjecting them.\n* ''m-of-n'' multisig outputs are often used in higher level protocols[[http://www.tik.ee.ethz.ch/file/716b955c130e6c703fac336ea17b1670/duplex-micropayment-channels.pdf|A Fast and Scalable Payment Network with Bitcoin Duplex Micropayment Channels ]][[http://lightning.network/lightning-network-paper.pdf|The Bitcoin Lightning Network:\nScalable Off-Chain Instant Payments]] in which several parties sign a transaction. Without normalized transaction IDs it is trivial for one party to re-sign a transaction, hence changing the transaction hash and invalidating any transaction built on top of its outputs. Normalized transaction IDs force the ID not to change, even if a party replaces its signature.\n* Many higher level protocols build structures of transactions on top of multisig outputs that are not completely signed. This is currently not possible without one party holding a fully signed transaction and then calculating the ID. It is desirable to be able to build successive transactions without one party collecting all signatures, and thus possibly lock in funds unilaterally. Normalized transaction IDs allow the use of transaction templates, i.e., completely unsigned transactions upon which further transactions can be built, and only once every party is assured the structure matches its expectations it signs the template, thus validating the template.\n\nThe only occurrence in which transactions can still be modified unilaterally is in the case SIGHASH_NONE, SIGHASH_SINGLE or SIGHASH_ANYONECANPAY is used. This however is not problematic since in these cases the creator of the transaction explicitly allows modification.\n\nIn case of a transaction becoming invalid due to one of the inputs being malleated it is necessary to modify the spending transaction to reference the modified transaction ID. However, the signatures, which only use the normalized IDs, remain valid as long as the semantics of the funding transaction remain unchanged. An observer in the network may fix the transaction and reinject a corrected version.\n\nUsing version 2 for transactions is an explicit opt-in to the normalized ID tracking and a simple upgrade for existing clients. It avoids having to reprocess the entire blockchain and computing the normalized transaction IDs for existing outputs in the UTXO. This would be further complicated by having to recursively compute normalized transaction IDs down to the coinbase transactions which created the coins.\n\nTracking the normalized transaction IDs in the UTXO requires the storage of an additional hash per transaction whose outputs are not completely spent, which at 7,000,000 transactions with unspent outputs amounts to 224MB additional storage on disk.\n\nThe coinbase transactions have been checked for hash-collisions and no collisions were found except for the coinbase transactions in blocks at heights 91842 and 91880, which are known to be identical[[https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki|BIP 30 - Duplicate transactions]], and motivated the introduction of BIP 34.[[https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki|Block v2, Height in Coinbase]] Since coinbase transactions are invalid if transmitted outside of a block it is not possible to modify them on the fly and since they only mature after being included for a long time in the blockchain they are considered safe.\n\n=== OP_CHECKSIGEX ===\n\nThe new opcode OP_CHECKSIGEX was introduced in order to allow the use of normalized transaction IDs as a softfork and in order to keep the number of OP_NOPs needed to a bare minimum, while enabling future soft-fork updates to the signing algorithms.\n\nThe additional argument containing the version can be pushed on the stack using a single byte up to version 16 (OP_1 - OP_16), resulting in one byte overhead for this script type. Using the standard multisig format also for 1-of-1 transactions add an additional 2 bytes, however it also removes the bug requiring a dummy push, resulting in a single byte overhead.\nFurthermore, using Schnorr signatures instead of ECDSA brings a number of improvements that reduce the size of transactions (''m-of-m'' is the same size as ''1-of-1'') and increase verification speed (batch signature validation by summing up keys and signatures). The code is already in bitcoin/secp256k1 and can be merged in. We limited the description of this BIP to re-using BIP 11 style ''m-of-n'' scripts to keep it short, however Schnorr also allows a number of more complex applications which we defer to future BIPs.\n\nVersion 0 was intentionally skipped in order to guarantee that the top-most element before OP_CHECKSIGEX is non-zero. This is necessary to guarantee that non-upgraded clients, which interpret OP_CHECKSIGEX as OP_NOP4, do not end up with a zero value on top of the stack after execution, which would be interpreted as script failure.\n\n=== Impact ===\n\nThis is a softfork which replaces OP_NOP4 with the new implementation of OP_CHECKSIGEX, as such the impact on the network is minimal. Wallets that do not implement this opcode will not be able to verify the validity of the scripts, however if transactions using OP_CHECKSIGEX are included in blocks they will accept them and track the inputs correctly. This is guaranteed since the transaction inputs still use the non-normalized transaction ID to reference the outputs to be claimed, hence non-upgraded wallets can still lookup the outputs and mark them as spent. Furthermore, clients that do not implement this BIP are unable to identify outputs using this script as their own, however upgrading and rescanning the blockchain will make them available.\n\n== See also ==\n\n* [[bip-0062.mediawiki|BIP 62: Dealing with malleability]]\n* [[bip-0066.mediawiki|BIP 66: Strict DER Signatures]]\n\n== References ==\n\n\n==Copyright==\nThis document is placed in the public domain.", "category": "bips" }, { "instruction": "How would you explain 
 to someone who knows Bitcoin basics?",
    "input": "",
    "output": "BIP: 343\n  Layer: Consensus (soft fork)\n  Title: Mandatory activation of taproot deployment\n  Authors: Shinobius \n           Michael Folkson \n  Status: Deployed\n  Type: Specification\n  Assigned: 2021-04-25\n  License: BSD-3-Clause OR CC0-1.0\n
\n\n==Abstract==\n\nThis document specifies a BIP8 (LOT=true) deployment to activate taproot.\n\n==Motivation==\n\nThe Taproot soft fork upgrade has been assessed to have overwhelming community consensus and hence should attempt to be activated. Lessons have been learned from the BIP148 and BIP91 deployments in 2017 with regards to giving many months of advance warning before the mandatory signaling is attempted. The mandatory signaling is only required if miners have failed to meet the signaling threshold during the BIP8 deployment. It is important that mandatory signaling is included as without it miners would effectively have the ability to indefinitely block the activation of a soft fork with overwhelming consensus.\n\n==Specification==\n\nThis BIP will begin an activation signaling period using bit 2 at blockheight 681408 with a minimum activation height of 709632 and an activation threshold of 90%. The signaling period will timeout at blockheight 760032 with a latest activation height of 762048. Lockinontimeout (LOT) is set to true so mandatory signaling will be enforced in the last signaling period before the timeout height. Blocks without the signaling bit 2 set run the risk of being rejected during this period if taproot is not locked in prior. This BIP will cease to be active when taproot is locked in.\n\n==Reference implementation==\n\n*[[https://github.com/BitcoinActivation/bitcoin]]\n\n==Backward Compatibility==\n\nAs 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. They are strongly encouraged to upgrade in order to fully validate the new programs.\n\n==Compatibility with later alternative activations==\n\nThe activation mechanism “Speedy Trial” as proposed by Russell O’Connor and outlined in this bitcoin-dev mailing list [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018583.html post] by David Harding was released in Bitcoin Core. It is effectively a BIP8 activation mechanism with one exception: start height and timeout height were defined using median time past (MTP) rather than block heights. It uses signaling bit 2, was deployed between midnight April 24th 2021 and midnight August 11th 2021, has a minimum activation height of 709632 and intends to activate BIPs 340, 341, and 342. The BIP8(LOT=true) deployment is compatible with the “Speedy Trial” deployment in Bitcoin Core as there was not a discrepancy between MTP and block height for the defined start heights.\n\nThe BIP8 (LOT=true) deployment has also been deliberately designed to be compatible with a future BIP8(LOT=false) or BIP8(LOT=true) deployment in Bitcoin Core assuming Bitcoin Core releases one of these activation mechanisms in the event of the Speedy Trial deployment failing to activate.\n\n==Rationale==\n\nThe deployment of BIP148 demonstrated that multiple implementations with different activation mechanisms can incentivize the necessary actors to act so that the different deployments activate in sync. A BIP8 LOT=true deployment can run in parallel with other BIP8 activation mechanisms that have eventual mandatory signaling or no mandatory signaling. Eventual mandatory signaling ensures that miners cannot prevent the activation of a desired feature with community consensus indefinitely.\n\n==Acknowledgements==\n\nThanks to Shaolin Fry and Luke Dashjr for their work on BIP148 and BIP8 which were important prerequisites for this proposal.\n\n==References==\n\n*[[bip-0008.mediawiki|BIP8 Version bits with lock-in by height]]\n*[[bip-0148.mediawiki|BIP148 Mandatory activation of segwit deployment]]\n*[[bip-0340.mediawiki|BIP340 Schnorr Signatures for secp256k1]]\n*[[bip-0341.mediawiki|BIP341 Taproot: SegWit version 1 spending rules]]\n*[[bip-0342.mediawiki|BIP342 Validation of Taproot Scripts]]\n*[https://taproot.works/taproot-faq/ Taproot benefits]\n\n==Copyright==\n\nThis document is dual licensed as BSD 3-clause, and Creative Commons CC0 1.0 Universal.", "category": "bips" }, { "instruction": "I'm trying to understand 
 - can you walk me through it?",
    "input": "",
    "output": "BIP: 98\n  Layer: Consensus (soft fork)\n  Title: Fast Merkle Trees\n  Authors: Mark Friedenbach \n           Kalle Alm \n           BtcDrak \n  Status: Draft\n  Type: Specification\n  Assigned: 2017-08-24\n  License: CC-BY-SA-4.0\n  License-Code: MIT\n
\n\n==Abstract==\n\nIn many applications it is useful to prove membership of a data element in a set without having to reveal the entire contents of that set.\nThe Merkle hash-tree, where inner/non-leaf nodes are labeled with the hash of the labels or values of its children, is a cryptographic tool that achieves this goal.\nBitcoin uses a Merkle hash-tree construct for committing the transactions of a block into the block header.\nThis particular design, created by Satoshi, suffers from a serious flaw related to duplicate entries documented in the National Vulnerability Database as CVE-2012-2459[1], and also suffers from less than optimal performance due to unnecessary double-hashing.\n\nThis Bitcoin Improvement Proposal describes a more efficient Merkle hash-tree construct that is not vulnerable to CVE-2012-2459\nand achieves an approximate 55% decrease in hash-tree construction and validation times as compared with fully optimized implementations of the Satoshi Merkle hash-tree construct.\n\n==Copyright==\n\nThis BIP is licensed under a Creative Commons Attribution-ShareAlike license. All provided source code is licensed under the MIT license.\n\n==Motivation==\n\nA Merkle hash-tree is a directed acyclic graph data structure where all non-terminal nodes are labeled with the hash of combined labels or values of the node(s) it is connected to.\nBitcoin uses a unique Merkle hash-tree construct invented by Satoshi for calculating the block header commitment to the list of transactions in a block.\nWhile it would be convenient for new applications to make use of this same data structure so as to share implementation and maintenance costs, there are three principal drawbacks to reuse.\n\nFirst, Satoshi's Merkle hash-tree has a serious vulnerability[1] related to duplicate tree entries that can cause bugs in protocols that use it.\nWhile it is possible to secure protocols and implementations against exploit of this flaw, it requires foresight and it is a bit more tricky to design secure protocols that work around this vulnerability.\nDesigners of new protocols ought avoid using the Satoshi Merkle hash-tree construct where at all possible in order to responsibly decrease the likelihood of downstream bugs in naïve implementations.\n\nSecond, Satoshi's Merkle hash-tree performs an unnecessary number of cryptographic hash function compression rounds, resulting in construction and validation times that are approximately three (3) times more computation than is strictly necessary in a naïve implementation, or 2.32x more computation in an implementation specialized for this purpose only[2].\nNew implementations that do not require backwards compatibility ought to consider hash-tree implementations that do not carry this unnecessary performance hit.\n\nThird, Satoshi's algorithm presumes construction of a tree index from an ordered list, and therefore is designed to support balanced trees with a uniform path length from root to leaf for all elements in the tree.\nMany applications, on the other hand, benefit from having unbalanced trees, particularly if the shorter path is more likely to be used.\nWhile it is possible to make a few elements of a Satoshi hash-tree have shorter paths than the others, the tricks for doing so are dependent on the size of the tree and not very flexible.\n\nTogether these three reasons provide justification for specifying a standard Merkle hash-tree structure for use in new protocols that fixes these issues.\nThis BIP describes such a structure, and provides an example implementation.\n\n==Specification==\n\nA Merkle hash-tree as defined by this BIP is an arbitrarily-balanced binary tree whose terminal/leaf nodes are labelled with the double-SHA256 hashes of data, whose format is outside the scope of this BIP, and inner nodes with labels constructed from the fast-SHA256 hash of its children's labels.\nThe following image depicts an example unbalanced hash-tree:\n\n:: [[File:bip-0098/unbalanced-hash-tree.png]]\n\n'''A''', '''B''', and '''C''' are leaf labels, 32-byte double-SHA256 hashes of the data associated with the leaf.\n'''Node''' and '''Root''' are inner nodes, whose labels are fast-SHA256 (defined below) hashes of their respective children's labels.\n'''Node''' is labelled with the fast-SHA256 hash of the concatenation of '''B''' and '''C'''.\n'''Root''' is labelled with the fast-SHA256 hash of the concatenation of '''A''' and '''Node''', and is the ''Merkle root'' of the tree.\nNodes with single children are not allowed.\n\nThe ''double-SHA256'' cryptographic hash function takes an arbitrary-length data as input and produces a 32-byte hash by running the data through the SHA-256 hash function as specified in FIPS 180-4[3], and then running the same hash function again on the 32-byte result, as a protection against length-extension attacks.\n\nThe ''fast-SHA256'' cryptographic hash function takes two 32-byte hash values, concatenates these to produce a 64-byte buffer, and applies a single run of the SHA-256 hash function with a custom 'initialization vector' (IV) and without message padding.\nThe result is a 32-byte 'midstate' which is the combined hash value and the label of the inner node.\nThe changed IV protects against path-length extension attacks (grinding to interpret a hash as both an inner node and a leaf).\nfast-SHA256 is only defined for two 32-byte inputs.\nThe custom IV is the intermediate hash value generated after performing a standard SHA-256 of the following hex-encoded bytes and extracting the midstate:\n\n cbbb9d5dc1059ed8 e7730eaff25e24a3 f367f2fc266a0373 fe7a4d34486d08ae\n d41670a136851f32 663914b66b4b3c23 1b9e3d7740a60887 63c11d86d446cb1c\n\nThis data is the first 512 fractional bits of the square root of 23, the 9th prime number.\nThe resulting midstate is used as IV for the fast-SHA256 cryptographic hash function:\n\n static unsigned char _MidstateIV[32] =\n { 0x89, 0xcc, 0x59, 0xc6, 0xf7, 0xce, 0x43, 0xfc,\n 0xf6, 0x12, 0x67, 0x0e, 0x78, 0xe9, 0x36, 0x2e,\n 0x76, 0x8f, 0xd2, 0xc9, 0x18, 0xbd, 0x42, 0xed,\n 0x0e, 0x0b, 0x9f, 0x79, 0xee, 0xf6, 0x8a, 0x24 };\n\nAs fast-SHA256 is only defined for two (2) 32-byte hash inputs, there are necessarily two special cases:\nan empty Merkle tree is not allowed, nor is any root hash defined for such a \"tree\";\nand a Merkle tree with a single value has a root hash label equal to that self-same value of the leaf branch, the only node in the tree (a passthrough operation with no hashing).\n\n===Rationale===\n\nThe fast-SHA256 hash function can be calculated 2.32x faster than a specialized double-SHA256 implementation[2], or three (3) times faster than an implementation applying a generic SHA-256 primitive twice,\nas hashing 64 bytes of data with SHA-256 as specified by FIPS 180-4[3] takes two compression runs (because of message padding) and then a third compression run for the double-SHA256 construction.\nValidating a fast-SHA256 Merkle root is therefore more than twice as fast as the double-SHA256 construction used by Satoshi in bitcoin.\nFurthermore the fastest fast-SHA256 implementation ''is'' the generic SHA-256 implementation, enabling generic circuitry and code reuse without a cost to performance.\n\nThe application of fast-SHA256 to inner node label updates is safe in this limited domain because the inputs are hash values and fixed in number and in length,\nso the sorts of attacks prevented by message padding and double-hashing do not apply.\n\nThe 'initialization vector' for fast-SHA256 is changed in order to prevent a category of attacks on higher level protocols where a partial collision can serve as both a leaf hash and as an inner node commitment to another leaf hash.\nThe IV is computed using standard SHA-256 plus midstate extraction so as to preserve compatibility with cryptographic library interfaces that do not support custom IVs, at the cost of a 2x performance hit if neither custom IVs nor resuming from midstate are supported.\nThe data hashed is a nothing-up-my-sleeve number that is unlikely to have a known hash preimage.\nThe prime 23 was chosen as the leading fractional bits of the first eight (8) primes, two (2) through nineteen (19), are constants used in the setup of SHA-256 itself.\nUsing the next prime in sequence reduces the likelihood of introducing weakness due to reuse of a constant factor.\n\nThe Merkle root hash of a single element tree is a simple pass-through of the leaf hash without modification so as to allow for chained validation of split proofs.\nThis is particularly useful when the validation environment constrains proof sizes, such as push limits in Bitcoin script.\nChained validation allows a verifier to split one proof into two or more, where the leaf is shown to be under an inner node, and that inner node is shown to be under the root.\nWithout pass-through hashing in a single-element tree, use of chained validation would unnecessarily introduce a minimum path length requirement equal to the number of chain links.\nPass-through hashing of single elements allows instead for one or more of the chained validations to use a \"NOP\" proof consisting of a zero-length path,\nthereby allowing, for example, a fixed series of four (4) chained validations to verify a length three (3) or shorter path.\n\n==Inclusion Proofs==\n\nAn important use of Merkle hash-trees is the ability to compactly prove membership with log-sized proofs.\nThis section specifies a standard encoding for a multi-element inclusion proof.\n\nTo prove that a set of hashes is contained within a Merkle tree with a given root requires four pieces of information:", "category": "bips" }, { "instruction": "Hey, I need to set up Bitcoin Operations Guide - what's the command line way to do that?", "input": "", "output": "# The hash values to be verified, a set usually consisting of the double-SHA256 hash of data elements, but potentially the labels of inner nodes instead, or both;", "category": "bips" }, { "instruction": "What's the deal with Bitcoin Operations Guide in Bitcoin? Explain it like I'm a friend.", "input": "", "output": "# The paths from the root to the nodes containing the values under consideration, expressed as a serialized binary tree structure; and", "category": "bips" }, { "instruction": "Can you show me the CLI commands for The hash values of branches not taken along those paths.?", "input": "", "output": "Typically the last two elements, the paths and the elided branch hashes, are lumped together and referred to as the ''proof''.\n\nSerialization begins with a variable-length integer (VarInt) used to encode N, the number of internal nodes in the proof.\nNext the structure of the tree is traversed using depth-first, left-to-right, pre-order algorithm to visit each internal nodes, which are serialized using a packed 3-bit representation for the configuration of each node, consuming (3*N + 7) / 8 bytes.\nThen the number skipped hashes (those included in the proof, not verified by the proof) is serialized as a variable-length integer (VarInt),\nfollowed by the hashes themselves in the order previously traversed.\n\nThere are eight possible configurations of internal nodes, as given in the following diagram:\n\n:: [[File:bip-0098/node-variants.png]]\n\nIn this diagram, DESCEND means the branch links to another internal node, as indicated by its child graph elements labeled \"...\";\nSKIP means the branch contains a hash of an elided subtree or element, and the fast-SHA256 root hash of this subtree or double-SHA256 hash of the element is included in the proof structure; and\nVERIFY means the branch contains an externally provided hash that is needed as witness for the verification of the proof.\nIn tabular form, these code values are:\n\n{| class=\"wikitable\"\n|-\n| scope=\"col\"| Code\n| scope=\"col\"| Left\n| scope=\"col\"| Right\n|-\n| scope=\"row\"| 000\n| VERIFY\n| SKIP\n|-\n| scope=\"row\"| 001\n| VERIFY\n| VERIFY\n|-\n| scope=\"row\"| 010\n| VERIFY\n| DESCEND\n|-\n| scope=\"row\"| 011\n| DESCEND\n| SKIP\n|-\n| scope=\"row\"| 100\n| DESCEND\n| VERIFY\n|-\n| scope=\"row\"| 101\n| DESCEND\n| DESCEND\n|-\n| scope=\"row\"| 110\n| SKIP\n| VERIFY\n|-\n| scope=\"row\"| 111\n| SKIP\n| DESCEND\n|}\n\nThese 3-bit codes are packed into a byte array such that eight (8) codes would fit in every three (3) bytes.\nThe order of filling a byte begins with the most significant bit 0x80 and ends with the least significant bit 0x01.\nUnless the number of inner nodes is a multiple of eight (8), there will be excess low-order bits in the final byte of serialization.\nThese excess bits must be zero.\n\nNote that the tree serialization is self-segmenting.\nBy tracking tree structure a proof reader will know when the parser has reached the last internal node.\nThe number of inner nodes serialized in the proof MUST equal the number of nodes inferred from the tree structure itself.\nSimilarly, the number of SKIP hashes can also be inferred from the tree structure as serialized, and MUST equal the number of hashes provided within the proof.\n\nThe single-hash proof has N=0 (the number of inner nodes),\nthe tree structure is not serialized (as there are no inner nodes),\nand the number of SKIP hashes can be either 0 or 1.\n\n===Example===\n\nConsider the following Merkle tree structure:\n\n:: [[File:bip-0098/traversal-example.png]]\n\nThere are six (6) internal nodes.\nThe depth-first, left-to-right, pre-order traversal of the tree visits these nodes in the following order: A, B, D, F, C, then E.\nThere are three (3) skipped hashes, visited in the following order: 0x00..., 0x66..., and 0x22...\nThe remaining four (4) hashes are provided at runtime to be verified by the proof.\n\n{|\n| scope=\"col\"|\n| scope=\"col\"| Byte 1\n| scope=\"col\"| Byte 2\n| scope=\"col\"| Byte 3\n|-\n| scope=\"row\"| Bits\n| 76543210\n| 76543210\n| 76543210\n|-\n| scope=\"row\"| Nodes\n| AAABBBDD\n| DFFFCCCE\n| EE------\n|-\n| scope=\"row\"| Code\n| 10111101\n| 10000100\n| 01000000\n|}\n\nThe serialization begins with the VarInt encoded number of inner nodes, 0x06, followed by the tree serialization itself, 0xbd8440.\nNext the number of SKIP hashes is VarInt encoded, 0x03, followed by the three (3) hashes in sequence.\nThe resulting 101 byte proof, encoded in base64:.\n\n Br2EQAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGZmZmZmZmZmZmZmZmZmZmZmZmZm\n ZmZmZmZmZmZmZmZmREREREREREREREREREREREREREREREREREREREREREQ=\n\n===Rationale===\n\nThe 3-bit encoding for inner nodes allows encoding all relevant configurations of the nodes where the left and right branches can each be one of {DESCEND, SKIP, VERIFY}.\nThe excluded 9th possibility would have both branches as SKIP:\n\n:: [[File:bip-0098/skip-skip.png]]\n\nThis possibility is not allowed as for verification purposes it is entirely equivalent to the shorter proof where the branch to that node was SKIP'ed.\nDisallowing a node with two SKIP branches eliminates what would otherwise be a source of proof malleability.\n\nThe number of hashing operations required to verify a proof is one less than the number of hashes (SKIP and VERIFY combined),\nand is exactly equal to the number of inner nodes serialized as the beginning of the proof as N.\nThe variable-length integer encoding has the property that serialized integers, sorted lexicographically, will also be sorted numerically.\nSince the first serialized item is the number of inner nodes, sorting proofs lexicographically has the effect of sorting the proofs by the amount of work required to verify.\n\nThe number of hashes required as input for verification of a proof is N+1 minus the number of SKIP hashes,\nand can be quickly calculated without parsing the tree structure.\n\nThe coding and packing rules for the serialized tree structure were also chosen to make lexicographical comparison useful (or at least not meaningless).\nIf we consider a fully-expanded tree (no SKIP hashes, all VERIFY) to be encoding a list of elements in the order traversed depth-first from left-to-right,\nthen we can extract proofs for subsets of the list by SKIP'ing the hashes of missing values and recursively pruning any resulting SKIP,SKIP nodes.\nLexicographically comparing the resulting serialized tree structures is the same as lexicographically comparing lists of indices from the original list verified by the derived proof.\n\nBecause the number of inner nodes and the number of SKIP hashes is extractible from the tree structure,\nboth variable-length integers in the proof are redundant and could have been omitted.\nHowever that would require either construction and storage of the explicit tree in memory at deserialization time,\nor duplication of the relatively complicated tree parsing code in both the serialization and verification methods.\nFor that reason (as well as to handle the single-hash edge case) the redundant inner node and SKIP hash counts are made explicit in the serialization,\nand the two values must match what is inferred from the tree structure for a proof to be valid.\nThis makes deserialization trivial and defers tree construction until verification time,\nwhich has the additional benefit of enabling log-space verification algorithms.\n\n==Fast Merkle Lists==\n\nMany applications use a Merkle tree to provide indexing of, or compact membership proofs about the elements in a list.\nThis addendum specifies an algorithm that constructs a canonical balanced tree structure for lists of various lengths.\nIt differs in a subtle but important way from the algorithm used by Satoshi so as to structurally prevent the vulnerability described in [1].", "category": "bips" }, { "instruction": "I'm stuck with While the list has 2 or more elements, - what should I check?", "input": "", "output": "#* Pass through the list combining adjacent entries with the fast-SHA256 hash. If the list has an odd number of elements, leave the last element as-is (this fixes [1]). This step reduces a list of N elements to ceil(N/2) entries.", "category": "bips" }, { "instruction": "How do I troubleshoot The last remaining item in the list is the Merkle root. issues?", "input": "", "output": "This algorithm differs from Merkle lists used in bitcoin in two ways.\nFirst, fast-SHA256 is used instead of double-SHA256 for inner node labels.\nSecond, final entries on an odd-length list are not duplicated and hashed, which is the mistake that led to CVE-2012-2459[1].\n\n==Implementation==\n\nAn implementation of this BIP for extraction of Merkle branches and fast, log-space Merkle branch validation is available at the following Github repository:\n\n[https://github.com/maaku/bitcoin/tree/fast-merkle-tree]\n\nAlso included in this repo is a 'merklebranch' RPC for calculating root values and extracting inclusion proofs for both arbitrary trees and trees constructed from lists of values using the algorithm in this BIP,\nand a 'mergemerklebranch' RPC for unifying two or more fast Merkle tree inclusion proofs--replacing SKIP hashes in one proof with a subtree extracted from another.\n\n==Deployment==\n\nThis BIP is used by BIP116 (MERKLEBRANCHVERIFY)[4] to add Merkle inclusion proof verification to script by means of a soft-fork NOP expansion opcode.\nDeployment of MERKLEBRANCHVERIFY would make the contents of this BIP consensus critical.\nThe deployment plan for BIP116 is covered in the text of that BIP.\n\n==Compatibility==\n\nThis BIP on its own does not cause any backwards incompatibility.\n\n==References==\n\n[1] [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2459 National Vulnerability Database: CVE-2012-2459]\n\n[2] [https://github.com/sipa/bitcoin/tree/201709_dsha256_64 github.com:sipa/bitcoin 201709_dsha256_64] Pieter Wuille, September 2017, personal communication. By making use of knowledge that the inputs at each stage are fixed length, Mr. Wuille was able to achieve a 22.7% reduction in the time it takes to compute the double-SHA256 hash of 64 bytes of data, the hash aggregation function of the Satoshi Merkle tree construction.\n\n[3] [http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf Secure Hash Standard]\n\n[4] [https://github.com/bitcoin/bips/blob/master/bip-0116.mediawiki BIP 116 MERKLEBRANCHVERIFY]", "category": "bips" }, { "instruction": "What are the best practices for 
?",
    "input": "",
    "output": "BIP: 171\n  Layer: Applications\n  Title: Currency/exchange rate information API\n  Authors: Luke Dashjr \n  Comments-Summary: No comments yet.\n  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0171\n  Status: Closed\n  Type: Specification\n  Assigned: 2017-03-04\n  License: BSD-2-Clause\n
\n\n==Abstract==\n\nA common interface for requesting currency exchange rate information from a server.\n\n==Copyright==\n\nThis BIP is licensed under the BSD 2-clause license.\n\n==Specification==\n\nFour requests are defined, which are all made by a GET request to a common URI with parameters encoded in application/x-www-form-urlencoded format.\nAll matching parameters may be specified with multiple comma-separated values, which are to be interpreted as \"any of these\".\nEach result is always in JSON format, with a line-feed (never a carriage-return) separating multiple results.\n\nAuthentication for subscription-based services MAY be supported using standard HTTP authentication.\nIt is recommended to use TLS (HTTPS) and/or Linked Data Signatures, so that MITM attackers cannot deceive the client.\n\nTo be BIP 171 compatible, servers MUST support at least one currency-pair compared to XBT.\nAll inquiries for bitcoin amounts MUST be specified in XBT, even if the presentation to the end user is in another unit.\n(FIXME: or should this be satoshis?)\n\nCurrency-pair tokens are arbitrary Strings no longer than 255 characters, which may include any ASCII [https://tools.ietf.org/html/rfc3986#section-2.3 RFC 3986 unreserved characters] (ie, alphanumerics and the hyphen, underscore, period, and tilde symbols).\n\nCurrency code(s) used herein are defined as such:\n\n* All ISO 4217 codes are valid currency codes.\n* XBT is defined as 100000000 satoshis (commonly known as 1 BTC).\n* Strings longer than 3 characters may be used for currencies without an applicable code. (If a shorter code is desired despite this, it may be padded with space(s) to the left until it is 4 characters. Software MAY strip these spaces.)\n\nRate is defined as the amount of quote-currency to be exchanged for one unit of the base-currency.\nIn other words, 1 baseCurrency = rate quoteCurrency.\n\n===Enumerating supported currency-pair tokens===\n\nParameters:\n\n* ''mode'' - Always \"list\" for this request.\n* ''quote'' - If provided, the server MAY limit the results to only currency-pairs describing a currency with the given currency code(s).\n* ''base'' - If provided, the server MAY limit the results to only currency-pairs describing currency rates compared to the given currency code(s).\n* ''locale'' - If provided, the server MAY limit the results to only currency-pairs supporting the given Unicode CLDR locale(s).\n\nEach currency-pair will receive a separate result, a JSON Object, with the following information:\n\n* ''cp'' - The currency-pair token.\n* ''quote'' - The currency code for the quote currency.\n* ''base'' - The currency code for the base currency.\n* ''locale'' - If provided, a String with the applicable Unicode CLDR locale.\n* ''desc'' - Optional description. For example, it could be \"Based on Florida BTM prices.\" or any other short String that provides information useful to the user. SHOULD be shorter than 45 characters.\n* ''signature'' - Optional. May be used for Linked Data Signatures.\n\nExample:\n\n Request: http://api.example.tld/?mode=list"e=USD&base=XBT&locale=en_US,en_GB\n Result:\n {\"cp\":\"XBTUSD-ver4\", \"quote\":\"USD\", \"base\": \"XBT\", \"locale\": \"en_US\", \"desc\": \"Smoothed averages\"}\n {\"cp\":\"2\", \"quote\":\"USD\", \"base\": \"XBT\", \"locale\": \"en_US\", \"desc\": \"Updated per-trade\"}\n {\"cp\":\"XBTUSD-european\", \"quote\":\"USD\", \"base\": \"XBT\", \"locale\": \"en_GB\"}\n\n===Currency-pair information===\n\nParameters:\n\n* ''mode'' - Always \"info\" for this request.\n* ''cp'' - Currency pair(s) for which information is requested.\n\nEach currency-pair will receive a separate result, a JSON Object, with the following information:\n\n* ''cp'' - The currency-pair token.\n* ''quote'' - The currency code for the quote currency.\n* ''base'' - The currency code for the base currency.\n* ''locale'' - If provided, a String with the applicable Unicode CLDR locale.\n* ''desc'' - Optional description. For example, it could be \"Based on Florida BTM prices.\" or any other short String that provides information useful to the user. SHOULD be shorter than 45 characters.\n* ''longdesc'' - Optional description, but may be longer and include newlines.\n* ''symbol'' - An Array of prefix and suffix for the quote currency. Each may be either a fixed String, an Array of two Strings (negative and positive), or null. Any positive or negative symbols must be included in this prefix/suffix; it MUST NOT be implied otherwise.\n* ''digits'' - The type of digits to use for the quote currency's numbers. \"arabic\" should be used for common 0-9 digits.\n* ''grouping'' - An Array alternating between Numbers representing a series of digits, and Strings used as delimiters. If terminated by a zero, the final grouping is to be repeated continually. For example, the common US locale thousands grouping would be [3, \",\", 0]\n* ''fraction_sep'' - A String to be placed between whole numbers and a fractional amount.\n* ''fraction_digits'' - Array of absolute minimum (even for whole numbers) number of fractional digits, minimum fractional digits when a fraction exists, and maximum number of fractional digits when absolute precision is not demanded (below which is to be rounded in an implementation-dependent manner).\n* ''minpoll'' - A Number of seconds indicating a minimum time between polls to the server. Clients should be prudent about not polling too often, even if this number is low.\n* ''longpoll'' - If provided and true, indicates longpolling is supported by the server.\n* ''history'' - If provided, indicates the server has historical records going back no earlier than the POSIX timestamp provided as a value.\n* ''archive'' - If provided, indicates the server no longer has current rates, and has no historical rates more recent than the POSIX timestamp provided as a value.\n* ''signature'' - Optional. May be used for Linked Data Signatures.\n\nExample:\n\n Request: http://api.example.tld/?mode=info&cp=XBTUSD-ver4,2\n Result:\n {\"cp\":\"XBTUSD-ver4\", \"quote\":\"USD\", \"base\": \"XBT\", \"locale\": \"en_US\", \"desc\": \"Smoothed averages\", \"longdesc\": \"USD price quotes as compared to Bitcoin value\\n\\nRecommended for casual usage\", \"symbol\": [[\"-$\", \"$\"], null], \"digits\": \"arabic\", \"grouping\": [3, \",\", 0], \"fraction_sep\": \".\", \"fraction_digits\": [0, 2, 2], \"minpoll\": 300, \"longpoll\": true, \"history\": 1457231416}\n {\"cp\":\"2\", \"quote\":\"USD\", \"base\": \"XBT\", \"locale\": \"en_US\", \"desc\": \"Updated per-trade\", \"longdesc\": \"Maximum precision USD price quotes as compared to Bitcoin value\", \"symbol\": [[\"-$\", \"$\"], null], \"digits\": \"arabic\", \"grouping\": [3, \",\", 0], \"fraction_sep\": \".\", \"fraction_digits\": [0, 2, 2], \"minpoll\": 3600, \"longpoll\": false, \"history\": 1467458333.1225}\n\n===Current exchange rate===\n\nParameters:\n\n* ''mode'' - Always \"rate\" for this request.\n* ''cp'' - Currency pair(s) for which rate is requested.\n* ''type'' - Type of exchange rate data being requested. May be \"high\", \"low\", \"average\", \"typical\", or any other arbitrary name. If omitted, the server may provide any rates it deems appropriate.\n* ''minrate'', ''maxrate'' - If specified, indicates this request is a longpoll. The server should not send a response until the rate(s) fall below or above (respectively) the provided value.\n* ''nonce'' - If specified, the server SHOULD return it in each result.\n\nEach currency-pair receives a separate result (a JSON Object) with all requested rate types:\n\n* ''cp'' - The currency-pair token.\n* ''time'' - The time (as a POSIX timestamp) the rate information is applicable to (should be approximately the request time).\n* ''rates'' - A JSON Object with each rate type provided as a key, and a Number as the value specifying the rate.\n* ''nonce'' - Only if the request specified a nonce, the server SHOULD include it here as a JSON String.\n* ''signature'' - Optional. May be used for Linked Data Signatures.\n\nExample:\n\n Request: http://api.example.tld/?mode=rate&cp=XBTUSD-ver4,2&type=typical,high\n Result:\n {\"cp\":\"XBTUSD-ver4\", \"time\": 1488767410.5463133, \"rates\": {\"typical\": 1349.332215, \"high\": 1351.2}}\n {\"cp\":\"2\", \"time\": 1488767410, \"rates\": {\"typical\": 1350.111332}}\n\n===Historical exchange rates===\n\nParameters:\n\n* ''mode'' - Always \"history\" for this request.\n* ''cp'' - Currency pair(s) for which rate is requested.\n* ''type'' - Type of exchange rate data being requested. May be \"high\", \"low\", \"average\", \"typical\", or any other arbitrary name. If omitted, the server may provide any rates it deems appropriate.\n* ''from'' - POSIX timestamp the results should begin with.\n* ''to'' - POSIX timestamp the results should end with. If omitted, the present time shall be used.\n* ''nearest'' - If provided and true, indicates that only the nearest timestamp to \"from\" must be returned, and a range is not desired. (\"to\" should be omitted in this case.)\n* ''ratedelta'', ''timedelta'' - If specified, the server may omit data where the rate or time has not changed since the last provided rate and time. If both are provided, either a significant rate change OR time change should trigger a new record in the results.\n\nA result is provided for each currency-pair and timestamp record, in the same format as the current exchange rate request.\nRecords MUST be provided in chronological order, but only within the scope of the applicable currency-pair (ie, it is okay to send the full history for one currency-pair, and then the full history for the next; or to intermix them out of any given order).\n\nIf there is no exact record for the times specified by \"from\" and/or \"to\", a single record before \"from\" and/or after \"to\" should also be included.\nThis is not necessary when only the nearest record is requested, or when \"to\" is omitted (ie, ending at the most recent record).\n\nExample:\n\n Request: http://api.example.tld/?mode=history&cp=XBTUSD-ver4,2&type=typical&ratedelta=0.1&timedelta=10&from=1488759998&to=1488760090\n Result:\n {\"cp\":\"XBTUSD-ver4\", \"time\": 1488760000, \"rates\": {\"typical\": 1300}}\n {\"cp\":\"XBTUSD-ver4\", \"time\": 1488760010, \"rates\": {\"typical\": 1301.1}}\n {\"cp\":\"XBTUSD-ver4\", \"time\": 1488760020, \"rates\": {\"typical\": 1320}}\n {\"cp\":\"XBTUSD-ver4\", \"time\": 1488760030, \"rates\": {\"typical\": 1305}}\n {\"cp\":\"2\", \"time\": 1488760000.1, \"rates\": {\"typical\": 1300}}\n {\"cp\":\"2\", \"time\": 1488760010.2, \"rates\": {\"typical\": 1301.1}}\n {\"cp\":\"2\", \"time\": 1488760020.2, \"rates\": {\"typical\": 1320.111332}}\n {\"cp\":\"2\", \"time\": 1488760031, \"rates\": {\"typical\": 1305.222311}}\n {\"cp\":\"XBTUSD-ver4\", \"time\": 1488760040, \"rates\": {\"typical\": 1303.33}}\n {\"cp\":\"2\", \"time\": 1488760042, \"rates\": {\"typical\": 1303.33}}\n {\"cp\":\"XBTUSD-ver4\", \"time\": 1488760050, \"rates\": {\"typical\": 1305}}\n {\"cp\":\"2\", \"time\": 1488760052, \"rates\": {\"typical\": 1307}}\n {\"cp\":\"XBTUSD-ver4\", \"time\": 1488760060, \"rates\": {\"typical\": 1309}}\n {\"cp\":\"XBTUSD-ver4\", \"time\": 1488760072, \"rates\": {\"typical\": 1308}}\n {\"cp\":\"2\", \"time\": 1488760062, \"rates\": {\"typical\": 1309.55555555}}\n {\"cp\":\"2\", \"time\": 1488760072, \"rates\": {\"typical\": 1308}}\n {\"cp\":\"XBTUSD-ver4\", \"time\": 1488760082, \"rates\": {\"typical\": 1309}}\n {\"cp\":\"2\", \"time\": 1488760082, \"rates\": {\"typical\": 1309.1}}\n\n==Motivation==\n\nEnd users often desire to see fiat currency information in their Bitcoin wallet software.\nDue to the nature of Bitcoin, there is inherently no authoritative source for exchange rates.\nThere are many independent providers of such information, but they all use different formats for providing it, so wallet software is currently forced to implement dedicated code for each provider.\n\nBy providing a standard interface for retrieving this information, wallets (and other software) and service providers can implement it once, and become immediately interoperable with all other compatible implementations.\n\n==Rationale==\n\nWhy are multiple results separated by a line-feed rather than using a JSON Array?\n\n* Clients ought to cache historical data, and using a line-feed format allows them to simply append to a cache file.\n* Parsing JSON typically requires the entire data parsed together as a single memory object. Using simple lines to separate results, however, allows parsing a single result at a time.\n\nWhat if long descriptions require line and paragraph breaks?\n\n* Clients should word-wrap long lines, and JSON escapes newlines as \"\\n\" which can be used doubly (\"\\n\\n\") for paragraph breaks.\n\n==Backwards compatibility==\n\nWhile this new standard is adopted, software and providers can continue to use and provide their current formats until they are no longer needed.\n\n==Reference implementation==\n\nTODO\n\n==See also==\n\n* [https://w3c-dvcg.github.io/ld-signatures/ Draft W3c Linked Data Signatures specification]", "category": "bips" }, { "instruction": "Walk me through setting up 
 step by step",
    "input": "",
    "output": "BIP: 35\n  Layer: Peer Services\n  Title: mempool message\n  Authors: Jeff Garzik \n  Status: Deployed\n  Type: Specification\n  Assigned: 2012-08-16\n
\n\n==Abstract==\n\nMake a network node's transaction memory pool accessible via a new \"mempool\" message. Extend the existing \"getdata\" message behavior to permit accessing the transaction memory pool.\n\n==Motivation==\n\nSeveral use cases make it desirable to expose a network node's transaction memory pool:", "category": "bips" }, { "instruction": "What commands would you run to work with Bitcoin Operations Guide?", "input": "", "output": "# Miners, to avoid missing lucrative fees, downloading existing network transactions after a restart.", "category": "bips" }, { "instruction": "I want to understand Bitcoin Operations Guide from a technical perspective", "input": "", "output": "# Upon receipt of a \"mempool\" message, the node will respond with an \"inv\" message containing MSG_TX hashes of all the transactions in the node's transaction memory pool, if any.", "category": "bips" }, { "instruction": "Can you explain Bitcoin Operations Guide like we're having a beer and talking Bitcoin?", "input": "", "output": "# The typical node behavior in response to an \"inv\" is \"getdata\". However, the reference Satoshi implementation ignores requests for transaction hashes outside that which is recently relayed. To support \"mempool\", an implementation must extend its \"getdata\" message support to querying the memory pool.", "category": "bips" }, { "instruction": "How would you explain Feature discovery is enabled by checking two \"version\" message attributes: to someone who knows Bitcoin basics?", "input": "", "output": "## Protocol version >= 60002\n## NODE_NETWORK bit set in nServices\n\nNote that existing implementations drop \"inv\" messages with a vector size > 50000.\n\n==Backward compatibility==\n\nOlder clients remain 100% compatible and interoperable after this change.\n\n==Implementation==\n\nhttps://github.com/bitcoin/bitcoin/pull/1641", "category": "bips" }, { "instruction": "I'm trying to understand 
 - can you walk me through it?",
    "input": "",
    "output": "BIP: 150\n  Layer: Peer Services\n  Title: Peer Authentication\n  Authors: Jonas Schnelli \n  Comments-Summary: Discouraged for implementation (one person)\n  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0150\n  Status: Closed\n  Type: Specification\n  Assigned: 2016-03-23\n  License: PD\n
\n\n== Abstract ==\n\nThis BIP describes a way for peers to authenticate to other peers to guarantee node ownership and/or allow peers to access additional or limited node services, without the possibility of fingerprinting.\n\n== Motivation ==\n\nWe assume peer operators want to limit the access of different node services or increase datastream priorities to a selective subset of peers. Also we assume that peers want to connect to specific peers to broadcast or filter transactions (or similar actions that reveal sensitive information) and therefore operators want to authenticate the remote peer and ensure that they have not connected to a MITM (man-in-the-middle) attacker.\n\nBenefits of peer authentication:\n* Peers can detect MITM attacks when connecting to known peers\n* Peers can allow resource hungry transaction filtering only to specific peers\n* Peers can allow access to sensitive information that can lead to node fingerprinting (fee estimation)\n* Peers can allow custom message types (private extensions) to authenticated peers\n\nA simple authentication scheme based on elliptic cryptography will allow peers to identify each other and selectively allow access to restricted services or reject the connection if the peer identity cannot be verified.\n\n== Specification ==\n\nThe authentication scheme proposed in this BIP uses ECDSA, '''secrets will never be transmitted'''.\n\n'''Authentication initialization must only happen if encrypted channels have been established (according to BIP-151 [1]).'''\n\nThe '''encryption-session-ID''' is available once channels are encrypted (according to BIP-151 [1]).\n\nThe identity-public-keys used for the authentication must be pre-shared over a different channel (mail/PGP, physical paper exchange, etc.). This BIP does not cover a \"trust on first use\" (TOFU) concept.\n\nThe authentication state must be kept until the encryption/connection terminates.\n\nOnly one authentication process is allowed per connection. Re-authentication require re-establishing the connection.\n\n=== Known-peers and authorized-peers database ===\nEach peer that supports p2p authentication must provide two user-editable \"databases\".", "category": "bips" }, { "instruction": "Hey, I need to set up Bitcoin Operations Guide - what's the command line way to do that?", "input": "", "output": "# '''known-peers''' contains known identity-public-keys together with a network identifier (IP & port), similar to the \"known-host\" file supported by openssh.", "category": "bips" }, { "instruction": "What's the deal with '''authorized-peers''' contains authorized identity-public-keys in Bitcoin? Explain it like I'm a friend.", "input": "", "output": "=== Local identity key management ===\nEach peer can configure multiple identity-keys (ECC, 32 bytes). Peers should make sure that each network interface (IPv4, IPv6, tor) has its own identity-key (otherwise it would be possible to link a tor address to a IPvX address).\nThe identity-public-key(s) can be shared over a different channel with other node-operators (or non-validating clients) to grant authorized access.\n\n=== Authentication procedure ===\nAuthentication based on this BIP will require both sides to authenticate. Signatures/public-keys will only be revealed if the remote peer can prove that they already know the remote identity-public-key.", "category": "bips" }, { "instruction": "Can you show me the CLI commands for -> Requesting peer sends AUTHREPLY (signature)?", "input": "", "output": "For privacy reasons, dropping the connection or aborting during the authentication process must not be allowed.\n\n=== AUTHCHALLENGE message ===\nA peer can send an authentication challenge to see if the responding peer can produce a valid signature with the expected responding peer's identity-public-key by sending an AUTHCHALLENGE-message to the remote peer.\n\nThe responding peer needs to check if the hash matches the hash calculated with his own local identity-public-key. Fingerprinting the requesting peer is not possible.\n\n{|class=\"wikitable\"\n! Field Size !! Description !! Data type !! Comments\n|-\n| 32bytes || challenge-hash || hash || hash(encryption-session-ID || challenge_type || remote-peers-expected-identity-public-key)\n|}\n\n\nchallenge_type is a single character. i if the AUTHCHALLENGE-message is the first, requesting challenge or r if it's the second, remote peers challenge message.\n\n=== AUTHREPLY message ===\nA peer must reply an AUTHCHALLENGE-message with an AUTHREPLY-message.\n\n{|class=\"wikitable\"\n! Field Size !! Description !! Data type !! Comments\n|-\n| 64bytes || signature || normalized comp.-signature || A signature of the encryption-session-ID done with the identity-key\n|}\n\nIf the challenge-hash from the AUTHCHALLENGE-message did not match the local authentication public-key, the signature must contain 64 bytes of zeros.\n\nThe requesting peer can check the responding peer's identity by checking the validity of the sent signature against with the pre-shared remote peers identity-public-key.\n\nIf the signature was invalid, the requesting peer must still proceed with the authentication by sending an AUTHPROPOSE-message with 32 random bytes.\n\n=== AUTHPROPOSE message ===\nA peer can propose authentication of the channel by sending an AUTHPROPOSE-message to the remote peer.\n\nIf the signature sent in AUTHREPLY was invalid, the peer must still send an AUTHPROPOSE-message containing 32 random bytes.\n\nThe AUTHPROPOSE message must be answered with an AUTHCHALLENGE-message - even if the proposed requesting-peers identity-public-key has not been found in the authorized-peers database. In case of no match, the responding AUTHCHALLENGE-message must contains 32 bytes of zeros.\n\n{|class=\"wikitable\"\n! Field Size !! Description !! Data type !! Comments\n|-\n| 32bytes || auth-propose-hash || hash || hash(encryption-session-ID || \"p\" || identity-public-key)\n|}\n\n== Post-Authentication Re-Keying ==\n\nAfter the second AUTHREPLY message (requesting peer's signature -> responding peer), both clients must re-key the symmetric encryption according to BIP151 while using '''a slightly different re-key key derivation hash'''.\n\nBoth peers re-key with hash(encryption-session-ID || old_symmetric_cipher_key || requesting-peer-identity-public-key || responding-peer-identity-public-key)\n\n== Identity-Addresses ==\nThe peers should display/log the identity-public-key as an identity-address to the users, which is a base58-check encoded ripemd160(sha256) hash. The purpose of this is for better visual comparison (logs, accept-dialogs).\nThe base58check identity byte is 0x0F followed by an identity-address version number (=0xFF01).\n\nAn identity address would look like TfG4ScDgysrSpodWD4Re5UtXmcLbY5CiUHA and can be interpreted as a remote peer's fingerprint.\n\n== Compatibility ==\n\nThis proposal is backward compatible. Non-supporting peers will ignore the new AUTH* messages.\n\n== Example of an auth interaction ==\n\nBefore authentication (once during peer setup or upgrade)", "category": "bips" }, { "instruction": "I'm stuck with Bitcoin Operations Guide - what should I check?", "input": "", "output": "# Requesting and responding peer share the identity-public-key over a different channel (mail/PGP, physical paper exchange, etc.)", "category": "bips" }, { "instruction": "How do I troubleshoot Requesting peer sends an AUTHCHALLENGE message issues?", "input": "", "output": "AUTHCHALLENGE:\n [32 bytes, hash(encryption-session-ID || \"i\" || )]", "category": "bips" }, { "instruction": "What are the best practices for Bitcoin Operations Guide?", "input": "", "output": "# Responding peer does create the same hash (encryption-session-ID || \"i\" || ) with its local identity-public-key", "category": "bips" }, { "instruction": "Walk me through setting up Bitcoin Operations Guide step by step", "input": "", "output": "# If the hash does not match, response with an AUTHREPLY message containing 64bytes of zeros.", "category": "bips" }, { "instruction": "What commands would you run to work with In case of a match, response with an AUTHREPLY message?", "input": "", "output": "AUTHREPLY:\n [64 bytes normalized compact ECDSA signature (H)] (sig of the encryption-session-ID done with the identity-key)", "category": "bips" }, { "instruction": "I want to understand Bitcoin Operations Guide from a technical perspective", "input": "", "output": "# If the signature is invalid, requesting peer answers with an AUTHREPLY message containing 32 random bytes", "category": "bips" }, { "instruction": "Can you explain Bitcoin Operations Guide like we're having a beer and talking Bitcoin?", "input": "", "output": "# Responding peer iterates over authorized-peers database (A), hashes the identical data and looks for a match.", "category": "bips" }, { "instruction": "How would you explain Bitcoin Operations Guide to someone who knows Bitcoin basics?", "input": "", "output": "# If the hash does not match, responding peer answer with an AUTHCHALLENGE message containing 32 bytes of zeros.", "category": "bips" }, { "instruction": "I'm trying to understand Bitcoin Operations Guide - can you walk me through it?", "input": "", "output": "# Requesting peer sends an AUTHREPLY message containing 64 bytes of zeros if server failed to authenticate", "category": "bips" }, { "instruction": "Hey, I need to set up Otherwise, response with signature in the AUTHREPLY message - what's the command line way to do that?", "input": "", "output": "AUTHREPLY:\n [64 bytes normalized compact ECDSA signature (H)] (sig of the encryption-session-ID done with the identity-key)", "category": "bips" }, { "instruction": "What's the deal with Both peers re-key the encryption after BIP151 including the requesting-peer-identity-public-key and responding-peer-identity-public-key in Bitcoin? Explain it like I'm a friend.", "input": "", "output": "== Disadvantages ==\n\nThe protocol may be slow if a peer has a large authorized-peers database due to the requirement of iterating and hashing over all available authorized peer identity-public-keys.\n\n== Reference implementation ==\n\n== References ==\n\n* [1] [[bip-0151.mediawiki|BIP 151: Peer-to-Peer Communication Encryption]]\n\n== Acknowledgements ==\n* Gregory Maxwell and Pieter Wuille for most of the ideas in this BIP.\n* Bryan Bishop for editing.\n\n== Copyright ==\nThis work is placed in the public domain.", "category": "bips" }, { "instruction": "Can you show me the CLI commands for 
?",
    "input": "",
    "output": "BIP: 89\n  Layer: Applications\n  Title: Chain Code Delegation\n  Authors: Jesse Posner \n           Jurvis Tan \n  Comments-Summary: No comments yet.\n  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0089\n  Status: Draft\n  Type: Specification\n  Assigned: 2025-12-03\n  License: BSD-3-Clause\n  Discussion: https://delvingbitcoin.org/t/chain-code-delegation-private-access-control-for-bitcoin-keys/1837\n  Requires: 32, 340, 341\n
\n\n== Abstract ==\nChain Code Delegation (CCD) is a method for multi-signature wallets in which a privileged participant withholds BIP32 chain codes from one or more non-privileged participants, and supplies per-input scalar tweaks at signing time. This allows non-privileged participants to co-sign transactions without learning wallet-wide derivations, balances, or signing activity from other spending combinations. CCD defines the tweak exchange needed for verification and signing behavior when the signer does not possess a chain code.\n\n== Motivation ==\nIn multisig deployments, sharing extended public keys (xpubs) or descriptors enables all participants to scan the chain and infer counterparties' activity. CCD limits that visibility by ensuring non-privileged participants only ever hold a non-extended keypair and only receive the minimum per-spend data needed to sign. The procedure keeps policy enforcement feasible for the non-privileged signer while preserving balance privacy, which is particularly useful in collaborative custody arrangements where the wallet owner wants balance privacy from their custodian.\n\n== Terminology ==\nIn CCD, the chain code is the object of delegation—not signing authority. A participant who gives up their chain code delegates it to another.\n\n* A \"Delegator\" is a participant who delegates their chain code to another party. They hold only a non-extended keypair and receive scalar tweaks from the delegatee when asked to sign.\n* A \"Delegatee\" is a participant who receives and retains a delegated chain code for another participant's public key, and computes derivation tweaks for that participant.\n* A \"Participant\" is any key holder that can co-sign for UTXOs in the wallet (including delegators and delegatees).\n* A \"Non-hardened derivation\" is a BIP32 child derivation where index < 2^31.\n\n== Overview ==\nCCD operates by having Delegatees deprive Delegators of BIP32 chain codes during setup and later conveying the aggregated scalar tweak computed as the sum of non-hardened derivation tweaks along the remaining path to the child key used by a given input or change output. A Delegator uses the tweak to compute the child keys for verification and signing without being able to derive or recognize keys for other paths.\n\n== Specification ==\n\n=== Key material and setup ===\n* '''Delegator key:''' Each delegator generates a standard (non-extended) secp256k1 keypair and provides the public key to the counterparties. A delegator MUST NOT retain or be provided a chain code for this key.\n* '''Delegated chain code:''' A designated delegatee computes and retains a BIP32 chain code bound to the delegator's public key, forming an xpub that MUST NOT be disclosed to the delegator. The delegatee MAY share this xpub with other delegatees.\n* '''Other participants:''' Non-delegator participants use conventional extended keys and share the public half as appropriate for the wallet descriptor.\n* '''Derivation constraints:''' The delegatee holds an extended public key for the delegator. All derivation from this extended key MUST be non-hardened, as hardened derivation requires the private key, which the delegatee does not possess.\n\n=== Notation ===\nThe following conventions are used, with constants as defined for [https://www.secg.org/sec2-v2.pdf secp256k1]. We note that adapting this proposal to other elliptic curves is not straightforward and can result in an insecure scheme.\n* Lowercase variables represent integers or byte arrays.\n** The constant ''p'' refers to the field size, ''0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F''.\n** The constant ''n'' refers to the curve order, ''0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141''.\n* Uppercase variables refer to points on the curve with equation ''y2 = x3 + 7'' over the integers modulo ''p''.\n** ''is_infinite(P)'' returns whether ''P'' is the point at infinity.\n** ''x(P)'' and ''y(P)'' are integers in the range ''0..p-1'' and refer to the X and Y coordinates of a point ''P'' (assuming it is not infinity).\n** The constant ''G'' refers to the base point, for which ''x(G) = 0x79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798'' and ''y(G) = 0x483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8''.\n** Addition of points refers to the usual [https://en.wikipedia.org/wiki/Elliptic_curve#The_group_law elliptic curve group operation].\n** [https://en.wikipedia.org/wiki/Elliptic_curve_point_multiplication Multiplication (⋅) of an integer and a point] refers to the repeated application of the group operation.\n* Functions and operations:\n** ''||'' refers to byte array concatenation.\n** The function ''x[i:j]'', where ''x'' is a byte array and ''i, j ≥ 0'', returns a ''(j - i)''-byte array with a copy of the ''i''-th byte (inclusive) to the ''j''-th byte (exclusive) of ''x''.\n** The function ''bytes(n, x)'', where ''x'' is an integer, returns the n-byte encoding of ''x'', most significant byte first.\n** The constant ''empty_bytestring'' refers to the empty byte array. It holds that ''len(empty_bytestring) = 0''.\n** The function ''xbytes(P)'', where ''P'' is a point for which ''not is_infinite(P)'', returns ''bytes(32, x(P))''.\n** The function ''len(x)'' where ''x'' is a byte array returns the length of the array.\n** The function ''has_even_y(P)'', where ''P'' is a point for which ''not is_infinite(P)'', returns ''y(P) mod 2 == 0''.\n** The function ''with_even_y(P)'', where ''P'' is a point, returns ''P'' if ''is_infinite(P)'' or ''has_even_y(P)''. Otherwise, ''with_even_y(P)'' returns ''-P''.\n** The function ''cbytes(P)'', where ''P'' is a point for which ''not is_infinite(P)'', returns ''a || xbytes(P)'' where ''a'' is a byte that is ''2'' if ''has_even_y(P)'' and ''3'' otherwise.\n** The function ''int(x)'', where ''x'' is a 32-byte array, returns the 256-bit unsigned integer whose most significant byte first encoding is ''x''.\n** The function ''lift_x(x)'', where ''x'' is an integer in range ''0..2256-1'', returns the point ''P'' for which ''x(P) = x''\n Given a candidate X coordinate ''x'' in the range ''0..p-1'', there exist either exactly two or exactly zero valid Y coordinates. If no valid Y coordinate exists, then ''x'' is not a valid X coordinate either, i.e., no point ''P'' exists for which ''x(P) = x''. The valid Y coordinates for a given candidate ''x'' are the square roots of ''c = x3 + 7 mod p'' and they can be computed as ''y = ±c(p+1)/4 mod p'' (see [https://en.wikipedia.org/wiki/Quadratic_residue#Prime_or_prime_power_modulus Quadratic residue]) if they exist, which can be checked by squaring and comparing with ''c''. and ''has_even_y(P)'', or fails if ''x'' is greater than ''p-1'' or no such point exists. The function ''lift_x(x)'' is equivalent to the following pseudocode:\n*** Fail if ''x > p-1''.\n*** Let ''c = x3 + 7 mod p''.\n*** Let ''y' = c(p+1)/4 mod p''.\n*** Fail if ''c ≠ y'2 mod p''.\n*** Let ''y = y' '' if ''y' mod 2 = 0'', otherwise let ''y = p - y' ''.\n*** Return the unique point ''P'' such that ''x(P) = x'' and ''y(P) = y''.\n** The function ''cpoint(x)'', where ''x'' is a 33-byte array (compressed serialization), sets ''P = lift_x(int(x[1:33]))'' and fails if that fails. If ''x[0] = 2'' it returns ''P'' and if ''x[0] = 3'' it returns ''-P''. Otherwise, it fails.\n** The function ''hash256tag(x)'' where ''tag'' is a UTF-8 encoded tag name and ''x'' is a byte array returns the 32-byte hash ''SHA256(SHA256(tag) || SHA256(tag) || x)''.\n** The function ''hash512tag(x)'' where ''tag'' is a UTF-8 encoded tag name and ''x'' is a byte array returns the 64-byte hash ''SHA512(SHA512(tag) || SHA512(tag) || x)''.\n* Other:\n** Tuples are written by listing the elements within parentheses and separated by commas. For example, ''(2, 3, 1)'' is a tuple.\n\n=== Tweak Calculation ===\nTo produce CCD tweak data, a delegatee computes a per-participant scalar that aggregates the non-hardened derivation tweaks along the remaining path. Let the extended key retained by the delegatee be P at depth d, and let the target index vector be I = (id+1, …, in) with each ik < 231.\n\n
\nAlgorithm ''ComputeBIP32Tweak(P, I)'':\n* Inputs:\n** ''P'': base public key at depth ''d''\n** ''I = (id+1, …, in)'': ordered sequence of non-hardened child indices\n* Let ''t = 0'' and ''E = P''.\n* For each index ''i'' in ''I'' (from left to right):\n** Run the BIP32 non-hardened derivation ''CKDpub'' on ''E'' with child index ''i'', yielding the child extended key ''Pchild'' and its scalar tweak ''δ'' (the parse256(''IL'') term from BIP32).\n** Let ''t = (t + δ) mod n''.\n** Let ''E = Pchild''.\n* If ''I'' is empty, let ''P′ = P''; otherwise let ''P′ = Pchild'' from the final iteration.\n* Return ''(t, P′)''.\n
\n\nAny attempt to apply a hardened derivation (index ≥ 231) MUST fail. Delegatees MAY discard P′ after extracting t if it is not otherwise required.\n\n=== Delegation Bundle ===\nCCD requires the delegatee to provide per-participant tweaks for inputs and (optionally) change outputs. Tweaks for change outputs are only required if a delegator wants to be able to compute the amount of bitcoin they are spending. \n\nA delegatee MUST provide each delegator with, for every signing context, a collection of tuples (Pi, ti) where Pi is the participant's base public key disclosed to the delegator and ti is the aggregated tweak returned by ''ComputeBIP32Tweak''. The scalar ti MUST be encoded as a 32-byte big-endian integer. \n\nThe transport that carries this bundle is out of scope for this proposal; implementers MAY use PSBT proprietary keys, RPC payloads, or bespoke messages as long as the delegator can authenticate the origin of the data. Delegatees SHOULD attach the witness script (or sufficient script template information) built with the tweaked keys when the delegator is expected to verify the input or enforce spending policy on change outputs.\n\nDelegators use the supplied CCD tweak bundle during verification (see ''Delegator input and change verification'') and signature generation (see ''DelegatorSign''). The message to be signed is provided separately as part of the standard signing protocol and is not part of the CCD-specific bundle.\n\n=== Signing Modes ===\nThis BIP supports two modes:\n* '''Non‑blinded.''' The delegator receives the tweak for the child public key and the message. The delegator learns only about the specific child keys and transactions it signs for; it does not learn the wider address space.\n* '''Blinded.''' The delegator receives only a blinded challenge and parity bits. The delegator learns nothing about the message or child key for which it produces a signature.\n\nBoth modes produce valid BIP340 signatures.\n\n====Non-Blinded Signing====\nFor non-blinded signing, the delegator can produce signatures as usual using the tweaked key.\n\n=====Delegator input and change verification (Optional)=====\nA delegator MAY validate the data it receives before producing signatures. \n\nFor example, input verification reassures the delegator that every tweaked key they are asked to sign for corresponds to a wallet input they recognise. Change verification lets them establish the net outflow and enforce spending policy.\n\nBoth checks rely on the same delegated tweak bundle described above.\n\n=====Input verification=====\nFor each input, the delegatee SHOULD disclose the descriptor template, the untweaked participant keys, the input witness script, and the per-participant tweaks. The delegator then applies the following procedure.\n\n
\nAlgorithm ''InputVerification(D, W, T)'':\n* Inputs:\n** ''D'': wallet policy or descriptor template expressed in terms of the untweaked participant keys ''Pi''\n** ''W'': witness script disclosed for the input under review\n** ''T'': mapping from each ''Pi'' to a 32-byte big-endian tweak scalar ''ti''\n* For each participant key ''Pi'' referenced in ''D'':\n** Retrieve ''ti'' from ''T''; fail if the entry is missing or malformed.\n** If the verifier controls the corresponding private key ''di'', let ''d′i = (di + ti) mod n'' and ''P′i = d′i · G''; otherwise let ''P′i = Pi + ti · G''.\n* Let ''D′'' be the descriptor formed by substituting every occurrence of ''Pi'' in ''D'' with ''P′i''.\n* Derive the witness script ''W′'' from ''D′''.\n* Return true if ''W′ = W'', otherwise false.\n
\n\nSuccessful verification of an input confirms that the delegator is signing for a script that belongs to the wallet and that the aggregate tweak values align with the expected policy.\n\n=====Change-output verification=====\nWhen change outputs are disclosed, the delegator can perform an analogous check to ensure the destination script matches their policy template and to calculate outflows. Let D be the descriptor expressed in untweaked keys, W the provided witness script, and T the tweak mapping:\n\n
\nAlgorithm ''ChangeOutputVerification(D, W, T)'':\n* Inputs:\n** ''D'': wallet policy or descriptor template expressed in terms of the untweaked participant keys ''Pi''\n** ''W'': witness script disclosed for the change output\n** ''T'': mapping from each ''Pi'' to a 32-byte big-endian tweak scalar ''ti''\n* For each participant key ''Pi'' referenced in ''T'':\n** Retrieve ''ti'' from ''T''; fail if the entry is missing or malformed.\n** If the verifier controls the corresponding private key ''di'', let ''d′i = (di + ti) mod n'' and ''P′i = d′i · G''; otherwise let ''P′i = Pi + ti · G''.\n* Let ''D′'' be the descriptor formed by substituting every occurrence of ''Pi'' in ''D'' with ''P′i''.\n* Derive the witness script ''W′'' from ''D′''.\n* Return true if ''W′ = W'', otherwise false.\n
\n\nSuccessful verification ensures the change output commits to the tweaked participant keys implied by the CCD tweaks, preserving the intended policy.\n\nThe delegator may perform additional application-specific verification on the transaction (e.g., recipient addresses, amounts, compliance checks) using the message ''m''. In the concurrently secure blinded mode, such policies can be enforced via zero-knowledge proofs that encode predicates about ''m''. Specification of such policies is outside the scope of this BIP.\n\n=====Delegator Signing=====\nA delegator that holds only its base secret key x and public key P uses the delegated tweak bundle to derive per-input signing keys. The delegator MAY first call ''InputVerification'' and ''ChangeOutputVerification'' on any input and change output that provides a tweak in order to confirm outflow or policy requirements before signing.\n\n
\nAlgorithm ''DelegatorSign(t, x, m)'':\n* Inputs:\n** ''t'': aggregated tweak for the signing context (scalar mod ''n'')\n** ''x'': delegator base secret key\n** ''m'': message to be signed (for example, a transaction digest under the desired SIGHASH policy)\n* Let ''x′ = (x + t) mod n''.\n* Use secret key ''x′'' to produce the required signature ''σ'' under the indicated policy.\n* Return ''σ''.\n
\n\nThe delegatee is responsible for inserting ''σ'' into the surrounding protocol (e.g., a PSBT, transaction witness, or adaptor signature exchange).\n\n====Blinded Signing====\nThe delegator learns neither the message, the challenge, or the public key used in the BIP340 signature, only a blinded challenge e'.\n\nThis blind‑signing protocol specifies how a delegator can produce a blind partial Schnorr signature that a delegatee can unblind into a standard [https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki BIP340] signature under a possibly tweaked X‑only public key. The notation, algorithmic patterns, and test‑vector style are adapted from [BIP‑327 (MuSig2)] and from the [https://github.com/siv2r/bip-frost-signing FROST Signing BIP]. The design follows the “plain” blind Schnorr flow described in Concurrently Secure Blind Schnorr Signatures ([https://eprint.iacr.org/2022/1676 ePrint 2022/1676]), but without the concurrency hardening from that work.\n\nThe output signature is a BIP340 Schnorr signature valid under an X‑only key obtained by applying a sequence of plain (e.g. BIP32) and X‑only (e.g. Tapscript) tweaks to the signer’s plain public key. Consequently the protocol is compatible with [https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki BIP341]. The delegator learns neither the message, the challenge, or the public key used in the BIP340 signature, only a blinded challenge e'.\n\nThe plain protocol here is '''not''' concurrently secure. A signer '''MUST NOT''' run multiple blind signing sessions in parallel or interleave state across sessions. A signer '''MUST''' refuse any new blind‑nonce requests while a previous blind‑signature request is outstanding, or '''MUST''' irrevocably discard (and never reuse) any in‑flight blind nonce commitments that have not resulted in a signature, before accepting new ones.\n\nTo obtain concurrency security as in ([https://eprint.iacr.org/2022/1676 ePrint 2022/1676]), the delegatee first sends an encryption of (m, a, b) before the signer commits to the blind nonce; later, the delegatee includes a zero‑knowledge proof binding the produced challenge to that encrypted tuple. That proof can additionally encode policy predicates about m (spend limits, velocity controls, etc.). A complete specification of this variant is outside the scope of this BIP.\n\nThe following sections fully specify the non-concurrent blind signing protocol.\n\n===== Overview =====\n\n* '''Round 1 (blind nonce).''' The delegator runs ''BlindNonceGen'' to produce ''blindsecnonce'' and ''blindpubnonce'' and sends ''blindpubnonce'' to the delegatee.\n* '''Round 2 (challenge).''' The delegatee runs ''BlindChallengeGen'' using the message ''m'', ''blindpubnonce'', the base public key ''pk'', and a list of ordinary and X-only tweaks, to produce a ''session context'' (kept locally for unblinding), a ''blindchallenge'', and two booleans ''pk_parity'' and ''nonce_parity''. The delegatee sends ''blindchallenge'', ''pk_parity'', and ''nonce_parity'' to the signer.\n* '''Round 3 (blind signature).''' The delegator runs ''BlindSign'' with ''sk'', ''blindchallenge'', ''blindsecnonce'', ''pk_parity'', and ''nonce_parity'' and returns ''blindsignature''. The delegatee completes by calling ''UnblindSignature'' with the stored session context and ''blindsignature'' to obtain the final BIP340 signature ''sig''.\n\n''BlindSign'' '''MUST NOT''' be executed twice with the same ''blindsecnonce''. As a defense, implementations '''SHOULD''' overwrite the first 64 bytes of ''blindsecnonce'' with zeros after they have been read by ''BlindSign''.\n\n=====Key Tweaking=====\n======Tweak Context======\nThe Tweak Context is a data structure consisting of the following elements:\n* The point ''Q'' representing the potentially tweaked public key: an elliptic curve point\n* The accumulated tweak ''tacc'': an integer with ''0 ≤ tacc < n''\n* The value ''gacc'' : 1 or -1 mod n\n\nWe write \"Let ''(Q, gacc, tacc) = tweak_ctx''\" to assign names to the elements of a Tweak Context.\n\n
\nAlgorithm ''TweakCtxInit(pk)'':\n* Input:\n** The base public key pk: a 33-byte array\n* Let ''Q = cpoint(pk)''\n* Fail if ''is_infinite(Q)''\n* Let ''gacc = 1''\n* Let ''tacc = 0''\n* Return ''tweak_ctx = (Q, gacc, tacc)''\n
\n\n
\nAlgorithm ''ApplyTweak(tweak_ctx, tweak, is_xonly_t)'':\n* Inputs:\n** The ''tweak_ctx'': a [[#tweak-context|Tweak Context]] data structure\n** The ''tweak'': a 32-byte array\n** The tweak mode ''is_xonly_t'': a boolean\n* Let ''(Q, gacc, tacc) = tweak_ctx''\n* If ''is_xonly_t'' and ''not has_even_y(Q)'':\n** Let ''g = -1 mod n''\n* Else:\n** Let ''g = 1''\n* Let ''t = int(tweak)''; fail if ''t ≥ n''\n* Let ''Q' = g⋅Q + t⋅G''\n** Fail if ''is_infinite(Q')''\n* Let ''gacc' = g⋅gacc mod n''\n* Let ''tacc' = t + g⋅tacc mod n''\n* Return ''tweak_ctx' = (Q', gacc', tacc')''\n
\n\n=====Blind Nonce Generation=====\n\n
\nAlgorithm ''BlindNonceGen(sk, pk, aggpk, m, extra_in)'':\n* Inputs:\n** The base secret signing key ''sk'': a 32-byte array (optional argument)\n** The base public key ''pk'': a 33-byte array (optional argument)\n** The auxiliary input ''extra_in'': a byte array with ''0 ≤ len(extra_in) ≤ 232-1'' (optional argument)\n* Let ''rand' '' be a 32-byte array freshly drawn uniformly at random\n* If the optional argument ''sk'' is present:\n** Let ''rand'' be the byte-wise xor of ''sk'' and ''hash256CCD/aux(rand')''The random data is hashed (with a unique tag) as a precaution against situations where the randomness may be correlated with the secret signing key itself. It is xored with the secret key (rather than combined with it in a hash) to reduce the number of operations exposed to the actual secret key.\n* Else:\n** Let ''rand = rand' ''\n* If the optional argument ''extra_in'' is not present:\n** Let ''extra_in = empty_bytestring''\n* Let ''k' = int(hash256CCD/blindnonce(rand || bytes(1, len(pk)) || pk || bytes(4, len(extra_in)) || extra_in )) mod n''\n* Fail if ''k' = 0''\n* Let ''R' = k'⋅G''\n* Let ''blindpubnonce = cbytes(R')''\n* Let ''blindsecnonce = bytes(32, k' || pk)''The algorithms as specified here assume that the ''blindsecnonce'' is stored as a 65-byte array using the serialization ''blindsecnonce = bytes(32, k') || pk''. The same format is used in the reference implementation and in the test vectors. However, since the ''blindsecnonce'' is not meant to be sent over the wire, compatibility between implementations is not a concern, and this method of storing the ''blindsecnonce'' is merely a suggestion.
\nThe ''blindsecnonce'' is effectively a local data structure of the signer which comprises the value double ''(k', pk)'', and implementations may choose any suitable method to carry it from ''BlindNonceGen'' (first communication round) to ''BlindSign'' (third communication round). In particular, implementations may choose to hide the ''blindsecnonce'' in internal state without exposing it in an API explicitly, e.g., in an effort to prevent callers from reusing a ''blindsecnonce'' accidentally.\n* Return ''(secnonce, pubnonce)''\n
\n\n=====Session Context=====\n\nThe Session Context is a data structure consisting of the following elements:\n* The base public key ''pk'': a 33-byte array\n* The blind factor ''blindfactor'': a 32-byte array\n* The challenge hash ''challenge'': a 32-byte array\n* The public nonce ''pubnonce'': a 33-byte array\n* The number ''v'' of tweaks with ''0 ≤ v < 2^32''\n* The tweaks ''tweak1..v'': ''v'' 32-byte arrays\n* The tweak modes ''is_xonly_t1..v'' : ''v'' booleans\n\nWe write \"Let ''(pk, blindfactor, challenge, pubnonce, v, tweak1..v, is_xonly_t1..v) = session_ctx''\" to assign names to the elements of a Session Context.\n\n
\nAlgorithm ''GetSessionValues(session_ctx)'':\n* Let ''(pk, blindfactor, challenge, pubnonce, v, tweak1..v, is_xonly_t1..v) = session_ctx''\n* Let ''tweak_ctx0 = TweakCtxInit(pk)''; fail if that fails\n* For ''i = 1 .. v'':\n** Let ''tweak_ctxi = ApplyTweak(tweak_ctxi-1, tweaki, is_xonly_ti)''; fail if that fails\n* Let ''(Q, gacc, tacc) = tweak_ctxv''\n* Let ''a = int(blindfactor)''; fail if ''a ≥ n''\n* Let ''b = int(blindfactor)''; fail if ''b ≥ n''\n* Let ''e = int(challenge)''; fail if ''e ≥ n''\n* Let ''R = cpoint(pubnonce)''; fail if that fails\n* Return ''(Q, gacc, tacc, a, e, R)''\n
\n\n=====Blind Challenge Generation=====\n\n
\nAlgorithm ''BlindChallengeGen(m, blindpubnonce, pk, tweak1..v, is_xonly1..v, extra_in)'':\n* Inputs:\n** The message ''m'': a byte array\n** The blind public nonce ''blindpubnonce'': a 33-byte array\n** The base public key ''pk'': a 33-byte array\n** The tweaks ''tweak1..v'': ''v'' 32-byte arrays\n** The tweak modes ''is_xonly1..v'': ''v'' booleans \n** The auxiliary input ''extra_in'': a byte array with ''0 ≤ len(extra_in) ≤ 232-1'' (optional argument)\n* If ''extra_in'' is not present:\n** Let ''extra_in = empty_bytestring''\n* Let ''(Q, gacc, tacc) = TweakCtxInit(pk)''\n* For ''i = 1 .. v'':\n** Let ''(Q, gacc, tacc) = ApplyTweak((Q, gacc, tacc), tweaki, is_xonlyi)''; fail if that fails \n* Let ''cpk = cbytes(Q)''\n* Draw 32 random bytes ''rand''\n* Let ''z = hash512CCD/blindfactor(rand || bytes(1, len(cpk)) || cpk || bytes(1, len(blindpubnonce)) || blindpubnonce || bytes(8, len(m)) || m || bytes(4, len(extra_in)) || extra_in)''\n* Let ''a' = int(z[0:32]) mod n''; fail if ''a' = 0''\n* Let ''b' = int(z[32:64]) mod n''; fail if ''b' = 0''\n* Let ''g = 1'' if ''has_even_y(Q)'', else ''g = −1 mod n''\n* Let ''pk_parity = (g⋅gacc mod n == 1)''\n* Let ''X' = cpoint(pk)''; let ''X = X' '' if ''pk_parity'' else ''−X' ''\n* Let ''R' = cpoint(blindpubnonce)''\n* Let ''R = R' + a'⋅G + b'⋅X''; fail if ''is_infinite(R)''\n* Let ''nonce_parity = has_even_y(R)''\n* If ''nonce_parity'':\n** Let ''a = a' '', ''b = b' ''\n* Else:\n** Let ''a = n − a' '', ''b = n − b' ''\n* Let ''e = int(hashBIP0340/challenge(xbytes(R) || xbytes(Q) || m)) mod n''\n* Let ''e' = (e + b) mod n''\n* Let ''session_ctx = (pk, bytes(32, a), bytes(32, e), cbytes(R), tweak1..v, is_xonly1..v)''\n* Return ''(session_ctx, bytes(32, e'), pk_parity, nonce_parity)''\n
\n\n=====Blind Signing=====\n\n
\nAlgorithm ''BlindSign(sk, blindchallenge, blindsecnonce, pk_parity, nonce_parity)'':\n* Inputs:\n** The secret key ''sk'': a 32-byte array\n** The blind challenge ''blindchallenge'': a 32-byte array ''e' ''\n** The secret nonce ''blindsecnonce'': a byte array whose first 32 bytes are ''k'' (remaining bytes are implementation-defined)\n** ''pk_parity'': boolean (from ''BlindChallengeGen'')\n** ''nonce_parity'': boolean (from ''BlindChallengeGen'')\n* Let ''d' = int(sk)''; fail if ''d' = 0'' or ''d' ≥ n''\n* Let ''P = d'⋅G''; fail if ''is_infinite(P)''\n* Let ''d = d' '' if ''pk_parity'' else ''n − d' ''\n* Let ''e' = int(blindchallenge)''; fail if ''e' ≥ n''\n* Let ''k' = int(blindsecnonce[0:32])''; fail if ''k' = 0'' or ''k' ≥ n''\n* Let ''k = k' '' if ''nonce_parity'' else ''n − k' ''\n* Overwrite ''blindsecnonce[0:64]'' with 64 zero bytes This helps prevent accidental nonce reuse. A zeroed ''blindsecnonce'' MUST cause subsequent ''BlindSign'' calls to fail.\n* Let ''R' = k'⋅G''; fail if ''is_infinite(R')'' This check holds except with negligible probability.\n* Let ''s' = (k + e'⋅d) mod n''\n* If ''VerifyBlindSignature(cbytes(P), cbytes(R'), blindchallenge, bytes(32, s'), pk_parity, nonce_parity)'' returns failure, abort\n* Return ''blindsignature = bytes(32, s')''\n
\n\n
\nAlgorithm ''VerifyBlindSignature(pk, blindpubnonce, blindchallenge, blindsignature, pk_parity, nonce_parity)'':\n* Inputs:\n** ''pk'': a 33-byte compressed public key\n** ''blindpubnonce'': the signer’s 33-byte ''R' = k'⋅G''\n** ''blindchallenge'': 32-byte ''e' ''\n** ''blindsignature'': 32-byte ''s' ''\n** ''pk_parity, nonce_parity'': booleans\n* Let ''P' ' = cpoint(pk)''; let ''P = P' '' if ''pk_parity'' else ''−P' '' ; fail if ''is_infinite(P)''\n* Let ''R' ' = cpoint(blindpubnonce)''; let ''R = R' '' if ''nonce_parity'' else ''−R' ''\n* Let ''e' = int(blindchallenge)'', ''s' = int(blindsignature)''\n* Return success iff ''s'⋅G == R + e'⋅P''\n
\n\n=====Unblinding=====\n\n
\nAlgorithm ''UnblindSignature(session_ctx, blindsignature)'':\n* Inputs:\n** ''session_ctx'': as defined above\n** ''blindsignature'': the 32-byte ''s' '' returned by the signer\n* Let ''(Q, gacc, tacc, a, e, R) = GetSessionValues(session_ctx)''; fail if that fails\n* Let ''g = 1'' if ''has_even_y(Q)'', else ''g = −1 mod n''\n* Let ''s' = int(blindsignature)''; fail if ''s' ≥ n''\n* Let ''s = (s' + a + e⋅g⋅tacc) mod n''\n* Return the BIP340 signature ''sig = xbytes(R) || bytes(32, s)''\n
\n\n== Security Considerations ==\n* Exposure of any delegated tweak scalar t enables signing only for the specific child key(s) that scalar was derived for, and is typically short-lived if disclosed immediately before spending.\n* Delegatees MUST ensure every delegated path remains non-hardened and that ''ComputeBIP32Tweak'' yields the correct tweak t; incorrect scalars could render the delegator incapable of producing a signature.\n* Delegators MUST verify change outputs when tweak data is provided (for example via ''ChangeOutputVerification'') to avoid authorizing unexpected scripts.\n* Reusing the same k' (first 32 bytes in blindsecnonce) across two BlindSign calls allows recovery of the base secret key.\n* When using blinded signing, opening multiple sessions concurrently against the same signer can allow an attacker to learn the base secret key. If concurrency is required, use the concurrently secure variant (encryption + ZK) instead (not specified in this BIP).\n\n== Test Vectors ==\nA [[bip-0089/vectors|collection of JSON test vectors]] are provided, along with a [[bip-0089/reference.py|python reference implementation]].\nIt uses a vendored copy of the [https://github.com/secp256k1lab/secp256k1lab/ secp256k1lab] library\n(commit [https://github.com/secp256k1lab/secp256k1lab/commit/a265da139aea27386085a2a8760f8698e1bda64e\na265da139aea27386085a2a8760f8698e1bda64e]).\n\nYou may also find example code of CCD in action [https://github.com/jurvis/chaincode-delegation here].\n\n== Changelog ==\n\n* '''0.1.3''' (2026-02-02): Upgrade secp256k1lab and add license file; fix type checker and linter issues; clarify Delegator/Delegatee terminology, derivation constraints, signing modes, and verification scope.\n* '''0.1.2''' (2025-12-03): Updated to reflect BIP number assignment.\n* '''0.1.1''' (2025-11-30): Fix acknowledgments spelling, BIP3 formatting, and use \"Chain Code\" with a space throughout.\n* '''0.1.0''' (2025-10-14): Publication of draft BIP\n\n== Acknowledgements ==\n* Arik Sosman and Wilmer Paulino for the initial discussions and validation of this idea. \n* Sanket Kajalkar, Jordan Mecom, Gregory Sanders, ZmnSCPxj, Yuval Kogman, and John Cantrell for code and design review.\n\n== Copyright ==\nThis BIP is licensed under the BSD 3-Clause license.", "category": "bips" }, { "instruction": "I'm stuck with 
 - what should I check?",
    "input": "",
    "output": "BIP: 106\n  Layer: Consensus (hard fork)\n  Title: Dynamically Controlled Bitcoin Block Size Max Cap\n  Authors: Upal Chakraborty \n  Status: Closed\n  Type: Specification\n  Assigned: 2015-08-24\n
\n\n==Abstract==\n\nThis BIP proposes replacing the fixed one megabyte maximum block size with a dynamically controlled maximum block size that may increase or decrease with difficulty change depending on various network factors. I have two proposals regarding this...\n\ni. Depending only on previous block size calculation.\n\nii. Depending on previous block size calculation and previous Tx fee collected by miners.\n\n==Motivation==\n\nWith increased adoption, transaction volume on bitcoin network is bound to grow. If the one megabyte max cap is not changed to a flexible one which changes itself with changing network demand, then adoption will hamper and bitcoin's growth may choke up. Following graph shows the change in average block size since inception...\n\nhttps://blockchain.info/charts/avg-block-size?timespan=all&showDataPoints=false&daysAverageString=1&show_header=true&scale=0&address=\n\n==Specification==\n\n===Proposal 1 : Depending only on previous block size calculation===\n\n If more than 50% of block's size, found in the first 2000 of the last difficulty period, is more than 90% MaxBlockSize\n Double MaxBlockSize\n Else if more than 90% of block's size, found in the first 2000 of the last difficulty period, is less than 50% MaxBlockSize\n Half MaxBlockSize\n Else\n Keep the same MaxBlockSize\n\n===Proposal 2 : Depending on previous block size calculation and previous Tx fee collected by miners===\n\n TotalBlockSizeInLastButOneDifficulty = Sum of all Block size of first 2008 blocks in last 2 difficulty period\n TotalBlockSizeInLastDifficulty = Sum of all Block size of second 2008 blocks in last 2 difficulty period (This actually includes 8 blocks from last but one difficulty)\n\n TotalTxFeeInLastButOneDifficulty = Sum of all Tx fees of first 2008 blocks in last 2 difficulty period\n TotalTxFeeInLastDifficulty = Sum of all Tx fees of second 2008 blocks in last 2 difficulty period (This actually includes 8 blocks from last but one difficulty)\n\n If ( ( (Sum of first 4016 block size in last 2 difficulty period)/4016 > 50% MaxBlockSize) AND (TotalTxFeeInLastDifficulty > TotalTxFeeInLastButOneDifficulty) AND (TotalBlockSizeInLastDifficulty > TotalBlockSizeInLastButOneDifficulty) )\n MaxBlockSize = TotalBlockSizeInLastDifficulty * MaxBlockSize / TotalBlockSizeInLastButOneDifficulty\n Else If ( ( (Sum of first 4016 block size in last 2 difficulty period)/4016 < 50% MaxBlockSize) AND (TotalTxFeeInLastDifficulty < TotalTxFeeInLastButOneDifficulty) AND (TotalBlockSizeInLastDifficulty < TotalBlockSizeInLastButOneDifficulty) )\n MaxBlockSize = TotalBlockSizeInLastDifficulty * MaxBlockSize / TotalBlockSizeInLastButOneDifficulty\n Else\n Keep the same MaxBlockSize\n\n==Rationale==\n\nThese two proposals have been derived after discussion on [https://bitcointalk.org/index.php?topic=1154536.0 BitcoinTalk] and [http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010285.html bitcoin-dev mailing list]. The original idea and its evolution in the light of various arguments can be found [http://upalc.com/maxblocksize.php here].\n\n===Proposal 1 : Depending only on previous block size calculation===\n\nThis solution is derived directly from the indication of the problem. If transaction volume increases, then we will naturally see bigger blocks. On the contrary, if there are not enough transaction volume, but maximum block size is high, then only few blocks may sweep the mempool. Hence, if block size is itself taken into consideration, then maximum block size can most rationally be derived. Moreover, this solution not only increases, but also decreases the maximum block size, just like difficulty.\n\n===Proposal 2 : Depending on previous block size calculation and previous Tx fee collected by miners===\n\nThis solution takes care of stable mining subsidy. It will not increase maximum block size, if Tx fee collection is not increasing and thereby creating a Tx fee pressure on the market. On the other hand, though the block size max cap is dynamically controlled, it is very difficult to game by any party because the increase or decrease of block size max cap will take place in the same ratio of average block size increase or decrease.\n\n==Compatibility==\n\nThis is a hard-forking change to the Bitcoin protocol; anybody running code that fully validates blocks must upgrade before the activation time or they will risk rejecting a chain containing larger-than-one-megabyte blocks.\n\n==Other solutions considered==\n\n[http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf Making Decentralized Economic Policy] - by Jeff Garzik\n\n[https://bitcointalk.org/index.php?topic=1078521.0 Elastic block cap with rollover penalties] - by Meni Rosenfeld\n\n[https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki Increase maximum block size] - by Gavin Andresen\n\n[https://gist.github.com/sipa/c65665fc360ca7a176a6 Block size following technological growth] - by Pieter Wuille\n\n[https://lightning.network/lightning-network-paper.pdf The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments] - by Joseph Poon & Thaddeus Dryja\n\n==Deployment==\n\nIf consensus is achieved, deployment can be made at a future block number at which difficulty will change.", "category": "bips" }, { "instruction": "How do I troubleshoot 
 issues?",
    "input": "",
    "output": "BIP: 124\n  Layer: Applications\n  Title: Hierarchical Deterministic Script Templates\n  Authors: Eric Lombrozo \n           William Swanson \n  Status: Closed\n  Type: Informational\n  Assigned: 2015-11-20\n  License: PD\n  Discussion: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-November/011795.html\n
\n\n==Abstract==\n\nThis BIP defines a script template format that can be used by wallets to deterministically generate scripts with specific authorization policies using the key derivation mechanism defined in BIP32.\n\n==Motivation==\n\nCurrently existing wallets typically issue scripts in only a tiny handful of widely used formats. The most popular formats are pay-to-pubkey-hash and m-of-n pay-to-script-hash (BIP16). However, different wallets tend to use mutually incompatible derivation schemes to generate signing keys and construct scripts from them. Moreover, with the advent of hashlocked and timelocked contracts (BIP65, BIP112), it is necessary for different wallets to be able to cooperatively generate even more sophisticated scripts.\n\nIn addition, there's a lot of ongoing work in the development of multilayered protocols that use the blockchain as a settlement layer (i.e. the Lightning Network). These efforts require sufficiently generalized templates to allow for rapidly evolving script designs.\n\nThis BIP provides a generalized format for constructing a script template that guarantees that different wallets will all produce the same scripts for a given set of derivation paths according to BIP32.\n\n==Specification==\n\n===Keys===\n\nAn individual key is determined by a BIP32 derivation path and an index. For convenience, we introduce the following notation:\n\n'''A'''k = (derivation path for A)/k\n\n===Key Groups===\n\nLet '''m'''i denote distinct BIP32 derivation paths. We define a key group of n keys as a set of key derivation paths with a free index k:\n\n{'''K'''k} = { '''m'''1/k, '''m'''2/k, '''m'''3/k, ..., '''m'''n/k }\n\nKey groups are useful for constructing scripts that are symmetric in a set of keys. Scripts are symmetric in a set of keys if the semantics of the script is unaffected by permutations of the keys. Key groups enforce a canonical form and can improve privacy.\n\n===Sorting===\n\nWe define a lexicographic sorting of the keys. (TODO: specification of sorting conventions - compressed pubkeys, encoding, etc...)\n\nDefine {'''K'''k}j to be the jth element of the sorted keys for derivation index k.\n\n===Script Templates===\n\nWe construct script templates by inserting placeholders for data into a script. To denote a placeholder, we use the following notation:\n\n''Script''('''A''') = opcodes ['''A'''] opcodes\n\nWe extend this notation to an arbitrary number of placeholders:\n\n''Script''('''X1''', '''X2''', ..., '''Xn''') = opcodes ['''X1'''] opcodes ['''X2'''] opcodes ... opcodes ['''Xn'''] opcodes\n\nWe introduce the following convenient notation for sorted key groups:\n\n[{'''K'''k}] = [{'''K'''k}1] [{'''K'''k}2] ... [{'''K'''k}n]\n\n===Operations on Keys===\n\nIn some applications, we might want to insert the result of some operation performed on a key rather than the key itself into the script. For example, we might want to insert a Hash160 of key '''A'''k. We can use the following notation:\n\n[''Hash160''('''A'''k)]\n\n===Encoding===\n\nTODO\n\n==Examples==\n\n===2-of-3 Multisig===\n\nThe script template is defined by:\n\n''Script''('''X''') = 2 ['''X'''] 3 OP_CHECKMULTISIG\n\nLetting '''K'''k = { '''m'''1/k, '''m'''2/k, '''m'''3/k }, the ''k''th script for this key group is denoted by ''Script''({'''K'''k}).\n\n===1-of-1 or 2-of-3===\n\nThe script template is defined by:\n\n''Script''('''A''', '''B''') =
\n        OP_DUP ['''A'''] OP_CHECKSIG
\n        OP_NOTIF
\n                2 ['''B'''] 3 OP_CHECKMULTISIGVERIFY
\n        OP_NOTIF
\n        OP_ENDIF
\n        OP_TRUE
\n\nLet '''M'''k = '''m'''/k be a key of a superuser that can authorize all transactions and {'''K'''k} be a key group of three users that can only authorize transactions if at least two of them agree.\n\nThe ''k''th script is given by ''Script''('''M'''k, {'''K'''k}).\n\n===Timelocked Contract===\n\nThe output is payable to Alice immediately if she knows the private key for '''A'''k. Bob must know the private key for '''B'''k and also wait for a timeout '''t''' before being able to spend the output.\n\nThe script template is defined by:\n\n''Script''('''A''', '''B''', '''T''') =
\n        OP_IF
\n                OP_DUP OP_HASH160 [''Hash160''('''A''')] OP_EQUALVERIFY OP_CHECKSIG
\n        OP_ELSE
\n                ['''T'''] OP_CHECKLOCKTIMEVERIFY OP_DROP
\n                OP_DUP OP_HASH160 [''Hash160''('''B''')] OP_EQUALVERIFY OP_CHECKSIG
\n        OP_ENDIF\n\nThe ''k''th script with timeout '''t''' is given by ''Script''('''A'''k, '''B'''k, '''t''').\n\n==References==\n\n* [[bip-0016.mediawiki|BIP16 - Pay to Script Hash]]\n* [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]]\n* [[bip-0065.mediawiki|BIP65 - OP_CHECKLOCKTIMEVERIFY]]\n* [[bip-0112.mediawiki|BIP112 - CHECKSEQUENCEVERIFY]]\n* [[https://lightning.network/lightning-network-paper.pdf|Lightning Network Whitepaper]]\n\n==Copyright==\n\nThis document is placed in the public domain.", "category": "bips" }, { "instruction": "What are the best practices for 
?",
    "input": "",
    "output": "BIP: 149\n  Layer: Consensus (soft fork)\n  Title: Segregated Witness (second deployment)\n  Authors: Shaolin Fry \n  Status: Closed\n  Type: Specification\n  Assigned: 2017-04-14\n  License: BSD-3-Clause OR CC0-1.0\n
\n\n==Abstract==\n\nThis document specifies a user activated soft fork for [[bip-0141.mediawiki|BIP141]], [[bip-0143.mediawiki|BIP143]] and [[bip-0147.mediawiki|BIP147]] using versionbits with guaranteed lock-in.\n\n==Motivation==\n\nMiners have been reluctant to signal the BIP9 segwit deployment despite a large portion of the Bitcoin ecosystem who want the soft fork activated. This BIP specifies a user activated soft fork (UASF) that deploys segwit again using versionbits with guaranteed lock-in on timeout if the BIP is not already locked-in or activated by the timeout. This ensures users have sufficient time to prepare and no longer require a miner supermajority, while still allowing for an earlier miner activated soft fork (MASF).\n\n==Reference implementation==\n\nThe reference implementation will refuse to run on Bitcoin mainnet before 7 November 2017, and can only be run on testnet and regtest until then.\n\nhttps://github.com/bitcoin/bitcoin/compare/master...shaolinfry:uasegwit-flagday\n\n==Specification==\n\nThis deployment will set service bit (1<<5) as NODE_UAWITNESS.\n\n==Deployment==\n\nThis BIP should only be deployed if BIP9-segwit fails to lock-in or activate before timeout on 15 November 2017. This BIP cannot be deployed before 15 November 2017.\n\nThis BIP will be deployed by BIP8 with the name \"segwit\" and using bit 1.\n\nFor Bitcoin mainnet, the BIP8 starttime will be midnight 16 November 2017 UTC (Epoch timestamp 1510790400) and BIP8 timeout will be 4 July 2018 UTC (Epoch timestamp 1530662400).\n\nFor Bitcoin testnet, segwit is already activated so no deployment is specified.\n\n==Backwards Compatibility==\n\nThis deployment reuses the GBT deployment name \"segwit\" to maintain compatibility with existing mining software.\n\nThis deployment is incompatible with the BIP9-segwit deployment and should not be run concurrently with it.\n\n==Rationale==\n\nThe '''starttime''' of this BIP is after the BIP9-segwit timeout to remove compatibility issues with old nodes.\n\n==References==\n\n[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014234.html Mailing list discussion]\n\n[[bip-0008.mediawiki|BIP8]]\n\n[[bip-0009.mediawiki|BIP9]]\n\n[[bip-0141.mediawiki|BIP141]]\n\n[[bip-0143.mediawiki|BIP143]]\n\n[[bip-0147.mediawiki|BIP147]]\n\n==Copyright==\n\nThis document is dual licensed as BSD 3-clause, and Creative Commons CC0 1.0 Universal.", "category": "bips" }, { "instruction": "Walk me through setting up 
 step by step",
    "input": "",
    "output": "BIP: 22\n  Layer: API/RPC\n  Title: getblocktemplate - Fundamentals\n  Authors: Luke Dashjr \n  Status: Deployed\n  Type: Specification\n  Assigned: 2012-02-28\n  License: BSD-2-Clause\n
\n\n==Abstract==\n\nThis BIP describes a new JSON-RPC method for \"smart\" Bitcoin miners and proxies.\nInstead of sending a simple block header for hashing, the entire block structure is sent, and left to the miner to (optionally) customize and assemble.\n\n==Copyright==\n\nThis BIP is licensed under the BSD 2-clause license.\n\n==Specification==\n\n===Block Template Request===\n\nA JSON-RPC method is defined, called \"getblocktemplate\".\nIt accepts exactly one argument, which MUST be an Object of request parameters.\nIf the request parameters include a \"mode\" key, that is used to explicitly select between the default \"template\" request or a [[bip-0023.mediawiki#block-proposal|\"proposal\"]].\n\nBlock template creation can be influenced by various parameters:\n{| class=\"wikitable\"\n!colspan=4|template request\n|-\n! Key !! Required !! Type !! Description\n|-\n| capabilities || No || Array of Strings || SHOULD contain a list of the following, to indicate client-side support: [[#optional-long-polling|\"longpoll\"]], \"coinbasetxn\", \"coinbasevalue\", [[bip-0023.mediawiki#block-proposal|\"proposal\"]], [[bip-0023.mediawiki#logical-services|\"serverlist\"]], \"workid\", and any of the [[bip-0023.mediawiki#mutations|mutations]]\n|-\n| mode || No || String || MUST be \"template\" or omitted\n|}\n\ngetblocktemplate MUST return a JSON Object containing the following keys:\n{| class=\"wikitable\"\n!colspan=4| template\n|-\n! Key !! Required !! Type !! Description\n|-\n| bits || Yes || String || the compressed difficulty in hexadecimal\n|-\n| curtime || Yes || Number || the current time as seen by the server (recommended for block time) - note this is not necessarily the system clock, and must fall within the mintime/maxtime rules\n|-\n| height || Yes || Number || the height of the block we are looking for\n|-\n| previousblockhash || Yes || String || the hash of the previous block, in big-endian hexadecimal\n|-\n| sigoplimit || No || Number || number of sigops allowed in blocks\n|-\n| sizelimit || No || Number || number of bytes allowed in blocks\n|-\n| transactions || Should || Array of Objects || Objects containing [[#transactions-object-format|information for Bitcoin transactions]] (excluding coinbase)\n|-\n| version || Yes || Number || always 1 or 2 (at least for bitcoin) - clients MUST understand the implications of the version they use (eg, comply with [[bip-0034.mediawiki|BIP 0034]] for version 2)\n|-\n| coinbaseaux || No || Object || data that SHOULD be included in the coinbase's scriptSig content. Only the values (hexadecimal byte-for-byte) in this Object should be included, not the keys. This does not include the block height, which is required to be included in the scriptSig by [[bip-0034.mediawiki|BIP 0034]]. It is advisable to encode values inside \"PUSH\" opcodes, so as to not inadvertently expend SIGOPs (which are counted toward limits, despite not being executed).\n|-\n| coinbasetxn || this or ↓ || Object || [[#transactions-object-format|information for coinbase transaction]]\n|-\n| coinbasevalue || this or ↑ || Number || total funds available for the coinbase (in Satoshis)\n|-\n| workid || No || String || if provided, this value must be returned with results (see [[#block-submission|Block Submission]])\n|}\n\n==== Transactions Object Format ====\n\nThe Objects listed in the response's \"transactions\" key contains these keys:\n\n{| class=\"wikitable\"\n!colspan=3|template \"transactions\" element\n|-\n! Key !! Type !! Description\n|-\n| data || String || transaction data encoded in hexadecimal (byte-for-byte)\n|-\n| depends || Array of Numbers || other transactions before this one (by 1-based index in \"transactions\" list) that must be present in the final block if this one is; if key is not present, dependencies are unknown and clients MUST NOT assume there aren't any\n|-\n| fee || Number || difference in value between transaction inputs and outputs (in Satoshis); for coinbase transactions, this is a negative Number of the total collected block fees (ie, not including the block subsidy); if key is not present, fee is unknown and clients MUST NOT assume there isn't one\n|-\n| hash || String || hash/id encoded in little-endian hexadecimal\n|-\n| required || Boolean || if provided and true, this transaction must be in the final block\n|-\n| sigops || Number || total number of SigOps, as counted for purposes of block limits; if key is not present, sigop count is unknown and clients MUST NOT assume there aren't any\n|}\n\nOnly the \"data\" key is required, but servers should provide the others if they are known.\n\n===Block Submission===\n\nA JSON-RPC method is defined, called \"submitblock\", to submit potential blocks (or shares).\nIt accepts two arguments:\nthe first is always a String of the hex-encoded block data to submit;\nthe second is an Object of parameters, and is optional if parameters are not needed.\n\n{| class=\"wikitable\"\n!colspan=3|submitblock parameters (2nd argument)\n|-\n! Key !! Type !! Description\n|-\n| workid || String || if the server provided a workid, it MUST be included with submissions\n|}\n\nThis method MUST return either null (when a share is accepted), a String describing briefly the reason the share was rejected, or an Object of these with a key for each merged-mining chain the share was submitted to.\n\n===Optional: Long Polling===\n\n{| class=\"wikitable\"\n! colspan=\"3\" | template request\n|-\n! Key !! Type !! Description\n|-\n| capabilities || Array of Strings || miners which support long polling SHOULD provide a list including the String \"longpoll\"\n|-\n| longpollid || String || \"longpollid\" of job to monitor for expiration; required and valid only for long poll requests\n|}\n\n{| class=\"wikitable\"\n! colspan=\"3\" | template\n|-\n! Key !! Type !! Description\n|-\n| longpollid || String || identifier for long poll request; MUST be omitted if the server does not support long polling\n|-\n| longpolluri || String || if provided, an alternate URI to use for long poll requests\n|-\n| submitold || Boolean || only relevant for long poll responses: indicates if work received prior to this response remains potentially valid (default) and should have its shares submitted; if false, the miner may wish to discard its share queue\n|}\n\nIf the server supports long polling, it MUST include a \"longpollid\" key in block templates, and it MUST be unique for each event:\nany given \"longpollid\" should check for only one condition and not be reused.\nFor example, a server which has a long poll wakeup only for new blocks might use the previous block hash.\nHowever, clients should not assume the \"longpollid\" has any specific meaning.\nIt MAY supply the \"longpolluri\" key with a relative or absolute URI, which MAY specify a completely different resource than the original connection, including port number.\nIf \"longpolluri\" is provided by the server, clients MUST only attempt to use that URI for longpoll requests.\n\nClients MAY start a longpoll request with a standard JSON-RPC request (in the case of HTTP transport, POST with data) and same authorization, setting the \"longpollid\" parameter in the request to the value provided by the server.\n\nThis request SHOULD NOT be processed nor answered by the server until it wishes to replace the current block data as identified by the \"longpollid\".\nClients SHOULD make this request with a very long request timeout and MUST accept servers sending a partial response in advance (such as HTTP headers with \"chunked\" Transfer-Encoding), and only delaying the completion of the final JSON response until processing.\n\nUpon receiving a completed response:\n* Only if \"submitold\" is provided and false, the client MAY discard the results of past operations and MUST begin working on the new work immediately.\n* The client SHOULD begin working on the new work received as soon as possible, if not immediately.\n* The client SHOULD make a new request to the same long polling URI.\n\nIf a client receives an incomplete or invalid response, it SHOULD retry the request with an exponential backoff.\nClients MAY implement this backoff with limitations (such as maximum backoff time) or any algorithm as deemed suitable.\nIt is, however, forbidden to simply retry immediately with no delay after more than one failure.\nIn the case of a \"Forbidden\" response (for example, HTTP 403), a client SHOULD NOT attempt to retry without user intervention.\n\n===Optional: Template Tweaking===\n\n{| class=\"wikitable\"\n! colspan=\"3\" | template request\n|-\n! Key !! Type !! Description\n|-\n| sigoplimit || Number or Boolean || maximum number of sigops to include in template\n|-\n| sizelimit || Number or Boolean || maximum number of bytes to use for the entire block\n|-\n| maxversion || Number || highest block version number supported\n|}\n\nFor \"sigoplimit\" and \"sizelimit\", negative values and zero are offset from the server-determined block maximum.\nIf a Boolean is provided and true, the default limit is used; if false, the server is instructed not to use any limits on returned template.\nServers SHOULD respect these desired maximums, but are NOT required to:\nclients SHOULD check that the returned template satisfies their requirements appropriately.\n\n===Appendix: Example Rejection Reasons===\nPossible reasons a share may be rejected include, but are not limited to:\n{| class=\"wikitable\"\n!colspan=2| share rejection reasons\n|-\n! Reason !! Description\n|-\n| bad-cb-flag || the server detected a feature-signifying flag that it does not allow\n|-\n| bad-cb-length || the coinbase was too long (bitcoin limit is 100 bytes)\n|-\n| bad-cb-prefix || the server only allows appending to the coinbase, but it was modified beyond that\n|-\n| bad-diffbits || \"bits\" were changed\n|-\n| bad-prevblk || the previous-block is not the one the server intends to build on\n|-\n| bad-txnmrklroot || the block header's merkle root did not match the transaction merkle tree\n|-\n| bad-txns || the server didn't like something about the transactions in the block\n|-\n| bad-version || the version was wrong\n|-\n| duplicate || the server already processed this block data\n|-\n| high-hash || the block header did not hash to a value lower than the specified target\n|-\n| rejected || a generic rejection without details\n|-\n| stale-prevblk || the previous-block is no longer the one the server intends to build on\n|-\n| stale-work || the work this block was based on is no longer accepted\n|-\n| time-invalid || the time was not acceptable\n|-\n| time-too-new || the time was too far in the future\n|-\n| time-too-old || the time was too far in the past\n|-\n| unknown-user || the user submitting the block was not recognized\n|-\n| unknown-work || the template or workid could not be identified\n|}\n\n==Motivation==\n\nbitcoind's JSON-RPC server can no longer support the load of generating the work required to productively mine Bitcoin, and external software specializing in work generation has become necessary.\nAt the same time, new independent node implementations are maturing to the point where they will also be able to support miners.\n\nA common standard for communicating block construction details is necessary to ensure compatibility between the full nodes and work generation software.\n\n==Rationale==\nWhy not just deal with transactions as hashes (txids)?\n* Servers might not have access to the transaction database, or miners may wish to include transactions not broadcast to the network as a whole.\n* Miners may opt not to do full transaction verification, and may not have access to the transaction database on their end.\n\nWhat is the purpose of \"workid\"?\n* If servers allow all mutations, it may be hard to identify which job it is based on. While it may be possible to verify the submission by its content, it is much easier to compare it to the job issued. It is very easy for the miner to keep track of this. Therefore, using a \"workid\" is a very cheap solution to enable more mutations.\n\nWhy should \"sigops\" be provided for transactions?\n* Due to the [[bip-0016.mediawiki|BIP 0016]] changes regarding rules on block sigops, it is impossible to count sigops from the transactions themselves (the sigops in the scriptCheck must also be included in the count).\n\n==Reference Implementation==\n\n* [https://gitorious.org/bitcoin/eloipool Eloipool (server)]\n* [http://gitorious.org/bitcoin/libblkmaker libblkmaker (client)]\n* [https://github.com/bitcoin/bitcoin/pull/936/files bitcoind (minimal server)]\n\n==See Also==\n* [[bip-0023.mediawiki|BIP 23: getblocktemplate - Pooled Mining]]", "category": "bips" }, { "instruction": "What commands would you run to work with 
?",
    "input": "",
    "output": "BIP: 144\n  Layer: Peer Services\n  Title: Segregated Witness (Peer Services)\n  Authors: Eric Lombrozo \n           Pieter Wuille \n  Status: Deployed\n  Type: Specification\n  Assigned: 2016-01-08\n  License: PD\n
\n\n==Abstract==\nThis BIP defines new messages and serialization formats for propagation of transactions and blocks committing to segregated witness structures.\n\n==Motivation==\nIn addition to defining witness structures and requiring commitments in future blocks ([https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki BIP141] - Consensus segwit BIP), new mechanisms must be defined to allow peers to advertise support for segregated witness and to relay the witness structures and request them from other peers without breaking compatibility with older nodes.\n\n==Specification==\n\n=== Serialization ===\nA new serialization format for tx messages is added to the peer-to-peer protocol.\n\nThe serialization has the following structure:\n\n{| class=\"wikitable\" style=\"width: auto; text-align: center; font-size: smaller; table-layout: fixed;\"\n!Field Size\n!Name\n!Type\n!Description\n|-\n| 4\n| version\n| int32_t\n| Transaction data format version\n|-\n| 1\n| marker\n| char\n| Must be zero\n|-\n| 1\n| flag\n| char\n| Must be nonzero\n|-\n| 1+\n| txin_count\n| var_int\n| Number of transaction inputs\n|-\n| 41+\n| txins\n| txin[]\n| A list of one or more transaction inputs\n|-\n| 1+\n| txout_count\n| var_int\n| Number of transaction outputs\n|-\n| 9+\n| txouts\n| txouts[]\n| A list of one or more transaction outputs\n|-\n| 1+\n| script_witnesses\n| script_witnesses[]\n| The witness structure as a serialized byte array\n|-\n| 4\n| lock_time\n| uint32_t\n| The block number or timestamp until which the transaction is locked\n|}\n\nParsers supporting this BIP will be able to distinguish between the old serialization format (without the witness) and this one. The marker byte is set to zero so that this structure will never parse as a valid transaction in a parser that does not support this BIP. If parsing were to succeed, such a transaction would contain no inputs and a single output.\n\nIf the witness is empty, the old serialization format must be used.\n\nCurrently, the only witness objects type supported are script witnesses which consist of a stack of byte arrays. It is encoded as a var_int item count followed by each item encoded as a var_int length followed by a string of bytes. Each txin has its own script witness. The number of script witnesses is not explicitly encoded as it is implied by txin_count. Empty script witnesses are encoded as a zero byte. The order of the script witnesses follows the same order as the associated txins.\n\n* '''Rationale for not having an independent message type with its own serialization''': this would require separate \"tx\" and \"block\" messages, and all RPC calls operating on raw transactions would need to be duplicated, or need inefficient or nondeterministic guesswork to know which type is to be used.\n\n* '''Rationale for not using just a single 0x00 byte as marker''': that would lead to empty transactions (no inputs, no outputs, which are used in some tests) to be interpreted as new serialized data.\n\n* '''Rationale for the 0x01 flag byte in between''': this will allow us to easily add more extra non-committed data to transactions (like txouts being spent, ...). It can be interpreted as a bitvector.\n\n=== Handshake ===\nA node will signal that it can provide witnesses using the following service bit\n\n NODE_WITNESS = (1 << 3)\n\t\n\n=== Hashes ===\nTransaction hashes used in the transaction merkle tree and txin outpoints are always computed using the old non-witness\nserialization.\n\nSupport for a new hash including the witness data is added that is\ncomputed from the new witness serialization. (Note that transactions\nwith an empty witness always use the old serialization,\nand therefore, they have witness hash equal to normal hash.)\n\n\n\n=== Relay ===\nNew inv types MSG_WITNESS_TX (0x40000001, or (1<<30)+MSG_TX) and MSG_WITNESS_BLOCK (0x40000002, or (1<<30)+MSG_BLOCK) are added, only\nfor use in getdata. Inventory messages themselves still use just MSG_TX and MSG_BLOCK,\nsimilar to MSG_FILTERED_BLOCK. A further inv type MSG_FILTERED_WITNESS_BLOCK (0x40000003, or (1<<30)+MSG_FILTERED_BLOCK) is reserved for future use.\n\n* '''Rationale for not advertizing witnessness in invs''': we don't always use invs anymore (with 'sendheaders' BIP 130), plus it's not useful: implicitly, every transaction and block have a witness, old ones just have empty ones.\n\nMSG_WITNESS_TX getdata requests should use the non-witness serialized hash. The peer shall respond with a tx message, and if the witness structure is nonempty, the witness serialization shall be used.\n\nMSG_WITNESS_BLOCK requests will return a block message with transactions that have a witness using witness serialization.\n\n== Credits ==\nSpecial thanks to Gregory Maxwell for originating many of the ideas in this BIP and Luke-Jr for figuring out how to deploy this as a soft fork.\n\n== Reference Implementation ==\nhttps://github.com/bitcoin/bitcoin/pull/8149\n\n== Copyright ==\nThis document is placed in the public domain.", "category": "bips" }, { "instruction": "I want to understand 
 from a technical perspective",
    "input": "",
    "output": "BIP: 64\n  Layer: Peer Services\n  Title: getutxo message\n  Authors: Mike Hearn \n  Status: Closed\n  Type: Specification\n  Assigned: 2014-06-10\n
\n\n==Abstract==\n\nThis document describes a small P2P protocol extension that performs UTXO lookups given a set of outpoints.\n\n==Motivation==\n\nAll full Bitcoin nodes maintain a database called the unspent transaction output set. This set is\nhow double spending is checked for: to be valid a transaction must identify unspent outputs in this\nset using an identifier called an \"outpoint\", which is merely the hash of the output's containing\ntransaction plus an index.\n\nThe ability to query this can sometimes be useful for a lightweight/SPV client which does not have\nthe full UTXO set at hand. For example, it can be useful in applications implementing assurance\ncontracts to do a quick check when a new pledge becomes visible to test whether that pledge was\nalready revoked via a double spend. Although this message is not strictly necessary because e.g.\nsuch an app could be implemented by fully downloading and storing the block chain, it is useful for\nobtaining acceptable performance and resolving various UI cases.\n\nAnother example of when this data can be useful is for performing floating fee calculations in an\nSPV wallet. This use case requires some other changes to the Bitcoin protocol however, so we will\nnot dwell on it here.\n\n==Specification==\n\nTwo new messages are defined. The \"getutxos\" message has the following structure:\n\n{|class=\"wikitable\"\n! Field Size !! Description !! Data type !! Comments\n|-\n| 1 || check mempool || bool || Whether to apply mempool transactions during the calculation, thus exposing their UTXOs and removing outputs that they spend.\n|-\n| ? || outpoints || vector || The list of outpoints to be queried. Each outpoint is serialized in the same way it is in a tx message.\n|}\n\nThe response message \"utxos\" has the following structure:\n\n{|class=\"wikitable\"\n! Field Size !! Description !! Data type !! Comments\n|-\n| 4 || chain height || uint32 || The height of the chain at the moment the result was calculated.\n|-\n| 32 || chain tip hash || uint256 || Block hash of the top of the chain at the moment the result was calculated.\n|-\n| ? || hit bitmap || byte[] || An array of bytes encoding one bit for each outpoint queried. Each bit indicates whether the queried outpoint was found in the UTXO set or not.\n|-\n| ? || result utxos || result[] || A list of result objects (defined below), one for each outpoint that is unspent (i.e. has a bit set in the bitmap).\n|}\n\nThe result object is defined as:\n\n{|class=\"wikitable\"\n! Field Size !! Description !! Data type !! Comments\n|-\n| 4 || tx version || uint32 || The version number of the transaction the UTXO was found in.\n|-\n| 4 || height || uint32 || The height of the block containing the defining transaction, or 0x7FFFFFFF if the tx is in the mempool.\n|-\n| ? || output || CTxOut || The output itself, serialized in the same way as in a tx message.\n|}\n\n==Backward compatibility==\n\nNodes indicate support by advertising a protocol version above 70003 and by setting a new\nNODE_GETUTXO flag in their nServices field, which has a value of 2 (the second bit of the field).\n\n==Authentication==\n\nThe UTXO set is not currently authenticated by anything. There are proposals to resolve this by\nintroducing a new consensus rule that commits to a root hash of the UTXO set in blocks, however this\nfeature is not presently available in the Bitcoin protocol. Once it is, the utxos message could be\nupgraded to include Merkle branches showing inclusion of the UTXOs in the committed sets.\n\nIf the requesting client is looking up outputs for a signed transaction that they have locally, the\nclient can partly verify the returned output by running the input scripts with it. Currently this\nverifies only that the script is correct. A future version of the Bitcoin protocol is likely to also\nallow the value to be checked in this way. It does not show that the output is really unspent or was\never actually created in the block chain however. Additionally, the form of the provided scriptPubKey\nshould be checked before execution to ensure the remote peer doesn't just set the script to OP_TRUE.\n\nIf the requesting client has a mapping of chain heights to block hashes in the best chain e.g.\nobtained via getheaders, then they can obtain a proof that the output did at one point exist by\nrequesting the block and searching for the output within it. When combined with Bloom filtering this\ncan be reasonably efficient.\n\nNote that even when the outputs are being checked against something this protocol has the same\nsecurity model as Bloom filtering: a remote node can lie through omission by claiming the requested\nUTXO does not exist / was already spent (they are the same, from the perspective of a full node).\nQuerying multiple nodes and combining their answers can be a partial solution to this, although as\nnothing authenticates the Bitcoin P2P network a man in the middle could still yield incorrect\nresults.\n\n==Implementation==\n\nhttps://github.com/bitcoin/bitcoin/pull/4351/files", "category": "bips" }, { "instruction": "Can you explain 
 like we're having a beer and talking Bitcoin?",
    "input": "",
    "output": "BIP: 132\n  Title: Committee-based BIP Acceptance Process\n  Authors: Andy Chase \n  Status: Closed\n  Type: Process\n  Assigned: 2015-08-31\n  License: PD\n
\n\n== Abstract ==\n\nThe current process for accepting a BIP is not clearly defined. While [https://github.com/bitcoin/bips/blob/master/bip-0001.mediawiki BIP-0001] defines the process for writing and submitting a Bitcoin Improvement Proposal to the community it does not specify the precise method for which BIPs are considered accepted or rejected.\n\nThis proposal sets up a method for determining BIP acceptance.\n\nThis BIP has two parts:\n\n* It sets up a '''process''' which a BIP goes through for comments and acceptance. The Process is:\n** BIP Draft\n** Submitted for comments (2 weeks)\n** Waiting on opinion (2 weeks)\n** BIP becomes either Accepted or Deferred\n* It sets up '''committees''' for reviewing comments and indicating acceptance under precise conditions.\n** Committees are authorized groups that represent client authors, miners, merchants, and users (each as a segment). Each one must represent at least 1% stake in the Bitcoin ecosystem.\n\nBIP acceptance is defined as at least 70% of the represented percentage stake in 3 out of the 4 Bitcoin segments.\n\n== Copyright ==\n\nThis document is placed into the public domain.\n\n== Motivation ==\n\nBIPs represent important improvements to Bitcoin infrastructure, and in order to foster continued innovation, the BIP process must have clearly defined stages and acceptance acknowledgement.\n\n== Rationale ==\n\nA committee system is used to organize the essential concerns of each segment of the Bitcoin ecosystem. Although each segment may have many different viewpoints on each BIP, in order to seek a decisive yes/no on a BIP, a representational authoritative structure is sought. This structure should be fluid, allowing people to move away from committees that do not reflect their views and should be re-validated on each BIP evaluation.\n\n== Weaknesses ==\n\nEach committee submits a declaration including their claim to represent a certain percentage of the Bitcoin ecosystem in some way. Though guidelines are given, it's up to each committee to prove their stake, and it's up to the reader of the opinions to decide if a BIP was truly accepted or rejected.\n\nThe author doesn't believe this is a problem because a BIP cannot be forced on client authors, miners, merchants, or users. Ultimately this BIP is a tool for determining whether a BIP is overwhelmingly accepted. If one committee's validity claim becomes the factor that decides whether the BIP will succeed or fail, this process simply didn't return a clear answer and the BIP should be considered deferred.\n\n== Process ==\n\n* '''Submit for Comments.''' The first BIP champion named in the proposal can call a "submit for comments" at any time by posting to the [https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev Dev Mailing List] mailing with the BIP number and a statement that the champion intends to immediately submit the BIP for comments.\n** The BIP must have been assigned BIP-number (i.e. been approved by the BIP editor) to be submitted for comments.\n* '''Comments.'''\n** After a BIP has been submitted for comments, a two-week waiting period begins in which the community should transition from making suggestions about a proposal to publishing their opinions or concerns on the proposal.\n* '''Reported Opinions.'''\n** After the waiting period has past, committees must submit a summary of the comments which they have received from their represented communities.\n** The deadline for this opinion is four weeks after the BIP was submitted for comments.\n** Committees cannot reverse their decision after the deadline, but at their request may flag their decision as "likely to change if another submit for comments is called". Committees can change their decision if a resubmit is called.\n** Opinions must include:\n*** One of the following statements: "Intend to accept", "Intent to implement", "Decline to accept", "Intend to accept, but decline to implement".\n*** If rejected, the opinion must cite clear and specific reasons for rejecting including a checklist for what must happen or be change for their committee to accept the proposal.\n*** If accepted, the committee must list why they accepted the proposal and also include concerns they have or what about the BIP that, if things changed, would cause the committee to likely reverse their decision if another submit for comments was called.\n* '''Accepted.'''\n** If at least 70% of the represented percentage stake in 3 out of 4 segments accept a proposal, the BIP is considered accepted.\n** If a committee fails to submit an opinion, consider the opinion "Decline to accept".\n** The BIP cannot be substantially changed at this point, but can be replaced. Minor changes or clarifications are allowed but must be recorded in the document.\n* '''Deferred.'''\n** If the acceptance test above is not met, the BIP is sent back into suggestions.\n** BIP can be modified and re-submitted for a comments no sooner than two months after the date of the previous submit for comments is called.\n** The BIP is marked rejected after two failed submission attempts. A rejected BIP can still be modified and re-submitted.\n\n== Committees ==\n\n'''BIP Committees.'''\n\n* BIP Committees are representational structures that represent critical segments of the Bitcoin ecosystem.\n* Each committee must prove and maintain a clear claim that they represent at least 1% of the Bitcoin ecosystem in some form.\n* If an organization or community does not meet that requirement, it should conglomerate itself with other communities and organizations so that it does.\n* The segments that committees can be based around are:\n** Bitcoin software\n** Exchanges/Merchants/services/payment processors\n** Mining operators\n** User communities\n* A person may be represented by any number of segments, but a committee cannot re-use the same resource as another committee in the same segment.\n\n'''Committee Declarations.'''\n* At any point, a Committee Declaration can be posted.\n* This Declaration must contain details about:\n** The segment the Committee is representing\n** Who the committee claim to represent and it's compositional makeup (if made up of multiple miner orgs, user orgs, companies, clients, etc).\n** Proof of claim and minimum 1% stake via:\n*** Software: proof of ownership and user base (Min 1% of Bitcoin userbase)\n*** Merchant: proof of economic activity (Min 1% of Bitcoin economic activity)\n*** Mining: proof of work (Min 1% of Hashpower)\n*** For a user organization, auditable signatures qualifies for a valid committee (Min 1% of Bitcoin userbase)\n** Who is running the committee, their names and roles\n** How represented members can submit comments to the committee\n** A code of conduct and code of ethics which the committee promises to abide by\n* A committee declaration is accepted if:\n** The declaration includes all of the required elements\n** The stake is considered valid\n** Committee validation is considered when considering the results of opinions submitted by committee on a BIP. A committee must have met the required stake percentage before a BIP is submitted for comments, and have maintained that stake until a valid opinion is submitted.\n* Committees can dissolve at any time or submit a declaration at any time\n* Declaration must have been submitted no later than the third day following a BIP's request for comments to be eligible for inclusion in a BIP\n\n== BIP Process Management Role ==\n\nBIPs, Opinions, and Committee Declaration must be public at all times.\n\nA BIP Process Manager should be chosen who is in charge of:\n\n* Declaring where and how BIPs, Opinions, and Committee Declaration should be posted and updated officially.\n* Maintaining the security and authenticity of BIPs, Opinions, and Committee Declarations\n* Publishing advisory documents about what kinds of proof of stakes are valid and what kinds should be rejected.\n* Naming a series of successors for the roles of the BIP Process Manager and BIP Editor (BIP-001) as needed.\n\n== Conditions for activation ==\n\nIn order for this process BIP to become active, it must succeed by its own rules. At least a 4% sample of the Bitcoin community must be represented, with at least one committee in each segment included. Once at least one committee has submitted a declaration, a request for comments will be called and the process should be completed from there.", "category": "bips" }, { "instruction": "How would you explain 
 to someone who knows Bitcoin basics?",
    "input": "",
    "output": "BIP: 174\n  Layer: Applications\n  Title: Partially Signed Bitcoin Transaction Format\n  Authors: Ava Chow \n  Comments-Summary: No comments yet.\n  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0174\n  Status: Deployed\n  Type: Specification\n  Assigned: 2017-07-12\n  License: BSD-2-Clause\n  Version: 1.4.2\n
\n\n==Introduction==\n\n===Abstract===\n\nThis document proposes a binary transaction format which contains the information\nnecessary for a signer to produce signatures for the transaction and holds the\nsignatures for an input while the input does not have a complete set of signatures.\nThe signer can be offline as all necessary information will be provided in the\ntransaction.\n\nThe generic format is described here in addition to the specification for version 0\nof this format.\n\n===Copyright===\n\nThis BIP is licensed under the 2-clause BSD license.\n\n===Motivation===\n\nCreating unsigned or partially signed transactions to be passed around to multiple\nsigners is currently implementation dependent, making it hard for people who use\ndifferent wallet software from being able to easily do so. One of the goals of this\ndocument is to create a standard and extensible format that can be used between clients to allow\npeople to pass around the same transaction to sign and combine their signatures. The\nformat is also designed to be easily extended for future use which is harder to do\nwith existing transaction formats.\n\nSigning transactions also requires users to have access to the UTXOs being spent. This transaction\nformat will allow offline signers such as air-gapped wallets and hardware wallets\nto be able to sign transactions without needing direct access to the UTXO set and without\nrisk of being defrauded.\n\n==Specification==\n\nThe Partially Signed Bitcoin Transaction (PSBT) format consists of key-value maps.\nEach map consists of a sequence of key-value records, terminated by a 0x00 byte '''Why\nis the separator here 0x00 instead of 0xff?'''\nThe separator here is used to distinguish between each chunk of data. A separator of 0x00 would mean that\nthe unserializer can read it as a key length of 0, which would never occur with actual keys. It can thus\nbe used as a separator and allow for easier unserializer implementation..\n\n\n := * *\n := 0x70 0x73 0x62 0x74 0xFF\n := * 0x00\n := * 0x00\n := * 0x00\n := \n := \n := \n\nWhere:\n\n;\n: A [https://en.bitcoin.it/wiki/Protocol_documentation#Variable_length_integer compact size] unsigned integer representing the type. This compact size unsigned integer must be minimally encoded, i.e. if the value can be represented using one byte, it must be represented as one byte. There can be multiple entries with the same within a specific , but the must be unique.\n;\n: The compact size unsigned integer containing the combined length of and \n;\n: The compact size unsigned integer containing the length of (which must be exactly this many bytes).\n;\n: Magic bytes which are ASCII for psbt '''Why use 4 bytes for psbt?''' The\ntransaction format needed to start with a 5 byte header which uniquely identifies\nit. The first bytes were chosen to be the ASCII for psbt because that stands for\nPartially Signed Bitcoin Transaction. followed by a separator of 0xFF'''Why Use a separator after the magic bytes?''' The separator\nis part of the 5 byte header for PSBT. This byte is a separator of 0xff because\nthis will cause any non-PSBT unserializer to fail to properly unserialize the PSBT\nas a normal transaction. Likewise, since the 5 byte header is fixed, no transaction\nin the non-PSBT format will be able to be unserialized by a PSBT unserializer.. This integer must be serialized in most significant byte order.\n\nThe global types are defined as follows:\n\n{|\n! Name\n! \n! \n! Description\n! \n! Description\n! Versions Requiring Inclusion\n! Versions Requiring Exclusion\n! Versions Allowing Inclusion\n|-\n| Unsigned Transaction\n| PSBT_GLOBAL_UNSIGNED_TX = 0x00\n| None\n| No key data\n| \n| The transaction in network serialization. The scriptSigs and witnesses for each input must be empty. The transaction must be in the old serialization format (without witnesses).\n| 0\n| 2\n| 0\n|-\n| Extended Public Key\n| PSBT_GLOBAL_XPUB = 0x01\n| \n| The 78 byte serialized extended public key as defined by BIP 32. Extended public keys are those that can be used to derive public keys used in the inputs and outputs of this transaction. It should be the public key at the highest hardened derivation index so that the unhardened child keys used in the transaction can be derived.\n| <4 byte fingerprint> <32-bit little endian uint path element>*\n| The master key fingerprint as defined by BIP 32 concatenated with the derivation path of the public key. The derivation path is represented as 32-bit little endian unsigned integer indexes concatenated with each other. The number of 32 bit unsigned integer indexes must match the depth provided in the extended public key.\n|\n|\n| 0, 2\n|-\n| PSBT Version Number\n| PSBT_GLOBAL_VERSION = 0xFB\n| None\n| No key data\n| <32-bit little endian uint version>\n| The 32-bit little endian unsigned integer representing the version number of this PSBT. If omitted, the version number is 0.\n| 2\n|\n| 0, 2\n|-\n| Proprietary Use Type\n| PSBT_GLOBAL_PROPRIETARY = 0xFC\n| \n| Compact size unsigned integer of the length of the identifier, followed by identifier prefix, followed by a compact size unsigned integer subtype, followed by the key data itself.\n| \n| Any value data as defined by the proprietary type user.\n|\n|\n| 0, 2\n|}\n\nPer-input types are defined as follows:\n\n{|\n! Name\n! \n! \n! Description\n! \n! Description\n! Versions Requiring Inclusion\n! Versions Requiring Exclusion\n! Versions Allowing Inclusion\n|-\n| Non-Witness UTXO\n| PSBT_IN_NON_WITNESS_UTXO = 0x00\n| None\n| No key data\n| \n| The transaction in network serialization format the current input spends from. This should be present for inputs that spend non-segwit outputs and can be present for inputs that spend segwit outputs. An input can have both PSBT_IN_NON_WITNESS_UTXO and PSBT_IN_WITNESS_UTXO. '''Why can both UTXO types be provided?''' Many wallets began requiring the full previous transaction (i.e. PSBT_IN_NON_WITNESS_UTXO) for segwit inputs when PSBT was already in use. In order to be compatible with software which were expecting PSBT_IN_WITNESS_UTXO, both UTXO types must be allowed.\n|\n|\n| 0, 2\n|-\n| Witness UTXO\n| PSBT_IN_WITNESS_UTXO = 0x01\n| None\n| No key data\n| <64-bit little endian int amount> \n| The entire transaction output in network serialization which the current input spends from. This should only be present for inputs which spend segwit outputs, including P2SH embedded ones. An input can have both PSBT_IN_NON_WITNESS_UTXO and PSBT_IN_WITNESS_UTXO\n|\n|\n| 0, 2\n|-\n| Partial Signature\n| PSBT_IN_PARTIAL_SIG = 0x02\n| \n| The public key which corresponds to this signature.\n| \n| The signature as would be pushed to the stack from a scriptSig or witness. The signature should be a valid ECDSA signature corresponding to the pubkey that would return true when verified and not a value that would return false or be invalid otherwise (such as a NULLDUMMY).\n|\n|\n| 0, 2\n|-\n| Sighash Type\n| PSBT_IN_SIGHASH_TYPE = 0x03\n| None\n| No key data\n| <32-bit little endian uint sighash type>\n| The 32-bit unsigned integer specifying the sighash type to be used for this input. Signatures for this input must use the sighash type, finalizers must fail to finalize inputs which have signatures that do not match the specified sighash type. Signers who cannot produce signatures with the sighash type must not provide a signature.\n|\n|\n| 0, 2\n|-\n| Redeem Script\n| PSBT_IN_REDEEM_SCRIPT = 0x04\n| None\n| No key data\n| \n| The redeemScript for this input if it has one.\n|\n|\n| 0, 2\n|-\n| Witness Script\n| PSBT_IN_WITNESS_SCRIPT = 0x05\n| None\n| No key data\n| \n| The witnessScript for this input if it has one.\n|\n|\n| 0, 2\n|-\n| BIP 32 Derivation Path\n| PSBT_IN_BIP32_DERIVATION = 0x06\n| \n| The public key\n| <4 byte fingerprint> <32-bit little endian uint path element>*\n| The master key fingerprint as defined by BIP 32 concatenated with the derivation path of the public key. The derivation path is represented as 32 bit unsigned integer indexes concatenated with each other. Public keys are those that will be needed to sign this input.\n|\n|\n| 0, 2\n|-\n| Finalized scriptSig\n| PSBT_IN_FINAL_SCRIPTSIG = 0x07\n| None\n| No key data\n| \n| The Finalized scriptSig contains a fully constructed scriptSig with signatures and any other scripts necessary for the input to pass validation.\n|\n|\n| 0, 2\n|-\n| Finalized scriptWitness\n| PSBT_IN_FINAL_SCRIPTWITNESS = 0x08\n| None\n| No key data\n| \n| The Finalized scriptWitness contains a fully constructed scriptWitness with signatures and any other scripts necessary for the input to pass validation.\n|\n|\n| 0, 2\n|-\n| RIPEMD160 preimage\n| PSBT_IN_RIPEMD160 = 0x0a\n| <20-byte hash>\n| The resulting hash of the preimage\n| \n| The hash preimage, encoded as a byte vector, which must equal the key when run through the RIPEMD160 algorithm\n|\n|\n| 0, 2\n|-\n| SHA256 preimage\n| PSBT_IN_SHA256 = 0x0b\n| <32-byte hash>\n| The resulting hash of the preimage\n| \n| The hash preimage, encoded as a byte vector, which must equal the key when run through the SHA256 algorithm\n|\n|\n| 0, 2\n|-\n| HASH160 preimage\n| PSBT_IN_HASH160 = 0x0c\n| <20-byte hash>\n| The resulting hash of the preimage\n| \n| The hash preimage, encoded as a byte vector, which must equal the key when run through the SHA256 algorithm followed by the RIPEMD160 algorithm\n|\n|\n| 0, 2\n|-\n| HASH256 preimage\n| PSBT_IN_HASH256 = 0x0d\n| <32-byte hash>\n| The resulting hash of the preimage\n| \n| The hash preimage, encoded as a byte vector, which must equal the key when run through the SHA256 algorithm twice\n|\n|\n| 0, 2\n|-\n| Proprietary Use Type\n| PSBT_IN_PROPRIETARY = 0xFC\n| \n| Compact size unsigned integer of the length of the identifier, followed by identifier prefix, followed by a compact size unsigned integer subtype, followed by the key data itself.\n| \n| Any value data as defined by the proprietary type user.\n|\n|\n| 0, 2\n|}\n\nThe per-output '''Why do we need per-output data?''' Per-output data allows signers\nto verify that the outputs are going to the intended recipient. The output data can also be use by signers to\ndetermine which outputs are change outputs and verify that the change is returning to the correct place. types are defined as follows:\n\n{|\n! Name\n! \n! \n! Description\n! \n! Description\n! Versions Requiring Inclusion\n! Versions Requiring Exclusion\n! Versions Allowing Inclusion\n|-\n| Redeem Script\n| PSBT_OUT_REDEEM_SCRIPT = 0x00\n| None\n| No key data\n| \n| The redeemScript for this output if it has one.\n|\n|\n| 0, 2\n|-\n| Witness Script\n| PSBT_OUT_WITNESS_SCRIPT = 0x01\n| None\n| No key data\n| \n| The witnessScript for this output if it has one.\n|\n|\n| 0, 2\n|-\n| BIP 32 Derivation Path\n| PSBT_OUT_BIP32_DERIVATION = 0x02\n| \n| The public key\n| <4 byte fingerprint> <32-bit little endian uint path element>*\n| The master key fingerprint concatenated with the derivation path of the public key. The derivation path is represented as 32-bit little endian unsigned integer indexes concatenated with each other. Public keys are those needed to spend this output.\n|\n|\n| 0, 2\n|-\n| Proprietary Use Type\n| PSBT_OUT_PROPRIETARY = 0xFC\n| \n| Compact size unsigned integer of the length of the identifier, followed by identifier prefix, followed by a compact size unsigned integer subtype, followed by the key data itself.\n| \n| Any value data as defined by the proprietary type user.\n|\n|\n| 0, 2\n|}\n\nTypes can be skipped when they are unnecessary. For example, if an input is a witness\ninput, then it should not have a Non-Witness UTXO key-value pair.\n\nIf the signer encounters key-value pairs that it does not understand, it must\npass those key-value pairs through when re-serializing the transaction.\n\nAll keys must have the data that they specify. If any key or value does not match the\nspecified format for that type, the PSBT must be considered invalid. For example, any\nkey that has no data except for the type specifier must only have the type specifier in\nthe key.\n\nAdditional types may be defined by other BIPs. They should be added to the accompanying [[bip-0174/type-registry.mediawiki|type registry tables]] to ease coordination.\n\n===Handling Duplicated Keys===\n\nKeys within each scope should never be duplicated; all keys in the format are unique. PSBTs containing duplicate keys are invalid. However implementers\nwill still need to handle events where keys are duplicated when combining transactions with duplicated fields. In this event, the software may choose\nwhichever value it wishes.'''Why can the values be arbitrarily chosen?''' When there are duplicated keys, the values that can be chosen will either be\nvalid or invalid. If the values are invalid, a signer would simply produce an invalid signature and the final transaction itself would be invalid. If the\nvalues are valid, then it does not matter which is chosen as either way the transaction is still valid.\n\n===Proprietary Use Type===\n\nFor all global, per-input, and per-output maps, the type 0xFC is reserved for proprietary use.\nThe proprietary use type requires keys that follow the type with a compact size unsigned integer representing the length of the string identifier, followed by the string identifier, then a subtype, and finally any key data.\n\nThe identifier can be any variable length string that software can use to identify whether the particular data in the proprietary type can be used by it.\nIt can also be the empty string although this is not recommended.\n\nThe subtype is defined by the proprietary type user and can mean whatever they want it to mean.\nThe subtype must also be a compact size unsigned integer in the same form as the normal types.\nThe key data and value data are defined by the proprietary type user.\n\nThe proprietary use type is for private use by individuals and organizations who wish to use PSBT in their processes.\nIt is useful when there are additional data that they need attached to a PSBT but such data are not useful or available for the general public.\nThe proprietary use type is not to be used by any public specification and there is no expectation that any publicly available software be able to understand any specific meanings of it and the subtypes.\nThis type must be used for internal processes only.\n\n==Version 0==\n\nPartially Signed Bitcoin Transactions version 0 is the first version of the PSBT format.\nVersion 0 PSBTs must either omit PSBT_GLOBAL_VERSION or include it and set it to 0.\nVersion 0 PSBTs must include PSBT_GLOBAL_UNSIGNED_TX, if omitted, the PSBT is invalid.\n\n==Roles==\n\nUsing the transaction format involves many different roles. Multiple roles can be handled by a single entity, but each role is specialized in what it should be capable of doing.\n\n===Creator===\n\nThe Creator creates a new PSBT. It must create an unsigned transaction and place it in the PSBT.\nThe Creator must create empty input and output fields.\n\n===Updater===\n\nThe Updater must only accept a PSBT.\nThe Updater adds information to the PSBT that it has access to. If it has the UTXO for an input, it should add it to the PSBT.\nThe Updater should also add redeemScripts, witnessScripts, and BIP 32 derivation paths to the input and output data if it knows them.\n\nA single entity is likely to be both a Creator and Updater.\n\n===Signer===\n\nThe Signer must only accept a PSBT.\nThe Signer must only use the UTXOs provided in the PSBT to produce signatures for inputs.\nBefore signing a non-witness input, the Signer must verify that the TXID of the non-witness UTXO matches the TXID specified in the unsigned transaction.\nBefore signing a witness input, the Signer must verify that the witnessScript (if provided) matches the hash specified in the UTXO or the redeemScript, and the redeemScript (if provided) matches the hash in the UTXO.\nThe Signer may choose to fail to sign a segwit input if a non-witness UTXO is not provided. '''Why would non-witness UTXOs be provided for segwit inputs?''' The sighash algorithm for Segwit specified in BIP 143 is known to have an issue where an attacker could trick a user to sending Bitcoin to fees if they are able to convince the user to sign a malicious transaction multiple times. This is possible because the amounts in PSBT_IN_WITNESS_UTXO of other segwit inputs can be modified without effecting the signature for a particular input. In order to prevent this kind of attack, many wallets are requiring that the full previous transaction (i.e. PSBT_IN_NON_WITNESS_UTXO) be provided to ensure that the amounts of other inputs are not being tampered with.\nThe Signer should not need any additional data sources, as all necessary information is provided in the PSBT format.\nThe Signer must only add data to a PSBT.\nAny signatures created by the Signer must be added as a \"Partial Signature\" key-value pair for the respective input it relates to.\nIf a Signer cannot sign a transaction, it must not add a Partial Signature.\n\nThe Signer can additionally compute the addresses and values being sent, and the transaction fee, optionally showing this data to the user as a confirmation of intent and the consequences of signing the PSBT.\n\nSigners do not need to sign for all possible input types. For example, a signer may choose to only sign Segwit inputs.\n\nA single entity is likely to be both a Signer and an Updater as it can update a PSBT with necessary information prior to signing it.\n\n====Data Signers Check For====\n\nFor a Signer to only produce valid signatures for what it expects to sign, it must check that the following conditions are true:\n\n* If a non-witness UTXO is provided, its hash must match the hash specified in the prevout\n* If a witness UTXO is provided, no non-witness signature may be created\n* If a redeemScript is provided, the scriptPubKey must be for that redeemScript\n* If a witnessScript is provided, the scriptPubKey or the redeemScript must be for that witnessScript\n* If a sighash type is provided, the signer must check that the sighash is acceptable. If unacceptable, they must fail.\n* If a sighash type is not provided, the signer should sign using SIGHASH_ALL, but may use any sighash type they wish.\n\n=====Simple Signer Algorithm=====\n\nA simple signer can use the following algorithm to determine what and how to sign\n\n
\nsign_witness(script_code, i):\n    for key, sighash_type in psbt.inputs[i].items:\n        if sighash_type == None:\n            sighash_type = SIGHASH_ALL\n        if IsMine(key) and IsAcceptable(sighash_type):\n            sign(witness_sighash(script_code, i, input))\n\nsign_non_witness(script_code, i):\n    for key, sighash_type in psbt.inputs[i].items:\n        if sighash_type == None:\n            sighash_type = SIGHASH_ALL\n        if IsMine(key) and IsAcceptable(sighash_type):\n            sign(non_witness_sighash(script_code, i, input))\n\nfor input, i in enumerate(psbt.inputs):\n    if witness_utxo.exists:\n        if redeemScript.exists:\n            assert(witness_utxo.scriptPubKey == P2SH(redeemScript))\n            script = redeemScript\n        else:\n            script = witness_utxo.scriptPubKey\n        if IsP2WPKH(script):\n            sign_witness(P2PKH(script[2:22]), i)\n        else if IsP2WSH(script):\n            assert(script == P2WSH(witnessScript))\n            sign_witness(witnessScript, i)\n    else if non_witness_utxo.exists:\n        assert(sha256d(non_witness_utxo) == psbt.tx.input[i].prevout.hash)\n        if redeemScript.exists:\n            assert(non_witness_utxo.vout[psbt.tx.input[i].prevout.n].scriptPubKey == P2SH(redeemScript))\n            sign_non_witness(redeemScript, i)\n        else:\n            sign_non_witness(non_witness_utxo.vout[psbt.tx.input[i].prevout.n].scriptPubKey, i)\n    else:\n        assert False\n
\n\n====Change Detection====\n\nSigners may wish to display the inputs and outputs to users for extra verification.\nIn such displays, signers may wish to identify which outputs are change outputs in order to omit them to avoid additional user confusion.\nIn order to detect change, a signer can use the BIP 32 derivation paths provided in inputs and outputs as well as the extended public keys provided globally.\n\nFor a single key output, a signer can observe whether the master fingerprint for the public key for that output belongs to itself.\nIf it does, it can then derive the public key at the specified derivation path and check whether that key is the one present in that output.\n\nFor outputs involving multiple keys, a signer can first examine the inputs that it is signing.\nIt should determine the general pattern of the script and internally produce a representation of the policy that the script represents.\nSuch a policy can include things like how many keys are present, what order they are in, how many signers are necessary, which signers are required, etc.\nThe signer can then use the BIP 32 derivation paths for each of the pubkeys to find which global extended public key is the one that can derive that particular public key.\nTo do so, the signer would extract the derivation path to the highest hardened index and use that to lookup the public key with that index and master fingerprint.\nThe signer would construct this script policy with extended public keys for all of the inputs and outputs.\nChange outputs would then be identified as being the outputs which have the same script policy as the inputs that are being signed.\n\n===Combiner===\n\nThe Combiner can accept 1 or many PSBTs.\nThe Combiner must merge them into one PSBT (if possible), or fail.\nThe resulting PSBT must contain all of the key-value pairs from each of the PSBTs.\nThe Combiner must remove any duplicate key-value pairs, in accordance with the specification. It can pick arbitrarily when conflicts occur.\nA Combiner must not combine two different PSBTs. PSBTs can be uniquely identified by 0x00 global transaction typed key-value pair.\nFor every type that a Combiner understands, it may refuse to combine PSBTs if it detects that there will be inconsistencies or conflicts for that type in the combined PSBT.\n\nThe Combiner does not need to know how to interpret scripts in order to combine PSBTs. It can do so without understanding scripts or the network serialization format.\n\nIn general, the result of a Combiner combining two PSBTs from independent participants A and B should be functionally equivalent to a result obtained from processing the original PSBT by A and then B in a sequence.\nOr, for participants performing fA(psbt) and fB(psbt): Combine(fA(psbt), fB(psbt)) == fA(fB(psbt)) == fB(fA(psbt))\n\n===Input Finalizer===\n\nThe Input Finalizer must only accept a PSBT.\nFor each input, the Input Finalizer determines if the input has enough data to pass validation. If it does, it must construct the 0x07 Finalized scriptSig and 0x08 Finalized scriptWitness and place them into the input key-value map. If the input has a PSBT_IN_SIGHASH_TYPE field, the Input Finalizer must fail to finalize that input if any signature does not match the specified sighash type.\nIf scriptSig is empty for an input, 0x07 should remain unset rather than assigned an empty array.\nLikewise, if no scriptWitness exists for an input, 0x08 should remain unset rather than assigned an empty array.\nAll other data except the UTXO and unknown fields (including PSBT_IN_PROPRIETARY fields the Input Finalizer does not understand) in the input key-value map should be cleared from the PSBT. The UTXO should be kept to allow Transaction Extractors to verify the final network serialized transaction.\n\n===Transaction Extractor===\n\nThe Transaction Extractor must only accept a PSBT.\nIt checks whether all inputs have complete scriptSigs and scriptWitnesses by checking for the presence of 0x07 Finalized scriptSig and 0x08 Finalized scriptWitness typed records. If they do, the Transaction Extractor should construct complete scriptSigs and scriptWitnesses and encode them into network serialized transactions. Otherwise the Extractor must not modify the PSBT.\nThe Extractor should produce a fully valid, network serialized transaction if all inputs are complete.\n\nThe Transaction Extractor does not need to know how to interpret scripts in order to extract the network serialized transaction. However it may be able to in order to validate the network serialized transaction at the same time.\n\nA single entity is likely to be both a Transaction Extractor and an Input Finalizer.\n\n==Encoding==\n\nA PSBT can be represented in two ways: in binary (as a file) or as a Base64 string using the encoding described in [https://tools.ietf.org/html/rfc4648#section-4 RFC4648].\n\nBinary PSBT files should use the .psbt file extension.\nA MIME type name will be added to this document once one has been registered.\n\n==Extensibility==\n\nThe Partially Signed Transaction format can be extended in the future by adding\nnew types for key-value pairs. Backwards compatibility will still be maintained as those new\ntypes will be ignored and passed-through by signers which do not know about them.\n\n===Version Numbers===\n\nThe Version number field exists only as a safeguard in the event that a backwards incompatible change is introduced to PSBT.\nIf a parser encounters a version number it does not recognize, it should exit immediately as this indicates that the PSBT will contain types that it does not know about and cannot be ignored.\nCurrent PSBTs are Version 0. Any PSBT that does not have the version field is version 0.\nIt is not expected that any backwards incompatible change will be introduced to PSBT, so it is not expected that the version field will ever actually be seen.\n\nUpdaters and combiners that need to add a version number to a PSBT should use the highest version number required.\nFor example, if a combiner sees two PSBTs for the same transaction, one with version 0, and the other with version 1, then it should combine them and produce a PSBT with version 1.\nIf an updater is updating a PSBT and needs to add a field that is only available in version 1, then it should set the PSBT version number to 1 unless a version higher than that is already specified.\n\n===Procedure For New Fields===\n\nNew fields should first be proposed on the bitcoin-dev mailing list,\nand their usage should then be defined in a separate BIP.\nNew fields must be added to the [[bip-0174/type-registry.mediawiki|type registry tables]].\nAlthough some PSBT version 0 implementations encode types as uint8_t rather than compact size,\nit is still safe to add >0xFD fields to PSBT 0, because these old parsers ignore\nunknown fields, and is prefixed by its length.\n\n===Procedure For New Versions===\n\nNew PSBT versions must be described in a separate BIP.\nSuch new BIPs may reference this BIP and any components of PSBT version 0 that are retained in the new version.\nAny new fields described in a new version must be added to the [[bip-0174/type-registry.mediawiki|type registry tables]].\n\n==Compatibility==\n\nThis transaction format is designed so that it is unable to be properly unserialized\nby normal transaction unserializers. Likewise, a normal transaction will not be\nable to be unserialized by an unserializer for the PSBT format.\n\n==Examples==\n\n===Manual CoinJoin Workflow===\n\n\n\n===2-of-3 Multisig Workflow===\n\n\n\n==Changelog==\n\n* '''1.4.2''' (2026-04-08):\n** Introduce type registry auxiliary file\n** Add changelog\n* '''1.4.1''' (2021-01-14):\n** Mark Final (Later updated to \"Deployed\" with adoption of BIP3)\n* '''1.4.0''' (2019-10-02):\n** Add preimage fields\n* '''1.3.0''' (2019-10-02):\n** Add proprietary fields\n* '''1.2.0''' (2019-08-01):\n** Types are compact size unsigned ints\n** Add global PSBT version field\n* '''1.1.0''' (2019-05-13):\n** Add global xpub field\n* '''1.0.0''' (2018-07-11):\n** Mark Proposed\n\n==Test Vectors==\n\nThe following are invalid PSBTs:\n\n* Case: Network transaction, not PSBT format\n** Bytes in Hex: 
0200000001268171371edff285e937adeea4b37b78000c0566cbb3ad64641713ca42171bf6000000006a473044022070b2245123e6bf474d60c5b50c043d4c691a5d2435f09a34a7662a9dc251790a022001329ca9dacf280bdf30740ec0390422422c81cb45839457aeb76fc12edd95b3012102657d118d3357b8e0f4c2cd46db7b39f6d9c38d9a70abcb9b2de5dc8dbfe4ce31feffffff02d3dff505000000001976a914d0c59903c5bac2868760e90fd521a4665aa7652088ac00e1f5050000000017a9143545e6e33b832c47050f24d3eeb93c9c03948bc787b32e1300
\n** Base64 String: 
AgAAAAEmgXE3Ht/yhek3re6ks3t4AAwFZsuzrWRkFxPKQhcb9gAAAABqRzBEAiBwsiRRI+a/R01gxbUMBD1MaRpdJDXwmjSnZiqdwlF5CgIgATKcqdrPKAvfMHQOwDkEIkIsgctFg5RXrrdvwS7dlbMBIQJlfRGNM1e44PTCzUbbezn22cONmnCry5st5dyNv+TOMf7///8C09/1BQAAAAAZdqkU0MWZA8W6woaHYOkP1SGkZlqnZSCIrADh9QUAAAAAF6kUNUXm4zuDLEcFDyTT7rk8nAOUi8eHsy4TAA==
\n\n* Case: PSBT missing outputs\n** Bytes in Hex: 
70736274ff0100750200000001268171371edff285e937adeea4b37b78000c0566cbb3ad64641713ca42171bf60000000000feffffff02d3dff505000000001976a914d0c59903c5bac2868760e90fd521a4665aa7652088ac00e1f5050000000017a9143545e6e33b832c47050f24d3eeb93c9c03948bc787b32e1300000100fda5010100000000010289a3c71eab4d20e0371bbba4cc698fa295c9463afa2e397f8533ccb62f9567e50100000017160014be18d152a9b012039daf3da7de4f53349eecb985ffffffff86f8aa43a71dff1448893a530a7237ef6b4608bbb2dd2d0171e63aec6a4890b40100000017160014fe3e9ef1a745e974d902c4355943abcb34bd5353ffffffff0200c2eb0b000000001976a91485cff1097fd9e008bb34af709c62197b38978a4888ac72fef84e2c00000017a914339725ba21efd62ac753a9bcd067d6c7a6a39d05870247304402202712be22e0270f394f568311dc7ca9a68970b8025fdd3b240229f07f8a5f3a240220018b38d7dcd314e734c9276bd6fb40f673325bc4baa144c800d2f2f02db2765c012103d2e15674941bad4a996372cb87e1856d3652606d98562fe39c5e9e7e413f210502483045022100d12b852d85dcd961d2f5f4ab660654df6eedcc794c0c33ce5cc309ffb5fce58d022067338a8e0e1725c197fb1a88af59f51e44e4255b20167c8684031c05d1f2592a01210223b72beef0965d10be0778efecd61fcac6f79a4ea169393380734464f84f2ab30000000000
\n** Base64 String: 
cHNidP8BAHUCAAAAASaBcTce3/KF6Tet7qSze3gADAVmy7OtZGQXE8pCFxv2AAAAAAD+////AtPf9QUAAAAAGXapFNDFmQPFusKGh2DpD9UhpGZap2UgiKwA4fUFAAAAABepFDVF5uM7gyxHBQ8k0+65PJwDlIvHh7MuEwAAAQD9pQEBAAAAAAECiaPHHqtNIOA3G7ukzGmPopXJRjr6Ljl/hTPMti+VZ+UBAAAAFxYAFL4Y0VKpsBIDna89p95PUzSe7LmF/////4b4qkOnHf8USIk6UwpyN+9rRgi7st0tAXHmOuxqSJC0AQAAABcWABT+Pp7xp0XpdNkCxDVZQ6vLNL1TU/////8CAMLrCwAAAAAZdqkUhc/xCX/Z4Ai7NK9wnGIZeziXikiIrHL++E4sAAAAF6kUM5cluiHv1irHU6m80GfWx6ajnQWHAkcwRAIgJxK+IuAnDzlPVoMR3HyppolwuAJf3TskAinwf4pfOiQCIAGLONfc0xTnNMkna9b7QPZzMlvEuqFEyADS8vAtsnZcASED0uFWdJQbrUqZY3LLh+GFbTZSYG2YVi/jnF6efkE/IQUCSDBFAiEA0SuFLYXc2WHS9fSrZgZU327tzHlMDDPOXMMJ/7X85Y0CIGczio4OFyXBl/saiK9Z9R5E5CVbIBZ8hoQDHAXR8lkqASECI7cr7vCWXRC+B3jv7NYfysb3mk6haTkzgHNEZPhPKrMAAAAAAA==
\n\n* Case: PSBT where one input has a filled scriptSig in the unsigned tx\n** Bytes in Hex: 
70736274ff0100fd0a010200000002ab0949a08c5af7c49b8212f417e2f15ab3f5c33dcf153821a8139f877a5b7be4000000006a47304402204759661797c01b036b25928948686218347d89864b719e1f7fcf57d1e511658702205309eabf56aa4d8891ffd111fdf1336f3a29da866d7f8486d75546ceedaf93190121035cdc61fc7ba971c0b501a646a2a83b102cb43881217ca682dc86e2d73fa88292feffffffab0949a08c5af7c49b8212f417e2f15ab3f5c33dcf153821a8139f877a5b7be40100000000feffffff02603bea0b000000001976a914768a40bbd740cbe81d988e71de2a4d5c71396b1d88ac8e240000000000001976a9146f4620b553fa095e721b9ee0efe9fa039cca459788ac00000000000001012000e1f5050000000017a9143545e6e33b832c47050f24d3eeb93c9c03948bc787010416001485d13537f2e265405a34dbafa9e3dda01fb82308000000
\n** Base64 String: 
cHNidP8BAP0KAQIAAAACqwlJoIxa98SbghL0F+LxWrP1wz3PFTghqBOfh3pbe+QAAAAAakcwRAIgR1lmF5fAGwNrJZKJSGhiGDR9iYZLcZ4ff89X0eURZYcCIFMJ6r9Wqk2Ikf/REf3xM286KdqGbX+EhtdVRs7tr5MZASEDXNxh/HupccC1AaZGoqg7ECy0OIEhfKaC3Ibi1z+ogpL+////qwlJoIxa98SbghL0F+LxWrP1wz3PFTghqBOfh3pbe+QBAAAAAP7///8CYDvqCwAAAAAZdqkUdopAu9dAy+gdmI5x3ipNXHE5ax2IrI4kAAAAAAAAGXapFG9GILVT+glechue4O/p+gOcykWXiKwAAAAAAAABASAA4fUFAAAAABepFDVF5uM7gyxHBQ8k0+65PJwDlIvHhwEEFgAUhdE1N/LiZUBaNNuvqePdoB+4IwgAAAA=
\n\n* Case: PSBT where inputs and outputs are provided but without an unsigned tx\n** Bytes in Hex: 
70736274ff000100fda5010100000000010289a3c71eab4d20e0371bbba4cc698fa295c9463afa2e397f8533ccb62f9567e50100000017160014be18d152a9b012039daf3da7de4f53349eecb985ffffffff86f8aa43a71dff1448893a530a7237ef6b4608bbb2dd2d0171e63aec6a4890b40100000017160014fe3e9ef1a745e974d902c4355943abcb34bd5353ffffffff0200c2eb0b000000001976a91485cff1097fd9e008bb34af709c62197b38978a4888ac72fef84e2c00000017a914339725ba21efd62ac753a9bcd067d6c7a6a39d05870247304402202712be22e0270f394f568311dc7ca9a68970b8025fdd3b240229f07f8a5f3a240220018b38d7dcd314e734c9276bd6fb40f673325bc4baa144c800d2f2f02db2765c012103d2e15674941bad4a996372cb87e1856d3652606d98562fe39c5e9e7e413f210502483045022100d12b852d85dcd961d2f5f4ab660654df6eedcc794c0c33ce5cc309ffb5fce58d022067338a8e0e1725c197fb1a88af59f51e44e4255b20167c8684031c05d1f2592a01210223b72beef0965d10be0778efecd61fcac6f79a4ea169393380734464f84f2ab30000000000
\n** Base64 String: 
cHNidP8AAQD9pQEBAAAAAAECiaPHHqtNIOA3G7ukzGmPopXJRjr6Ljl/hTPMti+VZ+UBAAAAFxYAFL4Y0VKpsBIDna89p95PUzSe7LmF/////4b4qkOnHf8USIk6UwpyN+9rRgi7st0tAXHmOuxqSJC0AQAAABcWABT+Pp7xp0XpdNkCxDVZQ6vLNL1TU/////8CAMLrCwAAAAAZdqkUhc/xCX/Z4Ai7NK9wnGIZeziXikiIrHL++E4sAAAAF6kUM5cluiHv1irHU6m80GfWx6ajnQWHAkcwRAIgJxK+IuAnDzlPVoMR3HyppolwuAJf3TskAinwf4pfOiQCIAGLONfc0xTnNMkna9b7QPZzMlvEuqFEyADS8vAtsnZcASED0uFWdJQbrUqZY3LLh+GFbTZSYG2YVi/jnF6efkE/IQUCSDBFAiEA0SuFLYXc2WHS9fSrZgZU327tzHlMDDPOXMMJ/7X85Y0CIGczio4OFyXBl/saiK9Z9R5E5CVbIBZ8hoQDHAXR8lkqASECI7cr7vCWXRC+B3jv7NYfysb3mk6haTkzgHNEZPhPKrMAAAAAAA==
\n\n* Case: PSBT with duplicate keys in an input\n** Bytes in Hex: 
70736274ff0100750200000001268171371edff285e937adeea4b37b78000c0566cbb3ad64641713ca42171bf60000000000feffffff02d3dff505000000001976a914d0c59903c5bac2868760e90fd521a4665aa7652088ac00e1f5050000000017a9143545e6e33b832c47050f24d3eeb93c9c03948bc787b32e1300000100fda5010100000000010289a3c71eab4d20e0371bbba4cc698fa295c9463afa2e397f8533ccb62f9567e50100000017160014be18d152a9b012039daf3da7de4f53349eecb985ffffffff86f8aa43a71dff1448893a530a7237ef6b4608bbb2dd2d0171e63aec6a4890b40100000017160014fe3e9ef1a745e974d902c4355943abcb34bd5353ffffffff0200c2eb0b000000001976a91485cff1097fd9e008bb34af709c62197b38978a4888ac72fef84e2c00000017a914339725ba21efd62ac753a9bcd067d6c7a6a39d05870247304402202712be22e0270f394f568311dc7ca9a68970b8025fdd3b240229f07f8a5f3a240220018b38d7dcd314e734c9276bd6fb40f673325bc4baa144c800d2f2f02db2765c012103d2e15674941bad4a996372cb87e1856d3652606d98562fe39c5e9e7e413f210502483045022100d12b852d85dcd961d2f5f4ab660654df6eedcc794c0c33ce5cc309ffb5fce58d022067338a8e0e1725c197fb1a88af59f51e44e4255b20167c8684031c05d1f2592a01210223b72beef0965d10be0778efecd61fcac6f79a4ea169393380734464f84f2ab30000000001003f0200000001ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff0000000000ffffffff010000000000000000036a010000000000000000
\n** Base64 String: 
cHNidP8BAHUCAAAAASaBcTce3/KF6Tet7qSze3gADAVmy7OtZGQXE8pCFxv2AAAAAAD+////AtPf9QUAAAAAGXapFNDFmQPFusKGh2DpD9UhpGZap2UgiKwA4fUFAAAAABepFDVF5uM7gyxHBQ8k0+65PJwDlIvHh7MuEwAAAQD9pQEBAAAAAAECiaPHHqtNIOA3G7ukzGmPopXJRjr6Ljl/hTPMti+VZ+UBAAAAFxYAFL4Y0VKpsBIDna89p95PUzSe7LmF/////4b4qkOnHf8USIk6UwpyN+9rRgi7st0tAXHmOuxqSJC0AQAAABcWABT+Pp7xp0XpdNkCxDVZQ6vLNL1TU/////8CAMLrCwAAAAAZdqkUhc/xCX/Z4Ai7NK9wnGIZeziXikiIrHL++E4sAAAAF6kUM5cluiHv1irHU6m80GfWx6ajnQWHAkcwRAIgJxK+IuAnDzlPVoMR3HyppolwuAJf3TskAinwf4pfOiQCIAGLONfc0xTnNMkna9b7QPZzMlvEuqFEyADS8vAtsnZcASED0uFWdJQbrUqZY3LLh+GFbTZSYG2YVi/jnF6efkE/IQUCSDBFAiEA0SuFLYXc2WHS9fSrZgZU327tzHlMDDPOXMMJ/7X85Y0CIGczio4OFyXBl/saiK9Z9R5E5CVbIBZ8hoQDHAXR8lkqASECI7cr7vCWXRC+B3jv7NYfysb3mk6haTkzgHNEZPhPKrMAAAAAAQA/AgAAAAH//////////////////////////////////////////wAAAAAA/////wEAAAAAAAAAAANqAQAAAAAAAAAA
\n\n* Case: PSBT with invalid global transaction typed key\n** Bytes in Hex: 
70736274ff020001550200000001279a2323a5dfb51fc45f220fa58b0fc13e1e3342792a85d7e36cd6333b5cbc390000000000ffffffff01a05aea0b000000001976a914ffe9c0061097cc3b636f2cb0460fa4fc427d2b4588ac0000000000010120955eea0b0000000017a9146345200f68d189e1adc0df1c4d16ea8f14c0dbeb87220203b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4646304302200424b58effaaa694e1559ea5c93bbfd4a89064224055cdf070b6771469442d07021f5c8eb0fea6516d60b8acb33ad64ede60e8785bfb3aa94b99bdf86151db9a9a010104220020771fd18ad459666dd49f3d564e3dbc42f4c84774e360ada16816a8ed488d5681010547522103b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd462103de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd52ae220603b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4610b4a6ba67000000800000008004000080220603de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd10b4a6ba670000008000000080050000800000
\n** Base64 String: 
cHNidP8CAAFVAgAAAAEnmiMjpd+1H8RfIg+liw/BPh4zQnkqhdfjbNYzO1y8OQAAAAAA/////wGgWuoLAAAAABl2qRT/6cAGEJfMO2NvLLBGD6T8Qn0rRYisAAAAAAABASCVXuoLAAAAABepFGNFIA9o0YnhrcDfHE0W6o8UwNvrhyICA7E0HMunaDtq9PEjjNbpfnFn1Wn6xH8eSNR1QYRDVb1GRjBDAiAEJLWO/6qmlOFVnqXJO7/UqJBkIkBVzfBwtncUaUQtBwIfXI6w/qZRbWC4rLM61k7eYOh4W/s6qUuZvfhhUduamgEBBCIAIHcf0YrUWWZt1J89Vk49vEL0yEd042CtoWgWqO1IjVaBAQVHUiEDsTQcy6doO2r08SOM1ul+cWfVafrEfx5I1HVBhENVvUYhA95V0eHayAXj+KWMH7+blMAvPbqv4Sf+/KSZXyb4IIO9Uq4iBgOxNBzLp2g7avTxI4zW6X5xZ9Vp+sR/HkjUdUGEQ1W9RhC0prpnAAAAgAAAAIAEAACAIgYD3lXR4drIBeP4pYwfv5uUwC89uq/hJ/78pJlfJvggg70QtKa6ZwAAAIAAAACABQAAgAAA
\n\n* Case: PSBT with invalid input witness utxo typed key\n** Bytes in Hex: 
70736274ff0100550200000001279a2323a5dfb51fc45f220fa58b0fc13e1e3342792a85d7e36cd6333b5cbc390000000000ffffffff01a05aea0b000000001976a914ffe9c0061097cc3b636f2cb0460fa4fc427d2b4588ac000000000002010020955eea0b0000000017a9146345200f68d189e1adc0df1c4d16ea8f14c0dbeb87220203b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4646304302200424b58effaaa694e1559ea5c93bbfd4a89064224055cdf070b6771469442d07021f5c8eb0fea6516d60b8acb33ad64ede60e8785bfb3aa94b99bdf86151db9a9a010104220020771fd18ad459666dd49f3d564e3dbc42f4c84774e360ada16816a8ed488d5681010547522103b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd462103de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd52ae220603b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4610b4a6ba67000000800000008004000080220603de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd10b4a6ba670000008000000080050000800000
\n** Base64 String: 
cHNidP8BAFUCAAAAASeaIyOl37UfxF8iD6WLD8E+HjNCeSqF1+Ns1jM7XLw5AAAAAAD/////AaBa6gsAAAAAGXapFP/pwAYQl8w7Y28ssEYPpPxCfStFiKwAAAAAAAIBACCVXuoLAAAAABepFGNFIA9o0YnhrcDfHE0W6o8UwNvrhyICA7E0HMunaDtq9PEjjNbpfnFn1Wn6xH8eSNR1QYRDVb1GRjBDAiAEJLWO/6qmlOFVnqXJO7/UqJBkIkBVzfBwtncUaUQtBwIfXI6w/qZRbWC4rLM61k7eYOh4W/s6qUuZvfhhUduamgEBBCIAIHcf0YrUWWZt1J89Vk49vEL0yEd042CtoWgWqO1IjVaBAQVHUiEDsTQcy6doO2r08SOM1ul+cWfVafrEfx5I1HVBhENVvUYhA95V0eHayAXj+KWMH7+blMAvPbqv4Sf+/KSZXyb4IIO9Uq4iBgOxNBzLp2g7avTxI4zW6X5xZ9Vp+sR/HkjUdUGEQ1W9RhC0prpnAAAAgAAAAIAEAACAIgYD3lXR4drIBeP4pYwfv5uUwC89uq/hJ/78pJlfJvggg70QtKa6ZwAAAIAAAACABQAAgAAA
\n\n* Case: PSBT with invalid pubkey length for input partial signature typed key\n** Bytes in Hex: 
70736274ff0100550200000001279a2323a5dfb51fc45f220fa58b0fc13e1e3342792a85d7e36cd6333b5cbc390000000000ffffffff01a05aea0b000000001976a914ffe9c0061097cc3b636f2cb0460fa4fc427d2b4588ac0000000000010120955eea0b0000000017a9146345200f68d189e1adc0df1c4d16ea8f14c0dbeb87210203b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd46304302200424b58effaaa694e1559ea5c93bbfd4a89064224055cdf070b6771469442d07021f5c8eb0fea6516d60b8acb33ad64ede60e8785bfb3aa94b99bdf86151db9a9a010104220020771fd18ad459666dd49f3d564e3dbc42f4c84774e360ada16816a8ed488d5681010547522103b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd462103de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd52ae220603b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4610b4a6ba67000000800000008004000080220603de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd10b4a6ba670000008000000080050000800000
\n** Base64 String: 
cHNidP8BAFUCAAAAASeaIyOl37UfxF8iD6WLD8E+HjNCeSqF1+Ns1jM7XLw5AAAAAAD/////AaBa6gsAAAAAGXapFP/pwAYQl8w7Y28ssEYPpPxCfStFiKwAAAAAAAEBIJVe6gsAAAAAF6kUY0UgD2jRieGtwN8cTRbqjxTA2+uHIQIDsTQcy6doO2r08SOM1ul+cWfVafrEfx5I1HVBhENVvUYwQwIgBCS1jv+qppThVZ6lyTu/1KiQZCJAVc3wcLZ3FGlELQcCH1yOsP6mUW1guKyzOtZO3mDoeFv7OqlLmb34YVHbmpoBAQQiACB3H9GK1FlmbdSfPVZOPbxC9MhHdONgraFoFqjtSI1WgQEFR1IhA7E0HMunaDtq9PEjjNbpfnFn1Wn6xH8eSNR1QYRDVb1GIQPeVdHh2sgF4/iljB+/m5TALz26r+En/vykmV8m+CCDvVKuIgYDsTQcy6doO2r08SOM1ul+cWfVafrEfx5I1HVBhENVvUYQtKa6ZwAAAIAAAACABAAAgCIGA95V0eHayAXj+KWMH7+blMAvPbqv4Sf+/KSZXyb4IIO9ELSmumcAAACAAAAAgAUAAIAAAA==
\n\n* Case: PSBT with invalid redeemscript typed key\n** Bytes in Hex: 
70736274ff0100550200000001279a2323a5dfb51fc45f220fa58b0fc13e1e3342792a85d7e36cd6333b5cbc390000000000ffffffff01a05aea0b000000001976a914ffe9c0061097cc3b636f2cb0460fa4fc427d2b4588ac0000000000010120955eea0b0000000017a9146345200f68d189e1adc0df1c4d16ea8f14c0dbeb87220203b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4646304302200424b58effaaa694e1559ea5c93bbfd4a89064224055cdf070b6771469442d07021f5c8eb0fea6516d60b8acb33ad64ede60e8785bfb3aa94b99bdf86151db9a9a01020400220020771fd18ad459666dd49f3d564e3dbc42f4c84774e360ada16816a8ed488d5681010547522103b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd462103de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd52ae220603b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4610b4a6ba67000000800000008004000080220603de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd10b4a6ba670000008000000080050000800000
\n** Base64 String: 
cHNidP8BAFUCAAAAASeaIyOl37UfxF8iD6WLD8E+HjNCeSqF1+Ns1jM7XLw5AAAAAAD/////AaBa6gsAAAAAGXapFP/pwAYQl8w7Y28ssEYPpPxCfStFiKwAAAAAAAEBIJVe6gsAAAAAF6kUY0UgD2jRieGtwN8cTRbqjxTA2+uHIgIDsTQcy6doO2r08SOM1ul+cWfVafrEfx5I1HVBhENVvUZGMEMCIAQktY7/qqaU4VWepck7v9SokGQiQFXN8HC2dxRpRC0HAh9cjrD+plFtYLisszrWTt5g6Hhb+zqpS5m9+GFR25qaAQIEACIAIHcf0YrUWWZt1J89Vk49vEL0yEd042CtoWgWqO1IjVaBAQVHUiEDsTQcy6doO2r08SOM1ul+cWfVafrEfx5I1HVBhENVvUYhA95V0eHayAXj+KWMH7+blMAvPbqv4Sf+/KSZXyb4IIO9Uq4iBgOxNBzLp2g7avTxI4zW6X5xZ9Vp+sR/HkjUdUGEQ1W9RhC0prpnAAAAgAAAAIAEAACAIgYD3lXR4drIBeP4pYwfv5uUwC89uq/hJ/78pJlfJvggg70QtKa6ZwAAAIAAAACABQAAgAAA
\n\n* Case: PSBT with invalid witnessscript typed key\n** Bytes in Hex: 
70736274ff0100550200000001279a2323a5dfb51fc45f220fa58b0fc13e1e3342792a85d7e36cd6333b5cbc390000000000ffffffff01a05aea0b000000001976a914ffe9c0061097cc3b636f2cb0460fa4fc427d2b4588ac0000000000010120955eea0b0000000017a9146345200f68d189e1adc0df1c4d16ea8f14c0dbeb87220203b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4646304302200424b58effaaa694e1559ea5c93bbfd4a89064224055cdf070b6771469442d07021f5c8eb0fea6516d60b8acb33ad64ede60e8785bfb3aa94b99bdf86151db9a9a010104220020771fd18ad459666dd49f3d564e3dbc42f4c84774e360ada16816a8ed488d568102050047522103b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd462103de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd52ae220603b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4610b4a6ba67000000800000008004000080220603de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd10b4a6ba670000008000000080050000800000
\n** Base64 String: 
cHNidP8BAFUCAAAAASeaIyOl37UfxF8iD6WLD8E+HjNCeSqF1+Ns1jM7XLw5AAAAAAD/////AaBa6gsAAAAAGXapFP/pwAYQl8w7Y28ssEYPpPxCfStFiKwAAAAAAAEBIJVe6gsAAAAAF6kUY0UgD2jRieGtwN8cTRbqjxTA2+uHIgIDsTQcy6doO2r08SOM1ul+cWfVafrEfx5I1HVBhENVvUZGMEMCIAQktY7/qqaU4VWepck7v9SokGQiQFXN8HC2dxRpRC0HAh9cjrD+plFtYLisszrWTt5g6Hhb+zqpS5m9+GFR25qaAQEEIgAgdx/RitRZZm3Unz1WTj28QvTIR3TjYK2haBao7UiNVoECBQBHUiEDsTQcy6doO2r08SOM1ul+cWfVafrEfx5I1HVBhENVvUYhA95V0eHayAXj+KWMH7+blMAvPbqv4Sf+/KSZXyb4IIO9Uq4iBgOxNBzLp2g7avTxI4zW6X5xZ9Vp+sR/HkjUdUGEQ1W9RhC0prpnAAAAgAAAAIAEAACAIgYD3lXR4drIBeP4pYwfv5uUwC89uq/hJ/78pJlfJvggg70QtKa6ZwAAAIAAAACABQAAgAAA
\n\n* Case: PSBT with invalid pubkey in input BIP 32 derivation paths typed key\n** Bytes in Hex: 
70736274ff0100550200000001279a2323a5dfb51fc45f220fa58b0fc13e1e3342792a85d7e36cd6333b5cbc390000000000ffffffff01a05aea0b000000001976a914ffe9c0061097cc3b636f2cb0460fa4fc427d2b4588ac0000000000010120955eea0b0000000017a9146345200f68d189e1adc0df1c4d16ea8f14c0dbeb87220203b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4646304302200424b58effaaa694e1559ea5c93bbfd4a89064224055cdf070b6771469442d07021f5c8eb0fea6516d60b8acb33ad64ede60e8785bfb3aa94b99bdf86151db9a9a010104220020771fd18ad459666dd49f3d564e3dbc42f4c84774e360ada16816a8ed488d5681010547522103b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd462103de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd52ae210603b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd10b4a6ba67000000800000008004000080220603de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd10b4a6ba670000008000000080050000800000
\n** Base64 String: 
cHNidP8BAFUCAAAAASeaIyOl37UfxF8iD6WLD8E+HjNCeSqF1+Ns1jM7XLw5AAAAAAD/////AaBa6gsAAAAAGXapFP/pwAYQl8w7Y28ssEYPpPxCfStFiKwAAAAAAAEBIJVe6gsAAAAAF6kUY0UgD2jRieGtwN8cTRbqjxTA2+uHIgIDsTQcy6doO2r08SOM1ul+cWfVafrEfx5I1HVBhENVvUZGMEMCIAQktY7/qqaU4VWepck7v9SokGQiQFXN8HC2dxRpRC0HAh9cjrD+plFtYLisszrWTt5g6Hhb+zqpS5m9+GFR25qaAQEEIgAgdx/RitRZZm3Unz1WTj28QvTIR3TjYK2haBao7UiNVoEBBUdSIQOxNBzLp2g7avTxI4zW6X5xZ9Vp+sR/HkjUdUGEQ1W9RiED3lXR4drIBeP4pYwfv5uUwC89uq/hJ/78pJlfJvggg71SriEGA7E0HMunaDtq9PEjjNbpfnFn1Wn6xH8eSNR1QYRDVb0QtKa6ZwAAAIAAAACABAAAgCIGA95V0eHayAXj+KWMH7+blMAvPbqv4Sf+/KSZXyb4IIO9ELSmumcAAACAAAAAgAUAAIAAAA==
\n\n* Case: PSBT with invalid non-witness utxo typed key\n** Bytes in Hex: 
70736274ff01009a020000000258e87a21b56daf0c23be8e7070456c336f7cbaa5c8757924f545887bb2abdd750000000000ffffffff838d0427d0ec650a68aa46bb0b098aea4422c071b2ca78352a077959d07cea1d0100000000ffffffff0270aaf00800000000160014d85c2b71d0060b09c9886aeb815e50991dda124d00e1f5050000000016001400aea9a2e5f0f876a588df5546e8742d1d87008f0000000000020000bb0200000001aad73931018bd25f84ae400b68848be09db706eac2ac18298babee71ab656f8b0000000048473044022058f6fc7c6a33e1b31548d481c826c015bd30135aad42cd67790dab66d2ad243b02204a1ced2604c6735b6393e5b41691dd78b00f0c5942fb9f751856faa938157dba01feffffff0280f0fa020000000017a9140fb9463421696b82c833af241c78c17ddbde493487d0f20a270100000017a91429ca74f8a08f81999428185c97b5d852e4063f6187650000000107da00473044022074018ad4180097b873323c0015720b3684cc8123891048e7dbcd9b55ad679c99022073d369b740e3eb53dcefa33823c8070514ca55a7dd9544f157c167913261118c01483045022100f61038b308dc1da865a34852746f015772934208c6d24454393cd99bdf2217770220056e675a675a6d0a02b85b14e5e29074d8a25a9b5760bea2816f661910a006ea01475221029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f2102dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d752ae0001012000c2eb0b0000000017a914b7f5faf40e3d40a5a459b1db3535f2b72fa921e8870107232200208c2353173743b595dfb4a07b72ba8e42e3797da74e87fe7d9d7497e3b20289030108da0400473044022062eb7a556107a7c73f45ac4ab5a1dddf6f7075fb1275969a7f383efff784bcb202200c05dbb7470dbf2f08557dd356c7325c1ed30913e996cd3840945db12228da5f01473044022065f45ba5998b59a27ffe1a7bed016af1f1f90d54b3aa8f7450aa5f56a25103bd02207f724703ad1edb96680b284b56d4ffcb88f7fb759eabbe08aa30f29b851383d20147522103089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc21023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7352ae00220203a9a4c37f5996d3aa25dbac6b570af0650394492942460b354753ed9eeca5877110d90c6a4f000000800000008004000080002202027f6399757d2eff55a136ad02c684b1838b6556e5f1b6b34282a94b6b5005109610d90c6a4f00000080000000800500008000
\n** Base64 String: 
cHNidP8BAJoCAAAAAljoeiG1ba8MI76OcHBFbDNvfLqlyHV5JPVFiHuyq911AAAAAAD/////g40EJ9DsZQpoqka7CwmK6kQiwHGyyng1Kgd5WdB86h0BAAAAAP////8CcKrwCAAAAAAWABTYXCtx0AYLCcmIauuBXlCZHdoSTQDh9QUAAAAAFgAUAK6pouXw+HaliN9VRuh0LR2HAI8AAAAAAAIAALsCAAAAAarXOTEBi9JfhK5AC2iEi+CdtwbqwqwYKYur7nGrZW+LAAAAAEhHMEQCIFj2/HxqM+GzFUjUgcgmwBW9MBNarULNZ3kNq2bSrSQ7AiBKHO0mBMZzW2OT5bQWkd14sA8MWUL7n3UYVvqpOBV9ugH+////AoDw+gIAAAAAF6kUD7lGNCFpa4LIM68kHHjBfdveSTSH0PIKJwEAAAAXqRQpynT4oI+BmZQoGFyXtdhS5AY/YYdlAAAAAQfaAEcwRAIgdAGK1BgAl7hzMjwAFXILNoTMgSOJEEjn282bVa1nnJkCIHPTabdA4+tT3O+jOCPIBwUUylWn3ZVE8VfBZ5EyYRGMAUgwRQIhAPYQOLMI3B2oZaNIUnRvAVdyk0IIxtJEVDk82ZvfIhd3AiAFbmdaZ1ptCgK4WxTl4pB02KJam1dgvqKBb2YZEKAG6gFHUiEClYO/Oa4KYJdHrRma3dY0+mEIVZ1sXNObTCGD8auW4H8hAtq2H/SaFNtqfQKwzR+7ePxLGDErW05U2uTbovv+9TbXUq4AAQEgAMLrCwAAAAAXqRS39fr0Dj1ApaRZsds1NfK3L6kh6IcBByMiACCMI1MXN0O1ld+0oHtyuo5C43l9p06H/n2ddJfjsgKJAwEI2gQARzBEAiBi63pVYQenxz9FrEq1od3fb3B1+xJ1lpp/OD7/94S8sgIgDAXbt0cNvy8IVX3TVscyXB7TCRPpls04QJRdsSIo2l8BRzBEAiBl9FulmYtZon/+GnvtAWrx8fkNVLOqj3RQql9WolEDvQIgf3JHA60e25ZoCyhLVtT/y4j3+3Weq74IqjDym4UTg9IBR1IhAwidwQx6xttU+RMpr2FzM9s4jOrQwjH3IzedG5kDCwLcIQI63ZBPPW3PWd25BrDe4jUpt/+57VDl6GFRkmhgIh8Oc1KuACICA6mkw39ZltOqJdusa1cK8GUDlEkpQkYLNUdT7Z7spYdxENkMak8AAACAAAAAgAQAAIAAIgICf2OZdX0u/1WhNq0CxoSxg4tlVuXxtrNCgqlLa1AFEJYQ2QxqTwAAAIAAAACABQAAgAA=
\n\n* Case: PSBT with invalid final scriptsig typed key\n** Bytes in Hex: 
70736274ff01009a020000000258e87a21b56daf0c23be8e7070456c336f7cbaa5c8757924f545887bb2abdd750000000000ffffffff838d0427d0ec650a68aa46bb0b098aea4422c071b2ca78352a077959d07cea1d0100000000ffffffff0270aaf00800000000160014d85c2b71d0060b09c9886aeb815e50991dda124d00e1f5050000000016001400aea9a2e5f0f876a588df5546e8742d1d87008f00000000000100bb0200000001aad73931018bd25f84ae400b68848be09db706eac2ac18298babee71ab656f8b0000000048473044022058f6fc7c6a33e1b31548d481c826c015bd30135aad42cd67790dab66d2ad243b02204a1ced2604c6735b6393e5b41691dd78b00f0c5942fb9f751856faa938157dba01feffffff0280f0fa020000000017a9140fb9463421696b82c833af241c78c17ddbde493487d0f20a270100000017a91429ca74f8a08f81999428185c97b5d852e4063f618765000000020700da00473044022074018ad4180097b873323c0015720b3684cc8123891048e7dbcd9b55ad679c99022073d369b740e3eb53dcefa33823c8070514ca55a7dd9544f157c167913261118c01483045022100f61038b308dc1da865a34852746f015772934208c6d24454393cd99bdf2217770220056e675a675a6d0a02b85b14e5e29074d8a25a9b5760bea2816f661910a006ea01475221029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f2102dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d752ae0001012000c2eb0b0000000017a914b7f5faf40e3d40a5a459b1db3535f2b72fa921e8870107232200208c2353173743b595dfb4a07b72ba8e42e3797da74e87fe7d9d7497e3b20289030108da0400473044022062eb7a556107a7c73f45ac4ab5a1dddf6f7075fb1275969a7f383efff784bcb202200c05dbb7470dbf2f08557dd356c7325c1ed30913e996cd3840945db12228da5f01473044022065f45ba5998b59a27ffe1a7bed016af1f1f90d54b3aa8f7450aa5f56a25103bd02207f724703ad1edb96680b284b56d4ffcb88f7fb759eabbe08aa30f29b851383d20147522103089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc21023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7352ae00220203a9a4c37f5996d3aa25dbac6b570af0650394492942460b354753ed9eeca5877110d90c6a4f000000800000008004000080002202027f6399757d2eff55a136ad02c684b1838b6556e5f1b6b34282a94b6b5005109610d90c6a4f00000080000000800500008000
\n** Base64 String: 
cHNidP8BAJoCAAAAAljoeiG1ba8MI76OcHBFbDNvfLqlyHV5JPVFiHuyq911AAAAAAD/////g40EJ9DsZQpoqka7CwmK6kQiwHGyyng1Kgd5WdB86h0BAAAAAP////8CcKrwCAAAAAAWABTYXCtx0AYLCcmIauuBXlCZHdoSTQDh9QUAAAAAFgAUAK6pouXw+HaliN9VRuh0LR2HAI8AAAAAAAEAuwIAAAABqtc5MQGL0l+ErkALaISL4J23BurCrBgpi6vucatlb4sAAAAASEcwRAIgWPb8fGoz4bMVSNSByCbAFb0wE1qtQs1neQ2rZtKtJDsCIEoc7SYExnNbY5PltBaR3XiwDwxZQvufdRhW+qk4FX26Af7///8CgPD6AgAAAAAXqRQPuUY0IWlrgsgzryQceMF9295JNIfQ8gonAQAAABepFCnKdPigj4GZlCgYXJe12FLkBj9hh2UAAAACBwDaAEcwRAIgdAGK1BgAl7hzMjwAFXILNoTMgSOJEEjn282bVa1nnJkCIHPTabdA4+tT3O+jOCPIBwUUylWn3ZVE8VfBZ5EyYRGMAUgwRQIhAPYQOLMI3B2oZaNIUnRvAVdyk0IIxtJEVDk82ZvfIhd3AiAFbmdaZ1ptCgK4WxTl4pB02KJam1dgvqKBb2YZEKAG6gFHUiEClYO/Oa4KYJdHrRma3dY0+mEIVZ1sXNObTCGD8auW4H8hAtq2H/SaFNtqfQKwzR+7ePxLGDErW05U2uTbovv+9TbXUq4AAQEgAMLrCwAAAAAXqRS39fr0Dj1ApaRZsds1NfK3L6kh6IcBByMiACCMI1MXN0O1ld+0oHtyuo5C43l9p06H/n2ddJfjsgKJAwEI2gQARzBEAiBi63pVYQenxz9FrEq1od3fb3B1+xJ1lpp/OD7/94S8sgIgDAXbt0cNvy8IVX3TVscyXB7TCRPpls04QJRdsSIo2l8BRzBEAiBl9FulmYtZon/+GnvtAWrx8fkNVLOqj3RQql9WolEDvQIgf3JHA60e25ZoCyhLVtT/y4j3+3Weq74IqjDym4UTg9IBR1IhAwidwQx6xttU+RMpr2FzM9s4jOrQwjH3IzedG5kDCwLcIQI63ZBPPW3PWd25BrDe4jUpt/+57VDl6GFRkmhgIh8Oc1KuACICA6mkw39ZltOqJdusa1cK8GUDlEkpQkYLNUdT7Z7spYdxENkMak8AAACAAAAAgAQAAIAAIgICf2OZdX0u/1WhNq0CxoSxg4tlVuXxtrNCgqlLa1AFEJYQ2QxqTwAAAIAAAACABQAAgAA=
\n\n* Case: PSBT with invalid final script witness typed key\n** Bytes in Hex: 
70736274ff01009a020000000258e87a21b56daf0c23be8e7070456c336f7cbaa5c8757924f545887bb2abdd750000000000ffffffff838d0427d0ec650a68aa46bb0b098aea4422c071b2ca78352a077959d07cea1d0100000000ffffffff0270aaf00800000000160014d85c2b71d0060b09c9886aeb815e50991dda124d00e1f5050000000016001400aea9a2e5f0f876a588df5546e8742d1d87008f00000000000100bb0200000001aad73931018bd25f84ae400b68848be09db706eac2ac18298babee71ab656f8b0000000048473044022058f6fc7c6a33e1b31548d481c826c015bd30135aad42cd67790dab66d2ad243b02204a1ced2604c6735b6393e5b41691dd78b00f0c5942fb9f751856faa938157dba01feffffff0280f0fa020000000017a9140fb9463421696b82c833af241c78c17ddbde493487d0f20a270100000017a91429ca74f8a08f81999428185c97b5d852e4063f6187650000000107da00473044022074018ad4180097b873323c0015720b3684cc8123891048e7dbcd9b55ad679c99022073d369b740e3eb53dcefa33823c8070514ca55a7dd9544f157c167913261118c01483045022100f61038b308dc1da865a34852746f015772934208c6d24454393cd99bdf2217770220056e675a675a6d0a02b85b14e5e29074d8a25a9b5760bea2816f661910a006ea01475221029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f2102dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d752ae0001012000c2eb0b0000000017a914b7f5faf40e3d40a5a459b1db3535f2b72fa921e8870107232200208c2353173743b595dfb4a07b72ba8e42e3797da74e87fe7d9d7497e3b2028903020800da0400473044022062eb7a556107a7c73f45ac4ab5a1dddf6f7075fb1275969a7f383efff784bcb202200c05dbb7470dbf2f08557dd356c7325c1ed30913e996cd3840945db12228da5f01473044022065f45ba5998b59a27ffe1a7bed016af1f1f90d54b3aa8f7450aa5f56a25103bd02207f724703ad1edb96680b284b56d4ffcb88f7fb759eabbe08aa30f29b851383d20147522103089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc21023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7352ae00220203a9a4c37f5996d3aa25dbac6b570af0650394492942460b354753ed9eeca5877110d90c6a4f000000800000008004000080002202027f6399757d2eff55a136ad02c684b1838b6556e5f1b6b34282a94b6b5005109610d90c6a4f00000080000000800500008000
\n** Base64 String: 
cHNidP8BAJoCAAAAAljoeiG1ba8MI76OcHBFbDNvfLqlyHV5JPVFiHuyq911AAAAAAD/////g40EJ9DsZQpoqka7CwmK6kQiwHGyyng1Kgd5WdB86h0BAAAAAP////8CcKrwCAAAAAAWABTYXCtx0AYLCcmIauuBXlCZHdoSTQDh9QUAAAAAFgAUAK6pouXw+HaliN9VRuh0LR2HAI8AAAAAAAEAuwIAAAABqtc5MQGL0l+ErkALaISL4J23BurCrBgpi6vucatlb4sAAAAASEcwRAIgWPb8fGoz4bMVSNSByCbAFb0wE1qtQs1neQ2rZtKtJDsCIEoc7SYExnNbY5PltBaR3XiwDwxZQvufdRhW+qk4FX26Af7///8CgPD6AgAAAAAXqRQPuUY0IWlrgsgzryQceMF9295JNIfQ8gonAQAAABepFCnKdPigj4GZlCgYXJe12FLkBj9hh2UAAAABB9oARzBEAiB0AYrUGACXuHMyPAAVcgs2hMyBI4kQSOfbzZtVrWecmQIgc9Npt0Dj61Pc76M4I8gHBRTKVafdlUTxV8FnkTJhEYwBSDBFAiEA9hA4swjcHahlo0hSdG8BV3KTQgjG0kRUOTzZm98iF3cCIAVuZ1pnWm0KArhbFOXikHTYolqbV2C+ooFvZhkQoAbqAUdSIQKVg785rgpgl0etGZrd1jT6YQhVnWxc05tMIYPxq5bgfyEC2rYf9JoU22p9ArDNH7t4/EsYMStbTlTa5Nui+/71NtdSrgABASAAwusLAAAAABepFLf1+vQOPUClpFmx2zU18rcvqSHohwEHIyIAIIwjUxc3Q7WV37Sge3K6jkLjeX2nTof+fZ10l+OyAokDAggA2gQARzBEAiBi63pVYQenxz9FrEq1od3fb3B1+xJ1lpp/OD7/94S8sgIgDAXbt0cNvy8IVX3TVscyXB7TCRPpls04QJRdsSIo2l8BRzBEAiBl9FulmYtZon/+GnvtAWrx8fkNVLOqj3RQql9WolEDvQIgf3JHA60e25ZoCyhLVtT/y4j3+3Weq74IqjDym4UTg9IBR1IhAwidwQx6xttU+RMpr2FzM9s4jOrQwjH3IzedG5kDCwLcIQI63ZBPPW3PWd25BrDe4jUpt/+57VDl6GFRkmhgIh8Oc1KuACICA6mkw39ZltOqJdusa1cK8GUDlEkpQkYLNUdT7Z7spYdxENkMak8AAACAAAAAgAQAAIAAIgICf2OZdX0u/1WhNq0CxoSxg4tlVuXxtrNCgqlLa1AFEJYQ2QxqTwAAAIAAAACABQAAgAA=
\n\n* Case: PSBT with invalid pubkey in output BIP 32 derivation paths typed key\n** Bytes in Hex: 
70736274ff01009a020000000258e87a21b56daf0c23be8e7070456c336f7cbaa5c8757924f545887bb2abdd750000000000ffffffff838d0427d0ec650a68aa46bb0b098aea4422c071b2ca78352a077959d07cea1d0100000000ffffffff0270aaf00800000000160014d85c2b71d0060b09c9886aeb815e50991dda124d00e1f5050000000016001400aea9a2e5f0f876a588df5546e8742d1d87008f00000000000100bb0200000001aad73931018bd25f84ae400b68848be09db706eac2ac18298babee71ab656f8b0000000048473044022058f6fc7c6a33e1b31548d481c826c015bd30135aad42cd67790dab66d2ad243b02204a1ced2604c6735b6393e5b41691dd78b00f0c5942fb9f751856faa938157dba01feffffff0280f0fa020000000017a9140fb9463421696b82c833af241c78c17ddbde493487d0f20a270100000017a91429ca74f8a08f81999428185c97b5d852e4063f6187650000000107da00473044022074018ad4180097b873323c0015720b3684cc8123891048e7dbcd9b55ad679c99022073d369b740e3eb53dcefa33823c8070514ca55a7dd9544f157c167913261118c01483045022100f61038b308dc1da865a34852746f015772934208c6d24454393cd99bdf2217770220056e675a675a6d0a02b85b14e5e29074d8a25a9b5760bea2816f661910a006ea01475221029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f2102dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d752ae0001012000c2eb0b0000000017a914b7f5faf40e3d40a5a459b1db3535f2b72fa921e8870107232200208c2353173743b595dfb4a07b72ba8e42e3797da74e87fe7d9d7497e3b20289030108da0400473044022062eb7a556107a7c73f45ac4ab5a1dddf6f7075fb1275969a7f383efff784bcb202200c05dbb7470dbf2f08557dd356c7325c1ed30913e996cd3840945db12228da5f01473044022065f45ba5998b59a27ffe1a7bed016af1f1f90d54b3aa8f7450aa5f56a25103bd02207f724703ad1edb96680b284b56d4ffcb88f7fb759eabbe08aa30f29b851383d20147522103089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc21023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7352ae00210203a9a4c37f5996d3aa25dbac6b570af0650394492942460b354753ed9eeca58710d90c6a4f000000800000008004000080002202027f6399757d2eff55a136ad02c684b1838b6556e5f1b6b34282a94b6b5005109610d90c6a4f00000080000000800500008000
\n** Base64 String: 
cHNidP8BAJoCAAAAAljoeiG1ba8MI76OcHBFbDNvfLqlyHV5JPVFiHuyq911AAAAAAD/////g40EJ9DsZQpoqka7CwmK6kQiwHGyyng1Kgd5WdB86h0BAAAAAP////8CcKrwCAAAAAAWABTYXCtx0AYLCcmIauuBXlCZHdoSTQDh9QUAAAAAFgAUAK6pouXw+HaliN9VRuh0LR2HAI8AAAAAAAEAuwIAAAABqtc5MQGL0l+ErkALaISL4J23BurCrBgpi6vucatlb4sAAAAASEcwRAIgWPb8fGoz4bMVSNSByCbAFb0wE1qtQs1neQ2rZtKtJDsCIEoc7SYExnNbY5PltBaR3XiwDwxZQvufdRhW+qk4FX26Af7///8CgPD6AgAAAAAXqRQPuUY0IWlrgsgzryQceMF9295JNIfQ8gonAQAAABepFCnKdPigj4GZlCgYXJe12FLkBj9hh2UAAAABB9oARzBEAiB0AYrUGACXuHMyPAAVcgs2hMyBI4kQSOfbzZtVrWecmQIgc9Npt0Dj61Pc76M4I8gHBRTKVafdlUTxV8FnkTJhEYwBSDBFAiEA9hA4swjcHahlo0hSdG8BV3KTQgjG0kRUOTzZm98iF3cCIAVuZ1pnWm0KArhbFOXikHTYolqbV2C+ooFvZhkQoAbqAUdSIQKVg785rgpgl0etGZrd1jT6YQhVnWxc05tMIYPxq5bgfyEC2rYf9JoU22p9ArDNH7t4/EsYMStbTlTa5Nui+/71NtdSrgABASAAwusLAAAAABepFLf1+vQOPUClpFmx2zU18rcvqSHohwEHIyIAIIwjUxc3Q7WV37Sge3K6jkLjeX2nTof+fZ10l+OyAokDAQjaBABHMEQCIGLrelVhB6fHP0WsSrWh3d9vcHX7EnWWmn84Pv/3hLyyAiAMBdu3Rw2/LwhVfdNWxzJcHtMJE+mWzThAlF2xIijaXwFHMEQCIGX0W6WZi1mif/4ae+0BavHx+Q1Us6qPdFCqX1aiUQO9AiB/ckcDrR7blmgLKEtW1P/LiPf7dZ6rvgiqMPKbhROD0gFHUiEDCJ3BDHrG21T5EymvYXMz2ziM6tDCMfcjN50bmQMLAtwhAjrdkE89bc9Z3bkGsN7iNSm3/7ntUOXoYVGSaGAiHw5zUq4AIQIDqaTDf1mW06ol26xrVwrwZQOUSSlCRgs1R1PtnuylhxDZDGpPAAAAgAAAAIAEAACAACICAn9jmXV9Lv9VoTatAsaEsYOLZVbl8bazQoKpS2tQBRCWENkMak8AAACAAAAAgAUAAIAA
\n\n* Case: PSBT with invalid input sighash type typed key\n** Bytes in Hex: 
70736274ff0100730200000001301ae986e516a1ec8ac5b4bc6573d32f83b465e23ad76167d68b38e730b4dbdb0000000000ffffffff02747b01000000000017a91403aa17ae882b5d0d54b25d63104e4ffece7b9ea2876043993b0000000017a914b921b1ba6f722e4bfa83b6557a3139986a42ec8387000000000001011f00ca9a3b00000000160014d2d94b64ae08587eefc8eeb187c601e939f9037c0203000100000000010016001462e9e982fff34dd8239610316b090cd2a3b747cb000100220020876bad832f1d168015ed41232a9ea65a1815d9ef13c0ef8759f64b5b2b278a65010125512103b7ce23a01c5b4bf00a642537cdfabb315b668332867478ef51309d2bd57f8a8751ae00
\n** Base64 String: 
cHNidP8BAHMCAAAAATAa6YblFqHsisW0vGVz0y+DtGXiOtdhZ9aLOOcwtNvbAAAAAAD/////AnR7AQAAAAAAF6kUA6oXrogrXQ1Usl1jEE5P/s57nqKHYEOZOwAAAAAXqRS5IbG6b3IuS/qDtlV6MTmYakLsg4cAAAAAAAEBHwDKmjsAAAAAFgAU0tlLZK4IWH7vyO6xh8YB6Tn5A3wCAwABAAAAAAEAFgAUYunpgv/zTdgjlhAxawkM0qO3R8sAAQAiACCHa62DLx0WgBXtQSMqnqZaGBXZ7xPA74dZ9ktbKyeKZQEBJVEhA7fOI6AcW0vwCmQlN836uzFbZoMyhnR471EwnSvVf4qHUa4A
\n\n* Case: PSBT with invalid output redeemScript typed key\n** Bytes in Hex: 
70736274ff0100730200000001301ae986e516a1ec8ac5b4bc6573d32f83b465e23ad76167d68b38e730b4dbdb0000000000ffffffff02747b01000000000017a91403aa17ae882b5d0d54b25d63104e4ffece7b9ea2876043993b0000000017a914b921b1ba6f722e4bfa83b6557a3139986a42ec8387000000000001011f00ca9a3b00000000160014d2d94b64ae08587eefc8eeb187c601e939f9037c0002000016001462e9e982fff34dd8239610316b090cd2a3b747cb000100220020876bad832f1d168015ed41232a9ea65a1815d9ef13c0ef8759f64b5b2b278a65010125512103b7ce23a01c5b4bf00a642537cdfabb315b668332867478ef51309d2bd57f8a8751ae00
\n** Base64 String: 
cHNidP8BAHMCAAAAATAa6YblFqHsisW0vGVz0y+DtGXiOtdhZ9aLOOcwtNvbAAAAAAD/////AnR7AQAAAAAAF6kUA6oXrogrXQ1Usl1jEE5P/s57nqKHYEOZOwAAAAAXqRS5IbG6b3IuS/qDtlV6MTmYakLsg4cAAAAAAAEBHwDKmjsAAAAAFgAU0tlLZK4IWH7vyO6xh8YB6Tn5A3wAAgAAFgAUYunpgv/zTdgjlhAxawkM0qO3R8sAAQAiACCHa62DLx0WgBXtQSMqnqZaGBXZ7xPA74dZ9ktbKyeKZQEBJVEhA7fOI6AcW0vwCmQlN836uzFbZoMyhnR471EwnSvVf4qHUa4A
\n\n* Case: PSBT with invalid output witnessScript typed key\n** Bytes in Hex: 
70736274ff0100730200000001301ae986e516a1ec8ac5b4bc6573d32f83b465e23ad76167d68b38e730b4dbdb0000000000ffffffff02747b01000000000017a91403aa17ae882b5d0d54b25d63104e4ffece7b9ea2876043993b0000000017a914b921b1ba6f722e4bfa83b6557a3139986a42ec8387000000000001011f00ca9a3b00000000160014d2d94b64ae08587eefc8eeb187c601e939f9037c00010016001462e9e982fff34dd8239610316b090cd2a3b747cb000100220020876bad832f1d168015ed41232a9ea65a1815d9ef13c0ef8759f64b5b2b278a6521010025512103b7ce23a01c5b4bf00a642537cdfabb315b668332867478ef51309d06d57f8a8751ae00
\n** Base64 String: 
cHNidP8BAHMCAAAAATAa6YblFqHsisW0vGVz0y+DtGXiOtdhZ9aLOOcwtNvbAAAAAAD/////AnR7AQAAAAAAF6kUA6oXrogrXQ1Usl1jEE5P/s57nqKHYEOZOwAAAAAXqRS5IbG6b3IuS/qDtlV6MTmYakLsg4cAAAAAAAEBHwDKmjsAAAAAFgAU0tlLZK4IWH7vyO6xh8YB6Tn5A3wAAQAWABRi6emC//NN2COWEDFrCQzSo7dHywABACIAIIdrrYMvHRaAFe1BIyqeploYFdnvE8Dvh1n2S1srJ4plIQEAJVEhA7fOI6AcW0vwCmQlN836uzFbZoMyhnR471EwnQbVf4qHUa4A
\n\n* Case: PSBT with unsigned tx serialized with witness serialization format\n** Bytes in Hex: 
70736274ff01007802000000000101268171371edff285e937adeea4b37b78000c0566cbb3ad64641713ca42171bf60000000000feffffff02d3dff505000000001976a914d0c59903c5bac2868760e90fd521a4665aa7652088ac00e1f5050000000017a9143545e6e33b832c47050f24d3eeb93c9c03948bc78700b32e1300000100fda5010100000000010289a3c71eab4d20e0371bbba4cc698fa295c9463afa2e397f8533ccb62f9567e50100000017160014be18d152a9b012039daf3da7de4f53349eecb985ffffffff86f8aa43a71dff1448893a530a7237ef6b4608bbb2dd2d0171e63aec6a4890b40100000017160014fe3e9ef1a745e974d902c4355943abcb34bd5353ffffffff0200c2eb0b000000001976a91485cff1097fd9e008bb34af709c62197b38978a4888ac72fef84e2c00000017a914339725ba21efd62ac753a9bcd067d6c7a6a39d05870247304402202712be22e0270f394f568311dc7ca9a68970b8025fdd3b240229f07f8a5f3a240220018b38d7dcd314e734c9276bd6fb40f673325bc4baa144c800d2f2f02db2765c012103d2e15674941bad4a996372cb87e1856d3652606d98562fe39c5e9e7e413f210502483045022100d12b852d85dcd961d2f5f4ab660654df6eedcc794c0c33ce5cc309ffb5fce58d022067338a8e0e1725c197fb1a88af59f51e44e4255b20167c8684031c05d1f2592a01210223b72beef0965d10be0778efecd61fcac6f79a4ea169393380734464f84f2ab300000000000000
\n** Base64 String: 
cHNidP8BAHgCAAAAAAEBJoFxNx7f8oXpN63upLN7eAAMBWbLs61kZBcTykIXG/YAAAAAAP7///8C09/1BQAAAAAZdqkU0MWZA8W6woaHYOkP1SGkZlqnZSCIrADh9QUAAAAAF6kUNUXm4zuDLEcFDyTT7rk8nAOUi8eHALMuEwAAAQD9pQEBAAAAAAECiaPHHqtNIOA3G7ukzGmPopXJRjr6Ljl/hTPMti+VZ+UBAAAAFxYAFL4Y0VKpsBIDna89p95PUzSe7LmF/////4b4qkOnHf8USIk6UwpyN+9rRgi7st0tAXHmOuxqSJC0AQAAABcWABT+Pp7xp0XpdNkCxDVZQ6vLNL1TU/////8CAMLrCwAAAAAZdqkUhc/xCX/Z4Ai7NK9wnGIZeziXikiIrHL++E4sAAAAF6kUM5cluiHv1irHU6m80GfWx6ajnQWHAkcwRAIgJxK+IuAnDzlPVoMR3HyppolwuAJf3TskAinwf4pfOiQCIAGLONfc0xTnNMkna9b7QPZzMlvEuqFEyADS8vAtsnZcASED0uFWdJQbrUqZY3LLh+GFbTZSYG2YVi/jnF6efkE/IQUCSDBFAiEA0SuFLYXc2WHS9fSrZgZU327tzHlMDDPOXMMJ/7X85Y0CIGczio4OFyXBl/saiK9Z9R5E5CVbIBZ8hoQDHAXR8lkqASECI7cr7vCWXRC+B3jv7NYfysb3mk6haTkzgHNEZPhPKrMAAAAAAAAA
\n\n* Case: PSBT with an invalid value data due to its size being not the stated size\n** Bytes in Hex: 
70736274ff0100337401ff0700010000000100ff01000a73317428ff0000000001ff010301000001000000000000000076010000004100090000000000
\n** Base64 String: 
cHNidP8BADN0Af8HAAEAAAABAP8BAApzMXQo/wAAAAAB/wEDAQAAAQAAAAAAAAAAdgEAAABBAAkAAAAAAA==
\n\nThe following are valid PSBTs:\n\n* Case: PSBT with one P2PKH input. Outputs are empty\n** Bytes in Hex: 
70736274ff0100750200000001268171371edff285e937adeea4b37b78000c0566cbb3ad64641713ca42171bf60000000000feffffff02d3dff505000000001976a914d0c59903c5bac2868760e90fd521a4665aa7652088ac00e1f5050000000017a9143545e6e33b832c47050f24d3eeb93c9c03948bc787b32e1300000100fda5010100000000010289a3c71eab4d20e0371bbba4cc698fa295c9463afa2e397f8533ccb62f9567e50100000017160014be18d152a9b012039daf3da7de4f53349eecb985ffffffff86f8aa43a71dff1448893a530a7237ef6b4608bbb2dd2d0171e63aec6a4890b40100000017160014fe3e9ef1a745e974d902c4355943abcb34bd5353ffffffff0200c2eb0b000000001976a91485cff1097fd9e008bb34af709c62197b38978a4888ac72fef84e2c00000017a914339725ba21efd62ac753a9bcd067d6c7a6a39d05870247304402202712be22e0270f394f568311dc7ca9a68970b8025fdd3b240229f07f8a5f3a240220018b38d7dcd314e734c9276bd6fb40f673325bc4baa144c800d2f2f02db2765c012103d2e15674941bad4a996372cb87e1856d3652606d98562fe39c5e9e7e413f210502483045022100d12b852d85dcd961d2f5f4ab660654df6eedcc794c0c33ce5cc309ffb5fce58d022067338a8e0e1725c197fb1a88af59f51e44e4255b20167c8684031c05d1f2592a01210223b72beef0965d10be0778efecd61fcac6f79a4ea169393380734464f84f2ab300000000000000
\n** Base64 String: 
cHNidP8BAHUCAAAAASaBcTce3/KF6Tet7qSze3gADAVmy7OtZGQXE8pCFxv2AAAAAAD+////AtPf9QUAAAAAGXapFNDFmQPFusKGh2DpD9UhpGZap2UgiKwA4fUFAAAAABepFDVF5uM7gyxHBQ8k0+65PJwDlIvHh7MuEwAAAQD9pQEBAAAAAAECiaPHHqtNIOA3G7ukzGmPopXJRjr6Ljl/hTPMti+VZ+UBAAAAFxYAFL4Y0VKpsBIDna89p95PUzSe7LmF/////4b4qkOnHf8USIk6UwpyN+9rRgi7st0tAXHmOuxqSJC0AQAAABcWABT+Pp7xp0XpdNkCxDVZQ6vLNL1TU/////8CAMLrCwAAAAAZdqkUhc/xCX/Z4Ai7NK9wnGIZeziXikiIrHL++E4sAAAAF6kUM5cluiHv1irHU6m80GfWx6ajnQWHAkcwRAIgJxK+IuAnDzlPVoMR3HyppolwuAJf3TskAinwf4pfOiQCIAGLONfc0xTnNMkna9b7QPZzMlvEuqFEyADS8vAtsnZcASED0uFWdJQbrUqZY3LLh+GFbTZSYG2YVi/jnF6efkE/IQUCSDBFAiEA0SuFLYXc2WHS9fSrZgZU327tzHlMDDPOXMMJ/7X85Y0CIGczio4OFyXBl/saiK9Z9R5E5CVbIBZ8hoQDHAXR8lkqASECI7cr7vCWXRC+B3jv7NYfysb3mk6haTkzgHNEZPhPKrMAAAAAAAAA
\n\n* Case: PSBT with one P2PKH input and one P2SH-P2WPKH input. First input is signed and finalized. Outputs are empty\n** Bytes in Hex: 
70736274ff0100a00200000002ab0949a08c5af7c49b8212f417e2f15ab3f5c33dcf153821a8139f877a5b7be40000000000feffffffab0949a08c5af7c49b8212f417e2f15ab3f5c33dcf153821a8139f877a5b7be40100000000feffffff02603bea0b000000001976a914768a40bbd740cbe81d988e71de2a4d5c71396b1d88ac8e240000000000001976a9146f4620b553fa095e721b9ee0efe9fa039cca459788ac000000000001076a47304402204759661797c01b036b25928948686218347d89864b719e1f7fcf57d1e511658702205309eabf56aa4d8891ffd111fdf1336f3a29da866d7f8486d75546ceedaf93190121035cdc61fc7ba971c0b501a646a2a83b102cb43881217ca682dc86e2d73fa882920001012000e1f5050000000017a9143545e6e33b832c47050f24d3eeb93c9c03948bc787010416001485d13537f2e265405a34dbafa9e3dda01fb82308000000
\n** Base64 String: 
cHNidP8BAKACAAAAAqsJSaCMWvfEm4IS9Bfi8Vqz9cM9zxU4IagTn4d6W3vkAAAAAAD+////qwlJoIxa98SbghL0F+LxWrP1wz3PFTghqBOfh3pbe+QBAAAAAP7///8CYDvqCwAAAAAZdqkUdopAu9dAy+gdmI5x3ipNXHE5ax2IrI4kAAAAAAAAGXapFG9GILVT+glechue4O/p+gOcykWXiKwAAAAAAAEHakcwRAIgR1lmF5fAGwNrJZKJSGhiGDR9iYZLcZ4ff89X0eURZYcCIFMJ6r9Wqk2Ikf/REf3xM286KdqGbX+EhtdVRs7tr5MZASEDXNxh/HupccC1AaZGoqg7ECy0OIEhfKaC3Ibi1z+ogpIAAQEgAOH1BQAAAAAXqRQ1RebjO4MsRwUPJNPuuTycA5SLx4cBBBYAFIXRNTfy4mVAWjTbr6nj3aAfuCMIAAAA
\n\n* Case: PSBT with one P2PKH input which has a non-final scriptSig and has a sighash type specified. Outputs are empty\n** Bytes in Hex: 
70736274ff0100750200000001268171371edff285e937adeea4b37b78000c0566cbb3ad64641713ca42171bf60000000000feffffff02d3dff505000000001976a914d0c59903c5bac2868760e90fd521a4665aa7652088ac00e1f5050000000017a9143545e6e33b832c47050f24d3eeb93c9c03948bc787b32e1300000100fda5010100000000010289a3c71eab4d20e0371bbba4cc698fa295c9463afa2e397f8533ccb62f9567e50100000017160014be18d152a9b012039daf3da7de4f53349eecb985ffffffff86f8aa43a71dff1448893a530a7237ef6b4608bbb2dd2d0171e63aec6a4890b40100000017160014fe3e9ef1a745e974d902c4355943abcb34bd5353ffffffff0200c2eb0b000000001976a91485cff1097fd9e008bb34af709c62197b38978a4888ac72fef84e2c00000017a914339725ba21efd62ac753a9bcd067d6c7a6a39d05870247304402202712be22e0270f394f568311dc7ca9a68970b8025fdd3b240229f07f8a5f3a240220018b38d7dcd314e734c9276bd6fb40f673325bc4baa144c800d2f2f02db2765c012103d2e15674941bad4a996372cb87e1856d3652606d98562fe39c5e9e7e413f210502483045022100d12b852d85dcd961d2f5f4ab660654df6eedcc794c0c33ce5cc309ffb5fce58d022067338a8e0e1725c197fb1a88af59f51e44e4255b20167c8684031c05d1f2592a01210223b72beef0965d10be0778efecd61fcac6f79a4ea169393380734464f84f2ab30000000001030401000000000000
\n** Base64 String: 
cHNidP8BAHUCAAAAASaBcTce3/KF6Tet7qSze3gADAVmy7OtZGQXE8pCFxv2AAAAAAD+////AtPf9QUAAAAAGXapFNDFmQPFusKGh2DpD9UhpGZap2UgiKwA4fUFAAAAABepFDVF5uM7gyxHBQ8k0+65PJwDlIvHh7MuEwAAAQD9pQEBAAAAAAECiaPHHqtNIOA3G7ukzGmPopXJRjr6Ljl/hTPMti+VZ+UBAAAAFxYAFL4Y0VKpsBIDna89p95PUzSe7LmF/////4b4qkOnHf8USIk6UwpyN+9rRgi7st0tAXHmOuxqSJC0AQAAABcWABT+Pp7xp0XpdNkCxDVZQ6vLNL1TU/////8CAMLrCwAAAAAZdqkUhc/xCX/Z4Ai7NK9wnGIZeziXikiIrHL++E4sAAAAF6kUM5cluiHv1irHU6m80GfWx6ajnQWHAkcwRAIgJxK+IuAnDzlPVoMR3HyppolwuAJf3TskAinwf4pfOiQCIAGLONfc0xTnNMkna9b7QPZzMlvEuqFEyADS8vAtsnZcASED0uFWdJQbrUqZY3LLh+GFbTZSYG2YVi/jnF6efkE/IQUCSDBFAiEA0SuFLYXc2WHS9fSrZgZU327tzHlMDDPOXMMJ/7X85Y0CIGczio4OFyXBl/saiK9Z9R5E5CVbIBZ8hoQDHAXR8lkqASECI7cr7vCWXRC+B3jv7NYfysb3mk6haTkzgHNEZPhPKrMAAAAAAQMEAQAAAAAAAA==
\n\n* Case: PSBT with one P2PKH input and one P2SH-P2WPKH input both with non-final scriptSigs. P2SH-P2WPKH input's redeemScript is available. Outputs filled.\n** Bytes in Hex: 
70736274ff0100a00200000002ab0949a08c5af7c49b8212f417e2f15ab3f5c33dcf153821a8139f877a5b7be40000000000feffffffab0949a08c5af7c49b8212f417e2f15ab3f5c33dcf153821a8139f877a5b7be40100000000feffffff02603bea0b000000001976a914768a40bbd740cbe81d988e71de2a4d5c71396b1d88ac8e240000000000001976a9146f4620b553fa095e721b9ee0efe9fa039cca459788ac00000000000100df0200000001268171371edff285e937adeea4b37b78000c0566cbb3ad64641713ca42171bf6000000006a473044022070b2245123e6bf474d60c5b50c043d4c691a5d2435f09a34a7662a9dc251790a022001329ca9dacf280bdf30740ec0390422422c81cb45839457aeb76fc12edd95b3012102657d118d3357b8e0f4c2cd46db7b39f6d9c38d9a70abcb9b2de5dc8dbfe4ce31feffffff02d3dff505000000001976a914d0c59903c5bac2868760e90fd521a4665aa7652088ac00e1f5050000000017a9143545e6e33b832c47050f24d3eeb93c9c03948bc787b32e13000001012000e1f5050000000017a9143545e6e33b832c47050f24d3eeb93c9c03948bc787010416001485d13537f2e265405a34dbafa9e3dda01fb8230800220202ead596687ca806043edc3de116cdf29d5e9257c196cd055cf698c8d02bf24e9910b4a6ba670000008000000080020000800022020394f62be9df19952c5587768aeb7698061ad2c4a25c894f47d8c162b4d7213d0510b4a6ba6700000080010000800200008000
\n** Base64 String: 
cHNidP8BAKACAAAAAqsJSaCMWvfEm4IS9Bfi8Vqz9cM9zxU4IagTn4d6W3vkAAAAAAD+////qwlJoIxa98SbghL0F+LxWrP1wz3PFTghqBOfh3pbe+QBAAAAAP7///8CYDvqCwAAAAAZdqkUdopAu9dAy+gdmI5x3ipNXHE5ax2IrI4kAAAAAAAAGXapFG9GILVT+glechue4O/p+gOcykWXiKwAAAAAAAEA3wIAAAABJoFxNx7f8oXpN63upLN7eAAMBWbLs61kZBcTykIXG/YAAAAAakcwRAIgcLIkUSPmv0dNYMW1DAQ9TGkaXSQ18Jo0p2YqncJReQoCIAEynKnazygL3zB0DsA5BCJCLIHLRYOUV663b8Eu3ZWzASECZX0RjTNXuOD0ws1G23s59tnDjZpwq8ubLeXcjb/kzjH+////AtPf9QUAAAAAGXapFNDFmQPFusKGh2DpD9UhpGZap2UgiKwA4fUFAAAAABepFDVF5uM7gyxHBQ8k0+65PJwDlIvHh7MuEwAAAQEgAOH1BQAAAAAXqRQ1RebjO4MsRwUPJNPuuTycA5SLx4cBBBYAFIXRNTfy4mVAWjTbr6nj3aAfuCMIACICAurVlmh8qAYEPtw94RbN8p1eklfBls0FXPaYyNAr8k6ZELSmumcAAACAAAAAgAIAAIAAIgIDlPYr6d8ZlSxVh3aK63aYBhrSxKJciU9H2MFitNchPQUQtKa6ZwAAAIABAACAAgAAgAA=
\n\n* Case: PSBT with one P2SH-P2WSH input of a 2-of-2 multisig, redeemScript, witnessScript, and keypaths are available. Contains one signature.\n** Bytes in Hex: 
70736274ff0100550200000001279a2323a5dfb51fc45f220fa58b0fc13e1e3342792a85d7e36cd6333b5cbc390000000000ffffffff01a05aea0b000000001976a914ffe9c0061097cc3b636f2cb0460fa4fc427d2b4588ac0000000000010120955eea0b0000000017a9146345200f68d189e1adc0df1c4d16ea8f14c0dbeb87220203b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4646304302200424b58effaaa694e1559ea5c93bbfd4a89064224055cdf070b6771469442d07021f5c8eb0fea6516d60b8acb33ad64ede60e8785bfb3aa94b99bdf86151db9a9a010104220020771fd18ad459666dd49f3d564e3dbc42f4c84774e360ada16816a8ed488d5681010547522103b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd462103de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd52ae220603b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4610b4a6ba67000000800000008004000080220603de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd10b4a6ba670000008000000080050000800000
\n** Base64 String: 
cHNidP8BAFUCAAAAASeaIyOl37UfxF8iD6WLD8E+HjNCeSqF1+Ns1jM7XLw5AAAAAAD/////AaBa6gsAAAAAGXapFP/pwAYQl8w7Y28ssEYPpPxCfStFiKwAAAAAAAEBIJVe6gsAAAAAF6kUY0UgD2jRieGtwN8cTRbqjxTA2+uHIgIDsTQcy6doO2r08SOM1ul+cWfVafrEfx5I1HVBhENVvUZGMEMCIAQktY7/qqaU4VWepck7v9SokGQiQFXN8HC2dxRpRC0HAh9cjrD+plFtYLisszrWTt5g6Hhb+zqpS5m9+GFR25qaAQEEIgAgdx/RitRZZm3Unz1WTj28QvTIR3TjYK2haBao7UiNVoEBBUdSIQOxNBzLp2g7avTxI4zW6X5xZ9Vp+sR/HkjUdUGEQ1W9RiED3lXR4drIBeP4pYwfv5uUwC89uq/hJ/78pJlfJvggg71SriIGA7E0HMunaDtq9PEjjNbpfnFn1Wn6xH8eSNR1QYRDVb1GELSmumcAAACAAAAAgAQAAIAiBgPeVdHh2sgF4/iljB+/m5TALz26r+En/vykmV8m+CCDvRC0prpnAAAAgAAAAIAFAACAAAA=
\n\n* Case: PSBT with one P2WSH input of a 2-of-2 multisig. witnessScript, keypaths, and global xpubs are available. Contains no signatures. Outputs filled.\n** Bytes in Hex: 
70736274ff01005202000000019dfc6628c26c5899fe1bd3dc338665bfd55d7ada10f6220973df2d386dec12760100000000ffffffff01f03dcd1d000000001600147b3a00bfdc14d27795c2b74901d09da6ef133579000000004f01043587cf02da3fd0088000000097048b1ad0445b1ec8275517727c87b4e4ebc18a203ffa0f94c01566bd38e9000351b743887ee1d40dc32a6043724f2d6459b3b5a4d73daec8fbae0472f3bc43e20cd90c6a4fae000080000000804f01043587cf02da3fd00880000001b90452427139cd78c2cff2444be353cd58605e3e513285e528b407fae3f6173503d30a5e97c8adbc557dac2ad9a7e39c1722ebac69e668b6f2667cc1d671c83cab0cd90c6a4fae000080010000800001012b0065cd1d000000002200202c5486126c4978079a814e13715d65f36459e4d6ccaded266d0508645bafa6320105475221029da12cdb5b235692b91536afefe5c91c3ab9473d8e43b533836ab456299c88712103372b34234ed7cf9c1fea5d05d441557927be9542b162eb02e1ab2ce80224c00b52ae2206029da12cdb5b235692b91536afefe5c91c3ab9473d8e43b533836ab456299c887110d90c6a4fae0000800000008000000000220603372b34234ed7cf9c1fea5d05d441557927be9542b162eb02e1ab2ce80224c00b10d90c6a4fae0000800100008000000000002202039eff1f547a1d5f92dfa2ba7af6ac971a4bd03ba4a734b03156a256b8ad3a1ef910ede45cc500000080000000800100008000
\n** Base64 String: 
cHNidP8BAFICAAAAAZ38ZijCbFiZ/hvT3DOGZb/VXXraEPYiCXPfLTht7BJ2AQAAAAD/////AfA9zR0AAAAAFgAUezoAv9wU0neVwrdJAdCdpu8TNXkAAAAATwEENYfPAto/0AiAAAAAlwSLGtBEWx7IJ1UXcnyHtOTrwYogP/oPlMAVZr046QADUbdDiH7h1A3DKmBDck8tZFmztaTXPa7I+64EcvO8Q+IM2QxqT64AAIAAAACATwEENYfPAto/0AiAAAABuQRSQnE5zXjCz/JES+NTzVhgXj5RMoXlKLQH+uP2FzUD0wpel8itvFV9rCrZp+OcFyLrrGnmaLbyZnzB1nHIPKsM2QxqT64AAIABAACAAAEBKwBlzR0AAAAAIgAgLFSGEmxJeAeagU4TcV1l82RZ5NbMre0mbQUIZFuvpjIBBUdSIQKdoSzbWyNWkrkVNq/v5ckcOrlHPY5DtTODarRWKZyIcSEDNys0I07Xz5wf6l0F1EFVeSe+lUKxYusC4ass6AIkwAtSriIGAp2hLNtbI1aSuRU2r+/lyRw6uUc9jkO1M4NqtFYpnIhxENkMak+uAACAAAAAgAAAAAAiBgM3KzQjTtfPnB/qXQXUQVV5J76VQrFi6wLhqyzoAiTACxDZDGpPrgAAgAEAAIAAAAAAACICA57/H1R6HV+S36K6evaslxpL0DukpzSwMVaiVritOh75EO3kXMUAAACAAAAAgAEAAIAA
\n\n* Case: PSBT with unknown types in the inputs.\n** Bytes in Hex: 
70736274ff01003f0200000001ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff0000000000ffffffff010000000000000000036a010000000000000af00102030405060708090f0102030405060708090a0b0c0d0e0f0000
\n** Base64 String: 
cHNidP8BAD8CAAAAAf//////////////////////////////////////////AAAAAAD/////AQAAAAAAAAAAA2oBAAAAAAAACvABAgMEBQYHCAkPAQIDBAUGBwgJCgsMDQ4PAAA=
\n\n* Case: PSBT with `PSBT_GLOBAL_XPUB`.\n** Bytes in Hex: 
70736274ff01009d0100000002710ea76ab45c5cb6438e607e59cc037626981805ae9e0dfd9089012abb0be5350100000000ffffffff190994d6a8b3c8c82ccbcfb2fba4106aa06639b872a8d447465c0d42588d6d670000000000ffffffff0200e1f505000000001976a914b6bc2c0ee5655a843d79afedd0ccc3f7dd64340988ac605af405000000001600141188ef8e4ce0449eaac8fb141cbf5a1176e6a088000000004f010488b21e039e530cac800000003dbc8a5c9769f031b17e77fea1518603221a18fd18f2b9a54c6c8c1ac75cbc3502f230584b155d1c7f1cd45120a653c48d650b431b67c5b2c13f27d7142037c1691027569c503100008000000080000000800001011f00e1f5050000000016001433b982f91b28f160c920b4ab95e58ce50dda3a4a220203309680f33c7de38ea6a47cd4ecd66f1f5a49747c6ffb8808ed09039243e3ad5c47304402202d704ced830c56a909344bd742b6852dccd103e963bae92d38e75254d2bb424502202d86c437195df46c0ceda084f2a291c3da2d64070f76bf9b90b195e7ef28f77201220603309680f33c7de38ea6a47cd4ecd66f1f5a49747c6ffb8808ed09039243e3ad5c1827569c5031000080000000800000008000000000010000000001011f00e1f50500000000160014388fb944307eb77ef45197d0b0b245e079f011de220202c777161f73d0b7c72b9ee7bde650293d13f095bc7656ad1f525da5fd2e10b11047304402204cb1fb5f869c942e0e26100576125439179ae88dca8a9dc3ba08f7953988faa60220521f49ca791c27d70e273c9b14616985909361e25be274ea200d7e08827e514d01220602c777161f73d0b7c72b9ee7bde650293d13f095bc7656ad1f525da5fd2e10b1101827569c5031000080000000800000008000000000000000000000220202d20ca502ee289686d21815bd43a80637b0698e1fbcdbe4caed445f6c1a0a90ef1827569c50310000800000008000000080000000000400000000
\n** Base64 String: 
cHNidP8BAJ0BAAAAAnEOp2q0XFy2Q45gflnMA3YmmBgFrp4N/ZCJASq7C+U1AQAAAAD/////GQmU1qizyMgsy8+y+6QQaqBmObhyqNRHRlwNQliNbWcAAAAAAP////8CAOH1BQAAAAAZdqkUtrwsDuVlWoQ9ea/t0MzD991kNAmIrGBa9AUAAAAAFgAUEYjvjkzgRJ6qyPsUHL9aEXbmoIgAAAAATwEEiLIeA55TDKyAAAAAPbyKXJdp8DGxfnf+oVGGAyIaGP0Y8rmlTGyMGsdcvDUC8jBYSxVdHH8c1FEgplPEjWULQxtnxbLBPyfXFCA3wWkQJ1acUDEAAIAAAACAAAAAgAABAR8A4fUFAAAAABYAFDO5gvkbKPFgySC0q5XljOUN2jpKIgIDMJaA8zx9446mpHzU7NZvH1pJdHxv+4gI7QkDkkPjrVxHMEQCIC1wTO2DDFapCTRL10K2hS3M0QPpY7rpLTjnUlTSu0JFAiAthsQ3GV30bAztoITyopHD2i1kBw92v5uQsZXn7yj3cgEiBgMwloDzPH3jjqakfNTs1m8fWkl0fG/7iAjtCQOSQ+OtXBgnVpxQMQAAgAAAAIAAAACAAAAAAAEAAAAAAQEfAOH1BQAAAAAWABQ4j7lEMH63fvRRl9CwskXgefAR3iICAsd3Fh9z0LfHK57nveZQKT0T8JW8dlatH1Jdpf0uELEQRzBEAiBMsftfhpyULg4mEAV2ElQ5F5rojcqKncO6CPeVOYj6pgIgUh9JynkcJ9cOJzybFGFphZCTYeJb4nTqIA1+CIJ+UU0BIgYCx3cWH3PQt8crnue95lApPRPwlbx2Vq0fUl2l/S4QsRAYJ1acUDEAAIAAAACAAAAAgAAAAAAAAAAAAAAiAgLSDKUC7iiWhtIYFb1DqAY3sGmOH7zb5MrtRF9sGgqQ7xgnVpxQMQAAgAAAAIAAAACAAAAAAAQAAAAA
\n\n* Case: PSBT with global unsigned tx that has 0 inputs and 0 outputs\n** Bytes in Hex: 
70736274ff01000a0000000000000000000000
\n** Base64 String: 
cHNidP8BAAoAAAAAAAAAAAAAAA==
\n\n* Case: PSBT with 0 inputs\n** Bytes in Hex: 
70736274ff01004c020000000002d3dff505000000001976a914d0c59903c5bac2868760e90fd521a4665aa7652088ac00e1f5050000000017a9143545e6e33b832c47050f24d3eeb93c9c03948bc787b32e1300000000
\n** Base64 String: 
cHNidP8BAEwCAAAAAALT3/UFAAAAABl2qRTQxZkDxbrChodg6Q/VIaRmWqdlIIisAOH1BQAAAAAXqRQ1RebjO4MsRwUPJNPuuTycA5SLx4ezLhMAAAAA
\n\nFails Signer checks\n\n* Case: A Witness UTXO is provided for a non-witness input\n** Bytes in Hex: 
70736274ff0100a00200000002ab0949a08c5af7c49b8212f417e2f15ab3f5c33dcf153821a8139f877a5b7be40000000000feffffffab0949a08c5af7c49b8212f417e2f15ab3f5c33dcf153821a8139f877a5b7be40100000000feffffff02603bea0b000000001976a914768a40bbd740cbe81d988e71de2a4d5c71396b1d88ac8e240000000000001976a9146f4620b553fa095e721b9ee0efe9fa039cca459788ac0000000000010122d3dff505000000001976a914d48ed3110b94014cb114bd32d6f4d066dc74256b88ac0001012000e1f5050000000017a9143545e6e33b832c47050f24d3eeb93c9c03948bc787010416001485d13537f2e265405a34dbafa9e3dda01fb8230800220202ead596687ca806043edc3de116cdf29d5e9257c196cd055cf698c8d02bf24e9910b4a6ba670000008000000080020000800022020394f62be9df19952c5587768aeb7698061ad2c4a25c894f47d8c162b4d7213d0510b4a6ba6700000080010000800200008000
\n** Base64 String: 
cHNidP8BAKACAAAAAqsJSaCMWvfEm4IS9Bfi8Vqz9cM9zxU4IagTn4d6W3vkAAAAAAD+////qwlJoIxa98SbghL0F+LxWrP1wz3PFTghqBOfh3pbe+QBAAAAAP7///8CYDvqCwAAAAAZdqkUdopAu9dAy+gdmI5x3ipNXHE5ax2IrI4kAAAAAAAAGXapFG9GILVT+glechue4O/p+gOcykWXiKwAAAAAAAEBItPf9QUAAAAAGXapFNSO0xELlAFMsRS9Mtb00GbcdCVriKwAAQEgAOH1BQAAAAAXqRQ1RebjO4MsRwUPJNPuuTycA5SLx4cBBBYAFIXRNTfy4mVAWjTbr6nj3aAfuCMIACICAurVlmh8qAYEPtw94RbN8p1eklfBls0FXPaYyNAr8k6ZELSmumcAAACAAAAAgAIAAIAAIgIDlPYr6d8ZlSxVh3aK63aYBhrSxKJciU9H2MFitNchPQUQtKa6ZwAAAIABAACAAgAAgAA=
\n\n* Case: redeemScript with non-witness UTXO does not match the scriptPubKey\n** Bytes in Hex: 
70736274ff01009a020000000258e87a21b56daf0c23be8e7070456c336f7cbaa5c8757924f545887bb2abdd750000000000ffffffff838d0427d0ec650a68aa46bb0b098aea4422c071b2ca78352a077959d07cea1d0100000000ffffffff0270aaf00800000000160014d85c2b71d0060b09c9886aeb815e50991dda124d00e1f5050000000016001400aea9a2e5f0f876a588df5546e8742d1d87008f00000000000100bb0200000001aad73931018bd25f84ae400b68848be09db706eac2ac18298babee71ab656f8b0000000048473044022058f6fc7c6a33e1b31548d481c826c015bd30135aad42cd67790dab66d2ad243b02204a1ced2604c6735b6393e5b41691dd78b00f0c5942fb9f751856faa938157dba01feffffff0280f0fa020000000017a9140fb9463421696b82c833af241c78c17ddbde493487d0f20a270100000017a91429ca74f8a08f81999428185c97b5d852e4063f618765000000220202dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d7483045022100f61038b308dc1da865a34852746f015772934208c6d24454393cd99bdf2217770220056e675a675a6d0a02b85b14e5e29074d8a25a9b5760bea2816f661910a006ea01010304010000000104475221029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f2102dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d752af2206029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f10d90c6a4f000000800000008000000080220602dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d710d90c6a4f0000008000000080010000800001012000c2eb0b0000000017a914b7f5faf40e3d40a5a459b1db3535f2b72fa921e8872202023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e73473044022065f45ba5998b59a27ffe1a7bed016af1f1f90d54b3aa8f7450aa5f56a25103bd02207f724703ad1edb96680b284b56d4ffcb88f7fb759eabbe08aa30f29b851383d2010103040100000001042200208c2353173743b595dfb4a07b72ba8e42e3797da74e87fe7d9d7497e3b2028903010547522103089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc21023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7352ae2206023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7310d90c6a4f000000800000008003000080220603089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc10d90c6a4f00000080000000800200008000220203a9a4c37f5996d3aa25dbac6b570af0650394492942460b354753ed9eeca5877110d90c6a4f000000800000008004000080002202027f6399757d2eff55a136ad02c684b1838b6556e5f1b6b34282a94b6b5005109610d90c6a4f00000080000000800500008000
\n** Base64 String: 
cHNidP8BAJoCAAAAAljoeiG1ba8MI76OcHBFbDNvfLqlyHV5JPVFiHuyq911AAAAAAD/////g40EJ9DsZQpoqka7CwmK6kQiwHGyyng1Kgd5WdB86h0BAAAAAP////8CcKrwCAAAAAAWABTYXCtx0AYLCcmIauuBXlCZHdoSTQDh9QUAAAAAFgAUAK6pouXw+HaliN9VRuh0LR2HAI8AAAAAAAEAuwIAAAABqtc5MQGL0l+ErkALaISL4J23BurCrBgpi6vucatlb4sAAAAASEcwRAIgWPb8fGoz4bMVSNSByCbAFb0wE1qtQs1neQ2rZtKtJDsCIEoc7SYExnNbY5PltBaR3XiwDwxZQvufdRhW+qk4FX26Af7///8CgPD6AgAAAAAXqRQPuUY0IWlrgsgzryQceMF9295JNIfQ8gonAQAAABepFCnKdPigj4GZlCgYXJe12FLkBj9hh2UAAAAiAgLath/0mhTban0CsM0fu3j8SxgxK1tOVNrk26L7/vU210gwRQIhAPYQOLMI3B2oZaNIUnRvAVdyk0IIxtJEVDk82ZvfIhd3AiAFbmdaZ1ptCgK4WxTl4pB02KJam1dgvqKBb2YZEKAG6gEBAwQBAAAAAQRHUiEClYO/Oa4KYJdHrRma3dY0+mEIVZ1sXNObTCGD8auW4H8hAtq2H/SaFNtqfQKwzR+7ePxLGDErW05U2uTbovv+9TbXUq8iBgKVg785rgpgl0etGZrd1jT6YQhVnWxc05tMIYPxq5bgfxDZDGpPAAAAgAAAAIAAAACAIgYC2rYf9JoU22p9ArDNH7t4/EsYMStbTlTa5Nui+/71NtcQ2QxqTwAAAIAAAACAAQAAgAABASAAwusLAAAAABepFLf1+vQOPUClpFmx2zU18rcvqSHohyICAjrdkE89bc9Z3bkGsN7iNSm3/7ntUOXoYVGSaGAiHw5zRzBEAiBl9FulmYtZon/+GnvtAWrx8fkNVLOqj3RQql9WolEDvQIgf3JHA60e25ZoCyhLVtT/y4j3+3Weq74IqjDym4UTg9IBAQMEAQAAAAEEIgAgjCNTFzdDtZXftKB7crqOQuN5fadOh/59nXSX47ICiQMBBUdSIQMIncEMesbbVPkTKa9hczPbOIzq0MIx9yM3nRuZAwsC3CECOt2QTz1tz1nduQaw3uI1Kbf/ue1Q5ehhUZJoYCIfDnNSriIGAjrdkE89bc9Z3bkGsN7iNSm3/7ntUOXoYVGSaGAiHw5zENkMak8AAACAAAAAgAMAAIAiBgMIncEMesbbVPkTKa9hczPbOIzq0MIx9yM3nRuZAwsC3BDZDGpPAAAAgAAAAIACAACAACICA6mkw39ZltOqJdusa1cK8GUDlEkpQkYLNUdT7Z7spYdxENkMak8AAACAAAAAgAQAAIAAIgICf2OZdX0u/1WhNq0CxoSxg4tlVuXxtrNCgqlLa1AFEJYQ2QxqTwAAAIAAAACABQAAgAA=
\n\n* Case: redeemScript with witness UTXO does not match the scriptPubKey\n** Bytes in Hex: 
70736274ff01009a020000000258e87a21b56daf0c23be8e7070456c336f7cbaa5c8757924f545887bb2abdd750000000000ffffffff838d0427d0ec650a68aa46bb0b098aea4422c071b2ca78352a077959d07cea1d0100000000ffffffff0270aaf00800000000160014d85c2b71d0060b09c9886aeb815e50991dda124d00e1f5050000000016001400aea9a2e5f0f876a588df5546e8742d1d87008f00000000000100bb0200000001aad73931018bd25f84ae400b68848be09db706eac2ac18298babee71ab656f8b0000000048473044022058f6fc7c6a33e1b31548d481c826c015bd30135aad42cd67790dab66d2ad243b02204a1ced2604c6735b6393e5b41691dd78b00f0c5942fb9f751856faa938157dba01feffffff0280f0fa020000000017a9140fb9463421696b82c833af241c78c17ddbde493487d0f20a270100000017a91429ca74f8a08f81999428185c97b5d852e4063f618765000000220202dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d7483045022100f61038b308dc1da865a34852746f015772934208c6d24454393cd99bdf2217770220056e675a675a6d0a02b85b14e5e29074d8a25a9b5760bea2816f661910a006ea01010304010000000104475221029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f2102dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d752ae2206029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f10d90c6a4f000000800000008000000080220602dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d710d90c6a4f0000008000000080010000800001012000c2eb0b0000000017a914b7f5faf40e3d40a5a459b1db3535f2b72fa921e8872202023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e73473044022065f45ba5998b59a27ffe1a7bed016af1f1f90d54b3aa8f7450aa5f56a25103bd02207f724703ad1edb96680b284b56d4ffcb88f7fb759eabbe08aa30f29b851383d2010103040100000001042200208c2353173743b595dfb4a07b72ba8e42e3797da74e87fe7d9d7497e3b2028900010547522103089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc21023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7352ae2206023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7310d90c6a4f000000800000008003000080220603089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc10d90c6a4f00000080000000800200008000220203a9a4c37f5996d3aa25dbac6b570af0650394492942460b354753ed9eeca5877110d90c6a4f000000800000008004000080002202027f6399757d2eff55a136ad02c684b1838b6556e5f1b6b34282a94b6b5005109610d90c6a4f00000080000000800500008000
\n** Base64 String: 
cHNidP8BAJoCAAAAAljoeiG1ba8MI76OcHBFbDNvfLqlyHV5JPVFiHuyq911AAAAAAD/////g40EJ9DsZQpoqka7CwmK6kQiwHGyyng1Kgd5WdB86h0BAAAAAP////8CcKrwCAAAAAAWABTYXCtx0AYLCcmIauuBXlCZHdoSTQDh9QUAAAAAFgAUAK6pouXw+HaliN9VRuh0LR2HAI8AAAAAAAEAuwIAAAABqtc5MQGL0l+ErkALaISL4J23BurCrBgpi6vucatlb4sAAAAASEcwRAIgWPb8fGoz4bMVSNSByCbAFb0wE1qtQs1neQ2rZtKtJDsCIEoc7SYExnNbY5PltBaR3XiwDwxZQvufdRhW+qk4FX26Af7///8CgPD6AgAAAAAXqRQPuUY0IWlrgsgzryQceMF9295JNIfQ8gonAQAAABepFCnKdPigj4GZlCgYXJe12FLkBj9hh2UAAAAiAgLath/0mhTban0CsM0fu3j8SxgxK1tOVNrk26L7/vU210gwRQIhAPYQOLMI3B2oZaNIUnRvAVdyk0IIxtJEVDk82ZvfIhd3AiAFbmdaZ1ptCgK4WxTl4pB02KJam1dgvqKBb2YZEKAG6gEBAwQBAAAAAQRHUiEClYO/Oa4KYJdHrRma3dY0+mEIVZ1sXNObTCGD8auW4H8hAtq2H/SaFNtqfQKwzR+7ePxLGDErW05U2uTbovv+9TbXUq4iBgKVg785rgpgl0etGZrd1jT6YQhVnWxc05tMIYPxq5bgfxDZDGpPAAAAgAAAAIAAAACAIgYC2rYf9JoU22p9ArDNH7t4/EsYMStbTlTa5Nui+/71NtcQ2QxqTwAAAIAAAACAAQAAgAABASAAwusLAAAAABepFLf1+vQOPUClpFmx2zU18rcvqSHohyICAjrdkE89bc9Z3bkGsN7iNSm3/7ntUOXoYVGSaGAiHw5zRzBEAiBl9FulmYtZon/+GnvtAWrx8fkNVLOqj3RQql9WolEDvQIgf3JHA60e25ZoCyhLVtT/y4j3+3Weq74IqjDym4UTg9IBAQMEAQAAAAEEIgAgjCNTFzdDtZXftKB7crqOQuN5fadOh/59nXSX47ICiQABBUdSIQMIncEMesbbVPkTKa9hczPbOIzq0MIx9yM3nRuZAwsC3CECOt2QTz1tz1nduQaw3uI1Kbf/ue1Q5ehhUZJoYCIfDnNSriIGAjrdkE89bc9Z3bkGsN7iNSm3/7ntUOXoYVGSaGAiHw5zENkMak8AAACAAAAAgAMAAIAiBgMIncEMesbbVPkTKa9hczPbOIzq0MIx9yM3nRuZAwsC3BDZDGpPAAAAgAAAAIACAACAACICA6mkw39ZltOqJdusa1cK8GUDlEkpQkYLNUdT7Z7spYdxENkMak8AAACAAAAAgAQAAIAAIgICf2OZdX0u/1WhNq0CxoSxg4tlVuXxtrNCgqlLa1AFEJYQ2QxqTwAAAIAAAACABQAAgAA=
\n\n* Case: witnessScript with witness UTXO does not match the redeemScript\n** Bytes in Hex: 
70736274ff01009a020000000258e87a21b56daf0c23be8e7070456c336f7cbaa5c8757924f545887bb2abdd750000000000ffffffff838d0427d0ec650a68aa46bb0b098aea4422c071b2ca78352a077959d07cea1d0100000000ffffffff0270aaf00800000000160014d85c2b71d0060b09c9886aeb815e50991dda124d00e1f5050000000016001400aea9a2e5f0f876a588df5546e8742d1d87008f00000000000100bb0200000001aad73931018bd25f84ae400b68848be09db706eac2ac18298babee71ab656f8b0000000048473044022058f6fc7c6a33e1b31548d481c826c015bd30135aad42cd67790dab66d2ad243b02204a1ced2604c6735b6393e5b41691dd78b00f0c5942fb9f751856faa938157dba01feffffff0280f0fa020000000017a9140fb9463421696b82c833af241c78c17ddbde493487d0f20a270100000017a91429ca74f8a08f81999428185c97b5d852e4063f618765000000220202dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d7483045022100f61038b308dc1da865a34852746f015772934208c6d24454393cd99bdf2217770220056e675a675a6d0a02b85b14e5e29074d8a25a9b5760bea2816f661910a006ea01010304010000000104475221029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f2102dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d752ae2206029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f10d90c6a4f000000800000008000000080220602dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d710d90c6a4f0000008000000080010000800001012000c2eb0b0000000017a914b7f5faf40e3d40a5a459b1db3535f2b72fa921e8872202023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e73473044022065f45ba5998b59a27ffe1a7bed016af1f1f90d54b3aa8f7450aa5f56a25103bd02207f724703ad1edb96680b284b56d4ffcb88f7fb759eabbe08aa30f29b851383d2010103040100000001042200208c2353173743b595dfb4a07b72ba8e42e3797da74e87fe7d9d7497e3b2028903010547522103089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc21023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7352ad2206023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7310d90c6a4f000000800000008003000080220603089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc10d90c6a4f00000080000000800200008000220203a9a4c37f5996d3aa25dbac6b570af0650394492942460b354753ed9eeca5877110d90c6a4f000000800000008004000080002202027f6399757d2eff55a136ad02c684b1838b6556e5f1b6b34282a94b6b5005109610d90c6a4f00000080000000800500008000
\n** Base64 String: 
cHNidP8BAJoCAAAAAljoeiG1ba8MI76OcHBFbDNvfLqlyHV5JPVFiHuyq911AAAAAAD/////g40EJ9DsZQpoqka7CwmK6kQiwHGyyng1Kgd5WdB86h0BAAAAAP////8CcKrwCAAAAAAWABTYXCtx0AYLCcmIauuBXlCZHdoSTQDh9QUAAAAAFgAUAK6pouXw+HaliN9VRuh0LR2HAI8AAAAAAAEAuwIAAAABqtc5MQGL0l+ErkALaISL4J23BurCrBgpi6vucatlb4sAAAAASEcwRAIgWPb8fGoz4bMVSNSByCbAFb0wE1qtQs1neQ2rZtKtJDsCIEoc7SYExnNbY5PltBaR3XiwDwxZQvufdRhW+qk4FX26Af7///8CgPD6AgAAAAAXqRQPuUY0IWlrgsgzryQceMF9295JNIfQ8gonAQAAABepFCnKdPigj4GZlCgYXJe12FLkBj9hh2UAAAAiAgLath/0mhTban0CsM0fu3j8SxgxK1tOVNrk26L7/vU210gwRQIhAPYQOLMI3B2oZaNIUnRvAVdyk0IIxtJEVDk82ZvfIhd3AiAFbmdaZ1ptCgK4WxTl4pB02KJam1dgvqKBb2YZEKAG6gEBAwQBAAAAAQRHUiEClYO/Oa4KYJdHrRma3dY0+mEIVZ1sXNObTCGD8auW4H8hAtq2H/SaFNtqfQKwzR+7ePxLGDErW05U2uTbovv+9TbXUq4iBgKVg785rgpgl0etGZrd1jT6YQhVnWxc05tMIYPxq5bgfxDZDGpPAAAAgAAAAIAAAACAIgYC2rYf9JoU22p9ArDNH7t4/EsYMStbTlTa5Nui+/71NtcQ2QxqTwAAAIAAAACAAQAAgAABASAAwusLAAAAABepFLf1+vQOPUClpFmx2zU18rcvqSHohyICAjrdkE89bc9Z3bkGsN7iNSm3/7ntUOXoYVGSaGAiHw5zRzBEAiBl9FulmYtZon/+GnvtAWrx8fkNVLOqj3RQql9WolEDvQIgf3JHA60e25ZoCyhLVtT/y4j3+3Weq74IqjDym4UTg9IBAQMEAQAAAAEEIgAgjCNTFzdDtZXftKB7crqOQuN5fadOh/59nXSX47ICiQMBBUdSIQMIncEMesbbVPkTKa9hczPbOIzq0MIx9yM3nRuZAwsC3CECOt2QTz1tz1nduQaw3uI1Kbf/ue1Q5ehhUZJoYCIfDnNSrSIGAjrdkE89bc9Z3bkGsN7iNSm3/7ntUOXoYVGSaGAiHw5zENkMak8AAACAAAAAgAMAAIAiBgMIncEMesbbVPkTKa9hczPbOIzq0MIx9yM3nRuZAwsC3BDZDGpPAAAAgAAAAIACAACAACICA6mkw39ZltOqJdusa1cK8GUDlEkpQkYLNUdT7Z7spYdxENkMak8AAACAAAAAgAQAAIAAIgICf2OZdX0u/1WhNq0CxoSxg4tlVuXxtrNCgqlLa1AFEJYQ2QxqTwAAAIAAAACABQAAgAA=
\n\nThe private keys in the tests below are derived from the following master private key:\n\n* Extended Private Key: 
tprv8ZgxMBicQKsPd9TeAdPADNnSyH9SSUUbTVeFszDE23Ki6TBB5nCefAdHkK8Fm3qMQR6sHwA56zqRmKmxnHk37JkiFzvncDqoKmPWubu7hDF
\n** Seed: 
cUkG8i1RFfWGWy5ziR11zJ5V4U4W3viSFCfyJmZnvQaUsd1xuF3T
\n\nA creator creating a PSBT for a transaction which creates the following outputs:\n\n* scriptPubKey: 0014d85c2b71d0060b09c9886aeb815e50991dda124d, Amount: 1.49990000\n* scriptPubKey: 001400aea9a2e5f0f876a588df5546e8742d1d87008f, Amount: 1.00000000\n\nand spends the following inputs:\n\n* TXID: 75ddabb27b8845f5247975c8a5ba7c6f336c4570708ebe230caf6db5217ae858, Index: 0\n* TXID: 1dea7cd05979072a3578cab271c02244ea8a090bbb46aa680a65ecd027048d83, Index: 1\n\nmust create this PSBT:\n* Bytes in Hex: 
70736274ff01009a020000000258e87a21b56daf0c23be8e7070456c336f7cbaa5c8757924f545887bb2abdd750000000000ffffffff838d0427d0ec650a68aa46bb0b098aea4422c071b2ca78352a077959d07cea1d0100000000ffffffff0270aaf00800000000160014d85c2b71d0060b09c9886aeb815e50991dda124d00e1f5050000000016001400aea9a2e5f0f876a588df5546e8742d1d87008f000000000000000000
\n* Base64 String: 
cHNidP8BAJoCAAAAAljoeiG1ba8MI76OcHBFbDNvfLqlyHV5JPVFiHuyq911AAAAAAD/////g40EJ9DsZQpoqka7CwmK6kQiwHGyyng1Kgd5WdB86h0BAAAAAP////8CcKrwCAAAAAAWABTYXCtx0AYLCcmIauuBXlCZHdoSTQDh9QUAAAAAFgAUAK6pouXw+HaliN9VRuh0LR2HAI8AAAAAAAAAAAA=
\n\nGiven the above PSBT, an updater with only the following:\n\n* Redeem Scripts:\n** 5221029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f2102dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d752ae\n** 00208c2353173743b595dfb4a07b72ba8e42e3797da74e87fe7d9d7497e3b2028903\n* Witness Scripts:\n** 522103089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc21023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7352ae\n* Previous Transactions:\n** 
0200000000010158e87a21b56daf0c23be8e7070456c336f7cbaa5c8757924f545887bb2abdd7501000000171600145f275f436b09a8cc9a2eb2a2f528485c68a56323feffffff02d8231f1b0100000017a914aed962d6654f9a2b36608eb9d64d2b260db4f1118700c2eb0b0000000017a914b7f5faf40e3d40a5a459b1db3535f2b72fa921e88702483045022100a22edcc6e5bc511af4cc4ae0de0fcd75c7e04d8c1c3a8aa9d820ed4b967384ec02200642963597b9b1bc22c75e9f3e117284a962188bf5e8a74c895089046a20ad770121035509a48eb623e10aace8bfd0212fdb8a8e5af3c94b0b133b95e114cab89e4f7965000000
\n** 
0200000001aad73931018bd25f84ae400b68848be09db706eac2ac18298babee71ab656f8b0000000048473044022058f6fc7c6a33e1b31548d481c826c015bd30135aad42cd67790dab66d2ad243b02204a1ced2604c6735b6393e5b41691dd78b00f0c5942fb9f751856faa938157dba01feffffff0280f0fa020000000017a9140fb9463421696b82c833af241c78c17ddbde493487d0f20a270100000017a91429ca74f8a08f81999428185c97b5d852e4063f618765000000
\n* Public Keys\n** Key: 029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f, Derivation Path: m/0'/0'/0'\n** Key: 02dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d7, Derivation Path: m/0'/0'/1'\n** Key: 03089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc, Derivation Path: m/0'/0'/2'\n** Key: 023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e73, Derivation Path: m/0'/0'/3'\n** Key: 03a9a4c37f5996d3aa25dbac6b570af0650394492942460b354753ed9eeca58771, Derivation Path: m/0'/0'/4'\n** Key: 027f6399757d2eff55a136ad02c684b1838b6556e5f1b6b34282a94b6b50051096, Derivation Path: m/0'/0'/5'\n\nMust create this PSBT:\n\n* Bytes in Hex: 
70736274ff01009a020000000258e87a21b56daf0c23be8e7070456c336f7cbaa5c8757924f545887bb2abdd750000000000ffffffff838d0427d0ec650a68aa46bb0b098aea4422c071b2ca78352a077959d07cea1d0100000000ffffffff0270aaf00800000000160014d85c2b71d0060b09c9886aeb815e50991dda124d00e1f5050000000016001400aea9a2e5f0f876a588df5546e8742d1d87008f00000000000100bb0200000001aad73931018bd25f84ae400b68848be09db706eac2ac18298babee71ab656f8b0000000048473044022058f6fc7c6a33e1b31548d481c826c015bd30135aad42cd67790dab66d2ad243b02204a1ced2604c6735b6393e5b41691dd78b00f0c5942fb9f751856faa938157dba01feffffff0280f0fa020000000017a9140fb9463421696b82c833af241c78c17ddbde493487d0f20a270100000017a91429ca74f8a08f81999428185c97b5d852e4063f6187650000000104475221029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f2102dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d752ae2206029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f10d90c6a4f000000800000008000000080220602dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d710d90c6a4f0000008000000080010000800001012000c2eb0b0000000017a914b7f5faf40e3d40a5a459b1db3535f2b72fa921e88701042200208c2353173743b595dfb4a07b72ba8e42e3797da74e87fe7d9d7497e3b2028903010547522103089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc21023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7352ae2206023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7310d90c6a4f000000800000008003000080220603089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc10d90c6a4f00000080000000800200008000220203a9a4c37f5996d3aa25dbac6b570af0650394492942460b354753ed9eeca5877110d90c6a4f000000800000008004000080002202027f6399757d2eff55a136ad02c684b1838b6556e5f1b6b34282a94b6b5005109610d90c6a4f00000080000000800500008000
\n* Base64 String: 
cHNidP8BAJoCAAAAAljoeiG1ba8MI76OcHBFbDNvfLqlyHV5JPVFiHuyq911AAAAAAD/////g40EJ9DsZQpoqka7CwmK6kQiwHGyyng1Kgd5WdB86h0BAAAAAP////8CcKrwCAAAAAAWABTYXCtx0AYLCcmIauuBXlCZHdoSTQDh9QUAAAAAFgAUAK6pouXw+HaliN9VRuh0LR2HAI8AAAAAAAEAuwIAAAABqtc5MQGL0l+ErkALaISL4J23BurCrBgpi6vucatlb4sAAAAASEcwRAIgWPb8fGoz4bMVSNSByCbAFb0wE1qtQs1neQ2rZtKtJDsCIEoc7SYExnNbY5PltBaR3XiwDwxZQvufdRhW+qk4FX26Af7///8CgPD6AgAAAAAXqRQPuUY0IWlrgsgzryQceMF9295JNIfQ8gonAQAAABepFCnKdPigj4GZlCgYXJe12FLkBj9hh2UAAAABBEdSIQKVg785rgpgl0etGZrd1jT6YQhVnWxc05tMIYPxq5bgfyEC2rYf9JoU22p9ArDNH7t4/EsYMStbTlTa5Nui+/71NtdSriIGApWDvzmuCmCXR60Zmt3WNPphCFWdbFzTm0whg/GrluB/ENkMak8AAACAAAAAgAAAAIAiBgLath/0mhTban0CsM0fu3j8SxgxK1tOVNrk26L7/vU21xDZDGpPAAAAgAAAAIABAACAAAEBIADC6wsAAAAAF6kUt/X69A49QKWkWbHbNTXyty+pIeiHAQQiACCMI1MXN0O1ld+0oHtyuo5C43l9p06H/n2ddJfjsgKJAwEFR1IhAwidwQx6xttU+RMpr2FzM9s4jOrQwjH3IzedG5kDCwLcIQI63ZBPPW3PWd25BrDe4jUpt/+57VDl6GFRkmhgIh8Oc1KuIgYCOt2QTz1tz1nduQaw3uI1Kbf/ue1Q5ehhUZJoYCIfDnMQ2QxqTwAAAIAAAACAAwAAgCIGAwidwQx6xttU+RMpr2FzM9s4jOrQwjH3IzedG5kDCwLcENkMak8AAACAAAAAgAIAAIAAIgIDqaTDf1mW06ol26xrVwrwZQOUSSlCRgs1R1Ptnuylh3EQ2QxqTwAAAIAAAACABAAAgAAiAgJ/Y5l1fS7/VaE2rQLGhLGDi2VW5fG2s0KCqUtrUAUQlhDZDGpPAAAAgAAAAIAFAACAAA==
\n\nAn updater which adds SIGHASH_ALL to the above PSBT must create this PSBT:\n\n* Bytes in Hex: 
70736274ff01009a020000000258e87a21b56daf0c23be8e7070456c336f7cbaa5c8757924f545887bb2abdd750000000000ffffffff838d0427d0ec650a68aa46bb0b098aea4422c071b2ca78352a077959d07cea1d0100000000ffffffff0270aaf00800000000160014d85c2b71d0060b09c9886aeb815e50991dda124d00e1f5050000000016001400aea9a2e5f0f876a588df5546e8742d1d87008f00000000000100bb0200000001aad73931018bd25f84ae400b68848be09db706eac2ac18298babee71ab656f8b0000000048473044022058f6fc7c6a33e1b31548d481c826c015bd30135aad42cd67790dab66d2ad243b02204a1ced2604c6735b6393e5b41691dd78b00f0c5942fb9f751856faa938157dba01feffffff0280f0fa020000000017a9140fb9463421696b82c833af241c78c17ddbde493487d0f20a270100000017a91429ca74f8a08f81999428185c97b5d852e4063f618765000000010304010000000104475221029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f2102dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d752ae2206029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f10d90c6a4f000000800000008000000080220602dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d710d90c6a4f0000008000000080010000800001012000c2eb0b0000000017a914b7f5faf40e3d40a5a459b1db3535f2b72fa921e8870103040100000001042200208c2353173743b595dfb4a07b72ba8e42e3797da74e87fe7d9d7497e3b2028903010547522103089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc21023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7352ae2206023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7310d90c6a4f000000800000008003000080220603089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc10d90c6a4f00000080000000800200008000220203a9a4c37f5996d3aa25dbac6b570af0650394492942460b354753ed9eeca5877110d90c6a4f000000800000008004000080002202027f6399757d2eff55a136ad02c684b1838b6556e5f1b6b34282a94b6b5005109610d90c6a4f00000080000000800500008000
\n* Base64 String: 
cHNidP8BAJoCAAAAAljoeiG1ba8MI76OcHBFbDNvfLqlyHV5JPVFiHuyq911AAAAAAD/////g40EJ9DsZQpoqka7CwmK6kQiwHGyyng1Kgd5WdB86h0BAAAAAP////8CcKrwCAAAAAAWABTYXCtx0AYLCcmIauuBXlCZHdoSTQDh9QUAAAAAFgAUAK6pouXw+HaliN9VRuh0LR2HAI8AAAAAAAEAuwIAAAABqtc5MQGL0l+ErkALaISL4J23BurCrBgpi6vucatlb4sAAAAASEcwRAIgWPb8fGoz4bMVSNSByCbAFb0wE1qtQs1neQ2rZtKtJDsCIEoc7SYExnNbY5PltBaR3XiwDwxZQvufdRhW+qk4FX26Af7///8CgPD6AgAAAAAXqRQPuUY0IWlrgsgzryQceMF9295JNIfQ8gonAQAAABepFCnKdPigj4GZlCgYXJe12FLkBj9hh2UAAAABAwQBAAAAAQRHUiEClYO/Oa4KYJdHrRma3dY0+mEIVZ1sXNObTCGD8auW4H8hAtq2H/SaFNtqfQKwzR+7ePxLGDErW05U2uTbovv+9TbXUq4iBgKVg785rgpgl0etGZrd1jT6YQhVnWxc05tMIYPxq5bgfxDZDGpPAAAAgAAAAIAAAACAIgYC2rYf9JoU22p9ArDNH7t4/EsYMStbTlTa5Nui+/71NtcQ2QxqTwAAAIAAAACAAQAAgAABASAAwusLAAAAABepFLf1+vQOPUClpFmx2zU18rcvqSHohwEDBAEAAAABBCIAIIwjUxc3Q7WV37Sge3K6jkLjeX2nTof+fZ10l+OyAokDAQVHUiEDCJ3BDHrG21T5EymvYXMz2ziM6tDCMfcjN50bmQMLAtwhAjrdkE89bc9Z3bkGsN7iNSm3/7ntUOXoYVGSaGAiHw5zUq4iBgI63ZBPPW3PWd25BrDe4jUpt/+57VDl6GFRkmhgIh8OcxDZDGpPAAAAgAAAAIADAACAIgYDCJ3BDHrG21T5EymvYXMz2ziM6tDCMfcjN50bmQMLAtwQ2QxqTwAAAIAAAACAAgAAgAAiAgOppMN/WZbTqiXbrGtXCvBlA5RJKUJGCzVHU+2e7KWHcRDZDGpPAAAAgAAAAIAEAACAACICAn9jmXV9Lv9VoTatAsaEsYOLZVbl8bazQoKpS2tQBRCWENkMak8AAACAAAAAgAUAAIAA
\n\nGiven the above updated PSBT, a signer that supports SIGHASH_ALL for P2PKH and P2WPKH spends and uses RFC6979 for nonce generation and has the following keys:\n* cP53pDbR5WtAD8dYAW9hhTjuvvTVaEiQBdrz9XPrgLBeRFiyCbQr (m/0'/0'/0')\n* cR6SXDoyfQrcp4piaiHE97Rsgta9mNhGTen9XeonVgwsh4iSgw6d (m/0'/0'/2')\nmust create this PSBT:\n\n* Bytes in Hex: 
70736274ff01009a020000000258e87a21b56daf0c23be8e7070456c336f7cbaa5c8757924f545887bb2abdd750000000000ffffffff838d0427d0ec650a68aa46bb0b098aea4422c071b2ca78352a077959d07cea1d0100000000ffffffff0270aaf00800000000160014d85c2b71d0060b09c9886aeb815e50991dda124d00e1f5050000000016001400aea9a2e5f0f876a588df5546e8742d1d87008f00000000000100bb0200000001aad73931018bd25f84ae400b68848be09db706eac2ac18298babee71ab656f8b0000000048473044022058f6fc7c6a33e1b31548d481c826c015bd30135aad42cd67790dab66d2ad243b02204a1ced2604c6735b6393e5b41691dd78b00f0c5942fb9f751856faa938157dba01feffffff0280f0fa020000000017a9140fb9463421696b82c833af241c78c17ddbde493487d0f20a270100000017a91429ca74f8a08f81999428185c97b5d852e4063f6187650000002202029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f473044022074018ad4180097b873323c0015720b3684cc8123891048e7dbcd9b55ad679c99022073d369b740e3eb53dcefa33823c8070514ca55a7dd9544f157c167913261118c01010304010000000104475221029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f2102dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d752ae2206029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f10d90c6a4f000000800000008000000080220602dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d710d90c6a4f0000008000000080010000800001012000c2eb0b0000000017a914b7f5faf40e3d40a5a459b1db3535f2b72fa921e887220203089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc473044022062eb7a556107a7c73f45ac4ab5a1dddf6f7075fb1275969a7f383efff784bcb202200c05dbb7470dbf2f08557dd356c7325c1ed30913e996cd3840945db12228da5f010103040100000001042200208c2353173743b595dfb4a07b72ba8e42e3797da74e87fe7d9d7497e3b2028903010547522103089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc21023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7352ae2206023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7310d90c6a4f000000800000008003000080220603089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc10d90c6a4f00000080000000800200008000220203a9a4c37f5996d3aa25dbac6b570af0650394492942460b354753ed9eeca5877110d90c6a4f000000800000008004000080002202027f6399757d2eff55a136ad02c684b1838b6556e5f1b6b34282a94b6b5005109610d90c6a4f00000080000000800500008000
\n* Base64 String: 
cHNidP8BAJoCAAAAAljoeiG1ba8MI76OcHBFbDNvfLqlyHV5JPVFiHuyq911AAAAAAD/////g40EJ9DsZQpoqka7CwmK6kQiwHGyyng1Kgd5WdB86h0BAAAAAP////8CcKrwCAAAAAAWABTYXCtx0AYLCcmIauuBXlCZHdoSTQDh9QUAAAAAFgAUAK6pouXw+HaliN9VRuh0LR2HAI8AAAAAAAEAuwIAAAABqtc5MQGL0l+ErkALaISL4J23BurCrBgpi6vucatlb4sAAAAASEcwRAIgWPb8fGoz4bMVSNSByCbAFb0wE1qtQs1neQ2rZtKtJDsCIEoc7SYExnNbY5PltBaR3XiwDwxZQvufdRhW+qk4FX26Af7///8CgPD6AgAAAAAXqRQPuUY0IWlrgsgzryQceMF9295JNIfQ8gonAQAAABepFCnKdPigj4GZlCgYXJe12FLkBj9hh2UAAAAiAgKVg785rgpgl0etGZrd1jT6YQhVnWxc05tMIYPxq5bgf0cwRAIgdAGK1BgAl7hzMjwAFXILNoTMgSOJEEjn282bVa1nnJkCIHPTabdA4+tT3O+jOCPIBwUUylWn3ZVE8VfBZ5EyYRGMAQEDBAEAAAABBEdSIQKVg785rgpgl0etGZrd1jT6YQhVnWxc05tMIYPxq5bgfyEC2rYf9JoU22p9ArDNH7t4/EsYMStbTlTa5Nui+/71NtdSriIGApWDvzmuCmCXR60Zmt3WNPphCFWdbFzTm0whg/GrluB/ENkMak8AAACAAAAAgAAAAIAiBgLath/0mhTban0CsM0fu3j8SxgxK1tOVNrk26L7/vU21xDZDGpPAAAAgAAAAIABAACAAAEBIADC6wsAAAAAF6kUt/X69A49QKWkWbHbNTXyty+pIeiHIgIDCJ3BDHrG21T5EymvYXMz2ziM6tDCMfcjN50bmQMLAtxHMEQCIGLrelVhB6fHP0WsSrWh3d9vcHX7EnWWmn84Pv/3hLyyAiAMBdu3Rw2/LwhVfdNWxzJcHtMJE+mWzThAlF2xIijaXwEBAwQBAAAAAQQiACCMI1MXN0O1ld+0oHtyuo5C43l9p06H/n2ddJfjsgKJAwEFR1IhAwidwQx6xttU+RMpr2FzM9s4jOrQwjH3IzedG5kDCwLcIQI63ZBPPW3PWd25BrDe4jUpt/+57VDl6GFRkmhgIh8Oc1KuIgYCOt2QTz1tz1nduQaw3uI1Kbf/ue1Q5ehhUZJoYCIfDnMQ2QxqTwAAAIAAAACAAwAAgCIGAwidwQx6xttU+RMpr2FzM9s4jOrQwjH3IzedG5kDCwLcENkMak8AAACAAAAAgAIAAIAAIgIDqaTDf1mW06ol26xrVwrwZQOUSSlCRgs1R1Ptnuylh3EQ2QxqTwAAAIAAAACABAAAgAAiAgJ/Y5l1fS7/VaE2rQLGhLGDi2VW5fG2s0KCqUtrUAUQlhDZDGpPAAAAgAAAAIAFAACAAA==
\n\nGiven the above updated PSBT, a signer with the following keys:\n* cT7J9YpCwY3AVRFSjN6ukeEeWY6mhpbJPxRaDaP5QTdygQRxP9Au (m/0'/0'/1')\n* cNBc3SWUip9PPm1GjRoLEJT6T41iNzCYtD7qro84FMnM5zEqeJsE (m/0'/0'/3')\nmust create this PSBT:\n\n* Bytes in Hex: 
70736274ff01009a020000000258e87a21b56daf0c23be8e7070456c336f7cbaa5c8757924f545887bb2abdd750000000000ffffffff838d0427d0ec650a68aa46bb0b098aea4422c071b2ca78352a077959d07cea1d0100000000ffffffff0270aaf00800000000160014d85c2b71d0060b09c9886aeb815e50991dda124d00e1f5050000000016001400aea9a2e5f0f876a588df5546e8742d1d87008f00000000000100bb0200000001aad73931018bd25f84ae400b68848be09db706eac2ac18298babee71ab656f8b0000000048473044022058f6fc7c6a33e1b31548d481c826c015bd30135aad42cd67790dab66d2ad243b02204a1ced2604c6735b6393e5b41691dd78b00f0c5942fb9f751856faa938157dba01feffffff0280f0fa020000000017a9140fb9463421696b82c833af241c78c17ddbde493487d0f20a270100000017a91429ca74f8a08f81999428185c97b5d852e4063f618765000000220202dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d7483045022100f61038b308dc1da865a34852746f015772934208c6d24454393cd99bdf2217770220056e675a675a6d0a02b85b14e5e29074d8a25a9b5760bea2816f661910a006ea01010304010000000104475221029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f2102dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d752ae2206029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f10d90c6a4f000000800000008000000080220602dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d710d90c6a4f0000008000000080010000800001012000c2eb0b0000000017a914b7f5faf40e3d40a5a459b1db3535f2b72fa921e8872202023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e73473044022065f45ba5998b59a27ffe1a7bed016af1f1f90d54b3aa8f7450aa5f56a25103bd02207f724703ad1edb96680b284b56d4ffcb88f7fb759eabbe08aa30f29b851383d2010103040100000001042200208c2353173743b595dfb4a07b72ba8e42e3797da74e87fe7d9d7497e3b2028903010547522103089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc21023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7352ae2206023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7310d90c6a4f000000800000008003000080220603089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc10d90c6a4f00000080000000800200008000220203a9a4c37f5996d3aa25dbac6b570af0650394492942460b354753ed9eeca5877110d90c6a4f000000800000008004000080002202027f6399757d2eff55a136ad02c684b1838b6556e5f1b6b34282a94b6b5005109610d90c6a4f00000080000000800500008000
\n* Base64 String: 
cHNidP8BAJoCAAAAAljoeiG1ba8MI76OcHBFbDNvfLqlyHV5JPVFiHuyq911AAAAAAD/////g40EJ9DsZQpoqka7CwmK6kQiwHGyyng1Kgd5WdB86h0BAAAAAP////8CcKrwCAAAAAAWABTYXCtx0AYLCcmIauuBXlCZHdoSTQDh9QUAAAAAFgAUAK6pouXw+HaliN9VRuh0LR2HAI8AAAAAAAEAuwIAAAABqtc5MQGL0l+ErkALaISL4J23BurCrBgpi6vucatlb4sAAAAASEcwRAIgWPb8fGoz4bMVSNSByCbAFb0wE1qtQs1neQ2rZtKtJDsCIEoc7SYExnNbY5PltBaR3XiwDwxZQvufdRhW+qk4FX26Af7///8CgPD6AgAAAAAXqRQPuUY0IWlrgsgzryQceMF9295JNIfQ8gonAQAAABepFCnKdPigj4GZlCgYXJe12FLkBj9hh2UAAAAiAgLath/0mhTban0CsM0fu3j8SxgxK1tOVNrk26L7/vU210gwRQIhAPYQOLMI3B2oZaNIUnRvAVdyk0IIxtJEVDk82ZvfIhd3AiAFbmdaZ1ptCgK4WxTl4pB02KJam1dgvqKBb2YZEKAG6gEBAwQBAAAAAQRHUiEClYO/Oa4KYJdHrRma3dY0+mEIVZ1sXNObTCGD8auW4H8hAtq2H/SaFNtqfQKwzR+7ePxLGDErW05U2uTbovv+9TbXUq4iBgKVg785rgpgl0etGZrd1jT6YQhVnWxc05tMIYPxq5bgfxDZDGpPAAAAgAAAAIAAAACAIgYC2rYf9JoU22p9ArDNH7t4/EsYMStbTlTa5Nui+/71NtcQ2QxqTwAAAIAAAACAAQAAgAABASAAwusLAAAAABepFLf1+vQOPUClpFmx2zU18rcvqSHohyICAjrdkE89bc9Z3bkGsN7iNSm3/7ntUOXoYVGSaGAiHw5zRzBEAiBl9FulmYtZon/+GnvtAWrx8fkNVLOqj3RQql9WolEDvQIgf3JHA60e25ZoCyhLVtT/y4j3+3Weq74IqjDym4UTg9IBAQMEAQAAAAEEIgAgjCNTFzdDtZXftKB7crqOQuN5fadOh/59nXSX47ICiQMBBUdSIQMIncEMesbbVPkTKa9hczPbOIzq0MIx9yM3nRuZAwsC3CECOt2QTz1tz1nduQaw3uI1Kbf/ue1Q5ehhUZJoYCIfDnNSriIGAjrdkE89bc9Z3bkGsN7iNSm3/7ntUOXoYVGSaGAiHw5zENkMak8AAACAAAAAgAMAAIAiBgMIncEMesbbVPkTKa9hczPbOIzq0MIx9yM3nRuZAwsC3BDZDGpPAAAAgAAAAIACAACAACICA6mkw39ZltOqJdusa1cK8GUDlEkpQkYLNUdT7Z7spYdxENkMak8AAACAAAAAgAQAAIAAIgICf2OZdX0u/1WhNq0CxoSxg4tlVuXxtrNCgqlLa1AFEJYQ2QxqTwAAAIAAAACABQAAgAA=
\n\nGiven both of the above PSBTs, a combiner must create this PSBT:\n\n* Bytes in Hex: 
70736274ff01009a020000000258e87a21b56daf0c23be8e7070456c336f7cbaa5c8757924f545887bb2abdd750000000000ffffffff838d0427d0ec650a68aa46bb0b098aea4422c071b2ca78352a077959d07cea1d0100000000ffffffff0270aaf00800000000160014d85c2b71d0060b09c9886aeb815e50991dda124d00e1f5050000000016001400aea9a2e5f0f876a588df5546e8742d1d87008f00000000000100bb0200000001aad73931018bd25f84ae400b68848be09db706eac2ac18298babee71ab656f8b0000000048473044022058f6fc7c6a33e1b31548d481c826c015bd30135aad42cd67790dab66d2ad243b02204a1ced2604c6735b6393e5b41691dd78b00f0c5942fb9f751856faa938157dba01feffffff0280f0fa020000000017a9140fb9463421696b82c833af241c78c17ddbde493487d0f20a270100000017a91429ca74f8a08f81999428185c97b5d852e4063f6187650000002202029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f473044022074018ad4180097b873323c0015720b3684cc8123891048e7dbcd9b55ad679c99022073d369b740e3eb53dcefa33823c8070514ca55a7dd9544f157c167913261118c01220202dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d7483045022100f61038b308dc1da865a34852746f015772934208c6d24454393cd99bdf2217770220056e675a675a6d0a02b85b14e5e29074d8a25a9b5760bea2816f661910a006ea01010304010000000104475221029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f2102dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d752ae2206029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f10d90c6a4f000000800000008000000080220602dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d710d90c6a4f0000008000000080010000800001012000c2eb0b0000000017a914b7f5faf40e3d40a5a459b1db3535f2b72fa921e887220203089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc473044022062eb7a556107a7c73f45ac4ab5a1dddf6f7075fb1275969a7f383efff784bcb202200c05dbb7470dbf2f08557dd356c7325c1ed30913e996cd3840945db12228da5f012202023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e73473044022065f45ba5998b59a27ffe1a7bed016af1f1f90d54b3aa8f7450aa5f56a25103bd02207f724703ad1edb96680b284b56d4ffcb88f7fb759eabbe08aa30f29b851383d2010103040100000001042200208c2353173743b595dfb4a07b72ba8e42e3797da74e87fe7d9d7497e3b2028903010547522103089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc21023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7352ae2206023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7310d90c6a4f000000800000008003000080220603089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc10d90c6a4f00000080000000800200008000220203a9a4c37f5996d3aa25dbac6b570af0650394492942460b354753ed9eeca5877110d90c6a4f000000800000008004000080002202027f6399757d2eff55a136ad02c684b1838b6556e5f1b6b34282a94b6b5005109610d90c6a4f00000080000000800500008000
\n* Base64 String: 
cHNidP8BAJoCAAAAAljoeiG1ba8MI76OcHBFbDNvfLqlyHV5JPVFiHuyq911AAAAAAD/////g40EJ9DsZQpoqka7CwmK6kQiwHGyyng1Kgd5WdB86h0BAAAAAP////8CcKrwCAAAAAAWABTYXCtx0AYLCcmIauuBXlCZHdoSTQDh9QUAAAAAFgAUAK6pouXw+HaliN9VRuh0LR2HAI8AAAAAAAEAuwIAAAABqtc5MQGL0l+ErkALaISL4J23BurCrBgpi6vucatlb4sAAAAASEcwRAIgWPb8fGoz4bMVSNSByCbAFb0wE1qtQs1neQ2rZtKtJDsCIEoc7SYExnNbY5PltBaR3XiwDwxZQvufdRhW+qk4FX26Af7///8CgPD6AgAAAAAXqRQPuUY0IWlrgsgzryQceMF9295JNIfQ8gonAQAAABepFCnKdPigj4GZlCgYXJe12FLkBj9hh2UAAAAiAgKVg785rgpgl0etGZrd1jT6YQhVnWxc05tMIYPxq5bgf0cwRAIgdAGK1BgAl7hzMjwAFXILNoTMgSOJEEjn282bVa1nnJkCIHPTabdA4+tT3O+jOCPIBwUUylWn3ZVE8VfBZ5EyYRGMASICAtq2H/SaFNtqfQKwzR+7ePxLGDErW05U2uTbovv+9TbXSDBFAiEA9hA4swjcHahlo0hSdG8BV3KTQgjG0kRUOTzZm98iF3cCIAVuZ1pnWm0KArhbFOXikHTYolqbV2C+ooFvZhkQoAbqAQEDBAEAAAABBEdSIQKVg785rgpgl0etGZrd1jT6YQhVnWxc05tMIYPxq5bgfyEC2rYf9JoU22p9ArDNH7t4/EsYMStbTlTa5Nui+/71NtdSriIGApWDvzmuCmCXR60Zmt3WNPphCFWdbFzTm0whg/GrluB/ENkMak8AAACAAAAAgAAAAIAiBgLath/0mhTban0CsM0fu3j8SxgxK1tOVNrk26L7/vU21xDZDGpPAAAAgAAAAIABAACAAAEBIADC6wsAAAAAF6kUt/X69A49QKWkWbHbNTXyty+pIeiHIgIDCJ3BDHrG21T5EymvYXMz2ziM6tDCMfcjN50bmQMLAtxHMEQCIGLrelVhB6fHP0WsSrWh3d9vcHX7EnWWmn84Pv/3hLyyAiAMBdu3Rw2/LwhVfdNWxzJcHtMJE+mWzThAlF2xIijaXwEiAgI63ZBPPW3PWd25BrDe4jUpt/+57VDl6GFRkmhgIh8Oc0cwRAIgZfRbpZmLWaJ//hp77QFq8fH5DVSzqo90UKpfVqJRA70CIH9yRwOtHtuWaAsoS1bU/8uI9/t1nqu+CKow8puFE4PSAQEDBAEAAAABBCIAIIwjUxc3Q7WV37Sge3K6jkLjeX2nTof+fZ10l+OyAokDAQVHUiEDCJ3BDHrG21T5EymvYXMz2ziM6tDCMfcjN50bmQMLAtwhAjrdkE89bc9Z3bkGsN7iNSm3/7ntUOXoYVGSaGAiHw5zUq4iBgI63ZBPPW3PWd25BrDe4jUpt/+57VDl6GFRkmhgIh8OcxDZDGpPAAAAgAAAAIADAACAIgYDCJ3BDHrG21T5EymvYXMz2ziM6tDCMfcjN50bmQMLAtwQ2QxqTwAAAIAAAACAAgAAgAAiAgOppMN/WZbTqiXbrGtXCvBlA5RJKUJGCzVHU+2e7KWHcRDZDGpPAAAAgAAAAIAEAACAACICAn9jmXV9Lv9VoTatAsaEsYOLZVbl8bazQoKpS2tQBRCWENkMak8AAACAAAAAgAUAAIAA
\n\nGiven the above PSBT, an input finalizer must create this PSBT:\n\n* Bytes in Hex: 
70736274ff01009a020000000258e87a21b56daf0c23be8e7070456c336f7cbaa5c8757924f545887bb2abdd750000000000ffffffff838d0427d0ec650a68aa46bb0b098aea4422c071b2ca78352a077959d07cea1d0100000000ffffffff0270aaf00800000000160014d85c2b71d0060b09c9886aeb815e50991dda124d00e1f5050000000016001400aea9a2e5f0f876a588df5546e8742d1d87008f00000000000100bb0200000001aad73931018bd25f84ae400b68848be09db706eac2ac18298babee71ab656f8b0000000048473044022058f6fc7c6a33e1b31548d481c826c015bd30135aad42cd67790dab66d2ad243b02204a1ced2604c6735b6393e5b41691dd78b00f0c5942fb9f751856faa938157dba01feffffff0280f0fa020000000017a9140fb9463421696b82c833af241c78c17ddbde493487d0f20a270100000017a91429ca74f8a08f81999428185c97b5d852e4063f6187650000000107da00473044022074018ad4180097b873323c0015720b3684cc8123891048e7dbcd9b55ad679c99022073d369b740e3eb53dcefa33823c8070514ca55a7dd9544f157c167913261118c01483045022100f61038b308dc1da865a34852746f015772934208c6d24454393cd99bdf2217770220056e675a675a6d0a02b85b14e5e29074d8a25a9b5760bea2816f661910a006ea01475221029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f2102dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d752ae0001012000c2eb0b0000000017a914b7f5faf40e3d40a5a459b1db3535f2b72fa921e8870107232200208c2353173743b595dfb4a07b72ba8e42e3797da74e87fe7d9d7497e3b20289030108da0400473044022062eb7a556107a7c73f45ac4ab5a1dddf6f7075fb1275969a7f383efff784bcb202200c05dbb7470dbf2f08557dd356c7325c1ed30913e996cd3840945db12228da5f01473044022065f45ba5998b59a27ffe1a7bed016af1f1f90d54b3aa8f7450aa5f56a25103bd02207f724703ad1edb96680b284b56d4ffcb88f7fb759eabbe08aa30f29b851383d20147522103089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc21023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7352ae00220203a9a4c37f5996d3aa25dbac6b570af0650394492942460b354753ed9eeca5877110d90c6a4f000000800000008004000080002202027f6399757d2eff55a136ad02c684b1838b6556e5f1b6b34282a94b6b5005109610d90c6a4f00000080000000800500008000
\n* Base64 String: 
cHNidP8BAJoCAAAAAljoeiG1ba8MI76OcHBFbDNvfLqlyHV5JPVFiHuyq911AAAAAAD/////g40EJ9DsZQpoqka7CwmK6kQiwHGyyng1Kgd5WdB86h0BAAAAAP////8CcKrwCAAAAAAWABTYXCtx0AYLCcmIauuBXlCZHdoSTQDh9QUAAAAAFgAUAK6pouXw+HaliN9VRuh0LR2HAI8AAAAAAAEAuwIAAAABqtc5MQGL0l+ErkALaISL4J23BurCrBgpi6vucatlb4sAAAAASEcwRAIgWPb8fGoz4bMVSNSByCbAFb0wE1qtQs1neQ2rZtKtJDsCIEoc7SYExnNbY5PltBaR3XiwDwxZQvufdRhW+qk4FX26Af7///8CgPD6AgAAAAAXqRQPuUY0IWlrgsgzryQceMF9295JNIfQ8gonAQAAABepFCnKdPigj4GZlCgYXJe12FLkBj9hh2UAAAABB9oARzBEAiB0AYrUGACXuHMyPAAVcgs2hMyBI4kQSOfbzZtVrWecmQIgc9Npt0Dj61Pc76M4I8gHBRTKVafdlUTxV8FnkTJhEYwBSDBFAiEA9hA4swjcHahlo0hSdG8BV3KTQgjG0kRUOTzZm98iF3cCIAVuZ1pnWm0KArhbFOXikHTYolqbV2C+ooFvZhkQoAbqAUdSIQKVg785rgpgl0etGZrd1jT6YQhVnWxc05tMIYPxq5bgfyEC2rYf9JoU22p9ArDNH7t4/EsYMStbTlTa5Nui+/71NtdSrgABASAAwusLAAAAABepFLf1+vQOPUClpFmx2zU18rcvqSHohwEHIyIAIIwjUxc3Q7WV37Sge3K6jkLjeX2nTof+fZ10l+OyAokDAQjaBABHMEQCIGLrelVhB6fHP0WsSrWh3d9vcHX7EnWWmn84Pv/3hLyyAiAMBdu3Rw2/LwhVfdNWxzJcHtMJE+mWzThAlF2xIijaXwFHMEQCIGX0W6WZi1mif/4ae+0BavHx+Q1Us6qPdFCqX1aiUQO9AiB/ckcDrR7blmgLKEtW1P/LiPf7dZ6rvgiqMPKbhROD0gFHUiEDCJ3BDHrG21T5EymvYXMz2ziM6tDCMfcjN50bmQMLAtwhAjrdkE89bc9Z3bkGsN7iNSm3/7ntUOXoYVGSaGAiHw5zUq4AIgIDqaTDf1mW06ol26xrVwrwZQOUSSlCRgs1R1Ptnuylh3EQ2QxqTwAAAIAAAACABAAAgAAiAgJ/Y5l1fS7/VaE2rQLGhLGDi2VW5fG2s0KCqUtrUAUQlhDZDGpPAAAAgAAAAIAFAACAAA==
\n\nGiven the above PSBT, a transaction extractor must create this Bitcoin transaction:\n\n* Bytes in Hex: 
0200000000010258e87a21b56daf0c23be8e7070456c336f7cbaa5c8757924f545887bb2abdd7500000000da00473044022074018ad4180097b873323c0015720b3684cc8123891048e7dbcd9b55ad679c99022073d369b740e3eb53dcefa33823c8070514ca55a7dd9544f157c167913261118c01483045022100f61038b308dc1da865a34852746f015772934208c6d24454393cd99bdf2217770220056e675a675a6d0a02b85b14e5e29074d8a25a9b5760bea2816f661910a006ea01475221029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f2102dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d752aeffffffff838d0427d0ec650a68aa46bb0b098aea4422c071b2ca78352a077959d07cea1d01000000232200208c2353173743b595dfb4a07b72ba8e42e3797da74e87fe7d9d7497e3b2028903ffffffff0270aaf00800000000160014d85c2b71d0060b09c9886aeb815e50991dda124d00e1f5050000000016001400aea9a2e5f0f876a588df5546e8742d1d87008f000400473044022062eb7a556107a7c73f45ac4ab5a1dddf6f7075fb1275969a7f383efff784bcb202200c05dbb7470dbf2f08557dd356c7325c1ed30913e996cd3840945db12228da5f01473044022065f45ba5998b59a27ffe1a7bed016af1f1f90d54b3aa8f7450aa5f56a25103bd02207f724703ad1edb96680b284b56d4ffcb88f7fb759eabbe08aa30f29b851383d20147522103089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc21023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7352ae00000000
\n\nGiven these two PSBTs with unknown key-value pairs:\n* Bytes in Hex: 
70736274ff01003f0200000001ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff0000000000ffffffff010000000000000000036a0100000000000af00102030405060708090f0102030405060708090a0b0c0d0e0f000af00102030405060708090f0102030405060708090a0b0c0d0e0f000af00102030405060708090f0102030405060708090a0b0c0d0e0f00
\n** Base64 String: 
cHNidP8BAD8CAAAAAf//////////////////////////////////////////AAAAAAD/////AQAAAAAAAAAAA2oBAAAAAAAK8AECAwQFBgcICQ8BAgMEBQYHCAkKCwwNDg8ACvABAgMEBQYHCAkPAQIDBAUGBwgJCgsMDQ4PAArwAQIDBAUGBwgJDwECAwQFBgcICQoLDA0ODwA=
\n\n* Bytes in Hex: 
70736274ff01003f0200000001ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff0000000000ffffffff010000000000000000036a0100000000000af00102030405060708100f0102030405060708090a0b0c0d0e0f000af00102030405060708100f0102030405060708090a0b0c0d0e0f000af00102030405060708100f0102030405060708090a0b0c0d0e0f00
\n** Base64 String: 
cHNidP8BAD8CAAAAAf//////////////////////////////////////////AAAAAAD/////AQAAAAAAAAAAA2oBAAAAAAAK8AECAwQFBgcIEA8BAgMEBQYHCAkKCwwNDg8ACvABAgMEBQYHCBAPAQIDBAUGBwgJCgsMDQ4PAArwAQIDBAUGBwgQDwECAwQFBgcICQoLDA0ODwA=
\n\nA combiner which orders keys lexicographically must produce the following PSBT:\n\n* Bytes in Hex: 
70736274ff01003f0200000001ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff0000000000ffffffff010000000000000000036a0100000000000af00102030405060708090f0102030405060708090a0b0c0d0e0f0af00102030405060708100f0102030405060708090a0b0c0d0e0f000af00102030405060708090f0102030405060708090a0b0c0d0e0f0af00102030405060708100f0102030405060708090a0b0c0d0e0f000af00102030405060708090f0102030405060708090a0b0c0d0e0f0af00102030405060708100f0102030405060708090a0b0c0d0e0f00
\n* Base64 String: 
cHNidP8BAD8CAAAAAf//////////////////////////////////////////AAAAAAD/////AQAAAAAAAAAAA2oBAAAAAAAK8AECAwQFBgcICQ8BAgMEBQYHCAkKCwwNDg8K8AECAwQFBgcIEA8BAgMEBQYHCAkKCwwNDg8ACvABAgMEBQYHCAkPAQIDBAUGBwgJCgsMDQ4PCvABAgMEBQYHCBAPAQIDBAUGBwgJCgsMDQ4PAArwAQIDBAUGBwgJDwECAwQFBgcICQoLDA0ODwrwAQIDBAUGBwgQDwECAwQFBgcICQoLDA0ODwA=
\n\n==Rationale==\n\n\n\n==Reference implementation==\n\nThe reference implementation of the PSBT format is available at https://github.com/achow101/bitcoin/tree/psbt.\n\n==Acknowledgements==\n\nSpecial thanks to Pieter Wuille for suggesting that such a transaction format should be made\nand for coming up with the name and abbreviation of PSBT.\n\nThanks to Pieter Wuille, Gregory Maxwell, Jonathan Underwood, Daniel Cousens and those who commented on the bitcoin-dev mailing list for additional comments\nand suggestions for improving this proposal.", "category": "bips" }, { "instruction": "I'm trying to understand 
 - can you walk me through it?",
    "input": "",
    "output": "BIP: 90\n  Title: Buried Deployments\n  Authors: Suhas Daftuar \n  Comments-Summary: Mostly Recommended for implementation, with some Discouragement\n  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0090\n  Status: Deployed\n  Type: Informational\n  Assigned: 2016-11-08\n  License: PD\n
\n\n\n==Abstract==\n\nPrior soft forks (BIP 34, BIP 65, and BIP 66) were activated via miner signaling in block version numbers. Now that the chain has long since passed the blocks at which those consensus rules have triggered, we can (as a simplification) replace the trigger mechanism by caching the block heights at which those consensus rules became enforced.\n\n==Motivation==\n\nBIPs 34, 65 and 66 were deployed on mainnet using miner signaling using block version numbers. In short, new consensus rules were proposed for use in blocks with a higher version number (N+1) than the prevailing block version (N) in use on the network, and those rules became enforced under the following conditions:", "category": "bips" }, { "instruction": "Hey, I need to set up Bitcoin Operations Guide - what's the command line way to do that?", "input": "", "output": "# 75% rule: If 750 of the prior 1000 blocks are version N+1 or higher, then blocks with version N+1 or higher must correctly enforce the new consensus rule.", "category": "bips" }, { "instruction": "What's the deal with 95% rule: If 950 of the prior 1000 blocks are version N+1 or higher, then blocks with version less than N+1 are invalid. in Bitcoin? Explain it like I'm a friend.", "input": "", "output": "Please see those [[#references|BIPs]] for more details.\n\nNote that this trigger mechanism is dependent on the chain history. To validate a block, we must test whether the trigger was met by looking at the previous 1000 blocks in the chain before it, which can be inefficient.\n\nIn addition, this mechanism for code deployments have been deprecated in favor of BIP 9 deployments, which offer several advantages (please see [https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki BIP 9]).\n\nThus we propose elimination of the logic implementing these kinds of deployments, by replacing the test which governs enforcement of BIP 34, BIP 65, and BIP 66 with simple height checks, which we choose to be the block height triggering the 95% activation rule on mainnet for each of those deployments. This simplification of the consensus rules would reduce the technical debt associated with deployment of those consensus changes.\n\n==Considerations==\n\nIt is technically possible for this to be a non-backwards compatible change. For example, if an alternate chain were created in which BIP 34's 95% activation triggered at a lower height (H') than it did on the current mainnet chain (H), then older software would enforce that version 1 blocks were invalid at heights between H' and H, while newer software implementing this change would not. Similarly, this BIP proposes doing away with the 75% threshold check altogether, which means, for example, that a version 2 block forking off of mainnet at height H-1 which omitted the height in coinbase would be invalid to older software, while accepted by newer software.\n\nHowever, while newer software and older software might validate old blocks differently, that could only cause a consensus split if there were an extremely large blockchain reorganization onto a chain built off such a block. As of November 2016, the most recent of these changes (BIP 65, enforced since December 2015) has nearly 50,000 blocks built on top of it. The occurrence of such a reorg that would cause the activating block to be disconnected would raise fundamental concerns about the security assumptions of Bitcoin, a far bigger issue than any non-backwards compatible change.\n\nSo while this proposal could theoretically result in a consensus split, it is extremely unlikely, and in particular any such circumstances would be sufficiently damaging to the Bitcoin network to dwarf any concerns about the effects of this proposed change.\n\n==Specification==\n\nThe BIP 34, 66, and 65 activation heights are set to 227931, 363725, and 388381, respectively.\n\nThe 1000-block lookback test, first described in BIP 34, is no longer performed during validation of any blocks. Instead, a new check is added:\n\n if((block.nVersion < 2 && nHeight >= consensusParams.BIP34Height) ||\n (block.nVersion < 3 && nHeight >= consensusParams.BIP66Height) ||\n (block.nVersion < 4 && nHeight >= consensusParams.BIP65Height))\n return state.Invalid(false, REJECT_OBSOLETE, strprintf(\"bad-version(0x%08x)\", block.nVersion),\n strprintf(\"rejected nVersion=0x%08x block\", block.nVersion));\n\nFurthermore, rather than consider the block versions of the prior 1000 blocks to determine whether to enforce BIP 34, BIP 65, or BIP 66 on a given block, we instead just compare the height of the block being validated with the stored activation heights:\n\n // Enforce rule that the coinbase starts with serialized block height\n if (nHeight >= consensusParams.BIP34Height)\n {\n CScript expect = CScript() << nHeight;\n if (block.vtx[0].vin[0].scriptSig.size() < expect.size() ||\n !std::equal(expect.begin(), expect.end(), block.vtx[0].vin[0].scriptSig.begin())) {\n return state.DoS(100, false, REJECT_INVALID, \"bad-cb-height\", false, \"block height mismatch in coinbase\");\n }\n }\n\nand\n\n // Start enforcing the DERSIG (BIP66) rule\n if (pindex->nHeight >= chainparams.GetConsensus().BIP66Height) {\n flags |= SCRIPT_VERIFY_DERSIG;\n }\n\n // Start enforcing CHECKLOCKTIMEVERIFY (BIP65) rule\n if (pindex->nHeight >= chainparams.GetConsensus().BIP65Height) {\n flags |= SCRIPT_VERIFY_CHECKLOCKTIMEVERIFY;\n }\n\nPlease see the implementation for additional details.\n\n==Implementation==\n\nhttps://github.com/bitcoin/bitcoin/pull/8391.\n\n\n==References==\n\n[https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki BIP34 Block v2, Height in Coinbase]\n\n[https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki BIP66 Strict DER signatures]\n\n[https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP65 OP_CHECKLOCKTIMEVERIFY]\n\n[https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki BIP9 Version bits with timeout and delay]\n\n==Acknowledgements==\n\nThanks to Nicolas Dorier for drafting an initial version of this BIP, and to Alex Morcos, Matt Corallo, and Greg Maxwell for suggestions and feedback.\n\n==Copyright==\n\nThis document is placed in the public domain.", "category": "bips" }, { "instruction": "Can you show me the CLI commands for 
?",
    "input": "",
    "output": "BIP: 79\n  Layer: Applications\n  Title: Bustapay :: a practical coinjoin protocol\n  Authors: Ryan Havar \n  Status: Closed\n  Type: Informational\n  Assigned: 2018-10-05\n  License: CC0-1.0\n  Proposed-Replacement: 78\n
\n\n\n==Abstract==\n\nThe way bitcoin transactions are normally created leaks more information than desirable, and as a result has been exploited by unreasonably effective blockchain analysis techniques to jeopardize important properties that are expected of a useful currency.\n\nBustapay is a simple and practical protocol for the sender and receiver of a payment to collaboratively sign a bitcoin transaction in such a way that busts some analysis assumptions to the immediate benefit of the sender and receiver. Furthermore it does so in such a way that gives a significant amount of control to the receiver to help manage their utxo set size, a constant problem for bitcoin merchants.\n\n==Copyright==\n\nThis document is licensed under the Creative Commons CC0 1.0 Universal license.\n\n==Motivation==\n\nOne of the most powerful blockchain analysis heuristics has been to assume all inputs of a transaction are controlled by a single party unless otherwise known (such as by the distinctive structure of a traditional coinjoin, or multisig spends that are validated onchain). Combined with other techniques (notably change-output guessing) this has lead to unexpectedly accurate tracking that has exposed bitcoin participants to unacceptable personal, business and financial risks -- undermining bitcoin's utility and fungibility -- and ultimately jeopardizing its ability to function as useful money.\n\nWe however can bust these assumptions with a sender-receiver coinjoin. To prevent costless spy/DoS attacks, we require the sending party to provide a fully-valid ready-to-propagate transaction to initiate the process, that the receiver can broadcast if the sender never completes the coinjoin thus tying the cost to that of spending a utxo. Most promisingly, bustapay transactions do not have an identifiable structure so any network analysis will be not able to tell if a given transaction is a bustapay transaction or not which erodes the confidence of their entire models, providing positive externalities for the entire bitcoin ecosystem.\n\nBustapay transactions also do not grow the receiver's count of unspent transaction outputs, and in fact gives the receiver an opportunity to better manage their utxo set, something normally only done when sending payments. Large utxo sets are often problematic and expensive, and frequently requiring privacy-destroying consolidation. Besides busting clustering assumptions, bustapay also provides a layer of obfuscation of send amounts.\n\nIt is worth noting that this specification has eschewed complexity and potentially useful extensions on the assumption that simplicity is of the most important to encourage adoption.\n\n\n==Overview==\n\nA bustapay payment is made from a sender to a receiver.\n\n====Step 1. Sender creates a bitcoin transaction paying the receiver====\n\nThis transaction must use segwit for all inputs, and be fully valid and signed. The transaction must be eligible for propagation on the network (but not done so at this stage)\n\n====Step 2. Sender gives the \"template transaction\" to the receiver====\n\nThis is done via an HTTP POST request, sent to a \"bustapay url\"\n\n====Step 3. Receiver processes the transaction and returns a partially signed coinjoin====\n\nThe receiver validates the transaction, and pays himself. The receiver then adds one or more of his own inputs (known as the ''contributed inputs'') and (optionally) increases the output that pays himself (generally by the sum of the ''contributed inputs''). Doing so creates a ''partial transaction'', which the receiver returns to the sender. It is called such as it requires the sender to re-sign his own inputs.\n\n====Step 4. Sender validates, re-signs, and propagates on the bitcoin network====\n\nThe sender MUST validate the ''partial transaction'' was changed correctly and non-maliciously (to allow using potentially untrusted communication channels), re-sign its original inputs and propagate the final transaction over the bitcoin network.\n\n====Step 5. Receiver observes the finalized transaction on the bitcoin network====\n\nOnce the receiver has seen the finalized transactions on the network (and has enough confirmations) it can process it like a normal payment for the sent amount (as opposed to the amount that it looks like on the network). If the receiver does not see the finalized transaction after a timeout, they will propagate the original \"template transaction\", which ensures the payment happens and functions a strong anti-DoS mechanism.\n\n== Specification ==\n\nThe standard way of letting a sender know where to send a bustapay transaction is done via a bip21 encoded address. The key value \"bpu\" (short for \"BustaPayUrl\") should be used. An example of such address would be bitcoin:2NABbUr9yeRCp1oUCtVmgJF8HGRCo3ifpTT?bpu=https://bp.bustabit.com/submit It is highly encouraged that urls are kept short.\n\nWhen the sender is creating a \"template transaction\" it is done almost identically to creating a normal send, with the exception that *only* segwit inputs may be used. The sender is also encouraged to use a slightly more aggressive feerate than usual as well as BIP125 (Opt-in Full Replace-by-Fee Signaling), but neither is strictly required.\n\nThe template transaction should be sent to the receiver via an HTTP POST to the bustapay url, with a binary encoded body.\n\nThe receiver is then responsible for validating the template transaction. If there is a problem with the transaction, or the receiver is generally unhappy with the transaction (e.g. fees are too small) the HTTP response code of 422 should be used and a human-readable string containing information on why which can be directly given to the user.\n\nShould the receiver reject a transaction, it should not attempt to propagate it on the network. However it is important for the sender to be aware that the receiver *could* at any time (regardless of which error was given) send this transaction. The client should therefore assume the receiver will, and act accordingly (either retry with adjustments or just propagate the transaction). It is imperative that the sender never finds themselves in a situation where two payments to the sender could be valid.\n\n=== Contributed Input Choice ===\n\nThe receiver must add at least one input to the transaction (the \"contributed inputs\"). If the receiver has no inputs, it should use a 500 internal server error, so the client can send the transaction as per normal (or try again later). Its generally advised to only add a single contributed input, however they are circumstances where adding more than a single input can be useful.\n\nTo prevent an attack where a receiver is continually sent variations of the same transaction to enumerate the receiver's utxo set, it is essential that the receiver always returns the same contributed inputs when it's seen the same inputs.\n\nIt is strongly preferable that the receiver makes an effort to pick a contributed input of the same type as the other transaction inputs if possible.\n\n=== Output Adjustment ===\n\nAfter adding inputs to the transaction, the receiver generally will want to adjust the output that pays himself by increasing it by the sum of the contributed input amounts (minus any fees he wants to contribute). However the only strict requirement is that the receiver *must never* remove inputs, and *must not* ever decrease any output amount.\n\n=== Returning the partial transaction ===\n\nThe receiver must sign all contributed inputs in the partial transaction. The partial transaction should also remove all witnesses from the original template transaction as they are no longer valid, and need to be recalculated by the sender. The receiver returns the partial transaction as a binary-encoded HTTP response with a status code of 200. To ensure compatibility with web-wallets and browser-based-tools, all responses (including errors) must contain the HTTP header \"Access-Control-Allow-Origin: *\"\n\n\n=== Sender Validation ===\n\nThe sender *must* do important validation on the partial transaction. They *must* verify:\n\n* All template transaction inputs are in the partial transaction (but perhaps different order) and have the same sequence numbers.\n* The partial transaction contains at least one new (and signed) segwit input (owned by the receiver)\n* All outputs from the template transaction exist in the partial transaction, except they are allowed to be reordered and have their amounts increased (but *never* decreased)\n\n=== Creating Final Transaction ===\n\nAfter validating the partial transaction, the sender signs all its inputs to create what is now the final transaction. It is important that the sender is careful to not be tricked by the receiver into signing other inputs it owns. The sender must only sign inputs that existed in the template transaction. If the sender is not careful the receiver may \"contribute\" inputs that are actually owned by the sender, with the hope the sender blindly signs everything.\n\n\n=== Transaction Publishing ===\n\nOnce the final transaction is created, the sender should publish it directly onto the bitcoin network. If the sender does not do this after a reasonable time (e.g. 1 minute), the receiver should publish the template transaction as an important anti-spy/anti-DoS tactic . The sender may also choose to publish the template transaction instead of the final transaction if they believe the receiver to have unreasonably lowered the feerate of the transaction (i.e. increased the size of the transaction, but not the feerate enough). And both parties can consider publishing the template transaction even after the finalized transaction is on the network (taking advantage of replace-by-fee) if the final transaction is not confirming and the template transaction has more fees.\n\n\n=== Implementation Notes ===\nFor anyone wanting to implement bustapay payments, here are some notes for receivers:\n\n* A transaction can easily be checked if it's suitable for the mempool with testmempoolaccept in bitcoin core 0.17+\n* Tracking transactions by txid is precarious. To keep your sanity make sure all inputs are segwit. But remember segwit does not prevent txid malleability unless you validate the transaction. So really make sure you're using testmempoolaccept at the very least\n* Bustapay could be abused by a malicious party to query if you own a deposit address or not. So never accept a bustapay transaction that pays an already used deposit address\n* You will need to keep a mapping of which utxos people have showed you and which you revealed. So if you see them again, you can reveal the same one of your own\n* Check if the transaction was already sorted according to BIP69, if so ensure the result stays that way. Otherwise probably just shuffle the inputs/outputs\n* A reference implementation is maintained at https://github.com/rhavar/bustapay which functions as a wrapper around some RPC calls to bitcoin core's wallet.\n* The sender must be careful of an attack where the receiver tries to add additional inputs that are controlled by the sender, with the hope that the sender blindly signs it.\n\n== Backwards Compatibility ==\n\nBustapay is an optional payment protocol and therefore has no backwards compatibility concerns. It in fact can only be supported in addition to normal transaction processing, as falling back to a normal bitcoin transaction is a required behavior.\n\n\n== Credits ==\nThe idea is obviously based upon Dr. Maxwell's seminal CoinJoin proposal, and reduced scope inspired by a simplification of the \"pay 2 endpoint\" blog post by blockstream.", "category": "bips" }, { "instruction": "I'm stuck with 
 - what should I check?",
    "input": "",
    "output": "BIP: 199\n  Layer: Applications\n  Title: Hashed Time-Locked Contract transactions\n  Authors: Sean Bowe \n           Daira Hopwood \n  Comments-Summary: No comments yet.\n  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0199\n  Status: Closed\n  Type: Specification\n  Assigned: 2017-03-27\n  License: BSD-3-Clause OR CC0-1.0\n
\n\n==Abstract==\n\nThis BIP describes a script for generalized off-chain contract negotiation.\n\n==Summary==\n\nA Hashed Time-Locked Contract (HTLC) is a script that permits a designated party (the \"seller\") to spend funds by disclosing the preimage of a hash. It also permits\na second party (the \"buyer\") to spend the funds after a timeout is reached, in a refund situation.\n\nThe script takes the following form:\n\n OP_IF\n [HASHOP] OP_EQUALVERIFY OP_DUP OP_HASH160 \n OP_ELSE\n [TIMEOUTOP] OP_DROP OP_DUP OP_HASH160 \n OP_ENDIF\n OP_EQUALVERIFY\n OP_CHECKSIG\n\n[HASHOP] is either OP_SHA256 or OP_HASH160.\n\n[TIMEOUTOP] is either OP_CHECKSEQUENCEVERIFY or OP_CHECKLOCKTIMEVERIFY.\n\n===Interaction===\n\n* Victor (the \"buyer\") and Peggy (the \"seller\") exchange public keys and mutually agree upon a timeout threshold. Peggy provides a hash digest. Both parties can now construct the script and P2SH address for the HTLC.\n* Victor sends funds to the P2SH address.\n* Either:\n** Peggy spends the funds, and in doing so, reveals the preimage to Victor in the transaction; OR\n** Victor recovers the funds after the timeout threshold.\n\nVictor is interested in a lower timeout to reduce the amount of time that his funds are encumbered in the event that Peggy does not reveal the preimage. Peggy is\ninterested in a higher timeout to reduce the risk that she is unable to spend the funds before the threshold, or worse, that her transaction spending the funds does\nnot enter the blockchain before Victor's but does reveal the preimage to Victor anyway.\n\n==Motivation==\n\nIn many off-chain protocols, secret disclosure is used as part of a settlement mechanism. In some others, the secrets themselves are valuable. HTLC transactions are\na safe and cheap method of exchanging secrets for money over the blockchain, due to the ability to recover funds from an uncooperative counterparty, and the\nopportunity that the possessor of a secret has to receive the funds before such a refund can occur.\n\n===Lightning network===\n\nIn the lightning network, HTLC scripts are used to perform atomic swaps between payment channels.\n\nAlice constructs K and hashes it to produce L. She sends an HTLC payment to Bob for the preimage of L. Bob sends an HTLC payment to Carol for the same preimage and\namount. Only when Alice releases the preimage K does any exchange of value occur, and because the secret is divulged for each hop, all parties are compensated. If\nat any point some parties become uncooperative, the process can be aborted via the refund conditions.\n\n===Zero-knowledge contingent payments===\n\nVarious practical zero-knowledge proving systems exist which can be used to guarantee that a hash preimage derives valuable information. As an example, a\nzero-knowledge proof can be used to prove that a hash preimage acts as a decryption key for an encrypted sudoku puzzle solution. (See\n[https://github.com/zcash/pay-to-sudoku pay-to-sudoku] for a concrete example of such a protocol.)\n\nHTLC transactions can be used to exchange such decryption keys for money without risk, and they do not require large or expensive-to-validate transactions.\n\n==Implementation==\n\nhttps://github.com/bitcoin/bitcoin/pull/7601\n\n==Copyright==\n\nThis document is dual licensed as BSD 3-clause, and Creative Commons CC0 1.0 Universal.", "category": "bips" }, { "instruction": "How do I troubleshoot 
 issues?",
    "input": "",
    "output": "BIP: 148\n  Layer: Consensus (soft fork)\n  Title: Mandatory activation of segwit deployment\n  Authors: Shaolin Fry \n  Status: Deployed\n  Type: Specification\n  Assigned: 2017-03-12\n  License: BSD-3-Clause OR CC0-1.0\n
\n\n==Abstract==\n\nThis document specifies a BIP16 like soft fork flag day activation of the segregated witness BIP9 deployment known as \"segwit\".\n\n==Definitions==\n\n\"existing segwit deployment\" refer to the BIP9 \"segwit\" deployment using bit 1, between November 15th 2016 and November 15th 2017 to activate BIP141, BIP143 and BIP147.\n\n==Motivation==\n\nSegwit increases the blocksize, fixes transaction malleability, and makes scripting easier to upgrade as well as bringing many other [https://bitcoincore.org/en/2016/01/26/segwit-benefits/ benefits].\n\nIt is hoped that miners will respond to this BIP by activating segwit early, before this BIP takes effect. Otherwise this BIP will cause the mandatory activation of the existing segwit deployment before the end of midnight November 15th 2017.\n\n==Specification==\n\nAll times are specified according to median past time.\n\nThis BIP will be active between midnight August 1st 2017 (epoch time 1501545600) and midnight November 15th 2017 (epoch time 1510704000) if the existing segwit deployment is not locked-in or activated before epoch time 1501545600. This BIP will cease to be active when segwit is locked-in.\n\nWhile this BIP is active, all blocks must set the nVersion header top 3 bits to 001 together with bit field (1<<1) (according to the existing segwit deployment). Blocks that do not signal as required will be rejected.\n\n=== Reference implementation ===\n\n
\n// Check if Segregated Witness is Locked In\nbool IsWitnessLockedIn(const CBlockIndex* pindexPrev, const Consensus::Params& params)\n{\n    LOCK(cs_main);\n    return (VersionBitsState(pindexPrev, params, Consensus::DEPLOYMENT_SEGWIT, versionbitscache) == THRESHOLD_LOCKED_IN);\n}\n\n// BIP148 mandatory segwit signalling.\nint64_t nMedianTimePast = pindex->GetMedianTimePast();\nif ( (nMedianTimePast >= 1501545600) &&  // Tue 01 Aug 2017 00:00:00 UTC\n     (nMedianTimePast <= 1510704000) &&  // Wed 15 Nov 2017 00:00:00 UTC\n     (!IsWitnessLockedIn(pindex->pprev, chainparams.GetConsensus()) &&  // Segwit is not locked in\n      !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus())) )   // and is not active.\n{\n    bool fVersionBits = (pindex->nVersion & VERSIONBITS_TOP_MASK) == VERSIONBITS_TOP_BITS;\n    bool fSegbit = (pindex->nVersion & VersionBitsMask(chainparams.GetConsensus(), Consensus::DEPLOYMENT_SEGWIT)) != 0;\n    if (!(fVersionBits && fSegbit)) {\n        return state.DoS(0, error(\"ConnectBlock(): relayed block must signal for segwit, please upgrade\"), REJECT_INVALID, \"bad-no-segwit\");\n    }\n}\n
\n\nhttps://github.com/bitcoin/bitcoin/compare/master...shaolinfry:bip-segwit-flagday\n\n==Backwards Compatibility==\n\nThis deployment is compatible with the existing \"segwit\" bit 1 deployment scheduled between midnight November 15th, 2016 and midnight November 15th, 2017.\n\n==Rationale==\n\nHistorically, the P2SH soft fork (BIP16) was activated using a predetermined flag day where nodes began enforcing the new rules. P2SH was successfully activated with relatively few issues\n\nBy orphaning non-signalling blocks during the last month of the BIP9 bit 1 \"segwit\" deployment, this BIP can cause the existing \"segwit\" deployment to activate without needing to release a new deployment.\n\n==References==\n\n*[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013714.html Mailing list discussion]\n*[https://github.com/bitcoin/bitcoin/blob/v0.6.0/src/main.cpp#L1281-L1283 P2SH flag day activation]\n*[[bip-0009.mediawiki|BIP9 Version bits with timeout and delay]]\n*[[bip-0016.mediawiki|BIP16 Pay to Script Hash]]\n*[[bip-0141.mediawiki|BIP141 Segregated Witness (Consensus layer)]]\n*[[bip-0143.mediawiki|BIP143 Transaction Signature Verification for Version 0 Witness Program]]\n*[[bip-0147.mediawiki|BIP147 Dealing with dummy stack element malleability]]\n*[https://bitcoincore.org/en/2016/01/26/segwit-benefits/ Segwit benefits]\n\n==Copyright==\n\nThis document is dual licensed as BSD 3-clause, and Creative Commons CC0 1.0 Universal.", "category": "bips" }, { "instruction": "What are the best practices for 
?",
    "input": "",
    "output": "BIP: 123\n  Title: BIP Classification\n  Authors: Eric Lombrozo \n  Status: Deployed\n  Type: Process\n  Assigned: 2015-08-26\n  License: CC0-1.0 OR FSFAP\n
\n\n==Abstract==\n\nThis document describes a classification scheme for BIPs.\n\nBIPs are classified by system layers with lower numbered layers involving more intricate interoperability requirements.\n\nThe specification defines the layers and sets forth specific criteria for deciding to which layer a particular standards BIP belongs.\n\n==Copyright==\n\nThis BIP is dual-licensed under the Creative Commons CC0 1.0 Universal and FSF All Permissive licenses.\n\n==Motivation==\n\nBitcoin is a system involving a number of different standards. Some standards are absolute requirements for interoperability while others can be considered optional, giving implementers a choice of whether to support them.\n\nIn order to have a BIP process which more closely reflects the interoperability requirements, it is necessary to categorize BIPs accordingly. Lower layers present considerably greater challenges in getting standards accepted and deployed.\n\n==Specification==\n\nStandards BIPs are placed in one of four layers:", "category": "bips" }, { "instruction": "Walk me through setting up Applications step by step", "input": "", "output": "Non-standards BIPs may be placed in these layers, or none at all.\n\n===1. Consensus Layer===\n\nThe consensus layer defines cryptographic commitment structures. Its purpose is ensuring that anyone can locally evaluate whether a particular state and history is valid, providing settlement guarantees, and assuring eventual convergence.\n\nThe consensus layer is not concerned with how messages are propagated on a network.\n\nDisagreements over the consensus layer can result in network partitioning, or forks, where different nodes might end up accepting different incompatible histories. We further subdivide consensus layer changes into soft forks and hard forks.\n\n====Soft Forks====\n\nIn a soft fork, some structures that were valid under the old rules are no longer valid under the new rules. Structures that were invalid under the old rules continue to be invalid under the new rules.\n\n====Hard Forks====\n\nIn a hard fork, structures that were invalid under the old rules become valid under the new rules.\n\n===2. Peer Services Layer===\n\nThe peer services layer specifies how nodes find each other and propagate messages.\n\nOnly a subset of all specified peer services are required for basic node interoperability. Nodes can support further optional extensions.\n\nIt is always possible to add new services without breaking compatibility with existing services, then gradually deprecate older services. In this manner, the entire network can be upgraded without serious risks of service disruption.\n\n===3. API/RPC Layer===\n\nThe API/RPC layer specifies higher level calls accessible to applications. Support for these BIPs is not required for basic network interoperability but might be expected by some client applications.\n\nThere's room at this layer to allow for competing standards without breaking basic network interoperability.\n\n===4. Applications Layer===\n\nThe applications layer specifies high level structures, abstractions, and conventions that allow different applications to support similar features and share data.\n\n==Classification of existing BIPs==\n\n{| class=\"wikitable sortable\" style=\"width: auto; text-align: center; font-size: smaller; table-layout: fixed;\"\n!Number\n!Layer\n!Title\n!Owner\n!Type\n!Status\n|- style=\"background-color: #cfffcf\"\n| [[bip-0001.mediawiki|1]]\n|\n| BIP Purpose and Guidelines\n| Amir Taaki\n| Process\n| Active\n|-\n| [[bip-0002.mediawiki|2]]\n|\n| BIP process, revised\n| Luke Dashjr\n| Process\n| Draft\n|- style=\"background-color: #cfffcf\"\n| [[bip-0009.mediawiki|9]]\n|\n| Version bits with timeout and delay\n| Pieter Wuille, Peter Todd, Greg Maxwell, Rusty Russell\n| Informational\n| Final\n|- style=\"background-color: #ffcfcf\"\n| [[bip-0010.mediawiki|10]]\n| Applications\n| Multi-Sig Transaction Distribution\n| Alan Reiner\n| Informational\n| Withdrawn\n|- style=\"background-color: #cfffcf\"\n| [[bip-0011.mediawiki|11]]\n| Applications\n| M-of-N Standard Transactions\n| Gavin Andresen\n| Standard\n| Final\n|- style=\"background-color: #ffcfcf\"\n| [[bip-0012.mediawiki|12]]\n| Consensus (soft fork)\n| OP_EVAL\n| Gavin Andresen\n| Standard\n| Withdrawn\n|- style=\"background-color: #cfffcf\"\n| [[bip-0013.mediawiki|13]]\n| Applications\n| Address Format for pay-to-script-hash\n| Gavin Andresen\n| Standard\n| Final\n|- style=\"background-color: #cfffcf\"\n| [[bip-0014.mediawiki|14]]\n| Peer Services\n| Protocol Version and User Agent\n| Amir Taaki, Patrick Strateman\n| Standard\n| Final\n|-\n| [[bip-0015.mediawiki|15]]\n| Applications\n| Aliases\n| Amir Taaki\n| Standard\n| Deferred\n|- style=\"background-color: #cfffcf\"\n| [[bip-0016.mediawiki|16]]\n| Consensus (soft fork)\n| Pay to Script Hash\n| Gavin Andresen\n| Standard\n| Final\n|- style=\"background-color: #ffcfcf\"\n| [[bip-0017.mediawiki|17]]\n| Consensus (soft fork)\n| OP_CHECKHASHVERIFY (CHV)\n| Luke Dashjr\n| Standard\n| Withdrawn\n|- style=\"background-color: #ffffcf\"\n| [[bip-0018.mediawiki|18]]\n| Consensus (soft fork)\n| hashScriptCheck\n| Luke Dashjr\n| Standard\n| Accepted\n|-\n| [[bip-0019.mediawiki|19]]\n| Applications\n| M-of-N Standard Transactions (Low SigOp)\n| Luke Dashjr\n| Standard\n| Draft\n|- style=\"background-color: #ffcfcf\"\n| [[bip-0020.mediawiki|20]]\n| Applications\n| URI Scheme\n| Luke Dashjr\n| Standard\n| Replaced\n|- style=\"background-color: #cfffcf\"\n| [[bip-0021.mediawiki|21]]\n| Applications\n| URI Scheme\n| Nils Schneider, Matt Corallo\n| Standard\n| Final\n|- style=\"background-color: #cfffcf\"\n| [[bip-0022.mediawiki|22]]\n| API/RPC\n| getblocktemplate - Fundamentals\n| Luke Dashjr\n| Standard\n| Final\n|- style=\"background-color: #cfffcf\"\n| [[bip-0023.mediawiki|23]]\n| API/RPC\n| getblocktemplate - Pooled Mining\n| Luke Dashjr\n| Standard\n| Final\n|- style=\"background-color: #cfffcf\"\n| [[bip-0030.mediawiki|30]]\n| Consensus (soft fork)\n| Duplicate transactions\n| Pieter Wuille\n| Standard\n| Final\n|- style=\"background-color: #cfffcf\"\n| [[bip-0031.mediawiki|31]]\n| Peer Services\n| Pong message\n| Mike Hearn\n| Standard\n| Final\n|- style=\"background-color: #cfffcf\"\n| [[bip-0032.mediawiki|32]]\n| Applications\n| Hierarchical Deterministic Wallets\n| Pieter Wuille\n| Informational\n| Final\n|-\n| [[bip-0033.mediawiki|33]]\n| Peer Services\n| Stratized Nodes\n| Amir Taaki\n| Standard\n| Draft\n|- style=\"background-color: #cfffcf\"\n| [[bip-0034.mediawiki|34]]\n| Consensus (soft fork)\n| Block v2, Height in Coinbase\n| Gavin Andresen\n| Standard\n| Final\n|- style=\"background-color: #cfffcf\"\n| [[bip-0035.mediawiki|35]]\n| Peer Services\n| mempool message\n| Jeff Garzik\n| Standard\n| Final\n|-\n| [[bip-0036.mediawiki|36]]\n| Peer Services\n| Custom Services\n| Stefan Thomas\n| Standard\n| Draft\n|- style=\"background-color: #cfffcf\"\n| [[bip-0037.mediawiki|37]]\n| Peer Services\n| Connection Bloom filtering\n| Mike Hearn, Matt Corallo\n| Standard\n| Final\n|-\n| [[bip-0038.mediawiki|38]]\n| Applications\n| Passphrase-protected private key\n| Mike Caldwell, Aaron Voisine\n| Standard\n| Draft\n|- style=\"background-color: #ffffcf\"\n| [[bip-0039.mediawiki|39]]\n| Applications\n| Mnemonic code for generating deterministic keys\n| Marek Palatinus, Pavol Rusnak, Aaron Voisine, Sean Bowe\n| Standard\n| Accepted\n|-\n| [[bip-0042.mediawiki|42]]\n| Consensus (soft fork)\n| A finite monetary supply for Bitcoin\n| Pieter Wuille\n| Standard\n| Draft\n|-\n| [[bip-0043.mediawiki|43]]\n| Applications\n| Purpose Field for Deterministic Wallets\n| Marek Palatinus, Pavol Rusnak\n| Informational\n| Draft\n|- style=\"background-color: #ffffcf\"\n| [[bip-0044.mediawiki|44]]\n| Applications\n| Multi-Account Hierarchy for Deterministic Wallets\n| Marek Palatinus, Pavol Rusnak\n| Standard\n| Accepted\n|- style=\"background-color: #ffffcf\"\n| [[bip-0045.mediawiki|45]]\n| Applications\n| Structure for Deterministic P2SH Multisignature Wallets\n| Manuel Araoz, Ryan X. Charles, Matias Alejo Garcia\n| Standard\n| Accepted\n|-\n| [[bip-0047.mediawiki|47]]\n| Applications\n| Reusable Payment Codes for Hierarchical Deterministic Wallets\n| Justus Ranvier\n| Informational\n| Draft\n|-\n| [[bip-0049.mediawiki|49]]\n| Applications\n| Derivation scheme for P2WPKH-nested-in-P2SH based accounts\n| Daniel Weigl\n| Informational\n| Draft\n|- style=\"background-color: #cfffcf\"\n| [[bip-0050.mediawiki|50]]\n|\n| March 2013 Chain Fork Post-Mortem\n| Gavin Andresen\n| Informational\n| Final\n|-\n| [[bip-0060.mediawiki|60]]\n| Peer Services\n| Fixed Length \"version\" Message (Relay-Transactions Field)\n| Amir Taaki\n| Standard\n| Draft\n|- style=\"background-color: #cfffcf\"\n| [[bip-0061.mediawiki|61]]\n| Peer Services\n| Reject P2P message\n| Gavin Andresen\n| Standard\n| Final\n|- style=\"background-color: #ffcfcf\"\n| [[bip-0062.mediawiki|62]]\n| Consensus (soft fork)\n| Dealing with malleability\n| Pieter Wuille\n| Standard\n| Withdrawn\n|-\n| [[bip-0064.mediawiki|64]]\n| Peer Services\n| getutxo message\n| Mike Hearn\n| Standard\n| Draft\n|- style=\"background-color: #cfffcf\"\n| [[bip-0065.mediawiki|65]]\n| Consensus (soft fork)\n| OP_CHECKLOCKTIMEVERIFY\n| Peter Todd\n| Standard\n| Final\n|- style=\"background-color: #cfffcf\"\n| [[bip-0066.mediawiki|66]]\n| Consensus (soft fork)\n| Strict DER signatures\n| Pieter Wuille\n| Standard\n| Final\n|- style=\"background-color: #ffffcf\"\n| [[bip-0067.mediawiki|67]]\n| Applications\n| Deterministic Pay-to-script-hash multi-signature addresses through public key sorting\n| Thomas Kerin, Jean-Pierre Rupp, Ruben de Vries\n| Standard\n| Accepted\n|- style=\"background-color: #cfffcf\"\n| [[bip-0068.mediawiki|68]]\n| Consensus (soft fork)\n| Relative lock-time using consensus-enforced sequence numbers\n| Mark Friedenbach, BtcDrak, Nicolas Dorier, kinoshitajona\n| Standard\n| Final\n|- style=\"background-color: #ffffcf\"\n| [[bip-0069.mediawiki|69]]\n| Applications\n| Lexicographical Indexing of Transaction Inputs and Outputs\n| Kristov Atlas\n| Informational\n| Accepted\n|- style=\"background-color: #cfffcf\"\n| [[bip-0070.mediawiki|70]]\n| Applications\n| Payment Protocol\n| Gavin Andresen, Mike Hearn\n| Standard\n| Final\n|- style=\"background-color: #cfffcf\"\n| [[bip-0071.mediawiki|71]]\n| Applications\n| Payment Protocol MIME types\n| Gavin Andresen\n| Standard\n| Final\n|- style=\"background-color: #cfffcf\"\n| [[bip-0072.mediawiki|72]]\n| Applications\n| bitcoin: uri extensions for Payment Protocol\n| Gavin Andresen\n| Standard\n| Final\n|- style=\"background-color: #cfffcf\"\n| [[bip-0073.mediawiki|73]]\n| Applications\n| Use \"Accept\" header for response type negotiation with Payment Request URLs\n| Stephen Pair\n| Standard\n| Final\n|-\n| [[bip-0074.mediawiki|74]]\n| Applications\n| Allow zero value OP_RETURN in Payment Protocol\n| Toby Padilla\n| Standard\n| Draft\n|-\n| [[bip-0075.mediawiki|75]]\n| Applications\n| Out of Band Address Exchange using Payment Protocol Encryption\n| Justin Newton, Matt David, Aaron Voisine, James MacWhyte\n| Standard\n| Draft\n|-\n| [[bip-0080.mediawiki|80]]\n|\n| Hierarchy for Non-Colored Voting Pool Deterministic Multisig Wallets\n| Justus Ranvier, Jimmy Song\n| Informational\n| Deferred\n|-\n| [[bip-0081.mediawiki|81]]\n|\n| Hierarchy for Colored Voting Pool Deterministic Multisig Wallets\n| Justus Ranvier, Jimmy Song\n| Informational\n| Deferred\n|-\n| [[bip-0083.mediawiki|83]]\n| Applications\n| Dynamic Hierarchical Deterministic Key Trees\n| Eric Lombrozo\n| Standard\n| Draft\n|-\n| [[bip-0099.mediawiki|99]]\n|\n| Motivation and deployment of consensus rule changes ([soft/hard]forks)\n| Jorge Timón\n| Informational\n| Draft\n|- style=\"background-color: #ffcfcf\"\n| [[bip-0101.mediawiki|101]]\n| Consensus (hard fork)\n| Increase maximum block size\n| Gavin Andresen\n| Standard\n| Withdrawn\n|-\n| [[bip-0102.mediawiki|102]]\n| Consensus (hard fork)\n| Block size increase to 2MB\n| Jeff Garzik\n| Standard\n| Draft\n|-\n| [[bip-0103.mediawiki|103]]\n| Consensus (hard fork)\n| Block size following technological growth\n| Pieter Wuille\n| Standard\n| Draft\n|-\n| [[bip-0105.mediawiki|105]]\n| Consensus (hard fork)\n| Consensus based block size retargeting algorithm\n| BtcDrak\n| Standard\n| Draft\n|-\n| [[bip-0106.mediawiki|106]]\n| Consensus (hard fork)\n| Dynamically Controlled Bitcoin Block Size Max Cap\n| Upal Chakraborty\n| Standard\n| Draft\n|-\n| [[bip-0107.mediawiki|107]]\n| Consensus (hard fork)\n| Dynamic limit on the block size\n| Washington Y. Sanchez\n| Standard\n| Draft\n|-\n| [[bip-0109.mediawiki|109]]\n| Consensus (hard fork)\n| Two million byte size limit with sigop and sighash limits\n| Gavin Andresen\n| Standard\n| Draft\n|- style=\"background-color: #ffffcf\"\n| [[bip-0111.mediawiki|111]]\n| Peer Services\n| NODE_BLOOM service bit\n| Matt Corallo, Peter Todd\n| Standard\n| Accepted\n|- style=\"background-color: #cfffcf\"\n| [[bip-0112.mediawiki|112]]\n| Consensus (soft fork)\n| CHECKSEQUENCEVERIFY\n| BtcDrak, Mark Friedenbach, Eric Lombrozo\n| Standard\n| Final\n|- style=\"background-color: #cfffcf\"\n| [[bip-0113.mediawiki|113]]\n| Consensus (soft fork)\n| Median time-past as endpoint for lock-time calculations\n| Thomas Kerin, Mark Friedenbach\n| Standard\n| Final\n|-\n| [[bip-0114.mediawiki|114]]\n| Consensus (soft fork)\n| Merkelized Abstract Syntax Tree\n| Johnson Lau\n| Standard\n| Draft\n|-\n| [[bip-0120.mediawiki|120]]\n| Applications\n| Proof of Payment\n| Kalle Rosenbaum\n| Standard\n| Draft\n|-\n| [[bip-0121.mediawiki|121]]\n| Applications\n| Proof of Payment URI scheme\n| Kalle Rosenbaum\n| Standard\n| Draft\n|-\n| [[bip-0122.mediawiki|122]]\n| Applications\n| URI scheme for Blockchain references / exploration\n| Marco Pontello\n| Standard\n| Draft\n|-\n| [[bip-0123.mediawiki|123]]\n|\n| BIP Classification\n| Eric Lombrozo\n| Process\n| Draft\n|-\n| [[bip-0124.mediawiki|124]]\n| Applications\n| Hierarchical Deterministic Script Templates\n| Eric Lombrozo, William Swanson\n| Informational\n| Draft\n|- style=\"background-color: #ffffcf\"\n| [[bip-0125.mediawiki|125]]\n| Applications\n| Opt-in Full Replace-by-Fee Signaling\n| David A. Harding, Peter Todd\n| Standard\n| Accepted\n|-\n| [[bip-0126.mediawiki|126]]\n|\n| Best Practices for Heterogeneous Input Script Transactions\n| Kristov Atlas\n| Informational\n| Draft\n|- style=\"background-color: #ffffcf\"\n| [[bip-0130.mediawiki|130]]\n| Peer Services\n| sendheaders message\n| Suhas Daftuar\n| Standard\n| Accepted\n|-\n| [[bip-0131.mediawiki|131]]\n| Consensus (hard fork)\n| \"Coalescing Transaction\" Specification (wildcard inputs)\n| Chris Priest\n| Standard\n| Draft\n|- style=\"background-color: #ffcfcf\"\n| [[bip-0132.mediawiki|132]]\n|\n| Committee-based BIP Acceptance Process\n| Andy Chase\n| Process\n| Withdrawn\n|-\n| [[bip-0133.mediawiki|133]]\n| Peer Services\n| feefilter message\n| Alex Morcos\n| Standard\n| Draft\n|-\n| [[bip-0134.mediawiki|134]]\n| Consensus (hard fork)\n| Flexible Transactions\n| Tom Zander\n| Standard\n| Draft\n|-\n| [[bip-0140.mediawiki|140]]\n| Consensus (soft fork)\n| Normalized TXID\n| Christian Decker\n| Standard\n| Draft\n|-\n| [[bip-0141.mediawiki|141]]\n| Consensus (soft fork)\n| Segregated Witness (Consensus layer)\n| Eric Lombrozo, Johnson Lau, Pieter Wuille\n| Standard\n| Draft\n|-\n| [[bip-0142.mediawiki|142]]\n| Applications\n| Address Format for Segregated Witness\n| Johnson Lau\n| Standard\n| Deferred\n|-\n| [[bip-0143.mediawiki|143]]\n| Consensus (soft fork)\n| Transaction Signature Verification for Version 0 Witness Program\n| Johnson Lau, Pieter Wuille\n| Standard\n| Draft\n|-\n| [[bip-0144.mediawiki|144]]\n| Peer Services\n| Segregated Witness (Peer Services)\n| Eric Lombrozo, Pieter Wuille\n| Standard\n| Draft\n|-\n| [[bip-0145.mediawiki|145]]\n| API/RPC\n| getblocktemplate Updates for Segregated Witness\n| Luke Dashjr\n| Standard\n| Draft\n|-\n| [[bip-0146.mediawiki|146]]\n| Consensus (soft fork)\n| Dealing with signature encoding malleability\n| Johnson Lau, Pieter Wuille\n| Standard\n| Draft\n|-\n| [[bip-0147.mediawiki|147]]\n| Consensus (soft fork)\n| Dealing with dummy stack element malleability\n| Johnson Lau\n| Standard\n| Draft\n|-\n| [[bip-0150.mediawiki|150]]\n| Peer Services\n| Peer Authentication\n| Jonas Schnelli\n| Standard\n| Draft\n|-\n| [[bip-0151.mediawiki|151]]\n| Peer Services\n| Peer-to-Peer Communication Encryption\n| Jonas Schnelli\n| Standard\n| Draft\n|-\n| [[bip-0152.mediawiki|152]]\n| Peer Services\n| Compact Block Relay\n| Matt Corallo\n| Standard\n| Draft\n|}", "category": "bips" }, { "instruction": "What commands would you run to work with 
?",
    "input": "",
    "output": "BIP: 84\n  Layer: Applications\n  Title: Derivation scheme for P2WPKH based accounts\n  Authors: Pavol Rusnak \n  Comments-Summary: No comments yet.\n  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0084\n  Status: Deployed\n  Type: Specification\n  Assigned: 2017-12-28\n  License: CC0-1.0\n
\n\n==Abstract==\n\nThis BIP defines the derivation scheme for HD wallets using the P2WPKH ([[bip-0173.mediawiki|BIP 173]]) serialization format for segregated witness transactions.\n\n==Motivation==\n\nWith the usage of P2WPKH transactions it is necessary to have a common derivation scheme.\nIt allows the user to use different HD wallets with the same masterseed and/or a single account seamlessly.\n\nThus the user needs to create dedicated segregated witness accounts, which ensures that only wallets compatible with this BIP will detect the accounts and handle them appropriately.\n\n===Considerations===\n\nWe use the same rationale as described in Considerations section of [[bip-0049.mediawiki|BIP 49]].\n\n==Specifications==\n\nThis BIP defines the two needed steps to derive multiple deterministic addresses based on a [[bip-0032.mediawiki|BIP 32]] root account.\n\n===Public key derivation===\n\nTo derive a public key from the root account, this BIP uses the same account-structure as defined in [[bip-0044.mediawiki|BIP 44]] and [[bip-0049.mediawiki|BIP 49]], but only uses a different purpose value to indicate the different transaction serialization method.\n\n
\nm / purpose' / coin_type' / account' / change / address_index\n
\n\nFor the purpose-path level it uses 84'. The rest of the levels are used as defined in BIP44 or BIP49.\n\n\n===Address derivation===\n\nTo derive the P2WPKH address from the above calculated public key, we use the encapsulation defined in [[bip-0141.mediawiki#p2wpkh|BIP 141]]:\n\n\n witness: \n scriptSig: (empty)\n scriptPubKey: 0 <20-byte-key-hash>\n (0x0014{20-byte-key-hash})\n\n\n===Extended Key Version===\n\nWhen serializing extended keys, this scheme uses alternate version bytes. Extended public keys use 0x04b24746 to produce a \"zpub\" prefix, and private keys use 0x04b2430c to produce a \"zprv\" prefix. Testnet uses 0x045f1cf6 \"vpub\" and 0x045f18bc \"vprv.\"\n\nAdditional registered version bytes are listed in [[https://github.com/satoshilabs/slips/blob/master/slip-0132.md|SLIP-0132]].\n\n\n==Backwards Compatibility==\n\nThis BIP is not backwards compatible by design as described under [[#considerations|considerations]]. An incompatible wallet will not discover accounts at all and the user will notice that something is wrong.\n\n==Test vectors==\n\n
\n  mnemonic = abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon about\n  rootpriv = zprvAWgYBBk7JR8Gjrh4UJQ2uJdG1r3WNRRfURiABBE3RvMXYSrRJL62XuezvGdPvG6GFBZduosCc1YP5wixPox7zhZLfiUm8aunE96BBa4Kei5\n  rootpub  = zpub6jftahH18ngZxLmXaKw3GSZzZsszmt9WqedkyZdezFtWRFBZqsQH5hyUmb4pCEeZGmVfQuP5bedXTB8is6fTv19U1GQRyQUKQGUTzyHACMF\n\n  // Account 0, root = m/84'/0'/0'\n  xpriv = zprvAdG4iTXWBoARxkkzNpNh8r6Qag3irQB8PzEMkAFeTRXxHpbF9z4QgEvBRmfvqWvGp42t42nvgGpNgYSJA9iefm1yYNZKEm7z6qUWCroSQnE\n  xpub  = zpub6rFR7y4Q2AijBEqTUquhVz398htDFrtymD9xYYfG1m4wAcvPhXNfE3EfH1r1ADqtfSdVCToUG868RvUUkgDKf31mGDtKsAYz2oz2AGutZYs\n\n  // Account 0, first receiving address = m/84'/0'/0'/0/0\n  privkey = KyZpNDKnfs94vbrwhJneDi77V6jF64PWPF8x5cdJb8ifgg2DUc9d\n  pubkey  = 0330d54fd0dd420a6e5f8d3624f5f3482cae350f79d5f0753bf5beef9c2d91af3c\n  address = bc1qcr8te4kr609gcawutmrza0j4xv80jy8z306fyu\n\n  // Account 0, second receiving address = m/84'/0'/0'/0/1\n  privkey = Kxpf5b8p3qX56DKEe5NqWbNUP9MnqoRFzZwHRtsFqhzuvUJsYZCy\n  pubkey  = 03e775fd51f0dfb8cd865d9ff1cca2a158cf651fe997fdc9fee9c1d3b5e995ea77\n  address = bc1qnjg0jd8228aq7egyzacy8cys3knf9xvrerkf9g\n\n  // Account 0, first change address = m/84'/0'/0'/1/0\n  privkey = KxuoxufJL5csa1Wieb2kp29VNdn92Us8CoaUG3aGtPtcF3AzeXvF\n  pubkey  = 03025324888e429ab8e3dbaf1f7802648b9cd01e9b418485c5fa4c1b9b5700e1a6\n  address = bc1q8c6fshw2dlwun7ekn9qwf37cu2rn755upcp6el\n
\n\n==Reference==\n\n* [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]]\n* [[bip-0043.mediawiki|BIP43 - Purpose Field for Deterministic Wallets]]\n* [[bip-0044.mediawiki|BIP44 - Multi-Account Hierarchy for Deterministic Wallets]]\n* [[bip-0049.mediawiki|BIP49 - Derivation scheme for P2WPKH-nested-in-P2SH based accounts]]\n* [[bip-0141.mediawiki|BIP141 - Segregated Witness (Consensus layer)]]\n* [[bip-0173.mediawiki|BIP173 - Base32 address format for native v0-16 witness outputs]]", "category": "bips" }, { "instruction": "I want to understand 
 from a technical perspective",
    "input": "",
    "output": "BIP: 157\n  Layer: Peer Services\n  Title: Client Side Block Filtering\n  Authors: Olaoluwa Osuntokun \n           Alex Akselrod \n           Jim Posen \n  Status: Deployed\n  Type: Specification\n  Assigned: 2017-05-24\n  License: CC0-1.0\n  Requires: 158\n
\n\n\n== Abstract ==\n\nThis BIP describes a new light client protocol in Bitcoin that improves upon\ncurrently available options. The standard light client protocol in use today,\ndefined in BIP\n37https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki, has\nknown flaws that weaken the security and privacy of clients and allow\ndenial-of-service attack vectors on full\nnodeshttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-May/012636.html.\nThe new protocol overcomes these issues by allowing light clients to obtain\ncompact probabilistic filters of block content from full nodes and download full\nblocks if the filter matches relevant data.\n\nNew P2P messages empower light clients to securely sync the blockchain without\nrelying on a trusted source. This BIP also defines a filter header, which serves\nas a commitment to all filters for previous blocks and provides the ability to\nefficiently detect malicious or faulty peers serving invalid filters. The\nresulting protocol guarantees that light clients with at least one honest peer\nare able to identify the correct block filters.\n\n== Motivation ==\n\nBitcoin light clients allow applications to read relevant transactions from the\nblockchain without incurring the full cost of downloading and validating all\ndata. Such applications seek to simultaneously minimize the trust in peers and\nthe amount of bandwidth, storage space, and computation required. They achieve\nthis by downloading all block headers, verifying the proofs of work, and\nfollowing the longest proof-of-work chain. Since block headers are a fixed\n80-bytes and are generated every 10 minutes on average, the bandwidth required\nto sync the block headers is minimal. Light clients then download only the\nblockchain data relevant to them directly from peers and validate inclusion in\nthe header chain. Though clients do not check the validity of all blocks in the\nlongest proof-of-work chain, they rely on miner incentives for security.\n\nBIP 37 is currently the most widely used light client execution mode for\nBitcoin. With BIP 37, a client sends a Bloom filter it wants to watch to a full\nnode peer, then receives notifications for each new transaction or block that\nmatches the filter. The client then requests relevant transactions from the peer\nalong with Merkle proofs of inclusion in the blocks containing them, which are\nverified against the block headers. The Bloom filters match data such as client\naddresses and unspent outputs, and the filter size must be carefully tuned to\nbalance the false positive rate with the amount of information leaked to peer. It\nhas been shown, however, that most implementations available offer virtually\n''zero privacy'' to wallets and other\napplicationshttps://eprint.iacr.org/2014/763.pdfhttps://jonasnick.github.io/blog/2015/02/12/privacy-in-bitcoinj/.\nAdditionally, malicious full nodes serving light clients can omit critical data\nwith little risk of detection, which is unacceptable for some applications\n(such as Lightning Network clients) that must respond to certain on-chain\nevents. Finally, honest nodes servicing BIP 37 light clients may incur\nsignificant I/O and CPU resource usage due to maliciously crafted Bloom filters,\ncreating a denial-of-service (DoS) vector and disincentizing node operators from\nsupporting the\nprotocolhttps://github.com/bitcoin/bips/blob/master/bip-0111.mediawiki.\n\nThe alternative detailed in this document can be seen as the opposite of BIP 37:\ninstead of the client sending a filter to a full node peer, full nodes generate\ndeterministic filters on block data that are served to the client. A light\nclient can then download an entire block if the filter matches the data it is\nwatching for. Since filters are deterministic, they only need to be constructed\nonce and stored on disk, whenever a new block is connected to the chain. This\nkeeps the computation required to serve filters minimal, and eliminates the I/O\nasymmetry that makes BIP 37 enabled nodes vulnerable. Clients also get better\nassurance of seeing all relevant transactions because they can check the\nvalidity of filters received from peers more easily than they can check\ncompleteness of filtered blocks. Finally, client privacy is improved because\nblocks can be downloaded from ''any source'', so that no one peer gets complete\ninformation on the data required by a client. Extremely privacy conscious light\nclients may opt to anonymously fetch blocks using advanced techniques such a\nPrivate Information\nRetrievalhttps://en.wikipedia.org/wiki/Private_information_retrieval.\n\n== Definitions ==\n\n[]byte represents a vector of bytes.\n\n[N]byte represents a fixed-size byte array with length N.\n\n''CompactSize'' is a compact encoding of unsigned integers used in the Bitcoin\nP2P protocol.\n\n''double-SHA256'' is a hash algorithm defined by two invocations of SHA-256:\ndouble-SHA256(x) = SHA256(SHA256(x)).\n\nThe key words \"MUST\", \"MUST NOT\", \"REQUIRED\", \"SHALL\", \"SHALL NOT\", \"SHOULD\",\n\"SHOULD NOT\", \"RECOMMENDED\", \"MAY\", and \"OPTIONAL\" in this document are to be\ninterpreted as described in RFC 2119.\n\n== Specification ==\n\n=== Filter Types ===\n\nFor the sake of future extensibility and reducing filter sizes, there are\nmultiple ''filter types'' that determine which data is included in a block\nfilter as well as the method of filter construction/querying. In this model,\nfull nodes generate one filter per block per filter type supported.\n\nEach type is identified by a one byte code, and specifies the contents and\nserialization format of the filter. A full node MAY signal support for\nparticular filter types using service bits. The initial filter types are defined\nseparately in [[bip-0158.mediawiki|BIP 158]], and one service bit is allocated\nto signal support for them.\n\n=== Filter Headers ===\n\nThis proposal draws inspiration from the headers-first mechanism that Bitcoin\nnodes use to sync the block\nchainhttps://bitcoin.org/en/developer-guide#headers-first. Similar to\nhow block headers have a Merkle commitment to all transaction data in the block,\nwe define filter headers that have commitments to the block filters. Also like\nblock headers, filter headers each have a commitment to the preceding one.\nBefore downloading the block filters themselves, a light client can download all\nfilter headers for the current block chain and use them to verify the\nauthenticity of the filters. If the filter header chains differ between multiple\npeers, the client can identify the point where they diverge, then download the\nfull block and compute the correct filter, thus identifying which peer is\nfaulty.\n\nThe canonical hash of a block filter is the double-SHA256 of the serialized\nfilter. Filter headers are 32-byte hashes derived for each block filter. They\nare computed as the double-SHA256 of the concatenation of the filter hash with\nthe previous filter header. The previous filter header used to calculate that of\nthe genesis block is defined to be the 32-byte array of 0's.\n\n=== New Messages ===\n\n==== getcfilters ====\ngetcfilters is used to request the compact filters of a particular\ntype for a particular range of blocks. The message contains the following\nfields:\n\n{| class=\"wikitable\"\n! Field Name\n! Data Type\n! Byte Size\n! Description\n|-\n| FilterType\n| byte\n| 1\n| Filter type for which headers are requested\n|-\n| StartHeight\n| uint32\n| 4\n| The height of the first block in the requested range\n|-\n| StopHash\n| [32]byte\n| 32\n| The hash of the last block in the requested range\n|}", "category": "bips" }, { "instruction": "Can you explain Bitcoin Operations Guide like we're having a beer and talking Bitcoin?", "input": "", "output": "# Nodes SHOULD NOT send getcfilters unless the peer has signaled support for this filter type. Nodes receiving getcfilters with an unsupported filter type SHOULD NOT respond.", "category": "bips" }, { "instruction": "How would you explain Bitcoin Operations Guide to someone who knows Bitcoin basics?", "input": "", "output": "# StopHash MUST be known to belong to a block accepted by the receiving peer. This is the case if the peer had previously sent a headers or inv message with that block or any descendents. A node that receives getcfilters with an unknown StopHash SHOULD NOT respond.", "category": "bips" }, { "instruction": "I'm trying to understand Bitcoin Operations Guide - can you walk me through it?", "input": "", "output": "# The height of the block with hash StopHash MUST be greater than or equal to StartHeight, and the difference MUST be strictly less than 1000.", "category": "bips" }, { "instruction": "Hey, I need to set up The receiving node MUST respond to valid requests by sending one cfilter message for each block in the requested range, sequentially in order by block height. - what's the command line way to do that?", "input": "", "output": "==== cfilter ====\ncfilter is sent in response to getcfilters, one for\neach block in the requested range. The message contains the following fields:\n\n{| class=\"wikitable\"\n! Field Name\n! Data Type\n! Byte Size\n! Description\n|-\n| FilterType\n| byte\n| 1\n| Byte identifying the type of filter being returned\n|-\n| BlockHash\n| [32]byte\n| 32\n| Block hash of the Bitcoin block for which the filter is being returned\n|-\n| NumFilterBytes\n| CompactSize\n| 1-5\n| A variable length integer representing the size of the filter in the following field\n|-\n| FilterBytes\n| []byte\n| NumFilterBytes\n| The serialized compact filter for this block\n|}", "category": "bips" }, { "instruction": "What's the deal with The FilterType SHOULD match the field in the getcfilters request, and BlockHash must correspond to a block that is an ancestor of StopHash with height greater than or equal to StartHeight. in Bitcoin? Explain it like I'm a friend.", "input": "", "output": "==== getcfheaders ====\ngetcfheaders is used to request verifiable filter headers for a\nrange of blocks. The message contains the following fields:\n\n{| class=\"wikitable\"\n! Field Name\n! Data Type\n! Byte Size\n! Description\n|-\n| FilterType\n| byte\n| 1\n| Filter type for which headers are requested\n|-\n| StartHeight\n| uint32\n| 4\n| The height of the first block in the requested range\n|-\n| StopHash\n| [32]byte\n| 32\n| The hash of the last block in the requested range\n|}", "category": "bips" }, { "instruction": "Can you show me the CLI commands for Bitcoin Operations Guide?", "input": "", "output": "# Nodes SHOULD NOT send getcfheaders unless the peer has signaled support for this filter type. Nodes receiving getcfheaders with an unsupported filter type SHOULD NOT respond.", "category": "bips" }, { "instruction": "I'm stuck with Bitcoin Operations Guide - what should I check?", "input": "", "output": "# StopHash MUST be known to belong to a block accepted by the receiving peer. This is the case if the peer had previously sent a headers or inv message with that block or any descendents. A node that receives getcfheaders with an unknown StopHash SHOULD NOT respond.", "category": "bips" }, { "instruction": "How do I troubleshoot The height of the block with hash StopHash MUST be greater than or equal to StartHeight, and the difference MUST be strictly less than 2,000. issues?", "input": "", "output": "==== cfheaders ====\ncfheaders is sent in response to getcfheaders. Instead\nof including the filter headers themselves, the response includes one filter\nheader and a sequence of filter hashes, from which the headers can be derived.\nThis has the benefit that the client can verify the binding links between the\nheaders. The message contains the following fields:\n\n{| class=\"wikitable\"\n! Field Name\n! Data Type\n! Byte Size\n! Description\n|-\n| FilterType\n| byte\n| 1\n| Filter type for which hashes are requested\n|-\n| StopHash\n| [32]byte\n| 32\n| The hash of the last block in the requested range\n|-\n| PreviousFilterHeader\n| [32]byte\n| 32\n| The filter header preceding the first block in the requested range\n|-\n| FilterHashesLength\n| CompactSize\n| 1-3\n| The length of the following vector of filter hashes\n|-\n| FilterHashes\n| [][32]byte\n| FilterHashesLength * 32\n| The filter hashes for each block in the requested range\n|}", "category": "bips" }, { "instruction": "What are the best practices for Bitcoin Operations Guide?", "input": "", "output": "# FilterHashes MUST have one entry for each block on the chain terminating with tip StopHash, starting with the block at height StartHeight. The entries MUST be the filter hashes of the given type for each block in that range, in ascending order by height.", "category": "bips" }, { "instruction": "Walk me through setting up PreviousFilterHeader MUST be set to the previous filter header of first block in the requested range. step by step", "input": "", "output": "==== getcfcheckpt ====\ngetcfcheckpt is used to request filter headers at evenly spaced\nintervals over a range of blocks. Clients may use filter hashes from\ngetcfheaders to connect these checkpoints, as is described in the\n[[#client-operation|Client Operation]] section below. The\ngetcfcheckpt message contains the following fields:\n\n{| class=\"wikitable\"\n! Field Name\n! Data Type\n! Byte Size\n! Description\n|-\n| FilterType\n| byte\n| 1\n| Filter type for which headers are requested\n|-\n| StopHash\n| [32]byte\n| 32\n| The hash of the last block in the chain that headers are requested for\n|}", "category": "bips" }, { "instruction": "What commands would you run to work with Bitcoin Operations Guide?", "input": "", "output": "# Nodes SHOULD NOT send getcfcheckpt unless the peer has signaled support for this filter type. Nodes receiving getcfcheckpt with an unsupported filter type SHOULD NOT respond.", "category": "bips" }, { "instruction": "I want to understand StopHash MUST be known to belong to a block accepted by the receiving peer. This is the case if the peer had previously sent a headers or inv message with any descendent blocks. A node that receives getcfcheckpt with an unknown StopHash SHOULD NOT respond. from a technical perspective", "input": "", "output": "==== cfcheckpt ====\ncfcheckpt is sent in response to getcfcheckpt. The\nfilter headers included are the set of all filter headers on the requested chain\nwhere the height is a positive multiple of 1,000. The message contains the\nfollowing fields:\n\n{| class=\"wikitable\"\n! Field Name\n! Data Type\n! Byte Size\n! Description\n|-\n| FilterType\n| byte\n| 1\n| Filter type for which headers are requested\n|-\n| StopHash\n| [32]byte\n| 32\n| The hash of the last block in the chain that headers are requested for\n|-\n| FilterHeadersLength\n| CompactSize\n| 1-3\n| The length of the following vector of filter headers\n|-\n| FilterHeaders\n| [][32]byte\n| FilterHeadersLength * 32\n| The filter headers at intervals of 1,000\n|}", "category": "bips" }, { "instruction": "Can you explain FilterHeaders MUST have exactly one entry for each block on the chain terminating in StopHash, where the block height is a multiple of 1,000 greater than 0. The entries MUST be the filter headers of the given type for each such block, in ascending order by height. like we're having a beer and talking Bitcoin?", "input": "", "output": "=== Node Operation ===\n\nFull nodes MAY opt to support this BIP and generate filters for any of the\nspecified filter types. Such nodes SHOULD treat the filters as an additional\nindex of the blockchain. For each new block that is connected to the main chain,\nnodes SHOULD generate filters for all supported types and persist them. Nodes\nthat are missing filters and are already synced with the blockchain SHOULD\nreindex the chain upon start-up, constructing filters for each block from\ngenesis to the current tip. They also SHOULD keep every checkpoint header in\nmemory, so that getcfcheckpt requests do not result in many\nrandom-access disk reads.\n\nNodes SHOULD NOT generate filters dynamically on request, as malicious peers may\nbe able to perform DoS attacks by requesting small filters derived from large\nblocks. This would require an asymmetrical amount of I/O on the node to compute\nand serve, similar to attacks against BIP 37 enabled nodes noted in BIP 111.\n\nNodes MAY prune block data after generating and storing all filters for a block.\n\n=== Client Operation ===\n\nThis section provides recommendations for light clients to download filters with\nmaximal security.\n\nClients SHOULD first sync the entire block header chain from peers using the\nstandard headers-first syncing mechanism before downloading any block filters or\nfilter headers. Clients configured with trusted checkpoints MAY only sync\nheaders started from the last checkpoint. Clients SHOULD disconnect any outbound\npeers whose best chain has significantly less work than the known longest\nproof-of-work chain.\n\nOnce a client's block headers are in sync, it SHOULD download and verify filter\nheaders for all blocks and filter types that it might later download. The client\nSHOULD send getcfheaders messages to peers and derive and store the\nfilter headers for each block. The client MAY first fetch headers at evenly\nspaced intervals of 1,000 by sending getcfcheckpt. The header\ncheckpoints allow the client to download filter headers for different intervals\nfrom multiple peers in parallel, verifying each range of 1,000 headers against\nthe checkpoints.\n\nUnless securely connected to a trusted peer that is serving filter headers, the\nclient SHOULD connect to multiple outbound peers that support each filter type\nto mitigate the risk of downloading incorrect headers. If the client receives\nconflicting filter headers from different peers for any block and filter type,\nit SHOULD interrogate them to determine which is faulty. The client SHOULD use\ngetcfheaders and/or getcfcheckpt to first identify\nthe first filter headers that the peers disagree on. The client then SHOULD\ndownload the full block from any peer and derive the correct filter and filter\nheader. The client SHOULD ban any peers that sent a filter header that does not\nmatch the computed one.\n\nOnce the client has downloaded and verified all filter headers needed, ''and''\nno outbound peers have sent conflicting headers, the client can download the\nactual block filters it needs. The client MAY backfill filter headers before the\nfirst verified one at this point if it only downloaded them starting at a later\npoint. Clients SHOULD persist the verified filter headers for the last 100 blocks in\nthe chain (or whatever finality depth is desired), to compare against headers\nreceived from new peers after restart. They MAY store more filter headers to\navoid redownloading them if a rescan is later necessary.\n\nStarting from the first block in the desired range, the client now MAY download\nthe filters. The client SHOULD test that each filter links to its corresponding\nfilter header and ban peers that send incorrect filters. The client MAY download\nmultiple filters at once to increase throughput, though it SHOULD test the\nfilters sequentially. The client MAY check if a filter is empty before\nrequesting it by checking if the filter header commits to the hash of the empty\nfilter, saving a round trip if that is the case.\n\nEach time a new valid block header is received, the client SHOULD request the\ncorresponding filter headers from all eligible peers. If two peers send\nconflicting filter headers, the client should interrogate them as described\nabove and ban any peers that send an invalid header.\n\nIf a client is fetching full blocks from the P2P network, they SHOULD be downloaded\nfrom outbound peers at random to mitigate privacy loss due to transaction\nintersection analysis. Note that blocks may be downloaded from peers that do not\nsupport this BIP.\n\n== Rationale ==\n\nThe filter headers and checkpoints messages are defined to help clients identify\nthe correct filter for a block when connected to peers sending conflicting\ninformation. An alternative solution is to require Bitcoin blocks to include\ncommitments to derived block filters, so light clients can verify authenticity\ngiven block headers and some additional witness data. This would require a\nnetwork-wide change to the Bitcoin consensus rules, however, whereas this\ndocument proposes a solution purely at the P2P layer.\n\nThe constant interval of 1,000 blocks between checkpoints was chosen so that,\ngiven the current chain height and rate of growth, the size of a\ncfcheckpt message is not drastically different from a\ncfheaders message between two checkpoints. Also, 1,000 is a nice\nround number, at least to those of us who think in decimal.\n\n== Compatibility ==\n\nThis light client mode is not compatible with current node deployments and\nrequires support for the new P2P messages. The node implementation of this\nproposal is not incompatible with the current P2P network rules (ie. doesn't\naffect network topology of full nodes). Light clients may adopt protocols based\non this as an alternative to the existing BIP 37. Adoption of this BIP may\nresult in reduced network support for BIP 37.\n\n== Acknowledgments ==\n\nWe would like to thank bfd (from the bitcoin-dev mailing list) for bringing the\nbasis of this BIP to our attention, Joseph Poon for suggesting the filter header\nchain scheme, and Pedro Martelletto for writing the initial indexing code for\nbtcd.\n\nWe would also like to thank Dave Collins, JJ Jeffrey, Eric Lombrozo, and Matt\nCorallo for useful discussions.\n\n== Reference Implementation ==\n\nLight client: [https://github.com/lightninglabs/neutrino]\n\nFull-node indexing: https://github.com/Roasbeef/btcd/tree/segwit-cbf\n\nGolomb-Rice Coded sets: https://github.com/Roasbeef/btcutil/tree/gcs/gcs\n\n== References ==\n\n\n\n== Copyright ==\n\nThis document is licensed under the Creative Commons CC0 1.0 Universal license.", "category": "bips" }, { "instruction": "How would you explain 
 to someone who knows Bitcoin basics?",
    "input": "",
    "output": "BIP: 46\n  Layer: Applications\n  Title: Address Scheme for Timelocked Fidelity Bonds\n  Authors: Chris Belcher \n           Thebora Kompanioni \n  Status: Draft\n  Type: Specification\n  Assigned: 2022-04-01\n  License: CC0-1.0\n  Discussion: 2022-05-01: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020389.html\n
\n\n== Abstract ==\n\nThis BIP defines the derivation scheme for HD wallets which create timelocked addresses used for creating fidelity bonds. It also gives advice to wallet developers on how to use fidelity bonds to sign over messages, such as certificates, which are needed when using fidelity bonds that are stored offline.\n\n== Copyright ==\n\nThis document is licensed under the Creative Commons CC0 1.0 Universal license.\n\n== Motivation ==\n\nFidelity bonds are used to resist sybil attacks in certain decentralized anonymous protocols. They are created by locking up bitcoins using the `OP_CHECKLOCKTIMEVERIFY` opcode.\n\nHaving a common derivation scheme allows users of wallet software to have a backup of their fidelity bonds by storing only the HD seed and a reference to this BIP. Importantly the user does not need to backup any timelock values.\n\nWe largely use the same approach used in BIPs 49, 84 and 86 for ease of implementation.\n\nThis allows keeping the private keys of fidelity bonds in cold storage, which increases the sybil resistance of a system without hot wallet risk.\n\n== Backwards Compatibility ==\n\nThis BIP is not backwards compatible by design as described in the Considerations section of [[bip-0049.mediawiki|BIP 49]]. An incompatible wallet will not discover fidelity bonds at all and the user will notice that something is wrong.\n\n== Background ==\n\n=== Fidelity bonds ===\n\nA fidelity bond is a mechanism where bitcoin value is deliberately sacrificed to make a cryptographic identity expensive to obtain. A way to create a fidelity bond is to lock up bitcoins by sending them to a timelocked address. The valuable thing being sacrificed is the time-value-of-money.\n\nThe sacrifice must be done in a way that can be proven to a third party. This proof can be made by showing the UTXO outpoint, the address redeemscript and a signature which signs a message using the private key corresponding to the public key in the redeemscript.\n\nThe sacrificed value is an objective measurement that can't be faked and which can be verified by anybody (just like, for example PoW mining). Sybil attacks can be made very expensive by forcing a hypothetical sybil attacker to lock up many bitcoins for a long time. JoinMarket implements fidelity bonds for protection from sybil attackers. At the time of writing over 600 BTC in total have been locked up with some for many years. Their UTXOs and signatures have been advertised to the world as proof. We can calculate that for a sybil attacker to succeed in unmixing all the CoinJoins, they would have to lock up over 100k BTC for several years.\n\n=== Fidelity bonds in cold storage ===\n\nTo allow for holding fidelity bonds in cold storage, there is an intermediate keypair called the certificate.\n\n UTXO key ---signs---> certificate ---signs---> endpoint\n\nWhere the endpoint might be a IRC nickname or Tor onion hostname. The certificate keypair can be kept online and used to prove ownership of the fidelity bond. Even if the hot wallet private keys are stolen, the coins in the timelocked address will still be safe, although the thief will be able to impersonate the fidelity bond until the expiry.\n\n== Rationale ==\n\nIt is useful for the user to avoid having to keep a record of the timelocks in the time-locked addresses. So only a limited small set of timelocks are defined by this BIP. This way the user must only store their seed phrase, and knowledge that they have coins stored using this BIP standard. The user doesn't need to remember or store any dates.\n\nThis standard is already implemented and deployed in JoinMarket. As most changes would require a protocol change of a live system, there is limited scope for changing this standard in review. This BIP is more about documenting something which already exists, warts and all.\n\n== Specifications ==\n\nThis BIP defines the two needed steps to derive multiple deterministic addresses based on a [[bip-0032.mediawiki|BIP 32]] master private key. It also defines the format of the certificate that can be signed by the deterministic address key.\n\n=== Public key derivation ===\n\nTo derive a public key from the root account, this BIP uses a similar account-structure as defined in BIP [[bip-0084.mediawiki|44]] but with change set to 2.\n\n
\nm / 84' / 0' / 0' / 2 / index\n
\n\nA key derived with this derivation path pattern will be referred to as derived_key further\nin this document.\n\nFor index, addresses are numbered from 0 in a sequentially increasing manner with a fixed upper bound: The index only goes up to 959 inclusive. Only 960 addresses can be derived for a given BIP32 master key. Furthermore there is no concept of a gap limit, instead wallets must always generate all 960 addresses and check for all of them if they have a balance and history.\n\n=== Timelock derivation ===\n\nThe timelock used in the time-locked address is derived from the index. The timelock is a unix time. It is always at the start of the first second at the beginning of the month (see [[#test-vectors|Test vectors]]). The index counts upwards the months from January 2020, ending in December 2099. At 12 months per year for 80 years this totals 960 timelocks. Note that care must be taken with the year 2038 problem on 32-bit systems.\n\n
\nyear = 2020 + index // 12\nmonth = 1 + index % 12\n
\n\n\n=== Address derivation ===\n\nTo derive the address from the above calculated public key and timelock, we create a witness script which locks the funds until the timelock, and then checks the signature of the derived_key. The witness script is hashed with SHA256 to produce a 32-byte hash value that forms the witness program in the output script of the P2WSH address.\n\n witnessScript: OP_CHECKLOCKTIMEVERIFY OP_DROP OP_CHECKSIG\n witness: \n scriptSig: (empty)\n scriptPubKey: 0 <32-byte-hash>\n (0x0020{32-byte-hash})\n\n=== Message signing ===\n\nIn order to support signing of certificates, implementers should support signing ASCII messages.\n\nThe certificate message is defined as `\"fidelity-bond-cert\" || \"|\" || cert_pubkey || \"|\" || cert_expiry`.\n\nThe certificate expiry `cert_expiry` is the number of the 2016-block period after which the certificate is no longer valid. For example, if `cert_expiry` is 330 then the certificate will become invalid after block height 665280 (:=330x2016). The purpose of the expiry parameter is so that in case the certificate keypair is compromised, the attacker can only impersonate the fidelity bond for a limited amount of time.\n\nA certificate message can be created by another application external to this standard. It is then prepended with the string `0x18 || \"Bitcoin Signed Message:\\n\"` and a byte denoting the length of the certificate message. The whole thing is then signed with the private key of the derived_key. This part is identical to the \"Sign Message\" function which many wallets already implement.\n\nAlmost all wallets implementing this standard can use their already-existing \"Sign Message\" function to sign the certificate message. As the certificate message itself is always an ASCII string, the wallet may not need to specially implement this section at all but just rely on users copypasting their certificate message into the already-existing \"Sign Message\" user interface. This works as long as the wallet knows how to use the private key of the timelocked address for signing messages.\n\nIt is most important for wallet implementations of this standard to support creating the certificate signature. Verifying the certificate signature is less important.\n\n\n== Test vectors ==\n\n
\nmnemonic = abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon about\nrootpriv = xprv9s21ZrQH143K3GJpoapnV8SFfukcVBSfeCficPSGfubmSFDxo1kuHnLisriDvSnRRuL2Qrg5ggqHKNVpxR86QEC8w35uxmGoggxtQTPvfUu\nrootpub  = xpub661MyMwAqRbcFkPHucMnrGNzDwb6teAX1RbKQmqtEF8kK3Z7LZ59qafCjB9eCRLiTVG3uxBxgKvRgbubRhqSKXnGGb1aoaqLrpMBDrVxga8\n\n// First timelocked address = m/84'/0'/0'/2/0\nderived private_key = L2tQBEdhC48YLeEWNg3e4msk94iKfyVa9hdfzRwUERabZ53TfH3d\nderived public_key  = 02a1b09f93073c63f205086440898141c0c3c6d24f69a18db608224bcf143fa011\nunix locktime       = 1577836800\nstring locktime     = 2020-01-01 00:00:00\nredeemscript        = 0400e10b5eb1752102a1b09f93073c63f205086440898141c0c3c6d24f69a18db608224bcf143fa011ac\nscriptPubKey        = 0020bdee9515359fc9df912318523b4cd22f1c0b5410232dc943be73f9f4f07e39ad\naddress             = bc1qhhhf29f4nlyalyfrrpfrknxj9uwqk4qsyvkujsa7w0ulfur78xkspsqn84\n\n// Test certificate using the first timelocked address\n// Note that as signatures contains a random nonce, it might not be exactly the same when your code generates it\n// p2pkh address is the p2pkh address corresponding to the derived public key, it can be used to verify the message\n//  signature in any wallet that supports Verify Message.\n// As mentioned before, it is more important for implementers of this standard to support signing such messages, not verifying them\nmessage       = fidelity-bond-cert|020000000000000000000000000000000000000000000000000000000000000001|375\naddress       = bc1qhhhf29f4nlyalyfrrpfrknxj9uwqk4qsyvkujsa7w0ulfur78xkspsqn84\np2pkh address = 16vmiGpY1rEaYnpGgtG7FZgr2uFCpeDgV6\nsignature     = H2b/90XcKnIU/D1nSCPhk8OcxrHebMCr4Ok2d2yDnbKDTSThNsNKA64CT4v2kt+xA1JmGRG/dMnUUH1kKqCVSHo=\n\n// 2nd timelocked address = m/84'/0'/0'/2/1\nderived private_key = KxctaFBzetyc9KXeUr6jxESCZiCEXRuwnQMw7h7hroP6MqnWN6Pf\nderived public_key  = 02599f6db8b33265a44200fef0be79c927398ed0b46c6a82fa6ddaa5be2714002d\nunix locktime       = 1580515200\nstring locktime     = 2020-02-01 00:00:00\nredeemscript        = 0480bf345eb1752102599f6db8b33265a44200fef0be79c927398ed0b46c6a82fa6ddaa5be2714002dac\nscriptPubKey        = 0020b8f898643991608524ed04e0c6779f632a57f1ffa3a3a306cd81432c5533e9ae\naddress             = bc1qhrufsepej9sg2f8dqnsvvaulvv490u0l5w36xpkds9pjc4fnaxhq7pcm4h\n\n// timelocked address after the year 2038 = m/84'/0'/0'/2/240\nderived private_key = L3SYqae23ZoDDcyEA8rRBK83h1MDqxaDG57imMc9FUx1J8o9anQe\nderived public_key  = 03ec8067418537bbb52d5d3e64e2868e67635c33cfeadeb9a46199f89ebfaab226\nunix locktime       = 2208988800\nstring locktime     = 2040-01-01 00:00:00\nredeemscript        = 05807eaa8300b1752103ec8067418537bbb52d5d3e64e2868e67635c33cfeadeb9a46199f89ebfaab226ac\nscriptPubKey        = 0020e7de0ad2720ae1d6cc9b6ad91af57eb74646762cf594c91c18f6d5e7a873635a\naddress             = bc1qul0q45njptsadnymdtv34at7karyva3v7k2vj8qc7m2702rnvddq0z20u5\n\n// last timelocked address = m/84'/0'/0'/2/959\nderived private_key = L5Z9DDMnj5RZMyyPiQLCvN48Xt7GGmev6cjvJXD8uz5EqiY8trNJ\nderived public_key  = 0308c5751121b1ae5c973cdc7071312f6fc10ab864262f0cbd8134f056166e50f3\nunix locktime       = 4099766400\nstring locktime     = 2099-12-01 00:00:00\nredeemscript        = 0580785df400b175210308c5751121b1ae5c973cdc7071312f6fc10ab864262f0cbd8134f056166e50f3ac\nscriptPubKey        = 0020803268e042008737cf439748cbb5a4449e311da9aa64ae3ac56d84d059654f85\naddress             = bc1qsqex3czzqzrn0n6rjayvhddygj0rz8df4fj2uwk9dkzdqkt9f7zs5c493u\n\n// Test certificate and endpoint signing using the first timelocked address = m/84'/0'/0'/2/0 (see above)\nbond private_key          = L2tQBEdhC48YLeEWNg3e4msk94iKfyVa9hdfzRwUERabZ53TfH3d\nbond p2pkh address        = 16vmiGpY1rEaYnpGgtG7FZgr2uFCpeDgV6\n\ncertificate private_key   = KyZpNDKnfs94vbrwhJneDi77V6jF64PWPF8x5cdJb8ifgg2DUc9d\ncertificate public_key    = 0330d54fd0dd420a6e5f8d3624f5f3482cae350f79d5f0753bf5beef9c2d91af3c\ncertificate p2pkh address = 1JaUQDVNRdhfNsVncGkXedaPSM5Gc54Hso\n\ncertificate message       = fidelity-bond-cert|0330d54fd0dd420a6e5f8d3624f5f3482cae350f79d5f0753bf5beef9c2d91af3c|375\ncertificate signature     = INOP3cB9UW7F1e1Aglj8rI9QhnyxmgWDEPt+nOMvl7hJJne7rH/KCNDYvLiqNuB9qWaWUojutjRsgPJrvyDQ+0Y=\n\n// example endpoint signing two IRC nicknames (used in JoinMarket)\nendpoint message          = J54LS6YyJPoseqFS|J55VZ6U6ZyFDNeuv\nendpoint signature        = H18WE4MugDNoWZIf9jU0njhQptdUyBDUf7lToG9bpMKmeJK0lOoABaDs5bKnohSuZ0e9gnSco5OL9lXdKU7gP5E=\n
\n\nCode generating these test vectors can be found here: https://github.com/chris-belcher/timelocked-addresses-fidelity-bond-bip-testvectors\n\n== Reference ==\n\n* [[https://gist.github.com/chris-belcher/18ea0e6acdb885a2bfbdee43dcd6b5af/|Design for improving JoinMarket's resistance to sybil attacks using fidelity bonds]]\n* [[https://github.com/JoinMarket-Org/joinmarket-clientserver/blob/master/docs/fidelity-bonds.md|JoinMarket fidelity bonds doc page]]\n* [[bip-0065.mediawiki|BIP65 - OP_CHECKLOCKTIMEVERIFY]]\n* [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]]\n* [[bip-0044.mediawiki|BIP44 - Multi-Account Hierarchy for Deterministic Wallets]]\n* [[bip-0049.mediawiki|BIP49 - Derivation scheme for P2WPKH-nested-in-P2SH based accounts]]\n* [[bip-0084.mediawiki|BIP84 - Derivation scheme for P2WPKH based accounts]]\n* [[bip-0086.mediawiki|BIP86 - Key Derivation for Single Key P2TR Outputs]]", "category": "bips" }, { "instruction": "I'm trying to understand 
 - can you walk me through it?",
    "input": "",
    "output": "BIP: 145\n  Layer: API/RPC\n  Title: getblocktemplate Updates for Segregated Witness\n  Authors: Luke Dashjr \n  Status: Deployed\n  Type: Specification\n  Assigned: 2016-01-30\n  License: BSD-2-Clause OR OPUBL-1.0\n
\n\n==Abstract==\n\nThis BIP describes modifications to the getblocktemplate JSON-RPC call ([[bip-0022.mediawiki|BIP 22]]) to support segregated witness as defined by [[bip-0141.mediawiki|BIP 141]].\n\n==Specification==\n\n===Block Template===\n\nThe template Object is revised to include a new key:\n\n{| class=\"wikitable\"\n!colspan=4| template\n|-\n! Key !! Required !! Type !! Description\n|-\n| weightlimit || No || Number || total weight allowed in blocks\n|}\n\nThe '!' rule prefix MUST be enabled on the \"segwit\" rule for templates including transactions with witness data.\nIn particular, note that even if the client's \"rules\" list lacks \"segwit\", server MAY support old miners by producing a witness-free template and omitting the '!' rule prefix for \"segwit\" in the template's \"rules\" list.\nIf the GBT server does not support producing witness-free templates after its activation, it must also use the '!' rule prefix in the \"vbavailable\" list prior to activation.\n\n====Transactions Object Format====\n\nThe Objects listed in the response's \"transactions\" key is revised to include these keys:\n\n{| class=\"wikitable\"\n!colspan=3|template \"transactions\" element\n|-\n! Key !! Type !! Description\n|-\n| txid || String || transaction id encoded in hexadecimal; required for transactions with witness data\n|-\n| weight || Number || numeric weight of the transaction, as counted for purposes of the block's weightlimit; if key is not present, weight is unknown and clients MUST NOT assume it is zero, although they MAY choose to calculate it themselves\n|-\n| hash || String || reversed hash of complete transaction (with witness data included) encoded in hexadecimal\n|}\n\nTransactions with witness data may only be included if the template's \"rules\" list (see [[bip-0009.mediawiki#getblocktemplate-changes|BIP 9]]) includes \"segwit\".\n\n===Sigops===\n\nFor templates with \"segwit\" enabled as a rule, the \"sigoplimit\" and \"sigops\" keys must use the new values as calculated in [[bip-0141.mediawiki#sigops|BIP 141]].\n\n===Block Assembly with Witness Transactions===\n\nWhen block assembly is done without witness transactions, no changes are made by this BIP, and it should be assembled as previously.\n\nWhen witness transactions are included in the block, the primary merkle root MUST be calculated with those transactions' \"txid\" field instead of \"hash\". A secondary merkle root MUST be calculated as per [[bip-0141.mediawiki#commitment-structure|BIP 141's commitment structure specification]] to be inserted into the generation (coinbase) transaction.\n\nServers MUST NOT include a commitment in the \"coinbasetxn\" key on the template. Clients MUST insert the commitment as an additional output at the end of the final generation (coinbase) transaction. Only if the template includes a \"mutable\" key (see [[bip-0023.mediawiki#mutations|BIP 23 Mutations]]) including \"generation\", the client MAY in that case place the commitment output in any position it chooses, provided that no later output matches the commitment pattern.\n\n==Motivation==\n\nSegregated witness substantially changes the structure of blocks, so the previous getblocktemplate specification is no longer sufficient.\nIt additionally also adds a new way of counting resource limits, and so GBT must be extended to convey this information correctly as well.\n\n==Rationale==\n\nWhy doesn't \"weightlimit\" simply redefine the existing \"sizelimit\"?\n* \"sizelimit\" is already enforced by clients by counting the sum of bytes in transactions' \"data\" keys.\n* Servers may wish to limit the overall size of a block, independently from the \"weight\" of the block.\n\nWhy is \"sigoplimit\" redefined instead of a new \"sigopweightlimit\" being added?\n* The old limit was already arbitrarily defined, and could not be counted by clients on their own anyway. The concept of \"sigop weight\" is merely a change in the arbitrary formula used.\n\nWhy is \"sigoplimit\" divided by 4?\n* To resemble the previous values. (FIXME: is this a good reason? maybe we shouldn't divide it?)\n\nWhy is the witness commitment required to be added to the end of the generation transaction rather than anywhere else?\n* Servers which do not allow modification of the generation outputs ought to be checking this as part of the validity of submissions. By requiring a specific placement, they can simply strip the commitment and do a byte-for-byte comparison of the outputs. Placing it at the end avoids the possibility of a later output matching the pattern and overriding it.\n\nWhy shouldn't the server simply add the commitment upfront in the \"coinbasetxn\", and simply send the client stripped transaction data?\n* It would become impossible for servers to specify only \"coinbasevalue\", since clients would no longer have the information required to construct the commitment.\n* getblocktemplate is intended to be a *decentralised* mining protocol, and allowing clients to be blinded to the content of the block works contrary to that purpose.\n* BIP 23's \"transactions\" mutations allow the client to modify the transaction-set on their own, which is impossible without the complete transaction data.\n\n==Reference Implementation==\n\n* [https://github.com/bitcoin/libblkmaker/tree/segwit libblkmaker]\n* [https://github.com/luke-jr/eloipool/tree/segwit Eloipool]\n* [https://github.com/bitcoin/bitcoin/pull/7404/files Bitcoin Core]\n\n==See Also==\n* [[bip-0009.mediawiki|BIP 9: Version bits with timeout and delay]]\n* [[bip-0022.mediawiki|BIP 22: getblocktemplate - Fundamentals]]\n* [[bip-0023.mediawiki|BIP 23: getblocktemplate - Pooled Mining]]\n* [[bip-0141.mediawiki|BIP 141: Segregated Witness (Consensus layer)]]\n\n==Copyright==\n\nThis BIP is dual-licensed under the Open Publication License and BSD 2-clause license.", "category": "bips" }, { "instruction": "Hey, I need to set up 
 - what's the command line way to do that?",
    "input": "",
    "output": "BIP: 67\n  Layer: Applications\n  Title: Deterministic Pay-to-script-hash multi-signature addresses through public key sorting\n  Authors: Thomas Kerin \n           Jean-Pierre Rupp \n           Ruben de Vries \n  Status: Complete\n  Type: Specification\n  Assigned: 2015-02-08\n  License: PD\n
\n\n==Abstract==\n\nThis BIP describes a method to deterministically generate multi-signature pay-to-script-hash transaction scripts. It focuses on defining how the public keys must be encoded and sorted so that the redeem script and corresponding P2SH address are always the same for a given set of keys and number of required signatures.\n\n==Motivation==\n\nPay-to-script-hash (BIP-0011[https://github.com/bitcoin/bips/blob/master/bip-0011.mediawiki BIP-0011]) is a transaction type that allows funding of arbitrary scripts, where the recipient carries the cost of fee's associated with using longer, more complex scripts.\n\nMulti-signature pay-to-script-hash transactions are defined in BIP-0016[https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki BIP-0016]. The redeem script does not require a particular ordering or encoding for public keys. This means that for a given set of keys and number of required signatures, there are as many as 2(n!) possible standard redeem scripts, each with its separate P2SH address. Adhering to an ordering and key encoding would ensure that a multi-signature “account” (set of public keys and required signature count) has a canonical P2SH address.\n\nBy adopting a sorting and encoding standard, compliant wallets will always produce the same P2SH address for the same given set of keys and required signature count, making it easier to recognize transactions involving that multi-signature account. This is particularly attractive for multisignature hierarchical-deterministic wallets, as less state is required to setup multi-signature accounts: only the number of required signatures and master public keys of participants need to be shared, and all wallets will generate the same addresses.\n\nWhile most web wallets do not presently facilitate the setup of multisignature accounts with users of a different service, conventions which ensure cross-compatibility should make it easier to achieve this.\n\nMany wallet as a service providers use a 2of3 multi-signature schema where the user stores 1 of the keys (offline) as backup while using the other key for daily use and letting the service cosign his transactions.\nThis standard will help in enabling a party other than the service provider to recover the wallet without any help from the service provider.\n\n==Specification==\n\nFor a set of public keys, ensure that they have been received in compressed form:\n\n 022df8750480ad5b26950b25c7ba79d3e37d75f640f8e5d9bcd5b150a0f85014da\n 03e3818b65bcc73a7d64064106a859cc1a5a728c4345ff0b641209fba0d90de6e9\n 021f2f6e1e50cb6a953935c3601284925decd3fd21bc445712576873fb8c6ebc18\n\nSort them lexicographically according to their binary representation:\n\n 021f2f6e1e50cb6a953935c3601284925decd3fd21bc445712576873fb8c6ebc18\n 022df8750480ad5b26950b25c7ba79d3e37d75f640f8e5d9bcd5b150a0f85014da\n 03e3818b65bcc73a7d64064106a859cc1a5a728c4345ff0b641209fba0d90de6e9\n\n..before using the resulting list of keys in a standard multisig redeem script:\n\n OP_2 021f2f6e1e50cb6a953935c3601284925decd3fd21bc445712576873fb8c6ebc18 022df8750480ad5b26950b25c7ba79d3e37d75f640f8e5d9bcd5b150a0f85014da 03e3818b65bcc73a7d64064106a859cc1a5a728c4345ff0b641209fba0d90de6e9 OP_3 OP_CHECKMULTISIG\n\nHash the redeem script according to BIP-0016 to get the P2SH address.\n\n 3Q4sF6tv9wsdqu2NtARzNCpQgwifm2rAba\n\n==Compatibility==\n* Uncompressed keys are incompatible with this specification. A compatible implementation should not automatically compress keys. Receiving an uncompressed key from a multisig participant should be interpreted as a sign that the user has an incompatible implementation.\n* P2SH addresses do not reveal information about the script that is receiving the funds. For this reason it is not technically possible to enforce this BIP as a rule on the network. Also, it would cause a hard fork.\n* Implementations that do not conform with this BIP will have compatibility issues with strictly-compliant wallets.\n* Implementations which do adopt this standard will be cross-compatible when choosing multisig addresses.\n* If a group of users were not entirely compliant, there is the possibility that a participant will derive an address that the others will not recognize as part of the common multisig account.\n\n==Test vectors==\nTwo signatures are required in each of these test vectors.\n\nVector 1\n* List\n** 02ff12471208c14bd580709cb2358d98975247d8765f92bc25eab3b2763ed605f8\n** 02fe6f0a5a297eb38c391581c4413e084773ea23954d93f7753db7dc0adc188b2f\n* Sorted\n** 02fe6f0a5a297eb38c391581c4413e084773ea23954d93f7753db7dc0adc188b2f\n** 02ff12471208c14bd580709cb2358d98975247d8765f92bc25eab3b2763ed605f8\n* Script\n** 522102fe6f0a5a297eb38c391581c4413e084773ea23954d93f7753db7dc0adc188b2f2102ff12471208c14bd580709cb2358d98975247d8765f92bc25eab3b2763ed605f852ae\n* Address\n** 39bgKC7RFbpoCRbtD5KEdkYKtNyhpsNa3Z\n\nVector 2 (Already sorted, no action required)\n* List:\n** 02632b12f4ac5b1d1b72b2a3b508c19172de44f6f46bcee50ba33f3f9291e47ed0\n** 027735a29bae7780a9755fae7a1c4374c656ac6a69ea9f3697fda61bb99a4f3e77\n** 02e2cc6bd5f45edd43bebe7cb9b675f0ce9ed3efe613b177588290ad188d11b404\n* Sorted:\n** 02632b12f4ac5b1d1b72b2a3b508c19172de44f6f46bcee50ba33f3f9291e47ed0\n** 027735a29bae7780a9755fae7a1c4374c656ac6a69ea9f3697fda61bb99a4f3e77\n** 02e2cc6bd5f45edd43bebe7cb9b675f0ce9ed3efe613b177588290ad188d11b404\n* Script\n** 522102632b12f4ac5b1d1b72b2a3b508c19172de44f6f46bcee50ba33f3f9291e47ed021027735a29bae7780a9755fae7a1c4374c656ac6a69ea9f3697fda61bb99a4f3e772102e2cc6bd5f45edd43bebe7cb9b675f0ce9ed3efe613b177588290ad188d11b40453ae\n* Address\n** 3CKHTjBKxCARLzwABMu9yD85kvtm7WnMfH\n\nVector 3:\n* List:\n** 030000000000000000000000000000000000004141414141414141414141414141\n** 020000000000000000000000000000000000004141414141414141414141414141\n** 020000000000000000000000000000000000004141414141414141414141414140\n** 030000000000000000000000000000000000004141414141414141414141414140\n* Sorted:\n** 020000000000000000000000000000000000004141414141414141414141414140\n** 020000000000000000000000000000000000004141414141414141414141414141\n** 030000000000000000000000000000000000004141414141414141414141414140\n** 030000000000000000000000000000000000004141414141414141414141414141\n* Script\n** 522102000000000000000000000000000000000000414141414141414141414141414021020000000000000000000000000000000000004141414141414141414141414141210300000000000000000000000000000000000041414141414141414141414141402103000000000000000000000000000000000000414141414141414141414141414154ae\n* Address\n** 32V85igBri9zcfBRVupVvwK18NFtS37FuD\n\nVector 4: (from bitcore)\n* List:\n** 022df8750480ad5b26950b25c7ba79d3e37d75f640f8e5d9bcd5b150a0f85014da\n** 03e3818b65bcc73a7d64064106a859cc1a5a728c4345ff0b641209fba0d90de6e9\n** 021f2f6e1e50cb6a953935c3601284925decd3fd21bc445712576873fb8c6ebc18\n* Sorted:\n** 021f2f6e1e50cb6a953935c3601284925decd3fd21bc445712576873fb8c6ebc18\n** 022df8750480ad5b26950b25c7ba79d3e37d75f640f8e5d9bcd5b150a0f85014da\n** 03e3818b65bcc73a7d64064106a859cc1a5a728c4345ff0b641209fba0d90de6e9\n* Script\n** 5221021f2f6e1e50cb6a953935c3601284925decd3fd21bc445712576873fb8c6ebc1821022df8750480ad5b26950b25c7ba79d3e37d75f640f8e5d9bcd5b150a0f85014da2103e3818b65bcc73a7d64064106a859cc1a5a728c4345ff0b641209fba0d90de6e953ae\n* Address\n** 3Q4sF6tv9wsdqu2NtARzNCpQgwifm2rAba\n\n==Acknowledgements==\nThe authors wish to thank BtcDrak and Luke-Jr for their involvement & contributions in the early discussions of this BIP.\n\n==Usage & Implementations==\n* [[https://github.com/bitcoin/bips/blob/master/bip-0045.mediawiki#address-generation-procedure|BIP-0045]] - Structure for Deterministic P2SH Multisignature Wallets\n* [[https://github.com/bitpay/bitcore/blob/50a868cb8cdf2be04bb1c5bf4bcc064cc06f5888/lib/script/script.js#L541|Bitcore]]\n* [[https://github.com/haskoin/haskoin-core/blob/b41b1deb0989334a7ead6fc993fb8b02f0c00810/haskoin-core/Network/Haskoin/Script/Parser.hs#L112-L122|Haskoin]] - Bitcoin implementation in Haskell\n* [[https://github.com/etotheipi/BitcoinArmory/blob/268db0f3fa20c989057bd43343a43b2edbe89aeb/armoryengine/ArmoryUtils.py#L1441|Armory]]\n* [[https://github.com/bitcoinj/bitcoinj/blob/f7ea0b92a619800c143b0142dc70306da33119a9/core/src/main/java/org/bitcoinj/script/ScriptBuilder.java#L331|BitcoinJ]]\n\n== References ==\n\n\n\n== Copyright ==\nThis document is placed in the public domain.", "category": "bips" }, { "instruction": "What's the deal with 
 in Bitcoin? Explain it like I'm a friend.",
    "input": "",
    "output": "BIP: 173\n  Layer: Applications\n  Title: Base32 address format for native v0-16 witness outputs\n  Authors: Pieter Wuille \n           Greg Maxwell \n  Comments-Summary: No comments yet.\n  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0173\n  Status: Deployed\n  Type: Informational\n  Assigned: 2017-03-20\n  License: BSD-2-Clause\n  Replaces: 142\n  Proposed-Replacement: 350\n
\n\n==Introduction==\n\n===Abstract===\n\nThis document proposes a checksummed base32 format, \"Bech32\", and a standard for native segregated witness output addresses using it.\n\n===Copyright===\n\nThis BIP is licensed under the 2-clause BSD license.\n\n===Motivation===\n\nFor most of its history, Bitcoin has relied on base58 addresses with a\ntruncated double-SHA256 checksum. They were part of the original\nsoftware and their scope was extended in\n[https://github.com/bitcoin/bips/blob/master/bip-0013.mediawiki BIP13]\nfor Pay-to-script-hash\n([https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki P2SH]).\nHowever, both the character set and the checksum algorithm have limitations:\n* Base58 needs a lot of space in QR codes, as it cannot use the ''alphanumeric mode''.\n* The mixed case in base58 makes it inconvenient to reliably write down, type on mobile keyboards, or read out loud.\n* The double SHA256 checksum is slow and has no error-detection guarantees.\n* Most of the research on error-detecting codes only applies to character-set sizes that are a [https://en.wikipedia.org/wiki/Prime_power prime power], which 58 is not.\n* Base58 decoding is complicated and relatively slow.\n\nIncluded in the Segregated Witness proposal are a new class of outputs\n(witness programs, see\n[https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki BIP141]),\nand two instances of it (\"P2WPKH\" and \"P2WSH\", see\n[https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki BIP143]).\nTheir functionality is available indirectly to older clients by embedding in P2SH\noutputs, but for optimal efficiency and security it is best to use it\ndirectly. In this document we propose a new address format for native\nwitness outputs (current and future versions).\n\nThis replaces\n[https://github.com/bitcoin/bips/blob/master/bip-0142.mediawiki BIP142],\nand was previously discussed\n[https://bitcoincore.org/logs/2016-05-zurich-meeting-notes.html#base32 here] (summarized\n[https://bitcoincore.org/en/meetings/2016/05/20/#error-correcting-codes-for-future-address-types here]).\n\n===Examples===\n\nAll examples use public key\n0279BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798.\nThe P2WSH examples use key OP_CHECKSIG as script.\n\n* Mainnet P2WPKH: bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4\n* Testnet P2WPKH: tb1qw508d6qejxtdg4y5r3zarvary0c5xw7kxpjzsx\n* Mainnet P2WSH: bc1qrp33g0q5c5txsp9arysrx4k6zdkfs4nce4xj0gdcccefvpysxf3qccfmv3\n* Testnet P2WSH: tb1qrp33g0q5c5txsp9arysrx4k6zdkfs4nce4xj0gdcccefvpysxf3q0sl5k7\n\n==Specification==\n\nWe first describe the general checksummed base32'''Why use base32 at all?''' The lack of mixed case makes it more\nefficient to read out loud or to put into QR codes. It does come with a 15% length\nincrease, but that does not matter when copy-pasting addresses. format called\n''Bech32'' and then define Segregated Witness addresses using it.\n\n===Bech32===\n\nA Bech32'''Why call it Bech32?''' \"Bech\" contains the characters BCH (the error\ndetection algorithm used) and sounds a bit like \"base\". string is at most 90 characters long and consists of:\n* The '''human-readable part''', which is intended to convey the type of data, or anything else that is relevant to the reader. This part MUST contain 1 to 83 US-ASCII characters, with each character having a value in the range [33-126]. HRP validity may be further restricted by specific applications.\n* The '''separator''', which is always \"1\". In case \"1\" is allowed inside the human-readable part, the last one in the string is the separator'''Why include a separator in addresses?''' That way the human-readable\npart is unambiguously separated from the data part, avoiding potential\ncollisions with other human-readable parts that share a prefix. It also\nallows us to avoid having character-set restrictions on the human-readable part. The\nseparator is ''1'' because using a non-alphanumeric character would\ncomplicate copy-pasting of addresses (with no double-click selection in\nseveral applications). Therefore an alphanumeric character outside the normal character set\nwas chosen..\n* The '''data part''', which is at least 6 characters long and only consists of alphanumeric characters excluding \"1\", \"b\", \"i\", and \"o\"'''Why not use an existing character set like [http://www.faqs.org/rfcs/rfc3548.html RFC3548] or [https://philzimmermann.com/docs/human-oriented-base-32-encoding.txt z-base-32]'''?\nThe character set is chosen to minimize ambiguity according to\n[https://hissa.nist.gov/~black/GTLD/ this] visual similarity data, and\nthe ordering is chosen to minimize the number of pairs of similar\ncharacters (according to the same data) that differ in more than 1 bit.\nAs the checksum is chosen to maximize detection capabilities for low\nnumbers of bit errors, this choice improves its performance under some\nerror models..\n\n\n{| class=\"wikitable\"\n|-\n!\n!0\n!1\n!2\n!3\n!4\n!5\n!6\n!7\n|-\n!+0\n|q||p||z||r||y||9||x||8\n|-\n!+8\n|g||f||2||t||v||d||w||0\n|-\n!+16\n|s||3||j||n||5||4||k||h\n|-\n!+24\n|c||e||6||m||u||a||7||l\n|}\n\n\n'''Checksum'''\n\nThe last six characters of the data part form a checksum and contain no\ninformation. Valid strings MUST pass the criteria for validity specified\nby the Python3 code snippet below. The function\nbech32_verify_checksum must return true when its arguments are:\n* hrp: the human-readable part as a string\n* data: the data part as a list of integers representing the characters after conversion using the table above\n\n
\ndef bech32_polymod(values):\n  GEN = [0x3b6a57b2, 0x26508e6d, 0x1ea119fa, 0x3d4233dd, 0x2a1462b3]\n  chk = 1\n  for v in values:\n    b = (chk >> 25)\n    chk = (chk & 0x1ffffff) << 5 ^ v\n    for i in range(5):\n      chk ^= GEN[i] if ((b >> i) & 1) else 0\n  return chk\n\ndef bech32_hrp_expand(s):\n  return [ord(x) >> 5 for x in s] + [0] + [ord(x) & 31 for x in s]\n\ndef bech32_verify_checksum(hrp, data):\n  return bech32_polymod(bech32_hrp_expand(hrp) + data) == 1\n
\n\nThis implements a [https://en.wikipedia.org/wiki/BCH_code BCH code] that\nguarantees detection of '''any error affecting at most 4 characters'''\nand has less than a 1 in 109 chance of failing to detect more\nerrors. More details about the properties can be found in the\nChecksum Design appendix. The human-readable part is processed by first\nfeeding the higher bits of each character's US-ASCII value into the\nchecksum calculation followed by a zero and then the lower bits of each'''Why are the high bits of the human-readable part processed first?'''\nThis results in the actually checksummed data being ''[high hrp] 0 [low hrp] [data]''. This means that under the assumption that errors to the\nhuman readable part only change the low 5 bits (like changing an alphabetical character into another), errors are restricted to the ''[low hrp] [data]''\npart, which is at most 89 characters, and thus all error detection properties (see appendix) remain applicable..\n\nTo construct a valid checksum given the human-readable part and (non-checksum) values of the data-part characters, the code below can be used:\n\n
\ndef bech32_create_checksum(hrp, data):\n  values = bech32_hrp_expand(hrp) + data\n  polymod = bech32_polymod(values + [0,0,0,0,0,0]) ^ 1\n  return [(polymod >> 5 * (5 - i)) & 31 for i in range(6)]\n
\n\n'''Error correction'''\n\nOne of the properties of these BCH codes is that they can be used for\nerror correction. An unfortunate side effect of error correction is that\nit erodes error detection: correction changes invalid inputs into valid\ninputs, but if more than a few errors were made then the valid input may\nnot be the correct input. Use of an incorrect but valid input can cause\nfunds to be lost irrecoverably. Because of this, implementations SHOULD\nNOT implement correction beyond potentially suggesting to the user where\nin the string an error might be found, without suggesting the correction\nto make.\n\n'''Uppercase/lowercase'''\n\nThe lowercase form is used when determining a character's value for checksum purposes.\n\nEncoders MUST always output an all lowercase Bech32 string.\nIf an uppercase version of the encoding result is desired, (e.g.- for presentation purposes, or QR code use),\nthen an uppercasing procedure can be performed external to the encoding process.\n\nDecoders MUST NOT accept strings where some characters are uppercase and some are lowercase (such strings are referred to as mixed case strings).\n\nFor presentation, lowercase is usually preferable, but inside QR codes uppercase SHOULD be used, as those permit the use of\n''[http://www.thonky.com/qr-code-tutorial/alphanumeric-mode-encoding alphanumeric mode]'', which is 45% more compact than the normal\n''[http://www.thonky.com/qr-code-tutorial/byte-mode-encoding byte mode]''.\n\n===Segwit address format===\n\nA segwit address'''Why not make an address format that is generic for all scriptPubKeys?'''\nThat would lead to confusion about addresses for\nexisting scriptPubKey types. Furthermore, if addresses that do not have a one-to-one mapping with scriptPubKeys (such as ECDH-based\naddresses) are ever introduced, having a fully generic old address type available would\npermit reinterpreting the resulting scriptPubKeys using the old address\nformat, with lost funds as a result if bitcoins are sent to them. is a Bech32 encoding of:\n\n* The human-readable part \"bc\"'''Why use 'bc' as human-readable part and not 'btc'?''' 'bc' is shorter. for mainnet, and \"tb\"'''Why use 'tb' as human-readable part for testnet?''' It was chosen to\nbe of the same length as the mainnet counterpart (to simplify\nimplementations' assumptions about lengths), but still be visually\ndistinct. for testnet.\n* The data-part values:\n** 1 character (representing 5 bits of data): the witness version\n** A conversion of the 2-to-40-byte witness program (as defined by [https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki BIP141]) to base32:\n*** Start with the bits of the witness program, most significant bit per byte first.\n*** Re-arrange those bits into groups of 5, and pad with zeroes at the end if needed.\n*** Translate those bits to characters using the table above.\n\n'''Decoding'''\n\nSoftware interpreting a segwit address:\n* MUST verify that the human-readable part is \"bc\" for mainnet and \"tb\" for testnet.\n* MUST verify that the first decoded data value (the witness version) is between 0 and 16, inclusive.\n* Convert the rest of the data to bytes:\n** Translate the values to 5 bits, most significant bit first.\n** Re-arrange those bits into groups of 8 bits. Any incomplete group at the end MUST be 4 bits or less, MUST be all zeroes, and is discarded.\n** There MUST be between 2 and 40 groups, which are interpreted as the bytes of the witness program.\n\nDecoders SHOULD enforce known-length restrictions on witness programs.\nFor example, BIP141 specifies ''If the version byte is 0, but the witness\nprogram is neither 20 nor 32 bytes, the script must fail.''\n\nAs a result of the previous rules, addresses are always between 14 and 74 characters long, and their length modulo 8 cannot be 0, 3, or 5.\nVersion 0 witness addresses are always 42 or 62 characters, but implementations MUST allow the use of any version.\n\nImplementations should take special care when converting the address to a\nscriptPubkey, where witness version ''n'' is stored as ''OP_n''. OP_0 is\nencoded as 0x00, but OP_1 through OP_16 are encoded as 0x51 though 0x60\n(81 to 96 in decimal). If a bech32 address is converted to an incorrect\nscriptPubKey the result will likely be either unspendable or insecure.\n\n===Compatibility===\n\nOnly new software will be able to use these addresses, and only for\nreceivers with segwit-enabled new software. In all other cases, P2SH or\nP2PKH addresses can be used.\n\n==Rationale==\n\n\n\n==Reference implementations==\n\n* Reference encoder and decoder:\n** [https://github.com/sipa/bech32/tree/master/ref/c For C]\n** [https://github.com/sipa/bech32/tree/master/ref/c++ For C++]\n** [https://github.com/sipa/bech32/tree/master/ref/javascript For JavaScript]\n** [https://github.com/sipa/bech32/tree/master/ref/go For Go]\n** [https://github.com/sipa/bech32/tree/master/ref/python For Python]\n** [https://github.com/sipa/bech32/tree/master/ref/haskell For Haskell]\n** [https://github.com/sipa/bech32/tree/master/ref/ruby For Ruby]\n** [https://github.com/sipa/bech32/tree/master/ref/rust For Rust]\n\n* Fancy decoder that localizes errors:\n** [https://github.com/sipa/bech32/tree/master/ecc/javascript For JavaScript] ([http://bitcoin.sipa.be/bech32/demo/demo.html demo website])\n\n==Registered Human-readable Prefixes==\n\nSatoshiLabs maintains a full list of registered human-readable parts for other cryptocurrencies:\n\n[https://github.com/satoshilabs/slips/blob/master/slip-0173.md SLIP-0173 : Registered human-readable parts for BIP-0173]\n\n==Appendices==\n\n===Test vectors===\n\nThe following strings are valid Bech32:\n* A12UEL5L\n* a12uel5l\n* an83characterlonghumanreadablepartthatcontainsthenumber1andtheexcludedcharactersbio1tt5tgs\n* abcdef1qpzry9x8gf2tvdw0s3jn54khce6mua7lmqqqxw\n* 11qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqc8247j\n* split1checkupstagehandshakeupstreamerranterredcaperred2y9e3w\n* ?1ezyfcl WARNING: During conversion to US-ASCII some encoders may set unmappable characters to a valid US-ASCII character, such as '?'. For example:\n\n
\n>>> bech32_encode('\\x80'.encode('ascii', 'replace').decode('ascii'), [])\n'?1ezyfcl'\n
\n\nThe following string are not valid Bech32 (with reason for invalidity):\n* 0x20 + 1nwldj5: HRP character out of range\n* 0x7F + 1axkwrx: HRP character out of range\n* 0x80 + 1eym55h: HRP character out of range\n* an84characterslonghumanreadablepartthatcontainsthenumber1andtheexcludedcharactersbio1569pvx: overall max length exceeded\n* pzry9x0s0muk: No separator character\n* 1pzry9x0s0muk: Empty HRP\n* x1b4n0q5v: Invalid data character\n* li1dgmt3: Too short checksum\n* de1lg7wt + 0xFF: Invalid character in checksum\n* A1G7SGD8: checksum calculated with uppercase form of HRP\n* 10a06t8: empty HRP\n* 1qzzfhee: empty HRP\n\nThe following list gives valid segwit addresses and the scriptPubKey that they\ntranslate to in hex.\n* BC1QW508D6QEJXTDG4Y5R3ZARVARY0C5XW7KV8F3T4: 0014751e76e8199196d454941c45d1b3a323f1433bd6\n* tb1qrp33g0q5c5txsp9arysrx4k6zdkfs4nce4xj0gdcccefvpysxf3q0sl5k7: 00201863143c14c5166804bd19203356da136c985678cd4d27a1b8c6329604903262\n* bc1pw508d6qejxtdg4y5r3zarvary0c5xw7kw508d6qejxtdg4y5r3zarvary0c5xw7k7grplx: 5128751e76e8199196d454941c45d1b3a323f1433bd6751e76e8199196d454941c45d1b3a323f1433bd6\n* BC1SW50QA3JX3S: 6002751e\n* bc1zw508d6qejxtdg4y5r3zarvaryvg6kdaj: 5210751e76e8199196d454941c45d1b3a323\n* tb1qqqqqp399et2xygdj5xreqhjjvcmzhxw4aywxecjdzew6hylgvsesrxh6hy: 0020000000c4a5cad46221b2a187905e5266362b99d5e91c6ce24d165dab93e86433\n\nThe following list gives invalid segwit addresses and the reason for\ntheir invalidity.\n* tc1qw508d6qejxtdg4y5r3zarvary0c5xw7kg3g4ty: Invalid human-readable part\n* bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t5: Invalid checksum\n* BC13W508D6QEJXTDG4Y5R3ZARVARY0C5XW7KN40WF2: Invalid witness version\n* bc1rw5uspcuh: Invalid program length\n* bc10w508d6qejxtdg4y5r3zarvary0c5xw7kw508d6qejxtdg4y5r3zarvary0c5xw7kw5rljs90: Invalid program length\n* BC1QR508D6QEJXTDG4Y5R3ZARVARYV98GJ9P: Invalid program length for witness version 0 (per BIP141)\n* tb1qrp33g0q5c5txsp9arysrx4k6zdkfs4nce4xj0gdcccefvpysxf3q0sL5k7: Mixed case\n* bc1zw508d6qejxtdg4y5r3zarvaryvqyzf3du: zero padding of more than 4 bits\n* tb1qrp33g0q5c5txsp9arysrx4k6zdkfs4nce4xj0gdcccefvpysxf3pjxtptv: Non-zero padding in 8-to-5 conversion\n* bc1gmk9yu: Empty data section\n\n===Checksum design===\n\n'''Design choices'''\n\nBCH codes can be constructed over any prime-power alphabet and can be chosen to have a good trade-off between\nsize and error-detection capabilities. While most work around BCH codes uses a binary alphabet, that is not a requirement.\nThis makes them more appropriate for our use case than [https://en.wikipedia.org/wiki/Cyclic_redundancy_check CRC codes]. Unlike\n[https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction Reed-Solomon codes],\nthey are not restricted in length to one less than the alphabet size. While they also support efficient error correction,\nthe implementation of just error detection is very simple.\n\nWe pick 6 checksum characters as a trade-off between length of the addresses and the error-detection capabilities, as 6\ncharacters is the lowest number sufficient for a random failure chance below 1 per billion. For the length of data\nwe're interested in protecting (up to 71 bytes for a potential future 40-byte witness\nprogram), BCH codes can be constructed that guarantee detecting up to 4 errors.\n\n'''Selected properties'''\n\nMany of these codes perform badly when dealing with more errors than they are designed to detect, but not all.\nFor that reason, we consider codes that are designed to detect only 3 errors as well as 4 errors,\nand analyse how well they perform in practice.\n\nThe specific code chosen here is the result\nof:\n* Starting with an exhaustive list of 159605 BCH codes designed to detect 3 or 4 errors up to length 93, 151, 165, 341, 1023, and 1057.\n* From those, requiring the detection of 4 errors up to length 71, resulting in 28825 remaining codes.\n* From those, choosing the codes with the best worst-case window for 5-character errors, resulting in 310 remaining codes.\n* From those, picking the code with the lowest chance for not detecting small numbers of ''bit'' errors.\n\nAs a naive search would require over 6.5 * 1019 checksum evaluations, a collision-search approach was used for\nanalysis. The code can be found [https://github.com/sipa/ezbase32/ here].\n\n'''Properties'''\n\nThe following table summarizes the chances for detection failure (as\nmultiples of 1 in 109).\n\n{| class=\"wikitable\"\n|-\n!colspan=\"2\" | Window length\n!colspan=\"6\" | Number of wrong characters\n|-\n!Length\n!Description\n!≤4\n!5\n!6\n!7\n!8\n!≥9\n|-\n| 8 || Longest detecting 6 errors || colspan=\"3\" | 0 || 1.127 || 0.909 || n/a\n|-\n| 18 || Longest detecting 5 errors || colspan=\"2\" | 0 || 0.965 || 0.929 || 0.932 || 0.931\n|-\n| 19 || Worst case for 6 errors || 0 || 0.093 || 0.972 || 0.928 || colspan=\"2\" | 0.931\n|-\n| 39 || Length for a P2WPKH address || 0 || 0.756 || 0.935 || 0.932 || colspan=\"2\" | 0.931\n|-\n| 59 || Length for a P2WSH address || 0 || 0.805 || 0.933 || colspan=\"3\" | 0.931\n|-\n| 71 || Length for a 40-byte program address || 0 || 0.830 || 0.934 || colspan=\"3\" | 0.931\n|-\n| 89 || Longest detecting 4 errors || 0 || 0.867 || 0.933 || colspan=\"3\" | 0.931\n|}\nThis means that when 5 changed characters occur randomly distributed in\nthe 39 characters of a P2WPKH address, there is a chance of\n''0.756 per billion'' that it will go undetected. When those 5 changes\noccur randomly within a 19-character window, that chance goes down to\n''0.093 per billion''. As the number of errors goes up, the chance\nconverges towards ''1 in 230'' = ''0.931 per billion''.\n\nEven though the chosen code performs reasonably well up to 1023 characters,\nother designs are preferable for lengths above 89 characters (excluding the\nseparator).\n\n==Acknowledgements==\n\nThis document is inspired by the [https://rusty.ozlabs.org/?p=578 address proposal] by Rusty Russell, the\n[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-February/004402.html base32] proposal by Mark Friedenbach, and had input from Luke Dashjr,\nJohnson Lau, Eric Lombrozo, Peter Todd, and various other reviewers.\n\n==Disclosures (added 2024)==\n\nDue to an oversight in the design of bech32, this checksum scheme is not always\nrobust against\n[[https://gist.github.com/sipa/a9845b37c1b298a7301c33a04090b2eb|the insertion\nand deletion of fewer than 5 consecutive characters]]. Due to this weakness,\n[[bip-0350.mediawiki|BIP-350]] proposes using the scheme described in this BIP\nonly for Native Segwit v0 outputs.", "category": "bips" }, { "instruction": "Can you show me the CLI commands for 
?",
    "input": "",
    "output": "BIP: 1\n  Title: BIP Purpose and Guidelines\n  Authors: Amir Taaki \n  Status: Closed\n  Type: Process\n  Assigned: 2011-09-19\n  Proposed-Replacement: 2\n
\n\n==What is a BIP?==\n\nBIP stands for Bitcoin Improvement Proposal. A BIP is a design document providing information to the Bitcoin community, or describing a new feature for Bitcoin or its processes or environment. The BIP should provide a concise technical specification of the feature and a rationale for the feature.\n\nWe intend BIPs to be the primary mechanisms for proposing new features, for collecting community input on an issue, and for documenting the design decisions that have gone into Bitcoin. The BIP author is responsible for building consensus within the community and documenting dissenting opinions.\n\nBecause the BIPs are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal.\n\n==BIP Types==\n\nThere are three kinds of BIP:\n\n* A Standards Track BIP describes any change that affects most or all Bitcoin implementations, such as a change to the network protocol, a change in block or transaction validity rules, or any change or addition that affects the interoperability of applications using Bitcoin.\n* An Informational BIP describes a Bitcoin design issue, or provides general guidelines or information to the Bitcoin community, but does not propose a new feature. Informational BIPs do not necessarily represent a Bitcoin community consensus or recommendation, so users and implementers are free to ignore Informational BIPs or follow their advice.\n* A Process BIP describes a process surrounding Bitcoin, or proposes a change to (or an event in) a process. Process BIPs are like Standards Track BIPs but apply to areas other than the Bitcoin protocol itself. They may propose an implementation, but not to Bitcoin's codebase; they often require community consensus; unlike Informational BIPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Bitcoin development. Any meta-BIP is also considered a Process BIP.\n\n==BIP Work Flow==\n\nThe BIP process begins with a new idea for Bitcoin. Each potential BIP must have a champion -- someone who writes the BIP using the style and format described below, shepherds the discussions in the appropriate forums, and attempts to build community consensus around the idea. The BIP champion (a.k.a. Author) should first attempt to ascertain whether the idea is BIP-able. Posting to the [https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev bitcoin-dev@lists.linuxfoundation.org] mailing list (and maybe the [https://bitcointalk.org/index.php?board=6.0 Development & Technical Discussion] forum) is the best way to go about this.\n\nVetting an idea publicly before going as far as writing a BIP is meant to save both the potential author and the wider community time. Many ideas have been brought forward for changing Bitcoin that have been rejected for various reasons. Asking the Bitcoin community first if an idea is original helps prevent too much time being spent on something that is guaranteed to be rejected based on prior discussions (searching the internet does not always do the trick). It also helps to make sure the idea is applicable to the entire community and not just the author. Just because an idea sounds good to the author does not mean it will work for most people in most areas where Bitcoin is used. Small enhancements or patches often don't need standardisation between multiple projects; these don't need a BIP and should be injected into the relevant Bitcoin development work flow with a patch submission to the applicable Bitcoin issue tracker.\n\nOnce the champion has asked the Bitcoin community as to whether an idea has any chance of acceptance, a draft BIP should be presented to the [https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev bitcoin-dev] mailing list. This gives the author a chance to flesh out the draft BIP to make it properly formatted, of high quality, and to address additional concerns about the proposal. Following a discussion, the proposal should be sent to the bitcoin-dev list and the BIP editor with the draft BIP. This draft must be written in BIP style as described below, else it will be sent back without further regard until proper formatting rules are followed.\n\nBIP authors are responsible for collecting community feedback on both the initial idea and the BIP before submitting it for review. However, wherever possible, long open-ended discussions on public mailing lists should be avoided. Strategies to keep the discussions efficient include: setting up a separate SIG mailing list for the topic, having the BIP author accept private comments in the early design phases, setting up a wiki page or git repository, etc. BIP authors should use their discretion here.\n\nIt is highly recommended that a single BIP contain a single key proposal or new idea. The more focused the BIP, the more successful it tends to be. If in doubt, split your BIP into several well-focused ones.\n\nThe BIP editors assign BIP numbers and change their status. Please send all BIP-related email to the BIP editor, which is listed under [[#bip-editors|BIP Editors]] below. Also see [[#bip-editor-responsibilities--workflow|BIP Editor Responsibilities & Workflow]]. The BIP editor reserves the right to reject BIP proposals if they appear too unfocused or too broad.\n\nAuthors MUST NOT self assign BIP numbers, but should use an alias such as \"bip-johndoe-infinitebitcoins\" which includes the author's name/nick and the BIP subject.\n\nIf the BIP editor approves, he will assign the BIP a number, label it as Standards Track, Informational, or Process, give it status \"Draft\", and add it to the BIPs git repository. The BIP editor will not unreasonably deny a BIP. Reasons for denying BIP status include duplication of effort, disregard for formatting rules, being too unfocused or too broad, being technically unsound, not providing proper motivation or addressing backwards compatibility, or not in keeping with the Bitcoin philosophy. For a BIP to be accepted it must meet certain minimum criteria. It must be a clear and complete description of the proposed enhancement. The enhancement must represent a net improvement. The proposed implementation, if applicable, must be solid and must not complicate the protocol unduly.\n\nThe BIP author may update the Draft as necessary in the git repository. Updates to drafts may also be submitted by the author as pull requests.\n\nStandards Track BIPs consist of two parts, a design document and a reference implementation. The BIP should be reviewed and accepted before a reference implementation is begun, unless a reference implementation will aid people in studying the BIP. Standards Track BIPs must include an implementation -- in the form of code, a patch, or a URL to same -- before it can be considered Final.\n\nOnce a BIP has been accepted, the reference implementation must be completed. When the reference implementation is complete and accepted by the community, the status will be changed to \"Final\".\n\nA BIP can also be assigned status \"Deferred\". The BIP author or editor can assign the BIP this status when no progress is being made on the BIP. Once a BIP is deferred, the BIP editor can re-assign it to draft status.\n\nA BIP can also be \"Rejected\". Perhaps after all is said and done it was not a good idea. It is still important to have a record of this fact.\n\nBIPs can also be superseded by a different BIP, rendering the original obsolete. This is intended for Informational BIPs, where version 2 of an API can replace version 1.\n\nThe possible paths of the status of BIPs are as follows:\n\n\n\nSome Informational and Process BIPs may also have a status of \"Active\" if they are never meant to be completed. E.g. BIP 1 (this BIP).\n\n==What belongs in a successful BIP?==\n\nEach BIP should have the following parts:\n\n* Preamble -- RFC 822 style headers containing meta-data about the BIP, including the BIP number, a short descriptive title (limited to a maximum of 44 characters), the names, and optionally the contact info for each author, etc.\n\n* Abstract -- a short (~200 word) description of the technical issue being addressed.\n\n* Copyright/public domain -- Each BIP must either be explicitly labelled as placed in the public domain (see this BIP as an example) or licensed under the Open Publication License.\n\n* Specification -- The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Bitcoin platforms (Satoshi, BitcoinJ, bitcoin-js, libbitcoin).\n\n* Motivation -- The motivation is critical for BIPs that want to change the Bitcoin protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the BIP solves. BIP submissions without sufficient motivation may be rejected outright.\n\n* Rationale -- The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages.\n\n* The rationale should provide evidence of consensus within the community and discuss important objections or concerns raised during discussion.\n\n* Backwards Compatibility -- All BIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The BIP must explain how the author proposes to deal with these incompatibilities. BIP submissions without a sufficient backwards compatibility treatise may be rejected outright.\n\n* Reference Implementation -- The reference implementation must be completed before any BIP is given status \"Final\", but it need not be completed before the BIP is accepted. It is better to finish the specification and rationale first and reach consensus on it before writing code.\n\n* The final implementation must include test code and documentation appropriate for the Bitcoin protocol.\n\n==BIP Formats and Templates==\n\nBIPs should be written in mediawiki or markdown format.\n\n===BIP Header Preamble===\n\nEach BIP must begin with an RFC 822 style header preamble. The headers must appear in the following order. Headers marked with \"*\" are optional and are described below. All other headers are required.\n\n
\n  BIP: \n  Title: \n  Author: \n* Discussions-To: \n  Status: \n  Type: \n  Created: \n* Post-History: \n* Replaces: \n* Superseded-By: \n* Resolution: \n
\n\nThe Author header lists the names, and optionally the email addresses of all the authors/owners of the BIP. The format of the Author header value must be\n\n Random J. User \n\nif the email address is included, and just\n\n Random J. User\n\nif the address is not given.\n\nIf there are multiple authors, each should be on a separate line following RFC 2822 continuation line conventions.\n\nNote: The Resolution header is required for Standards Track BIPs only. It contains a URL that should point to an email message or other web resource where the pronouncement about the BIP is made.\n\nWhile a BIP is in private discussions (usually during the initial Draft phase), a Discussions-To header will indicate the mailing list or URL where the BIP is being discussed. No Discussions-To header is necessary if the BIP is being discussed privately with the author, or on the bitcoin email mailing lists.\n\nThe Type header specifies the type of BIP: Standards Track, Informational, or Process.\n\nThe Created header records the date that the BIP was assigned a number, while Post-History is used to record the dates of when new versions of the BIP are posted to bitcoin mailing lists. Both headers should be in yyyy-mm-dd format, e.g. 2001-08-14.\n\nBIPs may have a Requires header, indicating the BIP numbers that this BIP depends on.\n\nBIPs may also have a Superseded-By header indicating that a BIP has been rendered obsolete by a later document; the value is the number of the BIP that replaces the current document. The newer BIP must have a Replaces header containing the number of the BIP that it rendered obsolete.\n\n===Auxiliary Files===\n\nBIPs may include auxiliary files such as diagrams. Image files should be included in a subdirectory for that BIP. Auxiliary files must be named BIP-XXXX-Y.ext, where \"XXXX\" is the BIP number, \"Y\" is a serial number (starting at 1), and \"ext\" is replaced by the actual file extension (e.g. \"png\").\n\n==Transferring BIP Ownership==\n\nIt occasionally becomes necessary to transfer ownership of BIPs to a new champion. In general, we'd like to retain the original author as a co-author of the transferred BIP, but that's really up to the original author. A good reason to transfer ownership is because the original author no longer has the time or interest in updating it or following through with the BIP process, or has fallen off the face of the 'net (i.e. is unreachable or not responding to email). A bad reason to transfer ownership is because you don't agree with the direction of the BIP. We try to build consensus around a BIP, but if that's not possible, you can always submit a competing BIP.\n\nIf you are interested in assuming ownership of a BIP, send a message asking to take over, addressed to both the original author and the BIP editor. If the original author doesn't respond to email in a timely manner, the BIP editor will make a unilateral decision (it's not like such decisions can't be reversed :).\n\n==BIP Editors==\n\nThe current BIP editor is Luke Dashjr who can be contacted at [[mailto:luke_bipeditor@dashjr.org|luke_bipeditor@dashjr.org]].\n\n==BIP Editor Responsibilities & Workflow==\n\nThe BIP editor subscribes to the Bitcoin development mailing list. All BIP-related correspondence should be sent (or CC'd) to luke_bipeditor@dashjr.org.\n\nFor each new BIP that comes in an editor does the following:\n\n* Read the BIP to check if it is ready: sound and complete. The ideas must make technical sense, even if they don't seem likely to be accepted.\n* The title should accurately describe the content.\n* Edit the BIP for language (spelling, grammar, sentence structure, etc.), markup (for reST BIPs), code style (examples should match BIP 8 & 7).\n\nIf the BIP isn't ready, the editor will send it back to the author for revision, with specific instructions.\n\nOnce the BIP is ready for the repository it should be submitted as a \"pull request\" to the [https://github.com/bitcoin/bips bitcoin/bips] repository on GitHub where it may get further feedback.\n\nThe BIP editor will:\n\n* Assign a BIP number (almost always just the next available number, but sometimes it's a special/joke number, like 666 or 3141) in the pull request comments.\n\n* Merge the pull request when the author is ready (allowing some time for further peer review).\n\n* List the BIP in [[README.mediawiki]]\n\n* Send email back to the BIP author with next steps (post to bitcoin-dev mailing list).\n\nThe BIP editors are intended to fulfill administrative and editorial responsibilities. The BIP editors monitor BIP changes, and correct any structure, grammar, spelling, or markup mistakes we see.\n\n==History==\n\nThis document was derived heavily from Python's PEP-0001. In many places text was simply copied and modified. Although the PEP-0001 text was written by Barry Warsaw, Jeremy Hylton, and David Goodger, they are not responsible for its use in the Bitcoin Improvement Process, and should not be bothered with technical questions specific to Bitcoin or the BIP process. Please direct all comments to the BIP editors or the Bitcoin development mailing list.\n\n==Changelog==\n\n* 2016-12-14:\n** Closed: [https://github.com/bitcoin/bips/pull/478 Superseded by BIP2]\n* 2016-01-01:\n** Clarified early stages of BIP idea championing, collecting community feedback, etc.\n* 2015-10-10:\n** Added clarifications about submission process and BIP number assignment.", "category": "bips" }, { "instruction": "I'm stuck with 
 - what should I check?",
    "input": "",
    "output": "BIP: 61\n  Layer: Peer Services\n  Title: Reject P2P message\n  Authors: Gavin Andresen \n  Comments-Summary: Controversial; some recommendation, and some discouragement\n  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0061\n  Status: Deployed\n  Type: Specification\n  Assigned: 2014-06-18\n
\n\n==Abstract==\n\nThis BIP describes a new message type for the Bitcoin peer-to-peer network.\n\n==Motivation==\n\nGiving peers feedback about why their blocks or transactions are rejected, or\nwhy they are being banned for not following the protocol helps\ninteroperability between different implementations.\n\nIt also gives SPV (simplified payment verification) clients a hint that something\nmay be wrong when their transactions are rejected due to insufficient priority\nor fees.\n\n==Specification==\n\nData types in this specification are as described at https://en.bitcoin.it/wiki/Protocol_specification\n\n===reject===\n\nOne new message type \"reject\" is introduced. It is sent directly to a peer in response to a \"version\", \"tx\" or \"block\" message.\n\nFor example, the message flow between two peers for a relayed transaction that is rejected for some reason would be:\n\n --> inv\n <-- getdata\n --> tx\n <-- reject\n\nAll implementations of the P2P protocol version 70,002 and later should support the reject message.\n\n====common payload====\n\n\nEvery reject message begins with the following fields. Some messages append extra, message-specific data.\n\n{|\n| Field Size || Name || Data type || Comments\n|-\n| variable || response-to-msg || var_str || Message that triggered the reject\n|-\n| 1 || reject-code || uint8_t || 0x01 through 0x4f (see below)\n|-\n| variable || reason || var_string || Human-readable message for debugging\n|}\n\nThe human-readable string is intended only for debugging purposes; in particular, different implementations may\nuse different strings. The string should not be shown to users or used for anything besides diagnosing\ninteroperability problems.\n\nThe following reject code categories are used; in the descriptions below, \"server\" is the peer generating\nthe reject message, \"client\" is the peer that will receive the message.\n\n{|\n| Range || Category\n|-\n| 0x01-0x0f || Protocol syntax errors\n|-\n| 0x10-0x1f || Protocol semantic errors\n|-\n| 0x40-0x4f || Server policy rule\n|}\n\n==== rejection codes common to all message types ====\n\n{|\n| Code || Description\n|-\n| 0x01 || Message could not be decoded\n|}\n\n==== reject version codes ====\n\nCodes generated during the initial connection process in response to a \"version\" message:\n\n{|\n| Code || Description\n|-\n| 0x11 || Client is an obsolete, unsupported version\n|-\n| 0x12 || Duplicate version message received\n|}\n\n==== reject tx payload, codes ====\n\nTransaction rejection messages extend the basic message with the transaction id hash:\n\n{|\n| Field Size || Name || Data type || Comments\n|-\n| 32 || hash || char[32] || transaction that is rejected\n|}\n\nThe following codes are used:\n\n{|\n| Code || Description\n|-\n| 0x10 || Transaction is invalid for some reason (invalid signature, output value greater than input, etc.)\n|-\n| 0x12 || An input is already spent\n|-\n| 0x40 || Not mined/relayed because it is \"non-standard\" (type or version unknown by the server)\n|-\n| 0x41 || One or more output amounts are below the 'dust' threshold\n|-\n| 0x42 || Transaction does not have enough fee/priority to be relayed or mined\n|}\n\n==== payload, reject block ====\n\nBlock rejection messages extend the basic message with the block header hash:\n\n{|\n| Field Size || Name || Data type || Comments\n|-\n| 32 || hash || char[32] || block (hash of block header) that is rejected\n|}\n\nRejection codes:\n\n{|\n| code || description\n|-\n| 0x10 || Block is invalid for some reason (invalid proof-of-work, invalid signature, etc)\n|-\n| 0x11 || Block's version is no longer supported\n|-\n| 0x43 || Inconsistent with a compiled-in checkpoint\n|}\n\nNote: blocks that are not part of the server's idea of the current best chain, but are otherwise valid, should not trigger reject messages.\n\n== Compatibility ==\n\nThe reject message is backwards-compatible; older peers that do not recognize the reject message will ignore it.\n\n== Implementation notes ==\n\nImplementers must consider what happens if an attacker either sends them\nreject messages for valid transactions/blocks or sends them random\nreject messages, and should beware of possible denial-of-service attacks.\nFor example, notifying the user of every reject message received\nwould make it trivial for an attacker to mount an annoy-the-user attack.\nEven merely writing every reject message to a debugging log could make\nan implementation vulnerable to a fill-up-the-users-disk attack.", "category": "bips" }, { "instruction": "How do I troubleshoot 
 issues?",
    "input": "",
    "output": "BIP: 158\n  Layer: Peer Services\n  Title: Compact Block Filters for Light Clients\n  Authors: Olaoluwa Osuntokun \n           Alex Akselrod \n  Status: Deployed\n  Type: Specification\n  Assigned: 2017-05-24\n  License: CC0-1.0\n  Requires: 157\n
\n\n\n== Abstract ==\n\nThis BIP describes a structure for compact filters on block data, for use in the\nBIP 157 light client protocolbip-0157.mediawiki. The filter\nconstruction proposed is an alternative to Bloom filters, as used in BIP 37,\nthat minimizes filter size by using Golomb-Rice coding for compression. This\ndocument specifies one initial filter type based on this construction that\nenables basic wallets and applications with more advanced smart contracts.\n\n== Motivation ==\n\n[[bip-0157.mediawiki|BIP 157]] defines a light client protocol based on\ndeterministic filters of block content. The filters are designed to\nminimize the expected bandwidth consumed by light clients, downloading filters\nand full blocks. This document defines the initial filter type ''basic''\nthat is designed to reduce the filter size for regular wallets.\n\n== Definitions ==\n\n[]byte represents a vector of bytes.\n\n[N]byte represents a fixed-size byte array with length N.\n\n''CompactSize'' is a compact encoding of unsigned integers used in the Bitcoin\nP2P protocol.\n\n''Bit streams'' are readable and writable streams of individual bits. The\nfollowing functions are used in the pseudocode in this document:\n* new_bit_stream instantiates a new writable bit stream\n* new_bit_stream(vector) instantiates a new bit stream reading data from vector\n* write_bit(stream, b) appends the bit b to the end of the stream\n* read_bit(stream) reads the next available bit from the stream\n* write_bits_big_endian(stream, n, k) appends the k least significant bits of integer n to the end of the stream in big-endian bit order\n* read_bits_big_endian(stream, k) reads the next available k bits from the stream and interprets them as the least significant bits of a big-endian integer\n\nThe key words \"MUST\", \"MUST NOT\", \"REQUIRED\", \"SHALL\", \"SHALL NOT\", \"SHOULD\",\n\"SHOULD NOT\", \"RECOMMENDED\", \"MAY\", and \"OPTIONAL\" in this document are to be\ninterpreted as described in RFC 2119.\n\n== Specification ==\n\n=== Golomb-Coded Sets ===\n\nFor each block, compact filters are derived containing sets of items associated\nwith the block (eg. addresses sent to, outpoints spent, etc.). A set of such\ndata objects is compressed into a probabilistic structure called a\n''Golomb-coded set'' (GCS), which matches all items in the set with probability\n1, and matches other items with probability 1/M for some\ninteger parameter M. The encoding is also parameterized by\nP, the bit length of the remainder code. Each filter defined\nspecifies values for P and M.\n\nAt a high level, a GCS is constructed from a set of N items by:", "category": "bips" }, { "instruction": "What are the best practices for writing the differences sequentially, compressed with Golomb-Rice coding?", "input": "", "output": "The following sections describe each step in greater detail.\n\n==== Hashing Data Objects ====\n\nThe first step in the filter construction is hashing the variable-sized raw\nitems in the set to the range [0, F), where F = N *\nM. Customarily, M is set to 2^P. However, if\none is able to select both Parameters independently, then more optimal values\ncan be\nselectedhttps://gist.github.com/sipa/576d5f09c3b86c3b1b75598d799fc845.\nSet membership queries against the hash outputs will have a false positive rate\nof 1 / M. To avoid integer overflow, the number of items N\nMUST be <2^32 and M MUST be <2^32.\n\nThe items are first passed through the pseudorandom function ''SipHash'', which\ntakes a 128-bit key k and a variable-sized byte vector and produces\na uniformly random 64-bit output. Implementations of this BIP MUST use the\nSipHash parameters c = 2 and d = 4.\n\nThe 64-bit SipHash outputs are then mapped uniformly over the desired range by\nmultiplying with F and taking the top 64 bits of the 128-bit result. This\nalgorithm is a faster alternative to modulo reduction, as it avoids the\nexpensive division\noperationhttps://lemire.me/blog/2016/06/27/a-fast-alternative-to-the-modulo-reduction/.\nNote that care must be taken when implementing this reduction to ensure the\nupper 64 bits of the integer multiplication are not truncated; certain\narchitectures and high level languages may require code that decomposes the\n64-bit multiplication into four 32-bit multiplications and recombines into the\nresult.\n\n
\nhash_to_range(item: []byte, F: uint64, k: [16]byte) -> uint64:\n    return (siphash(k, item) * F) >> 64\n\nhashed_set_construct(raw_items: [][]byte, k: [16]byte, M: uint) -> []uint64:\n    let N = len(raw_items)\n    let F = N * M\n\n    let set_items = []\n\n    for item in raw_items:\n        let set_value = hash_to_range(item, F, k)\n        set_items.append(set_value)\n\n    return set_items\n
\n\n==== Golomb-Rice Coding ====\n\nInstead of writing the items in the hashed set directly to the filter, greater\ncompression is achieved by only writing the differences between successive\nitems in sorted order. Since the items are distributed uniformly, it can be\nshown that the differences resemble a geometric\ndistributionhttps://en.wikipedia.org/wiki/Geometric_distribution.\n''Golomb-Rice''\n''coding''https://en.wikipedia.org/wiki/Golomb_coding#Rice_coding\nis a technique that optimally compresses geometrically distributed values.\n\nWith Golomb-Rice, a value is split into a quotient and remainder modulo\n2^P, which are encoded separately. The quotient q is\nencoded as ''unary'', with a string of q 1's followed by one 0. The\nremainder r is represented in big-endian by P bits. For example,\nthis is a table of Golomb-Rice coded values using P=2:\n\n{| class=\"wikitable\"\n! n !! (q, r) !! c\n|-\n| 0 || (0, 0) || 0 00\n|-\n| 1 || (0, 1) || 0 01\n|-\n| 2 || (0, 2) || 0 10\n|-\n| 3 || (0, 3) || 0 11\n|-\n| 4 || (1, 0) || 10 00\n|-\n| 5 || (1, 1) || 10 01\n|-\n| 6 || (1, 2) || 10 10\n|-\n| 7 || (1, 3) || 10 11\n|-\n| 8 || (2, 0) || 110 00\n|-\n| 9 || (2, 1) || 110 01\n|}\n\n
\ngolomb_encode(stream, x: uint64, P: uint):\n    let q = x >> P\n\n    while q > 0:\n        write_bit(stream, 1)\n        q--\n    write_bit(stream, 0)\n\n    write_bits_big_endian(stream, x, P)\n\ngolomb_decode(stream, P: uint) -> uint64:\n    let q = 0\n    while read_bit(stream) == 1:\n        q++\n\n    let r = read_bits_big_endian(stream, P)\n\n    let x = (q << P) + r\n    return x\n
\n\n==== Set Construction ====\n\nA GCS is constructed from four parameters:\n* L, a vector of N raw items\n* P, the bit parameter of the Golomb-Rice coding\n* M, the inverse of the target false positive rate\n* k, the 128-bit key used to randomize the SipHash outputs\n\nThe result is a byte vector with a minimum size of N * (P + 1)\nbits.\n\nThe raw items in L are first hashed to 64-bit unsigned integers as\nspecified above and sorted. The differences between consecutive values,\nhereafter referred to as ''deltas'', are encoded sequentially to a bit stream\nwith Golomb-Rice coding. Finally, the bit stream is padded with 0's to the\nnearest byte boundary and serialized to the output byte vector.\n\n
\nconstruct_gcs(L: [][]byte, P: uint, k: [16]byte, M: uint) -> []byte:\n    let set_items = hashed_set_construct(L, k, M)\n\n    set_items.sort()\n\n    let output_stream = new_bit_stream()\n\n    let last_value = 0\n    for item in set_items:\n        let delta = item - last_value\n        golomb_encode(output_stream, delta, P)\n        last_value = item\n\n    return output_stream.bytes()\n
\n\n==== Set Querying/Decompression ====\n\nTo check membership of an item in a compressed GCS, one must reconstruct the\nhashed set members from the encoded deltas. The procedure to do so is the\nreverse of the compression: deltas are decoded one by one and added to a\ncumulative sum. Each intermediate sum represents a hashed value in the original\nset. The queried item is hashed in the same way as the set members and compared\nagainst the reconstructed values. Note that querying does not require the entire\ndecompressed set be held in memory at once.\n\n
\ngcs_match(key: [16]byte, compressed_set: []byte, target: []byte, P: uint, N: uint, M: uint) -> bool:\n    let F = N * M\n    let target_hash = hash_to_range(target, F, k)\n\n    stream = new_bit_stream(compressed_set)\n\n    let last_value = 0\n\n    loop N times:\n        let delta = golomb_decode(stream, P)\n        let set_item = last_value + delta\n\n        if set_item == target_hash:\n            return true\n\n        // Since the values in the set are sorted, terminate the search once\n        // the decoded value exceeds the target.\n        if set_item > target_hash:\n            break\n\n        last_value = set_item\n\n    return false\n
\n\nSome applications may need to check for set intersection instead of membership\nof a single item. This can be performed far more efficiently than checking each\nitem individually by leveraging the sorted structure of the compressed GCS.\nFirst the query elements are all hashed and sorted, then compared in order\nagainst the decompressed GCS contents. See\n[[#golomb-coded-set-multi-match|Appendix B]] for pseudocode.\n\n=== Block Filters ===\n\nThis BIP defines one initial filter type:\n* Basic (0x00)\n** M = 784931\n** P = 19\n\n==== Contents ====\n\nThe basic filter is designed to contain everything that a light client needs to\nsync a regular Bitcoin wallet. A basic filter MUST contain exactly the\nfollowing items for each transaction in a block:\n* The previous output script (the script being spent) for each input, except for the coinbase transaction.\n* The scriptPubKey of each output, aside from all OP_RETURN output scripts.\n\nAny \"nil\" items MUST NOT be included into the final set of filter elements.\n\nWe exclude all outputs that start with OP_RETURN in order to allow\nfilters to easily be committed to in the future via a soft-fork. A likely area\nfor future commitments is an additional OP_RETURN output in the\ncoinbase transaction similar to the current witness commitment\nhttps://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki. By\nexcluding all OP_RETURN outputs we avoid a circular dependency\nbetween the commitment, and the item being committed to.\n\n==== Construction ====\n\nThe basic type is constructed as Golomb-coded sets with the following\nparameters.\n\nThe parameter P MUST be set to 19, and the parameter\nM MUST be set to 784931. Analysis has shown that if\none is able to select P and M independently, then\nsetting M=1.497137 * 2^P is close to optimal\nhttps://gist.github.com/sipa/576d5f09c3b86c3b1b75598d799fc845.\n\nEmpirical analysis also shows that these parameters minimize the bandwidth\nutilized, considering both the expected number of blocks downloaded due to false\npositives and the size of the filters themselves.\n\nThe parameter k MUST be set to the first 16 bytes of the hash\n(in standard little-endian representation) of the block for which the filter is\nconstructed. This ensures the key is deterministic while still varying from\nblock to block.\n\nSince the value N is required to decode a GCS, a serialized GCS\nincludes it as a prefix, written as a CompactSize. Thus, the\ncomplete serialization of a filter is:\n* N, encoded as a CompactSize\n* The bytes of the compressed filter itself\n\nA zero element filter MUST be written as one byte containing zeroes.\n\n==== Signaling ====\n\nThis BIP allocates a new service bit:\n\n{| class=\"wikitable\"\n|-\n| NODE_COMPACT_FILTERS\n| style=\"white-space: nowrap;\" | 1 << 6\n| If enabled, the node MUST respond to all BIP 157 messages for filter type 0x00\n|}\n\n== Compatibility ==\n\nThis block filter construction is not incompatible with existing software,\nthough it requires implementation of the new filters.\n\n== Acknowledgments ==\n\nWe would like to thank bfd (from the bitcoin-dev mailing list) for bringing the\nbasis of this BIP to our attention, Greg Maxwell for pointing us in the\ndirection of Golomb-Rice coding and fast range optimization, Pieter Wullie for\nhis analysis of optimal GCS parameters, and Pedro\nMartelletto for writing the initial indexing code for btcd.\n\nWe would also like to thank Dave Collins, JJ Jeffrey, and Eric Lombrozo for\nuseful discussions.\n\n== Reference Implementation ==\n\nLight client: [https://github.com/lightninglabs/neutrino]\n\nFull-node indexing: https://github.com/Roasbeef/btcd/tree/segwit-cbf\n\nGolomb-Rice Coded sets: https://github.com/btcsuite/btcd/tree/master/btcutil/gcs\n\n== Appendix A: Alternatives ==\n\nA number of alternative set encodings were considered before Golomb-coded\nsets were settled upon. In this appendix section, we'll list a few of the\nalternatives along with our rationale for not pursuing them.\n\n==== Bloom Filters ====\n\nBloom Filters are perhaps the best known probabilistic data structure for\ntesting set membership, and were introduced into the Bitcoin protocol with BIP\n37. The size of a Bloom filter is larger than the expected size of a GCS with\nthe same false positive rate, which is the main reason the option was rejected.\n\n==== Cryptographic Accumulators ====\n\nCryptographic\naccumulatorshttps://en.wikipedia.org/wiki/Accumulator_(cryptography)\nare a cryptographic data structures that enable (amongst other operations) a one\nway membership test. One advantage of accumulators are that they are constant\nsize, independent of the number of elements inserted into the accumulator.\nHowever, current constructions of cryptographic accumulators require an initial\ntrusted set up. Additionally, accumulators based on the Strong-RSA Assumption\nrequire mapping set items to prime representatives in the associated group which\ncan be preemptively expensive.\n\n==== Matrix Based Probabilistic Set Data Structures ====\n\nThere exist data structures based on matrix solving which are even more space\nefficient compared to Bloom\nfiltershttps://arxiv.org/pdf/0804.1845.pdf. We instead opted for our\nGCS-based filters as they have a much lower implementation complexity and are\neasier to understand.\n\n== Appendix B: Pseudocode ==\n\n=== Golomb-Coded Set Multi-Match ===\n\n
\ngcs_match_any(key: [16]byte, compressed_set: []byte, targets: [][]byte, P: uint, N: uint, M: uint) -> bool:\n    let F = N * M\n\n    // Map targets to the same range as the set hashes.\n    let target_hashes = []\n    for target in targets:\n        let target_hash = hash_to_range(target, F, k)\n        target_hashes.append(target_hash)\n\n    // Sort targets so matching can be checked in linear time.\n    target_hashes.sort()\n\n    stream = new_bit_stream(compressed_set)\n\n    let value = 0\n    let target_idx = 0\n    let target_val = target_hashes[target_idx]\n\n    loop N times:\n        let delta = golomb_decode(stream, P)\n        value += delta\n\n        inner loop:\n            if target_val == value:\n                return true\n\n            // Move on to the next set value.\n            else if target_val > value:\n                break inner loop\n\n            // Move on to the next target value.\n            else if target_val < value:\n                target_idx++\n\n                // If there are no targets left, then there are no matches.\n                if target_idx == len(targets):\n                    break outer loop\n\n                target_val = target_hashes[target_idx]\n\n    return false\n
\n\n== Appendix C: Test Vectors ==\n\nTest vectors for basic block filters on five testnet blocks, including the filters and filter headers, can be found [[bip-0158/testnet-19.json|here]]. The code to generate them can be found [[bip-0158/gentestvectors.go|here]].\n\n== References ==\n\n\n\n== Copyright ==\n\nThis document is licensed under the Creative Commons CC0 1.0 Universal license.", "category": "bips" }, { "instruction": "Walk me through setting up 
 step by step",
    "input": "",
    "output": "BIP: 119\n  Layer: Consensus (soft fork)\n  Title: CHECKTEMPLATEVERIFY\n  Authors: Jeremy Rubin \n  Status: Draft\n  Type: Specification\n  Assigned: 2020-01-06\n  License: BSD-3-Clause\n
\n\n==Abstract==\n\nThis BIP proposes a new opcode, OP_CHECKTEMPLATEVERIFY, to be activated\nas a change to the semantics of OP_NOP4.\n\n==Summary==\n\nOP_CHECKTEMPLATEVERIFY uses opcode OP_NOP4 (0xb3) as a soft fork upgrade.\n\nOP_CHECKTEMPLATEVERIFY does the following:\n\n* There is at least one element on the stack, fail otherwise\n* The element on the stack is 32 bytes long, NOP otherwise\n* The DefaultCheckTemplateVerifyHash of the transaction at the current input index is equal to the element on the stack, fail otherwise\n\nThe DefaultCheckTemplateVerifyHash commits to the serialized version, locktime, scriptSigs hash (if any\nnon-null scriptSigs), number of inputs, sequences hash, number of outputs, outputs hash, and\ncurrently executing input index.\n\nThe recommended standardness rules additionally:\n\n* Reject non-32 byte as SCRIPT_ERR_DISCOURAGE_UPGRADABLE_NOPS.\n\n==Motivation==\n\nThis BIP introduces a transaction template, a simple spending restriction that\npattern matches a transaction against a hashed transaction specification.\nOP_CHECKTEMPLATEVERIFY reduces many of the trust, interactivity, and storage\nrequirements inherent with the use of pre-signing in applications.\nFor more details on applications, please see the references.\n\n\n==Detailed Specification==\n\nThe below code is the main logic for verifying CHECKTEMPLATEVERIFY, described\nin pythonic pseudocode. The canonical specification for the semantics of\nOP_CHECKTEMPLATEVERIFY as implemented in C++ in the context of Bitcoin Core can\nbe seen in the reference implementation.\n\nThe execution of the opcode is as follows:\n\ndef execute_bip_119(self):\n # Before soft-fork activation / failed activation\n # continue to treat as NOP4\n if not self.flags.script_verify_default_check_template_verify_hash:\n # Potentially set for node-local policy to discourage premature use\n if self.flags.script_verify_discourage_upgradable_nops:\n return self.errors_with(errors.script_err_discourage_upgradable_nops)\n return self.return_as_nop()\n\n # CTV always requires at least one stack argument\n if len(self.stack) < 1:\n return self.errors_with(errors.script_err_invalid_stack_operation)\n\n # CTV only verifies the hash against a 32 byte argument\n if len(self.stack[-1]) == 32:\n # Ensure the precomputed data required for anti-DoS is available,\n # or cache it on first use\n if self.context.precomputed_ctv_data == None:\n self.context.precomputed_ctv_data = self.context.tx.get_default_check_template_precomputed_data()\n\n # If the hashes do not match, return error\n if self.stack[-1] != self.context.tx.get_default_check_template_hash(self.context.nIn, self.context.precomputed_ctv_data):\n return self.errors_with(errors.script_err_template_mismatch)\n\n return self.return_as_nop()\n\n # future upgrade can add semantics for this opcode with different length args\n # so discourage use when applicable\n if self.flags.script_verify_discourage_upgradable_nops:\n return self.errors_with(errors.script_err_discourage_upgradable_nops)\n else:\n return self.return_as_nop()\n\n\nThe computation of this hash can be implemented as specified below (where self\nis the transaction type). Care must be taken that in any validation context,\nthe precomputed data must be initialized to prevent Denial-of-Service attacks.\nAny implementation *must* cache these parts of the hash computation to avoid\nquadratic hashing DoS. All variable length computations must be precomputed\nincluding hashes of the scriptsigs, sequences, and outputs. See the section\n\"Denial of Service and Validation Costs\" below. This is not a performance\noptimization.\n\n\n\ndef ser_compact_size(l):\n r = b\"\"\n if l < 253:\n # Serialize as unsigned char\n r = struct.pack(\"B\", l)\n elif l < 0x10000:\n # Serialize as unsigned char 253 followed by unsigned 2 byte integer (little endian)\n r = struct.pack(\"\n\n\nA PayToBareDefaultCheckTemplateVerifyHash output matches the following template:\n\n", "category": "bips" }, { "instruction": "I want to understand Extra-fast test for pay-to-basic-standard-template CScripts: from a technical perspective", "input": "", "output": "def is_pay_to_bare_default_check_template_verify_hash(self):\n return len(self) == 34 and self[0] == 0x20 and self[-1] == OP_CHECKTEMPLATEVERIFY\n\n\n\n==Deployment==\n\nActivation logic is elided from this BIP and is more appropriately discussed elsewhere.\n\nUntil BIP-119 reaches ACTIVE state and the\nSCRIPT_VERIFY_DEFAULT_CHECK_TEMPLATE_VERIFY_HASH flag is enforced, node implementations should (are recommended to)\nexecute a NOP4 as SCRIPT_ERR_DISCOURAGE_UPGRADABLE_NOPS (to deny entry to the mempool) for policy and must evaluate as\na NOP for consensus (during block validation).\n\nIn order to facilitate using CHECKTEMPLATEVERIFY, the common case of a\nPayToBareDefaultCheckTemplateVerifyHash\nwith no scriptSig data may (is recommended to) be made standard to permit relaying. Future bare scripts may be\nstandardized later as policy changes at the preference of the implementer.\n\n\n==Reference Implementation==\n\nA reference implementation and tests are available here in the PR to Bitcoin Core https://github.com/bitcoin/bitcoin/pull/21702.\n\nIt is not ideal to link to a PR, as it may be rebased and changed, but it is the best place to find\nthe current implementation and review comments of others.\nA recent commit hash in that PR including tests and vectors can be found here https://github.com/jeremyrubin/bitcoin/commit/3109df5616796282786706738994a5b97b8a5a38.\nOnce the PR is merged, this BIP should be updated to point to the specific code released.\n\nTest vectors are available in [/bip-0119/vectors the bip-0119/vectors\ndirectory] for checking compatibility with the reference implementation and BIP.\n\n==Rationale==\n\nOP_CHECKTEMPLATEVERIFY's design is a small code change and simple to analyze. It is\ncompatible with future upgrades if new template types are required\nfor more complex but demonstrably safe use cases.\n\nBelow we'll discuss the rules one-by-one:\n\n====The DefaultCheckTemplateVerifyHash of the transaction at the current input index matches the top of the stack====\n\nThe set of data committed to is a superset of data which can impact the TXID of the transaction,\nother than the inputs. This ensures that for a given known input, the TXIDs can also be known ahead\nof time. Otherwise, CHECKTEMPLATEVERIFY would not be usable for Batched Channel Creation constructions\nas the redemption TXID could be malleated and pre-signed transactions invalidated, unless the channels\nare built using an LN-Symmetry-like protocol. Note that there may be other types of pre-signed contracts that\nmay or may not be able to use LN-Symmetry-like constructs, therefore making TXIDs predictable makes CTV more\ncomposable with arbitrary sub-protocols.\n\n=====Committing to the version and locktime=====\n\nWere these values not committed, it would be possible to delay the spending of\nan output arbitrarily as well as possible to change the TXID.\n\nCommitting these values, rather than restricting them to specific values, is\nmore flexible as it permits users of CHECKTEMPLATEVERIFY to set the version and\nlocktime as they please.\n\n=====Committing to the ScriptSigs Hash=====\n\nThe scriptsig in a segwit transaction must be exactly empty, unless it is a P2SH\nsegwit transaction in which case it must be only the exact redeemscript. P2SH is incompatible\n(unless the P2SH hash is broken) with CHECKTEMPLATEVERIFY because the template hash must commit\nto the ScriptSig, which must contain the redeemscript, which is a hash cycle.\n\nTo prevent malleability when not using a segwit input, we also commit to the\nscriptsig. This makes it possible to use a 2 input CHECKTEMPLATEVERIFY with a legacy pre-signed\nspend, as long as the exact scriptsig for the legacy output is committed. This is more robust than\nsimply disallowing any scriptSig to be set with CHECKTEMPLATEVERIFY.\n\nIf no scriptSigs are set in the transaction, there is no purpose in hashing the data or including it\nin the DefaultCheckTemplateVerifyHash, so we elide it. It is expected to be common that no scriptSigs will be\nset as segwit mandates that the scriptSig must be empty (to avoid malleability).\n\nWe commit to the hash rather than the values themselves as this is already\nprecomputed for each transaction to optimize SIGHASH_ALL signatures.\n\nCommitting to the hash additionally makes it simpler to construct DefaultCheckTemplateVerifyHash safely and unambiguously from\nscript.\n\n=====Committing to the number of inputs=====\n\nIf we allow more than one input to be spent in the transaction then it would be\npossible for two outputs to request payment to the same set of outputs,\nresulting in half the intended payments being discarded, the \"half-spend\" problem.\n\nFurthermore, the restriction on which inputs can be co-spent is critical for\npayments-channel constructs where a stable TXID is a requirement (updates would\nneed to be signed on all combinations of inputs).\n\nHowever, there are legitimate use cases for allowing multiple inputs. For\nexample:\n\nScript paths:\n\n Path A: <+24 hours> OP_CHECKSEQUENCEVERIFY OP_CHECKTEMPLATEVERIFY \n Path B: OP_CHECKTEMPLATEVERIFY \n\nIn this case, there are 24 hours for the output to, with the addition of a\nsecond output, pay Bob 2 BTC. If 24 hours lapses, then Alice may redeem her 1\nBTC from the contract. Both input UTXOs may have the exact same Path B, or only one.\n\nThe issue with these constructs is that there are N! orders that the inputs can\nbe ordered in and it's not generally possible to restrict the ordering.\n\nCHECKTEMPLATEVERIFY allows for users to guarantee the exact number of inputs being\nspent. In general, using CHECKTEMPLATEVERIFY with more than one input is difficult\nand exposes subtle issues, so multiple inputs should not be used except in\nspecific applications.\n\nIn principle, committing to the Sequences Hash (below) implicitly commits to the number of inputs,\nmaking this field strictly redundant. However, separately committing to this number makes it easier\nto construct DefaultCheckTemplateVerifyHash from script.\n\nWe treat the number of inputs as a `uint32_t` because Bitcoin's consensus decoding logic limits vectors\nto `MAX_SIZE=33554432` and that is larger than `uint16_t` and smaller than `uint32_t`. 32 bits is also\nfriendly for manipulation using Bitcoin's current math opcodes, should `OP_CAT` be added. Note that\nthe max inputs in a block is further restricted by the block size to around 25,000, which would fit\ninto a `uint16_t`, but that is an unnecessary abstraction leak.\n\n=====Committing to the Sequences Hash=====\n\nIf we don't commit to the sequences, then the TXID can be malleated. This also allows us to enforce\na relative sequence lock without an OP_CSV. It is insufficient to just pair CHECKTEMPLATEVERIFY\nwith OP_CSV because OP_CSV enforces a minimum nSequence value, not a literal value.\n\nWe commit to the hash rather than the values themselves as this is already\nprecomputed for each transaction to optimize SIGHASH_ALL signatures.\n\nCommitting to the hash additionally makes it simpler to construct DefaultCheckTemplateVerifyHash safely and unambiguously from\nscript.\n\n=====Committing to the Number of Outputs=====\n\nIn principle, committing to the Outputs Hash (below) implicitly commits to the number of outputs,\nmaking this field strictly redundant. However, separately committing to this number makes it easier\nto construct DefaultCheckTemplateVerifyHash from script.\n\nWe treat the number of outputs as a `uint32_t` because a `COutpoint` index is a `uint32_t`.\nFurther, Bitcoin's consensus decoding logic limits vectors to `MAX_SIZE=33554432` and that is\nlarger than `uint16_t` and smaller than `uint32_t`. 32 bits is also friendly for manipulation using\nBitcoin's current math opcodes, should `OP_CAT` be added.\n\n=====Committing to the outputs hash=====\n\nThis ensures that spending the UTXO is guaranteed to create the exact outputs\nrequested.\n\nWe commit to the hash rather than the values themselves as this is already\nprecomputed for each transaction to optimize SIGHASH_ALL signatures.\n\nCommitting to the hash additionally makes it simpler to construct DefaultCheckTemplateVerifyHash safely and unambiguously from\nscript.\n\n=====Committing to the current input's index=====\n\nCommitting to the currently executing input's index is not strictly needed for anti-malleability,\nhowever it does restrict the input orderings eliminating a source of malleability for protocol\ndesigners.\n\nHowever, committing to the index eliminates key-reuse vulnerability to the half-spend problem.\nAs CHECKTEMPLATEVERIFY scripts commit to being spent at particular index, reused instances of these\nscripts cannot be spent at the same index, which implies that they cannot be spent in the same transaction.\nThis makes it safer to design wallet vault contracts without half-spend vulnerabilities.\n\nCommitting to the current index doesn't prevent one from expressing a CHECKTEMPLATEVERIFY which can\nbe spent at multiple indices. In current script, the CHECKTEMPLATEVERIFY operation can be wrapped\nin an OP_IF for each index (or Tapscript branches in the future). If OP_CAT or OP_SHA256STREAM are\nadded to Bitcoin, the index may simply be passed in by the witness before hashing.\n\n=====Committing to Values by Hash=====\n\nCommitting to values by hash makes it easier and more efficient to construct a\nDefaultCheckTemplateVerifyHash\nfrom script. Fields which are not intended to be set may be committed to by hash without incurring\nO(n) overhead to re-hash.\n\nFurthermore, if OP_SHA256STREAM is added in the future, it may be possible to write a script which\nallows adding a single output to a list of outputs without incurring O(n) overhead by committing to\na hash midstate in the script.\n\n=====Using SHA256=====\n\nSHA256 is a 32 byte hash which meets Bitcoin's security standards and is\navailable already inside of Bitcoin Script for programmatic creation of template\nprograms.\n\nRIPEMD160, a 20 byte hash, might also be a viable hash in some contexts and has some benefits. For fee efficiency,\nRIPEMD160 saves 12 bytes. However, RIPEMD160 was not chosen for BIP-119 because it introduces\nrisks around the verification of programs created by third parties to be subject to a\n[birthday-attack https://bitcoin.stackexchange.com/questions/54841/birthday-attack-on-p2sh] on\ntransaction preimages.\n\n=====Using Non-Tagged Hashes=====\n\nThe Taproot/Schnorr BIPs use Tagged Hashes\n(`SHA256(SHA256(tag)||SHA256(tag)||msg)`) to prevent taproot leaves, branches,\ntweaks, and signatures from overlapping in a way that might introduce a security\n[vulnerability https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-June/016091.html].\n\nOP_CHECKTEMPLATEVERIFY is not subject to this sort of vulnerability as the\nhashes are effectively tagged externally, that is, by OP_CHECKTEMPLATEVERIFY\nitself and therefore cannot be confused for another hash.\n\nIt would be a conservative design decision to make it a tagged hash even if\nthere was no obvious benefit and no cost. However, in the future, if OP_CAT were\nto be introduced to Bitcoin, it would make programs which dynamically build\nOP_CHECKTEMPLATEVERIFY hashes less space-efficient. Therefore, bare untagged hashes\nare used in BIP-119.\n\n=====The Ordering of Fields=====\n\nStrictly speaking, the ordering of fields is insignificant. However, with a\ncarefully selected order, the efficiency of future scripts (e.g., those using a\nOP_CAT or OP_SHA256STREAM) may be improved (as described in the Future Upgrades\nsection).\n\nIn particular, the order is selected in order of least likely to change to most.\n\n#nVersion\n#nLockTime\n#scriptSig hash (maybe!)\n#input count\n#sequences hash\n#output count\n#outputs hash\n#input index\n\nSeveral fields are infrequently modified. nVersion should change infrequently. nLockTime should\ngenerally be fixed to 0 (in the case of a payment tree, only the *first* lock time is needed to\nprevent fee-sniping the root). scriptSig hash should generally not be set at all.\n\nSince there are many possible sequences hash for a given input count, the input count comes before\nthe sequences hash.\n\nSince there are many possible outputs hashes for a given out count, the output count comes before\nthe outputs hash.\n\nSince we're generally using a single input to many output design, we're more likely to modify the\noutputs hash than the inputs hash.\n\nWe usually have just a single input on a CHECKTEMPLATEVERIFY script, which would suggest that it\ndoes not make sense for input index to be the last field. However, given the desirability of being\nable to express a \"don't care\" index easily (e.g., for decentralized kickstarter-type transactions),\nthis value is placed last.\n\n===Design Tradeoffs and Risks===\n\nCHECKTEMPLATEVERIFY's design limits script authors to relatively precise template matching. The\nstructure of CHECKTEMPLATEVERIFY template is such that most of the transaction details must be known\nexactly at the time of construction, with the exception of the inputs.\n\nCHECKTEMPLATEVERIFY can be nested -- that is, a transaction that is created by spending an output with a\n` OP_CHECKTEMPLATEVERIFY` restriction may create outputs with ` OP_CHECKTEMPLATEVERIFY` restrictions.\nThis expansion is inherently finite, as re-creating an output with a script containing the hash `` from a transaction\nspending an output with the hash `` creates a hash cycle. This can also be thought of as each template hash `` having\na \"path height\" of the longest chain of possible unbroken `OP_CHECKTEMPLATEVERIFY` verifying transactions, and the path height is\nstrictly decreasing.\n\nFurthermore, templates are restricted to be spendable as a known number of inputs only and\nat a specific input index, preventing unintentional introduction of the 'half spend' problem.\n\nTemplates, as restricted as they are, bear some risks.\n\n====Denial of Service and Validation Costs====\n\nCTV is designed to be able to be validated very cheaply without introducing DoS, either by checking a\nprecomputed hash or computing a hash of fixed length arguments (some of which may be cached from more\nexpensive computations).\n\nIn particular, CTV requires that clients cache the computation of a hash over all the scriptSigs, sequences,\nand outputs. Before CTV, the hash of the scriptSigs was not required. CTV also requires that the presence of\nany non-empty scriptSig be hashed, but this can be handled as a part of the scriptSigs hash.\n\nAs such, evaluating a CTV hash during consensus is always O(1) computation when the caches are available.\nThese caches usually must be available due to similar issues in CHECKSIG behavior. Computing the caches\nis O(T) (the size of the transaction).\n\nAn example of a script that could experience a DoS issue without caching is:\n\n CTV CTV CTV... CTV\n\nSuch a script would cause the interpreter to compute hashes (supposing N CTV's) over O(N*T) data.\nIf the scriptSigs non-nullity is not cached, then the O(T) transaction could be scanned over O(N)\ntimes as well (although cheaper than hashing, still a DoS). As such, CTV caches hashes and computations\nover all variable length fields in a transaction.\n\nFor CTV, the Denial-of-Service exposure and validation costs are relatively clear. Implementers must be careful\nto correctly code CTV to make use of existing caches and cache the (new for CTV) computations over scriptSigs.\nOther more flexible proposals may have a more difficult time solving DoS issues as more complex template computations may\nbe less cacheable and expose issues around quadratic hashing, it is a tradeoff CTV makes in favor of cheap and secure\nvalidation at the expense of flexibility. For example, if CTV allowed the hashing only select outputs by a bitmask,\ncaching of all combinations of outputs would not be possible and would cause a quadratic hashing DoS vulnerability.\n\n====Permanently Unspendable Outputs====\n\nThe preimage argument passed to CHECKTEMPLATEVERIFY may be unknown or otherwise unsatisfiable.\nHowever, requiring knowledge that an address is spendable from is incompatible with sender's ability\nto spend to any address (especially, OP_RETURN). If a sender needs to know the template can be spent\nfrom before sending, they may request a signature of a provably non-transaction challenge string\nfrom the leaves of the CHECKTEMPLATEVERIFY tree.\n\n====Forwarding Addresses====\n\nKey-reuse with CHECKTEMPLATEVERIFY may be used as a form of \"forwarding address contract\".\nA forwarding address is an address which can automatically execute in a predefined way.\nFor example, an exchange's hot wallet might use an address which can automatically be moved to a cold\nstorage address after a relative timeout.\n\nThe issue is that reusing addresses in this way can lead to loss of funds.\nSuppose one creates a template address which forwards 1 BTC to cold storage.\nCreating an output to this address with less than 1 BTC will be frozen permanently.\nPaying more than 1 BTC will lead to the funds in excess of 1BTC to be paid as a large miner fee.\nCHECKTEMPLATEVERIFY could commit to the exact amount of bitcoin provided by the inputs/amount of fee\npaid, but as this is a user error and not a malleability issue this is not done.\nFuture soft-forks could introduce opcodes which allow conditionalizing which template or script\nbranches may be used based on inspecting the amount of funds available in a transaction\n\nAs a general best practice, it is incumbent on Bitcoin users to not reuse any address unless you are\ncertain that the address is acceptable for the payment attempted. This limitation and risk is not\nunique to CHECKTEMPLATEVERIFY. For example, atomic swap scripts are single use once the hash is\nrevealed. Future Taproot scripts may contain many logical branches that would be unsafe for being\nspent to multiple times (e.g., a Hash Time Lock branch should be instantiated with unique hashes\neach time it is used). Keys which have signed a SIGHASH_ANYPREVOUT transaction can similarly become\nreuse-unsafe.\n\nBecause CHECKTEMPLATEVERIFY commits to the input index currently being spent, reused-keys are\nguaranteed to execute in separate transactions which reduces the risk of \"half-spend\" type issues.\n\n====NOP-Default and Recommended Standardness Rules====\n\nIf the argument length is not exactly 32, CHECKTEMPLATEVERIFY treats it as a NOP during\nconsensus validation. Implementations are recommended to fail in such circumstances during non-consensus\nrelaying and mempool validation. In particular, making an invalid-length argument a failure aids future\nsoft-forks upgrades to be able to rely on the tighter standard restrictions to safely loosen\nthe restrictions for standardness while tightening them for consensus with the upgrade's rules.\n\nThe standardness rules may lead an unscrupulous script developer to accidentally rely on the\nstricter standardness rules to be enforced during consensus. Should that developer submit a\ntransaction directly to the network relying on standardness rejection, a standardness-invalid but\nconsensus-valid transaction may be caused, leading to a potential loss of funds.\n\n====Feature Redundancy====\n\nThere are other opcodes that, if implemented, could make the CHECKTEMPLATEVERIFY's functionality redundant.\nHowever, given CHECKTEMPLATEVERIFY's simple semantics and low on chain cost it's likely that it\nwould continue to be favored even if redundant with other capabilities. Or, in the case of opcodes\nsuch as OP_VAULT, OP_CHECKCONTRACTVERIFY, and OP_TXHASH, OP_CHECKTEMPLATEVERIFY is a part of their\ncurrently proposed implementations.\n\nMore powerful opcodes, like OP_COV proposed in MES16 or OP_TXHASH, would also bring some benefits in terms of\nimproving the ability to pay fees endogenously rather than relying on exogenous child-pays-for-parent or\nother fee paying mechanisms such as transaction sponsors. However, these features come at substantially\nincreased complexity and room for behaviors unintended by the application developer.\n\nAlternatively, SIGHASH_ANYPREVOUTANYSCRIPT can be used to implement something similar to templates,\nvia a scriptPubKey like:\n\n OP_CHECKSIG\n\nSIGHASH_ANYPREVOUTANYSCRIPT capabilities\nabove are similar to what CHECKTEMPLATEVERIFY offers. The key functional\ndifference between SIGHASH_ANYPREVOUTANYSCRIPT and OP_CHECKTEMPLATEVERIFY is\nthat OP_CHECKTEMPLATEVERIFY restricts the number of additional inputs and\nprecludes dynamically determined change outputs while\nSIGHASH_ANYPREVOUTANYSCRIPT can be combined with SIGHASH_SINGLE or\nSIGHASH_ANYONECANPAY. For the additional inputs, OP_CHECKTEMPLATEVERIFY also\ncommits to the scriptsig and sequence, which allows for specifying specific P2SH\nscripts (or segwit v0 P2SH) which have some use cases. Furthermore,\nCHECKTEMPLATEVERIFY has benefits in terms of script size (depending on choice of\nPK, SIGHASH_ANYPREVOUTANYSCRIPT may use about 2x-3x the bytes) and verification\nspeed, as OP_CHECKTEMPLATEVERIFY requires only hash computation rather than\nsignature operations. This can be significant when constructing large payment\ntrees or programmatic compilations. CHECKTEMPLATEVERIFY also has a feature-wise\nbenefit in that it provides a robust pathway for future template upgrades, as proposed\nin OP_TXHASH.\n\nOP_CHECKSIGFROMSTACKVERIFY along with OP_CAT may also be used to emulate\nCHECKTEMPLATEVERIFY. However such constructions are more complicated to implement in application\nscripts than CHECKTEMPLATEVERIFY, and encumber additional verification overhead absent\nfrom CHECKTEMPLATEVERIFY.\n\nGiven the simplicity of this approach to implement and analyze, and the benefits realizable by user\napplications, CHECKTEMPLATEVERIFY's single template based approach is proposed in lieu of a generalized\nsystem for specifying transactions in script.\n\n\n====Future Upgrades====\n\nThis section describes updates to OP_CHECKTEMPLATEVERIFY that are possible in\nthe future as well as synergies with other possible upgrades.\n\n=====CHECKTEMPLATEVERIFY Versions=====\n\nOP_CHECKTEMPLATEVERIFY currently only verifies properties of 32 byte arguments.\nIn the future, meaning could be ascribed to other length arguments. For\nexample, a 33-byte argument could just the last byte as a control program. In\nthat case, DefaultCheckTemplateVerifyHash could be computed when the flag byte\nis set to CTVHASH_ALL. Other programs could be added similar to a SIGHASH_TYPE.\nFor example, CTVHASH_GROUP could read data from the Taproot Annex for\ncompatibility with SIGHASH_GROUP type proposals and allow dynamic malleability\nof which indexes get hashed for bundling.\n\nThe work done for the OP_TXHASH pre-BIP details one approach to upgrading the\nOP_CHECKTEMPLATEVERIFY semantics.\n\n=====OP_CHECKSIGFROMSTACKVERIFY=====\n\nWere both OP_CHECKTEMPLATEVERIFY and OP_CHECKSIGFROMSTACKVERIFY to be added to\nBitcoin, it would be possible to implement a variant of LN-Symmetry's floating\ntransactions using the following script:\n\n witness(S+n): \n program(S): OP_CHECKTEMPLATEVERIFY OP_CHECKSIGFROMSTACKVERIFY OP_CHECKLOCKTIMEVERIFY\n\nCompared to SIGHASH_ANYPREVOUTANYSCRIPT, because OP_CHECKTEMPLATEVERIFY does not\nallow something similar to SIGHASH_ANYONECANPAY or SIGHASH_SINGLE, protocol\nimplementers might sign transactions with Ephemeral Anchors or additional Inputs\nfor paying fees or an alternative such as transaction sponsors might be considered.\n\nNote that this use of OP_CHECKSIGFROMSTACKVERIFY and OP_CHECKTEMPLATEVERIFY, without the ` OP_CHECKLOCKTIMEVERIFY` ratchet,\nenables a form of self-reproducing automata address with a one-time-trusted-setup, albeit with limited utility given the specifics\nof OP_CHECKTEMPLATEVERIFY's DefaultCheckTemplateVerifyHash. In comparison, SIGHASH_ANYPREVOUT enables a more\npowerful self-reproducing automata (colloquially called SpookChains), that uses a variety of combinations of SIGHASH flags\nto be able to restrict state transitions based on amount.\n\n=====OP_AMOUNTVERIFY=====\n\nAn opcode which verifies the exact amount that is being spent in the\ntransaction, the amount paid as fees, or made available in a given output could\nbe used to make safer OP_CHECKTEMPLATEVERIFY addresses. For instance, if the\nOP_CHECKTEMPLATEVERIFY program P expects exactly S satoshis, sending S-1\nsatoshis would result in a frozen UTXO and sending S+n satoshis would result in\nn satoshis being paid to fee. A range check could restrict the program to only\napply for expected values and default to a keypath otherwise, e.g.:\n\n IF OP_AMOUNTVERIFY OP_GREATER CHECKSIG ELSE OP_CHECKTEMPLATEVERIFY\n\n=====OP_CAT/OP_SHA256STREAM=====\n\nOP_CHECKTEMPLATEVERIFY is (as described in the Ordering of Fields section)\nefficient for specifying transactions dynamically from script should Bitcoin get enhanced\ndata manipulation opcodes.\n\nAs an example, the following code checks an input index argument and\nconcatenates it to the template and checks the template matches the transaction.\n\n OP_SIZE 4 OP_EQUALVERIFY\n \n OP_SWAP OP_CAT OP_SHA256 OP_CHECKTEMPLATEVERIFY\n\nNote that were OP_CAT to be introduced with a size limit, e.g. 520 bytes, one would be limited\nto use it to introspect transactions with 12 inputs and 12 outputs (depending on script type).\n\n== Backwards Compatibility ==\n\nOP_CHECKTEMPLATEVERIFY replaces a OP_NOP4 with stricter verification semantics. Therefore, scripts\nwhich previously were valid will cease to be valid with this change. Stricter verification semantics\nfor an OP_NOP are a soft fork, so existing software will be fully functional without upgrade except\nfor mining and block validation. Similar soft forks for OP_CHECKSEQUENCEVERIFY and OP_CHECKLOCKTIMEVERIFY\n(see BIP-0065 and BIP-0112) have similarly changed OP_NOP semantics without introducing compatibility issues.\n\nIn contrast to previous forks, OP_CHECKTEMPLATEVERIFY's reference implementation does not allow transactions with spending\nscripts using it to be accepted to the mempool or relayed under standard policy until the new rule is active. Other implementations\nare recommended to follow this rule as well, but not required.\n\nOlder wallet software will be able to accept spends from OP_CHECKTEMPLATEVERIFY outputs, but will\nrequire an upgrade in order to treat PayToBareDefaultCheckTemplateVerifyHash chains with a confirmed ancestor as\nbeing \"trusted\" (i.e., eligible for spending before the transaction is confirmed).\n\nBackports of OP_CHECKTEMPLATEVERIFY can be trivially prepared (see the reference implementation)\nfor older node versions that can be patched but not upgraded to a newer major release.\n\n== Script Compatibility ==\n\nOP_CHECKTEMPLATEVERIFY is made available in all script versions. Application developers should\nnote that P2SH and P2SH Segwit, which reveal the program in the scriptSig, may not use ` CTV`\nlike fragments in their program as the scriptSig commitment creates a hash cycle.\n\n== References ==\n\n*[https://utxos.org utxos.org informational site]\n*[https://covenants.info covenant informational site]\n*[https://learn.sapio-lang.org Sapio Bitcoin smart contract language]\n*[https://rubin.io/advent21 27 Blog Posts on building smart contracts with Sapio and CTV, including examples described here.]\n*[https://www.youtube.com/watch?v=YxsjdIl0034&t=2451 Scaling Bitcoin Presentation]\n*[https://bitcoinops.org/en/newsletters/2019/05/29/ Optech Newsletter Covering OP_CHECKOUTPUTSHASHVERIFY]\n*[https://rubin.io/public/pdfs/multi-txn-contracts.pdf Structuring Multi Transaction Contracts in Bitcoin]\n*[https://github.com/jeremyrubin/lazuli Lazuli Notes (ECDSA based N-of-N Signatures for Certified Post-Dated UTXOs)]\n*[https://web.archive.org/web/20220203124718/https://fc16.ifca.ai/bitcoin/papers/MES16.pdf Bitcoin Covenants]\n*[https://bitcointalk.org/index.php?topic=278122.0 CoinCovenants using SCIP signatures, an amusingly bad idea.]\n*[https://fc17.ifca.ai/bitcoin/papers/bitcoin17-final28.pdf Enhancing Bitcoin Transactions with Covenants]\n*[https://github.com/jamesob/simple-ctv-vault Simple CTV Vaults]\n*[https://github.com/kanzure/python-vaults Python Vaults]\n*[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019808.html CTV Dramatically Improves DLCs]\n*[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020225.html Calculus of Covenants]\n*[https://rubin.io/bitcoin/2021/12/10/advent-13/ Payment Pools with CTV]\n*[https://rubin.io/bitcoin/2021/12/11/advent-14/ Channels with CTV]\n*[https://rubin.io/bitcoin/2021/12/09/advent-12/ Congestion Control with CTV]\n*[https://rubin.io/bitcoin/2021/12/07/advent-10/ Building Vaults on Bitcoin]\n*[https://arkdev.info/ (Ark Labs) Ark Documentation]\n*[https://docs.second.tech/protocol/intro/ (Second) Ark Documentation]\n*[https://rubin.io/bitcoin/2022/09/14/drivechain-apo/ SpookChains]\n*[https://github.com/bitcoin/bips/pull/1500 OP_TXHASH]\n\n\n===Note on Similar Alternatives===\n\nAn earlier version of CHECKTEMPLATEVERIFY, CHECKOUTPUTSHASHVERIFY, is withdrawn\nin favor of CHECKTEMPLATEVERIFY. CHECKOUTPUTSHASHVERIFY did not commit to the\nversion or lock time and was thus insecure.\n\nCHECKTEMPLATEVERIFY could also be implemented as an extension to Taproot, and was\nproposed this way earlier. However, particular applications may want to use OP_CHECKTEMPLATEVERIFY\nin bare legacy scripts to maximize efficiency.\n\nCHECKTEMPLATEVERIFY has also been previously referred to as OP_SECURETHEBAG, which is mentioned here\nto aid in searching and referencing discussion on this BIP.\n\n==Copyright==\n\nThis document is licensed under the 3-clause BSD license.", "category": "bips" }, { "instruction": "Can you explain 
 like we're having a beer and talking Bitcoin?",
    "input": "",
    "output": "BIP: 65\n  Layer: Consensus (soft fork)\n  Title: OP_CHECKLOCKTIMEVERIFY\n  Authors: Peter Todd \n  Status: Deployed\n  Type: Specification\n  Assigned: 2014-10-01\n  License: PD\n
\n\n==Abstract==\n\nThis BIP describes a new opcode (OP_CHECKLOCKTIMEVERIFY) for the Bitcoin\nscripting system that allows a transaction output to be made unspendable until\nsome point in the future.\n\n\n==Summary==\n\nCHECKLOCKTIMEVERIFY redefines the existing NOP2 opcode. When executed, if\nany of the following conditions are true, the script interpreter will terminate\nwith an error:\n\n* the stack is empty; or\n* the top item on the stack is less than 0; or\n* the lock-time type (height vs. timestamp) of the top stack item and the nLockTime field are not the same; or\n* the top stack item is greater than the transaction's nLockTime field; or\n* the nSequence field of the txin is 0xffffffff;\n\nOtherwise, script execution will continue as if a NOP had been executed.\n\nThe nLockTime field in a transaction prevents the transaction from being mined\nuntil either a certain block height, or block time, has been reached. By\ncomparing the argument to CHECKLOCKTIMEVERIFY against the nLockTime field, we\nindirectly verify that the desired block height or block time has been reached;\nuntil that block height or block time has been reached the transaction output\nremains unspendable.\n\n\n==Motivation==\n\nThe nLockTime field in transactions can be used to prove that it is\n''possible'' to spend a transaction output in the future, by constructing a\nvalid transaction spending that output with the nLockTime field set.\n\nHowever, the nLockTime field can't prove that it is ''impossible'' to spend a\ntransaction output until some time in the future, as there is no way to know if\na valid signature for a different transaction spending that output has been\ncreated.\n\n\n===Escrow===\n\nIf Alice and Bob jointly operate a business they may want to\nensure that all funds are kept in 2-of-2 multisig transaction outputs that\nrequire the co-operation of both parties to spend. However, they recognise that\nin exceptional circumstances such as either party getting \"hit by a bus\" they\nneed a backup plan to retrieve the funds. So they appoint their lawyer, Lenny,\nto act as a third-party.\n\nWith a standard 2-of-3 CHECKMULTISIG at any time Lenny could conspire with\neither Alice or Bob to steal the funds illegitimately. Equally Lenny may prefer\nnot to have immediate access to the funds to discourage bad actors from\nattempting to get the secret keys from him by force.\n\nHowever, with CHECKLOCKTIMEVERIFY the funds can be stored in scriptPubKeys of\nthe form:\n\n IF\n CHECKLOCKTIMEVERIFY DROP\n CHECKSIGVERIFY\n 1\n ELSE\n 2\n ENDIF\n 2 CHECKMULTISIG\n\nAt any time the funds can be spent with the following scriptSig:\n\n 0 0\n\nAfter 3 months have passed Lenny and one of either Alice or Bob can spend the\nfunds with the following scriptSig:\n\n 0 1\n\n\n===Non-interactive time-locked refunds===\n\nThere exist a number of protocols where a transaction output is created that\nrequires the co-operation of both parties to spend the output. To ensure the\nfailure of one party does not result in the funds becoming lost, refund\ntransactions are setup in advance using nLockTime. These refund transactions\nneed to be created interactively, and additionally, are currently vulnerable to\ntransaction malleability. CHECKLOCKTIMEVERIFY can be used in these protocols,\nreplacing the interactive setup with a non-interactive setup, and additionally,\nmaking transaction malleability a non-issue.\n\n\n====Two-factor wallets====\n\nServices like GreenAddress store bitcoins with 2-of-2 multisig scriptPubKey's\nsuch that one keypair is controlled by the user, and the other keypair is\ncontrolled by the service. To spend funds the user uses locally installed\nwallet software that generates one of the required signatures, and then uses a\n2nd-factor authentication method to authorize the service to create the second\nSIGHASH_NONE signature that is locked until some time in the future and sends\nthe user that signature for storage. If the user needs to spend their funds and\nthe service is not available, they wait until the nLockTime expires.\n\nThe problem is there exist numerous occasions the user will not have a valid\nsignature for some or all of their transaction outputs. With\nCHECKLOCKTIMEVERIFY rather than creating refund signatures on demand\nscriptPubKeys of the following form are used instead:\n\n IF\n CHECKSIGVERIFY\n ELSE\n CHECKLOCKTIMEVERIFY DROP\n ENDIF\n CHECKSIG\n\nNow the user is always able to spend their funds without the co-operation of\nthe service by waiting for the expiry time to be reached.\n\n\n====Payment Channels====\n\nJeremy Spilman style payment channels first setup a deposit controlled by\n2-of-2 multisig, tx1, and then adjust a second transaction, tx2, that spends\nthe output of tx1 to payor and payee. Prior to publishing tx1 a refund\ntransaction is created, tx3, to ensure that should the payee vanish the payor\ncan get their deposit back. The process by which the refund transaction is\ncreated is currently vulnerable to transaction malleability attacks, and\nadditionally, requires the payor to store the refund. Using the same\nscriptPubKey form as in the Two-factor wallets example solves both these issues.\n\n\n===Trustless Payments for Publishing Data===\n\nThe PayPub protocol makes it possible to pay for information in a trustless way\nby first proving that an encrypted file contains the desired data, and secondly\ncrafting scriptPubKeys used for payment such that spending them reveals the\nencryption keys to the data. However the existing implementation has a\nsignificant flaw: the publisher can delay the release of the keys indefinitely.\n\nThis problem can be solved interactively with the refund transaction technique;\nwith CHECKLOCKTIMEVERIFY the problem can be non-interactively solved using\nscriptPubKeys of the following form:\n\n IF\n HASH160 EQUALVERIFY\n CHECKSIG\n ELSE\n CHECKLOCKTIMEVERIFY DROP\n CHECKSIG\n ENDIF\n\nThe buyer of the data is now making a secure offer with an expiry time. If the\npublisher fails to accept the offer before the expiry time is reached the buyer\ncan cancel the offer by spending the output.\n\n\n===Proving sacrifice to miners' fees===\n\nProving the sacrifice of some limited resource is a common technique in a\nvariety of cryptographic protocols. Proving sacrifices of coins to mining fees\nhas been proposed as a ''universal public good'' to which the sacrifice could\nbe directed, rather than simply destroying the coins. However doing so is\nnon-trivial, and even the best existing technique - announce-commit sacrifices\n- could encourage mining centralization. CHECKLOCKTIMEVERIFY can be used to\ncreate outputs that are provably spendable by anyone (thus to mining fees\nassuming miners behave optimally and rationally) but only at a time\nsufficiently far into the future that large miners can't profitably sell the\nsacrifices at a discount.\n\n\n===Freezing Funds===\n\nIn addition to using cold storage, hardware wallets, and P2SH multisig outputs\nto control funds, now funds can be frozen in UTXOs directly on the blockchain.\nWith the following scriptPubKey, nobody will be able to spend the encumbered\noutput until the provided expiry time. This ability to freeze funds reliably may\nbe useful in scenarios where reducing duress or confiscation risk is desired.\n\n CHECKLOCKTIMEVERIFY DROP DUP HASH160 EQUALVERIFY CHECKSIG\n\n\n===Replacing the nLockTime field entirely===\n\nAs an aside, note how if the SignatureHash() algorithm could optionally cover\npart of the scriptSig the signature could require that the scriptSig contain\nCHECKLOCKTIMEVERIFY opcodes, and additionally, require that they be executed.\n(the CODESEPARATOR opcode came very close to making this possible in v0.1 of\nBitcoin) This per-signature capability could replace the per-transaction\nnLockTime field entirely as a valid signature would now be the proof that a\ntransaction output ''can'' be spent.\n\n\n==Detailed Specification==\n\nRefer to the reference implementation, reproduced below, for the precise\nsemantics and detailed rationale for those semantics.\n\n\n case OP_NOP2:\n {\n // CHECKLOCKTIMEVERIFY\n //\n // (nLockTime -- nLockTime )\n\n if (!(flags & SCRIPT_VERIFY_CHECKLOCKTIMEVERIFY))\n break; // not enabled; treat as a NOP\n\n if (stack.size() < 1)\n return false;\n\n // Note that elsewhere numeric opcodes are limited to\n // operands in the range -2**31+1 to 2**31-1, however it is\n // legal for opcodes to produce results exceeding that\n // range. This limitation is implemented by CScriptNum's\n // default 4-byte limit.\n //\n // If we kept to that limit we'd have a year 2038 problem,\n // even though the nLockTime field in transactions\n // themselves is uint32 which only becomes meaningless\n // after the year 2106.\n //\n // Thus as a special case we tell CScriptNum to accept up\n // to 5-byte bignums, which are good until 2**32-1, the\n // same limit as the nLockTime field itself.\n const CScriptNum nLockTime(stacktop(-1), 5);\n\n // In the rare event that the argument may be < 0 due to\n // some arithmetic being done first, you can always use\n // 0 MAX CHECKLOCKTIMEVERIFY.\n if (nLockTime < 0)\n return false;\n\n // There are two types of nLockTime: lock-by-blockheight\n // and lock-by-blocktime, distinguished by whether\n // nLockTime < LOCKTIME_THRESHOLD.\n //\n // We want to compare apples to apples, so fail the script\n // unless the type of nLockTime being tested is the same as\n // the nLockTime in the transaction.\n if (!(\n (txTo.nLockTime < LOCKTIME_THRESHOLD && nLockTime < LOCKTIME_THRESHOLD) ||\n (txTo.nLockTime >= LOCKTIME_THRESHOLD && nLockTime >= LOCKTIME_THRESHOLD)\n ))\n return false;\n\n // Now that we know we're comparing apples-to-apples, the\n // comparison is a simple numeric one.\n if (nLockTime > (int64_t)txTo.nLockTime)\n return false;\n\n // Finally the nLockTime feature can be disabled and thus\n // CHECKLOCKTIMEVERIFY bypassed if every txin has been\n // finalized by setting nSequence to maxint. The\n // transaction would be allowed into the blockchain, making\n // the opcode ineffective.\n //\n // Testing if this vin is not final is sufficient to\n // prevent this condition. Alternatively we could test all\n // inputs, but testing just this input minimizes the data\n // required to prove correct CHECKLOCKTIMEVERIFY execution.\n if (txTo.vin[nIn].IsFinal())\n return false;\n\n break;\n\n }\n\nhttps://github.com/petertodd/bitcoin/commit/ab0f54f38e08ee1e50ff72f801680ee84d0f1bf4\n\n\n==Deployment==\n\nWe reuse the double-threshold IsSuperMajority() switchover mechanism used in\nBIP66 with the same thresholds, but for nVersion = 4. The new rules are\nin effect for every block (at height H) with nVersion = 4 and at least\n750 out of 1000 blocks preceding it (with heights H-1000..H-1) also\nhave nVersion >= 4. Furthermore, when 950 out of the 1000 blocks\npreceding a block do have nVersion >= 4, nVersion < 4 blocks become\ninvalid, and all further blocks enforce the new rules.\n\nIt should be noted that BIP9 involves permanently setting a high-order bit to\n1 which results in nVersion >= all prior IsSuperMajority() soft-forks and thus\nno bits in nVersion are permanently lost.\n\n\n===SPV Clients===\n\nWhile SPV clients are (currently) unable to validate blocks in general,\ntrusting miners to do validation for them, they are able to validate block\nheaders and thus can validate a subset of the deployment rules. SPV clients\nshould reject nVersion < 4 blocks if 950 out of 1000 preceding blocks have\nnVersion >= 4 to prevent false confirmations from the remaining 5% of\nnon-upgraded miners when the 95% threshold has been reached.\n\n\n==Credits==\n\nThanks goes to Gregory Maxwell for suggesting that the argument be compared\nagainst the per-transaction nLockTime, rather than the current block height and\ntime.\n\n\n==References==\n\nPayPub\n\n* https://github.com/unsystem/paypub\n\nJeremy Spilman Payment Channels\n\n* https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-April/002433.html\n\n\n==Implementations==\n\nPython / python-bitcoinlib\n\n* https://github.com/petertodd/checklocktimeverify-demos\n\nJavaScript / Node.js / bitcore\n\n* https://github.com/mruddy/bip65-demos\n\n\n==Copyright==\n\nThis document is placed in the public domain.", "category": "bips" }, { "instruction": "How would you explain 
 to someone who knows Bitcoin basics?",
    "input": "",
    "output": "BIP: 341\n  Layer: Consensus (soft fork)\n  Title: Taproot: SegWit version 1 spending rules\n  Authors: Pieter Wuille \n           Jonas Nick \n           Anthony Towns \n  Comments-Summary: No comments yet.\n  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0341\n  Status: Deployed\n  Type: Specification\n  Assigned: 2020-01-19\n  License: BSD-3-Clause\n  Discussion: 2019-05-06: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016914.html [bitcoin-dev] Taproot proposal\n              2019-10-09: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-October/017378.html [bitcoin-dev] Taproot updates\n  Requires: 340\n
\n\n==Introduction==\n\n===Abstract===\n\nThis document proposes a new SegWit version 1 output type, with spending rules based on Taproot, Schnorr signatures, and Merkle branches.\n\n===Copyright===\n\nThis document is licensed under the 3-clause BSD license.\n\n===Motivation===\n\nThis proposal aims to improve privacy, efficiency, and flexibility of Bitcoin's scripting capabilities without adding new security assumptions'''What does not adding security assumptions mean?''' Unforgeability of signatures is a necessary requirement to prevent theft. At least when treating script execution as a digital signature scheme itself, unforgeability can be [https://github.com/apoelstra/taproot proven] in the Random Oracle Model assuming the Discrete Logarithm problem is hard. A [https://nbn-resolving.de/urn:nbn:de:hbz:294-60803 proof] for unforgeability of ECDSA in the current script system needs non-standard assumptions on top of that. Note that it is hard in general to model exactly what security for script means, as it depends on the policies and protocols used by wallet software.. Specifically, it seeks to minimize how much information about the spendability conditions of a transaction output is revealed on chain at creation or spending time and to add a number of upgrade mechanisms, while fixing a few minor but long-standing issues.\n\n==Design==\n\nA number of related ideas for improving Bitcoin's scripting capabilities have been previously proposed: Schnorr signatures ([[bip-0340.mediawiki|BIP340]]), Merkle branches (\"MAST\", [[bip-0114.mediawiki|BIP114]], [[bip-0117.mediawiki|BIP117]]), new sighash modes ([[bip-0118.mediawiki|BIP118]]), new opcodes like CHECKSIGFROMSTACK, [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015614.html Taproot], [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/015700.html Graftroot], [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-July/016249.html G'root], and [https://bitcointalk.org/index.php?topic=1377298.0 cross-input aggregation].\n\nCombining all these ideas in a single proposal would be an extensive change, be hard to review, and likely miss new discoveries that otherwise could have been made along the way. Not all are equally mature as well. For example, cross-input aggregation [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-March/015838.html interacts] in complex ways with upgrade mechanisms, and solutions to that are still [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-October/016461.html in flux]. On the other hand, separating them all into independent upgrades would reduce the efficiency and privacy gains to be had, and wallet and service providers may not be inclined to go through many incremental updates. Therefore, we're faced with a tradeoff between functionality and scope creep. In this design we strike a balance by focusing on the structural script improvements offered by Taproot and Merkle branches, as well as changes necessary to make them usable and efficient. For things like sighashes and opcodes we include fixes for known problems, but exclude new features that can be added independently with no downsides.\n\nAs a result we choose this combination of technologies:\n* '''Merkle branches''' let us only reveal the actually executed part of the script to the blockchain, as opposed to all possible ways a script can be executed. Among the various known mechanisms for implementing this, one where the Merkle tree becomes part of the script's structure directly maximizes the space savings, so that approach is chosen.\n* '''Taproot''' on top of that lets us merge the traditionally separate pay-to-pubkey and pay-to-scripthash policies, making all outputs spendable by either a key or (optionally) a script, and indistinguishable from each other. As long as the key-based spending path is used for spending, it is not revealed whether a script path was permitted as well, resulting in space savings and an increase in scripting privacy at spending time.\n* Taproot's advantages become apparent under the assumption that most applications involve outputs that could be spent by all parties agreeing. That's where '''Schnorr''' signatures come in, as they permit [https://eprint.iacr.org/2018/068 key aggregation]: a public key can be constructed from multiple participant public keys, and which requires cooperation between all participants to sign for. Such multi-party public keys and signatures are indistinguishable from their single-party equivalents. This means that with taproot most applications can use the key-based spending path, which is both efficient and private. This can be generalized to arbitrary M-of-N policies, as Schnorr signatures support threshold signing, at the cost of more complex setup protocols.\n* As Schnorr signatures also permit '''batch validation''', allowing multiple signatures to be validated together more efficiently than validating each one independently, we make sure all parts of the design are compatible with this.\n* Where unused bits appear as a result of the above changes, they are reserved for mechanisms for '''future extensions'''. As a result, every script in the Merkle tree has an associated version such that new script versions can be introduced with a soft fork while remaining compatible with BIP 341. Additionally, future soft forks can make use of the currently unused annex in the witness (see [[bip-0341.mediawiki#rationale|Rationale]]).\n* While the core semantics of the '''signature hashing algorithm''' are not changed, a number of improvements are included in this proposal. The new signature hashing algorithm fixes the verification capabilities of offline signing devices by including amount and scriptPubKey in the signature message, avoids unnecessary hashing, uses '''tagged hashes''' and defines a default sighash byte.\n* The '''public key is directly included in the output''' in contrast to typical earlier constructions which store a hash of the public key or script in the output. This has the same cost for senders and is more space efficient overall if the key-based spending path is taken. '''Why is the public key directly included in the output?''' While typical earlier constructions store a hash of a script or a public key in the output, this is rather wasteful when a public key is always involved. To guarantee batch verifiability, the public key must be known to every verifier, and thus only revealing its hash as an output would imply adding an additional 32 bytes to the witness. Furthermore, to maintain [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012198.html 128-bit collision security] for outputs, a 256-bit hash would be required anyway, which is comparable in size (and thus in cost for senders) to revealing the public key directly. While the usage of public key hashes is often said to protect against ECDLP breaks or quantum computers, this protection is very weak at best: transactions are not protected while being confirmed, and a very [https://web.archive.org/web/20220531184542/https://twitter.com/pwuille/status/1108085284862713856 large portion] of the currency's supply is not under such protection regardless. Actual resistance to such systems can be introduced by relying on different cryptographic assumptions, but this proposal focuses on improvements that do not change the security model.\n\nInformally, the resulting design is as follows: a new witness version is added (version 1), whose programs consist of 32-byte encodings of points ''Q''. ''Q'' is computed as ''P + hash(P||m)G'' for a public key ''P'', and the root ''m'' of a Merkle tree whose leaves consist of a version number and a script. These outputs can be spent directly by providing a signature for ''Q'', or indirectly by revealing ''P'', the script and leaf version, inputs that satisfy the script, and a Merkle path that proves ''Q'' committed to that leaf. All hashes in this construction (the hash for computing ''Q'' from ''P'', the hashes inside the Merkle tree's inner nodes, and the signature hashes used) are tagged to guarantee domain separation.\n\n== Specification ==\n\nThis section specifies the Taproot consensus rules. Validity is defined by exclusion: a block or transaction is valid if no condition exists that marks it failed.\n\nThe notation below follows that of [[bip-0340.mediawiki#design|BIP340]]. This includes the ''hashtag(x)'' notation to refer to ''SHA256(SHA256(tag) || SHA256(tag) || x)''. To the best of the authors' knowledge, no existing use of SHA256 in Bitcoin feeds it a message that starts with two single SHA256 outputs, making collisions between ''hashtag'' with other hashes extremely unlikely.\n\n=== Script validation rules ===\n\nA Taproot output is a native SegWit output (see [[bip-0141.mediawiki|BIP141]]) with version number 1, and a 32-byte witness program.\nThe following rules only apply when such an output is being spent. Any other outputs, including version 1 outputs with lengths other than 32 bytes, or P2SH-wrapped version 1 outputs'''Why is P2SH-wrapping not supported?''' Using P2SH-wrapped outputs only provides 80-bit collision security due to the use of a 160-bit hash. This is considered low, and becomes a security risk whenever the output includes data from more than a single party (public keys, hashes, ...)., remain unencumbered.\n\n* Let ''q'' be the 32-byte array containing the witness program (the second push in the scriptPubKey) which represents a public key according to [[bip-0340.mediawiki#design|BIP340]].\n* Fail if the witness stack has 0 elements.\n* If there are at least two witness elements, and the first byte of the last element is 0x50'''Why is the first byte of the annex 0x50?''' The 0x50 is chosen as it could not be confused with a valid P2WPKH or P2WSH spending. As the control block's initial byte's lowest bit is used to indicate the parity of the public key's Y coordinate, each leaf version needs an even byte value and the immediately following odd byte value that are both not yet used in P2WPKH or P2WSH spending. To indicate the annex, only an \"unpaired\" available byte is necessary like 0x50. This choice maximizes the available options for future script versions., this last element is called ''annex'' ''a'''''What is the purpose of the annex?''' The annex is a reserved space for future extensions, such as indicating the validation costs of computationally expensive new opcodes in a way that is recognizable without knowing the scriptPubKey of the output being spent. Until the meaning of this field is defined by another softfork, users SHOULD NOT include annex in transactions, or it may lead to PERMANENT FUND LOSS. and is removed from the witness stack. The annex (or the lack of thereof) is always covered by the signature and contributes to transaction weight, but is otherwise ignored during taproot validation.\n* If there is exactly one element left in the witness stack, key path spending is used:\n** The single witness stack element is interpreted as the signature and must be valid (see the next section) for the public key ''q'' (see the next subsection).\n* If there are at least two witness elements left, script path spending is used:\n** Call the second-to-last stack element ''s'', the script.\n** The last stack element is called the control block ''c'', and must have length ''33 + 32m'', for a value of ''m'' that is an integer between 0 and 128'''Why is the Merkle path length limited to 128?''' The optimally space-efficient Merkle tree can be constructed based on the probabilities of the scripts in the leaves, using the Huffman algorithm. This algorithm will construct branches with lengths approximately equal to ''log2(1/probability)'', but to have branches longer than 128 you would need to have scripts with an execution chance below 1 in ''2128''. As that is our security bound, scripts that truly have such a low chance can probably be removed entirely., inclusive. Fail if it does not have such a length.\n** Let ''p = c[1:33]'' and let ''P = lift_x(int(p))'' where ''lift_x'' and ''[:]'' are defined as in [[bip-0340.mediawiki#design|BIP340]]. Fail if this point is not on the curve.\n** Let ''v = c[0] & 0xfe'' and call it the ''leaf version'''''What constraints are there on the leaf version?''' First, the leaf version cannot be odd as ''c[0] & 0xfe'' will always be even, and cannot be ''0x50'' as that would result in ambiguity with the annex. In addition, in order to support some forms of static analysis that rely on being able to identify script spends without access to the output being spent, it is recommended to avoid using any leaf versions that would conflict with a valid first byte of either a valid P2WPKH pubkey or a valid P2WSH script (that is, both ''v'' and ''v | 1'' should be an undefined, invalid or disabled opcode or an opcode that is not valid as the first opcode). The values that comply to this rule are the 32 even values between ''0xc0'' and ''0xfe'' and also ''0x66'', ''0x7e'', ''0x80'', ''0x84'', ''0x96'', ''0x98'', ''0xba'', ''0xbc'', ''0xbe''. Note also that this constraint implies that leaf versions should be shared amongst different witness versions, as knowing the witness version requires access to the output being spent..\n** Let ''k0 = hashTapLeaf(v || compact_size(size of s) || s)''; also call it the ''tapleaf hash''.\n** For ''j'' in ''[0,1,...,m-1]'':\n*** Let ''ej = c[33+32j:65+32j]''.\n*** Let ''kj+1 depend on whether ''kj < ej'' (lexicographically)'''Why are child elements sorted before hashing in the Merkle tree?''' By doing so, it is not necessary to reveal the left/right directions along with the hashes in revealed Merkle branches. This is possible because we do not actually care about the position of specific scripts in the tree; only that they are actually committed to.:\n**** If ''kj < ej'': ''kj+1 = hashTapBranch(kj || ej)'''''Why not use a more efficient hash construction for inner Merkle nodes?''' The chosen construction does require two invocations of the SHA256 compression functions, one of which can be avoided in theory (see [[bip-0098.mediawiki|BIP98]]). However, it seems preferable to stick to constructions that can be implemented using standard cryptographic primitives, both for implementation simplicity and analyzability. If necessary, a significant part of the second compression function can be optimized out by [https://github.com/bitcoin/bitcoin/pull/13191 specialization] for 64-byte inputs..\n**** If ''kj ≥ ej'': ''kj+1 = hashTapBranch(ej || kj)''.\n** Let ''t = hashTapTweak(p || km)''.\n** If ''t ≥ 0xFFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141'' (order of secp256k1), fail.\n** Let ''Q = P + int(t)G''.\n** If ''q ≠ x(Q)'' or ''c[0] & 1 ≠ y(Q) mod 2'', fail'''Why is it necessary to reveal a bit in a script path spend and check that it matches the parity of the Y coordinate of ''Q''?''' The parity of the Y coordinate is necessary to lift the X coordinate ''q'' to a unique point. While this is not strictly necessary for verifying the taproot commitment as described above, it is necessary to allow batch verification. Alternatively, ''Q'' could be forced to have an even Y coordinate, but that would require retrying with different internal public keys (or different messages) until ''Q'' has that property. There is no downside to adding the parity bit because otherwise the control block bit would be unused..\n** Execute the script, according to the applicable script rules'''What are the applicable script rules in script path spends?''' [[bip-0342.mediawiki|BIP342]] specifies validity rules that apply for leaf version 0xc0, but future proposals can introduce rules for other leaf versions., using the witness stack elements excluding the script ''s'', the control block ''c'', and the annex ''a'' if present, as initial stack. This implies that for the future leaf versions (non-''0xC0'') the execution must succeed.'''Why we need to success on future leaf version validation''' This is required to enable future leaf versions as soft forks.\n\n''q'' is referred to as ''taproot output key'' and ''p'' as ''taproot internal key''.\n\n=== Signature validation rules ===\n\nWe first define a reusable common signature message calculation function, followed by the actual signature validation as it's used in key path spending.\n\n==== Common signature message ====\n\nThe 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.\n\nThe parameter ''hash_type'' is an 8-bit unsigned value. The SIGHASH encodings from the legacy script system are reused, including SIGHASH_ALL, SIGHASH_NONE, SIGHASH_SINGLE, and SIGHASH_ANYONECANPAY. We define a new ''hashtype'' SIGHASH_DEFAULT (value ''0x00'') which results in signing over the whole transaction just as for SIGHASH_ALL. The following restrictions apply, which cause validation failure if violated:\n* Using any undefined ''hash_type'' (not ''0x00'', ''0x01'', ''0x02'', ''0x03'', ''0x81'', ''0x82'', or ''0x83'''''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.).\n* Using SIGHASH_SINGLE without a \"corresponding output\" (an output with the same index as the input being verified).\n\nThe 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()'''''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''..\n\nIf 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.\n\n* Control:\n** ''hash_type'' (1).\n* Transaction data:\n** ''nVersion'' (4): the ''nVersion'' of the transaction.\n** ''nLockTime'' (4): the ''nLockTime'' of the transaction.\n** If the ''hash_type & 0x80'' does not equal SIGHASH_ANYONECANPAY:\n*** ''sha_prevouts'' (32): the SHA256 of the serialization of all input outpoints.\n*** ''sha_amounts'' (32): the SHA256 of the serialization of all input amounts.\n*** ''sha_scriptpubkeys'' (32): the SHA256 of all spent outputs' ''scriptPubKeys'', serialized as script inside CTxOut.\n*** ''sha_sequences'' (32): the SHA256 of the serialization of all input ''nSequence''.\n** If ''hash_type & 3'' does not equal SIGHASH_NONE or SIGHASH_SINGLE:\n*** ''sha_outputs'' (32): the SHA256 of the serialization of all outputs in CTxOut format.\n* Data about this input:\n** ''spend_type'' (1): equal to ''(ext_flag * 2) + annex_present'', where ''annex_present'' is 0 if no annex is present, or 1 otherwise (the original witness stack has two or more witness elements, and the first byte of the last element is ''0x50'')\n** If ''hash_type & 0x80'' equals SIGHASH_ANYONECANPAY:\n*** ''outpoint'' (36): the COutPoint of this input (32-byte hash + 4-byte little-endian).\n*** ''amount'' (8): value of the previous output spent by this input.\n*** ''scriptPubKey'' (35): ''scriptPubKey'' of the previous output spent by this input, serialized as script inside CTxOut. Its size is always 35 bytes.\n*** ''nSequence'' (4): ''nSequence'' of this input.\n** If ''hash_type & 0x80'' does not equal SIGHASH_ANYONECANPAY:\n*** ''input_index'' (4): index of this input in the transaction input vector. Index of the first input is 0.\n** If an annex is present (the lowest bit of ''spend_type'' is set):\n*** ''sha_annex'' (32): the SHA256 of ''(compact_size(size of annex) || annex)'', where ''annex'' includes the mandatory ''0x50'' prefix.\n* Data about this output:\n** If ''hash_type & 3'' equals SIGHASH_SINGLE:\n*** ''sha_single_output'' (32): the SHA256 of the corresponding output in CTxOut format.\n\nThe total length of ''SigMsg()'' is at most ''206'' bytes'''What is the output length of ''SigMsg()''?''' The total length of ''SigMsg()'' can be computed using the following formula: ''174 - is_anyonecanpay * 49 - is_none * 32 + has_annex * 32''.. Note that this does not include the size of sub-hashes such as ''sha_prevouts'', which may be cached across signatures of the same transaction.\n\nIn summary, the semantics of the [[bip-0143.mediawiki|BIP143]] sighash types remain unchanged, except the following:", "category": "bips" }, { "instruction": "I'm trying to understand Bitcoin Operations Guide - can you walk me through it?", "input": "", "output": "# The way and order of serialization is changed.'''Why is the serialization in the signature message changed?''' Hashes that go into the signature message and the message itself are now computed with a single SHA256 invocation instead of double SHA256. There is no expected security improvement by doubling SHA256 because this only protects against length-extension attacks against SHA256 which are not a concern for signature messages because there is no secret data. Therefore doubling SHA256 is a waste of resources. The message computation now follows a logical order with transaction level data first, then input data and output data. This allows to efficiently cache the transaction part of the message across different inputs using the SHA256 midstate. Additionally, sub-hashes can be skipped when calculating the message (for example `sha_prevouts` if SIGHASH_ANYONECANPAY is set) instead of setting them to zero and then hashing them as in BIP143. Despite that, collisions are made impossible by committing to the length of the data (implicit in ''hash_type'' and ''spend_type'') before the variable length data.", "category": "bips" }, { "instruction": "Hey, I need to set up Bitcoin Operations Guide - what's the command line way to do that?", "input": "", "output": "# The signature message commits to the ''scriptPubKey'' of the spent output and if the SIGHASH_ANYONECANPAY flag is not set, the message commits to the ''scriptPubKey''s of ''all'' outputs spent by the transaction. '''Why does the signature message commit to the ''scriptPubKey''?''' This prevents lying to offline signing devices about output being spent, even when the actually executed script (''scriptCode'' in BIP143) is correct. This means it's possible to compactly prove to a hardware wallet what (unused) execution paths existed. Moreover, committing to all spent ''scriptPubKey''s helps offline signing devices to determine the subset that belong to its own wallet. This is useful in [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-April/017801.html automated coinjoins]..", "category": "bips" }, { "instruction": "What's the deal with Bitcoin Operations Guide in Bitcoin? Explain it like I'm a friend.", "input": "", "output": "# If the SIGHASH_ANYONECANPAY flag is not set, the message commits to the amounts of ''all'' transaction inputs.'''Why does the signature message commit to the amounts of all transaction inputs?''' This eliminates the possibility to lie to offline signing devices about the fee of a transaction.", "category": "bips" }, { "instruction": "Can you show me the CLI commands for Bitcoin Operations Guide?", "input": "", "output": "# The signature message commits to all input ''nSequence'' if SIGHASH_NONE or SIGHASH_SINGLE are set (unless SIGHASH_ANYONECANPAY is set as well).'''Why does the signature message commit to all input ''nSequence'' if SIGHASH_SINGLE or SIGHASH_NONE are set?''' Because setting them already makes the message commit to the prevouts part of all transaction inputs, it is not useful to treat the ''nSequence'' any different. Moreover, this change makes ''nSequence'' consistent with the view that SIGHASH_SINGLE and SIGHASH_NONE only modify the signature message with respect to transaction outputs and not inputs.", "category": "bips" }, { "instruction": "I'm stuck with The signature message includes commitments to the taproot-specific data ''spend_type'' and ''annex'' (if present). - what should I check?", "input": "", "output": "==== Taproot key path spending signature validation ====\n\nA Taproot signature is a 64-byte Schnorr signature, as defined in [[bip-0340.mediawiki|BIP340]], with the sighash byte appended in the usual Bitcoin fashion. This sighash byte is optional. If omitted, the resulting signatures are 64 bytes, and a SIGHASH_DEFAULT mode is implied.\n\nTo validate a signature ''sig'' with public key ''q'':\n* If the ''sig'' is 64 bytes long, return ''Verify(q, hashTapSighash(0x00 || SigMsg(0x00, 0)), sig)'''''Why is the input to ''hashTapSighash'' prefixed with 0x00?''' This prefix is called the sighash epoch, and allows reusing the ''hashTapSighash'' tagged hash in future signature algorithms that make invasive changes to how hashing is performed (as opposed to the ''ext_flag'' mechanism that is used for incremental extensions). An alternative is having them use a different tag, but supporting a growing number of tags may become undesirable., where ''Verify'' is defined in [[bip-0340.mediawiki#design|BIP340]].\n* If the ''sig'' is 65 bytes long, return ''sig[64] ≠ 0x00'''Why can the hash_type not be 0x00 in 65-byte signatures?''' Permitting that would enable malleating (by third parties, including miners) 64-byte signatures into 65-byte ones, resulting in a different `wtxid` and a different fee rate than the creator intended. and Verify(q, hashTapSighash(0x00 || SigMsg(sig[64], 0)), sig[0:64])''.\n* Otherwise, fail'''Why permit two signature lengths?''' By making the most common type of hash_type implicit, a byte can often be saved..\n\n== Constructing and spending Taproot outputs ==\n\nThis section discusses how to construct and spend Taproot outputs. It only affects wallet software that chooses to implement receiving and spending,\nand is not consensus critical in any way.\n\nConceptually, every Taproot output corresponds to a combination of a single public key condition (the internal key), and zero or more general conditions encoded in scripts organized in a tree.\nSatisfying any of these conditions is sufficient to spend the output.\n\n'''Initial steps''' The first step is determining what the internal key and the organization of the rest of the scripts should be. The specifics are likely application dependent, but here are some general guidelines:\n* When deciding between scripts with conditionals (OP_IF etc.) and splitting them up into multiple scripts (each corresponding to one execution path through the original script), it is generally preferable to pick the latter.\n* When a single condition requires signatures with multiple keys, key aggregation techniques like MuSig can be used to combine them into a single key. The details are out of scope for this document, but note that this may complicate the signing procedure.\n* If one or more of the spending conditions consist of just a single key (after aggregation), the most likely one should be made the internal key. If no such condition exists, it may be worthwhile adding one that consists of an aggregation of all keys participating in all scripts combined; effectively adding an \"everyone agrees\" branch. If that is inacceptable, pick as internal key a \"Nothing Up My Sleeve\" (NUMS) point, i.e., a point with unknown discrete logarithm. One example of such a point is ''H = lift_x(0x50929b74c1a04954b78b4b6035e97a5e078a5a0f28ec96d547bfee9ace803ac0)'' which is [https://github.com/ElementsProject/secp256k1-zkp/blob/11af7015de624b010424273be3d91f117f172c82/src/modules/rangeproof/main_impl.h#L16 constructed] by taking the hash of the standard uncompressed encoding of the [https://www.secg.org/sec2-v2.pdf secp256k1] base point ''G'' as X coordinate. In order to avoid leaking the information that key path spending is not possible it is recommended to pick a fresh integer ''r'' in the range ''0...n-1'' uniformly at random and use ''H + rG'' as internal key. It is possible to prove that this internal key does not have a known discrete logarithm with respect to ''G'' by revealing ''r'' to a verifier who can then reconstruct how the internal key was created.\n* If the spending conditions do not require a script path, the output key should commit to an unspendable script path instead of having no script path. This can be achieved by computing the output key point as ''Q = P + int(hashTapTweak(bytes(P)))G''. '''Why should the output key always have a taproot commitment, even if there is no script path?'''\nIf the taproot output key is an aggregate of keys, there is the possibility for a malicious party to add a script path without being noticed by the other parties.\nThis allows to bypass the multiparty policy and to steal the coin.\nMuSig key aggregation does not have this issue because it already causes the internal key to be randomized.\n\nThe attack works as follows: Assume Alice and Mallory want to aggregate their keys into a taproot output key without a script path.\nIn order to prevent key cancellation and related attacks they use [https://eprint.iacr.org/2018/483.pdf MSDL-pop] instead of MuSig.\nThe MSDL-pop protocol requires all parties to provide a proof of possession of their corresponding secret key and the aggregated key is just the sum of the individual keys.\nAfter Mallory receives Alice's key ''A'', Mallory creates ''M = M0 + int(t)G'' where ''M0'' is Mallory's original key and ''t'' allows a script path spend with internal key ''P = A + M0'' and a script that only contains Mallory's key.\nMallory sends a proof of possession of ''M'' to Alice and both parties compute output key ''Q = A + M = P + int(t)G''.\nAlice will not be able to notice the script path, but Mallory can unilaterally spend any coin with output key ''Q''.\n\n* 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.\n\n'''Computing the output script''' Once the spending conditions are split into an internal key internal_pubkey 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.\n\nFirst, we define taproot_tweak_pubkey for 32-byte [[bip-0340.mediawiki|BIP340]] public key arrays.\nThe function returns a bit indicating the tweaked public key's Y coordinate as well as the public key byte array.\nThe parity bit will be required for spending the output with a script path.\nIn order to allow spending with the key path, we define taproot_tweak_seckey to compute the secret key for a tweaked public key.\nFor any byte string h it holds that taproot_tweak_pubkey(pubkey_gen(seckey), h)[1] == pubkey_gen(taproot_tweak_seckey(seckey, h)).\n\nNote that because tweaks are applied to 32-byte public keys, `taproot_tweak_seckey` may need to negate the secret key before applying the tweak.\n\n\ndef taproot_tweak_pubkey(pubkey, h):\n t = int_from_bytes(tagged_hash(\"TapTweak\", pubkey + h))\n if t >= SECP256K1_ORDER:\n raise ValueError\n P = lift_x(int_from_bytes(pubkey))\n if P is None:\n raise ValueError\n Q = point_add(P, point_mul(G, t))\n return 0 if has_even_y(Q) else 1, bytes_from_int(x(Q))\n\ndef taproot_tweak_seckey(seckey0, h):\n seckey0 = int_from_bytes(seckey0)\n P = point_mul(G, seckey0)\n seckey = seckey0 if has_even_y(P) else SECP256K1_ORDER - seckey0\n t = int_from_bytes(tagged_hash(\"TapTweak\", bytes_from_int(x(P)) + h))\n if t >= SECP256K1_ORDER:\n raise ValueError\n return bytes_from_int((seckey + t) % SECP256K1_ORDER)\n\n\nThe following function, taproot_output_script, returns a byte array with the scriptPubKey (see [[bip-0141.mediawiki|BIP141]]).\nser_script refers to a function that prefixes its input with a CompactSize-encoded length.\n\n\ndef taproot_tree_helper(script_tree):\n if isinstance(script_tree, tuple):\n leaf_version, script = script_tree\n h = tagged_hash(\"TapLeaf\", bytes([leaf_version]) + ser_script(script))\n return ([((leaf_version, script), bytes())], h)\n left, left_h = taproot_tree_helper(script_tree[0])\n right, right_h = taproot_tree_helper(script_tree[1])\n ret = [(l, c + right_h) for l, c in left] + [(l, c + left_h) for l, c in right]\n if right_h < left_h:\n left_h, right_h = right_h, left_h\n return (ret, tagged_hash(\"TapBranch\", left_h + right_h))\n\ndef taproot_output_script(internal_pubkey, script_tree):\n \"\"\"Given a internal public key and a tree of scripts, compute the output script.\n script_tree is either:\n - a (leaf_version, script) tuple (leaf_version is 0xc0 for [[bip-0342.mediawiki|BIP342]] scripts)\n - a list of two elements, each with the same structure as script_tree itself\n - None\n \"\"\"\n if script_tree is None:\n h = bytes()\n else:\n _, h = taproot_tree_helper(script_tree)\n _, output_pubkey = taproot_tweak_pubkey(internal_pubkey, h)\n return bytes([0x51, 0x20]) + output_pubkey\n\n\n[[File:bip-0341/tree.png|frame|This diagram shows the hashing structure to obtain the tweak from an internal key ''P'' and a Merkle tree consisting of 5 script leaves. ''A'', ''B'', ''C'' and ''E'' are ''TapLeaf'' hashes similar to ''D'' and ''AB'' is a ''TapBranch'' hash. Note that when ''CDE'' is computed ''E'' is hashed first because ''E'' is less than ''CD''.]]\n\nTo spend this output using script ''D'', the control block would contain the following data in this order:\n\n \n\nThe TapTweak would then be computed as described [[bip-0341.mediawiki#script-validation-rules|above]] like so:\n\n\nD = tagged_hash(\"TapLeaf\", bytes([leaf_version]) + ser_script(script))\nCD = tagged_hash(\"TapBranch\", C + D)\nCDE = tagged_hash(\"TapBranch\", E + CD)\nABCDE = tagged_hash(\"TapBranch\", AB + CDE)\nTapTweak = tagged_hash(\"TapTweak\", p + ABCDE)\n\n\n'''Spending using the key path''' A Taproot output can be spent with the secret key corresponding to the internal_pubkey. To do so, a witness stack consists of a single element: a [[bip-0340.mediawiki|BIP340]] signature on the signature hash as defined above, with the secret key tweaked by the same h as in the above snippet. See the code below:\n\n\ndef taproot_sign_key(script_tree, internal_seckey, hash_type, bip340_aux_rand):\n if script_tree is None:\n h = bytes()\n else:\n _, h = taproot_tree_helper(script_tree)\n output_seckey = taproot_tweak_seckey(internal_seckey, h)\n sig = schnorr_sign(sighash(hash_type), output_seckey, bip340_aux_rand)\n if hash_type != 0:\n sig += bytes([hash_type])\n return [sig]\n\n\nThis function returns the witness stack necessary and a sighash function to compute the signature hash as defined above (for simplicity, the snippet above ignores passing information like the transaction, the input position, ... to the sighashing code).\n\n'''Spending using one of the scripts''' A Taproot output can be spent by satisfying any of the scripts used in its construction. To do so, a witness stack consisting of the script's inputs, plus the script itself and the control block are necessary. See the code below:\n\n\ndef taproot_sign_script(internal_pubkey, script_tree, script_num, inputs):\n info, h = taproot_tree_helper(script_tree)\n (leaf_version, script), path = info[script_num]\n output_pubkey_y_parity, _ = taproot_tweak_pubkey(internal_pubkey, h)\n pubkey_data = bytes([output_pubkey_y_parity + leaf_version]) + internal_pubkey\n return inputs + [script, pubkey_data + path]\n\n\n== Security ==\n\nTaproot improves the privacy of Bitcoin because instead of revealing all possible conditions for spending an output, only the satisfied spending condition has to be published.\nIdeally, outputs are spent using the key path which prevents observers from learning the spending conditions of a coin.\nA key path spend could be a \"normal\" payment from a single- or multi-signature wallet or the cooperative settlement of hidden multiparty contract.\n\nA script path spend leaks that there is a script path and that the key path was not applicable - for example because the involved parties failed to reach agreement.\nMoreover, the depth of a script in the Merkle root leaks information including the minimum depth of the tree, which suggests specific wallet software that created the output and helps clustering.\nTherefore, the privacy of script spends can be improved by deviating from the optimal tree determined by the probability distribution over the leaves.\n\nJust like other existing output types, taproot outputs should never reuse keys, for privacy reasons.\nThis does not only apply to the particular leaf that was used to spend an output but to all leaves committed to in the output.\nIf leaves were reused, it could happen that spending a different output would reuse the same Merkle branches in the Merkle proof.\nUsing fresh keys implies that taproot output construction does not need to take special measures to randomizing leaf positions because they are already randomized due to the branch-sorting Merkle tree construction used in taproot.\nThis does not avoid leaking information through the leaf depth and therefore only applies to balanced (sub-) trees.\nIn addition, every leaf should have a set of keys distinct from every other leaf.\nThe reason for this is to increase leaf entropy and prevent an observer from learning an undisclosed script using brute-force search.\n\n== Test vectors ==\n\nTest vectors for wallet operation (scriptPubKey computation, key path spending, control block construction) can be found [[bip-0341/wallet-test-vectors.json|here]].\nIt consists of two sets of vectors.\n* 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 null 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.\n* 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.\n* 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.\n\nValidation 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].\n\n== Rationale ==\n\n\n\n== Deployment ==\n\nThis BIP is deployed concurrently with [[bip-0342.mediawiki|BIP342]].\n\nFor Bitcoin signet, these BIPs are always active.\n\nFor 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:\n\n case DEFINED:\n if (GetMedianTimePast(block.parent) >= starttime) {\n return STARTED;\n }\n return DEFINED;\n\n case STARTED:\n int count = 0;\n walk = block;\n for (i = 0; i < 2016; i++) {\n walk = walk.parent;\n if ((walk.nVersion & 0xE0000000) == 0x20000000 && ((walk.nVersion >> bit) & 1) == 1) {\n count++;\n }\n }\n if (count >= threshold) {\n return LOCKED_IN;\n } else if (GetMedianTimePast(block.parent) >= timeout) {\n return FAILED;\n }\n return STARTED;\n\n case LOCKED_IN:\n if (block.nHeight < min_activation_height) {\n return LOCKED_IN;\n }\n return ACTIVE;\n\nFor 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.\nThe deployment did activate at height 709632 on Bitcoin mainnet.\n\nFor 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.\nThe deployment did activate at height 2011968 on Bitcoin testnet3.\n\n== Backwards compatibility ==\nAs a soft fork, older software will continue to operate without modification.\nNon-upgraded nodes, however, will consider all SegWit version 1 witness programs as anyone-can-spend scripts.\nThey are strongly encouraged to upgrade in order to fully validate the new programs.\n\nNon-upgraded wallets can receive and send bitcoin from non-upgraded and upgraded wallets using SegWit version 0 programs, traditional pay-to-pubkey-hash, etc.\nDepending on the implementation non-upgraded wallets may be able to send to Segwit version 1 programs if they support sending to [[bip-0350.mediawiki|BIP350]] Bech32m addresses.\n\n== Acknowledgements ==\n\nThis document is the result of discussions around script and signature improvements with many people, and had direct contributions from Greg Maxwell and others. It further builds on top of earlier published proposals such as Taproot by Greg Maxwell, and Merkle branch constructions by Russell O'Connor, Johnson Lau, and Mark Friedenbach.\n\nThe authors wish the thank Arik Sosman for suggesting to sort Merkle node children before hashes, removing the need to transfer the position in the tree, as well as all those who provided valuable feedback and reviews, including the participants of the [https://github.com/ajtowns/taproot-review structured reviews].", "category": "bips" }, { "instruction": "How do I troubleshoot 
 issues?",
    "input": "",
    "output": "BIP: 37\n  Layer: Peer Services\n  Title: Connection Bloom filtering\n  Authors: Mike Hearn \n           Matt Corallo \n  Comments-Summary: No comments yet.\n  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0037\n  Status: Deployed\n  Type: Specification\n  Assigned: 2012-10-24\n  License: PD\n
\n\n==Abstract==\n\nThis BIP adds new support to the peer-to-peer protocol that allows peers to reduce the amount of transaction data they are sent. Peers have the option of setting ''filters'' on each connection they make after the version handshake has completed. A filter is defined as a [http://en.wikipedia.org/wiki/Bloom_filter Bloom filter] on data derived from transactions. A Bloom filter is a probabilistic data structure which allows for testing set membership - they can have false positives but not false negatives.\n\nThis document will not go into the details of how Bloom filters work and the reader is referred to Wikipedia for an introduction to the topic.\n\n==Motivation==\n\nAs Bitcoin grows in usage the amount of bandwidth needed to download blocks and transaction broadcasts increases. Clients implementing ''simplified payment verification'' do not attempt to fully verify the block chain, instead just checking that block headers connect together correctly and trusting that the transactions in a chain of high difficulty are in fact valid. See the Bitcoin paper for more detail on this mode.\n\nToday, [[https://bitcoin.org/en/developer-guide#simplified-payment-verification-spv|SPV]] clients have to download the entire contents of blocks and all broadcast transactions, only to throw away the vast majority of the transactions that are not relevant to their wallets. This slows down their synchronization process, wastes users bandwidth (which on phones is often metered) and increases memory usage. All three problems are triggering real user complaints for the Android \"Bitcoin Wallet\" app which implements SPV mode. In order to make chain synchronization fast, cheap and able to run on older phones with limited memory we want to have remote peers throw away irrelevant transactions before sending them across the network.\n\n==Design rationale==\n\nThe most obvious way to implement the stated goal would be for clients to upload lists of their keys to the remote node. We take a more complex approach for the following reasons:\n\n* Privacy: Because Bloom filters are probabilistic, with the false positive rate chosen by the client, nodes can trade off precision vs bandwidth usage. A node with access to lots of bandwidth may choose to have a high FP rate, meaning the remote peer cannot accurately know which transactions belong to the client and which don't. A node with very little bandwidth may choose to use a very accurate filter meaning that they only get sent transactions actually relevant to their wallet, but remote peers may be able to correlate transactions with IP addresses (and each other).\n* Bloom filters are compact and testing membership in them is fast. This results in satisfying performance characteristics with minimal risk of opening up potential for DoS attacks.\n\n==Specification==\n\n===New messages===\n\nWe start by adding three new messages to the protocol:\n\n* filterload, which sets the current Bloom filter on the connection\n* filteradd, which adds the given data element to the connections current filter without requiring a completely new one to be set\n* filterclear, which deletes the current filter and goes back to regular pre-BIP37 usage.\n\nNote that there is no filterremove command because by their nature, Bloom filters are append-only data structures. Once an element is added it cannot be removed again without rebuilding the entire structure from scratch.\n\nThe filterload command is defined as follows:\n\n{|class=\"wikitable\"\n! Field Size !! Description !! Data type !! Comments\n|-\n| ? || filter || uint8_t[] || The filter itself is simply a bit field of arbitrary byte-aligned size. The maximum size is 36,000 bytes.\n|-\n| 4 || nHashFuncs || uint32_t || The number of hash functions to use in this filter. The maximum value allowed in this field is 50.\n|-\n| 4 || nTweak || uint32_t || A random value to add to the seed value in the hash function used by the bloom filter.\n|-\n| 1 || nFlags || uint8_t || A set of flags that control how matched items are added to the filter.\n|}\n\nSee below for a description of the Bloom filter algorithm and how to select nHashFuncs and filter size for a desired false positive rate.\n\nUpon receiving a filterload command, the remote peer will immediately restrict the broadcast transactions it announces (in inv packets) to transactions matching the filter, where the matching algorithm is specified below. The flags control the update behaviour of the matching algorithm.\n\nThe filteradd command is defined as follows:\n\n{|class=\"wikitable\"\n! Field Size !! Description !! Data type !! Comments\n|-\n| ? || data || uint8_t[] || The data element to add to the current filter.\n|}\n\nThe data field must be smaller than or equal to 520 bytes in size (the maximum size of any potentially matched object).\n\nThe given data element will be added to the Bloom filter. A filter must have been previously provided using filterload. This command is useful if a new key or script is added to a clients wallet whilst it has connections to the network open, it avoids the need to re-calculate and send an entirely new filter to every peer (though doing so is usually advisable to maintain anonymity).\n\nThe filterclear command has no arguments at all.\n\nAfter a filter has been set, nodes don't merely stop announcing non-matching transactions, they can also serve filtered blocks. A filtered block is defined by the merkleblock message and is defined like this:\n\n{|class=\"wikitable\"\n! Field Size !! Description !! Data type !! Comments\n|-\n| 4 || version || uint32_t || Block version information, based upon the software version creating this block\n|-\n| 32 || prev_block || char[32] || The hash value of the previous block this particular block references\n|-\n| 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block\n|-\n| 4 || timestamp || uint32_t || A timestamp recording when this block was created (Limited to 2106!)\n|-\n| 4 || bits || uint32_t || The calculated difficulty target being used for this block\n|-\n| 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes\n|-\n| 4 || total_transactions || uint32_t || Number of transactions in the block (including unmatched ones)\n|-\n| ? || hashes || uint256[] || hashes in depth-first order (including standard varint size prefix)\n|-\n| ? || flags || byte[] || flag bits, packed per 8 in a byte, least significant bit first (including standard varint size prefix)\n|}\n\nSee below for the format of the partial merkle tree hashes and flags.\n\nThus, a merkleblock message is a block header, plus a part of a merkle tree which can be used to extract identifying information for transactions that matched the filter and prove that the matching transaction data really did appear in the solved block. Clients can use this data to be sure that the remote node is not feeding them fake transactions that never appeared in a real block, although lying through omission is still possible.\n\n===Extensions to existing messages===\n\nThe version command is extended with a new field:\n\n{|class=\"wikitable\"\n! Field Size !! Description !! Data type !! Comments\n|-\n| 1 byte || fRelay || bool || If false then broadcast transactions will not be announced until a filter{load,add,clear} command is received. If missing or true, no change in protocol behaviour occurs.\n|}\n\nSPV clients that wish to use Bloom filtering would normally set fRelay to false in the version message, then set a filter based on their wallet (or a subset of it, if they are overlapping different peers). Being able to opt-out of inv messages until the filter is set prevents a client being flooded with traffic in the brief window of time between finishing version handshaking and setting the filter.\n\nThe getdata command is extended to allow a new type in the inv submessage. The type field can now be MSG_FILTERED_BLOCK (== 3) rather than MSG_BLOCK. If no filter has been set on the connection, a request for filtered blocks is ignored. If a filter has been set, a merkleblock message is returned for the requested block hash. In addition, because a merkleblock message contains only a list of transaction hashes, transactions matching the filter should also be sent in separate tx messages after the merkleblock is sent. This avoids a slow roundtrip that would otherwise be required (receive hashes, didn't see some of these transactions yet, ask for them). Note that because there is currently no way to request transactions which are already in a block from a node (aside from requesting the full block), the set of matching transactions that the requesting node hasn't either received or announced with an inv must be sent and any additional transactions which match the filter may also be sent. This allows for clients (such as the reference client) to limit the number of invs it must remember a given node to have announced while still providing nodes with, at a minimum, all the transactions it needs.\n\n===Filter matching algorithm===\n\nThe filter can be tested against arbitrary pieces of data, to see if that data was inserted by the client. Therefore the question arises of what pieces of data should be inserted/tested.\n\nTo determine if a transaction matches the filter, the following algorithm is used. Once a match is found the algorithm aborts.", "category": "bips" }, { "instruction": "What are the best practices for Bitcoin Operations Guide?", "input": "", "output": "# For each output, test each data element of the output script. This means each hash and key in the output script is tested independently. '''Important:''' if an output matches whilst testing a transaction, the node might need to update the filter by inserting the serialized COutPoint structure. See below for more details.", "category": "bips" }, { "instruction": "Walk me through setting up Bitcoin Operations Guide step by step", "input": "", "output": "# For each input, test each data element of the input script (note: input scripts only ever contain data elements).", "category": "bips" }, { "instruction": "What commands would you run to work with Otherwise there is no match.?", "input": "", "output": "In this way addresses, keys and script hashes (for P2SH outputs) can all be added to the filter. You can also match against classes of transactions that are marked with well known data elements in either inputs or outputs, for example, to implement various forms of [[https://en.bitcoin.it/wiki/Smart_Property|Smart property]].\n\nThe test for outpoints is there to ensure you can find transactions spending outputs in your wallet, even though you don't know anything about their form. As you can see, once set on a connection the filter is '''not static''' and can change throughout the connections lifetime. This is done to avoid the following race condition:", "category": "bips" }, { "instruction": "I want to understand Bitcoin Operations Guide from a technical perspective", "input": "", "output": "# A client sets a filter matching a key in their wallet. They then start downloading the block chain. The part of the chain that the client is missing is requested using getblocks.", "category": "bips" }, { "instruction": "Can you explain Bitcoin Operations Guide like we're having a beer and talking Bitcoin?", "input": "", "output": "# The first block is read from disk by the serving peer. It contains TX 1 which sends money to the clients key. It matches the filter and is thus sent to the client.", "category": "bips" }, { "instruction": "How would you explain The second block is read from disk by the serving peer. It contains TX 2 which spends TX 1. However TX 2 does not contain any of the clients keys and is thus not sent. The client does not know the money they received was already spent. to someone who knows Bitcoin basics?", "input": "", "output": "By updating the bloom filter atomically in step 2 with the discovered outpoint, the filter will match against TX 2 in step 3 and the client will learn about all relevant transactions, despite that there is no pause between the node processing the first and second blocks.\n\nThe nFlags field of the filter controls the nodes precise update behaviour and is a bit field.\n\n* BLOOM_UPDATE_NONE (0) means the filter is not adjusted when a match is found.\n* BLOOM_UPDATE_ALL (1) means if the filter matches any data element in a scriptPubKey the outpoint is serialized and inserted into the filter.\n* BLOOM_UPDATE_P2PUBKEY_ONLY (2) means the outpoint is inserted into the filter only if a data element in the scriptPubKey is matched, and that script is of the standard \"pay to pubkey\" or \"pay to multisig\" forms.\n\nThese distinctions are useful to avoid too-rapid degradation of the filter due to an increasing false positive rate. We can observe that a wallet which expects to receive only payments of the standard pay-to-address form doesn't need automatic filter updates because any transaction that spends one of its own outputs has a predictable data element in the input (the pubkey that hashes to the address). If a wallet might receive pay-to-address outputs and also pay-to-pubkey or pay-to-multisig outputs then BLOOM_UPDATE_P2PUBKEY_ONLY is appropriate, as it avoids unnecessary expansions of the filter for the most common types of output but still ensures correct behaviour with payments that explicitly specify keys.\n\nObviously, nFlags == 1 or nFlags == 2 mean that the filter will get dirtier as more of the chain is scanned. Clients should monitor the observed false positive rate and periodically refresh the filter with a clean one.\n\n===Partial Merkle branch format===\n\nA ''Merkle tree'' is a way of arranging a set of items as leaf nodes of tree in which the interior nodes are hashes of the concatenations of their child hashes. The root node is called the ''Merkle root''. Every Bitcoin block contains a Merkle root of the tree formed from the blocks transactions. By providing some elements of the trees interior nodes (called a ''Merkle branch'') a proof is formed that the given transaction was indeed in the block when it was being mined, but the size of the proof is much smaller than the size of the original block.\n\n====Constructing a partial merkle tree object====\n\n* Traverse the merkle tree from the root down, and for each encountered node:\n** Check whether this node corresponds to a leaf node (transaction) that is to be included OR any parent thereof:\n*** If so, append a '1' bit to the flag bits\n*** Otherwise, append a '0' bit.\n** Check whether this node is an internal node (non-leaf) AND is the parent of an included leaf node:\n*** If so:\n**** Descend into its left child node, and process the subtree beneath it entirely (depth-first).\n**** If this node has a right child node too, descend into it as well.\n*** Otherwise: append this node's hash to the hash list.\n\n====Parsing a partial merkle tree object====\n\nAs the partial block message contains the number of transactions in the entire block, the shape of the merkle tree is known before hand. Again, traverse this tree, computing traversed node's hashes along the way:\n* Read a bit from the flag bit list:\n** If it is '0':\n*** Read a hash from the hashes list, and return it as this node's hash.\n** If it is '1' and this is a leaf node:\n*** Read a hash from the hashes list, store it as a matched txid, and return it as this node's hash.\n** If it is '1' and this is an internal node:\n*** Descend into its left child tree, and store its computed hash as L.\n*** If this node has a right child as well:\n**** Descend into its right child, and store its computed hash as R.\n**** If L == R, the partial merkle tree object is invalid.\n**** Return Hash(L || R).\n*** If this node has no right child, return Hash(L || L).\n\nThe partial merkle tree object is only valid if:\n* All hashes in the hash list were consumed and no more.\n* All bits in the flag bits list were consumed (except padding to make it into a full byte), and no more.\n* The hash computed for the root node matches the block header's merkle root.\n* The block header is valid, and matches its claimed proof of work.\n* In two-child nodes, the hash of the left and right branches was never equal.\n\n===Bloom filter format===\n\nA Bloom filter is a bit-field in which bits are set based on feeding the data element to a set of different hash functions. The number of hash functions used is a parameter of the filter. In Bitcoin we use version 3 of the 32-bit Murmur hash function. To get N \"different\" hash functions we simply initialize the Murmur algorithm with the following formula:\n\nnHashNum * 0xFBA4C795 + nTweak\n\ni.e. if the filter is initialized with 4 hash functions and a tweak of 0x00000005, when the second function (index 1) is needed h1 would be equal to 4221880218.\n\nWhen loading a filter with the filterload command, there are two parameters that can be chosen. One is the size of the filter in bytes. The other is the number of hash functions to use. To select the parameters you can use the following formulas:\n\nLet N be the number of elements you wish to insert into the set and P be the probability of a false positive, where 1.0 is \"match everything\" and zero is unachievable.\n\nThe size S of the filter in bytes is given by (-1 / pow(log(2), 2) * N * log(P)) / 8. Of course you must ensure it does not go over the maximum size (36,000: selected as it represents a filter of 20,000 items with false positive rate of < 0.1% or 10,000 items and a false positive rate of < 0.0001%).\n\nThe number of hash functions required is given by S * 8 / N * log(2).\n\n==Copyright==\n\nThis document is placed in the public domain.", "category": "bips" }, { "instruction": "I'm trying to understand 
 - can you walk me through it?",
    "input": "",
    "output": "BIP: 60\n  Layer: Peer Services\n  Title: Fixed Length \"version\" Message (Relay-Transactions Field)\n  Authors: Amir Taaki \n  Comments-Summary: Discouraged for implementation (one person)\n  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0060\n  Status: Closed\n  Type: Specification\n  Assigned: 2013-06-16\n  License: PD\n
\n\n==Abstract==\n\n[[BIP 0037]] introduced a new flag to version messages which says whether to relay new transaction messages to that node.\n\nThe protocol version was upgraded to 70001, and the (now accepted) BIP 0037 became implemented.\n\nThe implementation is problematic because the RelayTransactions flag is an optional part of the version message stream.\n\n==Motivation==\n\nOne property of Bitcoin messages is their fixed number of fields. This keeps the format simple and easily understood. Adding optional fields to messages will cause deserialisation issues when other fields come after the optional one.\n\nAs an example, the length of version messages might be checked to ensure the byte stream is consistent. With optional fields, this checking is no longer possible. This is desirable to check for consistency inside internal deserialization code, and proper formatting of version messages originating from other nodes. In the future with diversification of the Bitcoin network, it will become desirable to enforce this kind of strict adherence to standard messages with field length compliance with every protocol version.\n\nAnother property of fixed-length field messages is the ability to pass stream operators around for deserialization. This property is also lost, as now the deserialisation code must know the remaining length of bytes to parse. The parser now requires an additional piece of information (remaining size of the stream) for parsing instead of being a dumb reader.\n\n==Specification==\n=== version ===\n\nWhen a node creates an outgoing connection, it will immediately advertise its version. The remote node will respond with its version. No further communication is possible until both peers have exchanged their version.\n\nPayload:\n\n{|class=\"wikitable\"\n! Field Size !! Description !! Data type !! Comments\n|-\n| 4 || version || int32_t || Identifies protocol version being used by the node\n|-\n| 8 || services || uint64_t || bitfield of features to be enabled for this connection\n|-\n| 8 || timestamp || int64_t || standard UNIX timestamp in seconds\n|-\n| 26 || addr_recv || net_addr || The network address of the node receiving this message\n|-\n|colspan=\"4\"| version >= 106\n|-\n| 26 || addr_from || net_addr || The network address of the node emitting this message\n|-\n| 8 || nonce || uint64_t || Node random nonce, randomly generated every time a version packet is sent. This nonce is used to detect connections to self.\n|-\n| ? || user_agent || var_str || [[bip-0014.mediawiki|User Agent]] (0x00 if string is 0 bytes long)\n|-\n| 4 || start_height || int32_t || The last block received by the emitting node\n|-\n| 1 || relay || bool || Whether the remote peer should announce relayed transactions or not, see [[bip-0037.mediawiki|BIP 0037]], since version >= 70001\n|}\n\nA \"verack\" packet shall be sent if the version packet was accepted.\n\nThe following services are currently assigned:\n\n{|class=\"wikitable\"\n! Value !! Name !! Description\n|-\n| 1 || NODE_NETWORK || This node can be asked for full blocks instead of just headers.\n|}\n\n=== Code Updates ===\n\nfRelayTx is added to the PushMessage() call inside PushVersion() (net.cpp)\n\n
\nvoid CNode::PushVersion()\n{\n    /// when NTP implemented, change to just nTime = GetAdjustedTime()\n    int64 nTime = (fInbound ? GetAdjustedTime() : GetTime());\n    CAddress addrYou = (addr.IsRoutable() && !IsProxy(addr) ? addr : CAddress(CService(\"0.0.0.0\",0)));\n    CAddress addrMe = GetLocalAddress(&addr);\n    RAND_bytes((unsigned char*)&nLocalHostNonce, sizeof(nLocalHostNonce));\n    printf(\"send version message: version %d, blocks=%d, us=%s, them=%s, peer=%s\\n\", PROTOCOL_VERSION, nBestHeight, addrMe.ToString().c_str(), addrYou.ToString().c_str(), addr.ToString().c_str());\n    PushMessage(\"version\", PROTOCOL_VERSION, nLocalServices, nTime, addrYou, addrMe,\n                nLocalHostNonce, FormatSubVersion(CLIENT_NAME, CLIENT_VERSION, std::vector()),\n                nBestHeight, true);\n}\n
\n\nAdditionally the protocol version is increased from 70001 to 70002.\n\n==Copyright==\n\nThis document is placed in the public domain.", "category": "bips" }, { "instruction": "Hey, I need to set up 
 - what's the command line way to do that?",
    "input": "",
    "output": "BIP: 130\n  Layer: Peer Services\n  Title: sendheaders message\n  Authors: Suhas Daftuar \n  Status: Deployed\n  Type: Specification\n  Assigned: 2015-05-08\n  License: PD\n
\n\n==Abstract==\n\nAdd a new message, \"sendheaders\", which indicates that a node prefers to receive new block announcements via a \"headers\" message rather than an \"inv\".\n\n==Motivation==\n\nSince the introduction of \"headers-first\" downloading of blocks in 0.10, blocks will not be processed unless\nthey are able to connect to a (valid) headers chain. Consequently, block relay generally works\nas follows:", "category": "bips" }, { "instruction": "What's the deal with Bitcoin Operations Guide in Bitcoin? Explain it like I'm a friend.", "input": "", "output": "# A peer (P) responds to the \"inv\" with a \"getheaders\" message (to request headers up to the new tip) and a \"getdata\" message for the new tip itself", "category": "bips" }, { "instruction": "Can you show me the CLI commands for N responds with a \"headers\" message (with the header for the new block along with any preceding headers unknown to P) and a \"block\" message containing the new block?", "input": "", "output": "However, in the case where a new block is being announced that builds on the tip, it would be generally more efficient if the node N just announced the block header for the new block, rather than just the block hash, and saved the peer from generating and transmitting the getheaders message (and the required block locator).\n\nIn the case of a reorg, where 1 or more blocks are disconnected, nodes currently just send an \"inv\" for the new tip. Peers currently are able to request the new tip immediately, but wait until the headers for the intermediate blocks are delivered before requesting those blocks. By announcing headers from the last fork point leading up to the new tip in the block announcement, peers are able to request all the intermediate blocks immediately.\n\n==Specification==", "category": "bips" }, { "instruction": "I'm stuck with Bitcoin Operations Guide - what should I check?", "input": "", "output": "# Upon receipt of a \"sendheaders\" message, the node will be permitted, but not required, to announce new blocks by sending the header of the new block (along with any other blocks that a node believes a peer might need in order for the block to connect).", "category": "bips" }, { "instruction": "How do I troubleshoot Feature discovery is enabled by checking protocol version >= 70012 issues?", "input": "", "output": "==Additional constraints==\n\nAs support for sendheaders is optional, software that implements this may also optionally impose additional constraints, such as only honoring sendheaders messages shortly after a connection is established.\n\n==Backward compatibility==\n\nOlder clients remain fully compatible and interoperable after this change.\n\n==Implementation==\n\nhttps://github.com/bitcoin/bitcoin/pull/6494\n\n==Copyright==\n\nThis document is placed in the public domain.", "category": "bips" }, { "instruction": "What are the best practices for 
?",
    "input": "",
    "output": "BIP: 337\n  Layer: API/RPC\n  Title: Compressed Transactions\n  Authors: Tom Briar \n  Status: Draft\n  Type: Specification\n  Assigned: 2024-02-01\n  License: BSD-3-Clause\n  Discussion: https://github.com/bitcoin/bitcoin/pull/29134\n              https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-August/021924.html\n
\n\n== Introduction ==\n\n=== Abstract ===\nThis document proposes a serialization scheme for compressing Bitcoin transactions. The compressed Bitcoin transactions can reach a serialized size of less than 50% of the original serialized transaction. One method for compressing involves reducing the transaction outpoints in a potentially lossy way. Therefore, it is an optional path for compression. Compressing the outpoints is necessary for compressed transactions to reach less than 70% of the original size.\n\n=== Motivation ===\nTypical Bitcoin transactions usually contain a large amount of white space and padding due to specific fields that are often one of a minimal number of possibilities. We can use this fact and a few similar methods to create an encoding for 90% of Bitcoin transactions that are roughly 25-50% smaller.\n\nThere exists a working-in-progress app that allows the use of steganography to encode data in images to be passed around via various social media groups. When used in conjunction with this compression scheme and an elligator squared encryption, this would allow for a very secure and private form of broadcasting bitcoin transactions.\n\n=== Rationale ===\n\nThe four main methods to achieve a lower transaction size are:\n\n1. Packing transaction metadata before it and each of its inputs and outputs to determine the following data structure.\n\n2. Replacing 32-bit numeric values with either variable-length integers (VarInts) or compact integers (CompactSizes).\n\n3. Using compressed signatures and public key recovery upon decompression.\n\n4. Replacing the 36-byte Outpoint txid/vout pair with a block height and index.\n\n\n=== Backwards Compatibility ===\n\nThere are no concerns with backwards compatibility.\n\n=== Specification ===\n\n==== Primitives ====\n\n{| class=\"wikitable\" style=\"margin:auto\"\n|-\n! Name !! Width !! Description\n|-\n| CompactSize || 1-5 Bytes || For 0-253, encode the value directly in one byte. For 254-65535, encode 254 followed by two little-endian bytes. For 65536-(2^32-1), encode 255 followed by four little-endian bytes.\n|-\n| CompactSize Flag || 2 Bits || 1, 2, or 3 indicate literal values. 0 indicates that a CompactSize encoding of the value will follow.\n|-\n| VarInt || 1+ Bytes || 7-bit little-endian encoding, with each 7-bit word encoded in a byte. The highest bit of each byte is one if more bytes follow, and 0 for the last byte.\n|-\n| VLP-Bytestream || 2+ Bytes || A VarInt Length Prefixed Bytestream. It uses the prefixed VarInt to determine the length of the following byte stream.\n|}\n\n==== General Schema ====\n\n{| class=\"wikitable\" style=\"margin:auto\"\n|-\n! Name !! Width !! Description\n|-\n| Transaction metadata || 1 Bytes || Information on the structure of the transaction. See [[#transaction-metadata|Transaction Metadata]]\n|-\n| Version || 0-5 Bytes || If present according to the metadata field, a CompactSize encoding of the transaction version.\n|-\n| Input Count || 0-5 Bytes || If present according to the metadata field, a CompactSize encoding of the transaction input count.\n|-\n| Output Count || 0-5 Bytes || If present according to the metadata field, a CompactSize encoding of the transaction output count.\n|-\n| LockTime || 0-5 Bytes || If present according to the metadata field, a CompactSize encoding of the transaction LockTime.\n|-\n| Minimum Blockheight || 1-5 Bytes || If present according to the metadata field, a VarInt encoding of the minimum block height for transaction compressed inputs and LockTime.\n|-\n| Input Metadata+Output Metadata || 1+ Bytes || An encoding containing the metadata for all the inputs followed by all the outputs of the transaction. For each input, see [[#input-metadata|Input Metadata]], and for each output, see [[#output-metadata|Output Metadata]].\n|-\n| Input Data || 66+ Bytes || See [[#input-data|Input Data]].\n|-\n| Output Data || 3+ Bytes || See [[#output-data|Output Data]].\n|}\n\n\n==== Transaction Metadata ====\n\n{| class=\"wikitable\" style=\"margin:auto\"\n|-\n! Name !! Width !! Description\n|-\n| Version || 2 Bits || A CompactSize flag for the transaction version.\n|-\n| Input Count || 2 Bits || A CompactSize flag for the transaction input count.\n|-\n| Output Count || 2 Bits || A CompactSize flag for the transaction output count.\n|-\n| LockTime || 1 Bit || A boolean to indicate if the transaction has a LockTime.\n|-\n| Minimum Blockheight || 1 Bit || A boolean to indicate if the transaction minimum block height is greater than zero.\n|}\n\n\n==== Input Metadata ====\n\n{| class=\"wikitable\" style=\"margin:auto\"\n|-\n! Name !! Width !! Description\n|-\n| Compressed Signature || 1 Bit || A Boolean to determine if this input's signature is compressed. The signature is only compressed for P2TR on a key spend and for P2SH when it is a wrapped P2SH-WPKH.\n|-\n| Standard Hash || 1 Bit || A Boolean to determine if this input's signature hash type is standard (0x00 for Taproot, 0x01 for Legacy/Segwit).\n|-\n| Standard Sequence || 2 Bits || A CompactSize flag for this input's sequence. Encode literal values as follows: 1 = 0x00000000, 2 = 0xFFFFFFFE, 3 = 0xFFFFFFFF.\n|-\n| Compressed OutPoint || 1 bit || A Boolean to determine if the input's outpoint is compressed.\n|}\n\n\n==== Output Metadata ====\n\n{| class=\"wikitable\" style=\"margin:auto\"\n|-\n! Name !! Width !! Description\n|-\n| Encoded Script Type || 3 Bits || [[#script-type-encoding|Encoded Script Type]].\n|}\n\n\n==== Script Type Encoding ====\n\n{| class=\"wikitable\" style=\"margin:auto\"\n|-\n! Script Type !! Value\n|-\n| Uncompressed Custom Script || 0b000\n|-\n| Uncompressed P2PK || 0b001\n|-\n| Compressed P2PK || 0b010\n|-\n| P2PKH || 0b011\n|-\n| P2SH || 0b100\n|-\n| P2WPKH || 0b101\n|-\n| P2WSH || 0b110\n|-\n| P2TR || 0b111\n|}\n\n\n==== Input Data ====\n\n{| class=\"wikitable\" style=\"margin:auto\"\n|-\n! Name !! Width !! Description\n|-\n| Outpoint || 2-37 Bytes || The Outpoint Txid/Vout are determined to be compressed or otherwise by the \"Compressed Outpoint\" Boolean in the input metadata. For each compressed outpoint see [[#compressed-outpoint|Compressed Outpoint]]. For each uncompressed outpoint see [[#uncompressed-outpoint|Uncompressed Outpoint]].\n|-\n| Signature || 64+ Bytes || The Signature is determined to be compressed or otherwise by the output script of the previous transaction. For each compressed signature see [[#compressed-signature|Compressed Signature]]. For each uncompressed signature see [[#uncompressed-signature|Uncompressed Signature]].\n|-\n| Sequence || 0-5 Bytes || If present due to a non-standard sequence, a VarInt encoding of the sequence.\n|}\n\n\n==== Compressed Outpoint ====\n\n{| class=\"wikitable\" style=\"margin:auto\"\n|-\n! Name !! Width !! Description\n|-\n| Txid Block Height || 1-5 Bytes || A VarInt containing the offset from Minimum Blockheight for this Txid.\n|-\n| Txid Block Index || 1-5 Bytes || A VarInt containing the flattened index from the Txid block height for the Vout.\n|}\n\n\n==== Uncompressed Outpoint ====\n\n{| class=\"wikitable\" style=\"margin:auto\"\n|-\n! Name !! Width !! Description\n|-\n| Txid || 32 Bytes || Contains the 32 Byte Txid.\n|-\n| Vout || 1-5 Bytes || A CompactSize Containing the Vout of the Txid.\n|}\n\n\n\n==== Compressed Signature ====\n\n{| class=\"wikitable\" style=\"margin:auto\"\n|-\n! Name !! Width !! Description\n|-\n| Signature || 64 Bytes || Contains the 64 Byte signature.\n|-\n| Pubkey Hash || 0-20 Bytes || If input is P2SH-P2WPKH contains the 20 byte hash of the public key.\n|-\n| Hash Type || 0-1 Bytes || An Optional Byte containing the Hash Type if it was non-standard.\n|}\n\n\n==== Uncompressed Signature ====\n\n{| class=\"wikitable\" style=\"margin:auto\"\n|-\n! Name !! Width !! Description\n|-\n| Signature || 2+ Bytes || A VLP-Bytestream containing the signature.\n|}\n\n\n==== Output Data ====\n\n{| class=\"wikitable\" style=\"margin:auto\"\n|-\n! Name !! Width !! Description\n|-\n| Output Script || 2+ Bytes || A VLP-Bytestream containing the output script.\n|-\n| Amount || 1-9 Bytes || A VarInt containing the output amount.\n|}\n\n==== Ideal Transaction ====\n\nThe compression scheme was designed to be optimal for a \"typical\" transaction, spending a few close-in-age inputs and having one or two outputs. Here are size\nvalues for such a transaction, which demonstrate the effectiveness of the compression.\n\n{| class=\"wikitable\" style=\"margin:auto\"\n|-\n! Field !! Requirements !! Savings Up To\n|-\n| Version || Less than four || 30 Bits\n|-\n| Input Count || Less than four || 30 Bits\n|-\n| Output Count || Less than four || 30 Bits\n|-\n| LockTime || 0 || 30 Bits\n|-\n| Input Sequence || 0x00, 0xFFFFFFFE, or 0xFFFFFFFF || 62 Bits For Each Input\n|-\n| Input Txid || Compressed Outpoint || 23 - 31 Bytes For Each Input\n|-\n| Input Vout || Compressed Outpoint || (-1) - 3 Bytes For Each Input\n|-\n| Input Signature || Non-custom Script Signing || 40 - 72 Bytes For Each Legacy Input\n|-\n| Input Hash Type || 0x00 for Taproot, 0x01 for Legacy || 7 Bits For Each Input\n|-\n| Output Script || Non-custom Scripts || 2 - 5 Bytes For Each Output\n|-\n| Output Amount || No Restrictions || (-1) - 7 Bytes For Each Output\n|}\n\n=== Reference Implementation ===\n\nThis reference implementation adds two new RPC endpoints, compressrawtransaction and decompressrawtransaction. The first accepts a raw hex-encoded transaction and returns a compact hex-encoded transaction; also included in the output is a list of warnings to help ensure there are no unexpected uncompressed values. The second accepts a compact hex transaction and returns the uncompressed raw hex-encoded transaction.\n\nhttps://github.com/bitcoin/bitcoin/pull/29134\n\n=== Test Vectors ===\n\n==== Taproot ====\n\n===== Uncompressed =====\n020000000001017ad1d0cc314504ec06f1b5c786c50cf3cda30bd5be88cf08ead571b0ce7481fb0000000000fdffffff0188130000000000001600142da377ed4978fefa043a58489912f8e28e16226201408ce65b3170d3fbc68e3b6980650514dc53565f915d14351f83050ff50c8609495b7aa96271c3c99cdac1a92b1b45e77a4a870251fc1673596793adf2494565e500000000\n\n===== Compressed =====\n96b1ec7f968001b0218ce65b3170d3fbc68e3b6980650514dc53565f915d14351f83050ff50c8609495b7aa96271c3c99cdac1a92b1b45e77a4a870251fc1673596793adf2494565e58efefefe7d2da377ed4978fefa043a58489912f8e28e162262a608\n\n==== P2WPKH ====\n\n===== Uncompressed =====\n0200000000010144bcf05ab48b8789268a7ca07133241ad654c0739ac7165015b2d669eadb10ea0000000000fdffffff0188130000000000001600142da377ed4978fefa043a58489912f8e28e16226202473044022043ab639a98dfbc704f16a35bf25b8b72acb4cb928fd772285f1fcf63725caa85022001c9ff354504e7024708bce61f30370c8db13da8170cef4e8e4c4cdad0f71bfe0121030072484c24705512bfb1f7f866d95f808d81d343e552bc418113e1b9a1da0eb400000000\n\n===== Compressed =====\n96b1ec71968001932643ab639a98dfbc704f16a35bf25b8b72acb4cb928fd772285f1fcf63725caa8501c9ff354504e7024708bce61f30370c8db13da8170cef4e8e4c4cdad0f71bfe8efefefe7d2da377ed4978fefa043a58489912f8e28e162262a608\n\n==== P2SH-P2WPKH ====\n\n===== Uncompressed =====\n0200000000010192fb2e4332b43dc9a73febba67f3b7d97ba890673cb08efde2911330f77bbdfc00000000171600147a1979232206857167b401fdac1ffbf33f8204fffdffffff0188130000000000001600142da377ed4978fefa043a58489912f8e28e16226202473044022041eb682e63c25b85a5a400b11d41cf4b9c25f309090a5f3e0b69dc15426da90402205644ddc3d5179bab49cce4bf69ebfaeab1afa34331c1a0a70be2927d2836b0e8012103c483f1b1bd24dd23b3255a68d87ef9281f9d080fd707032ccb81c1cc56c5b00200000000\n\n===== Compressed =====\n96b1ec7c9e8001981641eb682e63c25b85a5a400b11d41cf4b9c25f309090a5f3e0b69dc15426da9045644ddc3d5179bab49cce4bf69ebfaeab1afa34331c1a0a70be2927d2836b0e87a1979232206857167b401fdac1ffbf33f8204ff8efefefe7d2da377ed4978fefa043a58489912f8e28e162262a608\n\n==== P2PKH ====\n\n===== Uncompressed =====\n02000000015f5be26862482fe2fcc900f06ef26ee256fb205bc4773e5a402d0c1b88b82043000000006a473044022031a20f5d9212023b510599c9d53d082f8e07faaa2d51482e078f8e398cb50d770220635abd99220ad713a081c4f20b83cb3f491ed8bd032cb151a3521ed144164d9c0121027977f1b6357cead2df0a0a19570088a1eb9115468b2dfa01439493807d8f1294fdffffff0188130000000000001600142da377ed4978fefa043a58489912f8e28e16226200000000\n\n===== Compressed =====\n96b1ec7c968001981431a20f5d9212023b510599c9d53d082f8e07faaa2d51482e078f8e398cb50d77635abd99220ad713a081c4f20b83cb3f491ed8bd032cb151a3521ed144164d9c8efefefe7d2da377ed4978fefa043a58489912f8e28e162262a608\n\n\n== Acknowledgements ==\nThank you to Andrew Poelstra, who helped invent and develop the ideas in the proposal and the code for reference implementation.", "category": "bips" }, { "instruction": "Walk me through setting up 
 step by step",
    "input": "",
    "output": "BIP: 21\n  Layer: Applications\n  Title: URI Scheme\n  Authors: Nils Schneider \n           Matt Corallo \n  Status: Closed\n  Type: Specification\n  Assigned: 2012-01-29\n  Replaces: 20\n  Proposed-Replacement: 321\n
\n\n=Superseded by BIP 321=\n\nThis BIP has been superseded and replaced with BIP 321. Please see [[bip-0321.mediawiki|BIP 321]] instead.\n\n=Original BIP=\n\nThis BIP is a modification of an earlier [[bip-0020.mediawiki|BIP 0020]] by Luke Dashjr. BIP 0020 was based off an earlier document by Nils Schneider. The alternative payment amounts in BIP 0020 have been removed.\n\n==Abstract==\nThis BIP proposes a URI scheme for making Bitcoin payments.\n\n==Motivation==\nThe purpose of this URI scheme is to enable users to easily make payments by simply clicking links on webpages or scanning QR Codes.\n\n==Specification==\n\n=== General rules for handling (important!) ===\n\nBitcoin clients MUST NOT act on URIs without getting the user's authorization.\nThey SHOULD require the user to manually approve each payment individually, though in some cases they MAY allow the user to automatically make this decision.\n\n=== Operating system integration ===\nGraphical bitcoin clients SHOULD register themselves as the handler for the \"bitcoin:\" URI scheme by default, if no other handler is already registered. If there is already a registered handler, they MAY prompt the user to change it once when they first run the client.\n\n=== General Format ===\n\nBitcoin URIs follow the general format for URIs as set forth in RFC 3986. The path component consists of a bitcoin address, and the query component provides additional payment options.\n\nElements of the query component may contain characters outside the valid range. These must first be encoded according to UTF-8, and then each octet of the corresponding UTF-8 sequence must be percent-encoded as described in RFC 3986.\n\n=== ABNF grammar ===\n\n(See also [[#simpler-syntax|a simpler representation of syntax]])\n\n bitcoinurn = \"bitcoin:\" bitcoinaddress [ \"?\" bitcoinparams ]\n bitcoinaddress = *base58\n bitcoinparams = bitcoinparam [ \"&\" bitcoinparams ]\n bitcoinparam = [ amountparam / labelparam / messageparam / otherparam / reqparam ]\n amountparam = \"amount=\" *digit [ \".\" *digit ]\n labelparam = \"label=\" *qchar\n messageparam = \"message=\" *qchar\n otherparam = qchar *qchar [ \"=\" *qchar ]\n reqparam = \"req-\" qchar *qchar [ \"=\" *qchar ]\n\nHere, \"qchar\" corresponds to valid characters of an RFC 3986 URI query component, excluding the \"=\" and \"&\" characters, which this BIP takes as separators.\n\nThe scheme component (\"bitcoin:\") is case-insensitive, and implementations must accept any combination of uppercase and lowercase letters. The rest of the URI is case-sensitive, including the query parameter keys.\n\n=== Query Keys ===\n\n*label: Label for that address (e.g. name of receiver)\n*address: bitcoin address\n*message: message that describes the transaction to the user ([[#examples|see examples below]])\n*(others): optional, for future extensions\n\n==== Transfer amount ====\n\nIf an amount is provided, it MUST be specified in decimal BTC.\nAll amounts MUST contain no commas and use a period (.) as the separating character to separate whole numbers and decimal fractions.\nI.e. amount=50.00 or amount=50 is treated as 50 BTC, and amount=50,000.00 is invalid.\n\nBitcoin clients MAY display the amount in any format that is not intended to deceive the user.\nThey SHOULD choose a format that is foremost least confusing, and only after that most reasonable given the amount requested.\nFor example, so long as the majority of users work in BTC units, values should always be displayed in BTC by default, even if mBTC or TBC would otherwise be a more logical interpretation of the amount.\n== Rationale ==\n\n===Payment identifiers, not person identifiers===\nCurrent best practices are that a unique address should be used for every transaction.\nTherefore, a URI scheme should not represent an exchange of personal information, but a one-time payment.\n\n===Accessibility (URI scheme name)===\nShould someone from the outside happen to see such a URI, the URI scheme name already gives a description.\nA quick search should then do the rest to help them find the resources needed to make their payment.\nOther proposed names sound much more cryptic; the chance that someone googles that out of curiosity are much slimmer.\nAlso, very likely, what he will find are mostly technical specifications - not the best introduction to bitcoin.\n\n==Forward compatibility==\nVariables which are prefixed with a req- are considered required. If a client does not implement any variables which are prefixed with req-, it MUST consider the entire URI invalid. Any other variables which are not implemented, but which are not prefixed with a req-, can be safely ignored.\n\n==Backward compatibility==\nAs this BIP is written, several clients already implement a bitcoin: URI scheme similar to this one, however usually without the additional \"req-\" prefix requirement. Thus, it is recommended that additional variables prefixed with req- not be used in a mission-critical way until a grace period of 6 months from the finalization of this BIP has passed in order to allow client developers to release new versions, and users of old clients to upgrade.\n\n== Appendix ==\n\n=== Simpler syntax ===\n\nThis section is non-normative and does not cover all possible syntax.\nPlease see the BNF grammar above for the normative syntax.\n\n[foo] means optional, <bar> are placeholders\n\n bitcoin:
[?amount=][?label=