Transcript for #bitcoin-dev 2017/03/01

00:45 praxeology Hi. Are my latest two emails stuck in the bitcoin-dev email list moderator queue because the moderator rarely checks it? Or...? I submitted like 8 hours ago. Sorry not very familiar with the development process around here... finding it hard to communicate.
00:47 luke-jr "rarely"
00:48 praxeology I feel like the one about the UTXO Checkpoints w/ commitments is really good...
00:49 praxeology and I'm excited to see what the guys think about it
00:51 praxeology Basically I think I found a good way to do the UTXO commitment & all the good things that come with it like: trustworthy startup from a checkpoint instead of the genesis block, and allowing nodes to verify their computer didn't glitch the utxo, and more safely pruning
00:59 praxeology Here's my proposal, at least for the commitment part, which depends on the Checkpoint part that is in a brainstorming closed github issue.
00:59 praxeology And here is the UTXO Checkpoint issue :
01:00 praxeology As long as my proposal sounds reasonable I'm willing to start working on it right away
01:01 praxeology But I want feedback on whether you guys think it will work, any gotcha I overlooked
03:20 praxeology my computer took a nap... did anyone respond to my request for review while I was asleep?
09:24 maybefbi can the difficulty be less than the genesis block? can the target be higher than the genesis block?
09:31 arubi not on mainnet
09:53 maybefbi arubi, is this target valid on the mainnet: 0x0000000000000000000000000000000000000000000000000000000000000100
09:54 maybefbi i get it when the bits is 0xff00ffff
09:54 maybefbi oops i mean 0xff0001
09:55 maybefbi i meant 0xff000001
09:57 maybefbi im trying to find the edge cases of my bits to target algorithm
10:07 arubi I don't think it is, no
10:07 maybefbi ok thanks
10:10 maybefbi arubi, do all people on the bitcoin network use the same target? i hear pools dont use the flanking 000000s at the end of the target. they like the higher targets with the flanking fffffffffs because it is easier to hash under something so high
10:11 arubi I don't know the reason why there difference exist. there's one correct way to interpret bits and the hash should be below that target
10:12 maybefbi arubi, so the flanking 0s at the LSBs are part of the target?
10:19 arubi maybefbi, I don't understand the question, sorry. I actually don't know why target is calculated the way it is, or why pools use a slightly different value
10:21 maybefbi ok
15:47 praxeology Still looking for feedback on my Synchronization Checkpoints "" (plus "" to make it actually work)
18:37 arubi so re. bad sighash type for MASTv0, it appears that SIGHASHV2 is a thing now: , so that probably explains the error
19:08 arubi if anyone can make sense of it, I'd appreciate the input (hehe). I can see it follows the same scheme as v1(current) sighash algorithm, but I can't figure out what e.g. ALL would look like appended to a signature. maybe it
19:08 arubi 's the full 4 bytes now? can't tell
20:58 arubi I think you're supposed to push a signature as '<64 bytes r><64 bytes low s><4 bytes minimally encoded sighash>' where the fist byte can't be 0x00. seems like I'm at /least/ getting actual verification to fail now :)
21:26 arubi er, not 64 and not 4, 32 and 2. I'm too used to Words..