TIP-29 Milestone Payload (Stardust) #69
Conversation
Wollac
changed the title
|
Seems a bit strange it introduce a new TIP for this small change as you lose the option to view the diff. But I guess this is consistent with our process. |
lzpap
changed the title
The PoW option will be part of the upcoming Dynamic PoW TIP
Wollac
changed the title
Where were you thinking of putting it in the tip, @luca-moser ? I am honestly unsure whether it really belong in this TIP. The |
|
Alright, then lets not add it to this TIP. Makes sense that one would have to read the block TIP anyway in order to correctly be able to construct a block with a milestone in it. @Wollac |
| To increase the security of the design, a milestone can (optionally) be independently signed by multiple keys at once. These keys should be operated by detached signature provider services running on independent infrastructure elements. This assists in mitigating the risk of an attacker having access to all the key material necessary for forging milestones. While the Coordinator takes responsibility for forming Milestone Payload Blocks, it delegates signing in to these providers through an ad-hoc RPC connector. Mutual authentication should be enforced between the Coordinator and the signature providers: a [client-authenticated TLS handshake](https://en.wikipedia.org/wiki/Transport_Layer_Security#Client-authenticated_TLS_handshake) scheme is advisable. To increase the flexibility of the mechanism, nodes can be configured to require a quorum of valid signatures to consider a milestone as genuine. | ||
|
|
||
| In addition, a key rotation policy can also be enforced by limiting key validity to certain milestone intervals. Accordingly, nodes need to know which public keys are applicable for which milestone index. This can be provided by configuring a list of entries consisting of the following fields: | ||
| - _Index Range_ providing the interval of milestone indices for which this entry is valid. The interval must not overlap with any other entry. |
There was a problem hiding this comment.
This is not how it is implemented!
Key ranges are allowed to overlap.
There was a problem hiding this comment.
I checked the Hornet config and there it seems we have (@muXxer please correct if wrong):
- A list of key ranges, each element with:
- public key
- (potentially overlapping) range
- A global config for the threshold (which is then applied to all key ranges)
Technically, it is equivalent to either have an overlapping list of single keys or a non-overlapping list of sets of key (like in the TIP).
@muXxer, I suppose you are suggesting to change the TIP to reflect the configuration format which is already implemented in Hornet?
There was a problem hiding this comment.
Oh, I misunderstood that part. Thats even better than it is implemented right now in hornet, because you can specify the threshold per range. And it's easier to read.
So the TIP is fine, maybe we should change the format in hornet in an upcoming version.
Co-authored-by: muXxer <[email protected]>
Co-authored-by: muXxer <[email protected]>
Description
This PR slightly modifies the original Milestone Payload definition by removing the
Keysfrom theMilestone Essencein favor of regular Signature Blocks consistent with TIP-20.This supersedes the Milestone Payload introduced in TIP-8.
View
Rendered Document