ordinals / ord

👁‍🗨 Rare and exotic sats
https://ordinals.com
Creative Commons Zero v1.0 Universal
3.84k stars 1.37k forks source link

Is there a way to pre-fetch the sat number of the next inscription? #1782

Open null-ish opened 1 year ago

null-ish commented 1 year ago

Hi, I'm a generative artist and I've been experimenting with a full ord node.

I was wondering if it was a way to predict the number of the satoshi that would be used in the next inscribe command.

Many thanks!

mmikrut commented 4 months ago

Hi, newbie here. I would also like to know if there is any way to select a sat for the next inscription so I can display it as a part of the inscription - see my use case: https://signet.ordinals.com/inscription/66fa8c3e2c3a564e7027ce40612f5f290de914bc474cfaf2c50f2067cdbf9966i0

From my limited understanding, SAT number could be calculated from the selected UTXO ? Help would be appreciated.

raphjaph commented 4 months ago

To specify the sat you want to inscribe on you can use the --sat or --satpoint options on the ord wallet inscribe or the satpoint and sat with ord wallet batch in the modes same-sat or satpoints. Have a look at the docs here: https://docs.ordinals.com/guides/batch-inscribing.html

mmikrut commented 4 months ago

Thanks @raphjaph,

I'm trying to understand this for the last couple of days. To display the sat number on an inscription, I need to know it in advance. Choosing a sat with satpoint or sat is nice, but my problem is that I don't see any sats in my wallet.

bitcoind is running with -txindex, ord server is running with --index-sats, yet I see no sats are listed.

I would expect the ord wallet sat command to give me a list of sats ( or at least a range or list of sat ranges ? ), common and uncommon, but the list is empty.

I'm stuck :(

bitcoin-cli -signet -rpcwallet=ord_signet_test_wallet4 listreceivedbyaddress
[
  {
    "address": "tb1prdmef4ku2een9f052248ql9wf3wq6vtkpz48fzt8w2cpslng3qnslz7rtx",
    "amount": 0.00099878,
    "confirmations": 135,
    "label": "",
    "txids": [
      "e3b0d19e1e7cc375b61efb39ddfec97ad2329c7a5864f6a81ac5b4cb98af13c1"
    ]
  }
]

ord --signet --index-sats wallet --name ord_signet_test_wallet4 --server-url http://localhost:8080  outputs
[
  {
    "output": "e3b0d19e1e7cc375b61efb39ddfec97ad2329c7a5864f6a81ac5b4cb98af13c1:0",
    "amount": 99878
  }
]

ord --signet --index-sats wallet --name ord_signet_test_wallet4 --server-url http://localhost:8080  sats 
[]
raphjaph commented 4 months ago

When you start the indexing the first time the --index-sats has to be set. If you started it initially without it then it's ignored . We should add some sort of warning here. So you'll have to delete the index.redb file and start indexing again with ord --signet --index-sats server --http-port 8080 --address localhost

raphjaph commented 4 months ago

3785

mmikrut commented 4 months ago

Thanks, will try delting index & try again. BTW, I noticed ord index has an option '--update' - it would be nice if this created the index if it was not created initially.. (?)

raphjaph commented 4 months ago

I don't think we have an --update option. Do you mean the ord index update subcommand?

mmikrut commented 4 months ago

subcommand it is :)

I have rebuilt the index as per your advice. The ord --signet --index-sats index info command produces long output.

