├── README.md ├── mip-0001 └── mip-0001.md ├── mip-0002 └── mip-0002.md ├── mip-0003 └── mip-0003.md ├── mip-0004 └── mip-0004.md ├── mip-0005 └── mip-0005.md ├── mip-0006 └── mip-0006.md ├── mip-0007 └── mip-0007.md └── mip-0009 └── mip-0009.md /README.md: -------------------------------------------------------------------------------- 1 | # Memo Improvement Proposals (MIPs) 2 | 3 | Generally, memo features are opt-in. 4 | Clients can choose whether to support or not support each action. 5 | For instance, Wewo has [blogs](https://wewo.cash/blogs/) and 6 | Memberapp has [maps](https://memberapp.github.io/#map). 7 | Memo.cash doesn't yet support either feature. 8 | 9 | Since consensus is not required, there isn't currently a need for a strict approval process. 10 | However, sharing protocol additions and motivations is helpful for healthy collaboration. 11 | 12 | 13 | | Id | Title | Created | Status | 14 | | --- | --- | --- | --- | 15 | | MIP-1 | [Example](mip-0001/mip-0001.md) | 2018-09-09 | - | 16 | | MIP-2 | [Send money](mip-0002/mip-0002.md) | 2018-09-13 | Final | 17 | | MIP-3 | [Delegated keys](mip-0003/mip-0003.md) | 2018-09-13 | Draft | 18 | | MIP-4 | [Private messages](mip-0004/mip-0004.md) | 2018-09-14 | Draft | 19 | | MIP-5 | [Documents](mip-0005/mip-0005.md) | 2018-09-29 | Draft | 20 | | MIP-6 | [Commerce](mip-0006/mip-0006.md) | 2018-11-17 | Draft | 21 | | MIP-7 | [Gigs](mip-0007/mip-0007.md) | 2018-12-07 | Draft | 22 | | MIP-9 | [Token exchange](mip-0009/mip-0009.md) | 2019-06-05 | Final (v2) | 23 | -------------------------------------------------------------------------------- /mip-0001/mip-0001.md: -------------------------------------------------------------------------------- 1 | ``` 2 | MIP: 1 3 | Title: Example MIP 4 | Author: Jason Chavannes 5 | Status: - 6 | Created: 2018-09-09 7 | ``` 8 | 9 | ## Abstract 10 | 11 | MIP summary. 12 | 13 | ## Motivation 14 | 15 | Why MIP is needed. 16 | 17 | ## Specification 18 | 19 | How MIP works. 20 | 21 | ## Reference Implementation 22 | 23 | Example code. 24 | 25 | ## See Also 26 | 27 | Discussion, references, etc. 28 | -------------------------------------------------------------------------------- /mip-0002/mip-0002.md: -------------------------------------------------------------------------------- 1 | ``` 2 | MIP: 2 3 | Title: Send money 4 | Author: Jason Chavannes 5 | Status: Final 6 | Created: 2018-09-13 7 | ``` 8 | 9 | ## Abstract 10 | 11 | Add action prefixes for sending money between users. 12 | This includes not just sending, but requesting payment. 13 | 14 | ## Motivation 15 | 16 | There are some cases where people like to publicly send money to each other. 17 | This is evident by services like Venmo where many people will choose to publicly share their payments. 18 | 19 | ## Specification 20 | 21 | Add two new protocol actions: 22 | 23 | | Action | Prefix | Values | 24 | |---|---|---| 25 | | Send money | 0x6d24 | txhash(0/30), message(184/217) | 26 | | Request money (invoice) | 0x6d25 | address(35), message(179) | 27 | 28 | Transaction hash is an optional field in send money to indicate if paying a specific invoice. 29 | 30 | ## Reference Implementation 31 | 32 | Planned 33 | 34 | ## See Also 35 | -------------------------------------------------------------------------------- /mip-0003/mip-0003.md: -------------------------------------------------------------------------------- 1 | ``` 2 | MIP: 3 3 | Title: Delegated keys 4 | Author: Jason Chavannes 5 | Status: Draft 6 | Created: 2018-09-13 7 | ``` 8 | 9 | ## Abstract 10 | 11 | Associate multiple keys in a hierarchy with a single identity. 12 | The original parent key will be the main address associated with the identity. 13 | 14 | ## Motivation 15 | 16 | Having only a single key associated with an identity has a couple of limitations. 17 | First, your identity can only be associated with a single service. 18 | Second, you must trust that service to practice good security with your key 19 | and cannot use security measures like cold storage if your identity is being used regularly. 20 | 21 | Having a hierarchy of keys enables linking an identity across multiple services. 22 | The primary keys at the top of the tree can be secured in cold storage. 23 | Intermediate keys can be used similar to being your own certificate authority 24 | and using intermediate certs. 25 | Can use schemes similar to OAuth to easily sign-in and link identity between services. 26 | 27 | Can also be extended in the future to limit capabilities of child keys. 28 | For instance you might want a service to be able to post on your behalf 29 | but not change your name. 30 | 31 | Another action that could be added are aliases. 32 | Even though posts would be associated with a single identity, 33 | you would know which services they came through. 34 | 35 | 36 | ## Specification 37 | 38 | #### Protocol Actions 39 | 40 | | Action | Prefix | Values | 41 | |---|---|---| 42 | | Link request (MLR) | 0x6d20 | parent_address(20), message(196) | 43 | | Link accept (MLA) | 0x6d21 | request_tx_hash(32), message(149) | 44 | | Link revoke (MCR) | 0x6d22 | accept_tx_hash(32), message(184) | 45 | 46 | * `id_tx_hash` is the canonical main identifier for the identity 47 | * The tx_hash of the first MLR of the identity 48 | * For first link accept, use request tx hash 49 | * For subsequent links, use original `id_tx_hash` 50 | 51 | #### Identities 52 | 53 | All addresses in a hierarchy are part of a single identity with its own reputation. 54 | It is possible to merge multiple identities by making the parent of one a child of the other. 55 | 56 | Once a child is revoked all of its children are revoked as well, the entire branch is cut off. 57 | If addresses in that branch are still used they will be part of a new identity. 58 | 59 | The hierarchy is still maintained within the cut-off branch. 60 | Activity in the branch will be grouped with the new identity, unlinked to any previous identities. 61 | The branch can be re-attached to the original identity, to a new identity, or kept as its own. 62 | 63 | 64 | ## Example Flows 65 | 66 | #### Service Signup 67 | 68 | 1. You have an existing identity using a service provider like memo (Key A) 69 | ``` 70 | A 71 | ``` 72 | 73 | 2. You signup for a new service and choose to use Memo auth 74 | 3. The site creates a new key (Key B) and issues an MLR transaction 75 | ``` 76 | A B 77 | ``` 78 | 79 | 4. You are redirected to Memo to accept the MLR (using an MLA) 80 | 5. The child acceptance transaction is sent and redirected back to new service 81 | ``` 82 | A 83 | / 84 | B 85 | ``` 86 | 87 | 6. Accounts are now linked, also no login required for new service 88 | 89 | Fine to use Key B with site for awhile before linking to main Key A identity if desired. 90 | 91 | 92 | 93 | ### Key Rotation 94 | 95 | Assume existing hierarchy of Keys A, B, and C: 96 | 97 | ``` 98 | A 99 | / 100 | B 101 | / 102 | C 103 | ``` 104 | 105 | To replace Key B, create and link Keys D and E and 106 | start using instead of Keys B and C. 107 | 108 | ``` 109 | A 110 | / \ 111 | B D 112 | / / 113 | C E 114 | ``` 115 | 116 | Once all uses of Key B have been updated to use Key D (and C to E), 117 | revoke Key B. 118 | 119 | ``` 120 | A 121 | / 122 | D 123 | / 124 | E 125 | ``` 126 | 127 | ### Master Key Replacement 128 | 129 | In the case where you want to replace the master key it's a similar process. 130 | Assume existing hierarchy of Keys A, B, and C: 131 | 132 | ``` 133 | A 134 | / 135 | B 136 | / 137 | C 138 | ``` 139 | 140 | To replace Key A, create and link Keys D, E, and F and 141 | start using instead of Keys A, B, and C. 142 | 143 | ``` 144 | D 145 | / \ 146 | A E 147 | / / 148 | B F 149 | / 150 | C 151 | ``` 152 | 153 | Once all uses of Key A have been updated to use Key D (and B to E, and C to F), 154 | revoke Key A. 155 | 156 | ``` 157 | D 158 | / 159 | E 160 | / 161 | F 162 | ``` 163 | 164 | Even though no longer a valid key, the main identifier for the identity will remain the same. 165 | 166 | ### Compromised Child Key 167 | 168 | If a child key is compromised, can revoke it to start ignoring actions. 169 | Actions would still exist with the child key, but they will be disassociated with your identity. 170 | 171 | 172 | ## Reference Implementation 173 | 174 | Planned 175 | 176 | ## See Also 177 | -------------------------------------------------------------------------------- /mip-0004/mip-0004.md: -------------------------------------------------------------------------------- 1 | ``` 2 | MIP: 4 3 | Title: Private messages 4 | Author: Jason Chavannes 5 | Status: Draft 6 | Created: 2018-09-14 7 | ``` 8 | 9 | ## Abstract 10 | 11 | Create private messages with two or more memo users. 12 | Also obscure communicating parties. 13 | 14 | ## Motivation 15 | 16 | Sending private messages is a basic feature of a social network. 17 | Using Bitcoin Cash, direct and group messages can be sent in an uncensorable, anonymous, 18 | and asynchronous way. 19 | 20 | Best-in-class encrypted messaging apps like Signal still rely on a central server to 21 | relay and store the encrypted messages. 22 | This creates a centralized place for people to be censored, for instance Signal has been 23 | blocked in many places including China and Iran. 24 | 25 | #### Security Concerns 26 | 27 | Even though internet traffic can be recorded and played back later (which the NSA has done), 28 | data on the blockchain has a much higher likelihood of being accessible in the future. 29 | 30 | Quantum computers may one day be able to easily decrypt data encrypted today, 31 | users should be aware of these limitations. 32 | 33 | ## Specification 34 | 35 | #### Two new protocol actions 36 | 37 | | Action | Prefix | Values | 38 | |---|---|---| 39 | | Private message handshake | 0x6d30 | address(35), encrypted_handshake_message(179) | 40 | | Private message | No prefix | personal_key_hash(30), encrypted_private_message(184) | 41 | 42 | ECIES is used for handshake encryption key. 43 | A randomly generated key is used for regular messages. 44 | 45 | The personal key hash is a hash of the encryption key, the user public key, and a counter. 46 | Counter can be increased with each message or periodically so each message looks like a new room. 47 | Recipients can easily check which messages are for group since the hash is deterministic. 48 | 49 | No prefix is used for private messages. 50 | There is a separate prefix encrypted in the message for different actions. 51 | 52 | #### Format of encrypted private message 53 | 54 | | Name | Code (First byte) | Fields | 55 | |---|---|---| 56 | | New key | 1 | encryption_key(50) | 57 | | Other members | 2 | address(35) x 6 | 58 | | Message | 3 | message(219) | 59 | 60 | #### Example Flow 61 | 62 | 1. Initiator sends handshake to recipient main address 63 | - Handshake includes symmetric encryption key (see spec) 64 | - Can also post an initial message using the encryption key 65 | 2. Recipient responds when they post a message using the encryption key 66 | - Can include multiple recipients, people can be added to the conversation at any time 67 | 3. Any participant can publicly or privately invite others 68 | - Once handshake with coordinator, can read chat history to find messages 69 | that include other members 70 | 71 | #### Bloom Filter Support 72 | 73 | Participants only need to bloom filter on their pk_hash to detect handshakes. 74 | Once handshake detected, can add bloom filter for personal_key_hashes of other users. 75 | 76 | ## Reference Implementation 77 | 78 | Planned 79 | 80 | ## See Also 81 | -------------------------------------------------------------------------------- /mip-0005/mip-0005.md: -------------------------------------------------------------------------------- 1 | ``` 2 | MIP: 5 3 | Title: Documents 4 | Author: Jason Chavannes 5 | Status: Draft 6 | Created: 2018-09-29 7 | ``` 8 | 9 | ## Abstract 10 | 11 | Collaboratively add and edit documents stored on the blockchain. 12 | Use URI pointers to link documents together. 13 | 14 | ## Motivation 15 | 16 | Hyperlinking is the one of the core functionalities of the web. 17 | One of the drawbacks is to run a website you must host it 24/7 at a publicly available 18 | and discoverable location. 19 | Because of this many people rely on services to host their content for them. 20 | Using the blockchain, a one-time payment can get your document hosted indefinitely. 21 | This not only creates an uncensorable internet, it makes it practical to control 22 | your own content. 23 | 24 | ## Specification 25 | 26 | Add new protocol actions: 27 | 28 | | Action | Prefix | Values | 29 | |---|---|---| 30 | | Create page | 0x6d40 | location(181), title(181-len(location)), content_tx_hash(30) | 31 | | Update page | 0x6d41 | last_page_tx_hash(30), update_code(2), <...> | 32 | | Update content | 0x6d42 | (last_content_txt_hash(30)), content_diff(217/187) | 33 | 34 | Update codes: 35 | 36 | ||||| 37 | |---|---|---|---| 38 | | Set page location | 0x01 | location(181) | 39 | | Rename page | 0x02 | title(181) | 40 | | Remove page | 0x03 | | 41 | | Set content | 0x04 | tx_hash(30) | 42 | | Set image | 0x05 | image_uri(181) | 43 | 44 | 45 | Format of content diff: 46 | 47 | |||||| 48 | |---|---|---|---|---| 49 | | Add data | 0x01 | char_start | content | | 50 | | Remove data | 0x02 | char_start | char_end | | 51 | | Update data | 0x03 | char_start | char_end | content | 52 | 53 | #### Example 54 | 55 | - `01` `Hello world` 56 | - Hello world 57 | - `02` `5` 58 | - Hello 59 | - `03` `2` `y` 60 | - Hey 61 | 62 | ## Reference Implementation 63 | 64 | Planned 65 | 66 | ## See Also 67 | -------------------------------------------------------------------------------- /mip-0006/mip-0006.md: -------------------------------------------------------------------------------- 1 | ``` 2 | MIP: 6 3 | Title: Commerce 4 | Author: Jason Chavannes 5 | Status: Draft 6 | Created: 2018-11-17 7 | ``` 8 | 9 | ## Abstract 10 | 11 | List items for sale that others can buy. 12 | Include information about the products and required information for purchase. 13 | Allow buyers to purchase items. 14 | 15 | ## Motivation 16 | 17 | Being able to buy and sell items is one of the most popular uses of the internet. 18 | Sites like eBay and Craigslist enable easy direct sales between individuals. 19 | Those sites are closed off though, 20 | for instance Craigslist does not allow housing listings to be shown on other sites. 21 | Using Memo to post items for sale will enable a global decentralized peer-to-peer marketplace. 22 | 23 | ## Specification 24 | 25 | Seller protocol actions: 26 | 27 | | Action | Prefix | Values | 28 | |---|---|---| 29 | | List item | 0x6d50 | title(), description(), price() | 30 | | Add item image | 0x6d51 | item_tx_hash(30), url() | 31 | | Remove item image | 0x6d52 | item_image_tx_hash(30) | 32 | | Set purchase fields | 0x6d53 | field(), field(), ... | 33 | | Remove purchase fields | 0x6d54 | field(), field(), ... | 34 | | Set item title | 0x6d55 | item_tx_hash(30), title() | 35 | | Set item description | 0x6d56 | item_tx_hash(30), description() | 36 | | Set item price | 0x6d57 | item_tx_hash(30), price() | 37 | | Adjust inventory count | 0x6d58 | item_tx_hash(30), count_diff() | 38 | | Ack order | 0x6d59 | purchase_tx_hash(30), message() | 39 | | Void order | 0x6d5a | purchase_tx_hash(30), reason() | 40 | | Set escrow address | 0x6d5b | purchase_tx_hash(30), address(35) | 41 | | Update order status | 0x6d5c | purchase_tx_hash(30), status() | 42 | 43 | Buyer protocol actions: 44 | 45 | | Action | Prefix | Values | 46 | |---|---|---| 47 | | Purchase item | 0x6d60 | item_tx_hash(30), quantity(), details*() | 48 | | Add / update details | 0x6d61 | purchase_tx_hash(30), details*() | 49 | | Request refund | 0x6d62 | purchase_tx_hash(30), reason*() | 50 | | Mark item received | 0x6d63 | purchase_tx_hash(30), comment*() | 51 | | Review purchase | 0x6d64 | purchase_tx_hash(30), rating(), comment*() | 52 | | Rate item | 0x6d65 | item_tx_hash(30), rating(), comment*() | 53 | 54 | \* Details are encrypted with seller pub key and in JSON format. 55 | Comments can optionally be encrypted. 56 | 57 | #### Example 58 | 59 | - Seller: 60 | 61 | `0x6d50 "Sticker" "Cool bitcoin cash sticker" 250000` 62 | 63 | `0x6d51 "https://imgur.com/..."` 64 | 65 | `0x6d53 "Name" "Address"` 66 | 67 | `0x6d58 +5` 68 | 69 | - Buyer: 70 | 71 | `0x6d60 1 "{name: 'John Smith, address: '1600 Pennsylvania Ave NW, Washington, DC 20500'}"` 72 | 73 | - Payment directly to buyer or to escrow holder (maybe 2-3 multi-sig) 74 | - Details encrypted with seller key 75 | 76 | - Seller: 77 | 78 | - ACKs order 79 | 80 | `0x6d59 "Thank you for your order"` 81 | 82 | - Mails item 83 | 84 | - Buyer: 85 | 86 | - Receives item, marks it received 87 | 88 | `0x6d63 ` 89 | 90 | - Escrow releases to seller* 91 | 92 | \* Needs to handle disputes (from either buyer or seller) 93 | 94 | ## Reference Implementation 95 | 96 | Planned 97 | 98 | ## See Also 99 | -------------------------------------------------------------------------------- /mip-0007/mip-0007.md: -------------------------------------------------------------------------------- 1 | ``` 2 | MIP: 7 3 | Title: Gigs 4 | Author: Jason Chavannes 5 | Status: Draft 6 | Created: 2018-12-07 7 | ``` 8 | 9 | ## Abstract 10 | 11 | Post real-time gigs like taxi and food delivery. 12 | Allow purchasers to search and connect with workers. 13 | 14 | ## Motivation 15 | 16 | Apps connecting people for "gigs" have become very popular. 17 | Uber paved the way, turning everyone into on-demand taxis. 18 | Other services like food delivery, handy-man, and more have also taken off. 19 | These are closed systems and users are at the whim of the centralized networks that control them. 20 | Using Memo to post gigs will enable a global decentralized peer-to-peer gig economy. 21 | 22 | ## Specification (WIP) 23 | 24 | #### Seller protocol actions 25 | 26 | | Action | Prefix | Values | 27 | |---|---|---| 28 | | Set service info | 0x6d70 | type(), info() | 29 | | Set available | 0x6d71 | date(), message() | 30 | | Set unavailable | 0x6d72 | tx_hash(30), message() | 31 | | Accept reservation | 0x6d73 | tx_hash(30), message() | 32 | | Cancel reservation | 0x6d74 | tx_hash(30), message() | 33 | | Set options | 0x6d75 | tx_hash(30), price(), type*(), info() | 34 | | Set ready | 0x6d76 | tx_hash(30), message() | 35 | | Set finished | 0x6d77 | tx_hash(30), message() | 36 | | Set location | 0x6d78 | location(), message() | 37 | | Rate customer | 0x6d79 | tx_hash/address(30/35), rating(2), message() | 38 | 39 | #### Buyer protocol actions 40 | 41 | | Action | Prefix | Values | 42 | |---|---|---| 43 | | Set info | 0x6d80 | type(), info() | 44 | | Set location | 0x6d81 | location(), message() | 45 | | Set desired date | 0x6d82 | date(), location*(), message() | 46 | | Request reservation | 0x6d83 | tx_hash(30), message() | 47 | | Cancel reservation | 0x6d84 | tx_hash(30), message() | 48 | | Rate service | 0x6d85 | tx_hash/address(30/35), rating(2), message() | 49 | 50 | #### Example 51 | 52 | ... 53 | 54 | ## Reference Implementation 55 | 56 | Planned 57 | 58 | ## See Also 59 | -------------------------------------------------------------------------------- /mip-0009/mip-0009.md: -------------------------------------------------------------------------------- 1 | ``` 2 | MIP: 9 3 | Title: Token exchange 4 | Author: Jason Chavannes 5 | Status: Final (v2) 6 | Created: 2019-06-05 7 | V2: 2019-06-21 8 | ``` 9 | 10 | ## Abstract 11 | 12 | List tokens for sale. 13 | Make purchase offers. 14 | Accept purchase offers and transfer using an atomic transaction. 15 | 16 | ## Motivation 17 | 18 | Decentralized way to exchange tokens. 19 | 20 | ## Specification 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 39 | 40 | 41 | 42 | 43 | 52 | 53 | 54 | 55 | 56 | 66 | 67 |
PrefixActionValues
0x6d30
List sale 32 | 
 33 | OP_RETURN
 34 | <prefix: 0x6d30> (2 bytes)
 35 | <input/output_1>
 36 | ...
 37 | <input/output_n>
