tfchain client: send_money error

[zaibon]

In the grid broker, when we try to refund some token back to the user, I get this error:

[Wed10 11:06] - base.py           :224 :grid_broker-cd53529f-bea7-4791-84cd-4553febfb30c (grid_broker) - ERROR    - error executing action _watch_transactions:
Traceback (most recent call last):
  File "/opt/code/github/threefoldtech/grid_broker/templates/grid_broker/grid_broker.py", line 64, in _watch_transactions
    connection_info = self._deploy(tx, data)
  File "/opt/code/github/threefoldtech/grid_broker/templates/grid_broker/grid_broker.py", line 87, in _deploy
    task = s.schedule_action('install').wait(die=True)
  File "/opt/code/github/threefoldtech/0-robot/zerorobot/task/task.py", line 141, in wait
    raise RuntimeError(self.eco.message)
RuntimeError: Not enough free space for namespace creation with size 10 and type SSD,NVME

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/opt/code/github/threefoldtech/0-robot/zerorobot/task/task.py", line 81, in execute
    self._result = self._execute_greenlet.get(block=True, timeout=None)
  File "src/gevent/greenlet.py", line 709, in gevent._greenlet.Greenlet.get
  File "src/gevent/greenlet.py", line 317, in gevent._greenlet.Greenlet._raise_exception
  File "/usr/local/lib/python3.5/dist-packages/gevent/_compat.py", line 47, in reraise
    raise value.with_traceback(tb)
  File "src/gevent/greenlet.py", line 766, in gevent._greenlet.Greenlet.run
  File "/opt/code/github/threefoldtech/grid_broker/templates/grid_broker/grid_broker.py", line 71, in _watch_transactions
    self._refund(tx)
  File "/opt/code/github/threefoldtech/grid_broker/templates/grid_broker/grid_broker.py", line 99, in _refund
    self._wallet.send_money((tx.amount - DEFAULT_MINERFEE)/TFT_PRECISION, tx.from_addresses[0])
  File "/opt/code/github/threefoldtech/jumpscale_lib/JumpscaleLib/clients/blockchain/rivine/RivineWallet.py", line 423, in send_money
    locktime=locktime)
  File "/opt/code/github/threefoldtech/jumpscale_lib/JumpscaleLib/clients/blockchain/rivine/RivineWallet.py", line 662, in _create_transaction
    self._sign_transaction(transaction)
  File "/opt/code/github/threefoldtech/jumpscale_lib/JumpscaleLib/clients/blockchain/rivine/RivineWallet.py", line 721, in _sign_transaction
    input.sign(input_idx=index, transaction=transaction, secret_key=key.secret_key)
  File "/opt/code/github/threefoldtech/jumpscale_lib/JumpscaleLib/clients/blockchain/rivine/types/transaction.py", line 2094, in sign
    self._fulfillment.sign(sig_ctx=sig_ctx)
  File "/opt/code/github/threefoldtech/jumpscale_lib/JumpscaleLib/clients/blockchain/rivine/types/unlockconditions.py", line 84, in sign
    sig_hash = sig_ctx['transaction'].get_input_signature_hash(extra_objects=extraobjs)
  File "/opt/code/github/threefoldtech/jumpscale_lib/JumpscaleLib/clients/blockchain/rivine/types/transaction.py", line 403, in get_input_signature_hash
    buffer.extend(binary.encode(coin_input.parent_id, type_='hex'))
  File "/opt/code/github/threefoldtech/jumpscale_lib/JumpscaleLib/clients/blockchain/rivine/encoding/binary.py", line 41, in encode
    result.extend(bytearray.fromhex(hstr))
ValueError: non-hexadecimal number found in fromhex() arg at position 62

[LeeSmet]

caused by https://github.com/threefoldtech/jumpscale_lib/blob/development/JumpscaleLib/clients/blockchain/rivine/encoding/binary.py#L40

I'm guessing the idea of this line is to strip the common '0x' prefix which is usually present in a hex string (though not here). The problem is however that lstrip removes all leading chars which are either '0' or 'x'. Since we don't have a '0x' prefix here when encoding coin input ids, but leading '0' and 'x' is still stripped, this causes ids with a leading 0 to have this char stripped. The result is that the id is trimmed to 63 bytes, which is no longer valid hex. Interestingly, if the second char would also be '0', there would be no evident problem because the hash would be 62 chars long, which is valid hex (although the chain would reject the resulting signature).

All in all, an average of slightly less then 1/16 ids are affected by this

[LeeSmet]

Fixed in d1ddcfcc4c1c260e1fd94614e1454ab84baace00