14:32:41 <dEBRUYNE> UkoeHB, coinstudent2048[: Have you investigated the possibility of a kind of Lightning Network in conjunction with Seraphis?
15:04:33 <UkoeHB> I thought a little bit, but don't see a way. Maybe someone else can give it more attention.
16:13:52 <coinstudent2048[> I honestly don't know details of Lightning Network; I think UkoeHB would answer this better (and he did).
18:26:52 <atomfried[m]> <dEBRUYNE> "UkoeHB, coinstudent2048: Have..." <- i have thought a bit about privacy in a lightning network like structure for monero, one problem is finding a path in a graph. when the graphstructure is know, it is known who has opened channels with each other
18:27:18 <atomfried[m]> and to get an idea where to route your payments you would also need to know how much the channel contains in which direction
18:28:01 <atomfried[m]> that would mean that for some transactions it is public how much the channel contains and who transacted with who
18:28:26 <atomfried[m]> at least when it cannot be solved in another way to find a path in the graph 
18:29:09 <Rucknium[m]> What if it's not a network? Just two nodes, one connection, for micropayments?
18:29:37 <atomfried[m]> atomfried[m]: that could be quite possible, because in order to route a payment any path can work and the shortest path is irrelevant 
18:29:48 <atomfried[m]> Rucknium[m]: yes that could work ofc
18:30:55 <UkoeHB> the problem is you can't merge many intermediate tx together, so closing a channel would entail submitting a big set of tx, which may risk double spend attacks
18:34:52 <atomfried[m]> <atomfried[m]> "that could be quite possible..." <- maybe because of that knowing the actual graph can be omitted and every node only knows its neighbours and the strongly connected component it is a part of. 
18:34:52 <atomfried[m]> Then when routing a payment a node only needs to know if using an edge will get the payment closer to the target or not(without knowing the target and the graph)
18:35:01 <atomfried[m]> i dont know, maybe thats possible somehow
18:35:55 <atomfried[m]> UkoeHB: maybe there is a way to drop all transactions inbetween and we just dont know right now
18:40:05 <atomfried[m]> atomfried[m]: at least i dont know :D
19:09:02 <wfaressuissia> "https://github.com/haveno-dex/haveno/issues/103", "... then the attacker can learn the private key shares of other participants.", what attack does allow to extract private key shares during signing without commit&reveal ?
19:10:06 <UkoeHB> wfaressuissia: I was mistaken about what Drijvers is capable of
19:11:06 <wfaressuissia> "https://eprint.iacr.org/2018/417.pdf#page=3", " We show that an attacker performing `−1 concurrent signing queries can create a forgery in ..."
19:11:44 <wfaressuissia> *...  l-1 concurrent ...
19:27:52 <UkoeHB> ok? It doesn't really matter the exact number of parallel attempts to execute an attack. Are you going to sit down and code up a fix?
20:11:48 <wfaressuissia> In total tx construction will take 3 rounds without commit&reveal (1st - choose outputs, destinations and all params independent from private key shares; 2nd - everyone sends to others partial key images, derivatives from alpha_a_j, alpha_b_j,; 3rd everyone sends to initiator challenge responses r_pi_j_e) ?
20:36:24 <UkoeHB> yep sounds right; basically you just need to update the awkward `LRki` struct to include 2x as many alpha values, then when constructing partial response, you sort all the alpha pairs and merge them
20:41:47 <UkoeHB> and throw an error if parsing the multisig init msg fails because it was made by old version