GithubHelp home page GithubHelp logo

drand / drand Goto Github PK

View Code? Open in Web Editor NEW
701.0 18.0 106.0 52.1 MB

๐ŸŽฒ A Distributed Randomness Beacon Daemon - Go implementation

Home Page: https://drand.love

License: Other

Go 92.47% Shell 6.19% Dockerfile 0.52% Makefile 0.83%
randomness randomness-beacon cryptography golang hacktoberfest

drand's Issues

Unification of testing bash scripts

There's no need to have two separate scripts for running locally and testing as both share a large portion of the code.
Idea is to have run_local.sh take an argument such as ./run_local.sh test to run the docker test.

should not be able to use several nodes with same drand_id.public

When running drand group with the same drand_id.public repeated several times, we end up with a group file like

Threshold = 3
Period = "1m0s"

[[Nodes]]
  Address = "127.0.0.1:1234"
  Key = "64edd0385991a013619d6a6b284e51c219c1da9ff984ac2e214eb3f4af8fbb5a5413262090dde2c828c0634a1bef1e2ee95a130c6816ec76532a94862444be4b8b3cc28c233784987b9dc45033c240bdbe7a84ec1b62639851114dedfe549d4b749c5c476dfec4014d1c93e0ebc9614be9b9a9941c11aae133f2c12d2318e773"
  TLS = true

[[Nodes]]
  Address = "127.0.0.1:1234"
  Key = "64edd0385991a013619d6a6b284e51c219c1da9ff984ac2e214eb3f4af8fbb5a5413262090dde2c828c0634a1bef1e2ee95a130c6816ec76532a94862444be4b8b3cc28c233784987b9dc45033c240bdbe7a84ec1b62639851114dedfe549d4b749c5c476dfec4014d1c93e0ebc9614be9b9a9941c11aae133f2c12d2318e773"
  TLS = true

[[Nodes]]
  Address = "127.0.0.1:1234"
  Key = "64edd0385991a013619d6a6b284e51c219c1da9ff984ac2e214eb3f4af8fbb5a5413262090dde2c828c0634a1bef1e2ee95a130c6816ec76532a94862444be4b8b3cc28c233784987b9dc45033c240bdbe7a84ec1b62639851114dedfe549d4b749c5c476dfec4014d1c93e0ebc9614be9b9a9941c11aae133f2c12d2318e773"
  TLS = true

Should something be done to prevent this ?

Better logging

The logging in drand is very basic. We need to extend it to something more standardized, with dates and general format.

drand is using kyber.Groupable which was never merged into kyber

Currently a fresh install of drand fails because of the following:

$> go get -u github.com/dedis/drand
# github.com/dedis/drand/protobuf/crypto
drand/protobuf/crypto/converter.go:56:17: undefined: kyber.Groupable
drand/protobuf/crypto/converter.go:84:17: undefined: kyber.Groupable

since kyber.Groupable wasn't merged in dedis/kyber#298.

Remove catch up heuristic for beacon

When one reload its drand, drand checks if it has already some saved beacons inside.
If there are some, it assumes that the beacon generation routine already ran before and waits for the next request in order to "catch up" with the latest round number of the beacon generation. Catch up means it waits for an incoming requests and look at the round number and takes it up from there.

This is not really needed anymore, since the catch up functionality happens automatically now if one receives a request with a round number in the future or if one sees its requests being denied. Of course, one would have to check it still all works out.

x509: certificate is valid for drand.example.com, not drand.example.com:443

In this line, the serverNameOverride parameter is set to be the host:port address, which is different from the server name:
https://github.com/dedis/drand/blob/5aae894956265da27653de203863f4f045915226/net/client_grpc.go#L122
In particular, I got a pretty strange error when testing drand run:
dkg: failed to send deal to drand.example.com:443: rpc error: code = Unavailable desc = all SubConns are in TransientFailure, latest connection error: connection error: desc = "transport: authentication handshake failed: x509: certificate is valid for *.example.com, drand.example.com, not drand.example.com:443"

I think this could also be a side effect (if not bug) of my load balancer setup, but I realized that the docs for NewClientTLSFromFile suggest that this parameter be used only for testing:

