{"type":"rich","version":"1.0","author_name":"npub1wu8nl4rek0s38jw0p5tx4h8a0vu75f33v5ucc0ndj2fza5yav05q36fwsk","author_url":"https://nostr.ae/npub1wu8nl4rek0s38jw0p5tx4h8a0vu75f33v5ucc0ndj2fza5yav05q36fwsk","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-12-28\n📝 Original message:On Mon, Dec 28, 2015 at 11:12 AM, Peter Todd \u003cpete at petertodd.org\u003e wrote:\n\n\u003e On Sat, Dec 26, 2015 at 12:12:13AM -0800, Multipool Admin wrote:\n\u003e \u003e Any attempt to 'fix' this problem, would most likely require changes to\n\u003e all\n\u003e \u003e mining software, why not just make mining more decentralized in general?\n\u003e \u003e\n\u003e \u003e For example, allow anyone to submit proofs of work to Bitcoind that are\n\u003e \u003e some fraction of the network difficulty and receive payment for them if\n\u003e \u003e they're valid.  This would also encourage the proliferation of full nodes\n\u003e \u003e since anyone could solo mine again.  Then, the next coinbase transaction\n\u003e \u003e could be split among, say, the top 100 proofs of work.\n\u003e\n\u003e That's certainly be a good place to be, but the design of Bitcoin\n\u003e currently makes achieving that goal fundementally difficult.\n\u003e\n\nAgreed, however I don't think it would be impossible or even really that\ndifficult, and would be a great way to increase decentralization while\nsimultaneously fixing other issues with mining.\n\nProofs of work would be valid if they're built on top of the current block\nhash, and we could require (difficulty/N) proofs of work that are \u003e=\n(difficulty/N) to assemble a valid block.  Same as mining shares work.\n\nThe block assembler who finds the final diff/N 'share' could get a small\nbonus as an incentive to complete the block as quickly as possible.  Or\nalternatively, a checksum could be computed of all the current diff/N\nshares in the mempool and that way only the final share would need to be\nbroadcasted to the entire network, and clients with the correct checksum\ncould assemble the block themselves without having to download the entire\nblock.  This would drastically decrease data usage on the network.\n\n\u003e Eligius already does their miner payouts like this.\n\u003e \u003e\n\u003e \u003e If you want to fix an issue with mining, fix the selfish mining issue\n\u003e first\n\u003e \u003e as it's a much larger and more dangerous potential issue.\n\u003e\n\u003e Do you specifically mean selfish mining as defined in Emin Gün\n\u003e Sirer/Ittay Eyal's paper? Keep in mind that attack is only a significant\n\u003e issue in a scenario - one malicious miner with \u003e30% hashing power -\n\u003e where you're already very close to the margins anyway; the difference\n\u003e between a 50% attack threshold and a 30% attack threshold isn't very\n\u003e significant.\n\u003e\n\nYes, that's what I'm talking about.\n\n\n\u003e Far more concerning is network propagation effects between large and\n\u003e small miners. For that class of issues, if you are in an environemnt\n\u003e where selfish mining is possible - a fairly flat, easily DoS/sybil\n\u003e attacked network topology - the profitability difference between small\n\u003e and large miners even *without* attacks going on is a hugely worrying\n\u003e problem. OTOH, if you're blocksize is small enough that propagation time\n\u003e is negligable to profitability, then selfish mining attacks with \u003c30%\n\u003e hashing power aren't much of a concern - they'll be naturally defeated\n\u003e by anti-DoS/anti-sybil measures.\n\u003e\n\nThe possibility that a previously 'good' actor with 30% of the hashpower\ngoing 'rogue' becomes more and more of a concern as the block subsidy\ndecreases.\n\n\n\u003e \u003e I don't believe it was ever clearly established whether Eligius suffered\n\u003e a\n\u003e \u003e block withholding attack or was just the victim of a miner with (what\n\u003e was,\n\u003e \u003e at the time) a large amount of faulty hardware, however, from the\n\u003e \u003e Bitcointalk threads at the time I believe it was assumed to be the\n\u003e latter.\n\u003e\n\u003e I think the latter was assumed as well, although ruling out of the\n\u003e former is impossible.\n\u003e\n\u003e Note though that Eligius is *not* the only pool to have had problems\n\u003e with block withholding, though AFAIK Eligius is the only one who has\n\u003e gone on record so far. (as I said in my original post, I'm relaying\n\u003e information given to me under condition of confidentiality)\n\u003e\n\nWhat is the incentive not to go on record about this?\n\n--Adam\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151228/46d76db5/attachment.html\u003e"}