Why can't I find any resources on how to mint ordinal NFTs via code?

[warpanomaly]

I have spent a few days now looking into how to mint ordinal NFTs. I am a hobbyist developer so I consider myself pretty tech literate and ordinal NFTs are NOT user friendly lol. What's even more concerning is that ordinal services never provide a code example. They usually make you upload an image or piece of text to a webpage, pay an invoice QR code with the lightning network, wait (a long long time), and eventually receive an ordinal NFT to a btc taproot address. This doesn't make sense. Why can't I find a script on Github and do this myself? Doesn't minting an ordinal NFT require the simple construction of an envelope transaction like: 

Code:

OP_FALSE 
OP_IF
    OP_PUSH "ord"
    OP_PUSH 1
    OP_PUSH "text/plain;charset=utf-8"
    OP_PUSH 0
    OP_PUSH "Hello, world!"
OP_ENDIF

Assigning 1 satoshi to the output, and running the command? Why has no one written out a self contained script that mints ordinal NFTs?

[1714632868]

1714632868

[1714632868]

1714632868

[1714632868]

1714632868

[1714632868]

1714632868

[vjudeu]

Assigning 1 satoshi to the output, and running the command?

You can assign one satoshi, or even zero satoshi, to some output, but miners will not include those transactions into a block, because of the dust limit. If you would have one or zero satoshi in a spendable output, then what fee would be needed to spend it?

Why has no one written out a self contained script that mints ordinal NFTs?

Because a lot of people are against Ordinals, when it comes to their current implementation. There should be a separate sidechain, focused on cloud storage, to achieve such things, and to leave more space for regular payments. Because if you want to push data on-chain, then why do you need any coins for that?

And if you want to connect any data with your coins, then you can do so with commitments, that would be cheaper, because no additional on-chain bytes will be consumed. Which means, if your Taproot address for your Ordinal would be bc1pscu742m5eyt6vwzl62fjugy9mj5yq8pgk674qc2x44892t3zjqfs3ca78z, then it means you can just use "8639eaab74c917a6385fd2932e2085dca8401c28b6bd506146ad4e552e229013" as R-value of your signature, in any address type you want, and then your data will be connected with that signature.

[BlackHatCoiner]

You can assign one satoshi, or even zero satoshi

Just out of curiosity, is there a zero worth UTXO? I cannot find any results.

There should be a separate sidechain, focused on cloud storage, to achieve such things, and to leave more space for regular payments.

The best selling point of Ordinals is that they are stored on the main chain, which is the most secure and censorship resistant. That somewhat guarantees there will always be online peers that act as seeders. Migrating to a sidechain does not guarantee that.

[vjudeu]

Just out of curiosity, is there a zero worth UTXO? I cannot find any results.

https://mempool.space/tx/47c3ffaac3f64dff83131a429f9de40c58fee3ad0334468aed5e24c4b4bbda61

That somewhat guarantees there will always be online peers that act as seeders.

This is true here and now, but in the future, it can be changed. Because each time when something is sent as fees, the new coinbase transaction starts a new "chain of signatures". Which means, if you want to migrate transactions from one chain to another, then you have to follow signatures only to the nearest coinbase transaction. Because then, it could be made from original fees, or from any other fees, which means, it may be possible in the future to discard the chain of signatures, after the nearest coinbase transaction, if Ordinals or other abuse will force full node operators to do so, and to optimize some things in some future model (for example UTXO-based model).

[warpanomaly]

This is true here and now, but in the future, it can be changed. Because each time when something is sent as fees, the new coinbase transaction starts a new "chain of signatures". Which means, if you want to migrate transactions from one chain to another, then you have to follow signatures only to the nearest coinbase transaction. Because then, it could be made from original fees, or from any other fees, which means, it may be possible in the future to discard the chain of signatures, after the nearest coinbase transaction, if Ordinals or other abuse will force full node operators to do so, and to optimize some things in some future model (for example UTXO-based model).

Are you sure about this? I think the mining nodes would still have to keep an entire transaction history. Nodes that sync from the genesis block need every block to calculate/verify the hashes of every block leading up to the latest block. This requires at least some nodes to have every single block. This means that there can never be zero seeders for the entire bitcoin blockchain. Please correct me if I'm wrong. 

