blog

Cleaning up a couple of issues on Ladder script. Will publish release v0.24 soon.

Finding it a hard time with the TLA+ specs.

I took a few days off. I needed it. I will start to push on the projects again over the next few days.

Testing the new Wraith coinjoin protocol.

I haven't had time to work through the Ladder script tooling yet. I'm slowly progressing through the Wraith wallet for Bitcoin Ghost. Just building the L1 scanner for silent payments.

Fuzz tests complete. sendrawtransaction: 200,002 iterations 100% clean rejected. decoderawtransaction: 200,000 iterations 100% clean rejected.

Ladder script is almost finished. I have taken it as far as I dare to waste any further time on until it receives peer review. The fuzz testing is almost finished. I just need to walk through the engine and playgrounds and then I will publish and wait.

Wraith protocol is having an overhaul. I've decided to only ship two frontend products - Dashboard and Wraith Wallet. The Wraith protocol is being condensed into something similar to Samourai / Wasabi but decentralised.

Strategy selling Bitcoin. Saylors Ponzi scheme. Only time will tell with that one. I personally would stay clear.

So, it seems Knots may be going all in on BIP110. That is surprising. Core is being typical Core. One thing that i think most people saw coming was Citrea releasing a token. It's not a good look when Core associates are invested in it's success. I think the market is screaming for multiple node derivatives. Something different from the norm. Bitcoin Ghost is in a good place. All the foundations are solid. I have had four mainet nodes running for months now. The pool is mining well. The fact that it incentivises running a node and allows fine tuning of mempool and block policy should be enough to make users think about trying it. I'm still working on the frontend. I have redesigned the approach now - A node dashboard and a serperate wallet called Wraith. There is alot of tech being stacked into the wallet. May take a couple of months but I might be able to hit the July deadline for release.

Update for Ladder script. After lots of testing and patches i think i have everything stable. I'm just working through the docs and webpages again. The tooling (engine and playground's) will need updating. Then I think it's time to try and find some engagement. Maybe Delving or X. I could use some more eyes on this. I have probably missed something.

Have you ever built something knowing that when you have finally finished the initial product and have worked tirelessly and invested months of time, energy and thought - all whilst knowing, they will never accept this. It's a weird place to be. I thrive on problem solving and this is just that a big problem, with a logical solution. But it's scope is big. I will probably have to break this down into five BIPS for readers to accept. Thinking ahead, I am not looking forward to receiving abuse and rejection from everybody. How cruel a world this can be.

It's been a busy day. I'm currently working on test vectors.

Just working through the synthetic utxo re-org issue.

I've tried to follow the Vegas conference via socials to keep up to date. I watched the quantum debate featuring Hunter Beast. There were obvious outbursts with underlying tones of resentment. I can only empathise and try to understand all perspectives. One thing that stood out to me was Hunter Beasts comment regarding making BIP360 work for BIP110. I didn't really understand the reasoning as in my opinion BIP110 is stillborn at conception. Maybe he's seeing something I dont? Possibly just trying to gather support for his BIP as the BIP110 supporters are certainly loud when they want to be, I can undertand it's political use. It takes magnitudes of effort to even be considered for a softfork. Fair play. That said, could Ladder script be implemented within BIP110? I'd have to look at the most recent push to check.

Ladder script progress update. Code is almost at a point where i think it's safe to update docs and tooling. I've been working on the draft BIP. It's a giant pill to swallow, due to the size of the library. This is one of the reasons why I decided a core shim and library approach would work better, it's easier to review and modify. Just removing spend_index dead code and then I will be working through the docs today. They are a little outdated since the latest patches.

V0.19 released.

When people just wrote blogs of what they were building, those were the best times. You wrote unbiased. No instant audience. No statistics of how many likes or views someone scraped with a picture of their healthy lunch. Todays socials are horrendous. We should build a social site that just collates users blog posts and adds them to a timeline social feed. Users you follow fill your feed. You click the post you go to there blog. Maybe add an explore page for you to discover new users blogs. No bullshit. No applause. Just peer to peer updates on interesting builds or thoughts.

Almost there. Latest revision is looking better. Just running end to end tests now.

Due to multiple chainresets i need to sort the mining for Ladder script signet node. Just going to run a local instance to test signet peers. V0.16 has been released. I have almost closed all holes. More testing to do which may reveal things I have missed.

