On Wednesday, August 24, 2011 12:18:54 PM Pieter Wuille wrote: > While we're at it, some additional opcodes could be useful.
Also: - Access to the block height it's part of. While this can be abused, transactions accessing it can be given a big red flag in the GUI or something. Legitimate uses include "Clearcoin" functionality in the script itself. - Remove the 100 confirmation requirement for spending generated coins. If they are respent before 100 confirmations, clients can/should flag the new outputs as also "generated" or "recently generated" so recipients are aware of the risk. It would be especially handy for pool operators if blocks could contain a transaction spending one of the same block's generation in addition to other non-generated coins, and specifying the full amount as a fee to safely add coins to the generation. Right now, if I were to embed a 25 BTC fee-only transaction, there is a risk that Deepbit could grab that transaction for their own, and fork. By making pool payouts all generated, there is no risk to paying invalid blocks instantly (since if the block is invalid, so is the payout made in it). ------------------------------------------------------------------------------ EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
