Lockchain protocol

Efficient transaction and data discovery on Bitcoin using the nLockTime field in a new way Check out this repo: https://github.com/softmatsg/btc-nlock-lighthouse. It has the reference implementation for the Lockchain Protocol, which is a lightweight meta-protocol for Bitcoin. This thing can help with O(1) transaction discovery while keeping on-chain storage costs low. Feel free to share your thoughts! You can find the writeup here: https://arxiv.org/pdf/2512.16683

I skimmed the writeup and the repo, and the core idea is actually pretty clean, it seems you're not inventing a new data dumpster, but that you're basically giving indexers a cheap "hey, look here" flag by packing a magic/type/variant/sequence into nLockTime using a past-timestamp range that's still consensus-valid. If it gets people away from parsing half the blockchain's witness just to find a handful of protocol txs, that's a real win for hobbyist indexers. One nit though: the "O(1)" claim is only true relative to payload size, you still have to walk headers over time, but it does mean you can prefilter without touching scripts or witnesses unless the 4 bytes match, which is the whole point. So, the practical questions for me are wallet behavior and policy: do you require at least one non-final nSequence to make locktime meaningful, and if so are you accidentally dragging RBF semantics into places people didn't expect?

Thank you for the kind words. Yes, that is exactly what the protocol is about. The POCs are there to provide examples of how it can work, but of course, they are very simple and not really that interesting. They were fun to code, though. That said, libbitcoin version I used is broken, there were many gotchas (different ones in each POC) and a lot of swearing involved. I could have made that clearer. The O(1) claim refers to constant time relative to the transaction size, rather than constant time relative to the blockchain history. You need to parse 4 MB of data just to check if there is a relevant ordinal inside. While you must still check every transaction in every block, this applies to all protocols. Also, you don't necessarily need to match all 4 bytes; matching the first byte is enough to identify your custom txs (though there might be more false positives, and not much efficiency gain). Do you mean requiring the locktime to be consensus-enforced? That isn't necessary. In the protocol, the field acts as a passive data carrier, so consensus enforcement is not required for the protocol to function. If nLockTime is set properly within the gap, the tx is valid regardless of the nSequence, and the indexer reads the locktime anyway. RBF is not accidentally forced because the protocol works perfectly with 0xFFFFFFFF nSequence. I mentioned RBF only to demonstrate that the protocol is compatible with modern wallet policies, which often enforce RBF and therefore require valid past timestamps.