• rideOP
    link
    fedilink
    English
    arrow-up
    7
    ·
    10 days ago

    Monero GUI wallet

    If your run your own local node through the GUI wallet, go to Settings. In the “Daemon startup flags” box, input “–ban-list <file-path-to-ban-list>”. Then click the orange “Stop daemon” button. It will take a few seconds for the daemon to shut down. Then click the orange “Start daemon” button. If you use a remote node, whoever operates the remote node will decide if the ban list is enabled.

  • Eriq
    link
    fedilink
    English
    arrow-up
    1
    ·
    edit-2
    10 days ago

    All the subnet addresses are not banned and shows error when adding any subnet, other IPs without the subnet format are added successfully : "

    2024-12-08 22:08:06.735 E Invalid IP address or IPv4 subnet: 91.198.115.0/24

    2024-12-08 22:08:06.735 E Invalid IP address or IPv4 subnet: 100.42.27.0/24

    2024-12-08 22:08:06.735 E Invalid IP address or IPv4 subnet: 162.218.65.0/24

    2024-12-08 22:08:06.735 E Invalid IP address or IPv4 subnet: 193.142.4.0/24

    2024-12-08 22:08:06.735 E Invalid IP address or IPv4 subnet: 199.116.84.0/24

    2024-12-08 22:08:06.735 E Invalid IP address or IPv4 subnet: 209.222.252.0/24 "

    These IPs account for more than half the problem and do not seem to be banned properly by the ban list.

    If the subnet format does not work we could enumerate the subnet and have each individual IP from that subnet on the list as a workaround.

    • Eriq
      link
      fedilink
      English
      arrow-up
      1
      ·
      edit-2
      10 days ago

      deleted by creator

    • rideOP
      link
      fedilink
      English
      arrow-up
      1
      ·
      9 days ago

      Node operators who use this list should subscribe to Boog900/monero-ban-list updates so that a new version can be added when changes are made to the list.

      • Eriq
        link
        fedilink
        English
        arrow-up
        1
        ·
        9 days ago

        Is this a common issue of ban lists unable to parse subnets or am I the only one because if no one is banning these subnets due to parsing error that is small problem.

        • shortwavesurfer@lemmy.zip
          link
          fedilink
          arrow-up
          2
          ·
          8 days ago

          Looks like it might be something on your end because I just tried one of the IPs that yours gave an invalid for and it works fine.

          • Eriq
            link
            fedilink
            English
            arrow-up
            1
            ·
            7 days ago

            Did you manually ban from the monerod terminal? subnet parsing works when manually banning it from cli but seems to have issues when loading automatically ban list. If u loaded it with the ban list and it worked then it is somehow a local issue for me.

        • rideOP
          link
          fedilink
          English
          arrow-up
          1
          ·
          9 days ago

          Don’t worry, it’s not a problem. It’s just that every connection to the potentially spying nodes on this list that is blocked potentially strengthens the Monero network privacy.

    • Eriq
      link
      fedilink
      English
      arrow-up
      4
      ·
      8 days ago

      It removes the spy nodes from network so they cant do a timing attack (If one spy node receives a transaction unseen by the 100s of other spy nodes, they can logically deduce that the first instance seen was the originator of the transaction/block). The current list above has a parsing error for the subnets (IPs with 0/24) and those are important because each single subnet contains 256 possible IPs. These possible IPs are fully actively being utilized for the attack as I have seen first hand. I hope Boog900 or one of the list maintainers can address this parsing error somehow so I can remove my temporary fixed list. This could be somehow a personal error somehow but most probably these unparsed subnets are a unnoticed issue.

      • mister_monster
        link
        fedilink
        English
        arrow-up
        1
        ·
        8 days ago

        But with dandelion++ it should be infeasible to deduce anything about a transaction on receipt, no?

        • Eriq
          link
          fedilink
          English
          arrow-up
          2
          ·
          8 days ago

          Best solution when connecting to public nodes would be through Tor. Even if the public node is a spy node somehow with tor enabled, they would still be able to see requested blocks but would not be able to pinpoint who is requesting. It still adds a good layer and is recommended by most, but it is not perfect because Tor is also somewhat under a timing attack.

        • Eriq
          link
          fedilink
          English
          arrow-up
          2
          ·
          8 days ago

          yes the overall transaction is safe but the individual node sending that transaction/block is recorded with the IP logged. Mass collection with a large spy network would easily enable a semi reliable initiator logging system that could be used later for any purpose. You could connect to a public node to hide and not send from personal node but then again the public node itself could be a spy node too. Its all about collecting general metadata for use with other data to be cross examined when the time is needed.

          • mister_monster
            link
            fedilink
            English
            arrow-up
            2
            ·
            7 days ago

            Well, the concept of a ban list seems ripe for abuse. We have to trust someone to tell us canonically who the bad nodes are, people can slap a fed honeypot node label on you for not going along with something.

            What we need to do is design the system such that a bad node can do nothing but participate in the network. Just like the mining incentive structure with nakamoto consensus. Dandelion++ is supposed to do that, at least for everyone broadcasting their transactions only to initial nodes they know and trust. I don’t know how to do that, but a blacklist is a dangerous stopgap.

            • rideOP
              link
              fedilink
              English
              arrow-up
              1
              ·
              edit-2
              7 days ago

              👍

              transactions only to initial nodes they know and trust. I don’t know how to do that

              • Create your own fullnode and leave it running all the time. So don’t just start it when it is needed for transactions or interactions with Monero. There are also very accessible methods for this, such as PiNodeXMR, which easily converts an SBC such as RaspberryPi into a secure Monero full node.

              • Use Tor and a known trusted Tor node, e.g. hashvaultsvg2rinvxz7kos77hdfm6zrd5yco3tx2yh2linsmusfwyad.onion from hashvault Pool.

              • Use VPN (and a known trusted node)

              • mister_monster
                link
                fedilink
                English
                arrow-up
                1
                ·
                5 days ago

                Yeah, I mean for remote nodes, running your own node all the time basically solves these problems.

      • azalty@jlai.lu
        link
        fedilink
        English
        arrow-up
        1
        ·
        8 days ago

        The biggest risk is actually the manual selection of decoys by remote nodes

    • rideOP
      link
      fedilink
      English
      arrow-up
      1
      ·
      8 days ago

      explain the need of a ban list? And how it works?

      Adding the ban-list to your Monero GUI wallet or your Monero node prevents connections from being made to other nodes that are suspected of harming the Monero network. You don’t have to add a ban list, it’s voluntary, just an official recommendation. But everyone who adds a ban-list contributes to the security of Monero.