{"type":"rich","version":"1.0","author_name":"npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2","author_url":"https://nostr.ae/npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2013-07-18\n📝 Original message:On Thu, Jul 18, 2013 at 08:13:08AM -0400, Peter Todd wrote:\n\u003e A more sophisticated approach would be possible if there existed a\n\u003e version of H() with a computational trap-door - that is if there existed\n\u003e H'(s, i)=H(i) where H' had significantly faster running time than H(),\n\u003e but required knowledge of a secret. Our peers would then be able to\n\u003e answer our challenges quickly only if they stored the intermediate\n\u003e results in a lookup table, while we could check those challenges cheaply\n\u003e without that table.\n\u003e \n\u003e Adam: you're our local crypto-expert, what can we use for H'? Seems that\n\u003e maybe some kind of asymmetric crypto system would work by requiring the\n\u003e peer to crack weak secret keys that we generate deterministicly.\n\nActually, come to think of it a really easy way to create H' is for the\nnode to create some expensive to compute set of data associated with\ntheir identity. The data set is then stored once by the node, cheap, but\nthe clients have to store one set for every unique node they connect\ntoo, expensive. A set of the function scrypt(k | i) for i in 0..n is an\nobvious way to do it.\n\nThis can equally be used as a proof-of-work to make creating lots of\nnodes expensive given a cheap way to verify the POW; easily done with a\nnon-interactive zero-knowledge proofs. It'd be nice if that POW could\nincorporate blockchain data, showing that the identity had access to\nthat data and thus could have computed the UTXO set honestly. (the POW\nshould be incrementally extendable as new data becomes available)\nHowever that is back to using a bunch of bandwidth at startup if our\npeer doesn't have access to blockchain data, so both mechanisms would\nprobably have to be done independently. Note how we also make MITM\nattacks on encrypted P2P connections expensive this way too even without\nany form of authentication. (works best when the proof-of-work is\ndependent on your IP addresses)\n\n-- \n'peter'[:-1]@petertodd.org\n00000000000000762784b647ede3678f172d73dd0c72c2180ab451b00d756959\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 198 bytes\nDesc: Digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130718/4f4bcc2e/attachment.sig\u003e"}