Changes/clarifications to bip-330. #899

pull naumenkogs wants to merge 7 commits into bitcoin:master from naumenkogs:bip_0330_updates changing 3 files +49 −64
  1. naumenkogs commented at 7:55 PM on March 4, 2020: contributor

    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.

  2. Remove truncIDs and minor changes/clarifications to bip-330. 4acb0784b2
  3. naumenkogs commented at 8:30 PM on March 4, 2020: contributor

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

  4. luke-jr commented at 2:10 PM on April 30, 2020: member

    Please close this until it is ready to be merged

  5. naumenkogs closed this on Apr 30, 2020

  6. Link the implementation 3039172d85
  7. Switch from bisections to extensions 718bf137c0
  8. Simplify handling sketch description 28a863cc19
  9. Clarify that reconcildiff doesn't contain wtxids 4fbb40890b
  10. Update the diagram 58eb00e018
  11. Address the feedback a9089e6936
  12. naumenkogs renamed this:
    Remove truncIDs and minor changes/clarifications to bip-330.
    Changes/clarifications to bip-330.
    on Nov 21, 2020
  13. naumenkogs reopened this on Dec 1, 2020

  14. naumenkogs closed this on Dec 1, 2020

  15. sdaftuar commented at 8:08 PM on December 10, 2020: 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.

  16. naumenkogs commented at 8:26 PM on December 10, 2020: contributor

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

  17. naumenkogs commented at 11:31 AM on December 11, 2020: contributor

    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


github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bips. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2026-05-20 06:50 UTC