mirror of
https://github.com/bitcoin/bips.git
synced 2025-08-18 13:26:23 +00:00
Merge pull request #1864 from jonatack/2025-06-various-fixups
BIPs 77, 175, 443: various fixups
This commit is contained in:
commit
7d8b390c78
@ -222,7 +222,7 @@ receiver shares encoded in the URI.
|
|||||||
Instead of defining new Bitcoin URI parameters, the session-specific
|
Instead of defining new Bitcoin URI parameters, the session-specific
|
||||||
parameters are encoded in the [
|
parameters are encoded in the [
|
||||||
fragment](https://datatracker.ietf.org/doc/html/rfc3986#section-3.5)
|
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
|
The `#` fragment separator character must be [RFC 3986
|
||||||
percent-encoded](https://datatracker.ietf.org/doc/html/rfc3986#section-2.1)
|
percent-encoded](https://datatracker.ietf.org/doc/html/rfc3986#section-2.1)
|
||||||
|
@ -244,7 +244,6 @@ Communication between payer and payee as well as hashing the contract and genera
|
|||||||
|
|
||||||
==Reference implementations==
|
==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 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==
|
==Reference==
|
||||||
|
@ -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
|
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:
|
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_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.
|
* <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.
|
* 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>.
|
<code>OP_CHECKCONTRACTVERIFY</code>.
|
||||||
|
|
||||||
When evaluating <code>OP_CHECKCONTRACTVERIFY</code> (<code>OP_SUCCESS187</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>
|
<source>
|
||||||
<mode> <taptree> <pk> <index> <data>
|
<data> <index> <pk> <taptree> <mode>
|
||||||
</source>
|
</source>
|
||||||
|
|
||||||
where:
|
where:
|
||||||
|
Loading…
x
Reference in New Issue
Block a user