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: member

    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 cross-referenced this on Mar 4, 2020 from issue Erlay: bandwidth-efficient transaction relay protocol by naumenkogs
  4. naumenkogs commented at 8:30 PM on March 4, 2020: member

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

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

    Please close this until it is ready to be merged

  6. naumenkogs closed this on Apr 30, 2020

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

  15. naumenkogs closed this on Dec 1, 2020

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

  17. naumenkogs commented at 8:26 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?

    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.

  18. naumenkogs commented at 11:31 AM on December 11, 2020: member

    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-04-14 21:10 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me