P.S. I looked into commitment signatures and I think this would be a great replacement for ordinals in the application that I plan on building.

[vjudeu]

Are you sure about this?

Maybe I should show an example, how to move some mainnet transaction into regtest.

First, pick some mainnet block, that can be migrated, for example 227836, and get its coinbase transaction: https://mempool.space/tx/0f3601a5da2f516fa9d3f80c9bf6e530f1afb0c90da73e8f8ad0630c5483afe5

Then, generate at least N-1 blocks, that has to be present before that. Because of network rules, I usually generate 1000 blocks at a time:

Code:

generatetodescriptor 1000 "raw(51)#8lvh9jxk"

But it can be done faster, if you have custom software, because you can generate "the maximum amount of blocks" if you keep putting the earliest possible time in your blocks (the difficulty in regtest is left unchanged, so you can do that).

Also, because all coins are sent to OP_TRUE, it will be possible to reproduce my example, no matter, what block headers you will construct.

Of course, if you generate 1000 blocks at a time, starting from the current timestamp, you may encounter this error:

Code:

CreateNewBlock: TestBlockValidity failed: time-too-new, block timestamp too far in the future (code -1)

To avoid that, you can change your clock, or use custom software, to put custom timestamps in your headers. Coinbase hashes will stay identical, even if you tweak your timestamps.

Sooner or later, you should get there:

Code:

getblockcount
227835

And then, just check the last block you produced, and submit a new block on top of that, with the coinbase transaction from the mainnet.

Code:

submitblock 00000020ec6e213d3dc91be62e1d9c938f50ff894509c6bcdfe300ac17ac5012c76cf560e074c0ffa900ae2bf25debe7ee43d201f438b66ce6d7c89fa59ee4338dc48b63ac204f51ffff7f20000000000201000000010000000000000000000000000000000000000000000000000000000000000000ffffffff2703fc7903062f503253482f04ac204f510858029a11000003550d3363646164312f736c7573682f0000000001207e6295000000001976a914e285a29e0704004d4e95dbb7c57a98563d9fb2eb88ac0000000002000000010101811a9245cfae75af3f2fb5ebebb35ee25dfee53b74afac6a45be242bbab40000000000fdffffff01e073a39400000000015100000000
getblockcount
227836
getblockhash 227836
210573a3315d3ba36edbf728e15f748a1328a9ad40560489c70b6d311517532b
getblock 210573a3315d3ba36edbf728e15f748a1328a9ad40560489c70b6d311517532b
{
  "hash": "210573a3315d3ba36edbf728e15f748a1328a9ad40560489c70b6d311517532b",
  "confirmations": 1,
  "height": 227836,
  "version": 536870912,
  "versionHex": "20000000",
  "merkleroot": "638bc48d33e49ea59fc8d7e66cb638f401d243eee7eb5df22bae00a9ffc074e0",
  "time": 1364140204,
  "mediantime": 1325892379,
  "nonce": 0,
  "bits": "207fffff",
  "difficulty": 4.656542373906925e-10,
  "chainwork": "000000000000000000000000000000000000000000000000000000000006f3fa",
  "nTx": 2,
  "previousblockhash": "60f56cc71250ac17ac00e3dfbcc6094589ff508f939c1d2ee61bc93d3d216eec",
  "strippedsize": 266,
  "size": 266,
  "weight": 1064,
  "tx": [
    "0f3601a5da2f516fa9d3f80c9bf6e530f1afb0c90da73e8f8ad0630c5483afe5",
    "ced3a8562bd17e22598beee00724b3a74a3f1670537f6647943d3a6a1f1e49e1"
  ]
}
decoderawtransaction 01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff2703fc7903062f503253482f04ac204f510858029a11000003550d3363646164312f736c7573682f0000000001207e6295000000001976a914e285a29e0704004d4e95dbb7c57a98563d9fb2eb88ac00000000
{
  "txid": "0f3601a5da2f516fa9d3f80c9bf6e530f1afb0c90da73e8f8ad0630c5483afe5",
  "hash": "0f3601a5da2f516fa9d3f80c9bf6e530f1afb0c90da73e8f8ad0630c5483afe5",
  "version": 1,
  "size": 124,
  "vsize": 124,
  "weight": 496,
  "locktime": 0,
  "vin": [
    {
      "coinbase": "03fc7903062f503253482f04ac204f510858029a11000003550d3363646164312f736c7573682f",
      "sequence": 0
    }
  ],
  "vout": [
    {
      "value": 25.06260000,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 e285a29e0704004d4e95dbb7c57a98563d9fb2eb OP_EQUALVERIFY OP_CHECKSIG",
        "desc": "addr(n2Ah6YcQjuDCkLJ5YKuRKDLMEsLSPhKwWQ)#2l2jtden",
        "hex": "76a914e285a29e0704004d4e95dbb7c57a98563d9fb2eb88ac",
        "address": "n2Ah6YcQjuDCkLJ5YKuRKDLMEsLSPhKwWQ",
        "type": "pubkeyhash"
      }
    }
  ]
}
decoderawtransaction 02000000010101811a9245cfae75af3f2fb5ebebb35ee25dfee53b74afac6a45be242bbab40000000000fdffffff01e073a39400000000015100000000
{
  "txid": "ced3a8562bd17e22598beee00724b3a74a3f1670537f6647943d3a6a1f1e49e1",
  "hash": "ced3a8562bd17e22598beee00724b3a74a3f1670537f6647943d3a6a1f1e49e1",
  "version": 2,
  "size": 61,
  "vsize": 61,
  "weight": 244,
  "locktime": 0,
  "vin": [
    {
      "txid": "b4ba2b24be456aacaf743be5fe5de25eb3ebebb52f3faf75aecf45921a810101",
      "vout": 0,
      "scriptSig": {
        "asm": "",
        "hex": ""
      },
      "sequence": 4294967293
    }
  ],
  "vout": [
    {
      "value": 24.93740000,
      "n": 0,
      "scriptPubKey": {
        "asm": "1",
        "desc": "raw(51)#8lvh9jxk",
        "hex": "51",
        "type": "nonstandard"
      }
    }
  ]
}

