Skip to content

Instantly share code, notes, and snippets.

@nymius
nymius / silent_payments_psbt_spending.md
Last active January 19, 2026 17:34
Silent Payments PSBT spending

PSBT_IN_SP_TWEAK for spending silent payment outputs

Abstract

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.

Motivation

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.

@nymius
nymius / mastering_bitcoin_third_edition_chapter_6_notes.md
Created January 23, 2024 01:48
Some question which arose while reading the sixth chapter of Mastering Bitcoin, Third Edition, with the answers I found for them.
  • 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