38 | 
0x6d31
Make offer 44 | 
 45 | OP_RETURN
 46 | <prefix: 0x6d31> (2 bytes)
 47 | <list_sale_hash> (30 bytes)
 48 | <input/output_1>
 49 | ...
 50 | <input/output_n>
51 | 
0x6d32
Attach signature 57 | 
 58 | OP_RETURN
 59 | <prefix: 0x6d32> (2 bytes)
 60 | <sale/offer_hash> (30 bytes)
 61 | <signature_1> (72 bytes)
 62 | <pk_data_1> (34 bytes)
 63 | <signature_n> (72 bytes)
 64 | <pk_data_n> (34 bytes)
65 |
68 | 69 | #### Input / output types 70 | 71 | 72 | 73 | 74 | 75 | 76 | 77 | 78 | 79 | 80 | 86 | 87 | 88 | 89 | 90 | 95 | 96 | 97 | 98 | 99 | 104 | 105 | 106 | 107 | 108 | 114 | 115 | 116 | 117 | 118 | 124 | 125 | 126 | 127 | 128 | 134 | 135 | 136 | 137 | 138 | 144 | 145 |
TypeIn/Out TypeValues
1Input 81 | 
 82 | <type: 1> (1 byte)
 83 | <tx_hash> (30 bytes)
 84 | <index> (2 bytes)
