Implement the operation type for membership
Membership should be stored in the blockchain. We should implement the transaction operation type about membership.
@soonkuk IMO, this issue is similar to #311 Hence, please refer this PR #457 when you start to implement this issue But the PR is lack of test cases. I am working on #471 and the integration test for the APIs will be introduced. When the integration test for API is ready, I will let you know to help to add the test for this issue.
For now, implementation the operations and unit test cases are enough to start.
Ok I got it. I'll refer to PR #457
The transaction for membership should be signed by two account. At first by an account which want to get the membership and by voting server. Membership transaction is valid only signed by voting server. To verify membership transaction, IMO voting server's public address should be hard coded in sebak.
The transaction needed to be signed by two actors.
- Sender account
- Voting Server Hence, The transaction header's form should be revised like this
type GttpSignature struct {
Name string
Source string
}
type TransactionHeader struct {
Version string `json:"version"`
Created string `json:"created"`
Hash string `json:"-"`
Signature string `json:"signature"`
GTTPSignatures []GttpSignature
}
When validating the Register and Deregister operation,
The GTTPSignature is used to verify it.
This structure is a little bit tricky but, isn't it makes sense conceptually? @spikeekips we need to talk about this in person with @outsideris
Another alternative is like this.
Keep the transaction's structure as-is.
And make the Register operation keeps the signature of GTTP.
But, to meet this strategy, freezing account needed to be prepared before register.
Signing by account is necessary? I listened, decision of membership is done by voting server and it is GTTP. IMHO, we don’t need the another signing except voting server’s signing.