rich1.0npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwethttps://nostr.ae/npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwetnjumphttps://nostr.ae📅 Original date posted:2015-12-09 📝 Original message:On Wed, Dec 9, 2015 at 6:59 AM, Mark Friedenbach <mark at friedenbach.org> wrote: > Greg, if you have actual data showing that putting the commitment in the > last transaction would be disruptive, and how disruptive, that would be > appreciated. Of the mining hardware I have looked at, none of it cared at > all what transactions other than the coinbase are. You need to provide a > path to the coinbase for extranonce rolling, but the witness commitment > wouldn't need to be updated. > > I'm sorry but it's not clear how this would be an incompatible upgrade, > disruptive to anything other than the transaction selection code. Maybe I'm > missing something? I'm not familiar with all the hardware or pooling setups > out there. I didn't comment on the transaction output. I have commented on coinbase outputs and on a hard-fork. Using an output in the last transaction would break the assumption that you can truncate a block and still have a valid block. This is used by some mining setups currently, because GBT does not generate the coinbase transaction and so cannot know its size; and you may have to drop the last transaction(s) to make room for it. That a block can be truncated and still result in a valid block also seems like a useful property to me. If the input for that transaction is supposed to be generated from a coinbase output some blocks earlier, then this may again run into hardware output constraints in coinbase transactions. (But it may be better since it wouldn't matter which output created it.). This could likely be escaped by creating a zero value output only once and just rolling it forward.