Catching up on the #OP_RETURN change the #bitcoin core devs seem to want to shove down on our nodes.

Easy answer seems to be a switch to #knots by nostr:nprofile1qqs0m40g76hqmwqhhc9hrk3qfxxpsp5k3k9xgk24nsjf7v305u6xffcppemhxue69uhkummn9ekx7mp00qjrgs.

An even easier solution would be if Luke or someone else with a reputation would just fork the Core github to remove the changes affecting OP_RETURN like he already successfully did with the UASF fork that give us segwit.

My only questions are:

1) can I keep running my Lnd node without loosing my channels

2) Can I keep the same blockchain data without having to resync all of it from scratch

3) Does Electrs run with #knots

Seems feasible and I'm willing to try it out.

Any guidance would be highly appreciated 🐸

Reply to this note

Please Login to reply.

Discussion

I switched to Knots last weekend.

1) My Lightning node still works perfectly with all channels; other than pointing it to Knots, I didn’t have to do anything.

2) I re-synced the whole chain. I did see an article explaining how you can reuse the existing chain, but I didn’t try that – although it should be possible.

3) Yes, Electrs works with Knots

I synced the blockchain from scratch while my Core node was still running. Then I stopped Core and had my apps point to Knots. Easy to do on Umbrel: just change the node setting inside each app.

Thanks for the info.

I'll look into it just to be prepared in case Core actually decides to shove the change down out throats.

I also believe it shouldn't be to difficult to patch the change in future releases but I'm no expert in C++ and even less on the Core codebase.

Could you provide stats on the resync: time it took and type of hardware used?

It took about 23h on an Umbrel Home