85 |
2Token Output - Self 91 | 
 92 | <type: 2> (1 byte)
 93 | <quantity> (8 bytes, integer)
94 |
3Bitcoin Output - Self 100 | 
101 | <type: 3> (1 byte)
102 | <quantity> (8 bytes, integer)
103 |
4Token Output - P2PKH 109 | 
110 | <type: 4> (1 byte)
111 | <address> (35 bytes)
112 | <quantity> (8 bytes, integer)
113 |
5Bitcoin Output - P2PKH 119 | 
120 | <type: 5> (1 byte)
121 | <address> (35 bytes)
122 | <quantity> (8 bytes, integer)
123 |
6Token Output - P2SH 129 | 
130 | <type: 6> (1 byte)
131 | <address> (35 bytes)
132 | <quantity> (8 bytes, integer)
133 |
7Bitcoin Output - P2SH 139 | 
140 | <type: 7> (1 byte)
141 | <address> (35 bytes)
142 | <quantity> (8 bytes, integer)
143 |
146 | 147 | ### Generated 2-part transaction 148 | 149 | Using the list sale and make offer a deterministic transaction can be generated. 150 | 151 | 152 | 153 | 154 | 158 | 159 | 160 | 161 | 166 | 167 |
Inputs 155 | 1. List sale inputs
156 | 2. Make offer inputs
157 |
Outputs 162 | 1. OP_RETURN
163 | 2. List sale outputs
164 | 3. Make offer outputs
165 |
168 | 169 | ### Instant transaction 170 | 171 | When making a typical offer there is 1 input and 1 output. 172 | The input is the tokens for sale and the output is the purchase price. 173 | 174 | 175 | 176 | 177 | 178 | 179 | 180 | 181 | 184 | 187 | 188 |
InputOutput
182 | UTXO of tokens for sale 183 | 185 | X satoshis to seller 186 |
189 | 190 | Using a `SIGHASH_SINGLE | SIGHASH_ANYONECANPAY` signature, just this input/output pair can be signed. 191 | The purchaser can then create their own sale tx of their choosing, as long as it includes this pair. 192 | 193 | The removes the middle step from the 2-part transaction. 194 | The purchaser can sign and purchase token instantly. 195 | 196 | The final transaction would look like this: 197 | 198 | 199 | 200 | 201 | 202 | 203 | 204 | 205 | 208 | 211 | 214 | 215 | 216 | 219 | 222 | 225 | 226 | 227 | 230 | 233 | 236 | 237 |
IndexInputOutput
206 | 0 207 | 209 | UTXO of buyer payment 210 | 212 | OP_RETURN for SLP SEND 213 |
217 | 1 218 | 220 | UTXO of tokens for sale 221 | 223 | Payment to seller 224 |
228 | 2 229 | 231 | - 232 | 234 | Tokens to buyer 235 |
238 | 239 | The buyer signs input `0` using normal `SIGHASH_ALL` . 240 | The seller `SIGHASH_SINGLE | SIGHASH_ANYONECANPAY` signature is used for input `1`. 241 | 242 | When generating the transaction and input/output pair use: 243 | 244 | - P2PKH output 245 | - TX version 1 246 | - Input sequence `0xffffffff` 247 | - Seller pair must have same input/output index. Use index 1 since SLP requires OP_RETURN as output index 0. 248 | 249 | ## Alternative offer to purchase mechanism 250 | 251 | Instead of a seller posting the 0x6d30 list sale tx, 252 | a potentially buyer could post referring to specific UTXO with an offer price. 253 | 254 | For a seller to accept the offer they can just post the 0x6d32 signature. 255 | 256 | Payments will be made to the address used as the first input in the signature transaction. 257 | For regular purchases this same payment address should be used from the signature transaction. 258 | 259 | ## Accepting an offer 260 | 261 | Accept the offer by signing and broadcasting the transaction 262 | 263 | ## Declining an offer 264 | 265 | Decline an offer or remove a listing by: 266 | - Never accepting the offer 267 | - Accepting another offer 268 | - Moving the token(s) 269 | - Replacing with a newer listing 270 | 271 | ## Reference Implementation 272 | 273 | – 274 | 275 | ## See Also 276 | 277 | – 278 | --------------------------------------------------------------------------------