// NewClientTLSFromFile constructs TLS credentials from the input certificate file for client.
// serverNameOverride is for testing only. If set to a non empty string,
// it will override the virtual host name of authority (e.g. :authority header field) in requests.
func NewClientTLSFromFile(certFile, serverNameOverride string) (TransportCredentials, error) {

Is p.Address() needed there? If not, removing it will relieve some headache on my end.

New command-line interface

Here's a first proposal for a new command-line interface. It still on-going work and some of the optional commands can probably be merged here and there.

The following commands provide general information about the drand software.

drand [-hV]

	Options:

    -h, --help
        Print a help message.

    โ€”V, --version
        Output version.

The following commands start and stop the drand daemon.

drand start [--no-tls] [--tls-cert file] [--tls-key file] [--verbosity level]
    Start the drand daemon.
    
    Options:

    -n, --no-tls 
    	Disable TLS for all communications (not recommended).
    	
    -c, --tls-cert fullchain.pem
        Set the TLS certificate chain (in PEM format) for this drand node. If
        not specified previously and --no-tls is not set, drand asks the user to
        provide a path to a valid TLS certificate during boot up.
    	
    -k, --tls-key private-key.pem
        Set the TLS private key (in PEM format) for this drand node. If not
        specified previously and --no-tls is not set, drand asks the user to
        provide a path to a valid TLS private key during boot up.
    	
    -v, --verbosity level
    	Set verbosity to the given level.

drand stop 
	Stop the drand daemon.
        
The following commands interact with a remote drand node.

drand get cokey [--no-tls] address
    Get the collective public key from the drand node at the given address.

    Options:

    -n, --no-tls
    	Disable TLS for all communications (not recommended).

    -c, --tls-cert fullchain.pem
        Set the self-signed certificate of the remote drand node if necessary.

drand get public --cokey drand.cokey [--index num] [--no-tls] address
    Get the latest public randomness from the drand node at the given address
    and verify it against the given collective public key drand.cokey of the
    drand beacon.

    Options:

    -i, --index num
        Request the public randomness generated at index num. If the drand node
        does not have the requested value, it returns an error.

    -n, --no-tls
    	Disable TLS for all communications (not recommended).

    -c, --tls-cert fullchain.pem
        Set the self-signed certificate of the remote drand node if necessary.

drand get private --pubkey drand.public [--no-tls] address
    Get private randomness from the drand node at the given address. Requests
    are ECIES-encrypted towards the public key drand.public of the drand node.

    Options:

    -n, --no-tls
    	Disable TLS for all communications (not recommended).

    -c, --tls-cert fullchain.pem
        Set the self-signed certificate of the remote drand node if necessary.

The following commands interact with the drand node on localhost.

drand gen group <keys> group.toml
    Merge the given list of comma-separated drand.public keys into the
    group.toml file.

drand gen keypair
    Generate the longterm keypair (drand.private, drand.public).

drand gen dkg [--leader] group.toml
    Run the distributed key generation with the group specified in group.toml to
    generate the collective public key drand.cokey and a share drand.share for
    each node. Nodes which are not specified as a leader wait until being
    contacted by a node that is as a leader. After the dkg has been finished
    successfully, the leader automatically switches to the public randomness
    generation mode.

    Options:

    -l, --leader
        Initiate and coordinate the generation of the distributed key.

drand gen redkg [--leader] group-old.toml group-new.toml
    Reshare the distributed key from the nodes specified in group-old.toml
    towards those definied in group-new.toml. At least a threshold t-of-n nodes
    in group-old.toml have to be present to make this possible. Each node in
    group-new.toml that is not online at the time of the refresh will not get a
    new share and therefore will not become a member of the new group. Nodes
    which are not specified as a leader wait until being contacted by a node
    that is as a leader. After the resharing has been finished successfully, the
    new leader automatically switches to the public randomness generation mode.

    Options:

    -l, --leader
        Initiate and coordinate the resharing of the distributed key.

drand info cokey
    Print the collective public key drand.cokey.

drand info group
    Print the details about the group that the local drand node is part of
    currently.

drand info private
    Print the long-term private key drand.private.

drand info public
    Print the long-term public key drand.public.

drand info share
    Print the private key share drand.share.

port number missing gives a panic

With this public file:

Address = "dedis.nella.org"
Key = "0181683b428f3c6a67cddff09117f87a52b4797dbafd05eb0b0876d3bbd79874f978152ca614c17a2537a80baa794c98c3ba95e535d874bef88643a71676bc612c31c64aff0363f56cb44bb8650e69bc96c0976c6edab918e38e018f6c6e42a38c7400244e5e9e2aff0fa7d22b46526852a4a02885d233f3ed8ed8c3ec85b4c286"
TLS = true

I got this panic:

panic: listen tcp: address dedis.nella.org: missing port in address

goroutine 1 [running]:
github.com/dedis/drand/net.NewGrpcGatewayFromCertManager(0xc420423720, 0xf, 0x7ffc1d9f521c, 0x37, 0x7ffc1d9f525e, 0x35, 0xc42000c088, 0xa52980, 0xc420170120, 0x0, ...) 
        /Users/jallen/go/src/github.com/dedis/drand/net/gateway.go:59 +0x16e
github.com/dedis/drand/core.initDrand(0xa54ac0, 0xc420156120, 0xc42009c000, 0xc4200225a0, 0xc4201999d0, 0xc4201beb70)
        /Users/jallen/go/src/github.com/dedis/drand/core/drand.go:86 +0x263
github.com/dedis/drand/core.LoadDrand(0xa54ac0, 0xc420156120, 0xc42009c000, 0xc420156120, 0x0, 0x0)
        /Users/jallen/go/src/github.com/dedis/drand/core/drand.go:94 +0x43
main.runCmd(0xc42001f080, 0xc42016ec78, 0x892891)
        /Users/jallen/go/src/github.com/dedis/drand/main.go:336 +0x274
main.main.func5(0xc42001f080, 0x100, 0xc42001f080)
        /Users/jallen/go/src/github.com/dedis/drand/main.go:151 +0x30
github.com/dedis/drand/vendor/github.com/urfave/cli.HandleAction(0x90ad60, 0xa0a0d8, 0xc42001f080, 0xc42001c400, 0x0)
        /Users/jallen/go/src/github.com/dedis/drand/vendor/github.com/urfave/cli/app.go:490 +0xc8
github.com/dedis/drand/vendor/github.com/urfave/cli.Command.Run(0x9e20aa, 0x3, 0x0, 0x0, 0x0, 0x0, 0x0, 0xa00144, 0x3e, 0x0, ...)
        /Users/jallen/go/src/github.com/dedis/drand/vendor/github.com/urfave/cli/command.go:210 +0xa36
github.com/dedis/drand/vendor/github.com/urfave/cli.(*App).Run(0xc42008f040, 0xc42001c0c0, 0x6, 0x6, 0x0, 0x0)
        /Users/jallen/go/src/github.com/dedis/drand/vendor/github.com/urfave/cli/app.go:255 +0x6a0
main.main()
        /Users/jallen/go/src/github.com/dedis/drand/main.go:187 +0x1aef

Formal paper/specification of the drand protocol

I am working on a survey paper of distributed randomness beacons and would like to know if there is a formal paper for the drand protocol? I have read the authors of this libraries previous work and will be including it in the paper but I would like to include this one as well.

"drand get private" does not say who it contacted

It takes the --nodes whitespace separated list. And also a group file to know the public keys of the nodes.

It returns:

{
    "Randomness": "d15e24aa8b0f1c20df0ef5e005c4b607f9448d420d550a1fb6e3bd768640b1ab"
}

I think there should be a "Node" in there, to tell me which server it ended up getting data from.

And I'd like, if --nodes is empty, that it defaults to all nodes in the group file.

And I'd like that items from --nodes are tried in a random permutation order.

With all those changes, then repeated calls to "drand get private" will talk to all the servers in the network.

Another possibility: an -all option, that causes each of the servers in the --nodes option to be tried. Then I can use "drand get private --all" to try talking to each of the servers and see which ones work.

fetch public "no such file or directory"

$ ./drand-000e5e56 f public dedis.nella.org:8890
open : no such file or directory

This seems to be because it expects a -p argument, but it is also unclear what I'm supposed to use as the -p argument.

beacon: save beacon requests received by requests

Now, a drand node "requests" signatures from other nodes, by sending a request containing the round and its own signature - to prove it's from a member of the group.
This signature is not saved by the receiving side; it is only verified.
A simple optimization is to save this signature since it is most likely useful for a node, instead of requesting it later on.

drand should return dist_key in correct format

Currently, the command drand fetch dist_key returns the following:

$ drand fetch dist_key <addr>:<port>
{
    "distributed key": "0130f99a9845f4088e7f3b1c62934bfcc3c15a82c4277cc2beb0346cdb78d7dcd05c0e17d511f8ad4292097bf3f0b28490e4d1448b5157c61fb7a1649115e44b4179b5669e6e57ec46b66b82c891fa6206ae4d5afab167f216157d9c3dec872e20300d6ea17ee642fce9c2bbbb7d1f434c5f135f6c32f1a7d34cc23eb60cd7589a"
}

The subsequently used command drand fetch public -p <dist_key> <addr>:<port> seems to expect the key formatted as such:

Key = "0130f99a9845f4088e7f3b1c62934bfcc3c15a82c4277cc2beb0346cdb78d7dcd05c0e17d511f8ad4292097bf3f0b28490e4d1448b5157c61fb7a1649115e44b4179b5669e6e57ec46b66b82c891fa6206ae4d5afab167f216157d9c3dec872e20300d6ea17ee642fce9c2bbbb7d1f434c5f135f6c32f1a7d34cc23eb60cd7589a"

I think dist_key should return the key formatted so it is ready for use with drand fetch public.

Stable way to detect and handle node failure

gRPC has numerous methods to retry to connect, detect failures and so on. We should try to have a unified way to handle failures, with a short timeout, as it impacts DKG's performance:
Before #108 we were sending resharing signal packet sequentially, and if a node is down, then the whole DKG only starts after gRPC says the node is down, which may take up to a minute sometimes.

Make a resharing follow on last update from previous group

Currently, after a resharing has been performed, the beacon generation loop simply starts back a new "chain", with the same seed as message. It would be better if it started from the last randomness generated by the previous group.

Fails to compile in go1.11

Current tip fails to compile with

github.com/dedis/drand/vendor/github.com/dedis/kyber/pairing/bn256.gfpMul: relocation target runtime.support_bmi2 not defined

Go 1.11 dropped support for support_bmi2, I believe. This is one example where we had to replace support_bmi2: cloudflare/bn256#2

I see that the group_info branch of dedis/kyber has already been fixed to use HasBMI2, but the vendored version of dedis/kyber in this directory uses an old version of group_info that uses support_bmi2.

Problem is, when I run dep ensure -upgrade to get the latest version of dedis/kyber on branch group_info, I end up with the another error about a signature mismatch between the kyber library and drand's usage of it:

dkg/dkg.go:70:39: too many arguments in call to "github.com/dedis/drand/vendor/github.com/dedis/kyber/share/dkg/pedersen".NewDistKeyGenerator
	have ("github.com/dedis/drand/vendor/github.com/dedis/kyber/share/dkg/pedersen".Suite, kyber.Scalar, []kyber.Point, int, kyber.Scalar)
	want ("github.com/dedis/drand/vendor/github.com/dedis/kyber/share/dkg/pedersen".Suite, kyber.Scalar, []kyber.Point, int)

Is there a specific commit in the kyper group_info branch that works in go11.1 and is compatible with drand?

"show share" kills server

I ran drand show share. The server exited with drand: could not load drand.share.

It is true that I don't have a share yet, because DKG has not been run yet.

However, it should not be possible to kill the server accidentally from the admin interface.

OSX Errors when Executing run_local.sh

For the record: I'm getting a lot of errors when executing run_local.sh on OSX, see the (cropped) error message below.

[...]
ERRO[0000] error waiting for container: context canceled
cp: /var/folders/gr/3df3f28j5hx283ksn7zx9v5w0051wc/T/tmp.Ge4NM84k/node4/drand_id.public: No such file or directory
docker: Error response from daemon: Mounts denied:
The path /var/folders/gr/3df3f28j5hx283ksn7zx9v5w0051wc/T/tmp.Ge4NM84k/node3/
is not shared from OS X and is not known to Docker.
You can configure shared paths from Docker -> Preferences... -> File Sharing.
See https://docs.docker.com/docker-for-mac/osxfs/#namespaces for more info.
.
ERRO[0000] error waiting for container: context canceled
cp: /var/folders/gr/3df3f28j5hx283ksn7zx9v5w0051wc/T/tmp.Ge4NM84k/node3/drand_id.public: No such file or directory
docker: Error response from daemon: Mounts denied:
The path /var/folders/gr/3df3f28j5hx283ksn7zx9v5w0051wc/T/tmp.Ge4NM84k/node2/
is not shared from OS X and is not known to Docker.
You can configure shared paths from Docker -> Preferences... -> File Sharing.
See https://docs.docker.com/docker-for-mac/osxfs/#namespaces for more info.
.
ERRO[0000] error waiting for container: context canceled
cp: /var/folders/gr/3df3f28j5hx283ksn7zx9v5w0051wc/T/tmp.Ge4NM84k/node2/drand_id.public: No such file or directory
docker: Error response from daemon: Mounts denied:
The path /var/folders/gr/3df3f28j5hx283ksn7zx9v5w0051wc/T/tmp.Ge4NM84k/node1/
is not shared from OS X and is not known to Docker.
You can configure shared paths from Docker -> Preferences... -> File Sharing.
See https://docs.docker.com/docker-for-mac/osxfs/#namespaces for more info.
.
ERRO[0000] error waiting for container: context canceled
cp: /var/folders/gr/3df3f28j5hx283ksn7zx9v5w0051wc/T/tmp.Ge4NM84k/node1/drand_id.public: No such file or directory
docker: Error response from daemon: Mounts denied:
The path /var/folders/gr/3df3f28j5hx283ksn7zx9v5w0051wc/T/tmp.Ge4NM84k
is not shared from OS X and is not known to Docker.
You can configure shared paths from Docker -> Preferences... -> File Sharing.
See https://docs.docker.com/docker-for-mac/osxfs/#namespaces for more info.
.
ERRO[0000] error waiting for container: context canceled
[+] Group file generated at /var/folders/gr/3df3f28j5hx283ksn7zx9v5w0051wc/T/tmp.Ge4NM84k/group.toml
[+] TO LIST THE BEACONS:

  ls /var/folders/gr/3df3f28j5hx283ksn7zx9v5w0051wc/T/tmp.Ge4NM84k/node1/beacons/

[+] TO VERIFY THE FIRST BEACON:

  docker run --rm -v /var/folders/gr/3df3f28j5hx283ksn7zx9v5w0051wc/T/tmp.Ge4NM84k:/tmp dedis/drand verify --distkey /tmp/node1/dist_key.public /tmp/node1/beacons/$(ls /var/folders/gr/3df3f28j5hx283ksn7zx9v5w0051wc/T/tmp.Ge4NM84k/node1/be
acons/ | head -n1)
[...]

should not require group file

Running without group file should not exit with error:

No group file given, drand will try to run as a beacon.
open /home/jallen/.drand/groups/drand_group.toml: no such file or directory

crypto/x509: system root pool is not available on Windows causes TestClientTLS to fail

As go-lang does not implement system CertPool on windows, the TLS test in main_test.go fails :

panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xc0000005 code=0x0 addr=0x20 pc=0x610de2]

