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

Placing a bid shouldn't expose you to paying the seller unless you win the auction
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?

user19476: The following protocol is based on Providing a deposit example contract and the previous answer.
When placing a bid, the bidder and the auctioneer do the following:

Both generate new public keys.
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.
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.
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.
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.
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.

user5406: 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.

5254: <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>
 19476: <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>
 5406: <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>
