This document provides a comprehensive overview of all available configuration options for OpenCode, including command-line flags, environment variables, and configuration file settings.
| module { | |
| "name": "schema", | |
| "description": "JSON Schema Inference", | |
| "version": "0.0.3.1", | |
| "homepage": "https://gist.github.com/pkoppstein/a5abb4ebef3b0f72a6ed", | |
| "license": "MIT", | |
| "author": "pkoppstein at gmail dot com" | |
| }; | |
| # NEWS: |
This document proposes an additional per input field for BIP 370 PSBTv2 that allows BIP 352 silent payment tweaks to be included in a PSBT of version 2. This field will be relevant to silent payment outputs spending.
BIPs 352 specify silent payments protocol, which provides a new way to create P2TR outputs and spend them. The existing PSBT fields are unable to support silent payments without changes, due to the new method by which outputs are created. BIP 375 and complementary BIP 374 specify how to create outputs locked with silent payment keys using PSBTs. But they don't specify how to unlock these outputs in a transaction. Therefore a new field must be defined to allow PSBTs to carry the information necessary for tweaking taproot keys without following the BIP 340 tagging scheme.
- Why bother to have two fields (marker and flag) to signal a segwit
transaction if a single one would have been enough to allow transaction
versioning (like flag field) and its solely presence will be enough to make it
different from non segwit transactions (like marker field)?
From this bitcoin stackexchange answer and this bitcoin wiki article I interpretate segwit transactions are recognized by post-segwit nodes for their pattern 0x00 0x01 in the marker and flag fields plus the witness field, rather than the marker field presence, as I originally thought. For > post-segwit nodes the marker and flag would be interpretated as a zero vin