📅 Original date posted:2019-10-12
📝 Original message:On Sat, Oct 12, 2019 at 6:56 PM Joachim Strömbergson <
joachimstr at protonmail.com> wrote:
> I like the backwards syncing idea. First you provide proof of your best
> block height via coinbase, then sync backwards. It solves lots of related
> problems. You know how much you can expect from the given peer.
>
It shows you which nodes are on the same chain too.
If you have 8 peers and you ask the 8 of them for their 8 best, then they
should all agree on most of them.
You can then ask each of the 8 to start sending you headers backwards from
one of the 8 seeds.
They will all roughly split the chain into 8 equal pieces, though the split
will be based on work rather than header height.
If there is disagreement, you can give priority to the node(s) with the
lowest headers until they have completed their download.
It requires a network protocol change to allow reverse block downloads
though (and messages to indicate lowest headers etc.)
On different note, one of the problems that I haven't seen mentioned here
> yet is the timewarp attack. It is relevant to some of the proposed
> solutions. It should be possible, IIRC, for a malicious node to generate
> much longer chain with superslow timestamp increase (~5 blocks in 1 second)
> without increasing difficulty (i.e. staying at min. diff.). This could
> produce chain that is ~2500 times longer than main chain without having
> multiple branches.
>
That is a good point. It answers my question about formula for maximum
number of blocks.
5 * 60 * 60 * 24 * 365 = 157,680,000
That's around 150 million blocks per year at that rate.
I assume the 5 per second limit is that it is greater that the median of
the last 11 rather than greater or equal?
The timewarp bug can be fixed by a basic soft fork. You just need to limit
the maximum difference between the timestamp for the first header in a
period and the last header in the previous period.
An alternative would be to soft fork in a maximum block rate. In addition
to the current rules, you could limit it to a maximum of 1 block every 2
mins. That rule shouldn't activate normally.
block.height <= (block.timestamp - genesis.timestamp) / (2 mins)
It could have some weird incentives if it actually activated though.
Miners would have to shutdown mining if they were finding blocks to fast.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191012/557b7e19/attachment.html>;
Tier Nolan [ARCHIVE] /
npub1g6…sl5wd
2023-06-07 18:21:05
in reply to nevent1q…fxww
Author Public Key
npub1g6vxlp4e0nyhs2dqxxcryztyf5f5hyuaq93nw4r87zcnv0sdsa0qqsl5wdPublished at
2023-06-07 18:21:05Event JSON
{
"id": "827056094b9cf91eb2d88df816866084f341cf74ca550560e107c0cac1f902e0",
"pubkey": "46986f86b97cc97829a031b03209644d134b939d0163375467f0b1363e0d875e",
"created_at": 1686162065,
"kind": 1,
"tags": [
[
"e",
"a9a6913f6fc9138fe7aab169ce2974e6f08bf4a75cd5918afea0770bbfe2c32f",
"",
"root"
],
[
"e",
"bccb8ce51ee66f649f4647c22f4370dd75654147cef15337d013f9f421422da5",
"",
"reply"
],
[
"p",
"4995923bdd6657e6f16f87fa2c66ee60c7fbc82ae1658289a557fd3c9826cf6f"
]
],
"content": "📅 Original date posted:2019-10-12\n📝 Original message:On Sat, Oct 12, 2019 at 6:56 PM Joachim Strömbergson \u003c\njoachimstr at protonmail.com\u003e wrote:\n\n\u003e I like the backwards syncing idea. First you provide proof of your best\n\u003e block height via coinbase, then sync backwards. It solves lots of related\n\u003e problems. You know how much you can expect from the given peer.\n\u003e\n\nIt shows you which nodes are on the same chain too.\n\nIf you have 8 peers and you ask the 8 of them for their 8 best, then they\nshould all agree on most of them.\n\nYou can then ask each of the 8 to start sending you headers backwards from\none of the 8 seeds.\n\nThey will all roughly split the chain into 8 equal pieces, though the split\nwill be based on work rather than header height.\n\nIf there is disagreement, you can give priority to the node(s) with the\nlowest headers until they have completed their download.\n\nIt requires a network protocol change to allow reverse block downloads\nthough (and messages to indicate lowest headers etc.)\n\nOn different note, one of the problems that I haven't seen mentioned here\n\u003e yet is the timewarp attack. It is relevant to some of the proposed\n\u003e solutions. It should be possible, IIRC, for a malicious node to generate\n\u003e much longer chain with superslow timestamp increase (~5 blocks in 1 second)\n\u003e without increasing difficulty (i.e. staying at min. diff.). This could\n\u003e produce chain that is ~2500 times longer than main chain without having\n\u003e multiple branches.\n\u003e\n\nThat is a good point. It answers my question about formula for maximum\nnumber of blocks.\n\n5 * 60 * 60 * 24 * 365 = 157,680,000\n\nThat's around 150 million blocks per year at that rate.\n\nI assume the 5 per second limit is that it is greater that the median of\nthe last 11 rather than greater or equal?\n\nThe timewarp bug can be fixed by a basic soft fork. You just need to limit\nthe maximum difference between the timestamp for the first header in a\nperiod and the last header in the previous period.\n\nAn alternative would be to soft fork in a maximum block rate. In addition\nto the current rules, you could limit it to a maximum of 1 block every 2\nmins. That rule shouldn't activate normally.\n\n block.height \u003c= (block.timestamp - genesis.timestamp) / (2 mins)\n\nIt could have some weird incentives if it actually activated though.\nMiners would have to shutdown mining if they were finding blocks to fast.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191012/557b7e19/attachment.html\u003e",
"sig": "d2515e15d1f3fcd30f9cf13ad2c50761c9266f7962739167dbe6f8ee53fd418278b40bf8edad05e9b3d85764205dbb2c741fbd7445121e5c3cbbe5eb16e2ac31"
}