{"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-04\n📝 Original message:Are you assuming no network protocol changes?\n\nAt root, the requirement is that peers can prove their total chain POW.\n\nSince each block has the height in the coinbase, a peer can send a short\nproof of height for a disconnected header and could assert the POW for that\nheader.\n\nEach peer could send the the N strongest headers (lowest digest/most POW)\nfor their main chain and prove the height of each one.\n\nThe total chain work can be estimated as N times the POW for the lowest in\nthe list.  This is an interesting property of how POW works.  The 10th best\nPOW block will have about 10% of the total POW.\n\nThe N blocks would be spread along the chain and the peer could ask for all\nheaders between any 2 of them and check the different in claimed POW.  If\ndishonesty is discovered, the peer can be banned and all info from that\npeer wiped.\n\nYou can apply the rule hierarchically.  The honest peers would have a much\nhigher POW chain.  You could ask the peer to give you the N strongest\nheaders between 2 headers that they gave for their best chain.  You can\ncheck that their height is between the two limits.\n\nThe peer would effectively be proving their total POW recursively.\n\nThis would require a new set of messages so you can request info about the\nbest chain.\n\nIt also has the nice feature that it allows you to see if multiple peers\nare on the same chain, since they will have the same best blocks.\n\nThe most elegant would be something like using SNARKS to directly prove\nthat your chain tip has a particular POW.  The download would go tip to\ngenesis, unlike now when it is in the other direction.\n\n------------------------------------------------------------------------\n\nIn regard to your proposal, I think the key is to limit things by peer,\nrather than globally.\n\nThe limit to header width should be split between peers.  If you have N\noutgoing peers, they get 1/N of your header download resources each.\n\nYou store the current best/most POW header chain and at least one\nalternative chain per outgoing peer.\n\nYou could still prune old chains based on POW, but the best chain and the\ncurrent chain for each outgoing peer should not be pruned.\n\nThe security assumption is that a node is connected to at least one honest\nnode.\n\nIf you split resources between all peers, then it prevents the dishonest\nnodes from flooding and wiping out the progress for the honest peer.\n\n- Message Limiting -\n\nI have the same objection here.  The message limiting should be per peer.\n\nAn honest peer who has just been connected to shouldn't suffer a penalty.\n\nYour point that it is only a few minutes anyway may make this point moot\nthough.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191005/ea973505/attachment.html\u003e"}