1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <luke@dashjr.org>) id 1QwGHx-0001xM-NQ
for bitcoin-development@lists.sourceforge.net;
Wed, 24 Aug 2011 16:26:49 +0000
X-ACL-Warn:
Received: from zinan.dashjr.org ([173.242.112.54])
by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1QwGHs-0002PE-Py for bitcoin-development@lists.sourceforge.net;
Wed, 24 Aug 2011 16:26:49 +0000
Received: from ishibashi.localnet (fl-184-4-160-40.dhcp.embarqhsd.net
[184.4.160.40]) (Authenticated sender: luke-jr)
by zinan.dashjr.org (Postfix) with ESMTPSA id 3013356072F
for <bitcoin-development@lists.sourceforge.net>;
Wed, 24 Aug 2011 16:26:35 +0000 (UTC)
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>
X-PGP-Key-Fingerprint: CE5A D56A 36CC 69FA E7D2 3558 665F C11D D53E 9583
X-PGP-Key-ID: 665FC11DD53E9583
X-PGP-Keyserver: x-hkp://subkeys.pgp.net
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201108241226.26307.luke@dashjr.org>
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.5 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain -0.1 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1QwGHs-0002PE-Py
Subject: Re: [Bitcoin-development] New standard transaction types: time to
schedule a blockchain split?
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Wed, 24 Aug 2011 16:26:49 -0000
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).
|
