Gavin Andresen [ARCHIVE] on Nostr: 📅 Original date posted:2014-10-01 📝 Original message:On Wed, Oct 1, 2014 at ...
📅 Original date posted:2014-10-01
📝 Original message:On Wed, Oct 1, 2014 at 2:23 PM, Luke Dashjr <luke at dashjr.org> wrote:
> houghts on some way to have the stack item be incremented by the height at
> which the scriptPubKey was in a block? A limitation of encoding the target
> height/time directly, is that miners may choose not to mine the first
> transaction until they can also take the "burn to fee".
>
If the first transaction is P2SH, then the miner won't know there is an
advantage to holding it until it is too late (the scriptPubKey is an opaque
hash until the second transaction is final and relayed/broadcast).
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141001/dd4a8c60/attachment.html>
📝 Original message:On Wed, Oct 1, 2014 at 2:23 PM, Luke Dashjr <luke at dashjr.org> wrote:
> houghts on some way to have the stack item be incremented by the height at
> which the scriptPubKey was in a block? A limitation of encoding the target
> height/time directly, is that miners may choose not to mine the first
> transaction until they can also take the "burn to fee".
>
If the first transaction is P2SH, then the miner won't know there is an
advantage to holding it until it is too late (the scriptPubKey is an opaque
hash until the second transaction is final and relayed/broadcast).
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141001/dd4a8c60/attachment.html>