bitcoin/bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2025-08-18 13:26:23 +00:00
Code Issues Releases Wiki Activity

Merge pull request #1864 from jonatack/2025-06-various-fixups

Browse Source 
BIPs 77, 175, 443: various fixups
This commit is contained in:
Mark "Murch" Erhardt 2025-06-03 14:39:06 -07:00 committed by GitHub
commit 7d8b390c78
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
3 changed files with 5 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
bip-0077.md
View File

@ -222,7 +222,7 @@ receiver shares encoded in the URI.
Instead of defining new Bitcoin URI parameters, the session-specific
parameters are encoded in the [
fragment](https://datatracker.ietf.org/doc/html/rfc3986#section-3.5)
of the the mailbox endpoint URL.
of the mailbox endpoint URL.
The `#` fragment separator character must be [RFC 3986
percent-encoded](https://datatracker.ietf.org/doc/html/rfc3986#section-2.1)

1
bip-0175.mediawiki
View File

@ -244,7 +244,6 @@ Communication between payer and payee as well as hashing the contract and genera
==Reference implementations==
* Reference wallet implementation, based on Copay project : https://github.com/commerceblock/copay ([[https://github.com/commerceblock/copay/pull/1|pull_request]])
* Reference implementation to Hash to Partial Derivation Path Mapping in javascript ([[https://github.com/commerceblock/pay-to-contract-lib/blob/master/lib/contract.js|https://github.com/commerceblock/pay-to-contract-lib]])
==Reference==

8
bip-0443.mediawiki
View File

@ -38,7 +38,7 @@ This document is licensed under the 3-clause BSD license.
The ability to constrain the future of coins beyond what is possible with presigned transactions is at the core of
numerous attempts to improve bitcoin. Some of the proposed applications include:
* UTXO sharing schemes like Ark, CoinPools, Timeout Trees, etc. use various types of output restrictions in order to enable multiple parties to share the control of a UTXO, while ensuring that each participant controls their own `balance.
* UTXO sharing schemes like Ark, CoinPools, Timeout Trees, etc. use various types of output restrictions in order to enable multiple parties to share the control of a UTXO, while ensuring that each participant controls their own balance.
* <code>OP_VAULT</code><ref>[[bip-0345.mediawiki|BIP-345]]</ref> is a proposed opcode to implement a 2-step withdrawal process, enabling on-chain reactive security.
* <code>OP_CHECKTEMPLATEVERIFY</code><ref>[[bip-119.mediawiki|BIP-114]]</ref> is a long-proposed opcode to constrain a transaction to a ''template'' with a fixed set of outputs.
* Sidechains and rollups could be implemented via a UTXO encumbered with a recursive covenant, updating the sidechain state root every time it is spent.
@ -135,10 +135,10 @@ The tapscript opcode <code>OP_SUCCESS187</code> (<code>0xbb</code>) is constrain
<code>OP_CHECKCONTRACTVERIFY</code>.
When evaluating <code>OP_CHECKCONTRACTVERIFY</code> (<code>OP_SUCCESS187</code>,
<code>0xbb</code>), the expected format of the stack, shown bottom to top, is:
<code>0xbb</code>), the expected format of the stack, shown bottom-to-top, is:
<source>
<mode> <taptree> <pk> <index> <data>
<data> <index> <pk> <taptree> <mode>
</source>
where:
@ -462,4 +462,4 @@ without upgrade except for mining and block validation.
== Acknowledgements ==
TODO
TODO