Version 0.14 released. I'm running alot of tx tests locally. Specifically checking every block types within txs funded and spent. Its an easy way to spot any errors from the patches. When i eventually finish closing all data embedding gaps I will update all docs and tools. Overall.

Pushing V0.13 now. Still more patches to follow.

I'm just working through a subset of smaller patches to tidy things up. V0.10 will be released soon. Tools still need updating to latest version.

Ladder script v0.7 released. It includes data embedding patches and a fundamental wiring of relays. A few more to follow.

I'm working through the arbitrary data embedding bugs. Currently end to end testing all tx block types.

There is a common theme across a few of the blocks. Pub keys causing arbitrary data embedding possibilities. The original inner merkle root fix seems to be the solution. There are a few smaller block types that are allowing this. I will patch today and release a new binary.

I found another bug in the Accumulator block. I think i can resolve it the same way I did with Multisig.

It is so frustrating when a fundamental error is realised. Any patch implemented then requires an entire follow up of documentation and stat edits. Working through the Multisig issue. New release will be ready later.

Found a data embedding opportunity with a multisig block on Ladder script. K of N. So N - K = Arbitrary data slots. I need to patch this. If I don't enumerate them. The unused N - K pubkeys don't need to appear on chain if the conditions commit to them with a root. MULTISIG conditions (committed at fund time): NUMERIC threshold K HASH256 pubkey_root = MerkleRoot(pk_alice, pk_bob, pk_carol, pk_dave, pk_eve) MULTISIG witness (revealed at spend, for a 3-of-5 spend by Alice/Carol/Eve): PUBKEY pk_alice + MERKLE_PROOF + SIGNATURE sig_alice PUBKEY pk_carol + MERKLE_PROOF + SIGNATURE sig_carol PUBKEY pk_eve + MERKLE_PROOF + SIGNATURE sig_eve For each revealed pubkey, check the Merkle proof against the committed pubkey_root, and verify the signature for each pk. >/= K signatures verified = SATISFIED. I'll check wire format. It will need a change in maximum N pk. Probably 16.

Overnight audit picked up a few issues on the Ladder script library. I'm working through these today.

Ladder script v0.4 pre-release is now live.

I have decided to integrate the config into the binaries. Also I will create a multinode signet and incorporate the seed node for discovery.

Ladder script Windows release is complete. Spinning up a new signet node on Linux to connect to our original seed node that the website uses.

Ladder script docs look OK. I still need to go through them with a fine tooth comb in case i have missed something. Currently working on getting Windows build passing CI/CD for release. When I have finished with the release I will try and build locally and test thoroughly as I had to use an older version of Ubuntu. When i get to this point I will trun my attention to the TLA+ tests. I tried to push the limits on a rented server but the memory was getting eaten. Anyone got a spare server to throw some tests at? Leasing servers is not cheap.

Sorting Git CI/CD checks for Ladder script. Then going to finalise a release for review.

Today i'm working my way through updating the Ladder script documentation. Im also taking a second look at Bitcoin ghost pool load balancing. More specifically the high and high/high limits and remedial actions.

I have realised there is ambiguity between a legacy RPC for createrung and the newer createtxmlsc. Sorting now.

Ladder script library is clean. I have forgotten to add the descriptor notation for PQ batch block. I will add this sometime today. Just working on the docs.

QABIO Playground is all working fine. Finally, it's time to clean the library.

5 Asics happily mining on Bitcoin Ghost - ~11.07 TH/s. I have smoothed out the stats so they aren't so volatile.

I had an idea regarding the Bitcoin Ghost mining pool ledger system. Currently it pays out the top 1000 miners by share. It does this on a per worker system. Im going to try and change it to a per address payout. This way, if a miner has multiple rigs/machines and they are using the same payment address it will combine all workers into a single coinbase payment. This condenses the coinbase and allows more individual miners the chance to be paid when we find a block.

I've added a new section to the Ladder script site - Quantum batch playground. This enables users to see how the batch payment works and test it. Just testing the Qabio playground. When that is complete I will be tidying library code and then moving onto the docs and web pages.

