<p>It is possible to create a small transaction output as an anchor for each auction: Interested parties would then be able to place their bids by signing a transaction that uses both their bid and the anchor as inputs. </p>

<p>When the time-frame of the auction ends, the auctioneer can countersign the transaction with the highest bid, and since the anchor can only be spent once, all other bids are automatically invalidated.</p>

<p>The transactions would have to be posted through the auction's portal, as they wouldn't be relayed by the network without being signed completely. After they were posted though, everybody could verify that they are valid and the bidder actually has the funds.</p>

<p>One problem is though, that bidders could retract their bid, by doublespending the output used for the bid. This wouldn't be so much a problem if only people bid that actually want to win the auction, but would be a very easy way for the seller to push the price up.
In the end, the auctioneer could just sign the next highest bid then though.</p>

<p>The retracting of bids could be monitored by the auction platform, requiring registration.</p>

CC BY-SA 3.0
2014-09-22T00:00:16.187Z
Hm, very interesting. But that last problem is critical. The scheme I've come up also allows payments that depend on the bids of other bidders, but has the same problem that people can basically retract bids. My scheme was recording encrypted bids in the blockchain, and after the bidding window is closed, bidders would release the key they used to encrypt their bid. At that point the winner would be chosen and expected to pay. But it still wouldn't be able to force someone to pay..
B T
CC BY-SA 3.0
2014-09-22T00:01:15.683Z
If you had a 3rd party like the auctioneer, they could keep bids and then return the remaining value.. but that adds a centralized facet to something I was hoping could be distributed.
B T
CC BY-SA 3.0
2014-09-22T00:27:19.727Z
The "tracking" feature would need some extra infrastructure.  The submitted bids would not be valid transactions without the countersignature, so they wouldn't be relayed on the peer-to-peer network.  However, if they were posted on the auction house's website or something, other people could verify that they were otherwise valid (and in particular, that the bidders actually had the funds they were bidding with).  Incidentally, in some ways this is like using a colored coin as a token for the property being auctioned.
Nate Eldredge
CC BY-SA 3.0
2014-09-22T02:52:53.707Z
@BT If the bid is encrypted before going in the blockchain, how do you know it's valid? Also, how do you know that bidders will release the key for their bid?
Nick ODell
CC BY-SA 3.0
2014-09-22T05:05:54.030Z
@NickODell its only valid if its in the blockchain before a particular date (defined by the bidding window) and if the bidder releases their key. So if they don't release their key, it isn't counted as a bid. And if they do and it successfully decrypts their encrypted bid, wala its valid.
B T
CC BY-SA 3.0
2014-09-21T23:49:39.263Z
2014-09-22T07:31:25.143Z
2014-09-22T07:31:25.143Z
Murch
<p>The following protocol is based on <a href="https://en.bitcoin.it/wiki/Contracts#Example_1:_Providing_a_deposit" rel="nofollow">Providing a deposit</a> example contract and <a href="/a/30608">the previous answer</a>.</p>

<p>When placing a bid, the bidder and the auctioneer do the following:</p>

<ol>
<li>Both generate new public keys.</li>
<li>The bidder generates a transaction (<em>deposit</em>) which sends his bid to a multisignature script requiring signatures from both newly generated keys to spend. Then he sends its ID to the auctioneer.</li>
<li><p>The auctioneer generates a transaction (<em>return</em>) which spends <em>deposit</em> and sends the money back to the bidder. He sets its lock time (nLockTime) to some time after the auction ends. He also generates a transaction (<em>payment</em>) that spends <em>deposit</em> and sends the money to himself.</p>

<p>The auctioneer signs <em>return</em>, but not <em>payment</em>. Both transactions are not valid without the bidder's signature. He sends both transactions to the bidder.</p></li>
<li>The bidder checks that the transactions are as expected, and that the auctioneer's signature on <em>return</em> is valid. He broadcasts <em>deposit</em>. He also signs <em>payment</em> and sends it to the auctioneer.</li>
<li>The auctioneer checks the bidder's signature on <em>payment</em>. As soon as <em>deposit</em> is confirmed, the bidder's money is locked and can't be spent by the bidder until the auction is complete.</li>
<li>After the auction, the auctioneer signs and broadcasts <em>payment</em> transaction corresponding to the winning bid. Other bidders can have their bids returned by broadcasting <em>return</em> transaction when it becomes valid, or they can cooperate with the auctioneer to have their bids returned immediately.</li>
</ol>

