01:23:29 Is there research on timing side channels for wallets scanning for transactions? 01:24:40 There was a paper maybe half a year ago. Someone from Stanford, with Dan Boneh as coauthor, can't recall the main author. 01:25:21 It should be linked from the monero hackerone. 01:27:32 https://crypto.stanford.edu/timings/ 08:45:10 thanks a lot! 09:09:39 https://github.com/monero-project/monero/issues/6639#issuecomment-642937117 "I read the stackexchange comments and didn't find a convincing reason to use more than 128 bits of entropy. The Pollard's Rho algorithm can calculate the private key from the public key in O(√n) time and O(1) space" 09:10:27 I found tevador's argument compelling. It would be very interesting to see if there is consensus that we have nothing to gain in security by going beyond 128 bits 09:46:32 /win/win1 20:03:47 tevador wrote a PoC for a 14 word seed: https://github.com/tevador/monero-seed 20:04:11 knaccc: ^^ 20:05:03 whoa nice 20:05:55 wow that's incredible. using Reed-Solomon already! 20:06:46 my only comment is that maybe we should not be using more than rudimentary key stretching to add about 10-14 bits using rounds of keccak 20:06:58 otherwise issues maybe with low power simple hardware 20:33:13 Nice, all single-word issues detectable 21:24:29 does tevador not use irc? 21:27:04 He does 21:27:09 Perhaps he is not using a bouncer 21:31:22 and it uses BIP-39! 21:31:35 this is everything I has wished for 21:31:45 really nice work 21:32:03 I guess, if implemented, we should make the feature default but optional 21:32:11 Give users the ability to still generate the conventional seeds 21:34:46 I would leave it as an option in the CLI. Maybe best to not have it as an option during wallet creation in the GUI, as it may require additional explanation. 21:35:38 Yeah for the GUI we can disable it entirely