bitcoin/bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2026-07-06 17:46:00 +00:00
Code Issues Releases Wiki Activity

Fix other broken anchors

Browse Source 
Used the following `sed` command and manually verified the unstaged
changes. Special cases that were not committed included external links
to Wikipedia which are case-sensitive, links specific lines in code, a
link to a title with a slash that had to be cleaned up, and links to
citations on the BIP repository that contain an underscore.

```
sed -E -i '
s/(\[\[[^][]*#)([^]|]*)(\||\]\])/\1\L\2\E\3/g
:again
s/(\[\[[^][]*#)([^]|]*)([: _]+)([^]|]*)(\||\]\])/\1\2-\4\5/g
t again
' bip-0*mediawiki
```
This commit is contained in:
Murch
2026-02-27 14:12:41 -08:00
parent 32b7adf847
commit b3a069464a
14 changed files with 46 additions and 46 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
bip-0129.mediawiki
View File

@@ -71,7 +71,7 @@ The Signer is any software or hardware that controls the private keys and can si
* The Coordinator creates a new multisig wallet creation session. The Coordinator constructs the multisig script and its policy parameters, such as the required number of signatures and the total number of Signers (<tt>M</tt> and <tt>N</tt>).
* The session should expire after some time period determined by the Coordinator, e.g., 24 hours. The timeout allows the encryption key to have lower entropy.
* If encryption is enabled, the Coordinator distributes a secret <tt>TOKEN</tt> to each Signer over a secure channel. The Signer can use the <tt>TOKEN</tt> to derive an <tt>ENCRYPTION_KEY</tt>. Refer to the [[#Encryption]] section below for details on the <tt>TOKEN</tt>, the key derivation function and the encryption scheme. Depending on the use case, the Coordinator can decide whether to share one common <tt>TOKEN</tt> for all Signers, or to have one per Signer.
* If encryption is enabled, the Coordinator distributes a secret <tt>TOKEN</tt> to each Signer over a secure channel. The Signer can use the <tt>TOKEN</tt> to derive an <tt>ENCRYPTION_KEY</tt>. Refer to the [[#encryption]] section below for details on the <tt>TOKEN</tt>, the key derivation function and the encryption scheme. Depending on the use case, the Coordinator can decide whether to share one common <tt>TOKEN</tt> for all Signers, or to have one per Signer.
* If encryption is disabled, the <tt>TOKEN</tt> is set to <tt>0x00</tt>, and all the encryption/decryption steps below can be skipped.
=====Signer=====
@@ -189,7 +189,7 @@ Also refer to [https://github.com/BlockchainCommons/Research/blob/master/papers/
==Compatibility==
This specification is not backwards compatible with existing multisig implementations.
BSMS is opt-in, meaning existing multisig implementations can continue working as-is, with the caveat that they are likely to have various pitfalls. Some of the problems with existing solutions have been described in the [[#Motivation]] section.
BSMS is opt-in, meaning existing multisig implementations can continue working as-is, with the caveat that they are likely to have various pitfalls. Some of the problems with existing solutions have been described in the [[#motivation]] section.
To comply with this standard, a Signer must be able to persist the descriptor record in its storage.