Conversation
I was observing expected progress != horizon. That violates the design goals of PTO. Fixed now. Validated only on Bitcoin/honest.
1. make room for a new generic attack model / implicit mdp 2. move old scripts, notebooks, and thoughts into sprint-* dirs I've checked that the .py scripts work and the tests pass. I did not bother with the notebooks, sorry.
It works, but state size explodes massively. The old generic_v0 model has two tweaks that probably help: merging isomorphic states and forcing the attacker to consider its own blocks. One of the next steps should be to evaluate how generic_v0 behaves with these mechanisms turned off. Then adapt the effective mechanisms for generic_v1. Note. I think I've observed that the v1 model explores much faster than the v0 model. This can be due to the pickling or the merging of isomorphic states in v0. Investigate!
This reverts commit 5a5e40f.
The problem here was: the heuristic allowed for partially removing parents of blocks. This breaks the semantics of the BlockDAG and is not safe. The new version should avoid this case; we now check that none of the removed blocks has children among the future of the new genesis block.
546b9d0 to
0b6683b
Compare
e0a461c to
974c785
Compare
775feec to
3443634
Compare
Fun fact: progress(b) == 1 and Python disambiguates comparison of lists by length. So the old code was obscure but correct.
The current stale block removal mechanism does not remove invisible or ignored blocks. Withheld or ignored stale block blow up the state space considerably. I've here drafted a more aggressive approach, that only keeps such blocks that stay relevant in the future. On a first glance, the results look promising: For Bitcoin we meet the state sizes of the fc16 model at 9 blocks. However, I worry a bit that this restricts the policy too much. Are we maybe forcing honest behavior? ... running some value iterations ... It's even worse; this gives advantage to the attacker. There is a policy reaping _all_ rewards. A completely separate problem is: as this enables quite big BlockDAGs (good), the exploration takes much longer (bad). I guess there is some quadratic (or more) factor w.r.t. BlockDAG size. One quadratic factor was in the exploration logic, where I step up the DAG size limit by one while starting exploration from scratch each time. Works okay if the state size grows fast; less so if the growth is close to linear. Circumvented this with binary search for the upper limit. Even better would be to reuse the already explored MDP for the next DAG size limit, similar to the depth limit in the policy guided explorer. I suspect there is another quadratic factor in the model logic itself. Maybe it's only the asserts?!
Owner
Author
|
Described in the following preprint. Going to merge this now. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This already covers GhostDAG, Ethereum and Parallel Proof-of-Work. Tree-style (Tailstorm) and DAG-style (#47) voting will be easy to add.