Skip to content

Use # for mediawiki numbered list #20

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: p2qrh
Choose a base branch
from
Open

Use # for mediawiki numbered list #20

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
b331c2d
use # for mediawiki numbered list
xoloki Mar 17, 2025
45a50fb
fix another numbered list in the same section
xoloki Mar 17, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 9 additions & 9 deletions bip-0360.mediawiki
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -341,11 +341,11 @@ If there is only a single public key, the hash is computed as the HASH256 of the
In order to support multiple keys, as in the context of multisig or singlesig hybrid cryptography, the hash is
computed as a commitment to a vector of public key hashes:

1. Sort the public keys first by key type, then by public key value
2. For each sorted public key, compute its HASH256
3. Concatenate all the public key hashes in sorted order
4. Prepend key type bitmask and threshold to the concatenated hashes
5. Compute the HASH256 of the result
# Sort the public keys first by key type, then by public key value
# For each sorted public key, compute its HASH256
# Concatenate all the public key hashes in sorted order
# Prepend key type bitmask and threshold to the concatenated hashes
# Compute the HASH256 of the result

For example with 4 public keys:

Expand Down Expand Up @@ -382,10 +382,10 @@ cryptographic commitment in the hash computation and revealed in the attestation

Only a single 32-byte X-only secp256k1 public key can be provided as key type 0. There are a few reasons for this:

1. It maintains Taproot compatibility by removing ambiguity which key is representative of the Taptree.
2. It prevents abuse of public keys to store arbitrary data once quantum computing is ubiquitous.
3. When a secp256k1 key is specified in the key type bitmask, how many keys it commits to is unambiguous.
4. If multiple keys need to be committed to, they must be aggregated, which saves on transaction size.
# It maintains Taproot compatibility by removing ambiguity which key is representative of the Taptree.
# It prevents abuse of public keys to store arbitrary data once quantum computing is ubiquitous.
# When a secp256k1 key is specified in the key type bitmask, how many keys it commits to is unambiguous.
# If multiple keys need to be committed to, they must be aggregated, which saves on transaction size.

This design maintains compatibility for [https://github.com/bitcoin/bips/blob/master/bip-0114.mediawiki BIP-114]
Taproot Merkelized Alternative Script Tree (MAST) merkle root in the commitment, which makes P2QRH a
Expand Down