02:07:53 lederstrumpf - triangulation, right? 02:09:56 they're effectively creating a subnet within moneronet that they can observe. thats what i gather 02:12:03 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 ... 02:12:15 but they can feed you whatever information they want 02:12:26 so the real peerlist is X, but they can feed you Y 02:12:58 of course i always head down the road to PoW here, just don't know how to thread it in 02:13:21 because in this authority-less network, the only authority is power burned 02:14:44 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 * 02:14:58 looks like that one fizzled out 05:50:07 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? 05:54:09 moneromooo: is there a list of suspected asshole peers? 05:54:38 because maybe there's some simple wins, eg. restricting it to 1 peer per C-class 05:57:14 maybefbi: you make padding commitments 05:59:26 UkoeHB_: i am assuming we dont have to store this padding commitments in the transaction, because their values are always the same. 06:19:11 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? 07:19:02 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 07:20:58 can look for `BULLETPROOF MAX OUTPUTS` 11:08:54 fluffypony: you can make a list. There's already some code that does that kind of thing (one per class B IIRC). 11:09:14 moneromooo check #monero and #monero-dev 11:09:17 Monero is broken!