1 2017-04-11 06:36:17 <samlewis> Anyone around that has a reasonable understanding of asicboost? I've read through the paper and the 20% efficiency gain that is spouted everywhere seems grossly overstated.. it might just be that I don't understand the power of asics though, would love to talk it through.
 2 2017-04-11 11:49:36 <instagibbs> http://www.mit.edu/~jlrubin//public/pdfs/Asicboost.pdf is a pretty decent explainer
 3 2017-04-11 13:06:54 <comboy> do I understand correctly that sighash type is extracted as the last byte of the signature? and that it can have like 6 different values? if so why there's a lot of big integeres as sighash type here: https://raw.githubusercontent.com/bitcoin/bitcoin/master/src/test/data/sighash.json ?
 4 2017-04-11 13:19:04 <jonasschnelli> comboy: the sighash-type is appended to the sighash-serialized tx... its a uint32 (4 bytes)
 5 2017-04-11 13:20:09 <jonasschnelli> that's done before hashing (the appending)
 6 2017-04-11 13:20:12 <comboy> jonasschnelli: right, but if it's a single byte, how can it ever be more than 255 in reality?
 7 2017-04-11 13:20:32 <jonasschnelli> comboy: it's not a single byte.. it's 4 bytes.
 8 2017-04-11 13:20:45 <jonasschnelli> But I guess we currently support 4 different bits
 9 2017-04-11 13:20:55 <comboy> jonasschnelli: you are appending it as 4 bytes, but you take it from the last byte of the sig, right?
10 2017-04-11 13:20:56 <jonasschnelli> SIGHASH_ALL, SIGHASH_NONE, SIGHASH_SINGLE, SIGHASH_ANYONECANPAY
11 2017-04-11 13:21:22 <jonasschnelli> comboy: no.. I'm not aware that it would have something to do with the sig
12 2017-04-11 13:22:09 <comboy> https://github.com/bitcoin/bitcoin/blob/8152d3fe57a991e9088d0b9d261d2b10936f45a9/src/script/interpreter.cpp#L118
13 2017-04-11 13:22:12 <jonasschnelli> 1. serialize the tx for sighash (some special serialisation), append the sighash-type uin32t, double_sha256 and -> hash for ecdsa
14 2017-04-11 13:24:06 <comboy> here it says 1-byte, can it come from anywhere else?
15 2017-04-11 13:25:00 <jonasschnelli> hmm... checking...
16 2017-04-11 13:27:04 <jonasschnelli> comboy: Oh. Yes. I was looking at the compact signatures... the broadcasted DER encoded signatures have a single SIGHASH-TYPE byte at the end.
17 2017-04-11 13:28:37 <jonasschnelli> https://github.com/bitcoin/bitcoin/blob/8152d3fe57a991e9088d0b9d261d2b10936f45a9/src/script/sign.cpp#L34
18 2017-04-11 13:29:35 <jonasschnelli> comboy: the SignatureHash hashes over the serilaized tx and the sighash-type (4bytes),... but the DER encoded signatures have a 1byte sig-hash-type at the end
19 2017-04-11 13:30:08 <comboy> right, so even though we append it as 4 bytes, the sighash value is always a single byte value, correct?
20 2017-04-11 13:31:20 <jonasschnelli> comboy: Yes. Correct,... BIP66 and the DER encoding can't handle more.
21 2017-04-11 13:31:29 <jonasschnelli> The sighash can internally handle 32 bits.
22 2017-04-11 13:31:40 <comboy> jonasschnelli: so then we are back to my original question
23 2017-04-11 13:32:27 <jonasschnelli> let me check...
24 2017-04-11 13:32:59 <jonasschnelli> The test you have linked above is only the sighash test... that test has nothing to do with DER encoding (the last 1 byte)
25 2017-04-11 13:33:10 <jonasschnelli> It only cover how the tx gets hased before signing
26 2017-04-11 13:33:15 <jonasschnelli> There it's always 4 bytes
27 2017-04-11 13:34:36 <comboy> right.. but why test inputs that can never appear in reality and the fact that they can be currently present is only because of specifics of the current implementation? I'm not talking about signing, I understand there's 4 bytes there, maybe we'll use them one day maybe not, I'm just talking about this test data
28 2017-04-11 13:35:32 <jonasschnelli> yes... this is indeed strange
29 2017-04-11 13:36:23 <comboy> jonasschnelli: ok iif you find it's strange that's reassuring, I thought that maybe I'm understanding something wrong
30 2017-04-11 13:36:43 <jonasschnelli> comboy: I'm looking now into this... I guess there is a reason why
31 2017-04-11 13:37:40 <comboy> jonasschnelli: thanks, need to go afk for now but thanks for your time
32 2017-04-11 13:38:03 <jonasschnelli> np... will response here if I have found something
33 2017-04-11 16:19:59 <arubi> I think hybrid pubkeys don't have to adhere to strictder ?
34 2017-04-11 16:20:15 <arubi> might be able to use the extended range with that
35 2017-04-11 23:41:22 <comboy> re this test file, I guess it was just completely randomly generated, including these integers, scripts there don't make any sense just some randnom opcodes e.g. ""OP_CHECKSIG 2 OP_CHECKSIG OP_VERIF OP_CHECKSIG OP_VERIF OP_CHECKSIG 1", it's not testing any edge cases or anything
36 2017-04-11 23:43:23 <comboy> I guess it still is of some use, although alternative implementations which include it hoping to match bitcoin core behavior may be a bit dissapointed