getblockchaininfo: remove incorrect signblock fields

[jamesdorfman]

Fixes #1109.

To summarize, there are currently two similar sets of fields in the getblockchaininfo RPC response which purport to describe the network's current blocksigning script:

$ elements-cli getblockchaininfo
{
  "chain": "liquidv1",
  "blocks": 1808648,
  ...
  "signblock_asm": "11 026a2a106ec32c8a1e8052e5d02a7b0a150423dbd9b116fc48d46630ff6e6a05b9 02791646a8b49c2740352b4495c118d876347bf47d0551c01c4332fdc2df526f1a 02888bda53a424466b0451627df22090143bbf7c060e9eacb1e38426f6b07f2ae1 02aee8967150dee220f613de3b239320355a498808084a93eaf39a34dcd6202485 02d46e9259d0a0bb2bcbc461a3e68f34adca27b8d08fbe985853992b4b104e2741 02e9944e35e5750ab621e098145b8e6cf373c273b7c04747d1aa020be0af40ccd6 02f9a9d4b10a6d6c56d8c955c547330c589bb45e774551d46d415e51cd9ad51163 033b421566c124dfde4db9defe4084b7aa4e7f36744758d92806b8f72c2e943309 0353dcc6b4cf6ad28aceb7f7b2db92a4bf07ac42d357adf756f3eca790664314b6 037f55980af0455e4fb55aad9b85a55068bb6dc4740ea87276dc693f4598db45fa 0384001daa88dabd23db878dbb1ce5b4c2a5fa72c3113e3514bf602325d0c37b8e 039056d089f2fe72dbc0a14780b4635b0dc8a1b40b7a59106325dd1bc45cc70493 0397ab8ea7b0bf85bc7fc56bb27bf85e75502e94e76a6781c409f3f2ec3d112219 03b00e3b5b77884bf3cae204c4b4eac003601da75f96982ffcb3dcb29c5ee419b9 03c1f3c0874cfe34b8131af34699589aacec4093399739ae352e8a46f80a6f6837 15 OP_CHECKMULTISIG",
  "signblock_hex": "5b21026a2a106ec32c8a1e8052e5d02a7b0a150423dbd9b116fc48d46630ff6e6a05b92102791646a8b49c2740352b4495c118d876347bf47d0551c01c4332fdc2df526f1a2102888bda53a424466b0451627df22090143bbf7c060e9eacb1e38426f6b07f2ae12102aee8967150dee220f613de3b239320355a498808084a93eaf39a34dcd62024852102d46e9259d0a0bb2bcbc461a3e68f34adca27b8d08fbe985853992b4b104e27412102e9944e35e5750ab621e098145b8e6cf373c273b7c04747d1aa020be0af40ccd62102f9a9d4b10a6d6c56d8c955c547330c589bb45e774551d46d415e51cd9ad5116321033b421566c124dfde4db9defe4084b7aa4e7f36744758d92806b8f72c2e943309210353dcc6b4cf6ad28aceb7f7b2db92a4bf07ac42d357adf756f3eca790664314b621037f55980af0455e4fb55aad9b85a55068bb6dc4740ea87276dc693f4598db45fa210384001daa88dabd23db878dbb1ce5b4c2a5fa72c3113e3514bf602325d0c37b8e21039056d089f2fe72dbc0a14780b4635b0dc8a1b40b7a59106325dd1bc45cc70493210397ab8ea7b0bf85bc7fc56bb27bf85e75502e94e76a6781c409f3f2ec3d1122192103b00e3b5b77884bf3cae204c4b4eac003601da75f96982ffcb3dcb29c5ee419b92103c1f3c0874cfe34b8131af34699589aacec4093399739ae352e8a46f80a6f68375fae",
  ...
  "current_signblock_asm": "0 e51211e91d9cf4aec3bdc370a0303acde5d24baedb12235fdd2786885069d91c",
  "current_signblock_hex": "0020e51211e91d9cf4aec3bdc370a0303acde5d24baedb12235fdd2786885069d91c",
  ...
}

The signblock_asm/signblock_hex fields only display the initial blocksigning script that was used at the time of network genesis. On the other hand, the current_signblock_asm/current_signblock_hex fields actually show the blocksigning script that is currently being used on the network, and these values change as expected following dynafed transitions.

The signblock_asm/signblock_hex fields are currently misleading, and they will become entirely incorrect following future dynafed transitions that modify the signblockscript.

I have considered the following options:

• Rename these fields to initial_signblock_asm/initial_signblock_hex
• Remove the fields entirely

In this PR I have removed them entirely, because I don't think they serve any use. However, this will be a breaking change. As such, I am also open to simply renaming them.

[tiero]

ACK

[stevenroose]

utACK efdb2f4

[gwillen]

So I notice that "current_signblock_*" are showing the actual signblockscript, which is just the hash of the witness script and isn't very informative, whereas "signblock_*" appear to be showing the witness script, which contains the actual useful information. It would be nice if we could still get both of these things, even after we transition to new keys. I'm not sure how it ended up being split this way in the first place? I assume it was not intentional.

EDIT: .... Ok, I'm actually a little confused, after looking at the code, why these are even different right now. It definitely doesn't look like we have any easy way of getting the witness script in dynafed-land. I would love it if someone who remembers how this got this way could comment.

However, unless there's an easy way to get both correctly, I'm okay with just removing the one that's about to be wrong. There's no obvious reason that anybody other than us would want it.

So, utACK.

[jamesdorfman]

@gwillen #1108 fixed the signblock_witness field, so you can now call getblockheader to get it. But yes, I don't think anyone other than us has any need for it to be in the getblockchaininfo call.

[gwillen]

@gwillen #1108 fixed the signblock_witness field, so you can now call getblockheader to get it. But yes, I don't think anyone other than us has any need for it to be in the getblockchaininfo call.

Aha okay, perfect. This looks great then!