goroutine 1 [running]:
crypto/x509.(*CertPool).AddCert(0x0, 0xc0420c9600)
        C:/Go/src/crypto/x509/cert_pool.go:95 +0x72
crypto/x509.(*CertPool).AppendCertsFromPEM(0x0, 0xc042182000, 0x442, 0x642, 0x642)
        C:/Go/src/crypto/x509/cert_pool.go:128 +0x144
github.com/dedis/drand/net.(*CertManager).Add(0xc0420880c8, 0xc042090040, 0x32, 0xc042090040, 0x32)
        C:/Users/mathi/go/src/github.com/dedis/drand/net/certs.go:37 +0x75
main.fetchPrivateCmd(0xc0420ab340, 0xc042083f20, 0x8a2208)
        C:/Users/mathi/go/src/github.com/dedis/drand/main.go:357 +0x4cd
main.main.func7(0xc0420ab340, 0x0, 0xc0420ab340)
        C:/Users/mathi/go/src/github.com/dedis/drand/main.go:174 +0x32
github.com/dedis/drand/vendor/github.com/urfave/cli.HandleAction(0x91ba40, 0xa1b470, 0xc0420ab340, 0xc042124500, 0x0)
        C:/Users/mathi/go/src/github.com/dedis/drand/vendor/github.com/urfave/cli/app.go:490 +0xcf