The quantum batch block test results. N=10 (tx vsize 980 vB, vB/input 98) N=100 (tx vsize 5,818 vB, vB/input 58.18) N=500 (tx vsize 27,319 vB, vB/input 54.64) N=1500 (tx vsize 81,069 vB, vB/input 54.05) Comparison to Ladder scripts' other models of PQ spending. N=10 SIG(FALCON) (tx vsize 4,409 vB, Cost/input 440.90 vB) QABI_SPEND (tx vsize 3,366 vB, Cost/input 336.60 vB) PQ_BATCH (tx vsize 978 vB, Cost/input 97.80 vB) N=100 SIG(FALCON) (tx vsize 43,638 vB, Cost/input 436.38 vB) QABI_SPEND (tx vsize 28,589 vB, Cost/input 285.89 vB) PQ_BATCH (tx vsize 5,818 vB, Cost/input 58.18 vB) N=500 SIG(FALCON) Impossible - Max inputs for standard tx size is 229 QABI_SPEND (tx vsize 141,091 vB, Cost/input 282.18 vB) PQ_BATCH (tx vsize 27,319 vB, Cost/input 54.64 vB) Clearly PQ_BATCH wins the simple application and size argument. QABIO has its place for enabling trustless multi party input aggregation, but it comes at a cost of higher tx sizes.

Testing quantum batch input txs on Ladder script. N=10, N=100, N=500.

It took some time but I finished COSIGN block. Still working on Quantum Batch.

Bitcoin ghost website - core page now complete. Slowly working through them whilst debugging Ladder script engine.

Ladder script has QABIO for multi party quantum batch sig inputs. But I've noticed that we can make batched inputs cheaper for just standard batched qauntum inputs. Working on implementing standard batched quantum inputs as a new block type to the library.

I have completed the first pass of Ladder script engine examples. A few bugs were fixed along the way. I now have a list of issues i need to work through before completing another pass.

After thinking deeply about the pool economics and payout scheme, I have decided to tweak it. I will now run a ledger based model. Top 1000 miners (shares contributed) will be paid via coinbase and then their shares reset. Any miner with remaining shares contributed will be carried over to the next block. If a miner doesnt contribute for over 7 days then they will lose their shares.

Working on Pool address and individual miner stat pages. Trying to keep it minimal but retain enough data for users.

Building the Ghost pool stats page. I'm very happy with how the Quasar hash visualisation has turned out. Still working through the Ladder script examples. I'm hoping to finish those today and move onto Qabio playground.

I've spent a fair few hours building a Quasar hash visualisation tool for Ghost pool. I will be adding it to the pool page later today and wiring it up to pool hash rate.

New index page is pushed to bitcoinghost.org. I will work on the site over the next two weeks between Ladder script and BG frontend works.

Working on a new theme for Bitcoin Ghost website whilst waiting for signet blocks to mine.

These engine examples are tedious to work through but also have revealed a few bugs in the library refactor.

Deployed the latest version of reaper that now filters Runes. It seems Knots attacks them via a different approach. Knots filters based on OP_RETURN size where as reaper uses the script signature. The latest test showed reaper filtered 34 more Runes txs than Knots.

