The existing htlc_create() method did not provide a way to create an HTLC from a known hash value, but instead expected user to provide the preimage, from which the method would compute the hash. Generally, one party to an atomic swap knows the preimage, but the other party does not, meaning they would be unable to create the HTLC using this method.
This PR adds support for calling htlc_create() with EITHER a hash value OR a preimage. (The caller must supply one or the other but not both.)
Additionally, this PR adds support for the Hash160 hash algorithm (sha256 followed by ripemd160), recently added in core release 4.0.0. Also in core 4.0.0, the preimage length became an optional parameter. This PR now allows preimage length to be set to 0 for unrestricted. Lastly, in htlc_redeem(), this PR adds an encoding option to indicate whether the preimage parameter should be interpreted as an ascii string or as hex-encoded bytes.
This PR changes the call signature to htlc_create(), but does so in a way that SHOULD cause existing usage to break with an exception, rather than fail silently with perhaps undesired consequences. I suspect there is not much existing usage, however, given that the requirement to know the preimage limits applicable use cases.
The existing
htlc_create()
method did not provide a way to create an HTLC from a known hash value, but instead expected user to provide the preimage, from which the method would compute the hash. Generally, one party to an atomic swap knows the preimage, but the other party does not, meaning they would be unable to create the HTLC using this method.This PR adds support for calling
htlc_create()
with EITHER a hash value OR a preimage. (The caller must supply one or the other but not both.)Additionally, this PR adds support for the Hash160 hash algorithm (sha256 followed by ripemd160), recently added in core release 4.0.0. Also in core 4.0.0, the preimage length became an optional parameter. This PR now allows preimage length to be set to 0 for unrestricted. Lastly, in
htlc_redeem()
, this PR adds anencoding
option to indicate whether the preimage parameter should be interpreted as an ascii string or as hex-encoded bytes.This PR changes the call signature to
htlc_create()
, but does so in a way that SHOULD cause existing usage to break with an exception, rather than fail silently with perhaps undesired consequences. I suspect there is not much existing usage, however, given that the requirement to know the preimage limits applicable use cases.Note that this PR depends on python-graphenelib/pull/176.