github.com/dedis/drand/vendor/github.com/urfave/cli.Command.Run(0x9f5286, 0x7, 0x0, 0x0, 0x0, 0x0, 0x0, 0xa130f3, 0x4c, 0x0, ...)
        C:/Users/mathi/go/src/github.com/dedis/drand/vendor/github.com/urfave/cli/command.go:210 +0xa3d
github.com/dedis/drand/vendor/github.com/urfave/cli.(*App).RunAsSubcommand(0xc0420a3040, 0xc0420ab080, 0x0, 0x0)
        C:/Users/mathi/go/src/github.com/dedis/drand/vendor/github.com/urfave/cli/app.go:379 +0xa17
github.com/dedis/drand/vendor/github.com/urfave/cli.Command.startApp(0x9f31e3, 0x5, 0x0, 0x0, 0xc042055380, 0x1, 0x1, 0x9fda25, 0x15, 0x0, ...)
        C:/Users/mathi/go/src/github.com/dedis/drand/vendor/github.com/urfave/cli/command.go:298 +0x8e0
github.com/dedis/drand/vendor/github.com/urfave/cli.Command.Run(0x9f31e3, 0x5, 0x0, 0x0, 0xc042055380, 0x1, 0x1, 0x9fda25, 0x15, 0x0, ...)
        C:/Users/mathi/go/src/github.com/dedis/drand/vendor/github.com/urfave/cli/command.go:98 +0x124d
