search

bitcoin-dev-project / warnet

Monitor and analyze the emergent behaviors of Bitcoin networks
https://warnet.dev
MIT License
81 stars 35 forks source link

Set up Signet-like miner for warnet #503

Closed josibake closed 2 weeks ago

josibake commented 2 weeks ago

For war-games, we don't want teams to be able to mine their own blocks, which means we need an admin controlled miner. Signet is likely the easiest way to do this, so we will need to:

  1. Run warnet in signet mode
  2. Have a signet miner controlled by the war-games admin
  3. Mine the blocks into each team's namespace (randomly? round robin?)

The idea of randomly mining into each teams namespace is to ensure blocks will come from enemy teams, thus each teams need to maintain connections to malicious peers to hear about new blocks. Otherwise, you could just firewall your nodes from any attacker.

pinheadmz commented 2 weeks ago

Signet was introduced in 0.21.0 meaning wargames including nodes prior to this version will not support signet at all. I think that is an issue since many exciting vulnerabilities were present before signet.

So, options?

  1. Keep regtest

    • make a new set of bitcoin node images for every version with rpc generatetoaddress removed
    • admin has control over a v27 node, the only one in network, with the CPU miner still working

  2. Use Testnet 3

    • bring a BitAxe or small ASIC to tabconf, use actual PoW to prevent players from mining
    • means connecting meatspace hardware into the cluster somehow
    • block 546 is checkpointed, will have to config all tanks to invalidate block after that, start our warnet chain there
josibake commented 2 weeks ago

😭

Agree we should keep the older images. Keep regtest seems like the easiest path forward in the short term. Instead of modifying the images themselves, can't we just use -rpcwhitelist to allow everything but generatetoaddress? Sure, this looks ugly, but it's a config change which means we can do it just for Tabconf and not need to modify our images.

Using testnet 3 seems cool, but this seems really hard to get ready in the next month.

A third (unholy) option: we back port https://github.com/bitcoin/bitcoin/pull/18267/ to the pre-0.21 images 😬 I took a look at the PR and the bulk of the logic is adding signet.{cpp,h} and then lots of test files. I think this is the best approach long-term and would be happy to take a stab at it. Essentially, we just add the signet files and the necessary consensus changes and leave out the tests to keep the patches small. These old images will never change, so there isn't any risk of needing to maintain the patch (unlike our addrman patch that is applied to new images).

TLDR; try to back port signet to the old images, and if that doesn't work we use the rpc whitelist method with regtest?

willcl-ark commented 2 weeks ago

This is only needed for this single tabconf exercise. IMO it doesn't seem worth much effort. Just ask folks not to do it.

Another option is to rebuild (all images ZZZZZ) with an additional (bypassable) prohibition of bitcoin-cli *generate* commands, like this: https://github.com/bitcoin-dev-project/warnet/compare/main...willcl-ark:warnet:no-generate

pinheadmz commented 2 weeks ago

rpcwhitelist was added in 20 or 21 I think.

josibake commented 2 weeks ago

In that case, seems like our list of "we'll just ask them not to do it" is getting pretty large. If we are going to rebuild old images, I'd prefer just adding signet to the older vulnerable images. @pinheadmz can you keep working on adding a signet miner and only test with images that support signet? I'll work on back porting signet to the vulnerable images since I've already got some other work related to old patched images I'd like to do (e.g., #508 ).

I'm fairly certain backporting signet for the old images is possible, but if you're concerned about it not being possible before Tabconf, I can time box this work to this week and you can start on the signet miner next week after I've patched the images. If I can't get it done this week, we can always go with the "can you guys please not mine" approach.

willcl-ark commented 2 weeks ago

we can always go with the "can you guys please not mine" approach.

image

It's a bona fide strategy!

pinheadmz commented 2 weeks ago

Another option is to wrap all the player tanks in a proxy: https://github.com/pinheadmz/rpc-auth-proxy

This proxy has a rpc blocklist. Maybe we can set it up as a service, then it can be applied in wargames but not in other simulations.

pinheadmz commented 2 weeks ago

or we could block any mining RPCs in the scenario framework?

josibake commented 2 weeks ago

I'm not opposed to looking at other solutions so long as:

  1. Its generally a good idea for warnet, beyond Tabconf
  2. Does not involve making custom images just for Tabconf

So far, enabling signet in warnet has seemed like the most generally useful approach, with the only blocker being a one-time fix for old CVE images. But if something like the proxy player is a better long term solution, happy to consider arguments as to why.