But the output of wallet sats command is still an empty list :( Is the a way to run ord in a debug mode? I dont see any debug commands / options, and no logfiles produced.

ord --signet --index-sats wallet --name ord_signet_test_wallet4 --server-url http://localhost:8080  sats 
[]
mmikrut commented 4 months ago

OK, so I worked out logging the debug output, so here it is, same command as before, there is a JSON-RPC error in getblockhash that pops out in the log at the bottom. Still no sats displayed :(

[2024-05-25T11:18:24Z DEBUG hyper::proto::h1::io] parsed 2 headers
[2024-05-25T11:18:24Z DEBUG hyper::proto::h1::conn] incoming body is empty
[2024-05-25T11:18:24Z DEBUG hyper::proto::h1::io] flushed 361 bytes
[2024-05-25T11:18:24Z DEBUG hyper::proto::h1::io] parsed 4 headers
[2024-05-25T11:18:24Z DEBUG hyper::proto::h1::conn] incoming body is content-length (208 bytes)
[2024-05-25T11:18:24Z DEBUG hyper::proto::h1::conn] incoming body completed
[2024-05-25T11:18:24Z DEBUG bitcoincore_rpc] JSON-RPC request: getrawtransaction ["7bf4dd642417524da7bee9b01e3c0d32c0012524dc1becce400140be39372520",false]
[2024-05-25T11:18:24Z DEBUG bitcoincore_rpc] JSON-RPC request: gettxout ["7bf4dd642417524da7bee9b01e3c0d32c0012524dc1becce400140be39372520",0,true]
[2024-05-25T11:18:24Z DEBUG bitcoincore_rpc] JSON-RPC request: getrawtransaction ["5a5b4e5214da5bb77bc49d9e556e50eacbdb0805db0a3e94507ecb72f6350499",false]
[2024-05-25T11:18:24Z DEBUG bitcoincore_rpc] JSON-RPC request: gettxout ["5a5b4e5214da5bb77bc49d9e556e50eacbdb0805db0a3e94507ecb72f6350499",1,true]
[2024-05-25T11:18:24Z DEBUG bitcoincore_rpc] JSON-RPC request: getrawtransaction ["73ccfc5950eb7524bfa114a90bbd8ce70ec993dae1586bdb7950abf58062fcfd",false]
[2024-05-25T11:18:24Z DEBUG bitcoincore_rpc] JSON-RPC request: gettxout ["73ccfc5950eb7524bfa114a90bbd8ce70ec993dae1586bdb7950abf58062fcfd",1,true]
[2024-05-25T11:18:24Z DEBUG hyper::proto::h1::io] flushed 1591 bytes
[2024-05-25T11:18:24Z DEBUG hyper::proto::h1::io] parsed 4 headers
[2024-05-25T11:18:24Z DEBUG hyper::proto::h1::conn] incoming body is content-length (70 bytes)
[2024-05-25T11:18:24Z DEBUG hyper::proto::h1::conn] incoming body completed
[2024-05-25T11:18:24Z DEBUG bitcoincore_rpc] JSON-RPC request: getrawtransaction ["7bf4dd642417524da7bee9b01e3c0d32c0012524dc1becce400140be39372520",false]
[2024-05-25T11:18:24Z DEBUG bitcoincore_rpc] JSON-RPC request: getrawtransaction ["7bf4dd642417524da7bee9b01e3c0d32c0012524dc1becce400140be39372520",false]
[2024-05-25T11:18:24Z DEBUG hyper::proto::h1::io] flushed 982 bytes
[2024-05-25T11:18:24Z DEBUG hyper::proto::h1::io] parsed 2 headers
[2024-05-25T11:18:24Z DEBUG hyper::proto::h1::conn] incoming body is empty
[2024-05-25T11:18:24Z DEBUG hyper::proto::h1::io] flushed 3013 bytes
[2024-05-25T11:18:24Z DEBUG hyper::proto::h1::conn] read eof
[2024-05-25T11:18:26Z DEBUG bitcoincore_rpc] JSON-RPC request: getblockcount []
[2024-05-25T11:18:26Z INFO  ord::settings] Connecting to Bitcoin Core at 127.0.0.1:38332/
[2024-05-25T11:18:26Z INFO  ord::settings] Using credentials from cookie file at `/home/btcnode/.bitcoin/signet/.cookie`
[2024-05-25T11:18:26Z DEBUG bitcoincore_rpc] JSON-RPC request: getblockchaininfo []
[2024-05-25T11:18:26Z DEBUG bitcoincore_rpc] JSON-RPC request: getnetworkinfo []
[2024-05-25T11:18:26Z DEBUG bitcoincore_rpc] JSON-RPC request: getblockhash [197114]
[2024-05-25T11:18:26Z DEBUG bitcoincore_rpc] JSON-RPC error for getblockhash: RpcError { code: -8, message: "Block height out of range", data: None }
[2024-05-25T11:18:26Z DEBUG ord::index::updater] Outpoint channel closed
raphjaph commented 4 months ago

Ah sorry my bad, the ord wallet sats command only lists rare satoshis. If you pass in a tsv file with a list of satoshis you're looking for it will tell you if you have them in your wallet. I think we should not only list rare sats but just list all ranges of sats in a wallet. I'll open an issue for that.

As a workaround for now you could try the following:

List all outputs in wallets with ord wallet outputs

Then do ord list <OUTPOINT> for every one of those outputs to show you the sat ranges. You could probably also write a small bash script or even just pipe it smartly with jq.

raphjaph commented 4 months ago

3792

mmikrut commented 4 months ago

Thanks, will try that, but I had issues with ord list <OUTPOINT>, it produced empty list. Also, as you can run it only when server is not running, its utility is limited, as i would need a server running at all times in the production environment

raphjaph commented 4 months ago

Yeah, ord list is an old ccommand we haven't migrated to the new server model yet.

Which outpoint did you run the command on?

mmikrut commented 3 months ago

Hi, I'm now running ord 0.19.0-dev build, and ord list displays output correctly.

Any idea when this command will be migrated to the new server model?

raphjaph commented 3 months ago

It's very low priority right now because you can easily emulate that command by just doing:

 curl http://0.0.0.0:80/output/906873871102f5e54f8b8b21c8c9193f21c87c49cfc9e96ea0ae55317ddf840a:0 -H "Accept: application/json"

which returns:

{
  "address": "bc1pfg3a9kqup6r072v88dv70zzd494fnhl03k5a58vye9hwkakp7dgs3rte2e",
  "indexed": true,
  "inscriptions": [
    "906873871102f5e54f8b8b21c8c9193f21c87c49cfc9e96ea0ae55317ddf840ai0"
  ],
  "runes": {},
  "sat_ranges": [
    [
      1156381000177136,
      1156381000177682
    ]
  ],
  "script_pubkey": "OP_PUSHNUM_1 OP_PUSHBYTES_32 4a23d2d81c0e86ff29873b59e7884da96a99dfef8da9da1d84c96eeb76c1f351",
  "spent": false,
  "transaction": "906873871102f5e54f8b8b21c8c9193f21c87c49cfc9e96ea0ae55317ddf840a",
  "value": 546
}
raphjaph commented 3 months ago

I'd be happy to review a PR that makes that change though :)