profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/yiannisbot/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Yiannis Psaras yiannisbot BrexitLand :-o

ipfs/notes 340

IPFS Collaborative Notebook for Research

filecoin-project/specs 311

The Filecoin protocol specification

libp2p/notes 27

libp2p Collaborative Notebook for Research

ipfs-inactive/research 14

[ARCHIVED] Moved to https://github.com/ipfs/notes

yiannisbot/ns3-ipfs-ndn 7

Codebase to simulate production code with NS3 using Docker Containers

libp2p/gossipsub-hardening 4

testground plans for evaluating gossipsub under attack scenarios

yiannisbot/devgrants 0

want to hack on libp2p? this repo tracks libp2p endeavors eligible for incentivization.

yiannisbot/filecoin-docs 0

Filecoin Docs

yiannisbot/research 0

Research repo for the IPFS github org

yiannisbot/research-1 0

Research repo for libp2p

issue commentdrand/drand

Consider displaying the date in the beacon json object

Yeah, that's a tricky thing. Would it make sense to have an external supporting tool of some sort (even a simple script) to do the calculation of the date when the round was produced? Users can then check for themselves. Some downstream applications might need it, hence, I raised the issue.

yiannisbot

comment created time in 17 days

issue openeddrand/drand

Consider displaying the date in the beacon json object

Users of drand might need to have the date when the beacon was produced displayed in the JSON output.

The date at which the beacon was produced is determined by the round number, which can be translated to a timestamp. Under normal circumstances, the network produces the rounds at the right time and therefore, we can simply rely on the round number. This is because the timestamp would depend on which node you ask.

Despite having an indirect solution, it seems that it would be helpful if the timestamp corresponding to the round is displayed in the beacon output.

created time in 19 days

push eventdrand/drand

Emmanuel

commit sha b4378a500a5ae0392111945ddb1c7cb6ad480b22

