15:03:21 MRL meeting in this room in two hours. 17:00:42 Meeting time! https://github.com/monero-project/meta/issues/1105 17:00:46 1) Greetings 17:01:06 Hello 17:01:14 hello 17:01:16 *waves* 17:01:26 <0xfffc:monero.social> hi everyone 17:02:40 Hi 17:02:55 2) Updates. What is everyone working on? 17:03:59 me: Analyzed p2p connection logs to provide more supporting evidence for the proxy node banlist and estimated the empirical risk to user privacy: https://github.com/monero-project/research-lab/issues/126#issuecomment-2460261864 17:05:09 <0xfffc:monero.social> Like last week I was sick with covid19/flu, so haven't been that productive either. Only trivial reviews. Today I got back to work. First will review #9441, then fix issue raised at #9362 17:06:40 3) FCMP++ tx size and compute cost and MAX_INPUTS/MAX_OUTPUTS https://gist.github.com/kayabaNerve/c42aeae1ae9434f2678943c3b8da7898 https://github.com/monero-project/research-lab/issues/100#issuecomment-2433524326 17:07:01 kayabanerve kayabanerve : Anything to discuss today about this? 17:07:14 me: Continuing local wallet tree building 17:08:05 I haven't gone deeper into the MAX_INPUTS/MAX_OUTPUTS analysis yet because my main "database" process is occupied. 17:09:07 4) FCMP++ Optimization Competition. https://github.com/kayabaNerve/fcmp-plus-plus-optimization-competition 17:09:20 Anything to discuss on this? 17:09:33 Apologies. I have nothing to add 17:09:36 Howdy, sorry I'm late. Daylight savings got me 17:10:17 On either topic, I haven't personally worked on Monero this past week. 17:10:43 5) Reviews for Carrot. https://github.com/jeffro256/carrot/blob/master/carrot.md 17:10:59 jeffro256: , anything on Carrot today? 17:11:16 AFAIK, Cypherstack is still working on the review. No updates from them yet 17:13:39 That reminds me that I wanted to note a personnel change that's relevant to MRL: About a month ago, Aaron Feickert (Sarang Noether) left Cypher Stack. At about the same time, Brandon Goodell (Surae Noether) joined Cypher Stack. 17:14:35 6) Discussion: preventing P2P proxy nodes. https://github.com/monero-project/research-lab/issues/126 17:14:56 Rucknium: Do you want to add a research topic to these meetings re: making fee a pure fn of inputs/outputs/TX extra len? Or is that not an active discussion topic, solely a item of work for you? 17:15:14 Yes I could do that 17:15:27 Sorry for interrupting you mid-topic, it's just kinda FCMP++ related and one thing I wanted to quickly check in on. 17:15:35 Do you want to discuss now or next meeting? 17:16:46 If we have time today, we can open the discussion today. It should be brief. I'll leave you to decide when we get to it as the current agenda item is P2P proxy nodes :p 17:17:12 Ok. We can put it in the "Any other business" item if there is time at the end of the meeting 17:17:23 boog900: Do you want to open the discussion on p2p proxy nodes? 17:19:56 Sure, a few weeks ago I found some nodes displaying behavior which can only be explained by them being proxy nodes. These nodes make up a large portion of the network, 40% of the IPs I found and 75% of the IP:Ports. 17:20:41 The only reason I can think to run proxy nodes is to try and link IPs to transactions. 17:21:44 A "proxy node" is an IP address that pretends to run its own node, but actually it just relays messages between a "victim" node and another node (possibly honest node or controlled by the adversary) 17:21:52 They use 6 main IP ranges, all under the LionLink-Networks ASN 17:22:01 40% is nuts. I want to link this Bitcoin issue here: https://github.com/bitcoin/bitcoin/issues/16599. Seems like some people might have already done some research in this area. ASN bucketing would almost certainly help here 17:22:54 A lot of the threat models for network integrity and privacy assume that it is expensive for an adversary to run many nodes. Basically a proxy node reduces this expense by appearing to run a real node, but not actually running it 17:23:57 In my p2p log data, from April-May 2024, about 15% of outbound connections of the honest nodes are to IP addresses in the ban list, so the privacy risk isn't as high as 40%, probably. 17:24:24 We could add a PoW puzzle to any network requests which can be MITMd but not without replicating the work. I don't like the idea of PoW for any P2P req but also, it makes proxy nodes expensive again. 17:24:48 The question is is that an asymmetric cost or does it just make every node more expensive while massively degrading the P2P network. 17:24:51 Connections to the banlist IP addresses have a shorter duration. And the node software prefers to connect to IP addreses ranges that are not in the same subnet 17:26:15 If they operated the node being proxied they could probably get around this right? 17:26:35 <0xfffc:monero.social> This is very interesting approach. Particularly there is every kind of PoW defense available. But for adversary with $, this is not going to solve the problem. 17:26:45 I don't know what the long-term solution is, but in the short term, monerod could be hard-coded with the LinkingLion IP addresses and instruct monerod not to establish outbound connections to them. Inbound connections could be allowed, so no "innocent" nodes would be excluded from the network. Outbound connections are the privacy-sensitive ones for Dandelion++ 17:27:17 It'd also need PoW on responses :/ 17:27:55 LinkingLion has been publicly discussed for years, yet they have not changed their IP addresses. Maybe something prevents them from doing so. Maybe an IP address hardcode would stop them for a while. 17:28:10 They'd serve 10x the responses if they have 10 nodes, even if they only make 1x the requests for their one node 17:28:15 you can't prevent it from happening, but raising the fence is a good idea IMHO. 17:28:32 We could discuss introduction of a mixnet as an alternative to D++ 17:29:23 I don't know if a mixnet would prevent eclipse or network partitioning attacks. 17:29:26 I think that'd be excessively long-term and I'm not immediately sure it actually solves the problems we have 17:29:28 Yes but that would mean either 1) the proxy is doing the PoW which makes it expensive, or 2) the central node is doing all the PoW which will bottleneck the operation after a certain period of time 17:29:51 Wasn't Kovri the "mixnet" attempt in the past? 17:29:52 I would support banning every IP under LionLink-Networks, even the ones not currently running proxies. 17:30:33 <0xfffc:monero.social> I agree. As short term solution, right? eventually we want to have a better defense for this. 17:31:32 Kovri was just a I2P implementation, as far as I remember. 17:32:04 u/oh-chase on Reddit posted this: https://xmr.nodes.pub/ It cross-references node IP addresses with ASNs. "LIONLINK-NETWORKS" is 55% now. 17:32:21 If the PoW was also for responses yes but if the PoW is only for requests then by using their own main node they can just ignore the PoW requirement for their proxies. 17:33:14 Rucknium: Every however often, we can have a node declare a mix. In this mix, every participating node submits an encrypted TX or an encryption of nothing. The publishing node of a TX becomes any one of the honest nodes in the network per cryptography (regardless of network analysis). 17:34:27 Isn't that just broadcast a tx by proxy, which was already analyzed by the D++ designers? 17:34:35 That would also mean any one node can DoS the mix. We'd need a local reputation system for selecting mixes and a way to decline participation (if spammed with participation requests). 17:35:08 Possibly? "any one of the honest nodes" sounds stronger than simply using a proxy. 17:36:00 Eh. Presumably, the mix would only be conducted within the locally connected to region of the network. That means you can identify a TX as belonging to a subgraph of the P2P network. With D++, the fact it travels multiple hops prevents that. 17:36:10 I see what you're saying, since creating a stem would be a request made by the honest node to the spy node in this case 17:36:56 > A natural strategy for breaking symmetry about the source is to ask someone else to spread the message. That is, for every transaction, the source node chooses a peer uniformly at random from the pool of all nodes. It transmits the message to that node, who then broadcasts the message. More generally, the network could forward each message a few hops (each hop choosing a new no de at random) before diffusing it. We call this approach diffusion-by-proxy, and it is conceptually equivalent to propagating over a line that changes for every transmission. Diffusion-by-proxy might seem like it should have low precision because the graph is so dynamic, but that intuition turns out to be false. 17:37:01 ^ D++ paper 17:38:24 A long term solution will require time to research and develop. Can we discuss boog900's proposal to hardcode the banlist in monerod? 17:38:39 I'll leave my commentary as the idea and decline to claim to be knowledgeable enough to continue the discussion. 17:38:40 But even if adding PoW to D++ stem creation, it really doesn't happen that often, so it wouldn't be that much of a deterrent without crippling tx propagation for all nodes 17:38:42 ^ since that is a short-term solution that can be acted on quickly 17:39:31 I can't recall, is there precedent for including a hardcoded ban list? 17:39:54 I don't see any downsides to preventing nodes from establishing outbound connections to the proposed banlist nodes. 17:39:59 I think so far we carefully avoided any such things 17:40:07 I don't think there is precedent 17:41:04 <0xfffc:monero.social> this time seems a little bit different. scale is huge IMHO. Please feel free to correct me. 17:41:52 <0xfffc:monero.social> I have another question. If we implement such approach. https://xmr.nodes.pub/ are we losing 55% of nodes basically? 17:42:07 Those nodes aren't real 17:42:09 they are proxies so no 17:42:10 Why hardcode it in over propogating a banlist file with a concise explanation? 17:42:30 If we really take that drastic measure, maybe also create a new command-line switch to disable that hardcoded banlist? To uphold people's freedom to decide. 17:42:42 <0xfffc:monero.social> Ah, yes. thanks for clarification. 17:43:07 The main downside is risk of centralized censorship decisionmaking. Other downside is "what if they're honest for reasons we aren't seeing". Although generally I think it's reasonable / "within ethos" to seek to seek to ban centralized chokepoints 17:43:18 A non-hardcoded banlist file can possibly be used for corrupt purposes without a node running updating their software. Probably 17:43:46 And the reach and effect of such a separate file would certainly be smaller 17:44:09 Huh? Banlist files already exist though 17:44:11 I think it's fine to have a switch that allows users to disable the banlist. But have it on by default IMHO 17:44:27 Yes, that's what I meant: on by default 17:44:31 jeffro256: I know. But they aren't on by default 17:44:34 To be clear I want to hardcode a banlist for LionLink-Networks, not all IPs in the ban list. 17:45:24 Rucknium: Not sure what you mean with "corrupt uses" for banlists? 17:45:46 *corrupt purposes 17:46:20 I agree with this. It sets the wrong precedent to have the devs hard code in banned IPs 17:46:22 There is a banlist that you can enable that checks a DNS record for which nodes to ban. If something like that is enabled by default, the DNS record could be hacked and har, the network 17:47:02 The IPs wouldn't really be banned from the network. They could still establish their own outbound connections. 17:47:32 <0xfffc:monero.social> anyway to find out how many actual node are running? ( I want to understand what percentage of these 55% are proxies ) 17:47:58 IPV6 is already disabled by default because there is a sybil attack risk with IPv6. At least, that is the reason I have read. 17:49:27 Somehow hardcoding IP4 numbers look like a grave defeat IMHO. And totally out of place. 17:49:31 I haven't found a node in the 6 subnets that passed the not proxy test. 17:50:20 I get about 12,000 unique IP addresses in my log dataset from April-May that are not on boog900 's banlist. 17:50:39 <0xfffc:monero.social> my other question, how computationally intensive is to run proxy node? to rephrase, I assume running a proxy node is cheaper than running actual node? 17:51:04 It really depends how you count. A lot of nodes that do not have open ports, so an active, short network scan wouldn't find them. And then nodes are turned off and on sometimes. 17:52:01 Note that nodes without open ports are not going to be part of a D++ stem anyways 17:52:12 This spy node issue has been neglected for years. I assume because of dev resource constraints. 17:52:17 Won't "they" just rent a botnet and then have proxy nodes all over the planet? 17:52:29 <0xfffc:monero.social> ( correct. so for simplicity let's not consider them in our discussion ) 17:52:36 With quickly shifting IP numbers as well :) 17:52:47 <0xfffc:monero.social> That is what I am trying to get at. 17:53:08 <0xfffc:monero.social> I think we have to impose computational cost (PoW) to proxy nodes. 17:53:21 I get 4,600 non-banlist nodes with open ports in my dataset 17:53:32 <0xfffc:monero.social> because, if this assumption is correct, they can switch very easily (?) 17:54:13 For some reason the adversary is still using Lion Link even though there has been public discussion of this for years. That may suggest that it is not easy for them to switch IP ranges. 17:54:54 Hmmm, that approach so far had zero downside in the particular case of our network, no? Why switch then 17:55:17 And it took years to becoming aware ... 17:55:41 They are spying on the bitcoin network, too. I don't recall if bitcoin did anything about them. boog900 , do you know? 17:55:54 Maybe the game will change now however 17:55:59 Bitcoin has a much better ASM diversity logic 17:56:11 <0xfffc:monero.social> But privacy is not important aspect of Bitcoin. 17:56:25 Yeah, what would you even spy there :) 17:56:29 This is also a eclipse and network partition risk 17:56:45 Bitcoin cares about that 17:57:06 <0xfffc:monero.social> Yes, that too. Makes sense. 17:57:15 <0xfffc:monero.social> So what did Bitcoin do? Leave them alone? 17:57:18 Some of their IPs have been on selsta's ban list for a while, you would think they would switch to get as many nodes as possible. 17:58:43 Thinking back... isn't there precedent for this when there was a network attack in December 2020? Not hardcoded, but the DNS record banlist, etc 17:58:54 But that was abigger threat to network stability than this 17:59:17 I don't but IIRC their main concern was a DOS vector due to these nodes just passively listening and not participating in normal tx flow: https://github.com/0xB10C/banlist/issues/1#issuecomment-2407202886 18:00:05 This is a post about the 2020 attack: https://sethforprivacy.com/posts/moneros-ongoing-network-attack/ 18:00:30 > 2020-11-02 - PR6961 implemented to allow passing a banlist to monerod 18:02:17 Yes, introduction of banlists I would say. Totally optional and fully under user control, I would say. Nothing like a hardcoded opt-out banlist 18:02:31 Sorry I'm late as well, daylights savings tripped me up too. Not much report really, same as last week 18:03:17 I forgot to say thank you to boog900 for uncovering this proxy node issue :D 18:04:26 Now we all have one worry more :) 18:04:29 <0xfffc:monero.social> Sorry for this digression, any of you is familiar with DNS TXT messages and how they work? I will DM you to ask few general questions. 18:05:15 We are past the hour. One more hopefully quick one: 18:05:45 7) Proposal for FCMP++ HF Activation Rule to Retroactively Ignore Future unlock_time . https://github.com/monero-project/research-lab/issues/125 18:05:46 jeffro256 suggested that this be discussed for hopefully the last time at this meeting 18:07:13 For asking whether somebody changed their mind or had some really new insights, arguments, etc? 18:08:25 none from me 18:08:26 " I propose tentatively setting ignore-unlock-time block index `J` to 3401782, with threat of setting earlier. monero-project/research-lab #125#issuecomment-2448077632. We can discuss this in the next meeting, though" https://libera.monerologs.net/monero-research-lab/20241030#c453599 18:08:58 I am ok with the proposal from last time 18:09:09 I would prefer an earlier `J` date to minimize the risk of potential harm. 18:09:38 None from me either. 18:12:24 I think I like kayaba's approach of activating after a median block timestamp 18:13:55 this is the part from jeffro's write-up that see as a source of risk: "If everything is within acceptable bounds, we ship the code using the wallet locked output cache as designed. **If not, we go back to the drawing board.**" (emphasis mine.) there are ~6 months left and 70% of the hash rate seems to mine time-locked transactions, ignoring the relay rule. 18:14:04 To be absolutely clear, this isn't a soft fork, right? Therefore, there is nothing to activate at the time point. Just something to write in the code that would take effect retroactively when the FCMP++ hard fork is activated, correct? 18:14:15 Yes 18:14:59 Yeah I guess we will have to see what happens 18:15:40 It all takes place retroactively, we're not actually deploying code at the moment, so we can also change the rule retroactively as long as people support it 18:16:03 If a malicious actor starts packing blocks with txs with nonzero unlock time before 6 months, then the credible threat can be carried out: move the ignore date earlier. That's how I understand the proposal. 18:16:05 Hi. I'm so sorry. I had something come up personally and had to dip out. 18:16:46 I prefer announcing a time and using programmatic rules when the time comes than hardcoded constants. 18:17:11 I have a strong distaste for coding constants across networks and having to deal with that. 18:17:55 Yes. Since we can ignore anything locked, the only annoyance in the case of moving the ignore height back would be to the people who honestly wanted to use the feature, even though deprecated 18:18:11 Rucknium's data shows that there is already a near-zero on-chain interest in non-zero time locks. retroactively changing the cut-off date seems to be arbitrary, wouldn't look good IMHO. 18:23:00 I agree it wouldn't be ideal, but at the end of the day we're announcing and getting rough consensus to remove `unlock_time`, this proposed ignore date is mainly just a nicety 18:23:02 chaser seems to have a concern about the proposal's details. Hopefully it can be addressed before next meeting. If not, I will put this on the agenda again. How does that sound? 18:24:01 Rucknium I'm okay with continuing the discussion in the MRL issue 18:25:24 Ok. Let's end the meeting here. 18:26:43 Thanks everyone ! 18:26:45 If we propose 3 months and someone spams in 2 months, it arguably looks even worse. I think 6 months is more reasonable in enabling lingering voices to be heard on the issue, and the option is still there to retroactively cut off 18:27:14 <0xfffc:monero.social> Thanks everyone 18:27:51 A relevant issue and PR for ASN diversity: https://github.com/monero-project/monero/issues/7090 https://github.com/monero-project/monero/pull/7935 18:28:06 thank you all! 18:34:16 jberman: granted, it could happen at any time. why do you think it's worse though with 3 months? as for lingering voices, I have seen has been barely any since that post in September on Github. 18:35:11 and as for practical interest: there were 46 non-zero time locks during Sept 1 and Oct 13, out of which only one looked intentional (= locking for more than 10 blocks). 18:39:59 "We've moved up the timeline 3 months to reduce chances of an issue" *issue* would look a bit like incompetence. Moving the timeline doesn't make it significantly harder to pull off, unless we move it to a retroactive date, which the option is on the table to do still 18:51:14 yes, I see value in reducing the chance. (that's all that can be done aside from a retroactive decision.) as a rough consensus has already formed around May 1, I think the issue is I haven't voiced my concern in an explicit way earlier. 19:09:36 Re: hardcoding a banlist. Here is the DNS banlist PR, feature is disabled by default and enabled with `--enable-dns-blocklist`: https://github.com/monero-project/monero/pull/7138 19:09:46 Here are the hardcoded domains pointing to the banlist: https://github.com/monero-project/monero/blob/893916ad091a92e765ce3241b94e706ad012b62a/src/p2p/net_node.inl#L2030-L2038 19:09:56 IP's blocked by 1 as an example: https://www.nslookup.io/domains/blocklist.moneropulse.org/dns-records/txt/ 19:10:20 For starters seems it makes sense to add @boog900 's list there? 19:22:39 <321bob321:monero.social> Make it personal choice, your force a banlist and it might not be correct 19:24:17 These nodes are defiantly not running `monerod`. I have 0 doubt. They are also almost certainly proxies, it's the only explanation of their behavior. 19:24:45 I do not see a valid reason to run a proxy node. 19:28:08 <0xfffc:monero.social> The key point is it is extremely cheap for them to run these proxies. We have to return the favour and attack there, make it costly. Some kind of PoW. Problem with that is ordinary nodes are going to pay a little bit of extra computation. 19:28:16 <0xfffc:monero.social> IMHO 19:31:40 <0xfffc:monero.social> Although if the attacker has a huge budget. That’s not gonna hurt either. 19:36:11 I don't think a PoW that prevents proxies is possible. I did have one idea which is kinda like a mini proof-of-storage: 19:36:12 If nodes build a lookup table of values using a sufficiently hard function, with the input being their address, then other nodes could request values from this table and verify their correctness. The function to create the table would have to be hard enough where nodes can't generate the values on the fly. Now if we say the table has to be 10GB big, for every address they need to 19:36:14 create a 10GB lookup table. 19:37:19 The problem is we are now adding 10GB to every nodes storage and it might take a while to startup the first time as the table is generated. 19:38:14 And also it is still economical to run proxies, it's just more expensive now. 19:38:33 <0xfffc:monero.social> Yes, you are right. They don’t even need to run all the proxies. 19:40:27 boog900 you're thinking in the right direction, but I think it should be different. We need to find something monerod can do but a proxy can't do. For example, accessing some random bytes from the blockchain when connecting. It can't be proxied because real monerod will refuse this request for an already established connection, and it doesn't allow 19:40:27 new connections from the same IP. 19:41:33 <0xfffc:monero.social> How would the client verify the monerod answer? Random bytes from blockchain. 19:41:47 <0xfffc:monero.social> By asking randomly from multiple other nodes (?) maybe. 19:41:51 The client would ask for random bytes they already have themselves 19:41:53 If they run the nodes they could just ask the main node for the bytes though 19:42:09 <0xfffc:monero.social> s/asking/verifying/ 19:42:40 <0xfffc:monero.social> Yes, but I am thinking about cases where they don’t have it. 19:42:51 right, they could ask their own node (which is modified), or they could just share a common network drive with the blockchain 19:42:54 back to square one 19:43:00 <0xfffc:monero.social> But nevermind. 19:44:22 Proof of storage is the only actual way I think, stuff like the 10GB lookup table could be used to make it more expensive. 19:45:13 Proof of storage doesn't prove that you're not running a proxy, just that you're running at least one node 19:45:19 <0xfffc:monero.social> Quick question. This is the scenario I was thinking about. 19:45:20 <0xfffc:monero.social> Imagine you have one proxy application. And you have 800 IP address that redirecting to that proxy application. 19:45:41 <0xfffc:monero.social> Exactly. I was thinking about that and you beat me to it :)) 19:47:08 It does. It connects an address to the storage so to have multiple address you must store the blockchain multiple times 19:48:27 <0xfffc:monero.social> Aha. You are generating some data based on the node specific address. 19:48:28 <0xfffc:monero.social> And the client will use that address to query authenticity of your node. 19:48:32 Oh so the order of the random data is bound to your IPv4 address? 19:48:49 Or IPv6 address, or TOR address 19:50:30 How does the requester verify a memory hard function bound to a network address without building the table for every single peer? 19:53:12 <0xfffc:monero.social> I am not sure. But I believe there should be a lot of algorithms for doing that kind of asymmetric thing. 19:53:36 it only has to compute a few of the values, randomly, not the whole table, and then request those values and check they line up. 19:54:31 <0xfffc:monero.social> Kind of zkp :)) 19:55:25 Sounds like it 19:55:36 Guess I just gotta look into the moon math..... 19:56:46 Also sounds like an expensive operation for the prover. We then need some kind of PoW by the sender to start that computation.... 19:57:30 <0xfffc:monero.social> Very innovative. Basically: 19:57:30 <0xfffc:monero.social> 1. Client should be able to verify with acceptable computation. 19:57:32 <0xfffc:monero.social> 2. Node has to have the data to be able to respond in time. 19:57:34 <0xfffc:monero.social> 3. Client will try as much as possible, say 100 times, to rest assure the node has the data. 19:57:36 <0xfffc:monero.social> 4. For node it should not be easy to just compute correct answer without the storage. 19:58:25 <0xfffc:monero.social> I see. Since it is expensive, it can introduce a new surface for another kind of DDoS. 19:59:08 ah if you are talking about proof of storage, then that is done by "encrypting" the whole blockchain using your nodes identifier/address and then to verify you requests random, sequential, blockchain data and check that you can decrypt it. The decryption should be fast and the encryption should be relatively slow. 20:00:58 `A` --outboundConnection---> `B` 20:01:00 With these types of things, an honest Node `B` is just going to reduce its incoming connection count if the connection proving step is too expensive. With the Linking Lion threat model, it's node `B` that needs to do the proving that it's a real node. 20:02:21 Not a blocker to these types of proposals, but you have to look at incentives 20:02:30 The proving should be cheep once nodes encrypt the data/create the lookup table 20:03:08 FWIW I am not advocating for proof-of-storage, encrypting every new block is probably too expensive IMO for all nodes. 20:04:01 The lookup table could work to make it more expensive for them, but might not fully stop them. 20:04:52 <0xfffc:monero.social> Maybe we can have that as feature and optional layer of security. 20:04:54 <0xfffc:monero.social> If user does not want it can opt in. And client can decide whether they pass txis to that node or not based on the user input. 20:05:23 <0xfffc:monero.social> s/opt in/opt out/ 20:06:01 <0xfffc:monero.social> Nah. Makes it too complicated. 20:06:23 IMHO, if an opt-out list that avoids outbound connections is not acceptable, then the ASmap PR could be reviewed/updated and merged: https://github.com/monero-project/monero/pull/7935 20:07:09 If we make it optional, then that's going to incentivize a higher fraction of spy nodes connections since honest, low-resource, node runners will opt out, but the spy nodes won't 20:07:13 That could reduce the Linking Lion share of an honest node's outbound connections to 1/12 = 8.3% 20:11:04 This keeps looking like the best option with the fewest downsides: diversify outgoing connections with structural information about the network 20:11:19