See? It is valid, and instead of 1MejoVXRvsmwyDpTpkw3VJ82NsjjT8SyEw mainnet address, you have n2Ah6YcQjuDCkLJ5YKuRKDLMEsLSPhKwWQ regtest address. And because a lot of altcoins just copy-pasted Bitcoin code, you can migrate their coinbase transactions as well.

[seoincorporation]

I would recommend to read the ordinals BIP to understand how it works:
https://github.com/ordinals/ord/blob/master/bip.mediawiki

And if you want the full tech information, you can see the docs on the main ordinals site:
https://docs.ordinals.com/introduction.html

And that site you will understand how to work with ordinals step by step, and the limits of the technology.

You mentioned the sites that make ordinal don't have their code open source, and that's because anyone can code it's own program with the current info in the docs.

And one last source of ordinal info is Bitcoin-Knowledge repo:
https://github.com/vondas-network/Bitcoin-knowledge#ordinals

[warpanomaly]

See? It is valid, and instead of 1MejoVXRvsmwyDpTpkw3VJ82NsjjT8SyEw mainnet address, you have n2Ah6YcQjuDCkLJ5YKuRKDLMEsLSPhKwWQ regtest address. And because a lot of altcoins just copy-pasted Bitcoin code, you can migrate their coinbase transactions as well.

Fascinating... I'm surprised that there's away around storing the entire blockchain history. Thanks for the post.

[warpanomaly]

I would recommend to read the ordinals BIP to understand how it works:
https://github.com/ordinals/ord/blob/master/bip.mediawiki

And if you want the full tech information, you can see the docs on the main ordinals site:
https://docs.ordinals.com/introduction.html

And that site you will understand how to work with ordinals step by step, and the limits of the technology.

You mentioned the sites that make ordinal don't have their code open source, and that's because anyone can code it's own program with the current info in the docs.

And one last source of ordinal info is Bitcoin-Knowledge repo:
https://github.com/vondas-network/Bitcoin-knowledge#ordinals

Nice! Thanks for the resources! I will dig into this.