Conversation
take changes from dev
# Conflicts: # src/main/java/net/helix/pendulum/TransactionValidator.java # src/main/java/net/helix/pendulum/controllers/RoundViewModel.java # src/main/java/net/helix/pendulum/crypto/Merkle.java # src/main/java/net/helix/pendulum/service/API.java # src/main/java/net/helix/pendulum/service/milestone/impl/MilestonePublisher.java # src/main/java/net/helix/pendulum/service/milestone/impl/MilestoneServiceImpl.java # src/main/java/net/helix/pendulum/service/validator/impl/ValidatorServiceImpl.java
| || transactionViewModel.getAttachmentTimestamp() > System.currentTimeMillis() + MAX_TIMESTAMP_FUTURE_MS; | ||
| } | ||
|
|
||
| private boolean isTransactionRequested(TransactionViewModel transactionViewModel) throws Exception { |
There was a problem hiding this comment.
The business logic here is not clear. The methods seems to do much more than its name says -- in particular "cancel" the request etc. TransactionValidator at least as its name suggests, should not change the internal state, and handling the requested txs should be a responsibility of TransactionRequester
There was a problem hiding this comment.
There were cases when transactions exist but also they were in requested list, this is why I have added an extra check.
| Map<Hash, Integer> occurrences = new HashMap<>(); | ||
| Map<Hash, Set<Hash>> milestoneHashes = new HashMap<>(); | ||
|
|
||
| int quorum = (int)(config.getConfirmationQuorumPercentage() * BasePendulumConfig.Defaults.NUMBER_OF_ACTIVE_VALIDATORS); |
There was a problem hiding this comment.
| } | ||
|
|
||
|
|
||
| private static Set<Hash> splitMilestonesMerkleRoot(Tangle tangle, Hash expectedMilestoneMerkleRoot, TransactionViewModel milestoneTx) throws Exception { |
There was a problem hiding this comment.
In view of our last discussion, does it make sense to simply pack milestone hashes into the bundle similar to the tips?
There was a problem hiding this comment.
It could be a solution, but what is the purpose of virtual transactions then?
There was a problem hiding this comment.
We will probably not use them at all, at least for now
No description provided.