From 711e803ceac24dc91bb0e301d178ef8347515564 Mon Sep 17 00:00:00 2001 From: Andrew Chow Date: Wed, 4 Apr 2018 11:15:05 -0400 Subject: [PATCH] Updated Comments:BIP 0174 (markdown) --- Comments:BIP-0174.md | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/Comments:BIP-0174.md b/Comments:BIP-0174.md index 42e87d8..97fadb4 100644 --- a/Comments:BIP-0174.md +++ b/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.