BNS Upgrade: registration flow

This post is part of a larger effort to discuss potential features to be included in an upgraded version of BNS. Please see the megathread for more information.

Proposal: implement a change to the two-step registration process to reduce the potential for front-running expirations

The current BNS contract uses a “commit-reveal” scheme, where a user preorders and then registers their name in two steps. The desired outcome of this is to reduce the potential for front-running a registration. The current implementation does not prevent front-running, and it only adds additional complexity and cost to registrations.

To understand how front-running can occur, it’s important to understand that anyone can register a name in just one transaction by using a custom contract that calls name-preorder and name-register in a single transaction. Various apps take advantage of this to make registration more easy for users.

To illustrate the potential for front-running in the current implementation, imagine this example:

  • Alice wants to register alice.btc
  • Alice makes a first transaction, calling name-preorder. Alice’s desired name is not known to the public yet
  • Next, Alice broadcasts a contract call to name-register, which includes the “plain text” name they wish to register
  • An attacker sees this name-register transaction in the mempool, and broadcasts a custom “preorder and register” transaction with a higher fee
  • The attacker’s single transaction is confirmed first, resulting in the attacker owning alice.btc

Proposed solution: required time delay between preoder and registration

To prevent this scenario, a new version of BNS can require a minimum period of time (such as 1 block) between a pre-order and registration transaction. By implementing a required time delay, the previously described attack cannot be executed.

Determining the “best” time delay must balance the need for a good user experience, while still making it difficult to front-run. A delay that is too small (such as 10 seconds) is not sufficient, because the user’s transaction cannot be confidently confirmed that quickly. An attacker can spend a higher fee to easily confirm two transactions before the user’s final transaction is confirmed.

The ENS protocol uses a similar scheme, and their required delay is 1 minute. This value, which is roughly 4 blocks on Ethereum, is sufficient that a user at risk of being front-run can spend enough on fees to have their transaction confirmed within that amount of time.

This scheme doesn’t completely prevent front-running, because there is no guarantee that a user’s transaction can be confirmed in a specific amount of time. The goal is to create a design that balances both usability and safety.

Allowing single-transaction registrations

As described earlier, many apps have begun providing registration experiences that can be completed in a single transaction. For most users, this is a desirable result, and they are likely not at risk of being front-run.

To maintain this capability while still providing safety, a new BNS contract can implement a single-transaction registration flow that prevents transfers of the name for a minimum amount of time. This transfer restriction would prevent attackers from using this method to front-run registrations.

As an example, assume a “preorder delay” of 1 minute, and a “transfer delay” for single-transaction registrations of 20 minutes:

  • Alice preorders alice.btc and their transaction confirms
  • Alice broadcasts their name-register transaction
  • An attacker sees this transaction in the mempool, and front-runs the registration by broadcasting a “single transaction”
  • The attacker’s transaction is confirmed first, but they cannot transfer the name yet
  • Soon after, Alice’s transaction is confirmed
    • The BNS contract sees that Alice’s preorder transaction came before the attacker’s registration, and transfers the ownership of the name to Alice

Downsides of this approach

This proposal should reduce the potential for front-running, but it cannot completely prevent it. In addition, it adds complexity and the potential for confusion of users.

If this proposal were to be rejected, it may be the right approach to remove the name-preorder step entirely. Such a change would reduce in easier and cheaper registration fees, while still having the same potential for attacks as the current implementation.

Sounds good in theory, but I feel like frontrunning is not a big issue (anymore). It was more of an issue during peak .btc registration hype, when literally thousands of great names, digits and emoji domains where still free to register. Nowadays I don’t think it happens a lot, if at all.
It could be an issue again, if for whatever reason let’s say the .id namespace goes parabolic.

1 Like

Apologies if I’m missing something here Hank, but why can’t we just have a one transaction registration for BNS 2.0/V2? That would be the best outcome imo and agree with Deloon I don’t think front running is an issue at all anymore.

I understand these points and I think I agree that it doesn’t seem like front-running is a common problem.

What’s I’m suggesting is that there are three potential options:

  1. Exactly as it is today - no real front-running protection and it’s still possible to do a 1-tx registration.
  2. A new scheme where you can get front-running protection if you want, but otherwise you can still do a 1-tx registration. The downside is that you can’t transfer your name after the 1-tx registration for a short period of time (ie a few blocks)
  3. We drop the existing 2-tx flow entirely and only allow 1-tx registrations. This is basically the same thing as option 1 but with less contract cost and more simplicity

I think front-running is not a problem until it is a problem. Hopefully with new namespaces in the future front-running will be come a problem again. With that in mind I’d lean towards 2 - coming up with a new scheme. We can brainstorm more about what exactly that scheme is.

If we decide we don’t care about frontrunning at all, then 3 makes sense.

A fourth option is make deciding between 2 and 3 a per namespace option.

I agree with Larry’s point. Front running might not be an issue on the .btc namespace rn. But it will be for new namespaces.
My experience on btc.us dictates that 2-tx system is a real pain-point for users.
Add the chance of front-running to the mix and it leaves users frustrated.

Considering the current alternatives don’t really prevent front-running either. I would say UX needs to be prioritised. To that end, a 1-tx registration seems like the better approach. Let the amount of fees dictate who procures a name in the event of multiple users trying for the same name.