Transcript for #bitcoin-dev 2017/07/19

04:05 dongcarl I'm wondering if it'd be acceptable to make a few pull requests to `doc/init.md' under the linux section 3a to clarify how to do things mentioned in the guide, e.g. 1. proper creation of a bitcoin user and group 2. chowning and chmoding the configuration file and data directory for security reasons 3. adding the user's perferred user to bitcoin group in order to access bitcoin-cli and other bitcoind rpc clients
04:25 dongcarl Anyone?
04:55 kallewoof Best way to find out is to make a PR and see how people react.
05:01 dongcarl kallewoof: thanks
05:43 eck the bitcoin coding conventions kill me
05:43 eck why so inconsistent
05:43 eck not even consistent within the same file
08:51 Chicago Hello, I went to bitcoinuasf.org to grab the latest version of 0.14.2-uasfsegwit1.0 and found the Mac OS X binary is an unsigned dmg. Why wouldn't there be a signed release available for download?
09:56 bincap Chicago: there is https://bip148.org/ (that I run) with nice downloads over SSL, and as for uasf.co there is a small link below, if you ctrl-F for "downloaded here". I recommend to download from both and verify it's same file
09:57 bincap wait, nevermind, not that question. As for signed mac builds, don't you need mac devel licence?
10:04 bincap wumpus: I have a question about Gitian (also on ##uasf) - uafs.co produces binaries named "bitcoin-0.14.2-uasfsegwit1.0-x86_64-linux-gnu.tar.gz", while I got files without the -assfsegwit1.0 part.
10:04 bincap was there option in Gitian that affects that? or do users rename files manually
10:08 Chicago bincap, right -- looking for the signed OS X UASF build; which afaik Core team possesses the Apple code signing key so I'd have just figured/hoped there would have been a signed release.
10:09 bincap Chicago: is it important to have the signed file, on mac, or do you mean that just as a way to confirm that you got the right file and not some virus over hijacked internet connection?
10:11 Chicago bincap, well.... I do Gitian builds for regular releases and those are built with detached signatures and then eventually signed and can be verified; since UASF is contentious - -I want same assurances for the build as we go into the end of the month through these changes.
10:14 Chicago in other words, the signed releases usually go through the Gitian build process and can be verified against the builder's PGP keys.
11:08 wumpus bincap: no, there is no option that affects the file names, they're manually renamed
12:23 bincap Chicago: oh, that type of signing is always done. it's a separate file
14:23 SopaXorzTaker Uh, I propose a vanity header for addresses
14:24 SopaXorzTaker so that a hash does not need to be bruteforced to yield a nice address
14:25 SopaXorzTaker currently <id: 1> <hash: 20> <chksum: 4>
14:25 SopaXorzTaker proposed <vNonce> <<address = 25b>>
14:54 Mad7Scientist Is there a way that I can trim off the latest few blocks in bitcoin-qt?
14:54 Mad7Scientist even if I have to -renidex
15:19 Murch Mad7Scientist: Are you trying to switch to another chain?
20:30 Murch Mad7Scientist : bitcoin-cli invalidateblock <blockhash>
20:30 Murch if you're trying to switch the chain: https://bitcoin.org/en/developer-reference#preciousblock
20:31 Murch ah never mind, the latter only works at the same height
22:01 Mad7Scientist Murch, Actually I got a block checksum error and I was hoping to avoid a complete redownload
22:01 Mad7Scientist by making it go back a few blocks
22:04 Murch Mad7Scientist: Then just `-reindex` should fix it, right?
22:05 Mad7Scientist Murch, I guess so. But I assumed that the checksum error was the block itself not the other database around it
22:05 Mad7Scientist but it must not be
22:05 Murch mh
22:05 Murch gimme a minute
22:05 Mad7Scientist I also noticed that if I delete chainstate/ and index/ that I must use -reindex otherwise bitcoin-qt will try to download the whole thing from the network
22:06 Mad7Scientist I've deleted those and I'm doing -reindex now we'll see what happens
22:08 Murch Mad7Scientist: From what I find on Bitcoin.STackexchange.com reindex is the only solution and it might be a hardware issue
22:08 Murch https://bitcoin.stackexchange.com/q/51383/5406
22:08 Murch (See the comments on the question)
22:11 Mad7Scientist thank you
22:11 Mad7Scientist Use bad Maxtor USB/firewire bridge
22:12 Mad7Scientist Murch, after I have deleted index/ and chainstate/, can I delete one of the rev* or dat* files or are both sets needed?
22:13 Murch Mad7Scientist: You shouldn't delete anything
22:13 Murch Mad7Scientist just start with "-reindex"
22:13 Mad7Scientist What can I delete to save space while still allowing -reindex to work?
22:14 Murch Mad7Scientist: If you had the whole blockchain before, reindex won't need more room than before.
22:14 Murch If you are space restrained, run with -prune
22:14 Murch but then you'd definitely have to redownload if something goes wrong
22:14 Murch Mad7Scientist: In case it is a hardware issue, I hope you have a backup of your wallet.dat somewhere?
22:15 Mad7Scientist yeah
22:15 Murch Mad7Scientist: You're synching the Blockchain to an external harddrive?
22:15 Murch That explains it.
22:15 Mad7Scientist but if for some reason I want to reduce the size of the database to move it somewhere and then build it again with -reindex what can I delete other than chainstate/ and index/?
22:16 Mad7Scientist Yes external hard drive
22:18 Murch Mad7Scientist: The blocks are what takes space, all the rest is pretty small.
22:18 Mad7Scientist oh ok
22:18 Mad7Scientist rev must be some kind of metadata for the blk block files
22:19 Murch I've seen a number of issues reported when synching to external hard drive, I'd suspect that's what is causing the corrupted block checksum in the first place
22:19 Murch yeah, for reorgs