<p>Now, there is a little problem: the auctioneer can claim multiple bids. To solve this, have the auctioneer provide a small anchor output and make all <em>payment</em> transaction spend this output. Now at most one of the <em>payment</em> transactions can be accepted by the network. Of course, bidders need to check that <em>payment</em> spends that output before signing it, as well as to make sure that the same anchor is used for all bidders.</p>

CC BY-SA 3.0
2014-09-30T07:22:23.467Z
This is exactly the kind of detailed answer I was looking for! Very clever. Can you explain the anchor output in a little more detail? How can every payment spend the anchor output (when I would think every payment is from a different address)? I think it would be most clear if that part was included in the steps, instead of being an after-note.
B T
CC BY-SA 3.0
2014-09-30T07:23:21.857Z
Also, I think you should mention nLockTime, which it seems is critical to this protocol.
B T
CC BY-SA 3.0
2014-09-30T07:54:09.440Z
@BT I have already mentioned lock time. A transaction can spend from any (unspent) outputs, as long as appropriate signatures (or whatever else is required by output scripts) are provided. It doesn't matter whether these outputs are to the same address or not (or even to some custom script). I think the protocol is complicated enough without the anchor output, so it makes sense for the reader to comprehend the simplified version before the complete one.
abacabadabacaba
CC BY-SA 3.0
2014-09-30T19:33:25.857Z
Ah I think I see. So you're saying a bidder can create a transaction with two inputs: the bid coming from an address the bidder owns, and the anchor coming from an address the auctioneer owns. For that transaction to succeed, both bidder and auctioneer have to sign it. And as long as the transaction hasn't been given to the network, the same anchor can be used for all the bids, ensuring that only one will successfully be spent. Is that right?
B T
CC BY-SA 3.0
2014-10-01T04:24:35.373Z
@BT The *payment* transaction would have two inputs: one spending *deposit*, which requires signatures both from the bidder and from the auctioneer, and one spending the anchor output, which requires a signature from the auctioneer only. So, two inputs and three signatures in total. The auctioneer would sign only one of the transactions, and the network won't accept more than one because they spend the same output.
abacabadabacaba
CC BY-SA 3.0
2014-09-29T05:45:00.247Z
2014-09-30T23:18:59.137Z
2014-09-30T23:18:59.137Z
abacabadabacaba
<p>I'm thinking of the situation where you have an auction where bids are placed. There are two conditions that should be held:</p>

<ol>
<li>Placing a bid shouldn't expose you to paying the seller unless you win the auction</li>
<li>Placing a bid should require that you pay the selling in the case you win the auction</li>
</ol>

<p>Is it possible to satisfy these two conditions using bitcoins?</p>

<protocol>
Is it possible to force a person to honor a conditional promise-to-pay?
B T
# Is it possible to force a person to honor a conditional promise-to-pay?

(Asked by: username_0 on 2014-09-21)

I'm thinking of the situation where you have an auction where bids are placed. There are two conditions that should be held:

1. Placing a bid shouldn't expose you to paying the seller unless you win the auction
2. Placing a bid should require that you pay the selling in the case you win the auction

Is it possible to satisfy these two conditions using bitcoins?

**Tags:** protocol


---

## 2 answers

### Answer by username_4 on 2014-09-29. Score: 3 | Accepted answer

