📅 Original date posted:2014-04-07
📝 Original message:You have the trunk defined by the headers. Once a range from genesis to block n is fully downloaded,
you may validate upto block n. Furthermore after validation you can prune transactions spent until block n.
You would approach the highest block with validation and stop pruning say 100 blocks before it, to leave room for reorgs.
Tamas Blummer
http://bitsofproof.com
On 07.04.2014, at 21:13, Mark Friedenbach <mark at monetize.io> wrote:
>
>
> On 04/07/2014 12:20 PM, Tamas Blummer wrote:
>> Validation has to be sequantial, but that step can be deferred until the
>> blocks before a point are loaded and continous.
>
> And how do you find those blocks?
>
> I have a suggestion: have nodes advertise which range of full blocks
> they possess, then you can perform synchronization from the adversed ranges!
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> 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/20140407/cc4c7838/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140407/cc4c7838/attachment.sig>;
Tamas Blummer [ARCHIVE] /
npub1cc…ex8m8
2023-06-07 15:17:41
in reply to nevent1q…339u
Author Public Key
npub1ccegg9n9lnx6huppxg43m95488yur7pfemkn3pz0agjws5ffvtts0ex8m8Published at
2023-06-07 15:17:41Event JSON
{
"id": "ddcecd705bee337ee15c4a84ca561d330206f54eaea8e76f68e29d20c0769bc8",
"pubkey": "c632841665fccdabf021322b1d969539c9c1f829ceed38844fea24e8512962d7",
"created_at": 1686151061,
"kind": 1,
"tags": [
[
"e",
"376923b22263ee9091876d1ae02202112b3aeaa7a25d30e967b871af6956d76a",
"",
"root"
],
[
"e",
"888e8f15a51abac4e7c0688187272e7a7141ce1b0fcb35c1dbd3505d0a9c78c8",
"",
"reply"
],
[
"p",
"1c61d995949cbfaf14f767784e166bde865c7b8783d7aa3bf0a1d014b70c0069"
]
],
"content": "📅 Original date posted:2014-04-07\n📝 Original message:You have the trunk defined by the headers. Once a range from genesis to block n is fully downloaded,\nyou may validate upto block n. Furthermore after validation you can prune transactions spent until block n.\n\nYou would approach the highest block with validation and stop pruning say 100 blocks before it, to leave room for reorgs.\n\nTamas Blummer\nhttp://bitsofproof.com\n\nOn 07.04.2014, at 21:13, Mark Friedenbach \u003cmark at monetize.io\u003e wrote:\n\n\u003e \n\u003e \n\u003e On 04/07/2014 12:20 PM, Tamas Blummer wrote:\n\u003e\u003e Validation has to be sequantial, but that step can be deferred until the\n\u003e\u003e blocks before a point are loaded and continous.\n\u003e \n\u003e And how do you find those blocks?\n\u003e \n\u003e I have a suggestion: have nodes advertise which range of full blocks\n\u003e they possess, then you can perform synchronization from the adversed ranges!\n\u003e \n\u003e ------------------------------------------------------------------------------\n\u003e Put Bad Developers to Shame\n\u003e Dominate Development with Jenkins Continuous Integration\n\u003e Continuously Automate Build, Test \u0026 Deployment \n\u003e Start a new project now. Try Jenkins in the cloud.\n\u003e http://p.sf.net/sfu/13600_Cloudbees\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\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140407/cc4c7838/attachment.html\u003e\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 495 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140407/cc4c7838/attachment.sig\u003e",
"sig": "526e63a5a4567de8be6c9b0e09bf03c2d330f693cff1e671ec3c8406a56a8a4f2f5d4b0d96de805f149afc5763a7c08f23a55aba4810632cdf30b88503fc30fd"
}