6

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?

Improve this question

2 Answers 2

Reset to default
3

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:

  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.

Improve this answer
5
  • 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
    Commented Sep 30, 2014 at 7:22
  • Also, I think you should mention nLockTime, which it seems is critical to this protocol.
    – B T
    Commented Sep 30, 2014 at 7:23
  • @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
    Commented Sep 30, 2014 at 7:54
  • 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
    Commented Sep 30, 2014 at 19:33
  • 1
    @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
    Commented Oct 1, 2014 at 4:24
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.

Improve this answer
5
  • 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
    Commented Sep 22, 2014 at 0:00
  • 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
    Commented Sep 22, 2014 at 0:01
  • 1
    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
    Commented Sep 22, 2014 at 0:27
  • @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
    Commented Sep 22, 2014 at 2:52
  • @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
    Commented Sep 22, 2014 at 5:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.