nips/90.md

NIP-90
======

Partially Signed Bitcoin Transactions
--------------------------------------------
`draft` `optional` `author:ronaldstoner` `author:Armin Sabouri` `author:satsie` 

# 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 are version 0 [BIP-0174](https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki).

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](https://en.bitcoin.it/wiki/Protocol_documentation#Message_structure) are:
```
- mainnet: f9beb4d9
- testnet: 0b110907
- signet: 0a03cf40
- 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
```json
{
	"id": <32-bytes lowercase hex-encoded sha256 of the serialized event data>,
	"pubkey": <32-bytes lowercase hex-encoded public key>,
	"created_at": <unix timestamp in seconds>,
	"kind": 1174 <hardcoded integer>,
	"tags": [
		[“e”, <32-bytes lowercase hex-encoded sha256 of the previous serialized event data> ], // provided when replying
		[“magic”, <4-byte hex value representing the Bitcoin network identifier>],
		[“relays”, <list of relays to broadcast event>],
	],
	"content": <base 64 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>
}
```

## Explanation of fields:
```
id: The sha256 hash of the serialized event payload.
pubkey: The public key of the creator of the event.
created_at: A Unix timestamp indicating the time when the event was created.
kind: An integer value used to indicate the type of event. For PSBTs, the kind is set to 1174.
tags: An array of tags to capture additional information about the multisig transaction:
	“e”: (optional): the 32 byte lowercase hex encoded sha256 event id of a prior event id. Only required when replying.
	“magic”: the 4 byte hex representation of the network that the transaction belongs to.
	“relays”: (optional) tag provides relays to broadcast the transactions.
content: PSBT encoded as base64.
sig: The signature of the sha256 hash of the serialized event data, which is the same as the "id" field.
```

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