-
br-m<kiersten5821:matrix.org> scanning new blocks for outputs is constant time in the number of subaddresses right?
-
br-m<kiersten5821:matrix.org> is this the right chat to be asking these questions?
-
DataHoarderyou could try community-dev too
-
DataHoarderbut yes, it is constant time to the subaddress number - though it can be implemented differently
-
DataHoarderit's a map lookup
-
DataHoarderwhatever the O of your map implementation is the extra work factor
-
DataHoarderfor most relevant sizes, that will be constant compared to the cryptography done before the lookup
-
br-m<kiersten5821:matrix.org> thanks. so the number of subaddresses is basically irrelevant to the scan speed
-
DataHoarderyes. as long as it's the same wallet/viewkey
-
br-m<kiersten5821:matrix.org> how do i get there exactly? i looked at getmonero.org/community/workgroups but can't find it. i got directed here after asking the multisig attack question in the monero docs chat. > <DataHoarder> you could try community-dev too
-
DataHoarder#monero-community-dev < this should link to Matrix
-
DataHoarderit's fine to ask here, as well, but if it's more how to implement things that is more around community members developing things
-
br-m<kiersten5821:matrix.org> thanks, i joined that. this is a little confusing, is there not a central listing directory that has all of these? i keep getting linked to singular channels it feels like
-
DataHoarderthere is the Monero Space on Matrix
-
DataHoarderdon't worry, there are way more channels not listed there either :) it does need some work indeed
-
br-m<ofrnxmr:xmr.mx> Join my space Monero matrix.to/#/#monerospace:monero.social
-
br-m<torir:matrix.org> What's the reasoning behind requiring IPv4 for initial block download but not for timed block sync or other functions? The docs say Sybil resistance, but is there a specific attack during initial block download that requires that?
-
br-m<ofrnxmr:xmr.mx> Its effectively free to blackhole a node using onion addresses
-
br-m<ofrnxmr:xmr.mx> Not being able to replay transactions isnt as bad as being served a fake blockchain
-
br-m<torir:matrix.org> "blackhole" meaning eclipse attack? Or just spamming fake blockchains that don't verify?
-
br-m<ofrnxmr:xmr.mx> Eclipse
-
br-m<torir:matrix.org> My understanding of eclipse attacks is that connecting to a single honest node prevents the attack. I thought eclipse attacks can happen over IPv4. If a node connects to an attacker's, the attacker only advertise the IPs of other dishonest nodes. If the seed nodes are honest (and they should be), it shouldn't matter if thousan [... too long, see mrelay.p2pool.observer/e/k9Pmm90Ka2xHSzRE ]
-
br-m<torir:matrix.org> Okay, I can see why Sybil resistance is important there. I didn't get it at first.
-
br-m<torir:matrix.org> It just bothers me that Monero is reliant on IPv4 and the network can't operate purely on anonymity networks. Even if you can sync via Tor via using Tor to connect to IPv4 nodes, IPv4 reliance feels like a stopgap fix that we should work on replacing.
-
DataHoarderif you use pinned nodes, you can sync. otherwise auto-discovery allows eclipse
-
DataHoarderin p2pool we have tied auto-discovery of onion addresses to them getting published within shares (which are PoW) and they are allowed for connection only while that happens
-
br-m<torir:matrix.org> If someone has to sync exclusively over I2P (which can't connect to IPv4), does the current monerod support syncing from a pinned I2P node?
-
DataHoarderinitial sync requires trusted nodes to get the shares, or clearnet connections (which can be via tor)
-
br-m<ofrnxmr:xmr.mx> @torir:matrix.org: No. Its not enabled in the code
19 hours ago