github.com/dedis/drand/vendor/github.com/urfave/cli.(*App).Run(0xc0420a2d00, 0xc042092000, 0x6, 0x8, 0x0, 0x0)
        C:/Users/mathi/go/src/github.com/dedis/drand/vendor/github.com/urfave/cli/app.go:255 +0x6a7
main.main()
        C:/Users/mathi/go/src/github.com/dedis/drand/main.go:187 +0x1af6

--- FAIL: TestClientTLS (6.96s)
        Error Trace:    main_test.go:134
        Error:          Received unexpected error:
                        exit status 2
        Test:           TestClientTLS
FAIL

Ensure correct rights of config folder

When not existing the given config folder path is created with 0740 right bits. When it already exists, there is no verification mechanism that the folders are set with the appropriate rights.
We should at least check the rights on the folder and warn the user if something feels fishy about the rights.

Requesting public distKey fails: "unknown service drand.Info"

Hi there! I've been running into issues with the drand client, where my requests for a public distKey fail. I recreated this issue on a group of 4 drand nodes running locally. The drand nodes are indeed running as beacons locally, producing randomness every minute (excerpt):

beacon localhost:8003: next tick for round 34
beacon: localhost:8003 round 34 valid response from localhost:8002
beacon: localhost:8003 round 34 received partial randomness 2/3
beacon: localhost:8003 round 34 valid response from localhost:8001
beacon: localhost:8003 round 34 received partial randomness 3/3
beacon: localhost:8003 round 34 valid response from localhost:8004
beacon: round 34 finished: 3f6eb25409c5cef9288ea00f99bb846b03d5d66ec5d864d37f98e1d6181f56255fad6e897f9300eb52e2eb7fc4a72c5d225f9ec6e67b9d40a237f213daf1dd63
beacon: localhost:8003 round 34 finished: 
	final: 3f6eb25409c5cef9288ea00f99bb846b03d5d66ec5d864d37f98e1d6181f56255fad6e897f9300eb52e2eb7fc4a72c5d225f9ec6e67b9d40a237f213daf1dd63
	prev: 424c81e61979b6f820a667042a935c30fc7ab578fbbd0fe16e5eb11bb814099c1ca7f78ebc9f9d07f7f24402beedfb845e70679e64623129776e971ab87ae374

