One #2
Open
One #2
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
BIP-85: formatting and changelog updates, and add word cases for application 39'
Second sentence in the second paragraph of the Forwarding Addresses section, had a slight grammatical error that needed correcting. Helpful for the flurry of interested people keen on reviewing the BIP (i.e. Institutions, non-English nation-states)
Add BIP 349: OP_INTERNALKEY
an template address ↦ a template address
In order for this section to fully be grasped by readers, minor grammatical errors need to be fixed, especially when explaining the "Nonce exfiltration protection"
Fix link to considerations section in BIP-84
BIP340: minor grammar edits
Improve the clarity of the BIP w.r.t. pubkeys in the following ways:
- be specific about the purpose of pubkey types in PSBT fields
("plain pubkey" alone doesn't say a lot, especially if it's used
repeatedly within a field)
- replace all uses of "plain pubkey" by "compressed pubkey"
(the only category that should matter is whether the pubkey type
is "x-only" or "plain")
- use consistent word order, e.g. prefer
"compressed aggregate public key" over "aggregate compressed public key"
BIP 348: OP_CHECKSIGFROMSTACK
BIP125: update status to Final
…larity BIP-373: denote different public key types/purposes consistently
Co-authored-by: Sebastian Falbesoner <sebastian.falbesoner@gmail.com>
Co-authored-by: Sebastian Falbesoner <sebastian.falbesoner@gmail.com>
BIP348: trivial text correction
As Bitcoin has grown, the introduction of new address formats describing new forms of payment instructions has become increasingly fraught with compatibility issues. Not only does there exist traditional on-chain addresses, but some recipients wish to receive Lightning (when the sender supports it) or newer formats such as Silent Payments. This has led to increasing use of the BIP 21 query parameters to encode further optional payment instructions. Looking forward, as new payment instructions get adopted, it makes much more sense to include them in query parameters rather than replace the existing address field, ensuring compatibility with senders and recipients who may or may not be upgraded to support all the latest payment instructions. This updates BIP 321 to suggest that future address formats do this. Further, it updates BIP 321 to allow an empty bitcoin address in cases where new payment instructions have moved to becoming mandatory. This isn't a backwards-incompatible change any more than switching to a new address format is, so doesn't impact existing BIP 21 implementations in a new way, however provides a nice conclusion to the query-parameter-based upgrade path - once a form of payment instructions has broad adoption, senders can simply drop the existing address field, keeping their existing query parameter encoding, rather than replace the existing address field. It also addresses the question of what to do if a wallet no longer wishes to receive some legacy on-chain address, but has multiple payment instruction formats that they wish to include - deciding which one to place in the address field would be a difficult task. Finally, it defines a new query parameter, the `pop` parameter, which allows the initiating application to receive callbacks for proof of payment completion.
…-bodies BIP 321: URI Scheme (Replace BIP 21 with a new BIP containing information about more modern usage of it)
BIP 119: fix link to MES16 paper
Co-authored-by: xiaobei0715 <1505929057@qq.com> Co-authored-by: wgyt <wgythe@gmail.com> Co-authored-by: Ragnar <rodiondenmark@gmail.com>
* Update bip-0154.mediawiki * Update bip-0154.mediawiki
…#1836) * Update bip-0099.mediawiki * Update bip-0099.mediawiki
…xups Collect and curate typo fixups from April
BIP 197: Update the invalid link
BIP 54: Consensus Cleanup
BIP48: Add p2tr script type derivation
- Redefine bitcoin base unit to smallest unit - Propose BIP 21Q: Redefine bitcoin base unit to smallest indivisible unit - Adds comments acknowledging and handling sats and satoshis - Make use of "base unit" and variations more consistent and intentional - Make "bitcoin" v "Bitcoin" consistent - Made "bitcoin" v "Bitcoin" consistent by using Bitcoin for the protocol and idea, and bitcoin for the units, which I believe is conventional style.
BIP177: Redefine Bitcoin’s Base Unit
- Adds BIP172: Define Bitcoin Subunits as Satoshis
BIP48: Add P2SH-P2WSH and P2TR mainnet examples
BIP-372: Fix references and links formatting and minor typos
BIP 443: OP_CHECKCONTRACTVERIFY
Since the version is denoted as uint64, the size should be 8 bytes.
bip-0331: correct size of version field in sendpackages
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
19 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.