Proto commits in keep-network/keep-core

These commits are when the Protocol Buffers files have changed: (only the last 100 relevant commits are shown)

2026-06-19

feat(frost): carry the chosen signing subset in the signed package (7.3 t-of-included PR1/3) First of the t-of-included finalize stack: expose WHICH members the FROST signing package was built over, so a non-coordinator can learn the t-subset to await round-2 shares from when the package covers fewer than the full included set. Add a signed signer_ids field (member indices, ascending + distinct) to SigningPackageBody -- it rides the coordinator-signed body, so it is authenticated, not an unsigned sidecar. The SigningPackageBytes stays the cryptographic source of truth: the engine verifies shares against it, so a coordinator that lies in signer_ids causes only a LIVENESS failure (aggregate fails closed), never a wrong signature or false blame (Gemini's Option-B adjudication). Validate enforces structure (each a real member index so SignerIDs() cannot truncate; strictly ascending hence distinct); empty stays valid for the full-included flow, so this is fully back-compatible (the body-travels-verbatim discipline means old nodes still verify new packages over the received bytes). No behaviour change yet -- nothing sets or reads signer_ids. PR2 (runner subset) populates + consumes it; PR3 makes the done-check threshold-aware. The included-set oversizing that activates it is a deferred policy knob. Design locked via Codex + Gemini consult (both PROCEED). Pre-prod, behind frost_native tags; .pb.go regenerated with protoc-gen-go v1.36.3. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

2026-06-15

proto(frost/roast): add coordinator_package_proofs to LocalEvidenceSnapshotBody + regen (7.2b-4b PR2 WIP; wiring follows)

2026-06-14

fix(frost/roast): bind shares + detect equivocation by body hash, not envelope (review) Folds the #4060 review (Codex + Gemini, converged P2s) and reverses the #4058 envelope-hash binding it surfaced as wrong: - False equivocation / fragile binding: the coordinator signs domain||body, NOT the outer envelope. An unsigned re-encoding of the same (body, signature) - which SigningPackage.Unmarshal deliberately preserves - changes an envelope hash without being equivocation, letting a MitM frame an honest coordinator and fragmenting share bindings across members. Switch the package identity to the BODY hash for BOTH the share binding (signing_package_hash) and the collector's equivocation detection. SigningPackage.EnvelopeHash -> BodyHash (sha256 of the signed body, stable across envelope re-encoding); proto + struct docs updated. - Defensive copy: Round2Collector.RecordSigningPackage retains a collector-owned copy of the package envelope, so a caller reusing the SigningPackage (receive-loop Unmarshal) cannot mutate the retained blame evidence. - Also hardens the two-phase lock: re-check the binding's elected coordinator after re-acquiring (prune + re-begin TOCTOU). Tests: body hash stable across an envelope re-encoding; the collector treats a re-encoded same-body package as idempotent (not equivocation) and retains its own copy across caller mutation. Full pkg/frost/roast suite passes under -race. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

fix(frost/roast): bind coordinator_id + cap submitter signature in share submission (review) Folds the #4058 review (Gemini + Codex): - Gemini P1: add coordinator_id to ShareSubmissionBody so the share explicitly declares which elected coordinator it authorizes - self-describing for blame and non-repudiation, consistent with the other signed bodies - bounded to group.MemberIndex. Regenerated pb.go. - Codex P2: Validate now caps submitter_signature at MaxOperatorSignatureBytes, matching the other ROAST envelopes (an over-cap-but-under-envelope-cap signature previously reached verification/retention). - Gemini P1 (binding): keep signing_package_hash bound to the SignedSigningPackage ENVELOPE (Gemini affirmed - ties the share to the exact branch each member received); documented that this assumes canonical / non-malleable operator signatures, else the Phase 7.2b-4 blame layer must compare package bodies. Tests: round-trip asserts coordinator_id; validate-rejects adds zero / out-of-range coordinator + oversize submitter signature. Full pkg/frost/roast suite passes under -race. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

feat(frost/roast): Phase 7.2b-2 share-submission envelope (wire foundation) The context-bound, member-authenticated Round2 share submission - the wire foundation. After a member authenticates a SignedSigningPackage and accepts its taproot root, it returns its FROST round-2 share bound to that exact package; this binding is the hard prerequisite for blame adjudication (Phase 7.2b-4). - share_submission.proto: ShareSubmissionBody{attempt_context_hash, submitter_id, signing_package_hash, signature_share} + SignedShareSubmission {body, submitter_signature}; generated pb.go. - ShareSubmission Go wire type mirroring the signing-package envelope: bodyBytes() (bare wire body) + SignableBytes() (domain || body) with the leading-0x00 illegal-tag domain (roast/signed-share-submission/v1); Marshal/Unmarshal/Validate. Unmarshal bounds the envelope before parse, rejects an over-cap share field before copy, and primes the signable cache so concurrent verification is race-free; submitter_id is bounded to group.MemberIndex. - Tests: verbatim round-trip, non-canonical survival, domain-separated + undecodable, prefix-free distinctness vs the signing-package / snapshot / transition domains, validate-rejects-malformed, marshal-requires-signature, unmarshal-rejects-oversize-before-copy, and a -race guard. Full pkg/frost/roast suite passes under -race. Member sign/retain + network distribution land in the next increment. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

feat(frost/roast): Phase 7.2b-2 signed signing-package envelope (wire foundation) (#4056) ## Phase 7.2b-2: signed signing-package envelope — wire foundation First increment of Phase 7.2b-2 (design note §2/§6/§7, merged in #4054). Adds the coordinator-distributed signed signing-package envelope's **wire foundation**; the coordinator/member logic follows on this branch (see below). ### What this adds - **Protos** (`pkg/frost/roast/gen/pb/signing_package.proto`): `SigningPackageBody {attempt_context_hash, coordinator_id, signing_package, taproot_merkle_root}` and `SignedSigningPackage {body, coordinator_signature}` — generated into the existing `gen/pb` dir (protoc-gen-go v1.36.3; same dir as `evidence.proto`, so no new Dockerfile gen-allowlist entry). - **`SigningPackage` Go type** (`signing_package.go`): the same signed-body, sign-what-you-transmit / verify-what-you-received discipline as the evidence envelopes (`wire.go`). `SignableBytes` marshals the body once and caches it; `Unmarshal` retains the received body + envelope verbatim (the coordinator signature is checked over exactly those bytes); `Validate` does structural checks (32-byte attempt hash, non-zero coordinator, non-empty bounded signing package, 0-or-32-byte root, signature cap). ### Why byte-preservation The point of the envelope is that signature validity never depends on a serializer's canonical form (across protobuf versions or the Go↔Rust boundary). Pinned by tests: received bytes survive re-broadcast verbatim, a hand-crafted non-canonical encoding is preserved, key-path and script-path roots round-trip, `Validate` rejects malformed packages, and `Marshal` refuses an unsigned package. ### Not in this increment (follows on this branch) - Coordinator-side: sign `SigningPackageBody` with the operator key + distribute. - Member-side: authenticate (elected `coordinator_id` per RFC-21 Annex A + signature under that key + attempt-hash match + `taproot_merkle_root` == live root) and retain (incl. retain-on-reject for divergent envelopes). - Context-bound member-authenticated Round2 share submission (signed body covers attempt_context_hash + package/envelope hash + share) — the hard prerequisite gating blame (7.2b-4). - The engine never sees this envelope; blame adjudication stays Go-side (frozen spec §6). ### Verification `gofmt`, `go build`, `go vet`, and the full `pkg/frost/roast/...` test suite are green. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

docs(frost/roast): align evidence proto + RFC-21 with tagged signatures (review) Codex (PR #4057) flagged that the cross-language contract still documented snapshot and transition signatures as covering the bare body, while this PR makes Go sign/verify domain || body - so a non-Go implementation built from evidence.proto or RFC-21 would sign/verify different bytes and reject Go's evidence messages. Document the signed payload as `domain_tag || body` in evidence.proto (a file-level SIGNED PAYLOAD note with both exact tags + the four message comments) and in the RFC-21 wire-format decision. Regenerated evidence.pb.go is comment-only (descriptor and symbols unchanged). Same fix class as the signing-package proto contract on #4056. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

fix(frost/roast): harden signing-package domain separation + reset cache (P1/P2) P1: the domain tag began with ASCII "ro" (0x72 0x6f), which is valid protobuf wire data (field 14, length 111), so a parser skips it and resumes - letting a crafted signing_package embed a TransitionMessageBody at the resume point and re-enabling cross-protocol signature replay. Begin the tag with byte 0x00 (an illegal protobuf tag, field 0) so the signed payload is undecodable as any protobuf message: a signing-package signature is rejected when another envelope decodes the forged body, and another coordinator-signed message's signature (over a body starting >= 0x08) can never verify against domain||body. The test now asserts undecodability, including a body that embeds a full valid transition body. P2: Unmarshal reset bodyCache and wireEnvelope but not signaturePayloadCache, so a reused receiver could authenticate a freshly decoded package against stale signable bytes. Clear the cache on Unmarshal; test added. Proto SIGNED PAYLOAD note updated to the new tag bytes (file-level comment; generated .pb.go is unchanged). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

docs(frost/roast): align proto signing contract with domain separation (P2) The signed signing-package wire spec documented bare-body signatures, but SignableBytes prefixes a fixed domain tag ("roast/signed-signing-package/v1" + 0x00) before the body. A Rust or other verifier built from this proto would sign/verify the bare body and fail to interoperate with AuthenticateSigningPackage. Document the signed payload as `domain_tag || SigningPackageBody` in a file-level cross-language contract note (with the exact tag bytes) and correct the two message comments. Regenerated signing_package.pb.go is comment-only; the descriptor path and symbols are unchanged. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

feat(frost/roast): Phase 7.2b-2 signed signing-package envelope (wire) The wire foundation for the coordinator-distributed signing package (frozen spec section 6): SigningPackageBody {attempt_context_hash, coordinator_id, signing_package, taproot_merkle_root} + SignedSigningPackage {body, coordinator_signature} protos, and a SigningPackage Go type following the established sign-what-you-transmit / verify-what-you-received discipline (wire.go): SignableBytes caches the body marshaled once; Unmarshal retains the received body + envelope verbatim; Validate does structural checks. Byte-preservation (the point of the envelope) is pinned by tests: received bytes survive re-broadcast verbatim, a non-canonical encoding is preserved, key-path and script-path roots round-trip, and Validate rejects malformed packages. proto generated with protoc-gen-go v1.36.3 into the existing gen/pb dir (no new Dockerfile gen-allowlist entry). Coordinator signing/distribution and member-side authentication (elected-coordinator check, signature verification, root binding) + retention + the context-bound member-authenticated share submission follow on this branch; the engine never sees this envelope (blame adjudication is Go-side). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

2026-06-12

feat(frost/roast): protobuf signed-body envelopes for transition evidence Post-merge follow-up #4 from the June 2026 review stack: replace json.Marshal as the canonical signed-bytes encoding for evidence snapshots and transition bundles before Phase 7 wiring ossifies the format. Design - sign what you transmit, verify what you received: - new pkg/frost/roast/gen/pb/evidence.proto: a snapshot is SignedLocalEvidenceSnapshot{body, operator_signature} where body is the serialized LocalEvidenceSnapshotBody; a transition message is SignedTransitionMessage{body, coordinator_signature} whose body embeds every member's signed snapshot envelope VERBATIM (repeated bytes signed_snapshots) - producers marshal a body exactly once at signing time and cache it; parsed messages retain the received body/envelope bytes verbatim; verification always runs over exact received bytes and nothing in the evidence chain is ever re-encoded - signature validity never depends on any serializer's canonical form, across protobuf library versions or across languages (the Phase 7 Rust signer verifies and parses these same bytes) - CanonicalSnapshotBytes/CanonicalBundleBytes are replaced by SignableBytes() accessors; the coordinator's first-write-wins conflict comparison now compares exact signed bytes - Marshal of a received message returns the received envelope verbatim, so evidence bytes survive re-broadcast; wire-legal but non-canonical encodings also survive (pinned by test) - RFC-21 "Evidence message format" decision rewritten accordingly, with the rationale for retiring canonical JSON Tests: existing suite migrated off JSON fixtures (encode helpers bypass production signing to exercise structural rejection); new wire_test.go pins byte-preservation through re-broadcast, verbatim snapshot-envelope embedding in bundles, non-canonical-encoding survival, and tampered-body verification failure. go build ./..., go vet, gofmt clean; frost + tbtc package tests green. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

2024-05-02

Updated package structure

The documentation is generated from this commit.

2024-04-24

Added claim signature message

2024-02-20

Added MovedFundsSweepProposal type

2024-01-04

Removed wallet public key hash from moving funds proposal

Added moving funds message unmarshaling

2023-11-28

Coordination message and marshaling machinery Here we implement the coordination message type along with all marshaling machinery necessary to transfer it over the wire.

2022-12-12

Remove DKG stop pill mechanism

2022-11-17

Rename the concept of "signing sync" to "signing done check"

2022-11-16

Improve marshaling of `signingSyncMessage` The `message` field is easier to manage if it is marshaled as bytes not string.

Marshaling code for `tecdsa.Signature`

2022-11-15

Synchronize signing group members upon successful signing Here we implement a component that is meant to synchronize all signing group members once a signature is produced by the given attempt's participants. All signing group members (either participating or omitting the given attempt) must end up with the same signature and a common end block. This is crucial for serial signing.

2022-10-31

Abstract the tECDSA signing announcer logic Here we abstract the tECDSA signing announcer and move it to the `pkg/protocol/announcer` package. This logic is generic and can be used by multiple interactive protocols.

2022-10-28

Identify stop pill by DKG seed or signed message The stop pill was sent in a broadcast channel and stopped all signing and key generation using that broadcast channel. This worked fine for key generation, because broadcast channel name for key generation is computed from the last block's hash. This did not work well for signing sometimes because there is one broadcast channel used for all attempts of signing. If there were two attempts running at the same time (e.g. multiple attempts of the previous signing and a new signing starting), the stop pill was stopping the slower signing protocol. With this change, each signing and DKG is uniquely identified. It was not a must for DKG but I thought it is good to stay consistent. The identification is based on DKG seed and message being signed. My first attempt was to use a session ID but the session ID is computed separately for each attempt and we want to stop the main loop, not just the given attempt.

2022-10-14

Introduce the signing attempt announcement message

2022-10-05

Add confirmation state at the end of ECDSA DKG So far, members' failures in the last state (finalization) of the ECDSA DKG could remain undetected by other participants as no explicit confirmation step was done after the result was produced. The result signature process that occurs after the DKG finalization is able to detect such a failures to some extent, only when the signatures count is lower than the group quorum parameter. Undetected DKG finalization failures lead to a spurious view regarding the wallet's state because some members considered as properly operating are actually inactive. Such inactive members are normally selected for the signing work despite being unable to participate in the protocol. That leads to multiple signing failures that must be compensated by the random retry algorithm. This extends the signature time abnormally. To mitigate that problem, we are extending the DKG finalization state to produce and exchange messages informing about successful finalization. We are also introducing a new confirmation state that occurs after the finalization and makes sure that all DKG participants selected for current DKG attempt sent a finalization message thus were able to produce the result.

2022-09-29

Add session ID to the beacon DKG messages So far, the messages carrying information specific to a DKG instance were identified only by the sender ID. That can be problematic if multiple DKG instances occur in a short period of time. Due to network retransmissions, old DKG messages referring to a previous DKG instance may be handled by members listening for DKG messages specific for the currently executed DKG instance. If that scenario happens, group members can turn into an inconsistent state and break the protocol execution. As remediation, we are extending the DKG messages definitions by adding a session ID field that allows attributing the messages to a specific DKG instance. Then, the session ID can be used by group members to filter out all messages that does not belong to the currently processed DKG instance.

2022-09-28

Add session ID to the beacon relay entry messages So far, the messages carrying signature shares specific to a relay entry request were identified only by the sender ID. That turned to be problematic if multiple relay entry requests target the same group in a short period of time. Due to network retransmissions, old shares messages referring to a previous entry request may be handled by members listening for share messages specific for the currently processed entry request. If that scenario happens, group members reject the wrong shares related to previous entry and produce log warnings. Although that case does not harm the protocol execution at the moment, it is generally error-prone and may lead to unpredictable consequences in the future. As remediation, we are extending the relay entry share message definition by adding a session ID field that allows attributing the message to a specific relay entry request. Then, the session ID can be used by group members to filter out all messages that does not belong to the currently processed relay entry request.

2022-09-20

Stop pill as a workaround for no consensus integration `StopPill` is a temporary workaround for a missing chain integration. When a group member is not selected for the current attempt of key generation or signing and there is no other member from the same client selected for the protocol execution, the member does not know what was the result of the protocol execution and if it completed or not. In other words, `defer cancelLoopCtx()` does not get executed and the member will stay hung on the block waiter, waiting for their turn. The `StopPill` is sent via broadcast channel on a successful protocol execution and tells all members waiting for their turn in the retry loop to stop because the result was produced.

Marshal PaillierSK for PreParams The LocalPreParams struct from tss-lib defined a PaillierSK property. This property is generated for PreParams and is required for DKG execution. We need to marshal and unmarshal it to not loose the data.

2022-09-15

Merge remote-tracking branch 'origin/main' into storage

2022-09-13

Align field names in tECDSA protocol messages

2022-09-12

Implement pre params persistence We want to store the generated pre params on disk to use them after a client restarts. Here we implement the persistent storage for pre params. Once the preparams are generated they are stored on disk in the storage dir `work/preparams/` in a file named according to a template: `pp_<CREATION TIMESTAMP MS>_<HASH 7 characters>`. When the praparams are used by DKG they are deleted from the storage.

2022-09-08

Add `./` to go_package in .proto files The prefix is required by the protoc-gen-go ``` protoc-gen-go: invalid Go import path "pb" for "pkg/net/gen/pb/message.proto" The import path must contain at least one period ('.') or forward slash ('/') character. ```

2022-09-06

TSS round nine for tECDSA signing Here we implement the TSS round nine for the tECDSA signing protocol. This round expects simple broadcast messages produced in round eight as input and produces a simple broadcast message as output.

TSS round eight for tECDSA signing Here we implement the TSS round eight for the tECDSA signing protocol. This round expects simple broadcast messages produced in round seven as input and produces a simple broadcast message as output.

TSS round seven for tECDSA signing Here we implement the TSS round seven for the tECDSA signing protocol. This round expects simple broadcast messages produced in round six as input and produces a simple broadcast message as output.

TSS round six for tECDSA signing Here we implement the TSS round six for the tECDSA signing protocol. This round expects simple broadcast messages produced in round five as input and produces a simple broadcast message as output.

2022-09-05

TSS round five for tECDSA signing Here we implement the TSS round five for the tECDSA signing protocol. This round expects simple broadcast messages produced in round four as input and produces a simple broadcast message as output.

TSS round four for tECDSA signing Here we implement the TSS round four for the tECDSA signing protocol. This round expects simple broadcast messages produced in round three as input and produces a simple broadcast message as output.

TSS round three for tECDSA signing Here we implement the TSS round three for the tECDSA signing protocol. This round expects aggregate messages produced in TSS round two as input. Each input message consists of encrypted parts intended for specific participants. The TSS round three produces a simple message as output. The output message has only the public broadcast part.

TSS round two for tECDSA signing Here we implement the TSS round two for the tECDSA signing protocol. This round expects aggregate messages produced in TSS round one as input. Each input message consists of a public broadcast part and encrypted parts intended for specific participants. The TSS round two produces an aggregate message as output. The output message has only the encrypted point-to-point parts and, unlike the previous round output, does not contain the public broadcast part.

2022-09-02

Remove unused field from beacon's EphemeralPublicKey protobuf

2022-08-31

Components and setup of TSS round one for tECDSA signing Here we define all the required components (state, message, member, etc) for the TSS round one for tECDSA signing, and we implement the setup logic that is done upon switch from the symmetric key generation phase.

Ephemeral key exchange and symmetric key generation phases for tECDSA signing Here we introduce the two first phases of the tECDSA signing protocol that are about exchanging ephemeral keys and generating symmetric keys. Symmetric keys are meant to secure P2P communication in later phases of the protocol. Basically, the code was ported from the sibling `pkg/tecdsa/dkg` package that also uses those two phases at the beginning.

2022-08-25

Merge branch 'main' into dkg-result-submission-tbtc

2022-08-22

Merge branch 'main' into tbtc-dkg-retry # Conflicts: # pkg/tbtc/node.go # pkg/tecdsa/dkg/dkg.go

2022-08-19

Merge branch 'main' into dkg-result-submission-tbtc

2022-08-17

Added sessionID to resultSignatureMessage

Merge branch 'main' into dkg-result-submission-tbtc

2022-08-16

Renamed message

Move TSS pre-params marshalling code to dkg package TSS pre-params are important only for DKG. Also, the dkg package is where the pre-params pool lives.

2022-08-15

Merge branch 'main' into tbtc-dkg-retry

Use separate preparams pb type for LocalPreParams and LocalPartySaveData In 9c62fdd I promoted LocalPreParams to be defined outside of LocalPartySaveData. With this change, in 78dc79f, I could move LocalPreParams message to a separate file. This message is used by LocalPartySaveData and by PreParams that will be saved on disk. I was struggling with PrivateKey part: it is empty for PreParams (before DKG) and is filled for LocalPartySaveData. After consulting with @lukasz-zimnoch we decided to keep LocalPreParams as internal for LocalPartySaveData and introduce separate LocalPreParams without PrivateKey and use it as an internal message of PreParams. A little duplication seems to be a much smaller problem than introducing the additional complexity related to a field that can be in different states depending on the usage context. Protobuf definitions are meant to describe the shape of data and we think we should not have any details regarding how those data are processed (i.e. this field should be empty before DKG but filled after). Additionally, the structure with re-used pre-params can be error-prone, especially regarding the marshaling code.

Add `sessionID` to the `ephemeralPublicKeyMessage` Just like all other messages exchanged during ECDSA DKG, this message should have the `sessionID` as well. This way we guarantee that messages are not mixed between DKG retries.

Introduced PreParams message definition in preparams.proto PreParams message will be serialized on disk. This way generated and not yet used pre-parameters will survive client restarts.

Extracted LocalPreParams pb definition to a separate file We want to store LocalPreParams on disk and we need to generate LocalPreParams PB type. Doing it ouside of the context of key.pb.go feels cleaner.

Promote LocalPreParams pb type one level higher LocalPreParams has been promoted one level higher in protobuf definition - it is no longer embedded inside LocalPartySaveData. This will allow us to use LocalPreParams outside of the context of LocalPartySaveData.

2022-08-11

Merge branch 'main' into dkg-result-submission-tbtc

2022-08-10

Simplify `tbtc.signer` marshaling

2022-08-05

Marshaling of `tbtc.wallet` and `tbtc.signer`

Marshaling of `tecdsa.PrivateKeyShare` Here we add the code necessary for marshaling and unmarshaling of the `tecdsa.PrivateKeyShare` type. Most of it was directly ported from https://github.com/keep-network/keep-ecdsa/blob/main/pkg/ecdsa/tss/marshaling.go

Rename `pkg/ecdsa` to `pkg/tecdsa` This package is actually about threshold-ECDSA. Renaming it seems to be a good move since we avoid confusion with native `crypto/ecdsa` package, and we will achieve a better naming of package types.

2022-08-04

Used ECDSA DKG result publishing functionalities

2022-08-03

Added new state machine states for ECDSA DKG signing and submission

2022-07-27

Implement TSS round three Adds the TSS round three phase to the ECDSA DKG state machine.

Implement TSS round two Adds the TSS round two phase to the ECDSA DKG state machine.

Adjust param id in the `EphemeralPublicKeyMessage` proto

2022-07-25

Implement TSS round one Adds the TSS round one phase to the ECDSA DKG state machine.

2022-07-14

Store proper group operators on disk Since `RandomBeacon` contract stores the group members as a hash, each client should store the plain text group operators on disk in order to use them for future operations.

2022-07-07

Remove the intermediary `relay` package This package is redundant and makes the structure more complicated. We get an opportunity and remove it.

2022-07-04

Removed unicast channel functionality Since unicast channels will not be used in client v2, all the unicast channel-related code was removed. Maintaing connections bewteen nodes using unicast channels would require opening too many channels. Broadcast channels will most likely be used instead.

2020-05-16

Pass protocol identifier during the handshake There are two protocols run by Keep network: `keep-beacon` and `keep-ecdsa` both initiator and responder are expected to pass the protocol identifier during the handshake. This change lets to eliminate honest, misconfigured nodes from network they do not support.

2020-04-14

Remove unused Join protobuf message

2020-03-10

Merge branch 'master' into signature-shares-validation

2020-02-20

Refactoring of NetworkMessage

2020-02-14

Unicast channel message signing

2020-01-31

Sequence-number-based retransmissions Instead of computing a fingerpting for each received message (bottleneck) and using this fingerprint along with a retransmission counter to filter out duplicates (possibility of accepting the same message twice if order is flipped), we use per-channel sequence ID. This is faster and easier.

2020-01-20

Store computed group public key shares on disk

2019-11-20

Protobuf network message retransmission header changes 1. Renamed `retransmissionSequence` to `retransmission` and changed the type from int32 to uint32. It is not possible retransmission number can be negative so uint32 is better. 2. Removed checksum field. We do not want to trust the sender whether the checksum is correct and it reflects the message type and payload. We'd have to validate the checksum on the receiver side anyway. If the receiver needs to validate the checksum, there is no need to transfer it in the message from sender.

Extend message proto with checksum and sequence Added new fields in message proto in order to handle retransmission in a correct way.

2019-10-09

Rename DisqualifiedEphemeralKeysMessage Renamed DisqualifiedEphemeralKeysMessage to MisbehavedEphemeralKeysMessage. Also, some docs improved.

2019-07-26

Eliminated relay entry SigningID from Go client In the previous commit we removed signing ID from the operator contract. We can have just one ongoing relay entry so we do not need additional identifier. Two changes require more detailed explanation: 1. In local.go, I removed the map of relay entries altogether. The validation we had was not up to date - only one group member submits the entry, it does not make sense to validate if all signatures on entries are the same because multiple entry submissions from the same group are not going to happen - this is validated in other tests. 2. In cmd/relay.go I removed the part capturing request ID. When we run relay command we are bound to one service contract and one operator contract. Since there can be only one relay entry processed, the fact that the relay request was accepted is enough to assume that the relay entry that is going to be produced is "ours".

2019-07-03

Rename requestID to signingId

2019-05-29

Package thresholdsignature renamed to entry We are no longer doing only thresholdsignature there. We are preparing the new entry, signing it and publishing to the chain. Things that were changed additionally: - function CombineEntryToSign renamed to CombineToSign - File thresholdsignature.go renamed to entry.go - Function Execute renamed to SignAndSubmit

2019-05-22

Include request ID in SignatureShareMessage It is possible the same group may work on two or more relay entries at the same time. If that happens we need to be able to distinguish between SignatureShareMessages.

2019-05-15

Merge branch 'master' into state-managment-disk-storage

2019-05-14

Adding `ThresholdSigner` to message.proto as a separate type - Split MembershipMessage to `Membership` and `ThresholdSigner` in message.proto - Added and modified tests to cover the above changes

2019-05-13

Reorganizing group registry and adding marshalling functions - Restructured group registry packaged. Moved it to it's own package. - Added protobuff for Membership struct - Added marshalling functions around Membership in order to save it on disk

2019-05-03

Remove net.NetworkEnvelope Since we'll no longer be signing network messages (we rely on libp2p's pubsub layer to do this), we no longer need an envelope. We can directly use the net.NetworkMessage directly.

Remove unused fields in net.NetworkMessage

2019-04-22

nbstrip process

git ipynb notebook cleanup using nbstripout

2019-04-05

dkg2 package directory renamed to dkg dkg2 was a temporary name when we've been developing a new version of our DKG protocol having the old dkg still in place. Now, after we fully switched to the new version we can do the rename.

2019-03-22

Keep PeerShares message senderID as uint32 proto type

Keep proto share map keys as uint32 We were previously marshalling gjkr.MemberID and member.Index to bytes or string. String type was used for map keys because array of bytes cannot be a map key. We no longer use bytes for serialization and in this commit we port string map keys to uint32 as well. This way, we have all sender/receiver proto representations consistent.

Use uint32 proto type for threshold signature sender ID member.Index is a type aliast for uint32. We can use dedicated proto type for uint32 instead of serializing it to bytes.

Use uint32 as proto type for sender/receiver ID marshalling gjkr.MemberID is member.Index which is a type aliast for uint32. We can use dedicated proto type for uint32 instead of serializing it to bytes.

Revert "Update message sender index marshalling" This reverts commit 92d61a7ec449b37de443144d5d2ad5b3723e1a17. Appoach from GJKR might be wrong and we should change there protobuf to carry uint32 sender ID.

Update message sender index marshalling Marshall sender index to bytes and unmarshall it from bytes.