The owner of an inscription can create child inscriptions, trustlessly establishing the provenance of those children on-chain as having been created by the owner of the parent inscription. This can be used for collections, with the children of a parent inscription being members of the same collection.
Children can themselves have children, allowing for complex hierarchies. For example, an artist might create an inscription representing themselves, with sub inscriptions representing collections that they create, with the children of those sub inscriptions being items in those collections.
To create a child inscription C with parent inscription P:
- Create an inscribe transaction T as usual for C.
- Spend the parent P in one of the inputs of T.
- Include tag
OP_PUSH 3, in C, with the value of the serialized binary inscription ID of P, serialized as the 32-byte
TXID, followed by the four-byte little-endian
INDEX, with trailing zeroes omitted.
NB The bytes of a groestlcoin transaction ID are reversed in their text representation, so the serialized transaction ID will be in the opposite order.
An example of a child inscription of
OP_PUSH "Hello, world!"
Note that the value of tag
3 is binary, not hex, and that for the child
inscription to be recognized as a child,
000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1fi0 must be
spent as one of the inputs of the inscribe transaction.
Example encoding of inscription ID
And of inscription ID
3 is used because it is the first available odd tag. Unrecognized odd
tags do not make an inscription unbound, so child inscriptions would be
recognized and tracked by old versions of
A collection can be closed by burning the collection's parent inscription, which guarantees that no more items in the collection can be issued.