Quantum safe vault example from the Ladder script engine. FUND - 127 vB { "txid": "2eb992da834f3dcb89ab80d434ce20ba25e13ab84e7a20465487a4feb05d4cd4", "hash": "0b810523426819af83d365d85b988bba1e0d033c1251268b00cfa09dd3efaf40", "version": 4, "size": 210, "vsize": 127, "weight": 507, "locktime": 0, "vin": [ { "txid": "3fcffcb79a8b0a8d889238ec8362b8eaffe6bb80f17dd00599714acd6beea8eb", "vout": 0, "scriptSig": { "asm": "", "hex": "" }, "txinwitness": [ "304402200d8e8de54193c89a957adc3adbdbbfca38c2214146313130231c0a0aaddf68f6022041a720e75e1cae5edd6ca5e03021183e764b76714202389d31ac64ff1e3fc28701", "031786c101e44077372663aa4d46a0d1111050ae03ecf01386b773f50810da3e4f" ], "sequence": 4294967294 } ], "vout": [ { "value": 0.002, "n": 0, "scriptPubKey": { "asm": "MLSC bdc96d15d2224bacad8c6fd1628d228e7fdfec25a557dd28e9259e57e72d593d", "desc": "raw(dfbdc96d15d2224bacad8c6fd1628d228e7fdfec25a557dd28e9259e57e72d593d)#0lvnqgj4", "hex": "dfbdc96d15d2224bacad8c6fd1628d228e7fdfec25a557dd28e9259e57e72d593d", "type": "mlsc" } }, { "value": 49.99799509, "n": 1, "scriptPubKey": { "asm": "MLSC bdc96d15d2224bacad8c6fd1628d228e7fdfec25a557dd28e9259e57e72d593d", "desc": "raw(dfbdc96d15d2224bacad8c6fd1628d228e7fdfec25a557dd28e9259e57e72d593d)#0lvnqgj4", "hex": "dfbdc96d15d2224bacad8c6fd1628d228e7fdfec25a557dd28e9259e57e72d593d", "type": "mlsc" } } ], "hex": "04000000000201eba8ee6bcd4a719905d07df180bbe6ffeab86283ec3892888d0a8b9ab7fccf3f0000000000feffffffbdc96d15d2224bacad8c6fd1628d228e7fdfec25a557dd28e9259e57e72d593d02400d030000000000d5e2022a010000000247304402200d8e8de54193c89a957adc3adbdbbfca38c2214146313130231c0a0aaddf68f6022041a720e75e1cae5edd6ca5e03021183e764b76714202389d31ac64ff1e3fc2870121031786c101e44077372663aa4d46a0d1111050ae03ecf01386b773f50810da3e4f000000000000", "is_qabio": false } SPEND - 508 vB { "txid": "37017fd5ffd9cff55f354ac9384c664fc5bcd190636218d82fe07c533ba3fd0b", "hash": "3ea0b3c10e1f60f9952f767ecbe34bc853ffd25d7303fb0365e0ede942ec5e97", "version": 4, "size": 1756, "vsize": 508, "weight": 2029, "locktime": 0, "vin": [ { "txid": "2eb992da834f3dcb89ab80d434ce20ba25e13ab84e7a20465487a4feb05d4cd4", "vout": 0, "scriptSig": { "asm": "", "hex": "" }, "txinwitness": [ "010200fd81030973e2e3d8f42cf0594c47fa6a4c35baa6c4e48640651b2e10156e173075859f59f5a7384f1024b5b7a6ca13f90676342d8e54c959534f4f3a1352c95bd9e2f95fc43f2b5f975a97364e61fde5ba1de80519d2eca21aa2d84b7302bc225aaad0db68b0795dd929955cd12a449ea3080dcf73d49ba0634df69e96976987813a6d74e02833611bae95d2aa42da88422cf90b8c5ffb8aece600ed499365194eeaf5ad9726246728d9109cb10d8dfbafe4803b110041b712726d9e205b7d181835eac239e5d211a258d0805c83e294e8d2e5f207ebb7e18f3ae414c24be6f948a4ae59528e77c1a7137f7be89eb72900ae74bd1f098b88814a7cac047e97c35d8ee21aaae6ee4415f45af811987a71dec70a1cb73682d58bf1098f7462f3c29584f76161551756916247d4ee84d6cea60b99c613e7005fb7619cf7c717c48fd68e60c4a2074212c3122b42ce2a1a84031f89e91a1c0dd2d461703878c899d2a008984a2471fd8356a03c8657c88b8b7185b0034527ad8d2caf459d4a54bf00028597e50d57eaefe3ff287d858077d2c1dabb24b9f6d801a43b2f54edfa00431e3005f82276a37eac7041d507432d0bbd7a80ffc6789f66c1ea19608d470252683da09f6cec4211d443ba82d826f38e8f0639ad0b55c107529d74c4bb5fd3a4684ef6c6a3067d0ec44bc1780edc896d006433621e729ef347f8648f589616b213c4df5dbc7037025b977f3a61553545cb06de1d30abe33e0ab862a375afc1543190c682c26d54011f9542217ebff5a60a01114f96728505c6aecc533cc27b3469359ce4c823cb20e156398e20216915786c5a65319b264af691ca638e567d3edbb2c80b6946c468d8c1145dbb80884a0ddfb6820dbda3b34d6d4b9586a99605958ef24ba8acd8691ceafddbed973512612c98b8923c3e8c13d18c62472960e39bc1e9782a7a8c104e636c2c366948f3601fbf859b64199b2662702b0514697a447d76d5ae96586a8df5f4094f6d8c15281954e183b89c9630949938874e7777c8142391d9970300d20b1c31cebab6ced6108122b88898f177a5ba41171c6747517be5370354553a4ce0918d4811790890f1a1d05314ae5b24d50d8a0c528a9b950c12feaaf0158dc988b8d201068081840deeb484c5d03d41bb23cda4b362ee7b4bd9885a165cc0635b05ad74329b27b51f64beed963b78933256e0b8a7426ec309c926054c6eaabe9d8a6a86ca878d99fb6a508c7c819cd8d7db8d6844e09a82024094fd9102395ca61cd20a1cad8f111a70dce08deb6fc5d4340107bb4ac640db7be9072730cf4d6d90d5ed202f6bda9a7ea5e38f39afbf95722a9a09d8cf45ef3c1e84edd7b07c1fbd1964c8df92271eeb25ea2952faec917eb0fd88dacd4fe1aa6c5ce5553f79cf8b45029a4ecfe90a824b14ee1216f9431104ba239063e97227fcd6c8d21262b968f2ba82085f6f8f391f73598d82627d8f0bd756b47d78cc55e197dd2b24170450bad975e9599b2a98c441da86f66230a60493217321648910e622084434ec3bf289eeeb1cfe5cf70e5d602f8a6a36d127dda24078486f84ad5b39cc432d10de7fdf79b6c9c8872ae9fffa1d065634dd2555e49e7760add64b8587b4b17841b2266c6e621b59cf512c1fcf95d15782a0ec368d3c68349dca96f5704dd5ee24d9ae98c9bf2fb322fc1559415282a4c6aa73c7c4e41b5c479dc2973056ede940a9688a91acd04fedd39c315849d0cd53667109562108f8a9c8b94b67042528ca7874d4ee457943e9a0f7c9fbfce4d118f78ac7aef4c6d9d82385907ce651dd3abea97527ee730f236ee2877633f68866b3683b9ede119cef387bbbe82b1ba9eaeea41e6c6ab51e7c0ec6aa5fb0c3a84ed3bbc9dac0d3ec56b62c8d7760ed5b0f187e12765254b2236e7f6a6e317348bfa346de5e3a7db47886cd10a42e35b8760e025d40d05c935fb9cf4164959c664beb505a5597ad2dbeab32a69f6aa64d25bd5d747e56e823cc2a7b5a4c90bfc4b5bc87965ce0eb4074b1c1e8db63b8ed1ec9d229c66e35eb65d3aa091e8821986756ab2f73fc86ee5ce2b88fed07fc7ba873ace1165013a94fa755f738fa52249213ed82d5c83828d640c8abcbe64586350b5c58f5c80a7fd39e93166aaaed20fffc5514f56fbe32cc570f3eab41ebca1cac77db849779ad70ca33896f964b080c0001011000000000", "00010400000200100cfd1027fe404b4c00000002a071da0d559dc0f533447c1e31a0d919e506f4a420027d116f4bdf707b283f24057d0dd22734cfc3745644fd1779051a6e27cf50fba73a6a082ab911bef6a478" ], "sequence": 4294967294 } ], "vout": [ { "value": 0.00199, "n": 0, "scriptPubKey": { "asm": "MLSC 5b108a24b17846ea987731b2f94c6bba096b2704fdbcb295d411eae997cef72d", "desc": "raw(df5b108a24b17846ea987731b2f94c6bba096b2704fdbcb295d411eae997cef72d)#um57xm2y", "hex": "df5b108a24b17846ea987731b2f94c6bba096b2704fdbcb295d411eae997cef72d", "type": "mlsc" } } ], "hex": "04000000000201d44c5db0fea4875446207a4eb83ae125ba20ce34d480ab89cb3d4f83da92b92e0000000000feffffff5b108a24b17846ea987731b2f94c6bba096b2704fdbcb295d411eae997cef72d01580903000000000002fd2406010200fd81030973e2e3d8f42cf0594c47fa6a4c35baa6c4e48640651b2e10156e173075859f59f5a7384f1024b5b7a6ca13f90676342d8e54c959534f4f3a1352c95bd9e2f95fc43f2b5f975a97364e61fde5ba1de80519d2eca21aa2d84b7302bc225aaad0db68b0795dd929955cd12a449ea3080dcf73d49ba0634df69e96976987813a6d74e02833611bae95d2aa42da88422cf90b8c5ffb8aece600ed499365194eeaf5ad9726246728d9109cb10d8dfbafe4803b110041b712726d9e205b7d181835eac239e5d211a258d0805c83e294e8d2e5f207ebb7e18f3ae414c24be6f948a4ae59528e77c1a7137f7be89eb72900ae74bd1f098b88814a7cac047e97c35d8ee21aaae6ee4415f45af811987a71dec70a1cb73682d58bf1098f7462f3c29584f76161551756916247d4ee84d6cea60b99c613e7005fb7619cf7c717c48fd68e60c4a2074212c3122b42ce2a1a84031f89e91a1c0dd2d461703878c899d2a008984a2471fd8356a03c8657c88b8b7185b0034527ad8d2caf459d4a54bf00028597e50d57eaefe3ff287d858077d2c1dabb24b9f6d801a43b2f54edfa00431e3005f82276a37eac7041d507432d0bbd7a80ffc6789f66c1ea19608d470252683da09f6cec4211d443ba82d826f38e8f0639ad0b55c107529d74c4bb5fd3a4684ef6c6a3067d0ec44bc1780edc896d006433621e729ef347f8648f589616b213c4df5dbc7037025b977f3a61553545cb06de1d30abe33e0ab862a375afc1543190c682c26d54011f9542217ebff5a60a01114f96728505c6aecc533cc27b3469359ce4c823cb20e156398e20216915786c5a65319b264af691ca638e567d3edbb2c80b6946c468d8c1145dbb80884a0ddfb6820dbda3b34d6d4b9586a99605958ef24ba8acd8691ceafddbed973512612c98b8923c3e8c13d18c62472960e39bc1e9782a7a8c104e636c2c366948f3601fbf859b64199b2662702b0514697a447d76d5ae96586a8df5f4094f6d8c15281954e183b89c9630949938874e7777c8142391d9970300d20b1c31cebab6ced6108122b88898f177a5ba41171c6747517be5370354553a4ce0918d4811790890f1a1d05314ae5b24d50d8a0c528a9b950c12feaaf0158dc988b8d201068081840deeb484c5d03d41bb23cda4b362ee7b4bd9885a165cc0635b05ad74329b27b51f64beed963b78933256e0b8a7426ec309c926054c6eaabe9d8a6a86ca878d99fb6a508c7c819cd8d7db8d6844e09a82024094fd9102395ca61cd20a1cad8f111a70dce08deb6fc5d4340107bb4ac640db7be9072730cf4d6d90d5ed202f6bda9a7ea5e38f39afbf95722a9a09d8cf45ef3c1e84edd7b07c1fbd1964c8df92271eeb25ea2952faec917eb0fd88dacd4fe1aa6c5ce5553f79cf8b45029a4ecfe90a824b14ee1216f9431104ba239063e97227fcd6c8d21262b968f2ba82085f6f8f391f73598d82627d8f0bd756b47d78cc55e197dd2b24170450bad975e9599b2a98c441da86f66230a60493217321648910e622084434ec3bf289eeeb1cfe5cf70e5d602f8a6a36d127dda24078486f84ad5b39cc432d10de7fdf79b6c9c8872ae9fffa1d065634dd2555e49e7760add64b8587b4b17841b2266c6e621b59cf512c1fcf95d15782a0ec368d3c68349dca96f5704dd5ee24d9ae98c9bf2fb322fc1559415282a4c6aa73c7c4e41b5c479dc2973056ede940a9688a91acd04fedd39c315849d0cd53667109562108f8a9c8b94b67042528ca7874d4ee457943e9a0f7c9fbfce4d118f78ac7aef4c6d9d82385907ce651dd3abea97527ee730f236ee2877633f68866b3683b9ede119cef387bbbe82b1ba9eaeea41e6c6ab51e7c0ec6aa5fb0c3a84ed3bbc9dac0d3ec56b62c8d7760ed5b0f187e12765254b2236e7f6a6e317348bfa346de5e3a7db47886cd10a42e35b8760e025d40d05c935fb9cf4164959c664beb505a5597ad2dbeab32a69f6aa64d25bd5d747e56e823cc2a7b5a4c90bfc4b5bc87965ce0eb4074b1c1e8db63b8ed1ec9d229c66e35eb65d3aa091e8821986756ab2f73fc86ee5ce2b88fed07fc7ba873ace1165013a94fa755f738fa52249213ed82d5c83828d640c8abcbe64586350b5c58f5c80a7fd39e93166aaaed20fffc5514f56fbe32cc570f3eab41ebca1cac77db849779ad70ca33896f964b080c00010110000000005400010400000200100cfd1027fe404b4c00000002a071da0d559dc0f533447c1e31a0d919e506f4a420027d116f4bdf707b283f24057d0dd22734cfc3745644fd1779051a6e27cf50fba73a6a082ab911bef6a478000000000000", "blockhash": "00000112377e2a2aaadaa1cbbc0f6aa24477dfd726e42948d30f7eec0bc816d8", "confirmations": 1, "time": 1776781251, "blocktime": 1776781251, "is_qabio": false } Quantum safe transactions possible on signet.

