Number: HIP-XXXX
Title: Secondhand market
Type: Informational
Status: Draft
Authors: Fernando Falci <https://iamfernando/>
Created: 2021-01-18
This proposal describes how to (1) make an offer to any available name, (2) how to accept an offer and (3) advertise a name for sale, using only data on chain.
An offer has two actors (Buyer and Owner) and a locking script;
Let's suppose Alice wants to offer 1000 HNS for a name that belongs to Bob.
Alice should craft a transaction sending the money to a locking script. This locking script requires a preimage that is only known by Alice. This script can only be spent by Bob as long as he provides the preimage (which he doesn't know yet).
To prevent the money from getting stuck in the script forever, the offer must have an expiration date, allowing Alice to withdraw the money later.
Bob can receive any number of offers (for any domain). At any time, he can decide to accept one of those offers.
If Bob wants to accepts Alice's offer from above, he must to force Alice to reveal the preimage that is required for spending the offer.
Bob then creates a new locking script, simillar to the previous, allowing Alice to control the name as long as she provides the same preimage.
Bob should TRANSFER and FINALIZE the name.
As soon as the name is transferred to the new script, Alice can control it, transfer one more time, to a regular address from Alice's wallet. To do so, Alice will be forced to reveal the preimage. In this moment, Bob can use the same preimage and spend the money from the first script.
For the same reason, the second script should also have a timelocker, allowing Bob to control the name after some time (otherwise the name could be locked forever if Alice didn't reveal the preimage). It's important to note that the timelocker from the second script must to be shorter than the first script. Otherwise, we may end up in a situation where Alice can withdraw the offer and Bob can't control the name.
There are no technical requirement that prevents anyone making offers (of any value) for any name. However, it's possible that the name owner don't know about this proposal and don't even know about any offers. Not a problem, because who is making the offer can withdraw the money after some time, it would be just a waste of time.
If an owner is aware of this protocol and want to advertise a name he/she can send a transfer to a unique address, hard-coded in this protocol. This address should be the broker, receiving all the names advertised. Any wallet or web site interested in listing available names should monitor this address.
Both scripts are based on the Hashed Time-Locked Contract, defined in the BIP-199
OP_IF
OP_SHA256 <SHA256(Buyer's preimage)> OP_EQUALVERIFY
OP_DUP OP_HASH160 <seller pubkey hash>
OP_ELSE
<"30d"> OP_CHECKSEQUENCEVERIFY OP_DROP
OP_DUP OP_HASH160 <buyer pubkey hash>
OP_ENDIF
OP_EQUALVERIFY
OP_CHECKSIG
<sig> <seller's key> <preimage> <1>
Note: after the offer is accepted, the (former) "owner" becomes "seller".
<sig> <buyer's key> <0>
OP_IF
OP_SHA256 <SHA256(Buyer's preimage)> OP_EQUALVERIFY
OP_DUP OP_HASH160 <buyer pubkey hash>
OP_ELSE
<"30d"> OP_CHECKSEQUENCEVERIFY OP_DROP
OP_DUP OP_HASH160 <seller pubkey hash>
OP_ENDIF
OP_EQUALVERIFY
OP_CHECKSIG
<sig> <buyer's key> <preimage> <1>
<sig> <owner's key> <0>
When a script is created and add to transation, the network is not aware of the content of the script, just its hash. Who wants to spend from the script must to recreate the script, providing its source) and broadcast in the next TX. The network will only accept if this source hashes to the same known hash.
The name owner needs to know details about the script in order to be able to spend from it. Also, the owner needs to know the preimage's hash in advance, because this is the requirement for creating the "accept-offer" locking script.
This protocol doesn't define how this data should be published.