📅 Original date posted:2014-04-08
📝 Original message:Isn't that just conceding that p2p protocol A is better than p2p protocol B?
Can't Bitcoin Core's block fetching be improved to get similar performance as a torrent + import?
Currently it's hard to go wide on data fetching because headers first is still pretty 'beefy'. The headers can be compressed, which would get you about 50% savings.
Also, maybe adding a layer that groups block headers into a single hash (say, 2016 headers), and then being able to fetch those (possibly compressed) header 'blocks' from multiple sources in parallel. And fanning out block fetches even further, favoring fast nodes.
Just thinking out loud.
jp
> On Apr 7, 2014, at 8:44 PM, Jeff Garzik <jgarzik at bitpay.com> wrote:
>
> Being Mr. Torrent, I've held open the "80% serious" suggestion to
> simply refuse to serve blocks older than X (3 months?).
>
> That forces download by other means (presumably torrent).
>
> I do not feel it is productive for any nodes on the network to waste
> time/bandwidth/etc. serving static, ancient data. There remain, of
> course, issues of older nodes and "getting the word out" that prevents
> this switch from being flipped on tomorrow.
>
>
>
>> On Mon, Apr 7, 2014 at 2:49 PM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
>>> On Mon, Apr 7, 2014 at 11:35 AM, Tamas Blummer <tamas at bitsofproof.com> wrote:
>>> BTW, did we already agree on the service bits for an archive node?
>>
>> I'm still very concerned that a binary archive bit will cause extreme
>> load hot-spotting and the kind of binary "Use lots of resources YES or
>> NO" I think we're currently suffering some from, but at that point
>> enshrined in the protocol.
>>
>> It would be much better to extend the addr messages so that nodes can
>> indicate a range or two of blocks that they're serving, so that all
>> nodes can contribute fractionally according to their means. E.g. if
>> you want to offer up 8 GB of distributed storage and contribute to the
>> availability of the blockchain, without having to swollow the whole
>> 20, 30, 40 ... gigabyte pill.
>>
>> Already we need that kind of distributed storage for the most recent
>> blocks to prevent extreme bandwidth load on archives, so extending it
>> to arbitrary ranges is only more complicated because there is
>> currently no room to signal it.
>>
>> ------------------------------------------------------------------------------
>> 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
>
>
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc. https://bitpay.com/
>
> ------------------------------------------------------------------------------
> 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
Jean-Paul Kogelman [ARCHIVE] /
npub1sa…8y304
2023-06-07 15:17:43
in reply to nevent1q…8573
Author Public Key
npub1sa86gng3pvs3jgyt5majwcrhn8ck5qxgy9pjqxkh79u638cd7dys28y304Published at
2023-06-07 15:17:43Event JSON
{
"id": "f621183d4ff97f08e02333350d1778d2acdc8f1dbae850e1ca613e81285f6ecd",
"pubkey": "874fa44d110b2119208ba6fb27607799f16a00c82143201ad7f179a89f0df349",
"created_at": 1686151063,
"kind": 1,
"tags": [
[
"e",
"376923b22263ee9091876d1ae02202112b3aeaa7a25d30e967b871af6956d76a",
"",
"root"
],
[
"e",
"1135dd96f9cbd3a07f1d2860e5edca4301711410f793d88a80983147faf8c5ec",
"",
"reply"
],
[
"p",
"b25e10e25d470d9b215521b50da0dfe7a209bec7fedeb53860c3e180ffdc8c11"
]
],
"content": "📅 Original date posted:2014-04-08\n📝 Original message:Isn't that just conceding that p2p protocol A is better than p2p protocol B?\n\nCan't Bitcoin Core's block fetching be improved to get similar performance as a torrent + import?\n\nCurrently it's hard to go wide on data fetching because headers first is still pretty 'beefy'. The headers can be compressed, which would get you about 50% savings.\n\nAlso, maybe adding a layer that groups block headers into a single hash (say, 2016 headers), and then being able to fetch those (possibly compressed) header 'blocks' from multiple sources in parallel. And fanning out block fetches even further, favoring fast nodes.\n\nJust thinking out loud.\n\njp\n\n\u003e On Apr 7, 2014, at 8:44 PM, Jeff Garzik \u003cjgarzik at bitpay.com\u003e wrote:\n\u003e \n\u003e Being Mr. Torrent, I've held open the \"80% serious\" suggestion to\n\u003e simply refuse to serve blocks older than X (3 months?).\n\u003e \n\u003e That forces download by other means (presumably torrent).\n\u003e \n\u003e I do not feel it is productive for any nodes on the network to waste\n\u003e time/bandwidth/etc. serving static, ancient data. There remain, of\n\u003e course, issues of older nodes and \"getting the word out\" that prevents\n\u003e this switch from being flipped on tomorrow.\n\u003e \n\u003e \n\u003e \n\u003e\u003e On Mon, Apr 7, 2014 at 2:49 PM, Gregory Maxwell \u003cgmaxwell at gmail.com\u003e wrote:\n\u003e\u003e\u003e On Mon, Apr 7, 2014 at 11:35 AM, Tamas Blummer \u003ctamas at bitsofproof.com\u003e wrote:\n\u003e\u003e\u003e BTW, did we already agree on the service bits for an archive node?\n\u003e\u003e \n\u003e\u003e I'm still very concerned that a binary archive bit will cause extreme\n\u003e\u003e load hot-spotting and the kind of binary \"Use lots of resources YES or\n\u003e\u003e NO\" I think we're currently suffering some from, but at that point\n\u003e\u003e enshrined in the protocol.\n\u003e\u003e \n\u003e\u003e It would be much better to extend the addr messages so that nodes can\n\u003e\u003e indicate a range or two of blocks that they're serving, so that all\n\u003e\u003e nodes can contribute fractionally according to their means. E.g. if\n\u003e\u003e you want to offer up 8 GB of distributed storage and contribute to the\n\u003e\u003e availability of the blockchain, without having to swollow the whole\n\u003e\u003e 20, 30, 40 ... gigabyte pill.\n\u003e\u003e \n\u003e\u003e Already we need that kind of distributed storage for the most recent\n\u003e\u003e blocks to prevent extreme bandwidth load on archives, so extending it\n\u003e\u003e to arbitrary ranges is only more complicated because there is\n\u003e\u003e currently no room to signal it.\n\u003e\u003e \n\u003e\u003e ------------------------------------------------------------------------------\n\u003e\u003e Put Bad Developers to Shame\n\u003e\u003e Dominate Development with Jenkins Continuous Integration\n\u003e\u003e Continuously Automate Build, Test \u0026 Deployment\n\u003e\u003e Start a new project now. Try Jenkins in the cloud.\n\u003e\u003e http://p.sf.net/sfu/13600_Cloudbees\n\u003e\u003e _______________________________________________\n\u003e\u003e Bitcoin-development mailing list\n\u003e\u003e Bitcoin-development at lists.sourceforge.net\n\u003e\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e \n\u003e \n\u003e \n\u003e -- \n\u003e Jeff Garzik\n\u003e Bitcoin core developer and open source evangelist\n\u003e BitPay, Inc. https://bitpay.com/\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",
"sig": "b243c1c2653f84a287a0a45293a98ccae552d33a8a6cea4e1df1c32d8faae3de74d36fb361f791a7c558e155a325ae2404f19c0d8e707464d1044cbef562e60f"
}