From: Peter Todd <pete@petertodd•org>
To: bitcoin-development@lists•sourceforge.net
Subject: [Bitcoin-development] RFC: empty scriptPubKeys and OP_RETURN for marking unspendable txouts
Date: Tue, 12 Feb 2013 10:11:08 -0500 [thread overview]
Message-ID: <20130212151108.GA639@savin> (raw)
[-- Attachment #1: Type: text/plain, Size: 3936 bytes --]
In my fidelity bond protocol (1) I'm proposing the use of two possible
new features:
The first is the use of OP_RETURN at the end of a scriptPubKey to
designate that the txout can be immediately pruned as it is obviously
unspendable. My use-case is the publish part of the two-step
publish-sacrifice protocol. I specifically want to use OP_RETURN rather
than a spendable scriptPubKey like <serialized tx> <pubkey> OP_CHECKSIG
so that implementors can not get lazy and fail to actually write the
code to spend the non-standard outputs created, thus polluting the UTXO
set. Simply using <serialized tx> by itself as the scriptPubKey -
spendable with an empty scriptSig - is another possiblity, but I suspect
no-one will want to spend the tx fees to clean up those txouts; note how
long it took for someone to bother doing that with p2pools share chain
hash txout, and the effort(2) seems to have been a one-time experiment.
Of course, P2Pool itself could use this mechanism too.
OP_RETURN marks the script as invalid upon execution, and since a script
is invalid if an OP_IF or OP_ELSE is not terminated with OP_ENDIF it is
guaranteed to execute. (there is no op-code that marks a script as valid
and returns immediately) OP_FALSE is another possibility too; I don't
see clear advantages for one or the other modulo OP_FALSE's more
intuitive name.
Finally OP_VERIF and OP_VERNOTIF say that "Transaction is invalid even
when occuring in an unexecuted OP_IF branch" on the wiki, although a
look at EvalScript() leaves me less than convinced this is true. More
to the point, the mechanism should be something that is as unlikely as
possible to have different behavior in alternate implementations.
(remember that often only valid transactions are put in unittests by
lazy implementors)
OP_RETURN doesn't need any special support in the reference client yet
nor am I suggesting to make it a standard transaction type, but I would
like some feedback on if the idea itself is reasonable.
The second idea is the use of an empty scriptPubKey to create trivially
spendable outputs; provide the the scriptKey OP_TRUE or similar. For
fidelity bonds the advantage is to create a mechanism where even
non-miners have a chance at taking the funds sacrificed, and thus
increase the incentive to scan the blockchain for sacrifices and makes
it more likely for the sacrifice to be a true sacrifice of value. An
additional advantage is you avoid having to provide the txin to prove
the value of the mining fee. The advantage over just using a pubkey with
a known secret key is that the transaction size is shorter; remember
that the sacrifice transaction has to be published as serialized data in
a prior transaction.
In the future another use would be as a way of multiple parties to
collectively sign an assurance contract(3) donating to miners. This is
effectively a mining fee because miners who chose to include the
transaction can always chose to include an additional transfer from the
txout to a scriptPubKey only they can spend.
For the purpose of fidelity bonds ideally an empty scriptPubKey spent by
the scriptSig OP_TRUE would be made a standard transaction type to make
collecting the funds as easy as possible until miners start doing so
themselves. Having it a standard transaction type would also make it
easier for miners to implement the code to do this themselves; in
particular this discourages them from just allowing all non-standard
transactions. The main disadvantage I see is that it makes it easier for
people with buggy custom transaction code to accidentally lose their
funds.
Again, thoughts?
1) https://github.com/petertodd/trustbits/blob/master/fidelitybond.md
2) See the transactions associated with 1HfA1KHC7bT1hnPPCjpj9CB4koLM4Hz8Va
3) https://en.bitcoin.it/wiki/Contracts#Example_3:_Assurance_contracts
--
'peter'[:-1]@petertodd.org
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
next reply other threads:[~2013-02-12 15:11 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-12 15:11 Peter Todd [this message]
2013-02-12 17:42 ` Gavin Andresen
2013-02-13 4:12 ` Peter Todd
2013-02-13 10:00 ` Mike Hearn
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=20130212151108.GA639@savin \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/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