Whilst working through each example in the Ladder script engine I found a bug. (rpc.cpp): createtxmlsc was reading coil.type from each rung's coil object but silently dropping coil.scheme and coil.attestation. Any PQ rung committed with the default SCHNORR scheme, making spend-time leaf reconstruction (which uses FALCON512) diverge. I have fixed to use ParseCoil for the full coil specification.

I've now added a third mempool for comparison. 1 - Standard Bitcoin Ghost. 2. Bitcoin ghost with reaper. 3. Knots. I noticed that Knots filters alot of txs. When combined with their minimum 1 sat Vbyte - Knots filters 100% more than reaper. Obviously they are two different systems. Reaper was intentionally built to detect dead script to minimise censorship. Knots just nukes the mempool with filters. After further investigation I've found Runes to be passing through reaper as it doesnt use dead script. I'm now looking at ways to exclude them. They use a prefix which would be a simple filter but I dont have time for cat and mouse games. I need something definitive.

I managed to use mempool.space and build a visual comparison between reaper and non-reaper mempools. bitcoinghost - node with reaper enabled txs: 18,753 / node without reaper txs: 47,165 / filtered: 28,412 (60.2%).

Reaper is working. VM4 holds a mempool 66% smaller by transaction count, 72% smaller by bytes, vs. the three non-Reaper peers. Over 6 hours, 1,131+ dead-code txs rejected at the gate (all inscription envelopes). There are five types of rejection - 1. Inscriptions. 2. Drop stuffing. 3. Fake multisig. 4. P2TR annex. 5. Oversized OP_RETURN. Only the inscriptions detector executed over the six hour test.

