{"type":"rich","version":"1.0","author_name":"npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwet","author_url":"https://nostr.ae/npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwet","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2014-07-04\n📝 Original message:On Fri, Jul 4, 2014 at 3:27 AM, Andy Parkins \u003candyparkins at gmail.com\u003e wrote:\n\u003e Hello,\n\u003e\n\u003e I had a thought after reading Mike Hearn's blog about it being impossible to\n\u003e have an ASIC-proof proof of work algorithm.\n\u003e\n\u003e Perhaps I'm being dim, but I thought I'd mention my thought anyway.\n\nThanks for sharing. Ideas similar to what you're describing have come\nup a number of times before.\n\nI believe the particular formulation you're suggesting is not workable\nfor a number of reasons.\n\nIf I understand what you're proposing correctly, it that it has very\nhigh (nearly symmetrical) verification costs, all the verifiers have\nto also hash all of that information to check the result. It is\nimperative for the system that the proof of work be cheap to verify,\nsince every system needs to verify it and have no incentive to skip\nverifying it, needs to use it to block DOS attacks, etc.\n\nI believe this design would also completely preclude lite nodes (SPV\nnodes, section 8 of https://bitcoin.org/bitcoin.pdf), which are the\nmost popular Bitcoin wallets. SPV wallets do not need to store the\nblockchain, in fact they technically need no storage at all— and are\nsecure, given some assumptions about the decentralization and honesty\nof mining. It would make Bitcoin more or less infeasible to use on\nmobile devices and force many people using wallets onto centralized\nservices providers which they'd have to trust to process their\ntransactions.\n\nAnother longer term side effect of making verification costly is that\nit makes it much less reasonable to provide zero knoweldge proofs for\ndata in Bitcoin— closing off a whole set of useful tools like strongly\nprivate proofs of solvency, and strongly private bitcoin-backed\npseudonymous identities.\n\nI also believe this would also break pruning (section 7 of\nbitcoin.pdf): Right now a fully validating node can be created that\nuses only on the order of 1GB of disk space, without pruning the\nnumber is 25 GB and the gap is just going to grow over time. The\nelimiating of pruning would be a major scalability hit.\n\nA smaller, but potentially still important issue is that the proposed\nproof of work function would be expensive to run even once. This may\nresult in it not being effectively progress free— if a miner would\ntypically only make a small number of tries before success then it\nwould make mining like a race where faster miners would have a\nsuper-linear advantage over others instead of statistically rewarding\nminers fairly.\n\nThere are ways to make what I think you're trying to accomplish work\nwith fewer tradeoffs that have been suggested before (see\nhttps://en.bitcoin.it/wiki/User:Gmaxwell/alt_ideas \"POW which involves\nqueries against the UTXO set\")... the general idea there is that the\ncandidate block header is used to randomly select one or a few random\nentries in the set of spendable coins (UTXO set), which are then\nincluded in the hashing. If the UTXO set is also committed in every\nblock via a hash tree when the miner finds a solution he can also\nextract a compact membership proof that shows the UTXO he included in\nhis hashing were the right ones.  This way the work can still be\nverified by systems that don't have the blockchain (though they may\nuse 10x more bandwidth— unfortunate on its own and perhaps enough to\nstill make zero knoweldge proofs less practical), and because the\nqueries are against the UTXO set instead of the whole blockchain it's\nnot incompatible with pruning.\n\nThough even with those fixes, I am far from sure that this would be\nhelpful: It would not preclude specialized high efficiency hardware\nfor mining (see https://download.wpsoftware.net/bitcoin/asic-faq.pdf\nfor set of general arguments in this space), and the hardware that\nexisted may not be actually useful for validation in much the same way\nthat you cannot use existing mining hardware as a general sha256\naccelerator.\n\nThis specialized hardware might look more like an massively parallel\nflash or dram array with integrated computation (e.g.\nhttp://www.eecg.toronto.edu/~dunc/cram/ )— and these differences may\nnot all be good: by shifting costs from operating energy to gate-count\nit moves the total costs into hardware which is one-time and amortized\nover use (generally for modern process, compute bound equipment costs\nmore in energy than the marginal costs in fabrication after a month or\ntwo of operation), potentially creating an advantage for\nearlier/larger participants. Plus a CRAM like design might also have\nmassive throughput advantages compared to commodity hardware operating\nin a bus limited mode its hard to say until millions have been sunk in\ntrying to optimize it, but even if it does not— one of the arguments\nmade in asic-faq.pdf is because mining should be, in theory, nearly\nperfect competition even the small advantage in costs from eliminating\nunneeded peripherals can basically drive everyone without that\nadvantage out.\n\nAs an aside, there is an altcoin \"boolberry\" that implements something\nwhere 2MB of data is extracted from the blockchain and then mined one.\nBut because the extraction is not in the inner-loop mining pools just\nsend it out to miners... and of course it could be uploaded to a\ndedicated mining coprocessor (or FPGA, or GPU) if anyone ever got\naround to doing the optimizations... it also has most of the other\nissues I raised above relative to your proposal. It's still too new to\nsee what failure modes it suffers the most from first, and the\naltcoins that it is mostly competing with suffer from their own ill\nadvised (_very slow_) POW.\n\n\u003e Apologies in advance if this is a stupid idea.\n\nNo need to be sorry— talking about these things is how people learn.\nWhile I don't think this idea is good, and I'm even skeptical about\nfixed versions— I promise you many other people were thinking similar\nor even less useful things and will find the discussion interesting."}