- User Since
- May 14 2017, 13:52 (205 w, 5 d)
Wed, Apr 21
Why are the changes to P2PTxInvStore ignored?
Ok, now this is looking more like something that make sense. There is this encoding/decoding of the session key that needs to be addressed, but beside that, it's all good.
Tue, Apr 20
This is breaking the test suite, back to your queue. Please make sure you run it, this is happening way too often.
I note that you often submit patches that break everything. You should make sure that you compile/run what you submit.
This is pretty much good to go. Make sure isProofStateDustThreshold has a descriptive name.
Mon, Apr 19
This will allow for initializing the PeerData from the ArgsManager and make it independent from the Processor.
This kinda have the right idea, but the execution is a problem. For as long as you do these in the various constructors, you must have objects at the end, and therefore you end up constructing possibly invalid objects, which is just bad design.
The rationale of this patch doesn't rally make sense. If data aren't optional, then don't put them in the PeerData. If the name turn out to b confusing then rename.
Wed, Apr 14
On a side, note, if we commit to the proof score being the amount in satoshi, how do we handle overflows?
Wouldn't moving away imply to not do the translation in more and more places over time?
Tue, Apr 13
This is doing to many things at once. You should break this up, and, as you do so, you'll discover that there are various holes in some parts. This is just going to take forever to get all the parts right if they all prevent each other from moving.
Mon, Apr 12
You'll keep shuffling things around until you ask yourself the questions "What does the initialization?" "What does fetch the config?" "What does verify the validity of the different parameters?" and so on. Once you got the answers to these question, you need to apply them consistently.
Sun, Apr 11
You need to find what the right API for initialization is. Fixing the current API is mostly motion not progress. If you initialized where thing should be initialized, you wouldn't need to access the proof here now (maybe later, but later is later) and therefore, you wouldn't need to figure out what is the right API to access the proof.
Thu, Apr 8
The PR in the description is not correct
You need to read your code, it is telling you things and you are ignoring these things.
Wed, Apr 7
Tue, Apr 6
Why not just check for IBD status in runEventLoop ? What benefit does all this complication achieves?
Some open question, but this is better.
Sat, Apr 3
What problem removing the distinction between master key and session key solves? It seems to me like it's making security of the whole thing worse for no good reason.
Thu, Apr 1
The use case does not make sense. You don't want to have a long delegation chain for all the node one after the other anyways, you want to have a master key and delegate to each node. There is no point delegating to begin with if the master also have all the private key to which it is delegating. If you want to do that, you might as well distribute the master key instead of devising a complicated scheme that isn't any more secure.
You want to fix the proof size handling before moving on there, or you'll just multiply the point where this needs fixing.
Tue, Mar 30
What problem is this solving?
Feb 23 2021
Jan 26 2021
rebase from hell
Jan 25 2021
Make it a config to begin with.
Jan 23 2021
Jan 22 2021
Jan 21 2021
Back to your queue due to test failures.
Jan 18 2021
The config is needed down the road is just saying nothing at all.
You say that it differs from the original by passing a config, but provide no reason as to why. It doesn't looks like to me that this difference is justified.
Jan 16 2021
Jan 14 2021
Jan 13 2021
I know there isn't int he original code, but there should really be tests cases for this.
Jan 12 2021
Jan 11 2021
Jan 10 2021
The requested change differ from the existing code style for a benefit that is at best elusive.
Remove debug logs