📅 Original date posted:2014-04-21
📝 Original message: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.
>
Mark Friedenbach [ARCHIVE] /
npub1r3…48d0u
2023-06-07 15:19:13
in reply to nevent1q…yjyv
Author Public Key
npub1r3san9v5njl6798hvauyu9ntm6r9c7u8s0t65wls58gpfdcvqp5sa48d0uPublished at
2023-06-07 15:19:13Event JSON
{
"id": "ce5a5b95940aaaaab40a8d39b85466c67987f7ae558d24fb1cb97d841201433c",
"pubkey": "1c61d995949cbfaf14f767784e166bde865c7b8783d7aa3bf0a1d014b70c0069",
"created_at": 1686151153,
"kind": 1,
"tags": [
[
"e",
"225542fbb0416409e03eda129471630d31d92ef89928ee3f68c485123513f923",
"",
"root"
],
[
"e",
"bf3d49bbb156b9eb952fcdc0ead4a2ce13b9b20a490a88689d84c05e24f801c3",
"",
"reply"
],
[
"p",
"97bb75d510e4a50aa8afac49418b449fa86dc54bdd54ee4c38a59c1f6da6e431"
]
],
"content": "📅 Original date posted:2014-04-21\n📝 Original message:Yes, it certainly can be improved in this way. You can even extend the\nidea to distribute partial proofs of work (block headers + Merkle lists\nwhich represent significant but not sufficient work), and 'prime' your\nmemory pools with the transactions contained within.\n\nThis is, btw, basically what p2pool does, which is why last time I\ncalculated you get roughly 1% better return from p2pool than a zero-fee\nmining pool would get you, specifically because of the lower stale rate.\n\nOn 04/21/2014 09:22 AM, Paul Lyon wrote:\n\u003e I haven't done the math on this, so it may be a terrible idea. :)\n\u003e \n\u003e I've been wondering if block propagation times could also be improved by\n\u003e allowing peers to request the list of transaction hashes that make up a\n\u003e block, and then making a follow-up request to only download any\n\u003e transactions not currently known. I'm not sure what percentage of\n\u003e transactions a node will usually already have when it receives a new\n\u003e block, but if it's high I figure this could be beneficial.\n\u003e",
"sig": "755ca676a6b26d74e19885d86ada7a4008e5959076b63cb23bf659af6c2b61f407e32fb0060f5e5f4421e2b670fa6ead23b36ac0982d84decf37d8a47af241b8"
}