Russell O'Connor [ARCHIVE] on Nostr: 📅 Original date posted:2020-05-02 📝 Original message:On Sat, May 2, 2020 at ...
📅 Original date posted:2020-05-02
📝 Original message:On Sat, May 2, 2020 at 10:26 AM Anthony Towns <aj at erisian.com.au> wrote:
>
> except that we'd arguably still be missing:
>
> is this a coinbase output? (Coin.fCoinBase)
> what was the height of the coin? (Coin.nHeight)
>
> Maybe committing to the coinbase flag would have some use, but committing
> to the height would make it hard to chain unconfirmed spends, so at
> least that part doesn't seem worth adding.
>
To add to this point, the height of the coin is something that is *not*
currently covered by any signature mode and including it would constitute a
change of an entirely different caliber; a change that I would strongly
caution against for your above reason and more.
The coinbase output flag is currently covered by the signature as the
outpoint hash has the required information (its prevout index of 0xFFFFFFFF
is only legal in a coinbase transaction). While I'm not particularly
enthusiastic about making it easier to distinguish coinbase outputs from
other outputs, and I worry a little about alternative designs for
implementing the Bitcoin protocol where this information is not so readily
available, I suppose I won't really oppose adding it. However, I don't
think anyone is seriously proposing it.
-
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200502/4a4b2947/attachment.html>;
📝 Original message:On Sat, May 2, 2020 at 10:26 AM Anthony Towns <aj at erisian.com.au> wrote:
>
> except that we'd arguably still be missing:
>
> is this a coinbase output? (Coin.fCoinBase)
> what was the height of the coin? (Coin.nHeight)
>
> Maybe committing to the coinbase flag would have some use, but committing
> to the height would make it hard to chain unconfirmed spends, so at
> least that part doesn't seem worth adding.
>
To add to this point, the height of the coin is something that is *not*
currently covered by any signature mode and including it would constitute a
change of an entirely different caliber; a change that I would strongly
caution against for your above reason and more.
The coinbase output flag is currently covered by the signature as the
outpoint hash has the required information (its prevout index of 0xFFFFFFFF
is only legal in a coinbase transaction). While I'm not particularly
enthusiastic about making it easier to distinguish coinbase outputs from
other outputs, and I worry a little about alternative designs for
implementing the Bitcoin protocol where this information is not so readily
available, I suppose I won't really oppose adding it. However, I don't
think anyone is seriously proposing it.
-
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200502/4a4b2947/attachment.html>;