-
gingeropolouslederstrumpf - triangulation, right?
-
gingeropolousthey're effectively creating a subnet within moneronet that they can observe. thats what i gather
-
gingeropolousi 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 ...
-
gingeropolousbut they can feed you whatever information they want
-
gingeropolousso the real peerlist is X, but they can feed you Y
-
gingeropolousof course i always head down the road to PoW here, just don't know how to thread it in
-
gingeropolousbecause in this authority-less network, the only authority is power burned
-
gingeropolousso 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 *
-
gingeropolouslooks like that one fizzled out
-
maybefbiRange 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?
-
fluffyponymoneromooo: is there a list of suspected asshole peers?
-
fluffyponybecause maybe there's some simple wins, eg. restricting it to 1 peer per C-class
-
UkoeHB_maybefbi: you make padding commitments
-
maybefbiUkoeHB_: i am assuming we dont have to store this padding commitments in the transaction, because their values are always the same.
-
maybefbiUkoeHB_: 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?
-
UkoeHB_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
-
UkoeHB_can look for `BULLETPROOF MAX OUTPUTS`
-
moneromooofluffypony: you can make a list. There's already some code that does that kind of thing (one per class B IIRC).
-
sech1moneromooo check #monero and #monero-dev
-
sech1Monero is broken!