The problem is that, whenever I use drand's cli interface to request randomness from one of my nodes (running on port 8002), this first step fails:

$ drand fetch dist_key 127.0.0.1:8002 --insecure
could not fetch the distributed key from that server: rpc error: code = Unimplemented desc = unknown service drand.Info

TLS is set to false for this node. drand.Info is indeed specified as a service in client.pb.go, so I'm surprised that the service is not available. I suspect, for some reason, this service was not actually exposed as a method on drand when it is run as an insecure grpc server.

Errors on executing tests

When executing the tests, I am currently receiving the following errors:

Error 1

goroutine 86 [running]:
gopkg.in/dedis/kyber.v1/share/pedersen/vss.(*aggregator).DealCertified(0x0, 0xc420100500)
        /Users/cosh/Code/go/src/gopkg.in/dedis/kyber.v1/share/pedersen/vss/vss.go:597 +0x37
gopkg.in/dedis/kyber.v1/share/pedersen/dkg.(*DistKeyGenerator).qualIter(0xc420381180, 0xc420213958)
        /Users/cosh/Code/go/src/gopkg.in/dedis/kyber.v1/share/pedersen/dkg/dkg.go:282 +0xb3
gopkg.in/dedis/kyber.v1/share/pedersen/dkg.(*DistKeyGenerator).QUAL(0xc420381180, 0xc4202139c0, 0xc4202139c8, 0xc420020000)
        /Users/cosh/Code/go/src/gopkg.in/dedis/kyber.v1/share/pedersen/dkg/dkg.go:261 +0x66
gopkg.in/dedis/kyber.v1/share/pedersen/dkg.(*DistKeyGenerator).Certified(0xc420381180, 0x43d24a8)
        /Users/cosh/Code/go/src/gopkg.in/dedis/kyber.v1/share/pedersen/dkg/dkg.go:251 +0x2b
github.com/dedis/drand.(*DKG).checkCertified(0xc42010ed80)
        /Users/cosh/Code/go/src/github.com/dedis/drand/dkg.go:163 +0x8d
panic(0x435b000, 0x459d620)
        /usr/local/Cellar/go/1.9/libexec/src/runtime/panic.go:491 +0x283
gopkg.in/dedis/kyber.v1/share/pedersen/vss.(*aggregator).verifyResponse(0x0, 0xc42014a880, 0x4014582, 0xc42034e118)
        /Users/cosh/Code/go/src/gopkg.in/dedis/kyber.v1/share/pedersen/vss/vss.go:533 +0x4a
gopkg.in/dedis/kyber.v1/share/pedersen/vss.(*Verifier).ProcessResponse(0xc420122080, 0xc42014a880, 0x4, 0xc420380208)
        /Users/cosh/Code/go/src/gopkg.in/dedis/kyber.v1/share/pedersen/vss/vss.go:410 +0x39
