mirror of
https://github.com/bitcoin/bips.git
synced 2024-11-19 01:40:05 +01:00
docs: fix spelling (#1117)
Co-authored-by: Mark "Murch" Erhardt <murch@murch.one>
This commit is contained in:
John Bampton
GitHub
parent
2d9e431fbe
commit
f61885edcf
@ -28,7 +28,7 @@ Version bumping can also introduce incompatibilities and fracture the network. I
|
||||
|
||||
By 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.
|
||||
|
||||
Separation of the network protocol from the implemention, 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).
|
||||
Separation 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).
|
||||
|
||||
User 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.
|
||||
|
||||
|
||||
@ -348,7 +348,7 @@ By using DNS lookups, the MITM problem with IP transactions could be mitigated b
|
||||
|
||||
=== Namecoin ID ===
|
||||
|
||||
This proposal uses the Namecoin blockchain to associate an alias with a bitcoin address. Bitcoin queries a namecoin node. This retreives the structured data containing the bitcoin address(es) associated with this alias.
|
||||
This 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.
|
||||
|
||||
Using 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).
|
||||
|
||||
@ -401,4 +401,4 @@ Any text can be put into the brackets, allowing merchants to adapt it to all the
|
||||
New features can be added later to support uncovered cases.
|
||||
|
||||
|
||||
See the specification of [http://dot-bit.org/Namespace:Identity Namecoin ID] for more informations.
|
||||
See the specification of [http://dot-bit.org/Namespace:Identity Namecoin ID] for more information.
|
||||
|
||||
@ -57,7 +57,7 @@ Every reject message begins with the following fields. Some messages append extr
|
||||
|}
|
||||
|
||||
The human-readable string is intended only for debugging purposes; in particular, different implementations may
|
||||
use different strings. The string should not be shown to users or used for anthing besides diagnosing
|
||||
use different strings. The string should not be shown to users or used for anything besides diagnosing
|
||||
interoperability problems.
|
||||
|
||||
The following reject code categories are used; in the descriptions below, "server" is the peer generating
|
||||
|
||||
@ -53,10 +53,10 @@ Hash the redeem script according to BIP-0016 to get the P2SH address.
|
||||
3Q4sF6tv9wsdqu2NtARzNCpQgwifm2rAba
|
||||
|
||||
==Compatibility==
|
||||
* Uncompressed keys are incompatible with this specificiation. 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.
|
||||
* P2SH addressses 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.
|
||||
* 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.
|
||||
* 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.
|
||||
* Implementations that do not conform with this BIP will have compatibility issues with strictly-compliant wallets.
|
||||
* Implementations which do adopt this standard will be cross-compatible when choosing multisig addressses.
|
||||
* Implementations which do adopt this standard will be cross-compatible when choosing multisig addresses.
|
||||
* 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.
|
||||
|
||||
==Test vectors==
|
||||
|
||||
@ -143,7 +143,7 @@ If the receiver does not support the version of the sender, they should send an
|
||||
}
|
||||
</pre>
|
||||
|
||||
* <code>additionalfeeoutputindex=</code>, if the sender is willing to pay for increased fee, this indicate output can have its value substracted to pay for it.
|
||||
* <code>additionalfeeoutputindex=</code>, if the sender is willing to pay for increased fee, this indicate output can have its value subtracted to pay for it.
|
||||
|
||||
If the <code>additionalfeeoutputindex</code> 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.
|
||||
|
||||
@ -198,7 +198,7 @@ It is advised to hard code the description of the well known error codes into th
|
||||
===<span id="fee-output"></span>Fee output===
|
||||
|
||||
In some situation, the sender might want to pay some additional fee in the payjoin proposal.
|
||||
If such is the case, the sender must use both [[#optional-params|optional parameters]] <code>additionalfeeoutputindex=</code> and <code>maxadditionalfeecontribution=</code> to indicate which output and how much the receiver can substract fee.
|
||||
If such is the case, the sender must use both [[#optional-params|optional parameters]] <code>additionalfeeoutputindex=</code> and <code>maxadditionalfeecontribution=</code> to indicate which output and how much the receiver can subtract fee.
|
||||
|
||||
There is several cases where a fee output is useful:
|
||||
|
||||
@ -273,7 +273,7 @@ The sender should check the payjoin proposal before signing it to prevent a mali
|
||||
* For each outputs in the proposal:
|
||||
** Verify that no keypaths is in the PSBT output
|
||||
** If the output is the [[#fee-output|fee output]]:
|
||||
*** The amount that was substracted from the output's value is less than or equal to <code>maxadditionalfeecontribution</code>. Let's call this amount <code>actual contribution</code>.
|
||||
*** The amount that was subtracted from the output's value is less than or equal to <code>maxadditionalfeecontribution</code>. Let's call this amount <code>actual contribution</code>.
|
||||
*** Make sure the actual contribution is only paying fee: The <code>actual contribution</code> is less than or equals to the difference of absolute fee between the payjoin proposal and the original PSBT.
|
||||
*** Make sure the actual contribution is only paying for fee incurred by additional inputs: <code>actual contribution</code> is less than or equals to <code>originalPSBTFeeRate * vsize(sender_input_type) * (count(payjoin_proposal_inputs) - count(original_psbt_inputs))</code>. (see [[#fee-output|Fee output]] section)
|
||||
** If the output is the payment output and payment output substitution is allowed.
|
||||
@ -344,7 +344,7 @@ On top of this the receiver can poison analysis by randomly faking a round amoun
|
||||
|
||||
===<span id="output-substitution"></span>Payment output substitution===
|
||||
|
||||
Unless disallowed by sender explicitely via `disableoutputsubstitution=true` or by the BIP21 url via query parameter the `pjos=0`, the receiver is free to decrease the amount, remove, or change the scriptPubKey output paying to himself.
|
||||
Unless disallowed by sender explicitly via `disableoutputsubstitution=true` or by the BIP21 url via query parameter the `pjos=0`, the receiver is free to decrease the amount, remove, or change the scriptPubKey output paying to himself.
|
||||
Note that if payment output substitution is disallowed, the reveiver can still increase the amount of the output. (See [[#reference-impl|the reference implementation]])
|
||||
|
||||
For 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.
|
||||
@ -413,7 +413,7 @@ Here is pseudo code of a sender implementation.
|
||||
The <code>signedPSBT</code> represents a PSBT which has been fully signed, but not yet finalized.
|
||||
We then prepare <code>originalPSBT</code> from the <code>signedPSBT</code> via the <code>CreateOriginalPSBT</code> function and get back the <code>proposal</code>.
|
||||
|
||||
While we verify the <code>proposal</code>, we also import into it informations about our own inputs and outputs from the <code>signedPSBT</code>.
|
||||
While we verify the <code>proposal</code>, we also import into it information about our own inputs and outputs from the <code>signedPSBT</code>.
|
||||
At the end of this <code>RequestPayjoin</code>, the proposal is verified and ready to be signed.
|
||||
|
||||
We logged the different PSBT involved, and show the result in our [[#test-vectors|test vectors]].
|
||||
@ -557,7 +557,7 @@ public async Task<PSBT> RequestPayjoin(
|
||||
if (output.OriginalTxOut == feeOutput)
|
||||
{
|
||||
var actualContribution = feeOutput.Value - proposedPSBTOutput.Value;
|
||||
// The amount that was substracted from the output's value is less than or equal to maxadditionalfeecontribution
|
||||
// The amount that was subtracted from the output's value is less than or equal to maxadditionalfeecontribution
|
||||
if (actualContribution > optionalParameters.MaxAdditionalFeeContribution)
|
||||
throw new PayjoinSenderException("The actual contribution is more than maxadditionalfeecontribution");
|
||||
// Make sure the actual contribution is only paying fee
|
||||
@ -642,7 +642,7 @@ A successful exchange with:
|
||||
|
||||
{| class="wikitable"
|
||||
!InputScriptType
|
||||
!Orginal PSBT Fee rate
|
||||
!Original PSBT Fee rate
|
||||
!maxadditionalfeecontribution
|
||||
!additionalfeeoutputindex
|
||||
|-
|
||||
|
||||
@ -53,7 +53,7 @@ p //' n instead of p / 0' / n
|
||||
|
||||
Rather than specifying upfront which path is to be used for a specific purpose (i.e. external invoicing vs. internal change), different applications can specify arbitrary parent nodes and derivation paths. This allows for nesting of sublevels to arbitrary depth with application-specified semantics. Rather than trying to specify use cases upfront, we leave the design completely open-ended. Different applications can exchange these mappings for interoperability. Eventually, if certain mappings become popular, application user interfaces can provide convenient shortcuts or use them as defaults.
|
||||
|
||||
Note that BIP32 suggests reserving child 0 for the derivation of signing keys rather than sublevels. It is not really necessary to reserve signing key parents, however, as each key's parent's path can be explicitly stated. But unless we reserve a child for sublevel derivation, we lose the ability to nest deeper levels into the hierarchy. While we could reserve any arbitrary index for nesting sublevels, reserving child 0 seems simplest to implement, leaving all indices > 0 for contiguously indexed signing keys. We could also use MAX_INDEX (2<sup>31</sup> - 1) for this purpose. However, we believe doing so introduces more ideosyncracies into the semantics and will present a problem if we ever decide to extend the scheme to use indices larger than 31 bits.
|
||||
Note that BIP32 suggests reserving child 0 for the derivation of signing keys rather than sublevels. It is not really necessary to reserve signing key parents, however, as each key's parent's path can be explicitly stated. But unless we reserve a child for sublevel derivation, we lose the ability to nest deeper levels into the hierarchy. While we could reserve any arbitrary index for nesting sublevels, reserving child 0 seems simplest to implement, leaving all indices > 0 for contiguously indexed signing keys. We could also use MAX_INDEX (2<sup>31</sup> - 1) for this purpose. However, we believe doing so introduces more idiosyncrasies into the semantics and will present a problem if we ever decide to extend the scheme to use indices larger than 31 bits.
|
||||
|
||||
==Use Cases==
|
||||
|
||||
|
||||
@ -56,7 +56,7 @@ development, diversity, etc) to fork the Bitcoin Core software and it's good
|
||||
that there's many alternative implementations of the protocol (forks
|
||||
of Bitcoin Core or written from scratch).
|
||||
|
||||
But sometimes a bug in the reimplementaion of the consensus
|
||||
But sometimes a bug in the reimplementation of the consensus
|
||||
validation rules can prevent users of alternative implementation from
|
||||
following the longest (most work) valid chain. This can result in
|
||||
those users losing coins or being defrauded, making reimplementations
|
||||
|
||||
@ -37,7 +37,7 @@ In particular:
|
||||
|
||||
* The coinbase scriptSig is not counted
|
||||
* Signature operations in un-executed branches of a Script are not counted
|
||||
* OP_CHECKMULTISIG evaluations are counted accurately; if the signature for a 1-of-20 OP_CHECKMULTISIG is satisified 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.
|
||||
* 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.
|
||||
* Signature operations involving invalidly encoded signatures or public keys are not counted towards the limit
|
||||
|
||||
=== Add a new limit of 1,300,000,000 bytes hashed to compute transaction signatures per block ===
|
||||
|
||||
@ -14,7 +14,7 @@
|
||||
|
||||
When a Bitcoin transaction contains inputs that reference previous transaction outputs sent to different Bitcoin addresses, personally identifiable information of the user will leak into the blockchain in an uncontrolled manner. While undesirable, these transactions are frequently unavoidable due to the natural fragmentation of wallet balances over time.
|
||||
|
||||
This document proposes a set of best practice guidelines which minimize the uncontrolled disclosure of personally identifiable information by defining standard forms for transactions containing heterogenous input scripts.
|
||||
This document proposes a set of best practice guidelines which minimize the uncontrolled disclosure of personally identifiable information by defining standard forms for transactions containing heterogeneous input scripts.
|
||||
|
||||
==Copyright==
|
||||
|
||||
@ -23,8 +23,8 @@ This BIP is in the public domain.
|
||||
==Definitions==
|
||||
|
||||
* '''Heterogenous input script transaction (HIT)''': A transaction containing multiple inputs where the scripts of the previous transaction outputs being consumed are not identical (e.g. a transaction spending outputs which were sent to more than one Bitcoin address)
|
||||
* '''Unavoidable heterogenous input script transaction''': A HIT created as a result of a user’s desire to create a new output with a value larger than the value of his wallet's largest existing unspent output
|
||||
* '''Intentional heterogenous input script transaction''': A HIT created as part of a user protection protocol for reducing uncontrolled disclosure of personally-identifying information (PII)
|
||||
* '''Unavoidable heterogeneous input script transaction''': A HIT created as a result of a user’s desire to create a new output with a value larger than the value of his wallet's largest existing unspent output
|
||||
* '''Intentional heterogeneous input script transaction''': A HIT created as part of a user protection protocol for reducing uncontrolled disclosure of personally-identifying information (PII)
|
||||
|
||||
Throughout this procedure, when input scripts are evaluated for uniqueness, "input script" should be interpreted to mean, "the script of the previous output referenced by an input to a transaction".
|
||||
|
||||
@ -33,10 +33,10 @@ Throughout this procedure, when input scripts are evaluated for uniqueness, "inp
|
||||
The recommendations in this document are designed to accomplish three goals:
|
||||
|
||||
# Maximise the effectiveness of user-protecting protocols: Users may find that protection protocols are counterproductive if such transactions have a distinctive fingerprint which renders them ineffective.
|
||||
# Minimise the adverse consequences of unavoidable heterogenous input transactions: If unavoidable HITs are indistinguishable from intentional HITs, a user creating an unavoidable HIT benefits from ambiguity with respect to graph analysis.
|
||||
# Minimise the adverse consequences of unavoidable heterogeneous input transactions: If unavoidable HITs are indistinguishable from intentional HITs, a user creating an unavoidable HIT benefits from ambiguity with respect to graph analysis.
|
||||
# Limiting the effect on UTXO set growth: To date, non-standardized intentional HITs tend to increase the network's UTXO set with each transaction; this standard attempts to minimize this effect by standardizing unavoidable and intentional HITs to limit UTXO set growth.
|
||||
|
||||
In order to achieve these goals, this specification proposes a set of best practices for heterogenous input script transaction creation. These practices accommodate all applicable requirements of both intentional and unavoidable HITs while maximising the effectiveness of both in terms of preventing uncontrolled disclosure of PII.
|
||||
In order to achieve these goals, this specification proposes a set of best practices for heterogeneous input script transaction creation. These practices accommodate all applicable requirements of both intentional and unavoidable HITs while maximising the effectiveness of both in terms of preventing uncontrolled disclosure of PII.
|
||||
|
||||
In order to achieve this, two forms of HIT are proposed: Standard form and alternate form.
|
||||
|
||||
@ -44,7 +44,7 @@ In order to achieve this, two forms of HIT are proposed: Standard form and alter
|
||||
|
||||
Applications which wish to comply both with this procedure and BIP69 should apply this procedure prior to applying BIP69.
|
||||
|
||||
==Standard form heterogenous input script transaction==
|
||||
==Standard form heterogeneous input script transaction==
|
||||
|
||||
===Rules===
|
||||
|
||||
@ -63,7 +63,7 @@ The requirement that all output scripts are unique prevents address reuse. Restr
|
||||
|
||||
The requirement for at least one pair of outputs in an intentional HIT to be of equal value results in optimal behavior, and causes intentional HITs to resemble unavoidable HITs.
|
||||
|
||||
==Alternate form heterogenous input script transactions==
|
||||
==Alternate form heterogeneous input script transactions==
|
||||
|
||||
The formation of a standard form HIT is not possible in the following cases:
|
||||
|
||||
@ -100,7 +100,7 @@ An HIT formed via the preceding procedure will adhere to the following condition
|
||||
## The sum of the inputs in the set minus the value of the change output is equal to the standard value with a tolerance equal to the transaction fee.
|
||||
## Change outputs with a value of zero (virtual change outputs) are permitted. The are defined for the purpose of testing whether or not a HIT adheres to this specification but are not present in the version of the transaction which is broadcast to the network.
|
||||
|
||||
==Non-compliant heterogenous input script transactions==
|
||||
==Non-compliant heterogeneous input script transactions==
|
||||
|
||||
If a user wishes to create an output that is larger than half the total size of their spendable outputs, or if their inputs are not distributed in a manner in which the alternate form procedure can be completed, then the user can not create a transaction which is compliant with this procedure.
|
||||
|
||||
|
||||
@ -124,7 +124,7 @@ message FinalProof {
|
||||
// Bitcoin transaction.
|
||||
bytes proof_tx = 1;
|
||||
|
||||
// The metadata of the ouputs used in the proof transaction.
|
||||
// The metadata of the outputs used in the proof transaction.
|
||||
repeated OutputMeta output_metadata = 2;
|
||||
}
|
||||
|
||||
|
||||
@ -48,7 +48,7 @@ The author doesn't believe this is a problem because a BIP cannot be forced on c
|
||||
|
||||
== Process ==
|
||||
|
||||
* '''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] mailling with the BIP number and a statement that the champion intends to immediately submit the BIP for comments.
|
||||
* '''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.
|
||||
** The BIP must have been assigned BIP-number (i.e. been approved by the BIP editor) to be submitted for comments.
|
||||
* '''Comments.'''
|
||||
** 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.
|
||||
|
||||
@ -116,7 +116,7 @@ Since this format includes P2PKH keys, it is backwards compatible, but keep in m
|
||||
|
||||
==Implications==
|
||||
|
||||
Message 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 determing a signature's validity. This BIP can also be updated as new signature formats emerge.
|
||||
Message 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.
|
||||
|
||||
==Acknowledgements==
|
||||
|
||||
|
||||
@ -39,12 +39,12 @@ A new transaction digest algorithm is defined, but only applicable to sigops in
|
||||
9. nLocktime of the transaction (4-byte little endian)
|
||||
10. sighash type of the signature (4-byte little endian)
|
||||
|
||||
Semantics of the original sighash types remain unchanged, except the followings:
|
||||
Semantics of the original sighash types remain unchanged, except the following:
|
||||
# The way of serialization is changed;
|
||||
# All sighash types commit to the amount being spent by the signed input;
|
||||
# <code>FindAndDelete</code> of the signature is not applied to the <code>scriptCode</code>;
|
||||
# <code>OP_CODESEPARATOR</code>(s) after the last executed <code>OP_CODESEPARATOR</code> are not removed from the <code>scriptCode</code> (the last executed <code>OP_CODESEPARATOR</code> and any script before it are always removed);
|
||||
# <code>SINGLE</code> does not commit to the input index. When <code>ANYONECANPAY</code> is not set, the semantics are unchanged since <code>hashPrevouts</code> and <code>outpoint</code> together implictly commit to the input index. When <code>SINGLE</code> is used with <code>ANYONECANPAY</code>, omission of the index commitment allows permutation of the input-output pairs, as long as each pair is located at an equivalent index.
|
||||
# <code>SINGLE</code> does not commit to the input index. When <code>ANYONECANPAY</code> is not set, the semantics are unchanged since <code>hashPrevouts</code> and <code>outpoint</code> together implicitly commit to the input index. When <code>SINGLE</code> is used with <code>ANYONECANPAY</code>, omission of the index commitment allows permutation of the input-output pairs, as long as each pair is located at an equivalent index.
|
||||
|
||||
The items 1, 4, 7, 9, 10 have the same meaning as the original algorithm. <ref name=wiki></ref>
|
||||
|
||||
|
||||
@ -85,7 +85,7 @@ a 64 bit nonce and a 64 bit counter into 64 bytes of output. This output is used
|
||||
Poly1305, 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
|
||||
256 bit secret key.
|
||||
|
||||
The 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 encyption of the packet lengths.
|
||||
The 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.
|
||||
|
||||
<code>K_1</code> must be used to only encrypt the payload size of the encrypted message to avoid leaking information by revealing the message size.
|
||||
|
||||
|
||||
@ -207,7 +207,7 @@ func main() {
|
||||
|
||||
prevOutputScripts, err := fetchPrevOutputScripts(client, block)
|
||||
if err != nil {
|
||||
fmt.Println("Couldn't fetch prev output scipts: ", err)
|
||||
fmt.Println("Couldn't fetch prev output scripts: ", err)
|
||||
return
|
||||
}
|
||||
|
||||
|
||||
@ -633,7 +633,7 @@ values are valid, then it does not matter which is chosen as either way the tran
|
||||
===Proprietary Use Type===
|
||||
|
||||
For all global, per-input, and per-output maps, the type <tt>0xFC</tt> is reserved for proprietary use.
|
||||
The proprietary use type requires keys that follow the type with a compact size unsigned integer representing the length of the string identifer, followed by the string identifier, then a subtype, and finally any key data.
|
||||
The 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.
|
||||
|
||||
The 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.
|
||||
It can also be the empty string although this is not recommended.
|
||||
|
||||
@ -276,7 +276,7 @@ Miner provides additional text-based information.
|
||||
Currently, there is a similar protocol feature '''mining.capabilities''' that
|
||||
was intended for various protocol extensions. However, '''mining.configure'''
|
||||
is incompatible with this feature as it requires a server response confirming
|
||||
all accepted/negotatied extensions. The reason why we made it incompatible is
|
||||
all accepted/negotiated extensions. The reason why we made it incompatible is
|
||||
that '''mining.capabilities''' request has no associated response.
|
||||
|
||||
|
||||
|
||||
@ -120,7 +120,7 @@ def find_roots_inner(p, a):
|
||||
return []
|
||||
elif len(p) == 2:
|
||||
return [p[0]]
|
||||
# Otherwise, split p in left*right using paramater a_vals[0].
|
||||
# Otherwise, split p in left*right using parameter a_vals[0].
|
||||
t = poly_monic(poly_trace(p, a))
|
||||
left = poly_gcd(list(p), t)
|
||||
right = poly_divmod(list(left), p)
|
||||
|
||||
@ -248,7 +248,7 @@ Before any input or output may be added, the constructor must check the PSBT_GLO
|
||||
Inputs may only be added if the Inputs Modifiable flag is True.
|
||||
Outputs may only be added if the Outputs Modifiable flag is True.
|
||||
|
||||
When an input or output is added, the corresponding PSBT_GLOBAL_INPUT_COUNT or PSBT_GLOBAL_OUTPUT_COUNT must be incremeted to reflect the number of inputs and outputs in the PSBT.
|
||||
When an input or output is added, the corresponding PSBT_GLOBAL_INPUT_COUNT or PSBT_GLOBAL_OUTPUT_COUNT must be incremented to reflect the number of inputs and outputs in the PSBT.
|
||||
When an input is added, it must have PSBT_IN_PREVIOUS_TXID and PSBT_IN_OUTPUT_INDEX set.
|
||||
When an output is added, it must have PSBT_OUT_VALUE and PSBT_OUT_OUTPUT_SCRIPT set.
|
||||
If the input has a required timelock, Constructors must set the requisite timelock field.
|
||||
|
||||
Loading…
Reference in New Issue
Block a user