Sell/buy API behaviour

[randomlogin]

Testing API introduced in #58.

First observation

I've discovered that user can sell a name which has not yet been claimed.

Steps to reproduce:

1. Open a name
2. Wait until its rollout (perhaps this step does not affect anything and it will be the same before rollout and even when auction has 'concluded' and the name can be claimed).
3. Selling a name provides a valid response:

$ space-cli --chain regtest sell @qwerf 170000
{
  "space": "@qwerf",
  "price": 170000,
  "seller": "bcrts1pgmludxu7wjg2hzzxv3gpspxuku8r952sqr2ycqqwfw2cv6c0chwqn5jtzu",
  "signature": "2abaeac18197453ea171bf3080391a10ebcd63864c6ec6815bd56f130e1ce71ce15b1087415a455d301a9fa397e550ed9d64803dba8ef14dbd86413d935e19eb"
}

4. Trying to buy it shows an error of premature claim:

space-cli --chain regtest buy @qwerf 170000 --signature 2abaeac18197453ea171bf3080391a10ebcd63864c6ec6815bd56f130e1ce71ce15b1087415a455d301a9fa397e550ed9d64803dba8ef14dbd86413d935e19eb --seller bcrts1pgmludxu7wjg2hzzxv3gpspxuku8r952sqr2ycqqwfw2cv6c0chwqn5jtzu --fee-rate=1
{
  "code": -1,
  "message": "tx-check: transaction not broadcasted as it may cause a space to be revoked (code: PrematureClaim)"
}

Invoking verifylisting returns null.

$ space-cli --chain regtest verifylisting @qwerf 170000 --signature 2abaeac18197453ea171bf3080391a10ebcd63864c6ec6815bd56f130e1ce71ce15b1087415a455d301a9fa397e550ed9d64803dba8ef14dbd86413d935e19eb --seller bcrts1pgmludxu7wjg2hzzxv3gpspxuku8r952sqr2ycqqwfw2cv6c0chwqn5jtzu
null

Broadcasting this tx results in a revocation of a space.

Expected behaviour

1. Not yet 'owned' spaces should not be able to be sold.
2. Sell should return an error.
3. verifylisting should check a sell offer against the current chain state (and return something more human-readable than null in case there is no error)

Second observation

I'm not sure that I've decrypted it right, but anyway:

There is no way to make verifylisting to account for the current mempool or any unconfirmed chain state.
After a user creates a sell offer, then invokes some spaces action (say opens a name), the signature and the address for a sell offer change. Thus, creating several 'valid' offers which are essentially identical, which might be a problem.

Suppose a user wants to sell a name:

$ space-cli --chain regtest sell @111 12000
{
  "space": "@111",
  "price": 12000,
  "seller": "bcrts1px70kwkl2jzs9pgjzfgfncdqk4chvmau3cxxu7f52mszdr44hggkq4ycuzk",
  "signature": "11fcd52bd92d6997176eaf08cfdfe8b14121dc03bb083d9f81fa5017f9dd957a226ea8671db38044cf237ce3d86c9b0961f34d329f118745b9038639e718b5e0"
}

Next, he does some space action, let's say opens a space:

$ space-cli --chain regtest open @heyhey --fee-rate=1
{
  "result": [
    {
      "txid": "674e388d77fb5f7b8580d92c76d6f6020d043f08019062b251b182a2499fa3e4",
      "events": [
        {
          "type": "bidout",
          "count": 3
        },
        {
          "type": "commit",
          "space": "@heyhey",
          "commit_script_pubkey": "5120e1370216b65dd6e7c10d6fa8f8d02a54c94bfc866f173fd1f1af94046dda3746",
          "commit_signing_info": "04300cdededede010668657968657975209c0a9d1b76dcb8861820404f22759e279e43d9f8c0b7f3d79674b2efc070aa8cac225120e1370216b65dd6e7c10d6fa8f8d02a54c94bfc866f173fd1f1af94046dda374621c09c0a9d1b76dcb8861820404f22759e279e43d9f8c0b7f3d79674b2efc070aa8c2000ab6c3775dd6ed41c45c0d6c61f79766e874aef4eb05dbabb6613847d321f95"
        }
      ]
    },
    {
      "txid": "5517676223f42ea2e5bca3c4fcda6f17547140fa49a717e5d4458b52cc412990",
      "events": [
        {
          "type": "open",
          "space": "@heyhey",
          "bid_initial": 1000
        }
      ]
    }
  ]
}

After an open the data of the sell offer changes:

$ space-cli --chain regtest sell @111 12000
{
  "space": "@111",
  "price": 12000,
  "seller": "bcrts1pvjgzt8sky49f4dlw99s9j8fsux4ylp3hsnhwfd77lsgwdg6aj95qfmmj3y",
  "signature": "93845626bb686a35a59d46636ee88baabddfac79db52a49b022eb7ed0374dd27a275cbdeed26727f58259875bde76c9d43240a8060e188a80a41653c4beacc6a"
}

However both offers remain valid:

$ space-cli --chain regtest verifylisting @111 12000 --seller bcrts1px70kwkl2jzs9pgjzfgfncdqk4chvmau3cxxu7f52mszdr44hggkq4ycuzk --signature 11fcd52bd92d6997176eaf08cfdfe8b14121dc03bb083d9f81fa5017f9dd957a226ea8671db38044cf237ce3d86c9b0961f34d329f118745b9038639e718b5e0
null

$ space-cli --chain regtest verifylisting @111 12000 --seller bcrts1pvjgzt8sky49f4dlw99s9j8fsux4ylp3hsnhwfd77lsgwdg6aj95qfmmj3y --signature 93845626bb686a35a59d46636ee88baabddfac79db52a49b022eb7ed0374dd27a275cbdeed26727f58259875bde76c9d43240a8060e188a80a41653c4beacc6a
null

Buying a name using some of the offers makes the other obsolete:

$ space-cli --chain regtest buy @111 12000 --seller bcrts1pvjgzt8sky49f4dlw99s9j8fsux4ylp3hsnhwfd77lsgwdg6aj95qfmmj3y --signature 93845626bb686a35a59d46636ee88baabddfac79db52a49b022eb7ed0374dd27a275cbdeed26727f58259875bde76c9d43240a8060e188a80a41653c4beacc6a --wallet buyer --fee-rate=1
{
  "txid": "e6c3e0f6c450894eca077948b95b2150dd008d6ff33f8ffde1fce4340f127096",
  "events": [
    {
      "type": "buy",
      "space": "@111",
      "foreign_input": "c1b8860eb02dd7bb44a86606d2806a5c556b8357e35cd579e88ec47e78e5d98c:1"
    }
  ]
}

$ space-cli --chain regtest buy @111 12000 --seller bcrts1px70kwkl2jzs9pgjzfgfncdqk4chvmau3cxxu7f52mszdr44hggkq4ycuzk --signature 11fcd52bd92d6997176eaf08cfdfe8b14121dc03bb083d9f81fa5017f9dd957a226ea8671db38044cf237ce3d86c9b0961f34d329f118745b9038639e718b5e0 --wallet buyer --fee-rate=1 --skip-tx-check
{
  "code": -1,
  "message": "RPC: -26:bad-txns-spends-conflicting-tx, 0e87891c46b6687022eef2e3032fbdf2dca0129a5c71c3c729a2af54e69d16d6 spends conflicting transaction e6c3e0f6c450894eca077948b95b2150dd008d6ff33f8ffde1fce4340f127096"
}

However it's still is shown as valid via verifylisting:

$ space-cli --chain regtest verifylisting @111 12000 --seller bcrts1px70kwkl2jzs9pgjzfgfncdqk4chvmau3cxxu7f52mszdr44hggkq4ycuzk --signature 11fcd52bd92d6997176eaf08cfdfe8b14121dc03bb083d9f81fa5017f9dd957a226ea8671db38044cf237ce3d86c9b0961f34d329f118745b9038639e718b5e0
null

Thoughts: allow to force the second tx broadcast, to make possible the other buyer also to buy the name (same goes for buying using the same sell offer, but by several buyers), leaving it up to miners which tx of several conflicting ones to include.

[buffrr]

Thanks! yes we should check for transfer covenant during buy/sell/verify.

(and return something more human-readable than null in case there is no error)

verifylisting returns an RPC error object otherwise it's an RPC success with { "result": null } so it should be fine. We could return the listing or something but that should be a separate issue if you want to propose an alternative.

There is no way to make verifylisting to account for the current mempool or any unconfirmed chain state.

Yes, it shouldn't since those listings are still valid until confirmation and you can buy the space by paying a higher fee.

After a user creates a sell offer, then invokes some spaces action (say opens a name), the signature and the address for a sell offer change. Thus, creating several 'valid' offers which are essentially identical, which might be a problem.

That's because the wallet generates a new address for the other offers.

All have valid signatures and all are indeed valid.