gopkg.in/dedis/kyber.v1/share/pedersen/dkg.(*DistKeyGenerator).ProcessResponse(0xc420381180, 0xc420530260, 0x4, 0xc4201de198, 0x1)
        /Users/cosh/Code/go/src/gopkg.in/dedis/kyber.v1/share/pedersen/dkg/dkg.go:211 +0x7b
github.com/dedis/drand.(*DKG).processTmpResponses(0xc42010ed80, 0xc420142260)
        /Users/cosh/Code/go/src/github.com/dedis/drand/dkg.go:125 +0x29f
github.com/dedis/drand.(*DKG).processDeal(0xc42010ed80, 0xc42013d9a0, 0xc420142260)
        /Users/cosh/Code/go/src/github.com/dedis/drand/dkg.go:97 +0x2d6
github.com/dedis/drand.(*DKG).process(0xc42010ed80, 0xc42013d9a0, 0xc42048c2a0)
        /Users/cosh/Code/go/src/github.com/dedis/drand/dkg.go:80 +0x86
github.com/dedis/drand.(*Drand).processMessages(0xc420154960)
        /Users/cosh/Code/go/src/github.com/dedis/drand/drand.go:169 +0x368
created by github.com/dedis/drand.NewDrand
        /Users/cosh/Code/go/src/github.com/dedis/drand/drand.go:70 +0x1fb
exit status 2

Error 2

goroutine 28 [running]:
github.com/dedis/drand.(*Router).handleConnection(0xc42005e9c0, 0xc4200e86e0, 0x4573e40, 0xc42000e0c0)
        /Users/cosh/Code/go/src/github.com/dedis/drand/network.go:364 +0x188
created by github.com/dedis/drand.(*Router).connect
        /Users/cosh/Code/go/src/github.com/dedis/drand/network.go:309 +0x157
exit status 2

read /dist_public.toml: is a directory TEST <verify signature?>: FAILURE

When i try to run the script run_local.sh with more than 11 nodes I receive this error

message:read /dist_public.toml: is a directory TEST <verify signature?>: FAILURE

after the terminal show the message:

Starting the leader of the dkg

how can i test the program with more than 10 nodes?

run_local.sh affects my network.

I assign 192.168.0.1 to the default gateway and nameserver.

>route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.0.1     0.0.0.0         UG    0      0        0 ens33
192.168.0.0     *               255.255.255.0   U     0      0        0 ens33
>cat /etc/resolv.conf
nameserver 192.168.0.1

After running sudo ./run_local.sh, the network interface br-XXX is assigned to 192.168.0.1 and can not resolve address.

>ping www.google.com
ping: unknown host www.google.com

If I remove the interface, then I can ping.

>docker network ls

NETWORK ID          NAME                DRIVER              SCOPE
63b20fcb86f8        drand               bridge              local

>docker network rm 63b20fcb86f8

>ping www.google.com
PING www.google.com (172.217.26.100) 56(84) bytes of data.
64 bytes from kix05s01-in-f4.1e100.net (172.217.26.100): icmp_seq=1 ttl=51 time=12.3 ms

Is this a correct specification?

Problem with run_local.sh

After running successfully the first time run_local.sh, when i try to run another time the script, I receive the following error message:

cp: cannot stat '/tmp/drand/tmp.OQ0HXM6mUl/node1/drand_id.public': No such file or directory
cp: cannot stat '/tmp/drand/tmp.OQ0HXM6mUl/node2/drand_id.public': No such file or directory
cp: cannot stat '/tmp/drand/tmp.OQ0HXM6mUl/node4/drand_id.public': No such file or directory
cp: cannot stat '/tmp/drand/tmp.OQ0HXM6mUl/node3/drand_id.public': No such file or directory
cp: cannot stat '/tmp/drand/tmp.OQ0HXM6mUl/node6/drand_id.public': No such file or directory
cp: cannot stat '/tmp/drand/tmp.OQ0HXM6mUl/node5/drand_id.public': No such file or directory

I tryed to fixed this error removing all the content of the /tmp/drand directory but it dosent't work.
What can i do?

REST API endpoints specified in .proto files do not work

drand/protobuf/drand/client.proto defines services with a RESTful proxy on top of some drand services. For example,

service Info {
  rpc DistKey(DistKeyRequest) returns (DistKeyResponse) {
    option (google.api.http) = {
      get: "/info/dist_key"
    };
  }
}

This means that one should be able to request resources from a drand beacon with the following url:

http://<address>/info/dist_key

