6
1
I'm thinking of the situation where you have an auction where bids are placed. There are two conditions that should be held:
Is it possible to satisfy these two conditions using bitcoins?
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:
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.
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.
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.
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 – 2014-09-22T00:00:16.187
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 – 2014-09-22T00:01:15.683
1The "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 – 2014-09-22T00:27:19.727
@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 – 2014-09-22T02:52:53.707
@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 – 2014-09-22T05:05:54.030
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 – 2014-09-30T07:22:23.467
Also, I think you should mention nLockTime, which it seems is critical to this protocol. – B T – 2014-09-30T07:23:21.857
@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 – 2014-09-30T07:54:09.440
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 – 2014-09-30T19:33:25.857
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 – 2014-10-01T04:24:35.373