📅 Original date posted:2014-07-17
📝 Original message:I'm moving this design document to a gist so that I can integrate
changes as they come up:
https://gist.github.com/kazcw/43c97d3924326beca87d
One thing that I think is an important improvement over my initial
idea is that the bloom filters don't need to be kept around and built
up, they can just be one-shot and clear any matching entries from the
set of known-knowns upon arrival -- provided a node is careful to
ensure the txes it wants to forget are known-known-known (which isn't
as bad as it sounds) to the peer it's telling it's forgetting them
when the forget-filter arrives.
On Thu, Jul 17, 2014 at 3:46 PM, Gavin Andresen <gavinandresen at gmail.com> wrote:
>
> A couple of half-baked thoughts:
>
> On Thu, Jul 17, 2014 at 5:35 PM, Kaz Wesley <keziahw at gmail.com> wrote:
>>
>> If there's support for this proposal, I can begin working on the specific
>> implementation details, such as the bloom filters, message format, and
>> capability advertisment, and draft a BIP once I have a concrete proposal for
>> what those would look like and a corresponding precise cost/benefit analysis.
>
>
> I'd encourage you to code up a prototype first (or at the same time), in whatever programming language / networking library you're most familiar with.
>
> Maybe not even using the existing p2p protocol; there could be a mining-only very-fast-block-propagation network separate from the existing p2p network.
>
> Combining your optimizations with "broadcast as many near-miss blocks as bandwidth will allow" on a mining backbone network should allow insanely fast propagation of most newly solved blocks.
>
> --
> --
> Gavin Andresen
Thanks Gavin, I am planning on working out the design details as I
work on a prototype. I have the beginnings of a previous shot at
implementing this in bitcoind to start from but my new design has some
important improvements to add to that.
-kaz
Kaz Wesley [ARCHIVE] /
npub1lw…z8zjm
2023-06-07 15:24:07
in reply to nevent1q…pmyl
Author Public Key
npub1lwrwp8dzn9x5nqc7d735e0nuwxh0nyz5ezkfpjzr332efdxw9asq4z8zjmPublished at
2023-06-07 15:24:07Event JSON
{
"id": "ad2bd0bab058a425a8e64742e95288c946a44d41dcdc8c4596cc1658f39d7e64",
"pubkey": "fb86e09da2994d49831e6fa34cbe7c71aef99054c8ac90c8438c5594b4ce2f60",
"created_at": 1686151447,
"kind": 1,
"tags": [
[
"e",
"3507527acf6651445fc18e718512a320c7c5edde322b321b00914bf719d85722",
"",
"root"
],
[
"e",
"c81929a868839f954dd1844776bcb365a7fdde4172956558ab463abeadac7a44",
"",
"reply"
],
[
"p",
"857f2f78dc1639e711f5ea703a9fc978e22ebd279abdea1861b7daa833512ee4"
]
],
"content": "📅 Original date posted:2014-07-17\n📝 Original message:I'm moving this design document to a gist so that I can integrate\nchanges as they come up:\nhttps://gist.github.com/kazcw/43c97d3924326beca87d\nOne thing that I think is an important improvement over my initial\nidea is that the bloom filters don't need to be kept around and built\nup, they can just be one-shot and clear any matching entries from the\nset of known-knowns upon arrival -- provided a node is careful to\nensure the txes it wants to forget are known-known-known (which isn't\nas bad as it sounds) to the peer it's telling it's forgetting them\nwhen the forget-filter arrives.\n\nOn Thu, Jul 17, 2014 at 3:46 PM, Gavin Andresen \u003cgavinandresen at gmail.com\u003e wrote:\n\u003e\n\u003e A couple of half-baked thoughts:\n\u003e\n\u003e On Thu, Jul 17, 2014 at 5:35 PM, Kaz Wesley \u003ckeziahw at gmail.com\u003e wrote:\n\u003e\u003e\n\u003e\u003e If there's support for this proposal, I can begin working on the specific\n\u003e\u003e implementation details, such as the bloom filters, message format, and\n\u003e\u003e capability advertisment, and draft a BIP once I have a concrete proposal for\n\u003e\u003e what those would look like and a corresponding precise cost/benefit analysis.\n\u003e\n\u003e\n\u003e I'd encourage you to code up a prototype first (or at the same time), in whatever programming language / networking library you're most familiar with.\n\u003e\n\u003e Maybe not even using the existing p2p protocol; there could be a mining-only very-fast-block-propagation network separate from the existing p2p network.\n\u003e\n\u003e Combining your optimizations with \"broadcast as many near-miss blocks as bandwidth will allow\" on a mining backbone network should allow insanely fast propagation of most newly solved blocks.\n\u003e\n\u003e --\n\u003e --\n\u003e Gavin Andresen\n\nThanks Gavin, I am planning on working out the design details as I\nwork on a prototype. I have the beginnings of a previous shot at\nimplementing this in bitcoind to start from but my new design has some\nimportant improvements to add to that.\n\n-kaz",
"sig": "745b38394116158fb2ecbbad5ec2fc1069f077647ee4aa4798fa4c499e911a8df4605417e01ec279032cd3bbc4db97ed71a265ec556f78e508f30dccc0bb11e4"
}