Pushing Reaper to Mainnet testing on Bitcoin Ghost. Reaper rejects transactions whose script bytes contain regions that are provably never executed by the Bitcoin Script interpreter. I'm testing to see the difference in mempools between a node that runs reaper and three that don't. Currently mempools are relatively similar.

RUNG_TX channels could be used to replace LN script. They would be simpler, cheaper at force-close, more private and eliminate the watchtower requirement.

Ladder script initial run of the library estimates tx sizes to be of the smallest for key path. If script path is used we are slightly heavier than legacy tx types on the lower output count but after N+2 the window shifts. We save incredible savings for multi input/output txs. I have managed to implement a reduction of the UTXO size to 3 bytes (N x 3 + 33(one time synthetic 0xDF || conditions_root)). Reference "MEASUREMENTS.md".

Bitcoin Ghost update. The four nodes I have been testing on mainnet are still functioning perfectly. I noticed we received a mention from Eli Nagar on his X article about crawling for node counts. I have noticed the latest revision of load sharing on the pool is kicking miners between nodes frequently - I will address the issue as soon as I can. Public release of July 1st is looking tight but achievable.

I'm currently working through the engine and playground so that it works with the new library. Dont trust any docs or files until I have removed the banner.

The Ladder script project is ongoing. I have completed the intitial refactor into a minimal bitcoin-core shim and complementary ladder library. The reason for this is to enable easier revew. Additionally it enables individual blocks to be deleted in the event they are not chosen.

First post. Setting up defenwycke.org. More to come.