Transcript for #bitcoin-dev 2017/09/22

04:00 CryptAxe dabura667: I'll sign your key, nobody has signed my new one yet
04:00 CryptAxe We'll have to find eachother
04:47 dabura667 CryptAxe 0x074D68C3E4BB15B24407A56D91F0858CBB9B6574 ? That key is expired by the way :-P
04:49 dabura667 0xA72DA668A646C649325A89CA1D1321F094694EF4 is your new key I'm guessing... you know you can update the expiration date for keys, right?
04:55 CryptAxe Yep, but I want them to expire when they expire :) And that is the new one dabura667
15:21 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.
15:22 pepesza It does not have to be threshold signature, although being compact-ish is nice.
15:49 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.
19:33 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
19:34 ossifrage Then because of packing and per file size limits the database files diverge more and more as you fetch more blocks