2015-06-06 17:32 GMT+02:00 Peter Todd <p...@petertodd.org>: > On Sat, Jun 06, 2015 at 05:23:48PM +0200, Pieter Wuille wrote: >> On Sat, Jun 6, 2015 at 5:18 PM, Luke Dashjr <l...@dashjr.org> wrote: >> >> > I also agree with Pieter, that this should *not* be so cleanly compatible >> > with Bitcoin transactions. If you wish to share code, perhaps using an >> > invalid opcode rather than OP_RETURN would be appropriate. >> >> >> Using an invalid opcode would merely send funds into the void. It wouldn't >> invalidate the transaction. > > Just set nLockTime to 500000000-1 and nSequence appropriately to make > the transaction impossible to mine for the next 9500 years.
Actually, I suggested that on this list on april 27, but shortly after rejected my own idea: ####################### "Or a really high lock_time, but it would not make it invalid, just delayed." Ok, this was a bad idea, since nodes would have to keep it in memory. Please disregard that idea... ######################## Now I think I rejected it on based on a misunderstanding. Nodes will not put them in their mempool unless it's value is near in time, right? From the 0.9.0 release notes: "Accept nLockTime transactions that finalize in the next block". In that case this is a really nice option. > > Though I agree that this whole idea seems a bit dubious to me. > > -- > 'peter'[:-1]@petertodd.org > 00000000000000000000dd919214b66444dcebb4aa0214c1ab7c8b3b633be71f > > ------------------------------------------------------------------------------ > > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > ------------------------------------------------------------------------------ _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
