{"type":"rich","version":"1.0","author_name":"npub1353dy72duzm2f6r6y898723lczd066zs3etnnqa6dfhw3uuzlu9s3afd05","author_url":"https://nostr.ae/npub1353dy72duzm2f6r6y898723lczd066zs3etnnqa6dfhw3uuzlu9s3afd05","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2019-10-12\n📝 Original message: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.\n\nOn 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.\n\nI also agree that there is no big difference between hash checkpoints and \"min. diff. checkpoints\".\n\nJoachim\n\nSent with [ProtonMail](https://protonmail.com) Secure Email.\n\n‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐\nOn Saturday, October 12, 2019 4:27 PM, Tier Nolan via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e On Thu, Oct 10, 2019 at 5:20 PM Braydon Fuller via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\u003e  It would be interesting to have a succinct chainwork proof\n\u003e\u003e for all cases. Chainwork being a sum of the total proof-of-work in a\n\u003e\u003e chain. Such proofs currently only require a few headers for common cases\n\u003e\u003e and the other cases can be identified.\n\u003e\n\u003e I wonder if a \"seed\" based system would be useful.\n\u003e\n\u003e A seed is defined as a header with a very low digest.\n\u003e\n\u003e When a new peer connects, you ask him to send you the header with the lowest digest on his main chain.\n\u003e\n\u003e Chains ending at the strongest seeds are kept preferentially when discarding chains.\n\u003e\n\u003e This requires a way to download chains backwards, which the protocol doesn't support at the moment.\n\u003e\n\u003e The most chain work chain is overwhelmingly likely to contain the header with the strongest digest.\n\u003e\n\u003e This means that the honest peer's chain would be kept preferentially.\n\u003e\n\u003e It also means that a node that is synced to the main chain can easily discard noise from dishonest peers.  Before downloading, they could ask the peer to provide a header with at least 1% of the POW of the best header on the main chain starting at the fork point.  If they can't then their fork probably has less POW than the main chain.\n\u003e\n\u003e\u003e A peer could\n\u003e\u003e broadcast a few low-work header chains, reconnect and repeat ad nauseam.\n\u003e\n\u003e I meant connected peer rather than peer.  If a peer disconnects and then reconnects as a new peer, then their allocation of bandwidth/RAM resets to zero.\n\u003e\n\u003e Each peer would be allocated a certain bandwidth per minute for headers as in a token bucket system.   New peers would start with empty buckets.\n\u003e\n\u003e If an active (outgoing) peer is building on a header chain, then that chain is preferentially kept.  Essentially, the last chain that each outgoing peer built on may not be discarded.\n\u003e\n\u003e In retrospect, that works out as the same as throttling peer download, just with a different method for throttling.\n\u003e\n\u003e In your system, peers who extend the best chain don't get throttled, but the other peers do (but with a gradual transition).\n\u003e\n\u003e This could be accomplished by adding 80 bytes into the peers bucket if it extends the main chain.\n\u003e\n\u003e\u003e For example, let's assume a case that the initial chain of headers was\n\u003e\u003e dishonest and with low chainwork. The initial block download retrieves\n\u003e\u003e the header chain from a single loader peer first. Once recent time is\n\u003e\u003e reached, header chains are downloaded from all outgoing peers.\n\u003e\n\u003e The key it that it must not be possible to prevent a single honest peer from making progress by flooding with other peers and getting the honest peer's chain discarded.\n\u003e\n\u003e I think parallel downloading would be better than focusing on one peer initially.  Otherwise, a dishonest peer can slowly send their headers to prevent moving to parallel mode.\n\u003e\n\u003e Each connected peer is given a bandwidth and RAM allowance.  If a connected peer forks off their own chain before reaching current time, then the fork is just discarded.\n\u003e\n\u003e The RAM allowance would be sufficient to hold one header per minute since genesis.\n\u003e\n\u003e The header chains are relatively small (50MB), so it is not unreasonable to expect the honest peer to send the entire chain in one go.\n\u003e\n\u003e I wonder if there is a formula that gives the minimum chain work required to have a particular chain length by now.\n\u003e\n\u003e 1 minute per header would mean that the difficulty would increase every adjustment, so it couldn't be maintained without an exponentially rising total chain work.\n\u003e\n\u003e On Sat, Oct 12, 2019 at 2:41 AM Braydon Fuller via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\u003e   - Nodes are vulnerable during the initial sync when joining the\n\u003e\u003e network until the minimum chainwork is achieved.\n\u003e\n\u003e Nodes should stay \"headers-only\" until they have hit the threshold.\n\u003e\n\u003e It isn't really any different from a checkpoint anyway.\n\u003e\n\u003e Download headers until you hit this header is about the same as download headers until you hit this chain work.\n\u003e\n\u003e It would be different if header chains were downloaded from the final checkpoint backwards.\n\u003e\n\u003e You would start at a final checkpoint and work backwards.  Each ancestor header is committed to by the final checkpoint, so it would not be possible a dishonest peer to fool the node during IBD.\n\u003e\n\u003e\u003e This is possible if the\n\u003e\u003e loader peer is the attacker. To mitigate this there would need to be a\n\u003e\u003e minimum chainwork defined based on the current chainwork. However, such\n\u003e\u003e could also be used to prevent nodes from joining the network as it's\n\u003e\u003e rejecting rather that throttling.\n\u003e\n\u003e I think mixing two different concepts makes this problem more complex than needed.\n\u003e\n\u003e It looks like they are aiming for hard-coding\n\u003e\n\u003e A) \"The main chain has at least C chainwork\"\n\u003e B) \"All blocks after A is satisfied have at least X POW\"\n\u003e\n\u003e To me, this is equivalent to a checkpoint, without it having it be called a checkpoint.\n\u003e\n\u003e The point about excluding checkpoints is that it means that (in theory) two clients can't end up on incompatible forks due to different checkpoints.\n\u003e\n\u003e The \"checkpoint\" is replaced by a statement by the dev team that\n\u003e\n\u003e \"There exists at least one valid chain with C chainwork\"\n\u003e\n\u003e which is equivalent to\n\u003e\n\u003e \"The longest valid chain has at least C chainwork\"\n\u003e\n\u003e Two client making those statements can't cause a permanent incompatibility.  If they pick a different C, then eventually, once the main chain has more than the larger chain work, they will agree again.\n\u003e\n\u003e Checkpoints don't automatically heal.\n\u003e\n\u003e Adding in a minimum POW requirement could break the requirement for that to happen.\n\u003e\n\u003e Just because B was met on the original main chain, a fork isn't required to meet it.\n\u003e\n\u003e\u003e   - It's technically a consensus change each time the minimum difficulty\n\u003e\u003e or best chainwork is updated. It is a similar consensus change as\n\u003e\u003e maintaining the last checkpoint, as it's used to prevent forking prior\n\u003e\u003e to the last checkpoint.\n\u003e\n\u003e I agree on the min difficulty being a consensus change.\n\u003e\n\u003e The minimum chain work is just the devs making a true statement and then using it to optimize things.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191012/d2a9a41c/attachment-0001.html\u003e"}