--- Log opened Wed Mar 17 00:00:58 2021
00:04 -!- jungly [~jungly@host-79-26-88-253.retail.telecomitalia.it] has joined #braidpool
00:22 -!- jungly [~jungly@host-79-26-88-253.retail.telecomitalia.it] has quit [Ping timeout: 260 seconds]
00:27 -!- jungly [~jungly@host-79-26-88-253.retail.telecomitalia.it] has joined #braidpool
00:45 < jungly> belcher: Thanks for pointing to that post. I had read it a while ago and then convieniently forgot about it! It is nice to know there is a possible scalable solution once taproot is enabled. For now, we could build something with a single hub and when taproot is ready switch to the more scalable solution.
00:45 < jungly> My next concern then is with the long timeouts and how they increase with the number of hubs. I wonder if we can have shorter timeouts. This kind of becomes a subjective call.
00:45 < jungly> However, I think it might be a good idea to build a single hub solution and then scale as required using multiple hubs, or maybe an alternative technique to hide a single hub in a p2p network of miners. So to DDoS attack the hub, the attacker has to attack all miners on the p2p network. This is just an initial idea, I need to develop it more or see if it already is a published solution somewhere.
02:49 -!- jungly_ [~jungly@host-79-26-88-253.retail.telecomitalia.it] has joined #braidpool
02:55 -!- Netsplit *.net <-> *.split quits: jungly, belcher_
03:03 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #braidpool
05:37 < belcher_> payment channels with hubs does not imply that there needs to be a direct tcp connection between hub and hasher
05:38 -!- belcher_ is now known as belcher
06:37 < jungly_> belcher: Yup. Get that. :) But even with out of band communication between hub and hashers to fund channels and to receive state updates etc, we need a well known location of the hub, which could be ddos attacked. That is what you meant when you talked about ddos in the proposal too, right?
06:38 < belcher> yes, though im not sure
06:38 < belcher> i was vaguely thinking some kind of p2p network of all the hubs and hashers with messages relayed, and that would help with ddosing
06:38 < belcher> however not sure that would really work.... on the other hand today's centralized pools are also vulnerable to ddos
06:47 < jungly_> Yes. I was thinking the same, that today's pools have the same problem. But I think they probably throw cloudflare at the problem.
06:49 < jungly_> I am with you on using the p2p network to mitigate the ddos attack on the hub. I think I found some interesting papers building on chaumian mixer etc. Solving just the problem we are talking about. I just started looking into this and I think this is a problem that has been thought about, if not fully addressed by now.
06:49 < jungly_> In case you are interested, this is the first seed paper I'll be reading and following to see what else is there: http://www.csl.mtu.edu/cs6461/www/Reading/MuON_ICNP2005.pdf
06:50 < jungly_> Maybe we could use cloudflare too, but that just increases costs. Anyway. I'll keep you posted.
07:17 < belcher> chaumain mixer doesnt really do anything, because its custodial
09:09 < jungly_> Curious why you mentioned custody in ref to chaumian mixer? I am thinking of a chaumian mixer derived solution just to route communication between hashers and hub. To keep the hub safe from ddos.
09:58 < belcher> oh you mean like a mixnet
09:58 < belcher> why not just use tor
11:16 < jungly_> yeah.. sorry mixnet :) Tor will anonymises the client, in our case the hasher. But tor won't anonymise the server, i.e. the hub. So the hub's location is known and can be ddosed. We need a p2p network where it is hard to identify which node is the hub. Then we can live with one hub per instance of such a p2p pool. The paper I pointed to above presents a possible solution, and I think there will be others, I just started
11:16 < jungly_> looking into it tbh.
12:05 -!- jungly_ [~jungly@host-79-26-88-253.retail.telecomitalia.it] has quit [Ping timeout: 260 seconds]
14:01 -!- jungly [~jungly@host-79-26-88-253.retail.telecomitalia.it] has joined #braidpool
14:22 -!- jungly [~jungly@host-79-26-88-253.retail.telecomitalia.it] has quit [Ping timeout: 246 seconds]
15:32 < belcher> yes tor can anonymize the hub, if the hub runs behind a .onion
15:32 < belcher> however that wont be practical because of the latency of tor
15:32 < belcher> best to be like existing mining pools today and have a regular server socket and just deal with ddos somehow
15:33 < belcher> "hubs" are basically like mining pools, but with the lightning p2pool tech that makes it impossible for them to withhold payments, censor transactions or reorg blocks
15:33 < belcher> hubs will be run as businesses im sure
21:19 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #braidpool
21:22 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 256 seconds]
--- Log closed Thu Mar 18 00:00:59 2021