Transcript for #bitcoin-dev 2017/04/11

06:36 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.
11:49 instagibbs is a pretty decent explainer
13:06 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: ?
13:19 jonasschnelli comboy: the sighash-type is appended to the sighash-serialized tx... its a uint32 (4 bytes)
13:20 jonasschnelli that's done before hashing (the appending)
13:20 comboy jonasschnelli: right, but if it's a single byte, how can it ever be more than 255 in reality?
13:20 jonasschnelli comboy: it's not a single byte.. it's 4 bytes.
13:20 jonasschnelli But I guess we currently support 4 different bits
13:20 comboy jonasschnelli: you are appending it as 4 bytes, but you take it from the last byte of the sig, right?
13:21 jonasschnelli comboy: no.. I'm not aware that it would have something to do with the sig
13:22 comboy
13:22 jonasschnelli 1. serialize the tx for sighash (some special serialisation), append the sighash-type uin32t, double_sha256 and -> hash for ecdsa
13:24 comboy here it says 1-byte, can it come from anywhere else?
13:25 jonasschnelli hmm... checking...
13:27 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.
13:28 jonasschnelli
13:29 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
13:30 comboy right, so even though we append it as 4 bytes, the sighash value is always a single byte value, correct?
13:31 jonasschnelli comboy: Yes. Correct,... BIP66 and the DER encoding can't handle more.
13:31 jonasschnelli The sighash can internally handle 32 bits.
13:31 comboy jonasschnelli: so then we are back to my original question
13:32 jonasschnelli let me check...
13:32 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)
13:33 jonasschnelli It only cover how the tx gets hased before signing
13:33 jonasschnelli There it's always 4 bytes
13:34 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
13:35 jonasschnelli yes... this is indeed strange
13:36 comboy jonasschnelli: ok iif you find it's strange that's reassuring, I thought that maybe I'm understanding something wrong
13:36 jonasschnelli comboy: I'm looking now into this... I guess there is a reason why
13:37 comboy jonasschnelli: thanks, need to go afk for now but thanks for your time
13:38 jonasschnelli np... will response here if I have found something
16:19 arubi I think hybrid pubkeys don't have to adhere to strictder ?
16:20 arubi might be able to use the extended range with that
23:41 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
23:43 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