nips/90.md

NIP-90

Partially Signed Bitcoin Transactions

draft optional author:ronaldstoner author:Armin Sabouri author:satsie author:benthecarman

Abstract

This NIP defines an event type for partially signed bitcoin transactions (PSBT) that can be transferred via the Nostr relay network. 1174 is the event kind representing a Bitcoin transaction in standard PSBT format, regardless if the transaction is partially signed or fully finalized.

A special event with kind 1174 which contains an encoded PSBT. PSBTs used under this spec can be any version that conforms to BIP-0174. Since PSBTs have versioning built in, BIP-0174 recommends bitcoin clients and libraries stop parsing a PSBT if the version is not supported.

PSBTs are encoded as a base64 string, and are contained in the content field. These events use a specific kind identifier so that clients do not need to render PSBTs the same as they do notes, invoices, and other event kind identifiers. If clients wish to display PSBTs they can choose to do so in whatever format they wish (string, QR Code, view render).

The network magic is contained in the tags field. This is to identify the network that the transaction is for. The common ones are:

- mainnet: f9beb4d9
- testnet3: 0b110907
- signet: 0a03cf40
- testnet/regtest: fabfb5da

PSBTs transmitted via the Nostr network provide a decentralized communication layer, encryption, and digital signature benefits with no username and password required for participants to coordinate and sign transactions using separate sovereign bitcoin private keys.

Protocol Flow

The following are two protocol flow examples using the 1174 event kind. Other flows that could be used encompass various interactive/multi-party solutions such as coin joins, swaps or Schnorr based multisig solutions (FROST/Musig2).

Multisig P2WSH

2-of-2 Multisignature setup with Alice and Bob using a central coordinator

1. The coordinator publishes a PSBT that spends outputs controlled by Alice and Bob's multi-signature.
2. Alice listens for event type 1174. Alice provides a signature for each input and publishes the updated PSBT referencing the original note using the ref tag.
3. Bob performs the same steps
4. Once the coordinator has received a quorum of signatures the transaction is finalized and broadcast

Payjoin

1. Sender publishes PSBT as specified by BIP-078.
2. Receiver adds inputs and outputs to original PSBT and publishes the updated PSBT referencing the original note using the ref tag as specified in the “e” event reference tag detailed in the tags section of NIP-01.
3. Sender verifies the final PSBT, and broadcasts the transaction

Event Format

{
	"id": <32-bytes lowercase hex-encoded sha256 of the serialized event data>,
	"pubkey": <32-bytes lowercase hex-encoded public key of event creator>,
	"created_at": <unix timestamp in seconds of when event created>,
	"kind": 1174 <hardcoded integer>,
	"tags": [
		[“e”, <32-bytes lowercase hex-encoded sha256 id of the previous serialized event data> ], 
		[“magic”, <4-byte hex value representing the Bitcoin network identifier>],
		[“relays”, <list of relays to broadcast event>],
	],
	"content": <hex encoded PSBT>,
	"sig": <64-bytes hex of the signature of the sha256 hash of the serialized event data, which is the same as the "id" field>
}

Additional Encryption

The encryption used by DMs in NIP-04 can be utilized to further protect the base64 encoded data in the content field. This adds an extra layer of protection from those attempting to get information regarding transaction creation via nostr event data similar to how NIP-46 and NIP-47 implement NIP-04.

• nip04_encrypt
  • params [pubkey, plaintext]
  • result nip4 ciphertext
• nip04_decrypt
  • params [pubkey, nip4 ciphertext]
  • result [plaintext]

Note that pubkey is a hex-encoded strings.

Note:

The "e" field is optional and is used when replying to a prior event.

The "relays" field is optional and can be used to provide relay URL recommendations to clients for improved censorship resistance.