Mark Friedenbach [ARCHIVE] on Nostr: š Original date posted:2014-08-06 š Original message:On 08/06/2014 01:02 PM, ...
š
Original date posted:2014-08-06
š Original message:On 08/06/2014 01:02 PM, Tom Harding wrote:
> With first-eligible-height and last-eligible-height, creator could
> choose a lifetime shorter than the max, and in addition, lock the whole
> thing until some point in the future.
Note that this would be a massive, *massive* change that would
completely break bitcoin output frangibility. Merchants would have to
start demanding input history back to a certain depth in order to ensure
they are not exposing themselves to undue reorg-expiry risk.
There are useful applications of a consensus-enforced expiry,
particularly within a private (signed block) side chain, and for that
reason it is useful to have a discussion about the merits of an nExpiry
field or BLOCK_HEIGHT / BLOCK_TIME opcode, and methods for achieving
either. However I don't see this ever becoming part of the public
bitcoin network.
š Original message:On 08/06/2014 01:02 PM, Tom Harding wrote:
> With first-eligible-height and last-eligible-height, creator could
> choose a lifetime shorter than the max, and in addition, lock the whole
> thing until some point in the future.
Note that this would be a massive, *massive* change that would
completely break bitcoin output frangibility. Merchants would have to
start demanding input history back to a certain depth in order to ensure
they are not exposing themselves to undue reorg-expiry risk.
There are useful applications of a consensus-enforced expiry,
particularly within a private (signed block) side chain, and for that
reason it is useful to have a discussion about the merits of an nExpiry
field or BLOCK_HEIGHT / BLOCK_TIME opcode, and methods for achieving
either. However I don't see this ever becoming part of the public
bitcoin network.