How does Blockstack prevent front running?

@vsund asks:

wouldn’t this be vulnerable to race conditions like “server sees a preorder tx and sends the same preorder with a better fee”?

phisery asks:

I was wondering the same thing @vsund as it is now allowing me to register the same name even though I did get a confirm back.

In other words, how does Blockstack prevent a Bitcoin node that sees a Blockstack preorder transaction from sending the same preorder transaction with a higher fee that would theoretically be preferred by miners?

The Blockstack preorder transaction works as follows:

It takes the fully-qualified name you want to register (name + “.” + namespace), a script public key to prove that the the later register transaction is by the same person and the address that will own the name, hashes these values and broadcasts it along with the current consensus hash in op_return.

The data format is as follows: (shamelessly copied from the code )

0     2  3                                              23             39
|-----|--|----------------------------------------------|--------------|
magic op  hash(name.ns_id,script_pubkey,register_addr)   consensus hash

This means that a Bitcoin node doesn’t know which name the preorder operation is for, so it can’t pay more to register the same name as you unless it already knows via some other channel which name you are registering.

Ah, great thing!

So I guess the revealing of the plain name happens first after the preorder went through and the name provable belongs to an address?

yes, that happens with the register operation

I am the one that had the issue. Is there some way to manually intervene to get the pre-order to proceed? Not sure why it is hung up in that state still (more than 130 confirmations), but when I use blockstack info it still shows as preorder. Thoughts?

I have the tx_hash that was sent back when it took my BTC so it seems to be in a half-way state? Jude has a few more details from the api_endpoint.log that I sent him via dm.