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](https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki). 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](https://en.bitcoin.it/wiki/Protocol_documentation#Message_structure) 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
```json
{
	"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": <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>
}
```

### 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.