While this is an interesting idea for another form of secondary security, it's not really a necessary event. You could literally do this already, simply by altering your client to only forward valid blocks that have a known & trusted block award address. You don't even need to include a special transaction here. Or, for a softer form of this as a defense against a 51% attack, simply delay the forwarding of an untrusted, but otherwise valid, block for a very short time.
I doubt delays would do all that much as the longer chain would still win.
EDIT: The delay could also be automaticly expanded upon the detection of an attack, all the way to infinity, if appropriate.
Delays would dis-favor the attacker in a block race, with the practical effect of reducing his hashrate by a few percent, depending upon how widespread this method is used in practice.
Also:
However, you'd also have to be aware of the possiblity that this method of favoritism can be an attack vector itself; if the attacker were willing to simply forgo the block reward and use the addresses of trusted entities.
By requiring they also know the signature this is avoided - hence the special tx
An trust-faking attacker would not know the key.
That's true, but also adds unnecessary volume to the block, think about how many miners are going to want to be on as many trust lists as possible if this workds, and they would have to produce a trasaction for every block. Granted, tehy could only produce the transaction lcaly for when they capture a block, but then how do they get onto a trusted list to begin with?
All stuff with hash monitoring then also becomes unnecessary
I question that premise. A watchdog proces is a good idea for other reasons, and is likely to be implimented eventually anyway.
BTW, there are other, largely undisclosed, secondary security measures in effect that with similar goals aleady in use by some clients, that are also 'soft' & non-breaking changes that do not require that all clients participate to have a real effect.
What?
Well, for example there is a list of hard coded checksums in teh regular client, with a new checksum added to the list with each minor release. When the client is bootstrapping, it will check it's progress against each of these checksums as it encounters them, and then considers that section of blockchain unalterable. This has the effect that any attempts to alter that part of a blockchain (globally or locally) would have to match that checksum, even if a full rescan is forced. This puts a limit to how far back an ongoing 51% attack could go as well as prevents an isolation attack. Other cleints use different checksum lists as well, so even knowing the checksum list for the vanilla client and managing to brute force another matching solution of altered blocks (already astronomically unlikely) becomes more complicated by the introduction of the fact that different clients have different lsits of checksummed block numbers. This one serves many purposes, and doesn't really
prevent a 51% attack as much as limit it's scope (and thus it's practial viability as well). This one is not un-documented, per se, as it's documented on this very forum in many places, but it's not part of the core prtocol, thus it's not part of the whitepaper or any other such document, as far as I know. Methods of favoritism, but different than you proposal & with different goals, have been sugested in the past. I wouldn't be surprised to discover that something similar already exists in one or more alternate clients.