However, when I attempt to access the distributed key via http on a local cluster of drand nodes (using localhost:<port>/info/dist_key, I get a 404 Not Found. It seems that this RESTful proxy is not working.

DKG should employ timeout

The current DKG protocol works in synchronous network. Drand should use a timeout to determine whether the protocol is finished after a certain without any messages received. When the timeout triggers, one should call SetTimeout on the dkg handler from kyber to get the distributed key afterwards. Note that usually, the protocol finishes correctly and there's no need to resort to the timeout then.

Unified output for points / scalar

We should treat all points / scalar to string representation the same way, i.e.

{
   Group: "22",
   Scalar: <mylonghexstring>,
}

and

{
  Group: "22",
  Point: <mylonghexstring>
}

However, this will likely break backward compatibility...

dkg never finishes

Hi there! I'm strugging to run a local drand cluster on my machine.

When I attempt to run drand share, my cluster ends up hanging at

$ drand -f A share --leader group.toml --tls-disable
drand vtest-dev by nikkolasg @ DEDIS
WARNING: this software has NOT received a full audit and must be 
used with caution and probably NOT in a production environment.
drand: waiting the end of DKG protocol ... (you can CTRL-C to not quit waiting)

for all drand nodes I'm running.

For context, what I'm doing is using 4 different drand service directories (A, B, C, D) and one shared group.toml, which is as follows:

Threshold = 3
Period = "1m0s"

[[Nodes]]
  Address = "localhost:8000"
  Key = "01498d8ac39f53542f3f2761a85231dc7975a7a8abf07145f7962b5b00d70cb560087c6eecdc121c8dbe66f84a119ed52e7afe73f6c12153ad56b1686ec1ca05024ad77a8ba2f33710a18d35f8198c4a79cb19e1064e23eec5f7bbb50757539bb88c4e248d2ee67aa67203fbbd81edd613c7ddcf7b0024fe24ce79a78d7ec3724a"
  TLS = false

[[Nodes]]
  Address = "localhost:8001"
  Key = "0129b8687a23b97a00b918bdb6189f5f755426b52b194008798b775a0828b9dfd343dd25ca099fb94fa43b8b7899aaa0ece0fe775042095d547c0c1631371b1096611bb907a438082c0ff01fd7ebd859686a188188f6f404882fba23db2e3c4b0800d3f91a1d0d63d57db79a9f7f921c5e9a0ae57d81e58c82b8cd7311047afd39"
  TLS = false

[[Nodes]]
  Address = "localhost:8002"
  Key = "0148d9db5f8b9aa7253d0d19ecb0e841595a0576cac43fb26cacf6bd84b3a03572550ad16d99310673a31ea812e5c898c2b4fe262682605430930eb2d3430dd1aa415753f6eaf61ce50a831a60e0a44348e18f772545b93cb251fb3494bfc8980d0624980b1bcc31eeb132b95472b6a5c3ea036099ff667f5cad89c853ed1c1938"
  TLS = false

[[Nodes]]
  Address = "localhost:8003"
  Key = "017ca6ed635abf20f7c82e1ef0983e2f75902a6df995f9761a94ff40e7b9cbe13b33ca25b43644a3538fde0d73d9ce15e104096ba1c22e8ddf83008825f475878c669d67a4de78c630c41045b656b2f97da6779c48b31bbcfaaa8090fe96e5127f31419202818bae8e45bd92e79102fb794db6e4eec2b0ac1db6594c5da397bfd9"
  TLS = false

I run the drand daemon on separate listen ports and control ports for each drand instance:

drand -f A start --tls-disable --listen localhost:8000 --control 8888 &
drand -f B start --tls-disable --listen localhost:8001 --control 8889 &
drand -f C start --tls-disable --listen localhost:8002 --control 8890 &
drand -f D start --tls-disable --listen localhost:8003 --control 8891 &

I then try to start dkg with the following commands (each run in a different window):

drand -f A share --leader group.toml --control 8888 --tls-disable
drand -f B share group.toml --control 8889 --tls-disable
drand -f C share group.toml --control 8890 --tls-disable
drand -f D share group.toml --control 8891 --tls-disable

And I run into the hanging dkg output above :( Any tips on how to make this work? (For testing purposes before joining the larger drand project/cluster, I've been using multiple instances of drand on one machine to ensure that our ingress/egress configs from the drand cluster work).

Docker image size

We should see if it's possible to reduce the Docker image size. I think most of the size comes from the packages needed to compile the pairing based crypto library but it needs to be checked...

beacon: catch-up mode shouldn't be by default

After a sucessful DKG, drand automatically starts the beacon generation mode. It first looks if there is a beacon already saved. In that case, it assumes (wrongly) that it should be in catch-up mode. Catch-up mode simply means it waits for another drand daemon to request a beacon, so it can requests a beacon for the same round, hence catching up on the round number.

  1. This catch-up mode should be left as an option, argument to the method BeaconLoop()
  2. This catch-up mode is really trivially attacked, so more thoughts need to put into that.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.