OkPay seems to have rebranded to Weezzo.
The OkPay webpage is offline but some links go to Weezzo.
Seems pretty unprofessional hwo they did the move...
Seems they have been involved with BTC-e…
https://bitcointalk.to/index.php?topic=2094721.0
- Add COMPENSATION_REQUEST_MIN_AMOUNT and COMPENSATION_REQUEST_MAX_AMOUNT
As BSQ based validation values can change over time if BSQ value
rise we need to support that in the Params as well.
- Add validateParamValue to ChangeParamValidator
- Remove voteRevealInputState and replace with isVoteRevealInputInValid
in TxInputParser
- Rename optionalVerifiedOpReturnType to optionalOpReturnType
- Replace if checks with checkNotNull if case must not happen
- Remove unused isLastOutput param
- Inline handleOpReturnOutput code to processOpReturnOutput
- Remove class fields remainingInputValue and use a local var instead
- Rename getOptionalVerifiedOpReturnType to getOptionalOpReturnType
- We cannot validate the txType at startup as the blockchain is nto ready at that moment. So we cannot apply that validation when we receive the payloads. We do the validation instead at the access to the lists.
- We fix a glitch with missing cycle start time in ResultsOfCycle
- Cleanup in VoteResultView
- If both verifiedOpReturnType and opReturnTypeCandidate are empty we
got an error logged. We change that so that only of both are present
but not matching we log a warning.
- Rename excludeBsqUnlessDaoTradingIsActive to
isNotBsqOrBsqTradingActivated to make it more clear
- Fix wong check with getDefaultBaseCurrencyNetwork (use
getBaseCurrencyNetwork instead)
- Add comment to support network check or Tokens
- If user press cmd+t it switches to DEBUG log level for the tor
network library. If the user press it again it switch back to WARN level.
- If there is a connection startup timeout where we display the Tor
network settings popup we switch log level as well to DEBUG.
- When creating the ballot list we used all ballots of all cycles.
We added a new method to get the ballots of the current cycle.
- Add check if optionalTx.isPresent() in isTxInPhaseAndCycle
- Set PHASE_VOTE_REVEAL duration to 2 blocks as 1 block would cause an
invalid state (confirmation block is one block after phase)
- Rename getStateBuilder to getBsqStateBuilder
- Rename JsonBlockChainExporter to ExportJsonFilesService
- Remove getBlocksFromState method
- Add ExportJsonFilesService to DaoSetup and implement DaoSetupService
- Add json dir for all json sub dirs
- Move access to bsqStateService out from thread in ExportJsonFilesService
- Only do write to disk in thread
- Sync model files
- Rename JsonBlockChainExporter to ExportJsonFilesService
- Remove getBlocksFromState method
- Add ExportJsonFilesService to DaoSetup and implement DaoSetupService
- Add json dir for all json sub dirs
- Move access to bsqStateService out from thread in ExportJsonFilesService
- Only do write to disk in thread
If a transaction is considered invalid it should consider all the
txOutputs to be invalid. To avoid counting a txOutput as valid it's
better to commit to stateservice only after checking the validity of the
transaction.
Since the effects of opreturn act on the BSQ outputs it makes more sense
to parse the opreturn before parsing the remaining outputs.
Put the lock time in the LOCKUP txOutput. It makes more logical sense to
keep it there.
# Please enter a commit message to explain why this merge is necessary,
# especially if it merges an updated upstream into a topic branch.
#
# Lines starting with '#' will be ignored, and an empty message aborts
# the commit.
Apple disabled options do avoid App Nap in recent OSX versions.
Playing an inaudible sound marks the application for preventing to get
set to standby mode as well as App Nap mode.
The alternative to that "hack" would be to add OSX native code, but
even then it is likely only possible to prevent App Nap but not
sleep mode.
If Bisq is in App Nap mode offers cannot be taken as well the user loses
network connection and offers.
See: https://github.com/bisq-network/bisq/issues/1701
This commit essentially cherry-picks the changes made in ea8cbc1,
re-applying them after the renaming of CoreSeedNodesRepository =>
DefaultSeedNodeRepository that happened earlier on this branch. The
other changes made in that original commit are no longer relevant here,
or have already been made in earlier commits on this refactoring branch.
Problem: d218094 set the version to 0.7.0-SNAPSHOT, but that change
failed to produce the intended effect detailed in the commit comment.
Setting the version to a value like 0.7.0-SNAPSHOT works fine when
publishing artifacts to a local ~/.m2 repository, but JitPack has no
awareness of version metadata within pom files, and can only retreive
artifacts based on Git metadata, namely tags, branch names and commit
hashes. This means it is impossible to resolve artifacts from JitPack
with a GAV like `io.bisq.exchange:core:0.7.0-SNAPSHOT` unless there is a
branch named `0.7.0`. This is why the pull request at
bisq-network/bisq-seednode#1 failed.
Solution: JitPack supports the semantics of Maven-style `-SNAPSHOT`
versioning, and as a special case, allows for versions to be named
literally `-SNAPSHOT` with no preceding version string [1,2]. This
commit sets all Maven versions to `-SNAPSHOT`, achieving the original
effect intended by d218094. Now downstream components (like
bisq-seednode) can resolve dependencies seamlessly from JitPack or a
local ~/.m2 repo with a GAV like `io.bisq.exchange:core:-SNAPSHOT`. This
is a slightly unconventional arrangement, but should actually result in
fewer updates to pom files over time as there may in fact be no reason
to ever change this version string so long as we continue using JitPack
and avoid publication to Maven Central / JCenter or similar.
[1]: https://jitpack.io/docs/#building-with-jitpack
[2]: https://github.com/jitpack/jitpack.io/issues/351
See #1440
Problem: When resolving Bisq libraries, e.g. `core` or `network` from
JitPack for use in other components like bisq-seednode or
bisq-pricenode, we have historically, resolved them by tag or by
branchname, e.g. with GAV coordinates like `io.bisq:core:v0.6.7` or
`io.bisq:core:master`. This works well enough, but now that we are
beginning to modularize more aggressively, we want to make sure that
it's possible at any time to publish the latest snapshots of these
libraries to one's own local ~/.m2 repository such that they can be
easily resolved from downstream components without the need to push
commits to the bisq-network/exchange remote, and to wait for JitPack to
do a just-in-time build.
Solution: By updating the version value of all modules here in the
exchange repository from 0.6.7 => 0.7.0-SNAPSHOT, one can run
`mvn install` to publish the latest "snapshot" of exchange libraries to
the local ~/.m2 repository and be sure to resolve them from whatever
downstream component that they are working on. The -SNAPSHOT qualifier
ensures that no caching occurs, and that the very latest such binary
will always be used.
This new arrangement creates a situation where one can transparently
resolve these dependencies remotely from JitPack and then subsequently
resolve them locally from one's ~/.m2 repository without having to
change a line of code.
It also opens up the ability to manage all Bisq components together in a
single IDE window as if they were all in one repository, avoiding the
need even to issue a `mvn install` command to publish locally--but
that's not the main focus of this change.
Note that the change to 0.7.0 here is based on the fact that we already
planned to have the next version shipped from `master` be 0.7.0, as
there are quite a few new UI changes that probably merit the bump in
minor version. The version change also aligns well with the fact that
we're modularizing a number of components right now, and all
newly-extracted components have been jumping to v0.7.0 to indicate their
new independent status. This has been the case with bisq-seednode and
pricenode so far.
Finally, it is important to note here that the ONLY versions updated by
this change are those specific to Maven metadata and therefore artifact
management / dependency resolution. The version that the Bisq desktop
client reports in its UI and to the network in its user agent has NOT
been changed, on account of the fact that users may run Bisq from
source, and we need to think through more fully the implications of
reporting a verison like 0.7.0-SNAPSHOT in those situations. Here is a
list of files containing the old version (0.6.7) that have NOT been
updated:
- common/src/main/java/io/bisq/common/app/Version.java
- package/linux/32bitBuild.sh
- package/linux/Dockerfile
- package/osx/create_app.sh
- package/osx/finalize.sh
- package/windows/32bitBuild.bat
- package/windows/64bitBuild.bat
- package/windows/Bisq.iss
- package/linux/64bitBuild.sh
One thing we know for sure that wouldn't work here is that Bisq's
Version class currently does not support -SNAPSHOT qualifiers. It just
breaks the version string validation entirely. So we'd need to patch
that in any case if we do decide it's a good idea to let pre-release
builds report their version accurately.
Problem: The current `io.bisq` groupid does not align with the way
JitPack supports custom groupids. In order to be able to both resolve
artifacts from JitPack *and* be able to resolve the same artifacts from
one's local ~/.m2 repository, Bisq artifacts need to have the same GAV
coordinates everywhere (groupid, artifactid, version).
Solution: This commit changes all groupids from io.bisq =>
io.bisq.exchange to match the GAV coordinates produced / expected by
JitPack.
So where Bisq's core module would previously have been resolvable with
GAV coordinates `io.bisq:core:v0.6.7` it will now be resolvable as
`io.bisq.exchange:core:v0.6.7`.
Note that this change is not just to satisfy JitPack idiosyncracies, but
is actually good naming practice anyway where a multi-module build is
involved, and is arguably the way it should have been all along.
[1]: https://jitpack.io/docs/#publishing-on-jitpack
Prior to this change, the contents of io.bisq.core.network were in fact
all seednode-related, and the main public type in this package,
DefaultSeedNodeRepository, is an implementation of
io.bisq.network.p2p.seed.SeedNodeRepository. This repackaging makes
better reflects these facts, making it more obvious to the unitiated
what this package is all about, and preserving the unqualified
io.bisq.core.network package for future expansion into non-seednode
related areas.
Public members of package-private classes are in effect still
package-private. Leaving the public modifier in place on these members
(as opposed to marking all members package-private) is beneficial for
two reasons:
1. It leaves these members looking "normal" to the trained Java eye.
Readers are not left wondering why constructors and methods are
package-private. They can notice, if and when appropriate, that the
class itself is package-private, and can understand the transitive
visibility of each member on that basis. Otherwise, the class is left
looking conventional, unsurprising, and therefore as easy as possible to
read and understand.
2. It leaves the visibility of these members controlled by a single
modifier at the class level as opposed to N+1 modifiers (one for every
member + the class itself). Should the class in question for some reason
need to be promoted to public visibility, for example if it were to be
moved to a different package, its members would automatically inherit
the now-public visibility of the class, which is likely to be the
desired state, because if the class needs to be public, at least some of
its members will need to be public too. The maintainer making that
change can (and should) reduce the visibility of any members that should
remain package-private (e.g. those that exist only for for testing
purposes), but in doing so, they make an explicit and self-documenting
decision that will show up at the level of a Git diff.
The original name was intended to distinguish that this implementation
is the implentation that lives within Bisq's 'core' module. This commit
renames the class to DefaultSeedNodeRepository as this is more idiomatic
and intention-revealing. This implementation is in fact the only one
ever gets used; it is the 'default' (and only) implementation.
The idiomatic approach to naming domain-driven design (DDD)-style
repositories is to use the singular form of the object being
encapsulated by the repository, e.g. BookRepository vs. BooksRepository.
Thus far, the repository interfaces and implementations created here in
Bisq have used the latter, plural form, but going forward we should
revert to the norm. To this end, this commit renames SeedNodesRepository
and its single implementation to SeedNodeRepository and
CoreSeedNodeRepository respectively.
NetworkStressTest has been ignored for months because it had become
"outdated" and is therefore now dead code. It is the only place that the
CoreSeedNodesRepository#setTorSeedNodeAddresses
and #setLocalhostSeedNodeAddresses methods were called. Removing it
completely allows for removing these methods and marking the underlying
fields in CoreSeedNodesRepository as final.
The case where the Bsq input equals the compensation request fee will
generate a transaction with no bsq output. It's still an allowed
compensation request. There should still be an issuance output that's
not yet considered bsq.
