{"type":"rich","version":"1.0","author_name":"npub1g6vxlp4e0nyhs2dqxxcryztyf5f5hyuaq93nw4r87zcnv0sdsa0qqsl5wd","author_url":"https://nostr.ae/npub1g6vxlp4e0nyhs2dqxxcryztyf5f5hyuaq93nw4r87zcnv0sdsa0qqsl5wd","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2019-10-12\n📝 Original message:On Thu, Oct 10, 2019 at 5:20 PM Braydon Fuller via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e  It would be interesting to have a succinct chainwork proof\n\u003e for all cases. Chainwork being a sum of the total proof-of-work in a\n\u003e chain. Such proofs currently only require a few headers for common cases\n\u003e and the other cases can be identified.\n\u003e\n\nI wonder if a \"seed\" based system would be useful.\n\nA seed is defined as a header with a very low digest.\n\nWhen a new peer connects, you ask him to send you the header with the\nlowest digest on his main chain.\n\nChains ending at the strongest seeds are kept preferentially when\ndiscarding chains.\n\nThis requires a way to download chains backwards, which the protocol\ndoesn't support at the moment.\n\nThe most chain work chain is overwhelmingly likely to contain the header\nwith the strongest digest.\n\nThis means that the honest peer's chain would be kept preferentially.\n\nIt also means that a node that is synced to the main chain can easily\ndiscard noise from dishonest peers.  Before downloading, they could ask the\npeer to provide a header with at least 1% of the POW of the best header on\nthe main chain starting at the fork point.  If they can't then their fork\nprobably has less POW than the main chain.\n\n\n\u003e A peer could\n\u003e broadcast a few low-work header chains, reconnect and repeat ad nauseam.\n\u003e\n\nI meant connected peer rather than peer.  If a peer disconnects and then\nreconnects as a new peer, then their allocation of bandwidth/RAM resets to\nzero.\n\nEach peer would be allocated a certain bandwidth per minute for headers as\nin a token bucket system.   New peers would start with empty buckets.\n\nIf an active (outgoing) peer is building on a header chain, then that chain\nis preferentially kept.  Essentially, the last chain that each outgoing\npeer built on may not be discarded.\n\nIn retrospect, that works out as the same as throttling peer download, just\nwith a different method for throttling.\n\nIn your system, peers who extend the best chain don't get throttled, but\nthe other peers do (but with a gradual transition).\n\nThis could be accomplished by adding 80 bytes into the peers bucket if it\nextends the main chain.\n\n\n\u003e For example, let's assume a case that the initial chain of headers was\n\u003e dishonest and with low chainwork. The initial block download retrieves\n\u003e the header chain from a single loader peer first. Once recent time is\n\u003e reached, header chains are downloaded from all outgoing peers.\n\n\nThe key it that it must not be possible to prevent a single honest peer\nfrom making progress by flooding with other peers and getting the honest\npeer's chain discarded.\n\nI think parallel downloading would be better than focusing on one peer\ninitially.  Otherwise, a dishonest peer can slowly send their headers to\nprevent moving to parallel mode.\n\nEach connected peer is given a bandwidth and RAM allowance.  If a connected\npeer forks off their own chain before reaching current time, then the fork\nis just discarded.\n\nThe RAM allowance would be sufficient to hold one header per minute since\ngenesis.\n\nThe header chains are relatively small (50MB), so it is not unreasonable to\nexpect the honest peer to send the entire chain in one go.\n\nI wonder if there is a formula that gives the minimum chain work required\nto have a particular chain length by now.\n\n1 minute per header would mean that the difficulty would increase every\nadjustment, so it couldn't be maintained without an exponentially rising\ntotal chain work.\n\nOn Sat, Oct 12, 2019 at 2:41 AM Braydon Fuller via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e   - Nodes are vulnerable during the initial sync when joining the\n\u003e network until the minimum chainwork is achieved.\n\n\nNodes should stay \"headers-only\" until they have hit the threshold.\n\nIt isn't really any different from a checkpoint anyway.\n\nDownload headers until you hit this header is about the same as download\nheaders until you hit this chain work.\n\nIt would be different if header chains were downloaded from the final\ncheckpoint backwards.\n\nYou would start at a final checkpoint and work backwards.  Each ancestor\nheader is committed to by the final checkpoint, so it would not be possible\na dishonest peer to fool the node during IBD.\n\n\n\u003e This is possible if the\n\u003e loader peer is the attacker. To mitigate this there would need to be a\n\u003e minimum chainwork defined based on the current chainwork. However, such\n\u003e could also be used to prevent nodes from joining the network as it's\n\u003e rejecting rather that throttling.\n\u003e\n\nI think mixing two different concepts makes this problem more complex than\nneeded.\n\nIt looks like they are aiming for hard-coding\n\nA) \"The main chain has at least C chainwork\"\nB) \"All blocks after A is satisfied have at least X POW\"\n\nTo me, this is equivalent to a checkpoint, without it having it be called a\ncheckpoint.\n\nThe point about excluding checkpoints is that it means that (in theory) two\nclients can't end up on incompatible forks due to different checkpoints.\n\nThe \"checkpoint\" is replaced by a statement by the dev team that\n\n\"There exists at least one valid chain with C chainwork\"\n\nwhich is equivalent to\n\n\"The longest valid chain has at least C chainwork\"\n\nTwo client making those statements can't cause a permanent\nincompatibility.  If they pick a different C, then eventually, once the\nmain chain has more than the larger chain work, they will agree again.\n\nCheckpoints don't automatically heal.\n\nAdding in a minimum POW requirement could break the requirement for that to\nhappen.\n\nJust because B was met on the original main chain, a fork isn't required to\nmeet it.\n\n  - It's technically a consensus change each time the minimum difficulty\n\u003e or best chainwork is updated. It is a similar consensus change as\n\u003e maintaining the last checkpoint, as it's used to prevent forking prior\n\u003e to the last checkpoint.\n\u003e\n\nI agree on the min difficulty being a consensus change.\n\nThe minimum chain work is just the devs making a true statement and then\nusing it to optimize things.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191012/24bb4eaa/attachment.html\u003e"}