Split this protocol into 4 roles, then design accordingly, such that the 

Expect mature clients to abstract this complexity down to 2 (maker/taker).

Then, drive the protocol sequence and optional features based on declarative options and terms 

, using logical defaults if not over-ridden by the maker.

Takers simply let makers compete, and don't have much wiggle room to negotiate.  Makers can optionally list choices or flexibility in their terms.

nostr

n3xB - naive Nostr no-KYC exchange for Bitcoin

Rsync25

An idea for this...

Split this protocol into 4 roles, then design accordingly, such that the *maker declares* two things.
- What is on offer (something fungible + popular, but double-spendable eg. USD, or something non-fungible + unpopular, eg. real-estate).  
- What security guarantees are offered (by the maker) and what is required (by the taker) to execute the trade.

## 4 Roles

- BTC-sender-maker
- BTC-sender-taker
- BTC-getter-maker
- BTC-getter-taker

Expect mature clients to abstract this complexity down to 2 (maker/taker).

Then, drive the protocol sequence and optional features based on declarative options and terms *set by the maker*, using logical defaults if not over-ridden by the maker.   

Takers simply let makers compete, and don't have much wiggle room to negotiate.  Makers can optionally list choices or flexibility in their terms.  


4 Roles4 Roles