--- Log opened Thu Jul 23 00:00:27 2020
01:03 -!- slivera [~slivera@103.231.88.10] has joined #utreexo
01:36 < kcalvinalvin> PR #173 looks good
01:37 < kcalvinalvin> Maybe we should also be thinking of contributing guidelines...
03:53 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #utreexo
03:56 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 240 seconds]
05:48 < dergoegge> there is style.md which has some guidelines, maybe we polish that and add some more stuff and we could also create issue/PR templates
05:50 < dergoegge> we should also update the readme, it still has the ibdsim/genproofs command syntax.
07:24 -!- slivera [~slivera@103.231.88.10] has quit [Remote host closed the connection]
11:23 -!- jules__ [~jules__@206.217.205.92] has joined #utreexo
11:41 -!- prusnak [sid403625@gateway/web/irccloud.com/x-gcivvuybaramuwjp] has joined #utreexo
11:41 < prusnak> hi all!
11:44 < prusnak> Ever since I saw the talk about RSA Accumulators by Benedikt Bunz I was wondering when this will come to Bitcoin. It seems the time has come, thank you! :-)
11:46 < ja> prusnak: have you tried syncing?
11:51 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection]
11:52 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #utreexo
11:53 < prusnak> not yet
12:48 < mdrollette> I tried to run the server with an old spinning disk but it fell apart from bad disk sectors after a couple hours. At least I know this code path works https://github.com/mit-dci/utreexo/blob/master/accumulator/types.go#L60
12:50 < ja> mdrollette: hmm i wonder if you are more likely to get zeroes from a bad disk?
13:53 < adiabat> mdrollette: the server is quite disk io heavy, the client does almost none
13:54 < adiabat> so if you have a slow / bad disk, the client should still work OK
13:55 < adiabat> also, interesting that you got 0000 hashes.  That panic code is in there because most of the design bugs would start with some kind of use of uninitialized data, so that caught them early
14:12 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Ping timeout: 240 seconds]
14:12 -!- jules___ [~jules__@pool-68-134-219-181.bltmmd.fios.verizon.net] has joined #utreexo
14:15 -!- jules__ [~jules__@206.217.205.92] has quit [Ping timeout: 256 seconds]
14:16 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #utreexo
14:56 -!- slivera [~slivera@103.231.88.27] has joined #utreexo
15:04 < mdrollette> makes sense - I think the drive flat-out died and remounted itself as read-only. disk and server logs are here if there's anything interesting https://gist.github.com/MDrollette/a2c4e97b1a65f22a6f30f5b8d75afc06
15:07 -!- jules___ [~jules__@pool-68-134-219-181.bltmmd.fios.verizon.net] has quit []
15:19 -!- flr09 [2e726817@46.114.104.23] has joined #utreexo
15:19 -!- flr09 [2e726817@46.114.104.23] has quit [Remote host closed the connection]
15:19 -!- flr09 [2e726817@46.114.104.23] has joined #utreexo
15:28 < dergoegge> mdrollette: If a read/write fails we don't handle it and just print a warning, thats were all the "WARNING!! ..." lines come from. On a failed read you get an empty hash back and it panics. I guess the question is if the disk died because of us and if we can prevent it...
15:30 -!- flr09 [2e726817@46.114.104.23] has quit [Remote host closed the connection]
15:38 < dergoegge> also if you have 16GB you can keep the entire forest in RAM with the `-inram` flag. 
15:41 -!- vertion [617429dd@97-116-41-221.mpls.qwest.net] has joined #utreexo
15:43 < vertion> Hey all, first of all I noticed there was no cmd binary but the folder had utreexoclient and utreexoserver binaries to be build.  I ran `./utreexoclient genproofs -net=testnet` and it errored out eventually:
15:43 < vertion> `got to height 1779000Block 1780000 add 85993370 del 61998450 pol nl 23994920 roots 10 he 85990760 re 0 ow 67750908  plus 0.00 total 14026.18 got to height 1780000read error from connection 35.188.186.244:8338 EOFBlock 1780787 add 86139130 del 62165794 pol nl 23973336 roots 15 he 86136584 re 0 ow 67910296  plus 0.00 total 14052.36 User exit signal
15:43 < vertion> received. Exiting...Pollard leaves: 23973336Found 0 satoshis in 0 utxosDone Writing`
15:43 < vertion> got to height 1779000Block 1780000 add 85993370 del 61998450 pol nl 23994920 roots 10 he 85990760 re 0 ow 67750908  plus 0.00 total 14026.18 got to height 1780000read error from connection 35.188.186.244:8338 EOFBlock 1780787 add 86139130 del 62165794 pol nl 23973336 roots 15 he 86136584 re 0 ow 67910296  plus 0.00 total 14052.36 User exit signal
15:43 < vertion> received. Exiting...Pollard leaves: 23973336Found 0 satoshis in 0 utxosDone Writing
15:43 < vertion> I don't IRC
15:47 < adiabat> vertion: thanks for checking it out.  I don't think that's an "error" exactly, but a bad message for when it's finished
15:48 < adiabat> block 1780786 is the last block on the server so it disconnects after that.  We should put in better messages that clearly say "OK done!"
15:57 < vertion> Ah okay. I don't see a proofs.dat file in the directory in which I ran genproofs
16:01 < adiabat> it goes into a subfolder
16:01 < adiabat> utree/
16:01 < adiabat> the proofs for testnet are aout 14GB
16:07 < dergoegge> but vertion ran the client and the client does not store the proofs. i think there is some confusion because the readme still has the old command syntax.
16:08 < dergoegge> adiabat: i have a PR open that updates the readme
16:09 < adiabat> dergoegge: Ah cool i see it
16:10 < adiabat> looks good, thanks.  Yeah I think the 2 binaries are easier to understand, but not if the docs still refer to only one! :)
18:12 -!- instagibbs [~instagibb@pool-71-178-191-230.washdc.fios.verizon.net] has quit [Ping timeout: 272 seconds]
18:15 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection]
18:16 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #utreexo
18:20 -!- instagibbs [~instagibb@pool-71-178-191-230.washdc.fios.verizon.net] has joined #utreexo
19:28 < vertion> Haha, yeah.  I never got the utree/ subfolder.  I'll check out the updated readme!
21:42 -!- vertion [617429dd@97-116-41-221.mpls.qwest.net] has quit [Remote host closed the connection]
22:35 < mdrollette> interestingly, I plugged in a different disk and ran the same command, but with `-inram` this time, and this disk also seems to have been corrupted after some time. different I/O errors and write failures from the first disk though. 
22:47 -!- slivera [~slivera@103.231.88.27] has quit [Remote host closed the connection]
--- Log closed Fri Jul 24 00:00:28 2020