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/ : full block hex for 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/. 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…