1 2017-09-22 04:00:27 <CryptAxe> dabura667: I'll sign your key, nobody has signed my new one yet
 2 2017-09-22 04:00:41 <CryptAxe> We'll have to find eachother
 3 2017-09-22 04:47:32 <dabura667> CryptAxe 0x074D68C3E4BB15B24407A56D91F0858CBB9B6574 ? That key is expired by the way :-P
 4 2017-09-22 04:49:29 <dabura667> 0xA72DA668A646C649325A89CA1D1321F094694EF4 is your new key I'm guessing... you know you can update the expiration date for keys, right?
 5 2017-09-22 04:55:29 <CryptAxe> Yep, but I want them to expire when they expire :) And that is the new one dabura667
 6 2017-09-22 15:21:37 <pepesza> I'm a crypto noob. I'm looking for a robust k-of-n signature scheme. Robustness as I understand it implies that malicious signer can't really sabotage process - each next signer should be able to determine if current state of signature is OK or not.
 7 2017-09-22 15:22:51 <pepesza> It does not have to be threshold signature, although being compact-ish is nice.
 8 2017-09-22 15:49:47 <pierce> probabally a silly question, but is there a good reason why, for example, blk00000.dat isn't exactly the same across bitcoind installations?  It seems to have a new hash every time I resync, which seems unnecessary.  For some context I've been playing weird IPFS/overlayfs games, syncing nodes with very low disk space.
 9 2017-09-22 19:33:30 <ossifrage> pierce, I think the blocks are written in the order they are received not in height order. The read processed is done in parallel and the order would be somewhat random
10 2017-09-22 19:34:02 <ossifrage> Then because of packing and per file size limits the database files diverge more and more as you fetch more blocks