Blind value not found when trying to send reveal

[dylanbathurst]

I've been trying to send a reveal for a tld, initially from Bob wallet, but also from the cli on a completely separate hns full node and I keep getting the Blind value not found error. When I run hsw-rpc getbids i see the correct bid and I also see my bid when I run hsw-rpc getauctioninfo coin

from @pinheadmz's request I first tried hsw-rpc selectwallet mywallet to make sure I was using the correct wallet.

[pinheadmz]

Blinds are saved when the bid is made. In hsd wallet they are deterministically generated, so in the worst case you should be able to regenerate the nonce.

How did you make the bid? And what is the relationship between Bob and your other full node? If you sent the bid from one, I wouldn't expect the other to know the blind without being precomputed.

[dylanbathurst]

I see, I’ll try regenerating. I initially made the bid on bob but when I went to reveal I got that error, so I went over to my own had node on a separate computer and imported my seed to try it there, same error. I initially imported an existing seed into bob so I wonder if the issue with bob is that it’s not selecting my imported wallet before doing the reveal request...

[dylanbathurst]

Is there a nonce that I can compare the output of importnonce?

[pinheadmz]

Looks like the http endpoint (not rpc) has more verbose output:

https://hsd-dev.org/api-docs/#get-nonce-for-bid

You could compare the entire blind with the value in the BID covenant in the output of your BID transaction... is that what you mean?

[bemusementpark]

In hsd wallet they are deterministically generated, so in the worst case you should be able to regenerate the nonce.

Should this be done automatically when 1. importing a wallet and/or 2. you call reveal (etc.) and there is no blind present?

[pinheadmz]

@bemusementpark when importing a wallet from a mnemonic seed, there is no way to know the VALUE of the bid being blinded. Therefore a restored wallet can not regenerate the nonce without extra input from the user.

[bemusementpark]

Oh, that's unfortunate. I would have thought it would be stored on the blockchain.

It means some people will be unable to recover their wallet with their private-key/ mnemonic-phrase. It means you can't use handshake effectively on multiple computers e.g. during travel, between desktop/mobile etc.

Would it be possible/expensive to encrypt the bid and store it on the blockchain?

Then your wallet would be recoverable from seed phrase alone.

[pinheadmz]

Bids on Handshake are blinded. So by definition the bidder needs to keep something secret, off chain. The nonce can be any value at all but hsd has a convenient feature to generate it deterministically using the seed and bip44 tree, combined with the bid value itself. The bid value is the only external input into the nonce function because without that a user couldn't place more than one bid.

There are actually many shortcomings of the bip44 and bip39 design (the electrum developers have complained about this a good deal). These issues are exacerbated by hsd and bcoin watch only wallets among other features.

I think since mainnet launch we have learned that to really backup a wallet for hsd the entire wallet datadir should be copied. We could probably also add a function to dump bids and nonces and make an easy way to import that data.

If you have any ideas on how to implement this please open a PR or an issue! Perhaps this could be our first "HIP" (handshake improvement proposal)

[bemusementpark]

Well, the simplest solution from a users perspective is probably the best.

Where can we store data on-chain? I guess there is insignificant cost adding an extra int somewhere, right?

If we can store an extra field in the covenant and retain backwards compatibility then we could encrypt the bid with the seed using symmetric key cryptography. It would be useless for any other purpose than wallet recovery... or perhaps it would be so good that the wallet wouldn't even save the bids and this would be decrypted for every call requiring the bid (sendreveal, etc.)

[pinheadmz]

That's not bad. Maybe the nonce function could just use other data besides the bid value to be totally deterministic from the seed. (Like prev TX hash or something?)

[pinheadmz]

@chjj any thoughts on this? Is the bid value needed to create a unique, deterministic nonce? Or could some other data be integrated that doesn't need to be independently backed up by the user? At this time, hsd wallets in mid-auction are somewhat volatile, not unlike a Lightning Network node with active channels.

[bemusementpark]

It'd be convenient if when the wallet failed to sendreveal if it attempted an importnonce with a blind of 0.

[pinheadmz]

I want to add explicit directions for the work around for this until we have a better solution in the wallet.

The problem

After a rescan, a wallet can find all your blinded bids on the blockchain but it does not "remember" how much you actually bid on a name. This actual value is blinded in the BID transaction/covenant and is not recoverable from the blockchain + bip44 seed alone.

The workaround

You must remember the value of your bid before it was blinded, then re-import it into the wallet.

Step 1: find your BID

Find the bid in your wallet. This may be tricky if you have many unrevealed bids for multiple auctions but using the coins API command and grepping for BID you should be able to locate it:

https://hsd-dev.org/api-docs/?shell--cli#list-all-coins

$ hsw-cli coins | grep BID -B 7 -A 11
  {
    "version": 0,
    "height": -1,
    "value": 2000000,
    "address": "rs1qs9amxpz6q3rgs04qy3qkvae375qadzd3dhx8fa",
    "covenant": {
      "type": 3,
      "action": "BID",
      "items": [
        "09234807e4af85f17c66b48ee3bca89dffd1f1233659f9f940a2b17b0b8c6bc5",
        "65000000",
        "666f6f626172",
        "e696f15d3b4dc487c75ec4d70448549b20e5e717d5a27674cb68173ff5637fbd"
      ]
    },
    "coinbase": false,
    "hash": "301e75d47b8523619f98187488f5979382eb6103923d4cf705d7968cef4deb36",
    "index": 0
  },

Step 2: importnonce

The important detail from the above JSON is the address value. This is the address from your wallet that the BID is "spending to" (the destination of the UTXO containing the BID covenant).

Combine this datum with the name you bid on and the value you REMEMBER bidding (in HNS, for this example 1.000000 would be equivalent):

https://hsd-dev.org/api-docs/?shell--cli#importnonce

$ hsw-rpc importnonce foobar rs1qs9amxpz6q3rgs04qy3qkvae375qadzd3dhx8fa 1
e696f15d3b4dc487c75ec4d70448549b20e5e717d5a27674cb68173ff5637fbd

Notice how the output of this command (the blind, or hashed value) matches the last covenant item in the output of the first command.

If your value was correct, rpc sendreveal will work.

[tynes]

It'd be convenient if when the wallet failed to sendreveal if it attempted an importnonce with a blind of 0.

While automation is nice, I don't think that this will work most of the time. I think a CLI tool that grinds would be more useful here for when the blind value is lost. It is possible to implement what you are suggesting in a permissionless way using the plugin interface.

[pinheadmz]

The ability to import nonce into Bob will hopefully be added soon:
kyokan/bob-wallet#116

[pinheadmz]

I had a shower thought about this. Imagine an opt-in standard like this:

1. Import mnemonic phrase. Wallet derives a private key at some standard path like m'/5353'/5353'/5353'/5353'/<value> where <value> is something like the (nameHash || address)[0] so it's unique to each BID.

2. Repurpose this 32-byte ECDSA private key as an AES key

3. Encrypt bid value with this key and add encrypted value as an OP_RETURN (actually witness version 31 with up to 40 bytes program data) for each BID

When user imports seed phrase, AES key is regenerated deterministically and the blinded value can be decrypted and stored for use in the REVEAL.

[pinheadmz]

Well, it's been a long 17 months, but we have an idea for this now: handshake-org/HIPs#28