Skip to content

Clarify how to disable key path spending#43

Merged
sipa merged 1 commit intosipa:bip-schnorrfrom
jonasnick:script-path-only
Aug 21, 2019
Merged

Clarify how to disable key path spending#43
sipa merged 1 commit intosipa:bip-schnorrfrom
jonasnick:script-path-only

Conversation

@jonasnick
Copy link
Copy Markdown

No description provided.

@sipa
Copy link
Copy Markdown
Owner

sipa commented May 10, 2019

ack

@real-or-random
Copy link
Copy Markdown

Shouldn't this be a random key for privacy?

@jonasnick
Copy link
Copy Markdown
Author

@real-or-random yes, it is

it is recommended to pick a fresh integer ''r'' in the range ''0...n-1'' uniformly at random and use ''H + rG'' as internal key

@real-or-random
Copy link
Copy Markdown

Nevermind, I'm too stupid to read.

@jonasnick
Copy link
Copy Markdown
Author

Updated the link to how to derive H to a newer commit which made the code snippet actually copy-and-pastable.

@real-or-random
Copy link
Copy Markdown

ACK

Comment thread bip-taproot.mediawiki Outdated
* When deciding between scripts with conditionals (<code>OP_IF</code> etc.) and splitting them up into multiple scripts (each corresponding to one execution path through the original script), it is generally preferable to pick the latter.
* When a single condition requires signatures with multiple keys, key aggregation techniques like MuSig can be used to combine them into a single key. The details are out of scope for this document, but note that this may complicate the signing procedure.
* If one or more of the spending conditions consist of just a single key (after aggregation), the most likely one should be made the internal key. If no such condition exists, it may be worthwhile adding one that consists of an aggregation of all keys participating in all scripts combined; effectively adding an "everyone agrees" branch. If that is inacceptable, pick as internal key a point with unknown discrete logarithm (TODO).
* If one or more of the spending conditions consist of just a single key (after aggregation), the most likely one should be made the internal key. If no such condition exists, it may be worthwhile adding one that consists of an aggregation of all keys participating in all scripts combined; effectively adding an "everyone agrees" branch. If that is inacceptable, pick as internal key a point with unknown discrete logarithm. One example of such a point is ''H = point(0x0250929b74c1a04954b78b4b6035e97a5e078a5a0f28ec96d547bfee9ace803ac0)'' which is [https://github.com/ElementsProject/secp256k1-zkp/blob/11af7015de624b010424273be3d91f117f172c82/src/modules/rangeproof/main_impl.h#L16 constructed] by taking the hash of the uncompressed DER serialization of secp256k1 generator ''G'' as X coordinate. In order to avoid leaking the information that key path spending is not possible it is recommended to pick a fresh integer ''r'' in the range ''0...n-1'' uniformly at random and use ''H + rG'' as internal key. It is possible to prove that this internal key is does not have a known discrete logarithm with respect to ''G'' by revealing ''r'' to a verifier who can then reconstruct how the internal key was created.
Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: the elliptic curve point serialization is not DER; it's just the standard encoding for points. DER is only used for ECDSA signatures (and I hope nobody ever uses it for anything else...).

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry I just mindlessly copied the description from secp-zkp. Fixed.

@sipa sipa merged commit 4fef743 into sipa:bip-schnorr Aug 21, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants