In the function Script.evaluate on p116 and in line 134 in script.py at :
Chapter 6, script.py
would it not be better to have :
if decode_num(stack.pop()) == 0:
instead of :
if stack.pop() == b'':
since the functions decode_num and encode_num in op.py already encapsulate the mapping between byte vectors on the stack and signed integers as described in Bitcoin Wiki. decode_num already has the test if element == b'': return 0. Other representations of zero are possible besides the null length vector, eg 0x00 (1 zero byte), 0x00 0x00 (2 zero bytes), and 0x80 ('minus zero'). It is maybe best to handle all of these within decode_num to keep them all in the one place. If any of these other representations of zero ended up at the top of the stack on completion of the script then Script.evaluate would currently return True and then Tx.verify_input would return True, thus validating an input that maybe should not be considered valid. Not sure if there are any corner cases where this could arise, but maybe a good idea to guard against them anyway - defensive coding. At least it would be tidier to put it through decode_num.
In the function
Script.evaluateon p116 and in line 134 inscript.pyat : Chapter 6, script.py would it not be better to have :if decode_num(stack.pop()) == 0:instead of :if stack.pop() == b'':since the functionsdecode_numandencode_numinop.pyalready encapsulate the mapping between byte vectors on the stack and signed integers as described in Bitcoin Wiki.decode_numalready has the testif element == b'': return 0. Other representations of zero are possible besides the null length vector, eg0x00(1 zero byte),0x00 0x00(2 zero bytes), and0x80('minus zero'). It is maybe best to handle all of these withindecode_numto keep them all in the one place. If any of these other representations of zero ended up at the top of the stack on completion of the script thenScript.evaluatewould currently returnTrueand thenTx.verify_inputwould returnTrue, thus validating an input that maybe should not be considered valid. Not sure if there are any corner cases where this could arise, but maybe a good idea to guard against them anyway - defensive coding. At least it would be tidier to put it throughdecode_num.