UkoeHB, coinstudent2048[: Have you investigated the possibility of a kind of Lightning Network in conjunction with Seraphis?

I thought a little bit, but don't see a way. Maybe someone else can give it more attention.

I honestly don't know details of Lightning Network; I think UkoeHB would answer this better (and he did).

<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

and to get an idea where to route your payments you would also need to know how much the channel contains in which direction

that would mean that for some transactions it is public how much the channel contains and who transacted with who

at least when it cannot be solved in another way to find a path in the graph

What if it's not a network? Just two nodes, one connection, for micropayments?

atomfried[m]: that could be quite possible, because in order to route a payment any path can work and the shortest path is irrelevant

Rucknium[m]: yes that could work ofc

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

<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.

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)

i dont know, maybe thats possible somehow

UkoeHB: maybe there is a way to drop all transactions inbetween and we just dont know right now

atomfried[m]: at least i dont know :D

"haveno-dex/haveno #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 ?

wfaressuissia: I was mistaken about what Drijvers is capable of

"eprint.iacr.org/2018/417.pdf#page=3", " We show that an attacker performing `−1 concurrent signing queries can create a forgery in ..."

*... l-1 concurrent ...

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?

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) ?

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

and throw an error if parsing the multisig init msg fails because it was made by old version