-
Notifications
You must be signed in to change notification settings - Fork 3
More details about the protocol
- A negotiation is composed of several rounds
- Every round, Seller and Buyer exchange a price and an argument
- Seller and Buyer try to reach an agreement by sending better offers:
- amount_buyer(t+1) >= amount_buyer(t)
- amount_seller(t+1) <= amount_seller(t)
- An agreement is reached when amount_buyer(t) >= amount_seller(t)
- Buyer or Seller can abort the negotiation at any time
-
Every round, Seller sends a message embedding a list of outputs defining the expected price and how to pay (output scripts)
-
Every round, Buyer sends a message embedding one or several transactions.
Only three things are required for these transactions:
- they embed all the outputs previously sent by Seller
- their inputs are unspent outputs (utxos) owned by Buyer (checked by requesting the blockchain)
- Buyer proves that she owns the inputs by signing the transactions During negotiation phase, transactions are invalid according to bitcoin rules (sum(txins) < sum(txouts)). It ensures that these transactions will be rejected by the network if broadcast.
Completion phase is entered as soon as Buyer sends a message embedding redeemable transactions (agreement has been reached).
Buyer can insert some additional outputs for change. This allows to bargain with utxos bigger than the desired pledge.
-
Each message embeds a memo field allowing Buyer or Seller to send arguments for the negotiation
-
Each message is signed so that all messages form a chain of signatures
signature = sign( hash( pbuff(prev_msg) + '|' + pbuff(curr_msg) ) )
It ensures that the terms of the negotiation can't be forged.
The type of signature and the keys/certificates used by buyer and seller must remain the same all along the negotiation.
-
Supports X509 and ECDSA (Secp256k1 curve) signatures.
Buyer and Seller are not required to use the same type of signature (e.g. seller use X509 certificates, buyer uses an ephemeral ECDSA key)
-
During initialization phase, Buyer and Seller notify each other the url used to receive messages and the expiry date after which they'll abort the negotiation.
Bargaining allows a large range of scenarios like a seller who doesn't lower her financial offer but adds complementary services or products.
Moreover, while fixed price model is a pure financial interaction, bargaining adds a social dimension. During a negotiation the seller can prove her commercial skills and the buyer can prove her knowledge of the domain associated to the product. A successful negotiation should result in a financial agreement and the sentiment that it was a good deal for both actors.
As Seller and Buyer are not allowed to change the type of signature or the key/certificates used during the negotiation, they can be confident that received messages have been sent by the same person as long as the signature is valid (and that keys or certificates have not been compromised)
Moreover, the chain of signature ensures that the terms of the negotiation can't be forged after agreement. This is especially useful for consumers protection in order to avoid false promises by the seller. Note that signatures only protect signed contents. Content of external web pages shared via an hyperlink embedded in memo field shouldn't be considered as contractual content.
The point is that during the negotiation phase, transactions shouldn't be seen as payment transactions but should be interpreted as the terms of a "contract" stating: "I, the buyer, acknowledge that the seller has proposed a price of X btc which should be paid according to following conditions (). I certify that I can do a payment on the bitcoin network, that I agree to pay Y BTC, that I own this amount and that it can be checked in the blockchain thanks to the following information: [...]"
Incidently, at the completion phase, this "contract" is also a valid transaction (Y >= X) which can be broadcast to the network.
As you can see, there's much more in this "contract" that a single amount.
It's all about sellers protection. It aims to avoid that a seller engages in a long negotiation with a buyer who has no intent to complete the deal (does not own the coins).
It's also helps to protect the seller from concurrents trying to gain financial informations (like margins) in an automated way. For better protection, the seller could use additional heuristics like the detection of utxos appearing in a large number of simultaneous negotiations.
If the protocol requires that I add new utxos at every round, the final transaction will have a lot of inputs and will require high fees
The protocol doesn't require that an utxo used at round N is kept at round N+1. The buyer is just required to make a better offer.
It means that you can use a lot of small utxos during the negotiation phase but a reduced number of (bigger) utxos for the redeemable transaction. Since all messages are exchanged off-blockchain during the negotiation phase, no fees are implied.
The buyer can insert additional outputs to transactions. That allows to manage change.
In term of negotiation strategy, using a "big" utxo is of course very different from using "small" utxos. Small utxos hide your financial depth. Big utxos partially reveal this depth but it can be a part of the strategy used to negotiate.
In its current state, the protocol could be integrated by online merchants and online wallets with the expected level of privacy and features (synchronous/asynchronous negotiations).
For local wallets which are not always connected, the protocol needs some more work in order to support asynchronous negotiations. With respect to the http protocol, a possible solution could rely on an additional message and third-party services (mailboxes). Another solution would be a fully decentralized architecture relying on a P2P protocol and a DHT.