omnilayer / omnij Goto Github PK
View Code? Open in Web Editor NEWOmniLayer for Java, JVM, and Android
License: Apache License 2.0
OmniLayer for Java, JVM, and Android
License: Apache License 2.0
We need to fix some SLF4J configuration (in bitcoinj?) that is causing the following error message in :
foundation.omni.test.rpc.sto.MSCSendToOwnersTestPlanRawSpec STANDARD_ERROR
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
The OmniLayer.org site has a Repositories section that should list OmniJ.
When executing the Gradle tasks, for example ./gradlew :omnij-rpc:regTest
, then the output is rather cryptic and non-telling:
> ...
> Building 94% > :omnij-rpc:regTest > 27 tests completedfoundation.omni.test.rpc.misc.ClientConfigurationAndFundingSpec STANDARD_ERROR
> Building 94% > :omnij-rpc:regTest > 27 tests completed Apr 14, 2015 10:33:10 PM org.slf4j.Logger$info call
> Building 94% > :omnij-rpc:regTest > 27 tests completed INFO: Waiting for server...
> Building 94% > :omnij-rpc:regTest > 27 tests completed Waiting for server RPC ready:
> Building 94% > :omnij-rpc:regTest > 27 tests completed
> Building 94% > :omnij-rpc:regTest > 27 tests completed RPC Ready.
> Building 94% > :omnij-rpc:regTest > 27 tests completed8 tests completed9 tests completed30 tests completed1 tests completed2 tests completed3 tests completed4 tests completed5 tests completed6 tests completed7 tests completed8 tests completed9 tests completed40 tests completed1 tests completed
> Building 94% > :omnij-rpc:regTest > 41 tests completedfoundation.omni.test.rpc.smartproperty.SmartPropertySpec STANDARD_ERROR
> Building 94% > :omnij-rpc:regTest > 41 tests completed Apr 14, 2015 10:33:12 PM org.slf4j.Logger$info call
> Building 94% > :omnij-rpc:regTest > 41 tests completed INFO: Waiting for server...
> ...
It would certainly be possible to manually add a log entry for each test, but I was wondering, if there is a more Groovy way to report the current test, which is executed?
Just yesterday I stumbled upon your talk about unit and regtests tests and I was quite impressed.
I noticed a few points you mentioned:
Very recently, I think, Bitcoin Core master basically build a Python framework for regtests that takes care of a few things in particular:
My initial goal was to port the few regtests of Master Core v0.0.8, but I ended up modifiying the framework and basically hacked a Master Core regtest framework together. In the context of above:
I haven't explored bitcoin-spock yet (unfortunately!), and I'm not sure, if this is of any help, but wanted to let you know as soon as possible. :)
Regarding consensus hashes, I started mastercoin-MSC/mastercore#143 some time ago.
In BitcoinClient.java#L61-L67, when waiting for the server, and a SocketException
is caught, then the stack trace should not be dumped, if certain certain expected exception messages are identified. This is pretty straight forward, to suppress errors while waiting.
However, those messages are localized, even without getLocalizedMessage()
, and this causes a lot of output.
Could we replace those checks and suppress all ConnectException
? Or is there an alternative to using the exception messages?
From an user's point of view, there are probably three relevant outcomes in this context, which should be handled differently:
A failed authorization can be identified as JsonRPCException
with httpCode = 401
, but the other two are probably more tricky: a refused connection expresses itself as ConnectException
, but I was unable to see "waiting" in action.
To keep track of this issue:
MSCSendToOwnersConsensusComparisonSpec fails, when run after a fresh start, because there the sender is the only holder, and therefore no "send-to-owner" transaction takes place at all.
I just noticed those values are part of the output of the RPC call "getinfo", so it's possible to get rid of the magic numbers. Won't start this today, but I assume it's basically switching from value = magicnum
to value = getInfoRpcCallResult['key']
.
There are a few situations where one needs to be careful when using BigDecimal
or rather number conversion.
Here is an example:
This can become an issue when using external data, such as a test plan, with indivisible amounts like 9007199254740993
in this example.
A "native" NumberOfCoins class would be helpful, with BigDecimal as underlying value type, but proper constructors, string representation and so on.
We have divisible and indivisible amounts, with different ranges each, and furthermore different use-cases, for example send_MP
which consumes the number as string ("1,0", "0.00000001", "1"), as well as the creation methods, which use the number represented in units, where "1.0" is actually "100000000".
I claim: if the "send to many owners" tests work for 20 owners, then they also work for 200 or 2000.
Given my extensive testing with owner numbers of 25000, and that the dry runs were intended for debug purposes, I suggest:
What's your opinion on this, what are good numbers to test?
Context: foundation/omni/test/rpc/sto/MSCSendToManyOwnersSpec.groovy#L220-L236
Hey @msgilligan,
OmniJ's RPC tests are now executed via Travis CI for Omni Core, but for some reason the standard output of :omnij-rpc:regTest
is pretty messy, and differs from what I see locally:
Do you know why, by any chance? :)
See the work in the branch msgilligan-cliapi-traits
Currently there are 3 (Omni Foundation) CI jobs that build/test bitcoin-spock
, but all of them build it to use for running integration tests:
The main reason is that none of those jobs run the bitcoin-spock
unit tests (in src/test/groovy/
). But it also makes sense to have the API Docs (GroovyDoc) built there.
Once a JVM binding is available for libconsensus, Spock tests could be a very good way to test both the JVM binding and libconsensus itself.
There is not much documentation on libconsensus at this point, but it is mentioned int the Bitcoin Core 0.10.0 Release Notes
See also:
The tests:
com.msgilligan.bitcoin.cli.BitcoinJCliSpec: "generate a block"
com.msgilligan.bitcoin.rpc.DynamicRPCClientSpec: "setgenerate"
... fail, when using Bitcoin Core 0.10, because setgenerate
doesn't return null
anymore, but a list of block hashes.
@msgilligan: I was wondering: are the tests in ./src/test/test_bitcoin and ./src/qt/test_bitcoin-qt executed when testing Master Core? There is also a Java RPC test suite which can be included directly into the build process and configuration: https://github.com/TheBlueMatt/test-scripts
A build script could probably look like this:
JAVA_COMPARISON_TOOL_URL=https://github.com/TheBlueMatt/test-scripts/blob/38b490a2599d422b12d5ce8f165792f63fd8f54f/pull-tests-0f7b5d8.jar?raw=true
JAVA_COMPARISON_TOOL_HASH=ecd43b988a8b673b483e4f69f931596360a5e90fc415c75c4c259faa690df198
# setup dependencies etc.
curl -k -L -o ./share/BitcoindComparisonTool.jar $JAVA_COMPARISON_TOOL_URL
if [[ "$(sha256sum ./share/BitcoindComparisonTool.jar)" != "$JAVA_COMPARISON_TOOL_HASH ./share/BitcoindComparisonTool.jar" ]]; then echo "Hashes don't match."; exit 1; fi
# build
./autogen.sh
./configure --with-comparison-tool=./share/BitcoindComparisonTool.jar
make
# IIRC required for the bitcoind-comparison-test
cp ./src/mastercored ./src/bitcoind
cp ./src/mastercore-cli ./src/bitcoin-cli
make check
This downloads the Java test file and builds Bitcoin/Master Core with "test awareness". make check then executes the Boost tests (test_bitcoin, test_bitcoin_qt) as well as the bitcoind-comparison-test.
Specifically, with a hot wallet of (Test)BTC and MSC and/or TMSC, it would be nice to be able to take some/all of the transactions in the STO TSV file and put them out on TestNet and/or MainNet.
When trying to fund an address with an amount that has the last two digits set, it fails.
For example:
createFundedAddress(1.00000000, 0.00000010)
createFundedAddress(1.00000000, 0.00000001)
createFundedAddress(1.00000000, 1.00000010)
...
This is because creating 10 willets would require a BTC payment of 0.000000001 BTC.
Currently transaction fees and exodus/reference output amounts are hardcoded in OmniTxBuilder
. These fees need to be dynamically and correctly calculated.
I started to use the spock test suite way too late, because I initially assumed it would be a pain to setup, and I hadn't any idea how the gradle tasks work, or that the bash scripts sort of take care of the startup, and it was further not 100 % clear how the binary, the datadir and bitcoin.conf fit together, or that certain RPC credentials within the config were required. There was also the bad taste of some older Master Core 0.0.8 regtests, which looked like "one-click" scripts, but it turned out they used my default bitcoin.conf, and executed the tests on the current network (fortunally this was testnet at that time!).
@msgilligan convinced me to give it a try, after mentioning it really is just cloning the repo, and starting the tasks.
In a longer email conversation with @zathras-crypto I tried to explain how to setup IntelliJ IDEA and run the tests from within the IDE, but it's obvious, that this isn't a great way to hover into the waters either.
Now, actually it takes only four lines to get started, no scripts, no config, and no IDE, assuming Omni Core was already built:
# start omni core in regtest mode
~/omnicore$ ./src/qt/bitcoin-qt -datadir=/tmp -server -rpcuser=bitcoinrpc -rpcpassword=pass -rpcallowip=127.0.0.1 -regtest -txindex
# clone and run the tests
~/$ git clone https://github.com/OmniLayer/OmniJ.git
~/$ cd OmniJ
~/OmniJ$ ./gradlew omnij-rpc:regTest
Instead of using the QT client, this works of course also with bitcoind and in daemon mode:
~/omnicore$ ./src/bitcoind -datadir=/tmp -daemon -server -rpcuser=bitcoinrpc -rpcpassword=pass -rpcallowip=127.0.0.1 -regtest -txindex
... and to stop bitcoind daemon afterwards:
~/omnicore$ ./src/bitcoin-cli -datadir=/tmp -rpcuser=bitcoinrpc -rpcpassword=pass -regtest -rpcwait stop
So where I'm going? I'm not sure, where this project is heading (e.g. testing or mobile applications), but in my opinion it would probably be helpful, if the README.md
is updated to have a straight forward "Getting started" section at the top.
Further, it would be awesome, if there were a quick instruction how to run a single test (I assume this is possible), instead of the whole test suite.
@zathras-crypto: did you give it a try in the meantime? If not, what was the reason to hesitate, and if so, what would you say would have made it easier for you to start?
Create library functions that can create raw Omni Protocol transactions that can be sent over the peer-to-peer network directly (e.g. via bitcoinj)
We currently have support for creating raw Bitcoin and Omni transactions using RPC calls designed for that purpose and some work towards creating raw Bitcoin transactions with bitcoinj, but do not have the capability to generate a complete Omni transaction in a client-only configuration.
This Issue assumes that Issue #12 will be completed first, although the same basic reorganization could be done in sub packages of org.mastercoin
.
Currently all the useful Omni Protocol RegTest tests are in the org.mastercoin.test.rpc
package. I propose a new package hierarchy to improve reporting. Something like:
foundation.omni.test.rpc.sto
- Send To Owners testsfoundation.omni.test.rpc.dex
- Distributed Exchange testsfoundation.omni.test.rpc.basic
- basic tests of RPC functionsfoundation.omni.test.rpc.misc
- miscellaneous tests using RPCThis will allow us to view Jenkins reports at the package level and focus on a particular category of tests like "STO".
Currently the test Specs are all lumped together in a single package, generating this report. Adding an extra level of hierarchy here should make things more logical and allow us to write documentation with links to the reports for just one package, such as "STO".
I need to dig deeper in the actual issue. Sure, we could ban all uses of where we don't construct BTC transactions ourself (special note: there is no check either, but given the funding with coinbase coins, it's less likely to hit a maximum), but this doesn't feel right.
It needs to be investigated what causes the error and how to fix it (upstream?) or how to avoid causing it.
We need to overthink funding and other methods once again, I believe. There are two points I noticed already:
setgenerate
returns no longer null
, but a list of block hashes. This is an easy fix.
Assuming we start fresh and generate a block with setgenerate true 1
, and then using getnewaddress
, then the address is returned that received the generated coins. When getnewaddress
is used before generating a block, then it looks like it's another address.
Unfortunally this is a very annoying issue, and I'm not sure where it's coming from.
The issue I'm referring to was already outlined in #44, but I assumed it somehow wasn't an issue anymore, after we restructured the funding methods:
Assuming we start fresh and generate a block with setgenerate true 1, and then using getnewaddress, then the address is returned that received the generated coins. When getnewaddress is used before generating a block, then it looks like it's another address.
The behavior might not be exactly as described, and it's unclear to me how and why it happens.
When I start the regtests locally on this machine, the first test fails:
foundation.omni.test.rpc.reorgs.SendToOwnersReorgSpec
After invalidating a send to owners transaction, the transaction is invalid
foundation.omni.test.rpc.reorgs.SendToOwnersReorgSpec > After invalidating a send to owners transaction, the transaction is invalid FAILED
org.spockframework.runtime.ConditionNotSatisfiedError at SendToOwnersReorgSpec.groovy:21
This is not, because the test actually fails, but due to the rejection on a protocol level, of the inputs, which were selected to create the funding transaction.
The underlying issue is that using coinbase coins for Omni transactions aren't allowed, and somehow they are used for the funding transactions nevertheless.
To solve this issue, the funding logic needs to be refined further.
Given that OmniJ now uses Omni Core 0.0.10 we may think about alternatives though. For example, it may be thinkable to have a "filterunspent"
RPC in Omni Core, to filter a set of unspent outputs, and select only those, which qualify as input for Omni transactions. Such a command might be useful for anyone, who uses Omni Core to create raw Omni Core transactions.
@msgilligan: What do you think?
This involves at least the following tasks:
datadir
as omnicore-stable
and we can't share a blockchain datadir
between 0.0.9 and 0.10.0)We have an Omni Maven repo on Bintray, but we need to add generation and publishing of the proper Maven artifacts to the Gradle build.
To keep track of the progress:
As fix for #7 an intermediate address is funded with (requestedMSC / 100).setScale(8, BigDecimal.ROUND_UP)
from which requestedMSC
is sent to the final destination.
An intermediate address is also used in the case where (requestedMSC / 100).setScale(8, BigDecimal.ROUND_UP) == requestedMSC
, which is not necessary.
Now this is odd behavior that I can't explain:
When running MSCSendToOwnersConsensusComparisonSpec as single test, then everything appear to be fine.*
When running all RegTest tests (parameter: "--tests com.msgilligan.bitcoin.rpc.* --tests foundation.omni.test.rpc.*"), then it fails for one address. This is the case with the master branch, but also with my feature branch. The reason is that "before" is null:
This only happens sometimes and I haven't yet found a way to reproduce this issue at a 100 % rate.
*Because I'm not sure, how to reproduce this, there might not be a relation to whether I run the test individually or in a batch.
Edit: I took a look at a previous test report and in both cases it involves an address with reserved amount.
It's time to factor out core Omni Protocol classes to the OmniJ project.
We are currently doing some refactoring to prepare for this. We can use this issue for tracking the remaining work.
The RivetzSDK allows signing of Bitcoin transactions with a private key storedโฆ
โฆ in the Trusted Execution Environment (TEE) available in many modern devices. The TEE is a hardware environment that runs small applets outside the main OS. This protects sensitive code and data from malware or snooping with purpose-built hardware governed by an ecosystem of endorsements, beginning with the device manufacturer.
Currently, the method OmniTxBuilder.createSignedOmniTransaction()
requires local ECKey
objects with private keys and the method OmniTxBuilder.createOmniTransaction()
creates unsigned, incomplete transactions (no change output.) To support Rivetz we'll need some form of pluggable signing.
While I wanted to create a test of the STO invalidation for Bitcoin, I noticed this is difficult, because the range of CurrencyID starts with 1.
I'm going to change this to 0, because there are also other places where it would be of value, if the CurrencyID class could be used.
Another idea I had in mind was to create a subclass of CurrencyID, solely for Bitcoin.
Are there alternatives?
I'm wondering, how we should handle tests in the future, given that transaction creation for all transaction types is going to be available soon in Omni Core.
Currently, for example for the DEx spec, raw transactions are created and pushed via "sendrawtx_MP"
, which bypasses all checks. In contrast, the new "sendXXX"
RPC calls of Omni Core check certain requirements, e.g. whether the caller has a sufficient balance, or if a property indeed exists.
Now we probably want to test both cases:
With that in mind, I created the STO tests to run two times, once using the RPC call "sendtoowners_MP", and a second time by using "sendrawtx_MP".
The STO testing is very specific though, and I'm wondering, if there should be a more generalized solution in the future, and how this could look like.
Currently the Spock consensus tests use BitcoinClient.waitForServer()
and BitcoinClient.waitForBlock()
to make sure the Omni Core server being tested (usually on localhost) is warmed-up and in sync with the MainNet blockchain before the tests begin. The consensus test Specs contain an explicit comparison test of the blockheight between the local server (leftHeight
) and the remote (rightHeight
) which will fail if the remote server is on a different block. No attempt is made at synchronizing the local and remote servers and there are frequent failures of this blockheight comparison as well as false positives on Omni account balance comparison due to blockheight differences.
Because the Jenkins tests are typically started by commits to the omnicore or OmniJ repositories and the consensus tests run against multiple remote servers, some of which are occasionally many blocks behind the MainNet current height, I have not considered it practical to try to sync the block heights between the different servers -- at least in the context of a Jenkins job -- or even in the case of a developer running the Spock consensus tests (via command-line or IDE).
I have given serious thought to writing a continuously-running consensus-validating server that could cache consensus data from multiple Omni server implementations and do comparisons with matching blockheights whenever each server reaches a new block. This consensus-validating server is not something that is in my near term plans, however.
I created this issue to address @dexX7's request for this capability in a comment on Issue #74 and to give us a place to discuss possible solutions including the idea of a consensus-validating server.
Here's one way to test STO to hundreds or thousands of owners:
N existing owners each hold an integer number of divisible tokens and will receive .00000001 times the number of tokens they hold, so it will be easy to confirm they received the correct amount from the STO. The decimal portion of their balance after the STO will equal the integer portion, e.g. an address holding 1234.0 tokens before will now hold 1234.00001234 tokens after the STO.
Commit c9cc26b introduced some code that appears to be causing GroovyDoc to fail for this class. We need to workaround this problem somehow so that BitcoinClient
can have API docs generated -- and so the Jenkins publish JavaDocs step will succeed.
I think it's time to do this, given that we probably want to do some other refactoring as well.
The previous plan (Issue #49) was to export some of the code from this repo and import it in to the OmniJ
repo, but it now seems like a better idea to move the whole repo -- mostly to preserve the issues DB which is focused around Omni protocol testing and OmniJ implementation.
At a later point we can extract some of the code back to a bitcoin-spock
repo, or perhaps submit some of the Bitcoin-oriented code, eg. bitcoin-rpc
module to the http://github.com/bitcoinj/bitcoinj project.
It would be nice to have access to the Gradle-generated Spock HTML reports that are generated on the CI server. There must be a Jenkins plugin to do this -- either a generic HTML publishing plugin or one specific to Gradle.
See bitcoinj 0.12.1 release notes
Note: There is actually a 0.12.2 release that's not mentioned on the website or in the release notes!
The main reason is to just keep up with bug fixes from bitcoinj, but it will also give us a chance to experiment with the new Coin
class and figure out how that relates to potential Omni "amount" classes and or the new JavaMoney API.
See new row 15 in Send-To-Owners Tests
It tests the condition where an address tries to send too many MSC so that the address does not have enough available MSC remaining to pay the transfer fee for all the MSC owners that would receive a portion of the STO amount.
This should be an invalid transaction.
Without having studied the code or its behavior too closely, it seems that many more transactions and blocks are created than would be optimal to fund a given test. As a result the integration (functional) tests take too long to run.
One thing that might be helpful in optimizing this if there were a component that could keep totals and some basic statistics on these setup transactions.
In particular I was thinking about:
foundation.omni.test.exodus.ExodusFundraiserSpec
(duplicate of MoneyManSpec
?)foundation.omni.test.exodus.FaizSpec
I'm not sure about:
com.msgilligan.bitcoin.rpc.RegTestSendManySpec
(uses account system, ignored)foundation.omni.test.rpc.sto.SendToOwnersConsensusComparisonSpec
(ignored)To keep track of the progress:
We need to test two things: creating a transaction via the RPC interface with sendtoowners_MP
and creating transactions as raw transactions to get around sanity checks on the RPC layer.
Configured via default project structure I use "Oracle JDK 8" as project SDK and "8 - Lambdas, type annotations, etc." as default project language level. JAVA_HOME
is also properly defined.
When cloning bitcoin-spock and creating a new project with "Check out from Version Control", and opening /bitcoin-spock/build.gradle
as suggested, and using the default gradle wrapper, then the project language level switches to "6 - Override in interfaces".
As result an error is generated:
~/Projects/Java/bitcoin-spock/omnij-core/src/main/java/foundation/omni/CurrencyID.java
Error:Error:line (28)java: strings in switch are not supported in -source 1.6
(use -source 7 or higher to enable strings in switch)
After resolving this by selecting a higher language level, and making the project, a bunch of errors is shown, related to the inability to resolve some classes:
~/Projects/Java/bitcoin-spock/omnij-rpc/src/main/groovy/foundation/omni/consensus/ConsensusEntryPair.groovy
Error:Error:Groovyc: @Immutable processor doesn't know how to handle field 'address' of type 'org.bitcoinj.core.Address' while compiling class foundation.omni.consensus.ConsensusEntryPair.
@Immutable classes only support properties with effectively immutable types including:
- Strings, primitive types, wrapper types, Class, BigInteger and BigDecimal, enums
- other @Immutable classes and known immutables (java.awt.Color, java.net.URI)
- Cloneable classes, collections, maps and arrays, and other classes with special handling (java.util.Date)
Other restrictions apply, please see the groovydoc for @Immutable for further details
~/Projects/Java/bitcoin-spock/omnij-rpc/src/integ/groovy/foundation/omni/test/consensus/chest/tmsc/CompareCoreChestSpec.groovy
Error:Error:line (3)Groovyc: unable to resolve class foundation.omni.consensus.ChestConsensusTool
~/Projects/Java/bitcoin-spock/omnij-rpc/src/integ/groovy/foundation/omni/test/consensus/chest/tetherus/CompareCoreChestSpec.groovy
Error:Error:line (3)Groovyc: unable to resolve class foundation.omni.consensus.ChestConsensusTool
~/Projects/Java/bitcoin-spock/omnij-rpc/src/integ/groovy/foundation/omni/BaseRegTestSpec.groovy
Error:Error:line (5)Groovyc: unable to resolve class foundation.omni.rpc.OmniCLIClient
Error:Error:line (6)Groovyc: unable to resolve class foundation.omni.rpc.OmniClientDelegate
Error:Error:line (8)Groovyc: unable to resolve class foundation.omni.test.TestSupport
~/Projects/Java/bitcoin-spock/omnij-rpc/src/integ/groovy/foundation/omni/test/consensus/chest/msc/CompareCoreChestSpec.groovy
Error:Error:line (3)Groovyc: unable to resolve class foundation.omni.consensus.ChestConsensusTool
~/Projects/Java/bitcoin-spock/omnij-rpc/src/integ/groovy/foundation/omni/test/rpc/sto/SendToOwnersSpec.groovy
Error:Error:line (7)Groovyc: unable to resolve class foundation.omni.consensus.OmniCoreConsensusTool
Error:Error:line (6)Groovyc: unable to resolve class foundation.omni.consensus.ConsensusTool
~/Projects/Java/bitcoin-spock/omnij-rpc/src/integ/groovy/foundation/omni/test/consensus/omni_www/tetherus/CompareCoreOmniSpec.groovy
Error:Error:line (3)Groovyc: unable to resolve class foundation.omni.consensus.OmniwalletConsensusTool
~/Projects/Java/bitcoin-spock/omnij-rpc/src/integ/groovy/foundation/omni/test/enginedb/OmniEngineDBSmokeSpec.groovy
Error:Error:line (3)Groovyc: unable to resolve class foundation.omni.consensus.DBConsensusTool
~/Projects/Java/bitcoin-spock/omnij-rpc/src/integ/groovy/foundation/omni/test/consensus/remote_core/msc/CompareCoreCoreSpec.groovy
Error:Error:line (3)Groovyc: unable to resolve class foundation.omni.consensus.OmniCoreConsensusTool
~/Projects/Java/bitcoin-spock/omnij-rpc/src/integ/groovy/foundation/omni/test/consensus/remote_core/tetherus/CompareCoreCoreSpec.groovy
Error:Error:line (3)Groovyc: unable to resolve class foundation.omni.consensus.OmniCoreConsensusTool
~/Projects/Java/bitcoin-spock/omnij-rpc/src/integ/groovy/foundation/omni/BaseMainNetSpec.groovy
Error:Error:line (7)Groovyc: unable to resolve class foundation.omni.rpc.OmniCLIClient
Error:Error:line (8)Groovyc: unable to resolve class foundation.omni.rpc.OmniClientDelegate
~/Projects/Java/bitcoin-spock/omnij-rpc/src/integ/groovy/foundation/omni/test/consensus/chest/maidsafecoin/CompareCoreChestSpec.groovy
Error:Error:line (3)Groovyc: unable to resolve class foundation.omni.consensus.ChestConsensusTool
~/Projects/Java/bitcoin-spock/omnij-rpc/src/integ/groovy/foundation/omni/test/consensus/ChestServerSpec.groovy
Error:Error:line (5)Groovyc: unable to resolve class foundation.omni.consensus.OmniwalletConsensusTool
Error:Error:line (4)Groovyc: unable to resolve class foundation.omni.consensus.ChestConsensusTool
~/Projects/Java/bitcoin-spock/omnij-rpc/src/integ/groovy/foundation/omni/test/consensus/omni_www/tmsc/CompareCoreOmniSpec.groovy
Error:Error:line (3)Groovyc: unable to resolve class foundation.omni.consensus.OmniwalletConsensusTool
~/Projects/Java/bitcoin-spock/omnij-rpc/src/integ/groovy/foundation/omni/test/consensus/OmniwalletServerSpec.groovy
Error:Error:line (5)Groovyc: unable to resolve class foundation.omni.consensus.OmniwalletConsensusTool
~/Projects/Java/bitcoin-spock/omnij-rpc/src/integ/groovy/foundation/omni/test/consensus/remote_core/tmsc/CompareCoreCoreSpec.groovy
Error:Error:line (3)Groovyc: unable to resolve class foundation.omni.consensus.OmniCoreConsensusTool
~/Projects/Java/bitcoin-spock/omnij-rpc/src/integ/groovy/foundation/omni/test/test/OmniClientDelegateSpec.groovy
Error:Error:line (5)Groovyc: unable to resolve class foundation.omni.rpc.OmniClientDelegate
~/Projects/Java/bitcoin-spock/omnij-rpc/src/integ/groovy/foundation/omni/test/consensus/OmniCoreConsensusToolSpec.groovy
Error:Error:line (3)Groovyc: unable to resolve class foundation.omni.consensus.OmniCoreConsensusTool
~/Projects/Java/bitcoin-spock/omnij-rpc/src/integ/groovy/foundation/omni/test/consensus/omni_www/maidsafecoin/CompareCoreOmniSpec.groovy
Error:Error:line (3)Groovyc: unable to resolve class foundation.omni.consensus.OmniwalletConsensusTool
~/Projects/Java/bitcoin-spock/omnij-rpc/src/integ/groovy/foundation/omni/test/consensus/remote_core/maidsafecoin/CompareCoreCoreSpec.groovy
Error:Error:line (3)Groovyc: unable to resolve class foundation.omni.consensus.OmniCoreConsensusTool
~/Projects/Java/bitcoin-spock/omnij-rpc/src/integ/groovy/foundation/omni/test/consensus/BaseConsensusSpec.groovy
Error:Error:line (7)Groovyc: unable to resolve class foundation.omni.consensus.OmniCoreConsensusTool
Error:Error:line (6)Groovyc: unable to resolve class foundation.omni.consensus.ConsensusFetcher
Error:Error:line (5)Groovyc: unable to resolve class foundation.omni.consensus.ConsensusComparison
~/Projects/Java/bitcoin-spock/omnij-rpc/src/integ/groovy/foundation/omni/test/consensus/RPCSmokeTestSpec.groovy
Error:Error:line (4)Groovyc: unable to resolve class foundation.omni.consensus.OmniCoreConsensusTool
~/Projects/Java/bitcoin-spock/omnij-rpc/src/integ/groovy/foundation/omni/test/consensus/omni_www/msc/CompareCoreOmniSpec.groovy
Error:Error:line (3)Groovyc: unable to resolve class foundation.omni.consensus.OmniwalletConsensusTool
~/Projects/Java/bitcoin-spock/omnij-rpc/src/test/groovy/foundation/omni/consensus/SnapshotData.groovy
Error:Error:line (19)Groovyc: unable to resolve class ConsensusEntry
Error:Error:line (20)Groovyc: unable to resolve class ConsensusEntry
Error:Error:line (23)Groovyc: unable to resolve class ConsensusEntry
Error:Error:line (20)Groovyc: unable to resolve class ConsensusEntry
Error:Error:line (21)Groovyc: unable to resolve class ConsensusEntry
Error:Error:line (22)Groovyc: unable to resolve class ConsensusEntry
Error:Error:line (23)Groovyc: unable to resolve class ConsensusEntry
Error:Error:line (24)Groovyc: unable to resolve class ConsensusEntry
Error:Error:line (26)Groovyc: unable to resolve class ConsensusSnapshot
Error:Error:line (30)Groovyc: unable to resolve class ConsensusSnapshot
Error:Error:line (34)Groovyc: unable to resolve class ConsensusSnapshot
Error:Error:line (38)Groovyc: unable to resolve class ConsensusEntry
Error:Error:line (38)Groovyc: unable to resolve class ConsensusSnapshot
Error:Error:line (39)Groovyc: unable to resolve class ConsensusSnapshot
~/Projects/Java/bitcoin-spock/omnij-rpc/src/test/groovy/foundation/omni/consensus/ConsensusEntryPairSpec.groovy
Error:Error:line (17)Groovyc: unable to resolve class ConsensusEntryPair
Error:Error:line (17)Groovyc: unable to resolve class ConsensusEntry
Error:Error:line (17)Groovyc: unable to resolve class ConsensusEntry
Error:Error:line (20)Groovyc: unable to resolve class ConsensusEntry
Error:Error:line (28)Groovyc: unable to resolve class ConsensusEntryPair
Error:Error:line (28)Groovyc: unable to resolve class ConsensusEntry
Error:Error:line (28)Groovyc: unable to resolve class ConsensusEntry
Error:Error:line (39)Groovyc: unable to resolve class ConsensusEntry
Error:Error:line (40)Groovyc: unable to resolve class ConsensusEntry
~/Projects/Java/bitcoin-spock/omnij-rpc/src/test/groovy/foundation/omni/consensus/ConsensusSnapshotSpec.groovy
Error:Error:line (13)Groovyc: unable to resolve class ConsensusSnapshot
Error:Error:line (25)Groovyc: unable to resolve class ConsensusSnapshot
~/Projects/Java/bitcoin-spock/omnij-rpc/src/test/groovy/foundation/omni/consensus/DataPipeSpec.groovy
Error:Error:line (11)Groovyc: unable to resolve class ConsensusComparison
Error:Error:line (12)Groovyc: unable to resolve class ConsensusComparison
Error:Error:line (11)Groovyc: unable to resolve class ConsensusComparison
Error:Error:line (12)Groovyc: unable to resolve class ConsensusComparison
~/Projects/Java/bitcoin-spock/omnij-rpc/src/test/groovy/foundation/omni/consensus/ConsensusComparisonSpec.groovy
Error:Error:line (9)Groovyc: unable to resolve class ConsensusComparison
Error:Error:line (9)Groovyc: unable to resolve class ConsensusComparison
Most tests we currently have focus on correct behavior and logic, but only a fraction of the information of the API is actually used.
I'm not sure, how to tackle this, but it would be great, if all fields of the results for each command are checked somewhere, similar to the ListPropertiesSpec.
Step 1) actorA is funded with 1.0 BTC via createFundedAddress()
Step 2) actorB is funded with 1.0 BTC via createFundedAddress()
In the worst the coins of A are used to "sendToAddress" of B.
How the coin selection choses the coins to send is pretty much out of scope, and I don't see a straight forward guard against this behavior.
There is the RPC call "lockunspent" which could be used to "freeze" balances during funding and transfer periods..
The current Java clients for Bitcoin and Omni are very close in name and behavior to the direct RPCs, but their names are camel-case and because Java methods can't have optional parameters there are overloaded methods with fewer parameters.
OmniCLIClient.goovy
is a starting point for this work. There is a placeholder class BitcoinCLIClient.groovy
as well. The idea is to use Groovy's optional arguments capability to more closely resemble the RPC methods themselves.
One of the reasons for this implementation would be writing functional tests that are very readable by people familiar with the RPCs from Bitcoin and/or Omni documentation or from using the CLI command-line tools.
Here's a way to test STO with owner(s) who have MSC that are reserved, e.g. because they have a tx20 sale (Dex phase 1) that's active.
Assign the same number of MSC, e.g. 100.0, to 3 addresses. Then:
The actor address acquires a number of MSC, e.g. 100.0 or more. Then the actor address submits an STO for all but 1.0 of his MSC. This will leave enough MSC available for the transfer fee for 100,000,000 recipient owners.
After the STO, check the balances of the 3 addresses. The (available balance + reserved balance) for all three should be exactly equal, with the available balance for each of them increased by the same amount.
Sooner or later we won't get around it, I believe, and have to handle node statup internally.
This became very clear when I tested @zathras-crypto's UI branch with two seperated QT clients, resulting in two manual starts and a lot of switching between manual commands and spock tests.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.