bitcoin/bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2025-12-22 14:45:19 +00:00
Code Issues Releases Wiki Activity

Updated Comments:BIP 0174 (markdown)

Andrew Chow 2018-04-04 11:15:05 -04:00
parent 3c18d7a158
commit 711e803cea
1 changed files with 12 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
Comments:BIP-0174.md

@ -27,3 +27,15 @@ As to the second question - the public key is already present in the redeem scri
Another issue I see is related to change outputs. In order to securely compute the net amount transferred out of a wallet, change addresses must be verified. In order to do this, the redeem script of the output, as well as the BIP-32 derivation path of each pubkey therein must be provided. The way the redeem script element is described, it seems to apply only to inputs. That can be fixed with a doc change. I would further comment about the potential use for change outputs.
In fact, this can also apply to non-change outputs, if we want to prove to Signers that an output goes to a separate, white-listed, HD wallet.
## Response to comments from achow101
> As to the second question - the public key is already present in the redeem script, so it does not seem necessary to duplicate it in the map key. Instead, could refer to the public key index within the redeem script.
This would change the scope of the keypaths from being global to being per-input. This means that if the same output script is being spent from in multiple inputs (which can often happen), then the keypaths are going to be duplicated for every input. Furthermore, that makes the hd keypaths useless for change output stuff (the current form is actually necessary for Ledger Nano S support right now).
> The way the redeem script element is described, it seems to apply only to inputs. That can be fixed with a doc change. I would further comment about the potential use for change outputs.
> In fact, this can also apply to non-change outputs, if we want to prove to Signers that an output goes to a separate, white-listed, HD wallet.
Any field in the globals section (except the transaction itself and the number of inputs field) can apply to both inputs and outputs of the transaction. I can make that more clear in the BIP itself.