The Bitmap Standards I've just published bitmap GitHub, with the refined Standards for Districts and Parcels. It serves to clarify any grey areas. github.com/Blockamoto/bitmap If there are any questions that cannot be answered by the wording of these two standards, then there is still work to do. You can read my rationale in the audit branch, including pages for standard and non-standard rules in historic indexer audits.

Look forward to tomorrows update, it's getting good! 🫡 It's the Transaction locator index, with some major improvements on design, functionality, and exploration, including bitfeed.live style visualiser for blocks and an improved mempool.space visualiser for transaction flows. Turn your X notifications on from me 🔔

Ten more votes and we'll be in the top 100! Vote @blockamoto and @BitmapSunset and any other bitmapper you think deserves it! 🫶🏼 #bethebitmap

Introducing Gateway... I've been building a new kind of Bitcoin client. One that ANYBODY can run regardless of storage. Fetch only what you need, when you need it. On-demand, directly from Bitcoin peers. This is at the heart of Gateway. Sparse-by-default deep on-demand p2p-Bitcoin indexer. Now, I recommend you feed this post your favourite AI and have it talk to you directly about it, because I'm about to get into the weeds. And I'm very excited, so it's probably better you ask your AI how this applies to you, rather than leaving a comment that it's too complicated or that you don't understand. With that being said, if you're happy to go hardcore old-school style, and actually... read the thing, here it is! BITCOIN PEERS Traditionally, Bitcoin clients sync nodes by requesting blocks from other peers one-by-one, from zero. This is somewhat impractical for everyday users. Gateway does things differently. You can certainly sync the entire blockchain using Gateway, and become a full Bitcoin Node, and a useful Bitcoin Peer. You can even bring your existing Core node and plug it in if you already have one. But that's not the interesting part. The interesting part is that you don't need that. Seek data directly from Bitcoin Peers, on-demand. ON DEMAND Unlike Core, Gateway does not require you to sync the entire blockchain. You can sync any range, or even just type in a block number in the top bar to fetch the block from a Bitcoin peer directly. This approach is extremely useful for Blocks, but it has some limitations. Transactions (and thus, inscriptions) cannot be resolved directly, without knowing the block number. The latter part of that sentence is the important part. Gateway adds a schema that allows you to type "{tx}.{block}.bitcoin" and resolve a transaction directly from a Bitcoin peer. You can replace {tx} with either tx-hash, or tx-index (which is a new schema for Gateway), and {block} with either block-hash or block-height. For example: 0.0.bitcoin This becomes relevant for inscriptions. An inscription ID is simply: {tx-id}i{inscription-index} So you can resolve inscriptions by including block-number in the scheme: {inscription-ID}.{block}.bitcoin If you know the transaction index, you can even use that instead of transaction ID in inscription ID. That means, so long as you know the block number, any inscription can be resolved on Gateway, on-demand, by asking a Bitcoin peer directly. ORD When it comes to Ord, this is an extra layer on top of Bitcoin. It is an indexing system that takes Bitcoins already heavy data store, and adds its own index that can take roughly a week to sync. For the everyday user, this is not practical. Whilst I've demonstrated how we can fetch inscriptions directly from Bitcoin Peers without Ord, you need to know block number, and the standard in Ord is to use inscription ID, sat number, or inscription number as the key reference. I've added block in the Gateway schema as a useful primitive that enables purely on-demand inscriptions from Bitcoin peers, but that isn't the current standard. INDEXES This is where you can build your own data-store directly from Bitcoin data originated through Bitcoin peers, and either become a useful participant of the network, or take what you need privately. The baseline index is Bitcoin Blocks. However, you do not need that to resolve the other indexes. Each index has an "ephemeral" option, which means to seek the blocks you require from peers, strip the data you need, and discard the blocks. This is useful if you're running this on your everyday computer, and can't be spending so many GigaBytes on Bitcoin. For example, you can index Bitmap without storing a single block. The indexes are generally layered, so you can choose what you would like to index and when. If you index Bitcoin Blocks, you will be asked if you also want to index the other downstream indexes in parrallel, since it would be quicker to do that than re-run the index. If you already have a Bitcoin Node, you can build other indexes on top of that. But you don't have to have the Bitcoin blocks to sync inscriptions, Bitmap, or any other index we implement. Now, this is still some heavy lifting, but once we start activating the Gateway peer network, we can supercharge these capabilities. GATEWAY PEERS Gateway users can connect to each other in a peer-to-peer network, just as in Bitcoin. That means that, whatever data you need, you can ask Gateway peers directly and skip indexing directly from Bitcoin data, with Bitcoin as the hashed proof verification layer. So, anything your Gateway node doesn't know, or is impractical for you to find through Bitcoin peers, can be served by Gateway peers. This vital peer layer can become more useful as we start adding other cases for the Gateway peer network, for example, you could opt-in to become a persistent relay for a Bitmap or Ord gaming webRTC layer. We can even serve this p2p mesh layer to websites and ordinals over the web, so in the future, you will be able to connect to gateway from a website, or from an Ordinals inscription. For now though, it requires the Gateway client. But the dream is that you can become a useful OR private participant in Gateway from different angles. LONG STORY SHORT A sparse-by-default on-demand bitcoin node, with full-range indexing and p2p sharing with gateway nodes. EARLY RELEASE TESTERS I am seeking early testers who are happy to put the client through the ringer, vet the data, or just try and break the thing so we can make sure we ship a proper robust client. You can comment on this post if you're interested, and I'll share details when it's ready for testing. At this stage, I just wanted to let you know that I have a client, it's working, it's almost ready for testers. WHAT NOW? This is just one of the things I've been working on and excited about recently, but it's the one I think is the most important in terms of vital infrastructure that can benefit the entire stack from Bitcoin peers to Bitmappeers. Stay glued to my timeline for more! 👀 Comment if you want to get involved. 💬

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!