Test improvements (#814) * v1.2.0 * add drand status values on Ping response * add new fields for Pong on protobuf definition * improve tests readability, remove sleeps from tests * avoiding duplication on grpc prometheus metrics * create a new service called Status, leaving Ping as it was before * improvements on more tests * improve lifecycle flags on beacon handler * apply fmt on the project * improve beacon lifecycle flags usability * refactor Status service in a more flexible way * improve readability on more tests, remove more sleeps * fix issues reported by linter * fix more issues reported by linter * update protoc-gen-go module on CI job * apply go mod tidy * add a new lifecycle flag for beacon handler, use it on tests * apply readability improvements on node tests, remove more sleeps * fix lint issues * fix flaky test on HTTP Mock server Co-authored-by: Will Scott <will@cypherpunk.email> Co-authored-by: Will Scott <will.scott@protocol.ai>

view details

push time in 23 days

PR merged drand/drand

Test improvements

In the PR, test improvements where applied. A list of them is write below:

  • Renaming was applied to improve test readability
  • Use Ping control message to get drand status. We use that data to remove sleeps on tests
  • Remove sleeps on some tests
+1879 -766

3 comments

34 changed files

emmanuelm41

pr closed time in 23 days

issue commentZondax/drand

Review / close open PRs in upstream repo

@jleni I believe outdated PRs have been closed now. Is this correct? Can you give an update on this? The remaining PRs look like things we should still do, or at least are not resolved yet - but do not get in the way of this project. What do you think?

jleni

comment created time in 24 days

issue openeddrand/drand

New metric to monitor remotely when nodes have updated before ceremonies

As we move towards fully async ceremonies, we need to develop all the tooling needed to remotely monitor the state of nodes both before (updating and restarting daemon) and during the re-sharing ceremonies (running the re-share comment).

We do have visibility on when a node has run the resharing command, during the ceremony (and that's very helpful), but we do not have a straightforward way to check if partners have updated and restarted their daemons before the ceremony. One easy way to do that is to check the uptime of nodes in the days/hours preceding the ceremony itself - the uptime needs to be smaller than a particular threshold (e.g., hours/days). For this, we need to add uptime to metrics, so that it can be checked/monitored remotely.

created time in a month

issue commentdrand/drand

Leader is not protected against replay of DKG operation

What's the reason that the leader would want to do this? Is it in case the command is run again by mistake? Could someone else pretend to be the leader to hijack the procedure and take over leadership? In my understanding this cannot happen.

nikkolasg

comment created time in a month

PR merged drand/website

Reviewers
Update specification docs

Closes this issue https://github.com/drand/drand/issues/730

+86 -121

2 comments

2 changed files

emmanuelm41

pr closed time in a month

push eventdrand/website

Emmanuel

commit sha a6833ec1697f37d456633ccb3b4b0aa58729529d

update specification docs

view details

Yiannis Psaras

commit sha 104aa431dd4ac9aabfefb70c9481ae0866692b0a

Merge pull request #108 from Zondax/update-docs Update specification docs

view details

push time in a month

issue commentdrand/drand

Drand nodes may end up generating beacons delayed from start of round

Thanks Juan! If this becomes a self-contained monitoring module that we can provide to drand operators it will be great!

willscott

comment created time in a month

issue commentdrand/drand

Drand nodes may end up generating beacons delayed from start of round

Thanks for doing this exercise @emmanuelm41! However, given it's not a blocking or critical issue, I suggest we leave it for now.

@willscott thanks for the details! Yes, we certainly need better measurement/monitoring infrastructure to be run by as many LoE members as possible. We've got it as a separate task, but given it's not critical, it's been pushed for a little further ahead in the future :)

willscott

comment created time in a month

issue commentdrand/drand

Drand nodes may end up generating beacons delayed from start of round

@alanshaw @willscott have you observed tis again since last year? Can you reproduce it?

@emmanuelm41 I don't think this is on our critical path and does not look like one we should prioritise for now, unless it blocks you with some other task?

willscott

comment created time in a month

issue commentdrand/drand

Adjust timeout / early completion logic in DKG to account for multiple expected copies of shares

@emmanuelm41 I don't think this is on our critical path for now (at least for the next push), so you can leave it for now.

willscott

comment created time in a month

issue commentdrand/drand

spec doc outaded

Yup, approved! Thanks for fixing.

nikkolasg

comment created time in a month

pull request commentdrand/website

Update specification docs

@nikkolasg can you also have a quick look before I merge?

emmanuelm41

comment created time in a month

PullRequestReviewEvent

push eventdrand/website

Alexander Borzunov

commit sha 94ad608f3679c93b283fd5b53d23737fa6437bec

Fix broken code formatting in specification.md

view details

Yiannis Psaras

commit sha 6523e468d0ec9b7378efb4db82c17c8052e9cdad

Merge pull request #105 from borzunov/patch-1 Fix broken code formatting in specification.md

view details

push time in a month

PR merged drand/website

Fix broken code formatting in specification.md

Currently, the specification is displayed with the broken code formatting:

Screen Shot 2021-08-16 at 5 16 20 PM

This PR fixes it.

+2 -2

0 comment

1 changed file

borzunov

pr closed time in a month

PullRequestReviewEvent

issue commentdrand/drand

About box on GitHub should link to drand.love

Oops! Of course! Missed that field :) Changed now.

Hexstream

comment created time in a month

issue closeddrand/drand

About box on GitHub should link to drand.love

A direct link at the top of the page would increase usability.

closed time in a month

Hexstream

issue commentdrand/drand

About box on GitHub should link to drand.love

Thanks for the suggesion. I've added the link to drand.love in the "About" part on the right side as you land to https://github.com/drand/drand. Is that what you mean?

Hexstream

comment created time in a month

issue commentdrand/drand

spec doc outaded

In fact, you can! :-D This is the repo for the website: https://github.com/drand/website and this is the spec: https://github.com/drand/website/blob/master/docs/docs/specification.md

PRs more than welcome! :)

nikkolasg

comment created time in a month

issue commentdrand/drand

spec doc outaded

Sure, it's here in the docs page of the drand.love site: https://drand.love/docs/specification/

nikkolasg

comment created time in a month

issue commentdrand/drand

Sync of historical data not needed when randomness becomes unchained

Making a decision on this will resolve the following open issues one way or the other:

  • https://github.com/drand/drand/issues/739
  • https://github.com/drand/drand/issues/760
  • https://github.com/drand/drand/issues/666
yiannisbot

comment created time in a month

issue commentdrand/drand

Fix flaky free port logic in tests

https://github.com/drand/drand/pull/315 never got merged, but @nikkolasg mentioned there that it was never an issue, so I'll let him comment. If it is the case, then, yes, let's close it.

petar

comment created time in a month

issue closeddrand/drand

panic in Home

Seen while debugging something else:

2019/09/11 14:55:02 http2: panic serving 128.178.151.190:63310: runtime error: invalid memory address or nil pointer dereference
goroutine 49582 [running]:
net/http.(*http2serverConn).runHandler.func1(0xc0002f9db0, 0xc00e0f9faf, 0xc000e11200)
	/usr/local/go/src/net/http/h2_bundle.go:5651 +0x16b
panic(0xa5b700, 0x10c5260)
	/usr/local/go/src/runtime/panic.go:522 +0x1b5
