-
Notifications
You must be signed in to change notification settings - Fork 145
Update spec to 1.4.15 #509
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Changes from 1 commit
88d8e63
466ffc2
dba6a3f
092fb69
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -21,18 +21,9 @@ package types | |
| // it needs to request for construction. Metadata provided in this object should NEVER be a product | ||
| // of live data (i.e. the caller must follow some network-specific data fetching strategy outside of | ||
| // the Construction API to populate required Metadata). If live data is required for construction, | ||
| // it MUST be fetched in the call to `/construction/metadata`. The caller can provide a max fee they | ||
| // are willing to pay for a transaction. This is an array in the case fees must be paid in multiple | ||
| // currencies. The caller can also provide a suggested fee multiplier to indicate that the suggested | ||
| // fee should be scaled. This may be used to set higher fees for urgent transactions or to pay lower | ||
| // fees when there is less urgency. It is assumed that providing a very low multiplier (like 0.0001) | ||
| // will never lead to a transaction being created with a fee less than the minimum network fee (if | ||
| // applicable). In the case that the caller provides both a max fee and a suggested fee multiplier, | ||
| // the max fee will set an upper bound on the suggested fee (regardless of the multiplier provided). | ||
| // it MUST be fetched in the call to `/construction/metadata`. | ||
| type ConstructionPreprocessRequest struct { | ||
| NetworkIdentifier *NetworkIdentifier `json:"network_identifier"` | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. why removed SuggestedFeeMultiplier and MaxFee?
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The reason
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hi @jingweicb Noting that #479 (your team’s fix) is unmerged and out of scope here. Can we mark this resolved?
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. can you add them back manually ?
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Reverted: 092fb69 |
||
| Operations []*Operation `json:"operations"` | ||
| Metadata map[string]interface{} `json:"metadata,omitempty"` | ||
| MaxFee []*Amount `json:"max_fee,omitempty"` | ||
| SuggestedFeeMultiplier *float64 `json:"suggested_fee_multiplier,omitempty"` | ||
| NetworkIdentifier *NetworkIdentifier `json:"network_identifier"` | ||
| Operations []*Operation `json:"operations"` | ||
| Metadata map[string]interface{} `json:"metadata,omitempty"` | ||
| } | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -20,10 +20,12 @@ package types | |
| // (32-bytes)` - `64 bytes` * ecdsa_recovery: `r (32-bytes) || s (32-bytes) || v (1-byte)` - `65 | ||
| // bytes` * ed25519: `R (32-byte) || s (32-bytes)` - `64 bytes` * schnorr_1: `r (32-bytes) || s | ||
| // (32-bytes)` - `64 bytes` (schnorr signature implemented by Zilliqa where both `r` and `s` are | ||
| // scalars encoded as `32-bytes` values, most significant byte first.) * schnorr_poseidon: `r | ||
| // (32-bytes) || s (32-bytes)` where s = Hash(1st pk || 2nd pk || r) - `64 bytes` (schnorr | ||
| // signature w/ Poseidon hash function implemented by O(1) Labs where both `r` and `s` are scalars | ||
| // encoded as `32-bytes` values, least significant byte first. | ||
| // scalars encoded as `32-bytes` values, most significant byte first.) * schnorr_bip340: `r | ||
| // (32-bytes) || s (32-bytes)` - `64 bytes` (sig = (bytes(R) || bytes((k + ed) mod n) where `r` is | ||
| // the `X` coordinate of a point `R` whose `Y` coordinate is even, most significant bytes first.) * | ||
| // schnorr_poseidon: `r (32-bytes) || s (32-bytes)` where s = Hash(1st pk || 2nd pk || r) - `64 | ||
| // bytes` (schnorr signature w/ Poseidon hash function implemented by O(1) Labs where both `r` and | ||
| // `s` are scalars encoded as `32-bytes` values, least significant byte first. | ||
| // https://github.com/CodaProtocol/signer-reference/blob/master/schnorr.ml ) | ||
| type SignatureType string | ||
|
|
||
|
|
@@ -33,5 +35,6 @@ const ( | |
| EcdsaRecovery SignatureType = "ecdsa_recovery" | ||
| Ed25519 SignatureType = "ed25519" | ||
| Schnorr1 SignatureType = "schnorr_1" | ||
| SchnorrBip340 SignatureType = "schnorr_bip340" | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hi @sleepdefic1t , CAN I have more context of why we add it ?
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
The addition of these types is necessary because the construction and handling of BIP-340 signatures and public keys differ from other signature types. To reiterate, all of this was previously discussed and approved here: coinbase/mesh-specifications#113
Perhaps I'm still misunderstanding. This PR only adds the base signature and curve types as they relate to the specification, it's not intended to be a full or partial implementation of BIP-340. It was discussed and agreed upon that a subsequent PR would handle the actual implementation of BIP-340, which would then utilise these new types. Could you clarify where you propose adding a test? Without further implementation, testing doesn’t seem possible based solely on the spec update. |
||
| SchnorrPoseidon SignatureType = "schnorr_poseidon" | ||
| ) | ||
Uh oh!
There was an error while loading. Please reload this page.