Description of HTLC support in Zano

Function atomics_create_htlc_proposal initiate atomic swap process, or could be a response to the process initiated on the other blockchain. It create transaction with HTLC, which can be redeemed only by providing origin of the hash, specified in the contract. If no redeem happened during period of lock_blocks_count, then coins automatically considered to be returned to the sender wallet(no additional actions needed to get refunded).

Arguments:

  • amount - amount of the coins going into HTLC. Fee for redeem transaction will be withheld from this amount too.
  • counterparty_address - an address of the other part of atomic swap process
  • lock_blocks_count - amount of blocks, which define a period of time, allotted for the redeem operation. 1 block - 1 minute, 1440 blocks is est 1 day.
  • htlc_hash - Hash of the secret, if this field specified, then HTLC created with this hash, if this is empty, then wallet will derive secret in deterministic way, and in response will be returned derived_origin_secret, which will be the key for redeem of this HTLC and, obviously, for HTLC created by counter-party in the other blockchain. At this moment by default RPC API in wallet support only sha256 as hashing for HTLC, but we also have implemented support of RIPEMD-160 in core and wallet, so if anyone need access to this hash, please make a issue in our github, and we'll be happy to enable support of this hash too.

Response:

  • result_tx_blob - Created and broadcasted transaction itself.
  • result_tx_id - Created transaction id .
  • derived_origin_secret_as_hex - If htlc_hash field in request was empty, then this field will keep secret, which was deterministically created by sender wallet(If wallet file was lost and recovered from backup with seed phrase, then secret for any particular HTLC created by this wallet will be possible to restore). This field is HEX-encoded, but sha256 supposed to be calculated from raw blob of this secret.
Language