lederstrumpf - triangulation, right?

they're effectively creating a subnet within moneronet that they can observe. thats what i gather

i mean, its a tough cookie, because my head whittles it down to needing some way to assure that a node is connecting to peers honestly ...

but they can feed you whatever information they want

so the real peerlist is X, but they can feed you Y

of course i always head down the road to PoW here, just don't know how to thread it in

because in this authority-less network, the only authority is power burned

so if miner publishes a peer list and then for a node to accept the block it does ... something.. with challening... some subset or ... comparing its own.... something ..... * pppf *

looks like that one fizzled out

Range proof aggregation requires 2^n pairs of amounts, and blinding factors. But every transaction not have 2^n outputs. So how does Monero do it?

moneromooo: is there a list of suspected asshole peers?

because maybe there's some simple wins, eg. restricting it to 1 peer per C-class

maybefbi: you make padding commitments

UkoeHB_: i am assuming we dont have to store this padding commitments in the transaction, because their values are always the same.

UkoeHB_: bulletproofs have this initialization parameter "maximum number of parties that can produce an aggregated proof", do you know what is that number set to in monero?

maybefbi: yes dummy outputs can be generated during verification, and are not stored with the proof data; Im guessing that is max outputs, which is 16

can look for `BULLETPROOF MAX OUTPUTS`

fluffypony: you can make a list. There's already some code that does that kind of thing (one per class B IIRC).

moneromooo check #monero and #monero-dev

Monero is broken!