BSIP82: Add ed25519-sha-256 Support for HTLC

bsip-0078.md

@@ -0,0 +1,66 @@
+```
+BSIP: 77
+Title: ed25519-sha-256 algorithm addition to HTLC 
+Authors: ioBanker <Ammar.M@ioBanker.com>
+Status: Draft
+Type: Protocol
+Created: 2019-10-03
+Discussion: https://github.com/bitshares/bitshares-core/issues/2018
+```
+
+Abstract
+===================
+This BSIP proposes additional feature to Hashed Time Lock Contracts (HTLC) defined in [BSIP 44](https://github.com/bitshares/bsips/blob/master/bsip-0044.md). It adds the ed25519-sha-256 algorithm to the set of allowed hash functions.
+
+Motivation
+=================
+BitShares is aiming to become bridge of assets for market makers providing cross-currency liquidity as a software to individuals and corporate, supporting the ed25519-sha-256 pre-image hashing algorithm would enable BitShares to become compatible with the financial system transmission and it's future functions.
+
+Today banks are deploying solutions for Cross-Currency Settlement and FX Market Making.
+
+When those solutions are ILP-enabled, banks won’t have to change much – market makers will still hold accounts at their banks and they'll establish relationships with the other banks and market makers with whom they want to transact. ILP enables transactions across any number of different ledgers and exchanges using cryptographic escrow and a specialized two-phase commit protocol.
+
+Risks
+===============
+**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.
+
+Specifications
+=========
+
+**ed25519-sha-256**: Include this additional hashing algorithm to the list of hashes available to be used.
+
+**ILP PREIMAGE-SHA-256 Crypto-Conditions**: To calculate a condition and fulfillment in the proper format, you should use a [Crypto-Conditions](https://tools.ietf.org/html/draft-thomas-crypto-conditions-03) library such as [five-bells-condition](https://github.com/interledgerjs/five-bells-condition). For fulfillments, ILP recommends using one of the following methods to generate the fulfillment:
+
+Use a cryptographically secure source of randomness to generate at least 32 random bytes.
+Follow Interledger Protocol's [PSK specification](https://github.com/interledger/rfcs/blob/master/deprecated/0016-pre-shared-key/0016-pre-shared-key.md) and use an HMAC-SHA-256 of the ILP packet as the fulfillment.
+
+
+Discussion
+===================
+Adding the ed25519-sha-256 algorithm adds to the compatibility of BitShares Core with other blockchains.
+
+
+Copyright
+====================
+This document is placed in the public domain.
+
+See Also
+===================
+[Bitshares BSIP 44](https://github.com/bitshares/bsips/blob/master/bsip-0044.md)   
+[Support ed25519-sha-256 algorithm to enable cross chain trustless swap between BitShares and ILP](https://github.com/bitshares/bitshares-core/issues/2018)  
+[Interledger crypto-conditions implemented in C, including simple JSON api](https://github.com/ssadler/libcryptoconditions)
+[JS code for creating the Condition & Fulfillment on interledger](https://github.com/ioBanker/codes/blob/master/escrow.js)