Anunayj/turbo-blinds.md Secret

## turbo-blinds.md

      
    Raw
  

              turbo-blinds.md
            
          
    Turbo Blinds

The Problem


Alice wants to bid 10 HNS
Bob has 90 HNS to stake
Bob charges a fee of 5 HNS

Generalized protocol

Step 0

Bob sends ALice his public key pubKeyB, Alice generates two keys (pubkeyA1, pubkeyA2)
Step 1

Alice creates the following contracts:
Funding contract (fundingScript):
OP_IF
  <pubKeyB> OP_CHECKSIGVERIFY
OP_ELSE
  <reveal phase end height> OP_CHECKLOCKTIMEVERIFY OP_DROP
OP_ENDIF
<pubKeyA1> OP_CHECKSIG

Bid Contract (bidScript):
OP_IF
  <pubKeyB> OP_CHECKSIGVERIFY
OP_ELSE
  <reveal phase end height> OP_CHECKLOCKTIMEVERIFY OP_DROP
OP_ENDIF
<pubKeyA2> OP_CHECKSIG


They are identical except the use of different publickeys to end with a different P2WSH address, this ensures transactions to these addresses cannot be correlated onchain before the reveal phase.
Step 2

Now Bob and Alice presign the following transaction:
Reveal tx:
txid : tx-unknown // txid depends on prevouts
Input #0: ALL | NOINPUT | ANYONECANPAY
  prev_txid:
  prev_index: 
  amount: bid + blind (100 HNS)
  script : bidScript
Input #1: ALL | NOINPUT | ANYONECANPAY
  prev_txid:
  prev_index: 
  amount: bid + fee + txFee (15+1 HNS)
  
Output #0:
  Covenant: REVEAL
  Amount:  10 HNS
  To: Bid Contract
Output #1:
  Amount: 105 HNS (Alice's Fee + Blind + Bid)
  to: Bob's wallet

Both Alice and Bob verify the presigns, the transaction can be aborted here in case of foul play by either user.
Use of NOINPUT will allow one to fill the prevouts with any prevouts of appropriate value coming from the given script.
Step 3

Now Alice creates the following transaction and broadcasts it.
Alice's Funding Transaction
txid : t001
Input #0: her wallet

Output #0: 
  Amount: Her bid + Bob's Fee + Tx fee costs (16 HNS)
  To: Funding contract 
Output #1: change

Bob waits a appropriate (and random!) amount of time for this Transaction to get confirmed on-chain.
It is very important that this transaction is not orphaned in a reorg else Bob will not be able to reveal.
(Though bob can pay for the bid himself in worst case scenario and lose bid + free)
Randomness ensures that these transactions are not easily correlated on-chain.
Bob then creates and broadcasts the following transaction
Bob's Bid Transaction
txid : t002
Input #0: His wallet

Output #0: 
  type: BID to name
  Amount: Blind + Bid + Tx fee (100 HNS)
  To: Bid Contract
Output #1: change

Step 4

Since both parties have a copy of presigns, either of them can broadcast the reveal transaction as the auction goes on.
It is important that Bob stays online during this period and ensures that there presigns are broadcasted, since Alice has no incentive to broadcast these transactions herself. (All she loses is some transaction fees, time and on the auction)
After the end of reveal phase, Alice can unilaterally spend from the Bid contract which allows her to TRANSFER/REGISTER/UPDATE the domain however she desires.
Attack Vectors

Liquidity trolling

In Step 4, there is nothing stopping Bob from going offline after Alice broadcasts his funding transaction at no cost to him, locking Alice's bid amount for the entire duration of auction.
There are a few solutions to this:

The obvious, trusting Bob.
If Bob is a big known entity, liquidity trolling will be detrimental to their reputation and therefore it might be feasible to just trust them.
Both trusting a trusted 3rd party.
If Both Alice and Bob trust a 3rd party (Carol), this party can act as arbitrator. The scheme works by Carol and Bob creating a multisig (which can be spent alone by Bob after a (long) penalty time), and making Bob transferring her funds into this multisig. Now Carol can simply punish Bob anytime by simply refusing to sign any transactions for him.
This ensures that Carol is never in unilateral control of funds, and any attack involves Carol acting dishonestly (which is detrimental to her reputation), which in it's worth case scenario leads to funds being locked up for a duration of time.
Atomic Swap using Adaptor Signatures
Adaptor signatures can be used to ensure both transactions happen atomically (as in one transfer will allow the other to transfer, not as in same block or tx) in a way that cannot be correlated by a third party. The lockup time in case of malacious play will be in order of hours (instead of days).