Skip to content

Elaborate hash function design in BIP152#397

Merged
luke-jr merged 3 commits intobitcoin:masterfrom
sipa:clarifymath
Jun 7, 2016
Merged

Elaborate hash function design in BIP152#397
luke-jr merged 3 commits intobitcoin:masterfrom
sipa:clarifymath

Conversation

@sipa
Copy link
Copy Markdown
Member

@sipa sipa commented Jun 3, 2016

No description provided.

@luke-jr
Copy link
Copy Markdown
Member

luke-jr commented Jun 3, 2016

@TheBlueMatt


In case 1, we're good. In cases 2, 3, or 4, we request the full transaction because we know we're uncertain. Only in case 5, we fail to reconstruct. The chance that case 5 does not occur in any of the ''t'' transactions in a block is ''(1 - (1 - r) * m * (1 - P) * P^(m - 1))^t''. This expression is well approximated by ''1 - m * t * r / 2^B''. Thus, if we want only one in F block transmissions between honest nodes to fail, we need ''log2(F * m * t)'' bits hash functions.

This means that ''B = 48'' bits short IDs suffice blocks with up to ''t = 10000'' transactions, mempools up to ''m = 100000'' transactions, with failure to reconstruct up to once every ''F = 281474'' blocks. Since failure to reconstruct just means we fall back to normal inv/header based relay, it isn't necessary to avoid such failure completely. It just needs to be sufficiently rare they have a lower impact than random transmission failures (for example, network disconnection, node overloaded, ...).
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

once every ''F = 281474'' blocks. < needs to mention that every link in the network is multiple comparisons.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

That's already accounted for in the log2(F * m * t) formula. If it's not clear enough, that should be clarified where that formula is introduced.

@sipa sipa changed the title Eloborate hash function design in BIP152 Elaborate hash function design in BIP152 Jun 4, 2016
@sipa sipa force-pushed the clarifymath branch 2 times, most recently from c4dbc44 to 6d1b095 Compare June 4, 2016 12:10
@TheBlueMatt
Copy link
Copy Markdown
Contributor

TheBlueMatt commented Jun 7, 2016

Didnt check any of the math, but general text seems reasonable. ACK.

@TheBlueMatt
Copy link
Copy Markdown
Contributor

ACK

@luke-jr luke-jr merged commit c08a24c into bitcoin:master Jun 7, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants