Gateway uses something called blocators, which stands for Bitcoin Locators (previously BPS). I've published the specs here: github.com/Blockamoto/blocat… It's looks like: offset.output.tx.block First satpoint of first output of first tx of second block: 0.0.0.1 I'm drafting a BIP. WHY USE BLOCATORS? When working with Bitcoin peers, you can only ask them for blocks. Not specific data inside. That means, to use transaction ID's, you must have that block already, or know what block to ask for. In practical terms, this usually requires you to have a full node, since you don't know which block it is. Since blocators point to the exact location, you can skip running a full node entirely and fetch data on-demand. This means you don't need to have almost a terrabyte of storage available to work directly with Bitcoin. I'm building Gateway indexes almost entirely on blocators. You can run transaction locators which indexes txid's against tx locators. That means a translation from existing transaction hashes to blocators. This enables the use of traditional inscription ID's within Gateway. This way you can also export indexes that use traditional ID's instead of blocators. However, I'm so confident in blocators that I'm making it the default way to index with Gateway. It's going slightly against the grain, but with a bridge between methods. But put it this way... If ord used blocators for references like recursion, for example, there would be almost no need to use traditional inscription ID's. This is a system I wrote independently of @rodarmor for Gateway (and has been perculating for a long time), but later came to find that Casey proposed literally the mirror image of blocators in an early draft of the ord protocol. Personally, I think Casey's biggest mistake is not using a system like this to begin with. It means that for on-demand systems like Gateway, we have to have a translation index from transaction ID's to blocators (or have the raw blocks themselves) to be able to resolve an inscriptions directly from Bitcoin peers. So that's why Gateway uses inscription locators instead of inscription ID's, because we can resolve them on-demand from Bitcoin peers. But the limitation is simply that recursion and any reference to inscription ID won't work without having the txid locator index or raw block index. So I'm going all in on blocators. I'm writing a BIP for Bitcoin itself, and at some point I'll propose it for ordinals itself as an alternative to ID's. For now, we just prove its usefulness in Gateway. Any questions, please ask! --- THE GATEWAY BITMAP UPDATE IS ON ITS WAY Full Bitmap District and Parcel Indexing and exporting. It will ship with a much smoother user experience for the timeline, arming of tracks for indexing, control buttons, and general usability improvements. You can index tracks in parrallel now, with prompts when that is the best thing to do, such as when you index Bitmap or inscriptions, it will now prompt you to also arm the transaction locator track. Bitmap Chain will be held off until a 0.8.x update. The design is final, but there are some serious considerations I want to put to the community before I roll it out. You can view the current design on the "chain" branch of the bitmap github: github.com/Blockamoto/bitmap… I'm not sweating it right this second, my focus is finishing up 0.7.x versions. After the Bitmap v0.7.8 update, the v0.7.9 will be most likely be the last 0.7.x update for deeper Ordinals indexing and usability features, which will land us nicely on v0.8.x, where my intent is validation features, a full index building engine, and tightening the ship, testing it compulsively until we are ready for the 0.9.x versions, where I will begin implementing Gateway p2p features for on-demand index sharing. Where a bitcoin node will not get you the answer, in 0.9.x versions onwards, Gateway peers shall bridge the gap. And I intend to bridge Gateway and Bitcoin peers to web hopefully in 0.9.x. One day, even mobile. When that's done, I think we'll be ready for primetime, which is v1! At that point, I may change the name to Bitcoin Gateway just so I can appeal to plebs. If we ever add wallet features, it will be after v1, but I'm not rushing to do anything like that as it's not the main goal, and there are huge risks there. I may even keep this client focused solely on serving data. --- Anyway, that's my word for now! Stay notified for the Bitmap update 🔔

It's time to get excited about ORD and BITMAP again. Why? Because /r/block just got merged!! What does this mean? We now have full block data through recursion!! What problem does this solve? TL;DR: we can now accurately draw Bitcoin Maps! Up until this merge, it has been impossible to resolve transaction data within an inscription without knowing the txid. That means, the full promise of Bitmap has been impossible on-chain via ord, because we cannot represent accurate transaction data. THE SOLUTION /r/block/<query> : full block hex for <hash or height> One week ago, I submitted a PR issue to Ord that would allow you to fetch full block hex with one call. It was after working with Astra to close the gap. Originally I was going to build fetching txid from blocks, but it became clear that this would lead to thousands of recursive calls per block. Astra suggested using /r/block instead to get the full block hex. With one call, you get all transaction data from the block. I wholeheartedly agreed. It just made sense. I put Astra to work and it was done within 20 minutes. I tested it on my node and it worked a charm, then I submitted my PR as an issue to ord. Last night, Casey merged /r/block/<query>. So now we have full block and transaction data! This is a game-changer for bitmap. So this morning, I'm working on something to show what is now possible. See image for a clue. But more importantly, the endpoint is available now for you all! This is truly an exciting moment, and will open a dam of development on Ord and Bitmap. Use it wisely, and build procedurally. Please show Casey some Bitmap love on this historic merge. Happy building!

I'm speaking at 4:20pm at the Kawaii stage today at @NFCsummit! Live Forever on Bitcoin. See you there, and come say hi. It'll be nice to hang out.

Did you know, there are examples of multiple bitmap districts inscribed on the same sat? This is because there was never a condition specifying that the sat should be unique, and it's what indexers have been running with since. Automated inscribers sometimes use the same sat for multiple attempts to inscribe a bitmap, and this leads to them getting multiple, but on the same sat. It's an interesting edge case, as it means these districts are intrinsically linked and cannot be separated. If you send one, you send them all. If I were to design bitmap again from scratch today, I would make sure it can't be on an existing Bitmap sat, however I can't do that so it is what it is. However, it leads to an edge case in signal theory, which I've had to come to terms with. If you signal from one of these bitmap sats, one signal may amount to multiple, based on how many districts are on the sat. The obvious problem is that you might want to signal independently from each district, not one signal for multiple districts. This could be a little more problematic for districts that span multiple hoods, where the district signalled is outside the range of the district you are signalling. We have to go with it for now. It's the way the cookie crumbles. I cannot make changes to a consensus that holds so much weight by myself. However, one path is that we can raise this question as one of the first democratic issues of bitmap. It is possible that we can fix this edge case. It will not be too difficult to do this for all future districts from the point the decision is made. However, doing this retroactively will invalidate some districts, and validate other previously invalid ones. This will fix the issue where one send of a bitmap is actually a send of multiples, so the benefits of making this change may outweigh the drawbacks. The realistic case is that we index both realities, and let consensus emerge from indexer and product adoption. But I think we can also raise it as a referendum type situation within the signal, so we can see what version of Bitmap the community would rather see. It could become the first real test of our ability to collectively make decisions on serious issues that may affect Bitmappers and the integrity of the standard, but also, the first time Bitmappers get to decide individually which version is the one they support. The first true bitmap fork! Ultimately, products that run bitmap indexers (marketplaces, Metaverses) will have to choose one version, and currently the default indexing is that multiple bitmaps on sats are okay. Note. Things will stay the same for 99.99% of the bitmap index. I'll leave this here for now, but I wanted to start the conversation now, so you are all aware of the situation, and maybe soon after the signal starts, we will raise the issue in a town hall space and move towards inscribed proposals or acts for people to signal one way or the other.

You can play whatever game you like, so long as you don't speak for other people, as in using the word "we" when you mean "I".

BITMAP SIGNAL THEORY for HOODS and SECTORS At block 945,000, counting begins. Hood → Seats (2016 blocks) Sector → Elect + Capital (210,000 blocks) At difficulty adjustments, we count. At halvings, we score. ordinals.com/inscription/d9a…