From: "Luke-Jr" <luke@dashjr.org>
To: bitcoin-development@lists.sourceforge.net
Date: Wed, 24 Aug 2011 12:26:20 -0400
User-Agent: KMail/1.13.7 (Linux/2.6.39-gentoo; KDE/4.6.4; x86_64; ; )
References: <20110824161853.GA29981@ulyssis.org>
In-Reply-To: <20110824161853.GA29981@ulyssis.org>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201108241226.26307.luke@dashjr.org>
Subject: Re: [Bitcoin-development] New standard transaction types: time to
	schedule a blockchain split?
Precedence: list

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).