BSIP: 64
Title: Optional HTLC preimage length, HASH160 addition, and memo field
Authors: John Jones <jmjatlanta@gmail.com>, abitmore
Status: Installed
Type: Protocol
Created: 2019-07-09
Discussion: https://github.com/bitshares/bsips/issues/163
This BSIP proposes three changes to Hashed Time Lock Contracts (HTLC) defined in BSIP 44. The first makes the preimage length parameter optional. The second adds the HASH160 algorithm to the set of allowed hash functions. And the third creates an optional memo field.
The original implementation of Hashed Timelock Contracts included a protection to prevent an attack based on the size of the preimage. While it is still believed this is a valuable feature, this makes the implementation incompatible with a strict implementation of the popular BIP199 implemented by Bitcoin.
In addition, BIP199 includes the ability to use HASH160, which is not currently part of the BitShares implementation.
And finally, when participating in atomic cross-chain swaps (a major benefit of HTLCs), some extra information is necessary. An optional memo field should be added.
Note below is a discussion of HTLC risks in general, not risks inherent in implementing this BSIP.
An Oversized Preimage Attack There are limits to the size of a preimage that can be used. That limit is set by the blockchain itself. But when dealing with atomic swaps across blockchains, an attacker could use a preimage that is too large for one side of the 2 sided transaction. That means that an HTLC can be created on both chains, but only redeemed on one chain, and not the other.
This can be mitigated by specifying the preimage size as part of the contract. This feature is available on many bitcoin-based chains among others, but is not standard. Should the preimage size be used with an atomic swap, both sides of the transaction should include the preimage size in their contract.
One item to keep in mind is that although a preimage size may not be explicitly specified, implicit limitations may exist. For instance, a blockchain may have limitations that make a transaction valid on one chain, but invalid on another (i.e. maximum transaction size).
Timelock Attacks It is standard practice for HTLCs that the timelock should be long enough so that the block that contains the contract can be considered irreversible. This makes it possible for the redeemer to expose the preimage and still be guaranteed that the contract itself will not be reversed.
This becomes even more important with atomic swaps. The shorter duration (a.k.a “inner”) contract should allow time to achieve its own irreversibility. And the longer duration (a.k.a. “outer”) contract must allow time for irreversibility of both.
In addition, with an atomic swap both sides must consider the redemption time necessary. The creator of the inner contract must decide that should the redeemer redeem at the last moment, is there enough time to redeem the outer contract before the timelock expires.
One final consideration of the timelock portion of the contract is the use of capital. Should the other party not accept, the funds in the contract are held until the timelock expires. Long expiration times could result in missed opportunity costs.
Technically, the implementation of these changes are small.
Preimage Size: Permit that an HTLC can have the preimage size set to 0. This removes the size check during validation.
HASH160: Include this additional hashing algorithm to the list of hashes available to be used. Note: A "HASH160" is simply RIPEMD160(SHA256(preimage)).
Memo: Include this optional field for users to have an area for free-form data. It should work as does the memo field in typical BitShares transactions. This should be implemented as an extension of the htlc_create_operation. Note: adding to the htlc_object is not necessary, as existing in transaction history is sufficient.
While it is highly recommended that both halves of an atomic transaction provide explicit preimage lengths, the requirement as currently implemented in BitShares Core makes it incompatible with other "standardized" implementations. With the loosening of the preimage length requirement, atomic swaps that require such "standard" rules can be created on the BitShares blockchain.
In addition, adding the HASH160 algorithm adds to the compatibility of BitShares Core with other blockchains.
Additional discussion can be found in the issue related to this PR at #163
This document is placed in the public domain.
Bitshares BSIP 44
Bitcoin BIP 199
Preimage Size Attack
HTLC Operations memo