📅 Original date posted:2014-04-21
📝 Original message:Pieter tried it already. If the two nodes views of each others mempools are
not exactly in alignment it ends up being slower than just sending the data
immediately and redundantly.
On Mon, Apr 21, 2014 at 6:38 PM, Mark Friedenbach <mark at monetize.io> wrote:
> Yes, it certainly can be improved in this way. You can even extend the
> idea to distribute partial proofs of work (block headers + Merkle lists
> which represent significant but not sufficient work), and 'prime' your
> memory pools with the transactions contained within.
>
> This is, btw, basically what p2pool does, which is why last time I
> calculated you get roughly 1% better return from p2pool than a zero-fee
> mining pool would get you, specifically because of the lower stale rate.
>
> On 04/21/2014 09:22 AM, Paul Lyon wrote:
> > I haven't done the math on this, so it may be a terrible idea. :)
> >
> > I've been wondering if block propagation times could also be improved by
> > allowing peers to request the list of transaction hashes that make up a
> > block, and then making a follow-up request to only download any
> > transactions not currently known. I'm not sure what percentage of
> > transactions a node will usually already have when it receives a new
> > block, but if it's high I figure this could be beneficial.
> >
>
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140421/f3aba223/attachment.html>;
Mike Hearn [ARCHIVE] /
npub17t…4qgyd
2023-06-07 15:19:13
in reply to nevent1q…wpu8
Author Public Key
npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgydSeen on
wss://relay.noswhere.comPublished at
2023-06-07 15:19:13Event JSON
{
"id": "a1d9c74dad00cc3ee01271c0717f9172ac17b1a3c640bf5e4e60288fd6492f3a",
"pubkey": "f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2",
"created_at": 1686151153,
"kind": 1,
"tags": [
[
"e",
"225542fbb0416409e03eda129471630d31d92ef89928ee3f68c485123513f923",
"",
"root"
],
[
"e",
"ce5a5b95940aaaaab40a8d39b85466c67987f7ae558d24fb1cb97d841201433c",
"",
"reply"
],
[
"p",
"1c61d995949cbfaf14f767784e166bde865c7b8783d7aa3bf0a1d014b70c0069"
]
],
"content": "📅 Original date posted:2014-04-21\n📝 Original message:Pieter tried it already. If the two nodes views of each others mempools are\nnot exactly in alignment it ends up being slower than just sending the data\nimmediately and redundantly.\n\n\nOn Mon, Apr 21, 2014 at 6:38 PM, Mark Friedenbach \u003cmark at monetize.io\u003e wrote:\n\n\u003e Yes, it certainly can be improved in this way. You can even extend the\n\u003e idea to distribute partial proofs of work (block headers + Merkle lists\n\u003e which represent significant but not sufficient work), and 'prime' your\n\u003e memory pools with the transactions contained within.\n\u003e\n\u003e This is, btw, basically what p2pool does, which is why last time I\n\u003e calculated you get roughly 1% better return from p2pool than a zero-fee\n\u003e mining pool would get you, specifically because of the lower stale rate.\n\u003e\n\u003e On 04/21/2014 09:22 AM, Paul Lyon wrote:\n\u003e \u003e I haven't done the math on this, so it may be a terrible idea. :)\n\u003e \u003e\n\u003e \u003e I've been wondering if block propagation times could also be improved by\n\u003e \u003e allowing peers to request the list of transaction hashes that make up a\n\u003e \u003e block, and then making a follow-up request to only download any\n\u003e \u003e transactions not currently known. I'm not sure what percentage of\n\u003e \u003e transactions a node will usually already have when it receives a new\n\u003e \u003e block, but if it's high I figure this could be beneficial.\n\u003e \u003e\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e Start Your Social Network Today - Download eXo Platform\n\u003e Build your Enterprise Intranet with eXo Platform Software\n\u003e Java Based Open Source Intranet - Social, Extensible, Cloud Ready\n\u003e Get Started Now And Turn Your Intranet Into A Collaboration Platform\n\u003e http://p.sf.net/sfu/ExoPlatform\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140421/f3aba223/attachment.html\u003e",
"sig": "0514b6e06157a4e524bfc4d9d1c1bcd2aab59258ad121f523ca14b47de052ae7b94a3e5da13e103bbece5f2e82c283559af6875e96d7556a3e45f380a88199d8"
}