Blockchain Auction Software "needs" discussion

itod

legendary

Activity: 1974

Merit: 1077

^ Will code for Bitcoins

Quote from: Tehfiend on October 15, 2013, 03:43:57 PM

If you are bidding up your own auction and don't solve the next block then your only risk is winning your own auction and you can just try again. I agree these examples are not very feasible but only including bids in solved blocks removes a lot of possible exploits along these lines IMO.

Mining pool has to decide which Merkle tree hash it distributes to the miners, with or without some transaction. They can not switch at will. If they send the hash without the wining pump-up bid, it will be easily noticed by many people since sooner or later they will solve a block and it will be shown they were broadcasting the transaction they themselves did not include in the tree.

If you are speaking about them not cheating, anyone can bid up his own auction, being mining pool or not. This could not and should not be stopped by the system, happens also in real life.

Tehfiend

hero member

Activity: 491

Merit: 514

Quote from: itod on October 15, 2013, 02:57:45 PM

Quote from: Tehfiend on October 15, 2013, 02:05:22 PM

I haven't thought too much about it but one bad example would be the operator of a large pool like BTCguild would have the advantage of hiding their bids by including their transaction in their next block without transmitting it to the entire network. Or they could "bid up" their own auctions by transmitting a very high bid but then negating it by include a different transaction in their next solved block. Other bidders would see the high bid and try to outbid it while that transaction actually gets rejected, if that makes sense. I'm sure far more clever people could think of more sinister ideas Tongue

BTCguild can do all that, but only if they solve the next block. It's very risky to broadcast fake high bid, if you don't solve the block that amount will be included in the blockchain and forever gone from BTCguild's wallet. I don't believe they would do such things for just any auction. It's questionable also if they have software solution to play with such a things, remember you would have to send fake Merkle tree hash to all your pool miners, different from the publicly broadcasted tree. Members of your mining pool may notice that. I seriously doubt they would risk such things, their reputation and pool earnings a worth to them much more.

If you are bidding up your own auction and don't solve the next block then your only risk is winning your own auction and you can just try again. I agree these examples are not very feasible but only including bids in solved blocks removes a lot of possible exploits along these lines IMO.

itod

legendary

Activity: 1974

Merit: 1077

^ Will code for Bitcoins

Quote from: Tehfiend on October 15, 2013, 02:05:22 PM

I haven't thought too much about it but one bad example would be the operator of a large pool like BTCguild would have the advantage of hiding their bids by including their transaction in their next block without transmitting it to the entire network. Or they could "bid up" their own auctions by transmitting a very high bid but then negating it by include a different transaction in their next solved block. Other bidders would see the high bid and try to outbid it while that transaction actually gets rejected, if that makes sense. I'm sure far more clever people could think of more sinister ideas Tongue

BTCguild can do all that, but only if they solve the next block. It's very risky to broadcast fake high bid, if you don't solve the block that amount will be included in the blockchain and forever gone from BTCguild's wallet. I don't believe they would do such things for just any auction. It's questionable also if they have software solution to play with such a things, remember you would have to send fake Merkle tree hash to all your pool miners, different from the publicly broadcasted tree. Members of your mining pool may notice that. I seriously doubt they would risk such things, their reputation and pool earnings a worth to them much more.

itod

legendary

Activity: 1974

Merit: 1077

^ Will code for Bitcoins

I've read your previous thread. Don't think standalone client is the right solution, server solution is much more convenient. Bidder may transfer funds to the online wallet and bid from there, or use his client wallet and pay the bid amount to the designated auction address. Bitmit.net doesn't use a blockchain, but apart from that has pretty much all the functionality needed.

Tehfiend

hero member

Activity: 491

Merit: 514

Quote from: ProfMac on October 15, 2013, 01:39:13 PM

Quote from: Tehfiend on October 15, 2013, 01:12:06 PM

Quote from: itod on October 15, 2013, 12:49:59 PM

Quote from: Tehfiend on October 15, 2013, 12:37:59 PM

Also, in many auctions there is no "end time". The auction continues until nobody is willing to beat the highest bid (aka "going once going twice SOLD!!!"). Perhaps another option would be to end the auction after X blocks have passed since the last highest bid?

This is a nice idea. For instance: Auction lasts as long there are blocks with higher bids than the previous high. This may also solve "bids to close to the wire to be included" problem. In your opinion, should the system show the bids from the current (Edit: unsolved) block or publish them after the block is found?

I would say only bids included in solved blocks to avoid shenanigans.

I do prefer shenanigan free auctions.

What sort of shenanigan can you envision if non-confirmed bids are presented in the dashboard?

I haven't thought too much about it but one bad example would be the operator of a large pool like BTCguild would have the advantage of hiding their bids by including their transaction in their next block without transmitting it to the entire network. Or they could "bid up" their own auctions by transmitting a very high bid but then negating it by include a different transaction in their next solved block. Other bidders would see the high bid and try to outbid it while that transaction actually gets rejected, if that makes sense. I'm sure far more clever people could think of more sinister ideas Tongue

ProfMac

legendary

Activity: 1246

Merit: 1002

This is a continuation from an Avalon auction thread.

This thread will start out discussing software to support blockchain auctions. The view is to develop an idea of the community's needs that the software will solve.

Probably anything related to auctions is on topic. (<--- words I already regret)

Topic: Blockchain Auction Software "needs" discussion (Read 905 times)