Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BOLT3: RIPEMD160 -> HASH160 where appropriate #549

Conversation

Christewart
Copy link
Contributor

I believe we were misusing RIPEMD160 where HASH160 should have been used in BOLT3.

@Christewart Christewart changed the title RIPEMD160 -> HASH160 where appropriate BOLT3: RIPEMD160 -> HASH160 where appropriate Jan 17, 2019
@@ -126,7 +126,7 @@ This output sends funds to either an HTLC-timeout transaction after the HTLC-tim
OP_DROP 2 OP_SWAP <local_htlcpubkey> 2 OP_CHECKMULTISIG
OP_ELSE
# To remote node with preimage.
OP_HASH160 <RIPEMD160(payment_hash)> OP_EQUALVERIFY
OP_HASH160 <HASH160(payment_hash)> OP_EQUALVERIFY
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's actually RIPEMD160. The trick is:

  • R is a random 32 byte value chosen by the recipient
  • H = sha256(R) is the payment hash used is the payment request and HTLC
  • so ripemd160(H) = ripemd160(sha256(R)) = hash160(R).

This script does not check that sha256(R) == H, instead it checks that hash160(R) == ripemd160(H), which saves 12 bytes.

@sstone
Copy link
Collaborator

sstone commented Jan 18, 2019

Closing. Even in the places where we could replace RIPEMD160(SHA256()) with HASH160() it's still better to be explicit.

@sstone sstone closed this Jan 18, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants