Exploring a Bitcoin Quantum Kanarie : Post 3

It's been a while since my last post in this series, so lets start off with a link to each of my previous two and a half posts.

Part 1
Part 2
- Part 2B

I've continued to work on the idea, and made a lot of progress, but it now seems likely I may need to abandon the little project not because it's a lot of work (it isn't), but because I'm using up a lot of SD storage already, and will need to use even mode if I would like to do this seriously. But let's not get ahead of myself. I've put all of my work so far on github here and will continue to do so.

I'm planning to 'at least' complete the project with more code that someone else might use to post daily quantum kanarie posts on HIVE, or if someone can donate me 8TB or more of relatively fast external storage for running my scripts plus a number of core nodes, I'll run it myself. My currently single home server has 6TB of storage (4T + 2T), 5TB of what I need to alocate to other purposes. I'll get back to this at the end of my post.

Right now I've condensed a wide range of simpler scripts into two more complex ones. The first script, unimaginatively called btcqc1.py is the script that talks to the local bitcoin core node and fetches and processes blocks to extract different events. The script isn't perfect; lots of transactions are not trivial to parse, so some pubkeys are missing. I won't repeat the README too much, but the first script generates a number of event files each with its own types of events:

stripped.log : Receive and spend events
pubkey.log : Mappings between addresses and public keys
trigger.log : On incremental runs, hits that triggered the watchlist
debug.log : When run in debug mode, events about transaction inputs that didn't resolve to public keys

The second script with the equally unimaginative name btcqc2.py doesn't communicate with the core node. It just processes the event files, on init multiple times for memory usage reasons, and produces (updates to) the watch list.

Aliasses and multisig

Most of the work I've had to do since my last post revolved around aliasses and multisig.

It is important to realize that while ECDSA has remained the same, bitcoin has gone through a lot of development over the years. In the beginning bitcoin addresses didn't exist and the public key was used as such. Then addresses came into existence, but at first public keys werent compressed yet, so addresses used back then were derived from the uncompressed keys. Then public key compression was introduced. Later new address types were introduced, one of them being just another encoding of the same addresses, and enenthough these addresses all rever to different entities as far as the chain is concerned, in terms of QC exposure of the public keys, they are to be treated the same.

Next to this, if multi sign is used in an input, not just the the address in question and its linked funds are exposed through the used signing keys, but also the address that derives directly from that public key, if that key was ever used like that.

trigger.log

While there is a lot to tell about the other files too, we discussed a lot of it in my previous posts, at least in concept. The trigger.log file is the interesting output most usefull for a kanarie service for bitcoin. A rather noicy kanarie at this point to be frank. So lets look at a chunk of the content of such a file.

TRIGGER 1ModAH7GL3WgDKuUKqAdm7SMrm2YZMuqSB 2025-02-05T16:17:10 0.000995 882420 1635 pubkey 0.6504349999999982 2024-12-12T10:11:08 2025-01-29T12:09:35 2025-01-29T11:42:25
TRIGGER 1Kn92MBVPXYQqLqEDEAnJbqqTL3HBtzShw 2025-02-05T16:17:10 0.00112622 882420 1640 pubkey 0.0024505599999999996 2024-03-08T10:30:03 2025-01-29T10:53:43 2025-01-26T11:50:41
TRIGGER 1KkwWTGTAsVUR71BvFqNoLnrgTFvJ6r9vn 2025-02-05T16:17:10 0.000507 882420 1640 pubkey 0.0027327999999999966 2024-07-31T17:18:15 2025-01-29T12:09:35 2025-01-29T07:47:59
TRIGGER 1EbA1AZurGzYEFY3w83rGfJQkiQerbQuY2 2025-02-05T16:17:10 0.00096 882420 1640 pubkey 0.002248380000000066 2024-02-22T21:26:58 2025-01-29T12:09:35 2025-01-28T23:44:53
TRIGGER 1Hbf7wwFEZq3TJTZJraJ7u6kWYcWLTcyDV 2025-02-05T16:17:10 0.00304214 882420 1644 pubkey 0.044080610000000006 2025-01-24T09:49:35 2025-01-29T12:09:35 2025-01-29T11:42:25
TRIGGER 1ModAH7GL3WgDKuUKqAdm7SMrm2YZMuqSB 2025-02-05T16:17:10 0.001891 882420 1644 pubkey 0.6504349999999982 2024-12-12T10:11:08 2025-01-29T12:09:35 2025-01-29T11:42:25
TRIGGER 1FLZyvP8CWrhYYdS1nehdwstfMpyJ3Tjbj 2025-02-05T16:17:10 0.00352553 882420 1644 pubkey 0.00106154 2024-12-22T18:21:34 2025-01-29T12:09:35 2025-01-28T13:41:14
TRIGGER 1GKSnhP1XmCjZpEyUoupWsm7c1o64seyow 2025-02-05T16:17:10 0.45636053 882420 1667 pubkey 21.436482810000182 2023-11-10T12:50:07 2025-01-29T11:12:04 2025-01-29T11:12:04
TRIGGER 115QpjWagPe8P2Maupa5cfYS56rFot59Qi 2025-02-05T16:17:10 0.17546426 882420 2206 pubkey 1.1321750400000004 2013-04-29T03:33:30 2021-03-25T04:01:37 2024-12-15T12:21:14
TRIGGER 339kMy4j9nMS2jhomBeDZCwfVoB9CKqFyY 2025-02-05T16:17:10 0.90046727 882420 2797 pubkey 36.45048881999974 2018-10-29T16:55:56 2025-01-29T11:12:04 2025-01-29T11:12:04

Let's zoom into one of the lines. Let's pick the bottom line and look at its parts:

TRIGGER : The type of event
339kMy4j9nMS2jhomBeDZCwfVoB9CKqFyY : The address of the signing key that this event refers to
2025-02-05T16:17:10 : The time funds were spent within the current snapshot range
0.90046727 : The amount that was spent
882420 : The block number where this transaction resided
2797 : The transaction number within the block
pubkey : The type of input this SPEND arose from
36.45048881999974 : The funds that were in this address before the current snapshot range started
2018-10-29T16:55:56 : When this pubkey was first referenced on chain
2025-01-29T11:12:04 : The last time before the current snapshot window that funds were deposited to this address
2025-01-29T11:12:04 : The last time before the current snapshot window that funds were spend from this address.

While thousands and thousands of such trigger events, and sandly that is what we are looking at right now, even for just hours long snapshots, overviews and time trends might be more usefull when looking if we can still construct some kind of a kanarie.

So right now, the next task I will look at is creating a third script (guess how I'll name it) that creates a stats post suitable for posting to HIVE.
I'm currently running the latest version of the scripts in init mode just to make sure everything is still working, and when that run is done, waht will take a few days, I'll do an incremental run so I can after that try out a single day incremental and run the third script on it.

I'll post the resulting report, plus an other blog post in this series when it's done.

Storage needs for running this structurally

While I'm not abandoning writing the code, and while it has been a great learning experinence and eye opener to just how pervasive key reuse still is within bitcoin users, its currently not very likely I will myself be runing the code as a kanarie service for reasons of storage.

When I started these efforts I had in mind I could make do with a 1 TB VM to run a bitcoin node and my scripts on. I recently bought myself a Minisforum MS-01 as a development system and home server, and this particular application was only meant as a side quest for what I was going to run on here.
I have a 4TB and a 2 TB SSD in this system and that's it.

Running a bitcoin core node takes up a little less than 800GB what is within the limits, but my event dumps, even when I'm not debugging, already take up almost one TB.

I might be able to manage with my 4TB SSD if I was to assign 2TB to my bitcoin node VM, but bitcoin isn't the entirety of the story. If I want to run a usefull kanarie service I should at least consider that exposure of signing keys on hard forks of bitcoin also expose those same keys on the bitcoin network.

I'm not entiraly sure of how accurate it is, but so far I have the following list of hard fork chains that I think a usefull kanarie service should include a node for.

Bitcoin Cash (BCH): Block 478558
- Bitcoin SV (BSV): Block 556767
Bitcoin Gold (BTG): Block 491407
Bitcoin Diamond (BCD): Block 495866
Bitcoin Private (BTCP): Block 511346

If we assume a full node of each of these chains is about the same as bitcoin, and if we assume that if I make sure to truly treat them as hard forks with a shared first half,
running all of these will require rougly 1.3TB per chain, so that would be 1.8 TB for bitcoin plus 5 times 1.3 TB for the hard forks, adding up to about 8.3TB that I don't have.

So unless someone wants to sponsor me something like a , I'm basicly not going to structurally run a quantum computing kanarie service for bitcoin.

Because it is more likely one of you would like to run a kanarie service yourself than would want to sponsor me a big and fast external SSD or something better to run six full nodes plus my scripts on, I've made my code available on github and will continue to do so.

I think I might try running my code for one or two times with BCH included. not sure yet, but it will just be to make the code ready for multi-chain, and to gain more insights. I might even (seperately) have a look at LiteCoin just to see if there is any cross exposure there, what might lead to some interesting insights. But as for structurally running a kanarie service, I think for now at least it's not something I'll likely end up doing any time soon.

If you are already running multiple core nodes on your system and are interested in maybe running a kanarie service on that system too, wait a little for my stats posts and reach out to me if you would like to coordinate.