From: Adam Back <adam@cypherspace•org>
To: Peter Todd <pete@petertodd•org>
Cc: Bitcoin-Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Proposal: soft-fork to make anyone-can-spend outputs unspendable for 100 blocks
Date: Sun, 2 Jun 2013 23:45:54 +0200 [thread overview]
Message-ID: <20130602214553.GA11528@netbook.cypherspace.org> (raw)
In-Reply-To: <20130601193036.GA13873@savin>
So the idea is that people may want to use proof-of-work unrelated to
bitcoin, and abuse bitcoin to obtain that proof, in a way denominated in BTC
(and with a published USD exchange rate). And the ways they can do that are
to:
a) create unspendable addresses (which maybe you cant compact in the UTXO
set if the unspendable address choices are not standardized)
b) spend to anyone which I take it goes to a random person who happens to
see the address first and race the "spend to me" out on to the network, and
hope miners dnt replace it with "spend to miner", which is insecure
c) doesnt delay by 100 blocks just delay the "spend to me" race? Also most
likely to be one by a big miner once they adapt and join the race.
d) some new standardized spend to fees (only miners can claim).
e) spend to charity/non-profit of choice could be useful also
f) I guess we see something related in zerocoin - locked but unlockable via
another type of transaction later.
g) why not instead make the beneficiary the address of the service the user
is consuming that is being DoS protected by the proof-of-sacrifice? Seems
more useful than burning virtual money, then it helps the bitcoin network
AND it helps the service provide better service!
so if I understand what you proposed d) seems like a useful concept if that
is not currently possible. eg alternatively could we not just propose a
standard recognized address that clearly no-one knows the EC discrete log
of?
Adam
On Sat, Jun 01, 2013 at 03:30:36PM -0400, Peter Todd wrote:
>Currently the most compact way (proof-size) to sacrifice Bitcoins that
>does not involve making them unspendable is to create a anyone-can-spend
>output as the last txout in the coinbase of a block:
>
>scriptPubKey: <data> OP_TRUE
>
>The proof is then the SHA256 midstate, the txout, and the merkle path to
>the block header. However this mechanism needs miner support, and it is
>not possible to pay for such a sacrifice securely, or create an
>assurance contract to create one.
>
>A anyone-can-spend in a regular txout is another option, but there is no
>way to prevent a miner from including a transaction spending that txout
>in the same block. Once that happens, there is no way to prove the miner
>didn't create both, thus invalidating the sacrifice. The announce-commit
>protocol solves that problem, but at the cost of a much larger proof,
>especially if multiple parties want to get together to pay the cost of
>the sacrifice. (the proof must include the entire tx used to make the
>sacrifice)
>
>However if we add a rule where txouts ending in OP_TRUE are unspendable
>for 100 blocks, similar to coinbases, we fix these problems. The rule
>can be done as a soft-fork with 95% support in the same way the
>blockheight rule was implemented. Along with that change
>anyone-can-spend outputs should be make IsStandard() so they will be
>relayed.
>
>The alternative is sacrifices to unspendable outputs, which is very
>undesirable compared to sending the money to miners to further
>strengthen the security of the network.
>
>We should always make it easy for people to write code that does what is
>best for Bitcoin.
>
>--
>'peter'[:-1]@petertodd.org
>00000000000000ce3427502ee6a254fed27e1cd21a656a335cd2ada79b7b5293
>------------------------------------------------------------------------------
>Get 100% visibility into Java/.NET code with AppDynamics Lite
>It's a free troubleshooting tool designed for production
>Get down to code-level detail for bottlenecks, with <2% overhead.
>Download for free and get started troubleshooting in minutes.
>http://p.sf.net/sfu/appdyn_d2d_ap2
>_______________________________________________
>Bitcoin-development mailing list
>Bitcoin-development@lists•sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/bitcoin-development
next prev parent reply other threads:[~2013-06-02 21:46 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-01 19:30 Peter Todd
[not found] ` <201306012034.31543.luke@dashjr.org>
2013-06-01 20:58 ` Peter Todd
[not found] ` <38A06794-B6B4-45F3-99C1-24B08434536D@gmail.com>
2013-06-02 6:13 ` Peter Todd
2013-06-02 17:35 ` Jeff Garzik
2013-06-02 18:41 ` Peter Todd
2013-06-04 0:22 ` Mark Friedenbach
2013-06-02 21:45 ` Adam Back [this message]
2013-06-04 14:12 ` Jeff Garzik
2013-06-04 14:55 ` John Dillon
2013-06-04 17:42 ` Jeff Garzik
2013-06-04 18:36 ` Roy Badami
2013-06-04 18:49 ` Jeff Garzik
2013-06-04 20:25 ` Peter Todd
2013-06-03 23:43 ` Melvin Carvalho
2013-06-04 2:26 ` Michael Hendricks
2013-06-06 19:14 Luke-Jr
2013-06-06 19:59 ` Andreas M. Antonopoulos
2013-06-06 20:07 ` Luke-Jr
2013-06-06 20:16 ` Andreas M. Antonopoulos
2013-06-06 21:48 ` Luke-Jr
2013-06-06 22:10 ` Melvin Carvalho
2013-06-06 20:25 ` Melvin Carvalho
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130602214553.GA11528@netbook.cypherspace.org \
--to=adam@cypherspace$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=pete@petertodd$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox