I think the advantage of the source output/input was that the 1st TX does not have to be parsed my CP, all data required is in the 2nd TX and the 1st TX is purely just a setup part for the 2nd TX which makes for much simpler code since once the 2nd TX is being processed it does not need to somehow get any info/data about the 1st TX.
I think this is still true even if you leave out the source output/input.
The pubkey is in the redeem script. This gives us a verified source of the transaction.
Can we save space and drop the output and input?
I recommend removing the source output and relying on the pubkey in the redeem script as the source to save space.
Here’s a PR for the CIP:
What do you think @rubensayshi?
I’m having trouble getting my head around how a P2SH address would send a message using P2SH data encoding.
{{ pubkey }} OP_CHECKSIGVERIFY would need to be replaced with your custom multisig redeem script. That would be difficult to support in the API.
I guess in the same way that we don’t support the creation of normal p2sh redeem scripts in the API, we won’t support p2sh addresses sending a message using P2SH data encoding in the API.
yea back then we sort of acknowleged that it’s a lot more complicated and not consider it initally, I guess we could add a param my_redeem_script which indeed would replace {{ pubkey }} OP_CHECKSIGVERIFY.
it makes it even harder to determine the address for that though …
P2PKH is OP_DUP OP_HASH160 {{ pubKeyHash }} OP_EQUALVERIFY OP_CHECKSIG, we could translate {{ pubkey }} OP_CHECKSIGVERIFY to that easily, but more complicated scripts …
Yeah, I think we have to go back to including the source output in the setup transaction in order to support P2SH addresses.
Are you ok with making the source input optional?
If it is present, we will use that as the source. If it is not present, we will determine the address from {{ pubkey }} OP_CHECKSIGVERIFY.
I’m just trying to save the extra space here as blockchain space comes at a premium these days.
1 Like
Here’s the updated proposed CIP-6 with the above changes reflected. I think this keeps things small for p2pkh scripts and still safely supports p2sh scripts.
1 Like