Good morning Billy, and list,
> - Using an opcode would greatly increase CPU usage because the script cache
> would need to be reworked (and probably cannot be made to work).
> - Adding a field would greatly increase the code complexity to the level of
> SegWit, without all the important bug
Good morning Billy,
> I've come across this argument before, and it seems kind of like Satoshi's
> word here is held as gospel. I haven't heard any deep discussion of this
> topic, and I even asked a question on the bitcoin SE about it. Sorry to
> hijack this conversation, but I'm very curious
@Russell I think there were sound arguments against Satoshi's statement
made in that very thread. Especially that software can be written to warn
the user about edge cases.
If a person waited for the standard 6 blocks before accepting a transaction
as confirmed, there should be no significantly li
You could accomplish your rough goal by having:
tx A: desired expiry at H
tx B: nlocktime H, use same inputs as A, create outputs equivalent to
inputs (have to be sure no relative timelocks)
Thus after a timeout the participants in A can cancel the action using TX B.
The difference is the coin
>From https://bitcointalk.org/index.php?topic=1786.msg22119#msg22119:
We can't safely do OP_BLOCKNUMBER. In the event of a block chain reorg
> after a segmentation, transactions need to be able to get into the chain in
> a later block. The OP_BLOCKNUMBER transaction and all its dependants would
is there any way to specify a maximum block height on a transaction?
ie: this tx is only valid if included in a block with a certain height or less
i feel like this would be useful
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https
