Start9 node with both SHA-256 and BLAKE2B chains

Bitcoin
1

Is it possible to run both a Knots (blake2b) and Knots (preRDTS) or Core on a single Start9?

2

Yes, I have created “Companion” nodes which run alongside the normal slot for Knots/Core. They run as pruned by default (can be run as full nodes if you have 4TB of space on your server to support two full nodes). There are other threads on the forum here where I outlined the steps to set this up. I’ve been promising to record a video tutorial on this, so I’ll do that soon (I mainly wanted to finish porting LND to the BLAKE2b chain so I could include it in my “full stack”, and that is now completed)

3 Likes
3

I’m thinking of selling my sha256 coin soon. I have my start9 with a blake2b full node. To make the transaction to the exchange, I just install your bitcoin knots sha256 companion and also electrum pruned? Am I also right in thinking that to do replay protection I can simply add a large enough op_return with sparrow on the sha256 transaction thats being sent to the exchange?

4

A large OP_RETURN on the SHA256 chain is more difficult than a Unified Sighash on the BLAKE2b chain (since Sparrow doesn’t have an interface for that). I would replay-protect from the BLAKE2b side. Then once you confirm that the stacks are disconnected (by sending a small amount to another wallet and confirming it doesn’t replay), you can move the SHA256 sats to the exchange.

5

thank you for the tips. I havent put much research yet on how to do it but I’ll look more into it.

6

This would probably be one of the most valuable videos you could do next as I am sure there are many who want to disconnect the chain addresses and no longer have to fear replay attacks :folded_hands:

1 Like
7

One problem is I don’t have any replay-unprotected UTXOs to demonstrate with. It would be talking in theoreticals, which isn’t ideal for a tutorial. Maybe still worth it, IDK.

8

i have a coinos wallet with some btc in it from before the fork. I can send you a bit if this will work

9

ah I see; okay. where would you recommend are the cleanest steps you have seen e2e for applying replay protection to BTC as once that’s done I assume XBT will have it too. I have not gone near Shrike yet as it felt still too early in terms of maturity and hacks since it seems we are all under attack now certainly cold wallet vulnerabilities are all being well exploited.

10

I don’t have a clean guide, but basically you could follow what Matthew Kratter showed on one of his videos for adding a large OP_RETURN using electrum (since Sparrow doesn’t support it). I would use that in a process similar to what I mentioned for Shrike.

  1. Send a very small amount of your stack (not dust, but no need to risk anything here) to a new hot wallet
  2. Load the hot wallet in electrum, and send it back to the original wallet with a large OP_RETURN added (making it invalid on the BLAKE2b chain)
  3. Consolidate your stack in the original wallet, combining it with the UTXO from step 2.

You could do this as one large consolidation, or in whatever sized chunks you want for your final UTXOs.

Since you won’t be running Shrike, the best way to confirm replay protection is to load the consolidation transaction(s) from step 3 into a BLAKE2b mempool explorer (such as mempool.guide) to make sure they are not found. If they are found, then you know you did something wrong, so go back and check each step.

1 Like