Jude Nelson
> However, I don't think that (3) addresses the "long-range attack" problem for the following case: I'm not sure I communicated this well enough in my point (2). Specifically, I'm...
The fundamental problem here is that there exists a way for an attacker to do _O(1)_ work (i.e. to produce a private anchor block), and in doing so, can force...
Had a call with @kantai about this. Upon further reflection, this scheme cannot work by itself -- there's no way for a bootstrapping node to know in advance whether or...
I spent some time working through the solution space a bit more. I think the constraints we're working with are as follows: * Whatever we do, this is going to...
Wrapping up notes from the architecture meeting, the consensus going forward is to attack this problem in two phases: 1. Before code-freeze, make it so that the prepare phase is...
Wrote up a possible solution to this problem here: https://gist.github.com/jcnelson/b1aa4bef8b9adb0856b28d3a933ef9a0
Don't we already have this -- i.e. look at the log message's file name?
Closing criteria for this issue: * Get a PR merged that updates our logging macros to accept topics * Start using them
Hey! Are you running an event observer? Also, which release / Github commit are you running?
The consensus at the blockchain meeting is that `pow` exhibits well-defined behavior as-is. The issue is that it was not properly documented. @obycode will address the documentation.