-
Notifications
You must be signed in to change notification settings - Fork 5.4k
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
Changes/clarifications to bip-330. #899
Conversation
Let's not merge it for now, considering that looking at the implementation might spawn more changes? |
Please close this until it is ready to be merged |
@naumenkogs I think there is a mistake in the image describing the protocol flow. At the bottom of the "InitRecon" step, it says that if there is success, then you move on to ExtendSketch, else you FinalizeRecon. I think those are swapped? If set reconciliation succeeds, you go straight to FinalizeRecon, while if it fails, you should attempt to extend the sketch? Also it seems to me like there is an implicit assumption that we're only going to do Erlay for wtxid-based relay, so gating this on successful negotiation of BIP 339 would make sense to me. Is that what you had in mind? If so there should probably be some mention of that in this BIP. |
Yes.
Yes. Will update the BIP with both suggestions. |
Other TODO: |
We chose to drop truncated txids, because for certain protocols (such as Lightning or Coinjoin), 128-bit IDs would mean 64-bit collision-resistance due to the Meet-in-the-Middle attack.
We think this is not enough, because finding a collision might allow an attacker to censor a transaction (especially dangerous in a Lightning-like protocol).
Other changes include just fixing small mistakes in the spec and making it more clear.
P.S.
Added more stuff, mainly switching to extensions instead of bisections. The motivation is in the PR.