I agree with Gregory Maxwell, I don't think it would be as easy as just changing IsCoinBase(), since there are places where the code assumes that the coinbase's vin doesn't spend any prevouts and/or has size 1. For example, here and here

I think the motivation behind the original suggestion is to have a way to pay specific miners upon solving a block without risking possibly paying other miners through pay-to-fee. What I'm not sure about, though, is why not just send them a transaction once you see that the miner has solved a block? Not a pay-to-fee transaction, a pay to pubkeyhash or whatever type of transaction you need to make to send the miner some coins.

Although I don't completely understand the motivation for making such transactions, maybe this would this work. Have outputs in the coinbase transaction which have nValue == 0, then only apply the COINBASE_MATURITY rule to spending coinbase outputs which have non-zero value. That way you could make a transactions which is only valid after the miner specified solves a block with the coinbase having the same TxID referenced by the new transaction's input. It's still a hard fork, but might be easier than allowing the coinbase to spend prevouts. I guess, at that point though, why not just hard fork to allow the coinbase to spend prevouts...

Best,
Stephen

On Tue, Dec 30, 2014 at 1:28 PM, Gregory Maxwell <gmaxwell@gmail.com> wrote:
On Tue, Dec 30, 2014 at 4:25 PM, Sergio Lerner
<sergiolerner@certimix.com> wrote:
> Slight off-topic:
> That looks like an abuse of the VM. Even P2SH is an abuse of the VM.
> Gavin's OP_EVAL (hard-fork) should had been chosen. I'm taking about a
> simple change that goes along the lines of Satoshi's original design.
> Bitcoin was a beautiful design, and extra complexity is making it ugly.
> We need Bitcoin to be simple to understand for new programmers so they
> can keep the project going. It doesn't help the project that one needs
> to be a guru to code for Bitcoin.

Sergio there is no "abuse" there,  OP_NOP3 in that case would be
redefined to OP_COINBASE_FOO_CONSISTENCY.

(I say FOO because it's not clear what rule you actually hope to apply there.)

What you suggested has no purpose by itself: it would need an
additional change which overlays functionality in order to actually do
something. Such a change would likely be "ugly"-- it's easy to be
elegant when you do nothing.

------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development