{"type":"rich","version":"1.0","author_name":"npub1dw88wd5gqsqn6ufxhf9h03uk8087l7gfzdtez5csjlt6pupu4pwsj8plrw","author_url":"https://nostr.ae/npub1dw88wd5gqsqn6ufxhf9h03uk8087l7gfzdtez5csjlt6pupu4pwsj8plrw","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2020-05-02\n📝 Original message:On Sat, May 2, 2020 at 10:26 AM Anthony Towns \u003caj at erisian.com.au\u003e wrote:\n\n\u003e\n\u003e except that we'd arguably still be missing:\n\u003e\n\u003e     is this a coinbase output? (Coin.fCoinBase)\n\u003e     what was the height of the coin? (Coin.nHeight)\n\u003e\n\u003e Maybe committing to the coinbase flag would have some use, but committing\n\u003e to the height would make it hard to chain unconfirmed spends, so at\n\u003e least that part doesn't seem worth adding.\n\u003e\n\nTo add to this point, the height of the coin is something that is *not*\ncurrently covered by any signature mode and including it would constitute a\nchange of an entirely different  caliber; a change that I would strongly\ncaution against for your above reason and more.\n\nThe coinbase output flag is currently covered by the signature as the\noutpoint hash has the required information (its prevout index of 0xFFFFFFFF\nis only legal in a coinbase transaction).  While I'm not particularly\nenthusiastic about making it easier to distinguish coinbase outputs from\nother outputs, and I worry a little about alternative designs for\nimplementing the Bitcoin protocol where this information is not so readily\navailable, I suppose I won't really oppose adding it.  However, I don't\nthink anyone is seriously proposing it.\n-\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200502/4a4b2947/attachment.html\u003e"}