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

Changes/clarifications to bip-330. #899

Closed
wants to merge 7 commits into from

Conversation

naumenkogs
Copy link
Member

@naumenkogs naumenkogs commented Mar 4, 2020

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.

@naumenkogs
Copy link
Member Author

Let's not merge it for now, considering that looking at the implementation might spawn more changes?

@luke-jr
Copy link
Member

luke-jr commented Apr 30, 2020

Please close this until it is ready to be merged

@naumenkogs naumenkogs closed this Apr 30, 2020
@naumenkogs naumenkogs changed the title Remove truncIDs and minor changes/clarifications to bip-330. Changes/clarifications to bip-330. Nov 21, 2020
@naumenkogs naumenkogs reopened this Dec 1, 2020
@naumenkogs naumenkogs closed this Dec 1, 2020
@sdaftuar
Copy link
Member

@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.

@naumenkogs
Copy link
Member Author

@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?

Yes.

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.


Will update the BIP with both suggestions.

@naumenkogs
Copy link
Member Author

naumenkogs commented Dec 11, 2020

Other TODO:
1. Mention protocol version 70017
2. Update q=0.02
3. Mention that sendrecon should come after wtxidrelay
4. Don't allow inbound responders and outgoing requestors
5. Rename recon sender to recon requestor
6. Tagged hash
7. Q Precision of 16 bits

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.

3 participants