Auction with dynamic bidding phase duration

[Falci]

Hey!

Snipping sucks, we all agree, right?

How to solve?
Maybe we could finish the bidding phase early, in a dynamic way (read: random and deterministic).

Quick recap: name is

• OPENING from block 1 (when the open was sent) to block 36;
• BIDDING from 37 to 756;
• REVEALING from 757 to 2196;
• REDEEM/REVEAL starting on 2197;

We could reduce the BIDDING period but without anticipating the REVEALING.

How-to?

Each auction would have a random duration length for the bidding phase. This random duration must be deterministic but can't be known in advance.

How much?

First, we need to agree on how much early an auction could finish. I don't think a "1-day bidding period" would be fair.
My suggestion: the bidding could end between 0 and 144 blocks early. Totally arbitrary values, to be discussed.

That means: the auction would end somewhere between the block 612 (4 days) and 756 (5 days);

How to define

The logic to define how short should it be must use some information that we can't know in advance. Otherwise anyone could calculate the new final bidding block.
How to get a deterministic random value: block hash!

I didn't solve this part completely and need some help here. I was wondering if we could somehow check the block hash and decide to close the bidding phase early. Something like

var blocksUntilReveal = $n;
var allowBids = true;
var dynamicBiddingWindow = 144;

for (let i = blocksUntilReveal; i <= dynamicBiddingWindow; i++) {
  const hash = getBlockHash(currentHeight - i);
  if ( (hash + nameHash) % i > (dynamicBiddingWindow / 2) {
    allowBids = false;
    break;
  }
}

This code is just to have an idea. But we could check each of the last 144 bidding blocks and use their hash plus the name hash to decide if that was the "close block" and reject bids after that, even if the name is still in the bidding period.

Problems

The 2 main problems I found in this implementation:

1. Right now we just need two pieces of data to determine the namestate: which height the name was OPENed and the current height. This strategy adds more requirements and more processing per auction.
2. This is a soft-fork: if miners agree on that, they could ignore bids after that dynamic close block. But that also means the would be rejecting the fee in that bid. Miners have the incentive to accept as much bid as possible (with the consensus cap)

What are you thoughts ?

[jacobjonz]

Did you really mean a loop? Or each iteration is just a block?

Won't this suffice?

if (
	(revealBlock - currentBlock < dynamicBiddingWindow )
	&&
	(
		(hash + nameHash) % dynamicBiddingWindow >= dynamicBiddingWindow - (revealBlock - currentBlock)
	)
)
	allowBids = false;

As blocks progress, chances of a hit increases.
First block has a probability of 1/dynamicBiddingWindow , 2nd has 2/, 3rd has 3/...

[Falci]

nodes will have to change to reject these bids

If a node rejects a block that ignored this extra rule but this block follows all others rules that would mean a hard-fork. (help here @pinheadmz)

Nodes can decide to not propagate the bid that breaks this rule, while in mempool.

[pinheadmz]

nodes will have to change to reject these bids

If a node rejects a block that ignored this extra rule but this block follows all others rules that would mean a hard-fork. (help here @pinheadmz)

Nodes can decide to not propagate the bid that breaks this rule, while in mempool.

The concept of a soft fork is simply this: A majority of the hashrate collaborate to censor transactions.

If a miner with 1% of the total hashrate doesn't upgrade they may successfully find a block that breaks the soft fork rule and broadcast it. Full nodes (bob wallet, exchanges, etc) that HAVE upgraded will reject the block as invalid. Full nodes that HAVE NOT upgraded (lazy!) will still think the block is valid, but thats ok because the MAJORITY of the hashrate will also reject the block as invalid and in about 20 minutes will have a longer chain, wiping out the invalid block even from non-upgraded nodes.

[pinheadmz]

The other thing to consider about this proposal is that, even though it is technically a soft-fork, really everyone in the community needs to be aware. Users who don't upgrade their Bob Wallet will still think they can bid after the soft-fork rule ends the auciton.

[pinheadmz]

Another other thing to consider here is performance: right now we determine if bids allowed in an extremely fast way:

    if (height < this.height + openPeriod + biddingPeriod)
      return states.BIDDING;

This kind of proposal suggests that every time a BID comes in, the chain validator needs to check up to 144 recent block hashes. They could be cached or whatever but we are adding a lot of new state to the consensus engine and may have to pull 144 ChainEntry's from the database, etc

[Falci]

The other thing to consider about this proposal is that, even though it is technically a soft-fork, really everyone in the community needs to be aware. Users who don't upgrade their Bob Wallet will still think they can bid after the soft-fork rule ends the auciton.

I don't consider this a big problem because eventually the TX will become invalid and the money will be unblocked

Another other thing to consider here is performance

That's what I meant in the problem 1

[pinheadmz]

Required reading for this discussion should include:

https://polkadot.network/blog/research-update-the-case-for-candle-auctions/
https://wiki.polkadot.network/docs/learn-auction
https://wiki.polkadot.network/docs/learn-randomness

TLDR: Polkadot believes in random auction ending times but they are able to achieve this using a network-wide pseudorandom generator function which "might" be fair (I haven't dug in). The proposal by @Falci gets its entropy from a blockhash which is actually pretty bad: it means miners can choose to withhold blocks or do the extra work to find a block that affects an auction outcome unfairly. Miners already have the power to censor BIDs and (god forbid) REVEALs, giving them the extra power to determine auction close timing feels like we'd be making the game worse, not better.

I have another way of thinking about this, definitions:

Sniping

An "honest" bidder sends a BID with a lockup of 1.000000 HNS and unknown value.

A "sniper" sends a BID with lockup and value of 1.000001 HNS during the "sniping phase".

Sniping Phase

The sniping phase is the end of the bidding phase where there is SOME PROBABILITY that no one else will be able to place another bid. During this phase, the "honest" bidder and the "sniper" could both try to outbid each other by 1 dollarydoo back and forth, over and over, until the sniping phase is over, and the auction is ended. If both bidders are online and watching the mempool, they essentially have equal probability of being the last bidder.

In the current system, the sniping phase begins when the second-to-last BIDDING block is mined and ends when the last BIDDING block is mined. Currently, this phase lasts an average of 10 minutes but it could vary anywhere from 0 seconds to 1 hour or more. This duration is determined by the ONLY truly chaotic source of entropy in the entire system: the mining algorithm itself. Miners are currently incentivized to broadcast any block they find as soon as possible.

This proposal

This proposal changes the "sniping phase" in the following way:

• Instead of an average duration of 10 minutes, the duration is determined by the miners up to a 24-hour maximum.
• Instead of no one at all being able to know when an auction will end, the miners know.

Counter proposals

I suggest we think about things like this instead:

• (hard fork) include some kind of truly private zero-knowledge blinding for bids
• (soft fork) add some kind of extra truly random element like polkadot and use that for candle auctions
• (application layer) build and promote blinded liquidity loans so all blinds are huge even though actual bids may be small
• (soft fork) require that winning bids win by some % above the second-highest

This last one is compelling to me: what if we ignore the BIDDING phase and think about the REVEAL phase? This is how polkadot candle auctions work - basically there is some random factor to determine if a REVEAL should be counted or not.

[pinheadmz]

Although as @rithvik pointed out on discord, some of these things would actually require a hard fork. For example if we made some REVEALs "not count". We could prevent certain BIDs from REVEALing at all but in a soft fork that would still burn user coins.

[Falci]

This is how polkadot candle auctions work - basically there is some random factor to determine if a REVEAL should be counted or not.

So, all the we need is a random number generator, get a number and determine when the auction was over.

Using block hash is not safe because miner could manipulate it.
What if we use block hash but from the block with biggest difficult in the last N blocks?

N could be 5 or 100 or anything.

Do you think miner could still manipulate the outcome?

[pinheadmz]

A miner could just set their target to a higher value but that introduces an interesting trade-off because a harder target would take longer to find, potentially losing the race.

[pinheadmz]

https://gist.github.com/pinheadmz/43782e26b1c53eea08bd5b7d83dd4d5d

[Falci]

What would be better: highest or lowest difficult?

[jacobjonz]

That would ignore the bids in the last N blocks

Would be quite difficult to explain to people. Many don't understand the current system when they come in. This would confuse them more. But may be managable.