BSIP82: Add ed25519-sha-256 Support for HTLC #237
Conversation
bsip-0078.md
Outdated
|
|
||
| Risks | ||
| =============== | ||
| **Note** below is a discussion of HTLC risks in general, not risks inherent in implementing this BSIP. |
There was a problem hiding this comment.
This is duplicated from elsewhere, right? Please remove and leave only those risks that are specific to this proposal (if any).
There was a problem hiding this comment.
Yes, it's duplicated from BSIP: 64, It has same risks of HASH160 algorithm.
bsip-0078.md
Outdated
| Specifications | ||
| ========= | ||
|
|
||
| **ed25519-sha-256**: Include this additional hashing algorithm to the list of hashes available to be used. |
There was a problem hiding this comment.
Please explain - is the addition of this hash function necessary and sufficient for participation in ILP? In other words, does ILP support other hashing functions like those that we already have, and does ILP demand other things as well ("crypto-conditions")?
There was a problem hiding this comment.
To satisfy a full atomic swap transactions between BitShares and XRP (ILP Blockchain) for example, A crypto condition will be communicated from "ILP offChain" user to "onChain" user, so user "onChain" will create HTLC using that condition with "ed25519-sha-256" algorithm, when the fulfillment appears at "offChain" side, the "onChain" user will be using that fulfillment to release the transaction "onChain", BitShares blockchain suppose to be validating if that fulfillment is true for the earlier provided condition in that HTLC.
bsip-0078.md
Outdated
|
|
||
| **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: |
There was a problem hiding this comment.
Above your proposal sounds like it is only about adding a hashing function. Now you say that we must "calculate a condition and fulfillment in the proper format". Whatever that means, it would probably be a much bigger change than the mere addition of a hash function.
There was a problem hiding this comment.
The hash function ed25519-sha-256 is not a single equation.
bsip-0078.md
Outdated
|
|
||
| **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. |
There was a problem hiding this comment.
Generating preimage is client responsibility, not an on-chain protocol issue. It should not part of the specification.
There was a problem hiding this comment.
It's a part of specification since it's not only used by client.
ryanRfox
changed the title
There was a problem hiding this comment.
Overall a good start. Typically we do the rough draft within the Issue, but let's do it here as it's close enough at this point. As noted by @pmconrad this document should focus on the addition of the new hash function in the specification. The motivation may be ILP focused.
I'll need to do some additional research into this algo and ILP to determine what requirements they make on it use. We have a desire to use the minimum number of robust hash algos within our protocol to facilitate interoperability with viable external systems.
|
What is the motivation of this BSIP in terms of additionally available use-cases? |
I believe supporting XRP Escrow encryption algorithms within BitShares HTLC algorithms is a good step to the future of having atomic swaps between BitShares and CMC Ranked #3 XRP networks. Also XRP has built in API which is supported by Blockchain coders themselves, this would help us to integrate some standard API calls to any XRP node and give users the ability to trust any XRP node to execute the escrow transactions. I say if it's doable, lets do it, if it's complex and hard to do now, lets keep it in mind. |
|
If the goal is to connect our chain to XRP then we should start from there and see what's necessary to achieve it. Like I said above, the mere addition of a new hash function is not it. |
No description provided.