github.com/dedis/drand/core.(*Drand).Home(0xc00022bce0, 0xc10a40, 0xc00e2f39e0, 0xc00d79b460, 0xa26d60, 0xc00e418901, 0xc00d79b4c0)
	/home/drand/drand/core/drand_public.go:146 +0x102
github.com/dedis/drand/net.(*drandProxy).Home(0xc0002b0780, 0xc10a40, 0xc00e2f39e0, 0xc00d79b460, 0xc00d79b4c0, 0x2, 0x2, 0x0, 0x0, 0x8000103)
	/home/drand/drand/net/listener_grpc.go:219 +0x52
github.com/dedis/drand/protobuf/drand.request_Info_Home_0(0xc10a40, 0xc00e2f39e0, 0xc12600, 0x10f68a0, 0xc0c380, 0xc0002b0780, 0xc00f03c000, 0xc00e2f3950, 0x0, 0x1, ...)
	/home/drand/drand/protobuf/drand/info.pb.gw.go:53 +0xfb
github.com/dedis/drand/protobuf/drand.RegisterInfoHandlerClient.func3(0xc0f000, 0xc0002f9db0, 0xc00f03c000, 0xc00e2f3950)
	/home/drand/drand/protobuf/drand/info.pb.gw.go:145 +0x1c5
github.com/grpc-ecosystem/grpc-gateway/runtime.(*ServeMux).ServeHTTP(0xc0000c87e0, 0xc0f000, 0xc0002f9db0, 0xc00f03c000)
	/home/drand/go/pkg/mod/github.com/grpc-ecosystem/grpc-gateway@v1.8.5/runtime/mux.go:206 +0xd78
net/http.(*ServeMux).ServeHTTP(0xc0004fca80, 0xc0f000, 0xc0002f9db0, 0xc00f03c000)
	/usr/local/go/src/net/http/server.go:2375 +0x1d6
github.com/dedis/drand/net.grpcHandlerFunc.func1(0xc0f000, 0xc0002f9db0, 0xc00f03c000)
	/home/drand/drand/net/listener_grpc.go:237 +0x277
net/http.HandlerFunc.ServeHTTP(0xc0002b08a0, 0xc0f000, 0xc0002f9db0, 0xc00f03c000)
	/usr/local/go/src/net/http/server.go:1995 +0x44
net/http.serverHandler.ServeHTTP(0xc000427e10, 0xc0f000, 0xc0002f9db0, 0xc00f03c000)
	/usr/local/go/src/net/http/server.go:2774 +0xa8
net/http.initNPNRequest.ServeHTTP(0xc002820000, 0xc000427e10, 0xc0f000, 0xc0002f9db0, 0xc00f03c000)
	/usr/local/go/src/net/http/server.go:3323 +0x8d
net/http.(*http2serverConn).runHandler(0xc000e11200, 0xc0002f9db0, 0xc00f03c000, 0xc00d79b320)
	/usr/local/go/src/net/http/h2_bundle.go:5658 +0x89
created by net/http.(*http2serverConn).processHeaders
	/usr/local/go/src/net/http/h2_bundle.go:5392 +0x4f4

closed time in a month

jeffallen

issue commentdrand/drand

panic in Home

Good catch @emmanuelm41 - thanks! Closing.

jeffallen

comment created time in a month

issue openeddrand/drand

Sync of historical data not needed when randomness becomes unchained

Presently, when a node joins the drand network, they have to sync all the historical data from the genesis block in order to: i) establish trust by verifying the whole chain, and ii) get round $n$ randomness, in order to produce round $n+1$ randomness.

We are currently working to decouple randomness in round $n$ from randomness in round $n-1$, in other words, unchain the randomness that drand provides. When unchained randomness becomes the default, synchronising history (from the genesis block) will only be needed in order to respond to requests that ask for randomness at some point in the past, but not for producing new randomness.

That said, going forward, we've got the following options for syncing:

  1. We can leave things as they are and nodes still have to sync the way they do now.
  2. We do not require all members to be able to respond to past randomness requests.
  3. When a member that does not have the history is asked for a past round, they go and ask others on demand.
  4. We build a workflow that produces an image of the past randomness (from the genesis) at regular time intervals (e.g., per hour/day, or so) that new nodes (and nodes after failure) can fetch and sync from there to the current period. This will make things simpler and speed up the process (I believe).

I would disregard option 2) and would be most favourable with option 4). Happy to hear other opinions.

created time in a month

issue commentdrand/drand

Confusing message on join about saving the group.toml file

@thattommyhall is this still happening/relevant? It sounds to me that either nothing needs to be done (and we should close the issue), or it will take minimal time to change the message you're referring to. Can you please advise?

thattommyhall

comment created time in a month