The following protocol is based on [Providing a deposit](https://en.bitcoin.it/wiki/Contracts#Example_1:_Providing_a_deposit) example contract and [the previous answer](/a/30608).

When placing a bid, the bidder and the auctioneer do the following:

1. Both generate new public keys.
2. The bidder generates a transaction (*deposit*) which sends his bid to a multisignature script requiring signatures from both newly generated keys to spend. Then he sends its ID to the auctioneer.
3. The auctioneer generates a transaction (*return*) which spends *deposit* and sends the money back to the bidder. He sets its lock time (nLockTime) to some time after the auction ends. He also generates a transaction (*payment*) that spends *deposit* and sends the money to himself.

   The auctioneer signs *return*, but not *payment*. Both transactions are not valid without the bidder's signature. He sends both transactions to the bidder.
4. The bidder checks that the transactions are as expected, and that the auctioneer's signature on *return* is valid. He broadcasts *deposit*. He also signs *payment* and sends it to the auctioneer.
5. The auctioneer checks the bidder's signature on *payment*. As soon as *deposit* is confirmed, the bidder's money is locked and can't be spent by the bidder until the auction is complete.
6. After the auction, the auctioneer signs and broadcasts *payment* transaction corresponding to the winning bid. Other bidders can have their bids returned by broadcasting *return* transaction when it becomes valid, or they can cooperate with the auctioneer to have their bids returned immediately.

Now, there is a little problem: the auctioneer can claim multiple bids. To solve this, have the auctioneer provide a small anchor output and make all *payment* transaction spend this output. Now at most one of the *payment* transactions can be accepted by the network. Of course, bidders need to check that *payment* spends that output before signing it, as well as to make sure that the same anchor is used for all bidders.

> **Comments:**
> **username_0**: This is exactly the kind of detailed answer I was looking for! Very clever. Can you explain the anchor output in a little more detail? How can every payment spend the anchor output (when I would think every payment is from a different address)? I think it would be most clear if that part was included in the steps, instead of being an after-note.  
> **username_0**: Also, I think you should mention nLockTime, which it seems is critical to this protocol.  
> **username_4**: @BT I have already mentioned lock time. A transaction can spend from any (unspent) outputs, as long as appropriate signatures (or whatever else is required by output scripts) are provided. It doesn't matter whether these outputs are to the same address or not (or even to some custom script). I think the protocol is complicated enough without the anchor output, so it makes sense for the reader to comprehend the simplified version before the complete one.  
> **username_0**: Ah I think I see. So you're saying a bidder can create a transaction with two inputs: the bid coming from an address the bidder owns, and the anchor coming from an address the auctioneer owns. For that transaction to succeed, both bidder and auctioneer have to sign it. And as long as the transaction hasn't been given to the network, the same anchor can be used for all the bids, ensuring that only one will successfully be spent. Is that right?  
> **username_4**: @BT The *payment* transaction would have two inputs: one spending *deposit*, which requires signatures both from the bidder and from the auctioneer, and one spending the anchor output, which requires a signature from the auctioneer only. So, two inputs and three signatures in total. The auctioneer would sign only one of the transactions, and the network won't accept more than one because they spend the same output.  

---

### Answer by username_1 on 2014-09-21. Score: 4

It is possible to create a small transaction output as an anchor for each auction: Interested parties would then be able to place their bids by signing a transaction that uses both their bid and the anchor as inputs.

When the time-frame of the auction ends, the auctioneer can countersign the transaction with the highest bid, and since the anchor can only be spent once, all other bids are automatically invalidated.

The transactions would have to be posted through the auction's portal, as they wouldn't be relayed by the network without being signed completely. After they were posted though, everybody could verify that they are valid and the bidder actually has the funds.

One problem is though, that bidders could retract their bid, by doublespending the output used for the bid. This wouldn't be so much a problem if only people bid that actually want to win the auction, but would be a very easy way for the seller to push the price up.
In the end, the auctioneer could just sign the next highest bid then though.

The retracting of bids could be monitored by the auction platform, requiring registration.

> **Comments:**
> **username_0**: Hm, very interesting. But that last problem is critical. The scheme I've come up also allows payments that depend on the bids of other bidders, but has the same problem that people can basically retract bids. My scheme was recording encrypted bids in the blockchain, and after the bidding window is closed, bidders would release the key they used to encrypt their bid. At that point the winner would be chosen and expected to pay. But it still wouldn't be able to force someone to pay..  
> **username_0**: If you had a 3rd party like the auctioneer, they could keep bids and then return the remaining value.. but that adds a centralized facet to something I was hoping could be distributed.  
> **username_2**: The "tracking" feature would need some extra infrastructure.  The submitted bids would not be valid transactions without the countersignature, so they wouldn't be relayed on the peer-to-peer network.  However, if they were posted on the auction house's website or something, other people could verify that they were otherwise valid (and in particular, that the bidders actually had the funds they were bidding with).  Incidentally, in some ways this is like using a colored coin as a token for the property being auctioned.  
> **username_3**: @BT If the bid is encrypted before going in the blockchain, how do you know it's valid? Also, how do you know that bidders will release the key for their bid?  
> **username_0**: @username_3 its only valid if its in the blockchain before a particular date (defined by the bidding window) and if the bidder releases their key. So if they don't release their key, it isn't counted as a bid. And if they do and it successfully decrypts their encrypted bid, wala its valid.  

---

