{"type":"rich","version":"1.0","author_name":"npub1ac86vemj7ce5z8jyxt39rna3tvwql6xd30ha3vxcd6esysp23d9qrlswfj","author_url":"https://nostr.ae/npub1ac86vemj7ce5z8jyxt39rna3tvwql6xd30ha3vxcd6esysp23d9qrlswfj","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2013-06-02\n📝 Original message:So the idea is that people may want to use proof-of-work unrelated to\nbitcoin, and abuse bitcoin to obtain that proof, in a way denominated in BTC\n(and with a published USD exchange rate).  And the ways they can do that are\nto:\n\na) create unspendable addresses (which maybe you cant compact in the UTXO\nset if the unspendable address choices are not standardized)\n\nb) spend to anyone which I take it goes to a random person who happens to\nsee the address first and race the \"spend to me\" out on to the network, and\nhope miners dnt replace it with \"spend to miner\", which is insecure\n\nc) doesnt delay by 100 blocks just delay the \"spend to me\" race?  Also most\nlikely to be one by a big miner once they adapt and join the race.\n\nd) some new standardized spend to fees (only miners can claim).\n\ne) spend to charity/non-profit of choice could be useful also\n\nf) I guess we see something related in zerocoin - locked but unlockable via\nanother type of transaction later.\n\ng) why not instead make the beneficiary the address of the service the user\nis consuming that is being DoS protected by the proof-of-sacrifice?  Seems\nmore useful than burning virtual money, then it helps the bitcoin network\nAND it helps the service provide better service!\n\nso if I understand what you proposed d) seems like a useful concept if that\nis not currently possible.  eg alternatively could we not just propose a\nstandard recognized address that clearly no-one knows the EC discrete log\nof?\n\nAdam\n\nOn Sat, Jun 01, 2013 at 03:30:36PM -0400, Peter Todd wrote:\n\u003eCurrently the most compact way (proof-size) to sacrifice Bitcoins that\n\u003edoes not involve making them unspendable is to create a anyone-can-spend\n\u003eoutput as the last txout in the coinbase of a block:\n\u003e\n\u003escriptPubKey: \u003cdata\u003e OP_TRUE\n\u003e\n\u003eThe proof is then the SHA256 midstate, the txout, and the merkle path to\n\u003ethe block header. However this mechanism needs miner support, and it is\n\u003enot possible to pay for such a sacrifice securely, or create an\n\u003eassurance contract to create one.\n\u003e\n\u003eA anyone-can-spend in a regular txout is another option, but there is no\n\u003eway to prevent a miner from including a transaction spending that txout\n\u003ein the same block. Once that happens, there is no way to prove the miner\n\u003edidn't create both, thus invalidating the sacrifice. The announce-commit\n\u003eprotocol solves that problem, but at the cost of a much larger proof,\n\u003eespecially if multiple parties want to get together to pay the cost of\n\u003ethe sacrifice. (the proof must include the entire tx used to make the\n\u003esacrifice)\n\u003e\n\u003eHowever if we add a rule where txouts ending in OP_TRUE are unspendable\n\u003efor 100 blocks, similar to coinbases, we fix these problems. The rule\n\u003ecan be done as a soft-fork with 95% support in the same way the\n\u003eblockheight rule was implemented. Along with that change\n\u003eanyone-can-spend outputs should be make IsStandard() so they will be\n\u003erelayed.\n\u003e\n\u003eThe alternative is sacrifices to unspendable outputs, which is very\n\u003eundesirable compared to sending the money to miners to further\n\u003estrengthen the security of the network.\n\u003e\n\u003eWe should always make it easy for people to write code that does what is\n\u003ebest for Bitcoin.\n\u003e\n\u003e-- \n\u003e'peter'[:-1]@petertodd.org\n\u003e00000000000000ce3427502ee6a254fed27e1cd21a656a335cd2ada79b7b5293\n\n\n\n\u003e------------------------------------------------------------------------------\n\u003eGet 100% visibility into Java/.NET code with AppDynamics Lite\n\u003eIt's a free troubleshooting tool designed for production\n\u003eGet down to code-level detail for bottlenecks, with \u003c2% overhead.\n\u003eDownload for free and get started troubleshooting in minutes.\n\u003ehttp://p.sf.net/sfu/appdyn_d2d_ap2\n\n\u003e_______________________________________________\n\u003eBitcoin-development mailing list\n\u003eBitcoin-development at lists.sourceforge.net\n\u003ehttps://lists.sourceforge.net/lists/listinfo/bitcoin-development"}