* [Bitcoin-development] RFC: empty scriptPubKeys and OP_RETURN for marking unspendable txouts
@ 2013-02-12 15:11 Peter Todd
2013-02-12 17:42 ` Gavin Andresen
0 siblings, 1 reply; 4+ messages in thread
From: Peter Todd @ 2013-02-12 15:11 UTC (permalink / raw)
To: bitcoin-development
[-- 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 --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Bitcoin-development] RFC: empty scriptPubKeys and OP_RETURN for marking unspendable txouts
2013-02-12 15:11 [Bitcoin-development] RFC: empty scriptPubKeys and OP_RETURN for marking unspendable txouts Peter Todd
@ 2013-02-12 17:42 ` Gavin Andresen
2013-02-13 4:12 ` Peter Todd
0 siblings, 1 reply; 4+ messages in thread
From: Gavin Andresen @ 2013-02-12 17:42 UTC (permalink / raw)
To: Peter Todd; +Cc: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 851 bytes --]
On Tue, Feb 12, 2013 at 10:11 AM, Peter Todd <pete@petertodd•org> wrote:
> .... Again, thoughts?
>
First: I really like the fidelity bond concept, and want to see it happen.
RE: OP_RETURN : I've got a knee-jerk opposition to the OP_RETURN opcode,
because it was the cause of the nastiest bug ever Bitcoin history. So I'd
be more comfortable using either OP_FALSE or OP_INVALIDOPCODE for the
"provably unspendable" transaction.
RE: anyone-can-spend transactions: Thinking aloud... I wonder if we might
inadvertently cause "spend storms" on the network; if suddenly there are 11
BTC sitting in an anybody-can-spend txout, I could imagine EVERYBODY on the
network trying to race each other to spend it (maybe assuming that there
are a few miners on old versions of the software who are too dumb to claim
it for themselves).
--
--
Gavin Andresen
[-- Attachment #2: Type: text/html, Size: 1242 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Bitcoin-development] RFC: empty scriptPubKeys and OP_RETURN for marking unspendable txouts
2013-02-12 17:42 ` Gavin Andresen
@ 2013-02-13 4:12 ` Peter Todd
2013-02-13 10:00 ` Mike Hearn
0 siblings, 1 reply; 4+ messages in thread
From: Peter Todd @ 2013-02-13 4:12 UTC (permalink / raw)
To: Gavin Andresen; +Cc: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 5406 bytes --]
On Tue, Feb 12, 2013 at 12:42:37PM -0500, Gavin Andresen wrote:
> On Tue, Feb 12, 2013 at 10:11 AM, Peter Todd <pete@petertodd•org> wrote:
>
> > .... Again, thoughts?
> >
>
> First: I really like the fidelity bond concept, and want to see it happen.
>
> RE: OP_RETURN : I've got a knee-jerk opposition to the OP_RETURN opcode,
> because it was the cause of the nastiest bug ever Bitcoin history. So I'd
So what exactly was the OP_RETURN bug anyway? I know it has something to
do with not executing the scriptSig and scriptPubKey separately
(https://bitcointalk.org/index.php?topic=58579.msg691432#msg691432) but
commit 7f7f07 that you reference isn't in the tree, nor is 0.3.5 tagged.
> be more comfortable using either OP_FALSE or OP_INVALIDOPCODE for the
> "provably unspendable" transaction.
You know, come to think of it, OP_FALSE doesn't get used by standard
transactions either, and it's behavior is a little odd in how it does
push to the stack. So lets make the standard OP_INVALIDOPCODE,
specifically 0xFF, and put it at the start of the scriptPubKey.
> RE: anyone-can-spend transactions: Thinking aloud... I wonder if we might
> inadvertently cause "spend storms" on the network; if suddenly there are 11
> BTC sitting in an anybody-can-spend txout, I could imagine EVERYBODY on the
> network trying to race each other to spend it (maybe assuming that there
> are a few miners on old versions of the software who are too dumb to claim
> it for themselves).
That's a good point. It would encourage efforts to identify as many
Bitcoin nodes as possible, particularly miners, and I don't think we
really want to incentivise that. It's not a problem unique to this
proposal - compromised private keys and SIGHASH_NONE (1) - but
fidelity bonds will give people incentive to develop the infrastructure
to exploit it.
1) Speaking of, maybe I'm missing something, but if I have a
transaction with one or more txin's and sign every signature with
SIGHASH_SINGLE, what stops an attacker from adding their own txout
at the end and diverting the mining fee to themselves?
Having said that, if we both make empty scriptPubKeys standard, and add
code so that miners will always try to spend the outputs for themselves
at the same time, we can get rid of this problem by removing the
incentive. It would also still make non-fidelity-bond uses viable as
well.
Of course, if you want to go down that path, we might as well add code
to detect and spend fidelity bonds too, and make the publish
transactions IsStandard(). Basically for every script in a confirmed
block check if any pushdata op happens to be a script that we would be
willing to add to the mempool at nBlockHeight + N. (assuming current
utxo set) If so, add it to the mempool now. N should be at least 100
blocks I think for the same reason that coinbase tx's take 100 blocks to
spend. The limit also means the size of the mempool can't get larger
than MAX_BLOCK_SIZE * N. Meanwhile IsStandard() would allow the
scriptPubKey OP_INVALIDOPCODE <valid serialized tx>
P2SH already treats data as scripts, so treating data as entire tx's
isn't that big of a leap. Also since the txout is unspendable, the
Satoshi criteria that block-reorgs should not make child tx's vanish is
still met. (though tx mutability sort of breaks this anyway)
We would however open quite a few cans of worms:
1) We just made non-final !IsStandard() for a reason.
2) What if there are transactions already in the mempool that spend the
txin's of the sacrifice? If we ignore them, we've just created another
way to double-spend unconfirmed transactions. On the other hand, if we
don't ignore them, we've just created a way to give us a chance to mine
the sacrifice for ourselves.
Personally I'm with you Gavin and think assuming miners are greedy is
best, but lets just say I probably shouldn't write an implementation
with a function named IsTxOutStealable()?
2a) What if multiple sacrifice publications exist spending the same
txin's? We should have deterministic behavior and mine the most valuable
one. If you don't do that, the attackers effective hashpower is
increased. (and thus the true sacrifice value of the bond decreases)
2b) ...but this is actually an annoying optmization problem. You could
create a whole bunch of sacrifices, each spending two or more inputs,
one small, one large. Then create one large sacrifice, that spends all
the *small* inputs. If the value of the large sacrifice is less than the
combined totals of the smaller sacrifices, you should be mining the
small ones rather than the large for maximum return.
3) With the 10KB limit on scripts, a naive IsStandard() could wind up
recursing about 200 times; we probably should say recursive publish
transactions are non-standard.
3b) ...on the other hand, if they are non-standard, implementations that
use fidelity bonds better make sure they don't accept such monsters.
We probably should just define one standard sacrifice tx form with one
txin, one txout, and a standard P2SH scriptPubKey, but miners can still
do their own thing and cause problems in determining the true value
sacrificed if they don't get the optimization problem right.
Fidelity bonds needs a lot more thought, and a testnet implementation...
--
'peter'[:-1]@petertodd.org
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Bitcoin-development] RFC: empty scriptPubKeys and OP_RETURN for marking unspendable txouts
2013-02-13 4:12 ` Peter Todd
@ 2013-02-13 10:00 ` Mike Hearn
0 siblings, 0 replies; 4+ messages in thread
From: Mike Hearn @ 2013-02-13 10:00 UTC (permalink / raw)
To: Peter Todd; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1782 bytes --]
> So what exactly was the OP_RETURN bug anyway? I know it has something to
> do with not executing the scriptSig and scriptPubKey separately
> (https://bitcointalk.org/index.php?topic=58579.msg691432#msg691432) but
> commit 7f7f07 that you reference isn't in the tree, nor is 0.3.5 tagged.
>
It was fixed by Satoshi long ago, back when we used CVS I think.
The problem was how scripts were executed. They were concatenated together
and then run as a single unit. The now obsolete OP_CODESEPARATOR was put
between them to control what was hashed and what wasn't.
The obvious problem with that arrangement being that scriptSig ran first
(it has to, to push the signatures onto the stack), so nothing stopped you
setting a scriptSig to OP_RETURN and making the script evaluate to true,
always. A pretty amazing oversight given the thought and care that went
into Bitcoin generally, and its robustness since then.
The fix was to move to the current system whereby the two scripts are
executed independently but sharing a stack, and it's only the return value
of the scriptPubKey that matters.
The scripting system always struck me as a rather late addition to the
design. Satoshi admitted as much when he said that he added it after
encountering an explosion of special cases as he designed various types of
contracts. The fact that there's an obvious bug in CHECKMULTISIG is more
evidence of this part being a general rush job, along with Satoshis
willingness to disable much of its functionality later with the IsStandard
checks. Also the design of CHECKSIG is an obvious retrofit, it would have
made far more sense to decompose it, and we never found a use case for 99%
of the opcodes despite having successfully designed (redesigned?) all the
contract types he ever mentioned.
[-- Attachment #2: Type: text/html, Size: 2585 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2013-02-13 10:00 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-02-12 15:11 [Bitcoin-development] RFC: empty scriptPubKeys and OP_RETURN for marking unspendable txouts Peter Todd
2013-02-12 17:42 ` Gavin Andresen
2013-02-13 4:12 ` Peter Todd
2013-02-13 10:00 ` Mike Hearn
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox