HashEngineering - Android Wallet Creation Service

[rik8119]

The log has nothing to do with the tests, it is something that most apps generate and provides useful information.  It will definitely help with debugging.

Hi hashengineering i have the log-file now from the crash (it is loading now to block 10k), can you see somthing that helps debugging?
(I added extra heap memory by "android:largeHeap="true" - then it is not crashing anymore but no further blocks are loaded)

Code:

22:38:35.327 [Wallet autosave thread] WalletFiles - Background saving wallet, last seen block is 10000/000000000476f76304230b34d074a20822f2250f5c04c4424749a62831837aca
22:38:35.613 [Wallet autosave thread] WalletFiles - Save completed in 283msec
22:38:45.798 [NioClientManager] PeerGroup - [109.73.173.119]:55889: Peer died
22:38:45.844 [NioClientManager] PeerGroup - [91.108.68.164]:55889: Peer died
22:38:45.846 [NioClientManager] PeerGroup - Download peer died. Picking a new one.
22:38:45.848 [NioClientManager] PeerGroup - Unsetting download peer: [91.108.68.164]:55889
22:38:45.855 [NioClientManager] PeerGroup - Setting download peer: [185.38.44.6]:55889
22:38:45.885 [NioClientManager] PeerGroup - [185.38.44.6]:55889: Peer died
22:38:45.887 [NioClientManager] PeerGroup - Download peer died. Picking a new one.
22:38:45.888 [NioClientManager] PeerGroup - Unsetting download peer: [185.38.44.6]:55889
22:38:45.932 [NioClientManager] CrashReporter - crashing because of uncaught exception
java.lang.OutOfMemoryError: null
	at java.lang.String.<init>(String.java:432) ~[na:0.0]
	at java.lang.AbstractStringBuilder.toString(AbstractStringBuilder.java:642) ~[na:0.0]
	at java.lang.StringBuilder.toString(StringBuilder.java:663) ~[na:0.0]
	at ch.qos.logback.classic.pattern.ThrowableProxyConverter.throwableProxyToString(Unknown Source) ~[na:0.0]
	at ch.qos.logback.classic.pattern.ThrowableProxyConverter.convert(Unknown Source) ~[na:0.0]
	at ch.qos.logback.classic.pattern.ThrowableProxyConverter.convert(Unknown Source) ~[na:0.0]
	at ch.qos.logback.core.pattern.FormattingConverter.write(Unknown Source) ~[na:0.0]
	at ch.qos.logback.core.pattern.PatternLayoutBase.writeLoopOnConverters(Unknown Source) ~[na:0.0]
	at ch.qos.logback.classic.PatternLayout.doLayout(Unknown Source) ~[na:0.0]
	at ch.qos.logback.classic.PatternLayout.doLayout(Unknown Source) ~[na:0.0]
	at ch.qos.logback.core.encoder.LayoutWrappingEncoder.doEncode(Unknown Source) ~[na:0.0]
	at ch.qos.logback.core.OutputStreamAppender.writeOut(Unknown Source) ~[na:0.0]
	at ch.qos.logback.core.FileAppender.writeOut(Unknown Source) ~[na:0.0]
	at ch.qos.logback.core.OutputStreamAppender.subAppend(Unknown Source) ~[na:0.0]
	at ch.qos.logback.core.FileAppender.subAppend(Unknown Source) ~[na:0.0]
	at ch.qos.logback.core.rolling.RollingFileAppender.subAppend(Unknown Source) ~[na:0.0]
	at ch.qos.logback.core.OutputStreamAppender.append(Unknown Source) ~[na:0.0]
	at ch.qos.logback.core.UnsynchronizedAppenderBase.doAppend(Unknown Source) ~[na:0.0]
	at ch.qos.logback.core.spi.AppenderAttachableImpl.appendLoopOnAppenders(Unknown Source) ~[na:0.0]
	at ch.qos.logback.classic.Logger.appendLoopOnAppenders(Unknown Source) ~[na:0.0]
	at ch.qos.logback.classic.Logger.callAppenders(Unknown Source) ~[na:0.0]
	at ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Unknown Source) ~[na:0.0]
	at ch.qos.logback.classic.Logger.filterAndLog_0_Or3Plus(Unknown Source) ~[na:0.0]
	at ch.qos.logback.classic.Logger.warn(Unknown Source) ~[na:0.0]
	at org.bitcoinj.core.PeerSocketHandler.exceptionCaught(PeerSocketHandler.java:227) ~[na:0.0]
	at org.bitcoinj.core.PeerSocketHandler.receiveBytes(PeerSocketHandler.java:181) ~[na:0.0]
	at org.bitcoinj.net.ConnectionHandler.handleKey(ConnectionHandler.java:217) ~[na:0.0]
	at org.bitcoinj.net.NioClientManager.handleKey(NioClientManager.java:75) ~[na:0.0]
	at org.bitcoinj.net.NioClientManager.run(NioClientManager.java:111) ~[na:0.0]
	at com.google.common.util.concurrent.AbstractExecutionThreadService$1$2.run(AbstractExecutionThreadService.java:60) ~[na:0.0]
	at com.google.common.util.concurrent.Callables$3.run(Callables.java:93) ~[na:0.0]
	at java.lang.Thread.run(Thread.java:856) ~[na:0.0]
22:38:45.934 [PeerGroup] DnsDiscovery - DNS seed seed.winc-ev.de: got 4 peers
22:38:45.953 [PeerGroup] DnsDiscovery - DNS seed seed.winc-ev.com: failed to look up: java.net.UnknownHostException: Unable to resolve host "seed.winc-ev.com": No address associated with hostname
22:38:45.953 [PeerGroup] DnsDiscovery - DNS seed dnsseed.wlc-dnsseed.ssdpool.com: got 3 peers
22:38:45.957 [PeerGroup] PeerGroup - Waiting 848 msec before next connect attempt to [109.73.173.119]:55889
22:38:46.810 [PeerGroup] PeerGroup - Failed to connect to [109.73.173.119]:55889: null

[jk_14]

The bytes should be reversed, but since you are replacing the code in scryptDigest, then the bytes should be reversed in the code of Block.calculateScryptHash.

I have had this problem before when the hash was calculated incorrectly.  What I did was compare the java code, line by line, while debugging with the C++ code to see which part of the hash code was generating an incorrect hash.  In that case I found that one of the part of the hash functions was giving the wrong result.  I am not sure why in your case the hash is incorrect.

Hi,

You are probably right, that native mode is the way to go, due to severe problems with uint64_t in Java.
Could you prepare some simple Android Studio project, and include LYRA2 function from:
https://github.com/vertcoin/vertcoin/blob/master/src/Lyra2RE/Lyra2.c
as a native code, with NDK? (of course, as a paid service)

Then, I could just copy such solution in the wallet, I hope.

[jk_14]

You are probably right, that native mode is the way to go, due to severe problems with uint64_t in Java.
Could you prepare some simple Android Studio project, and include LYRA2 function from:
https://github.com/vertcoin/vertcoin/blob/master/src/Lyra2RE/Lyra2.c
as a native code, with NDK? (of course, as a paid service)

Then, I could just copy such solution in the wallet, I hope.

Lyra2 in Java is working, and wallet is working already.
so I will try to produce a 'checkpoints' file - in hex editor, then... 

[HashEngineering]

The bytes should be reversed, but since you are replacing the code in scryptDigest, then the bytes should be reversed in the code of Block.calculateScryptHash.

I have had this problem before when the hash was calculated incorrectly.  What I did was compare the java code, line by line, while debugging with the C++ code to see which part of the hash code was generating an incorrect hash.  In that case I found that one of the part of the hash functions was giving the wrong result.  I am not sure why in your case the hash is incorrect.

Hi,

You are probably right, that native mode is the way to go, due to severe problems with uint64_t in Java.
Could you prepare some simple Android Studio project, and include LYRA2 function from:
https://github.com/vertcoin/vertcoin/blob/master/src/Lyra2RE/Lyra2.c
as a native code, with NDK? (of course, as a paid service)

Then, I could just copy such solution in the wallet, I hope.

I maybe able to help you create native libraries, for instance, they would go here in the digitalcoin app that I made:
https://github.com/HashEngineering/digitalcoin-wallet/tree/prod/wallet/libs

and the code for these libraries are here:
https://github.com/HashEngineering/digitalcoinj/tree/master/jni

and the Android NDK must be installed to build the native libraries for as many as 7 platforms:
https://developer.android.com/tools/sdk/ndk/index.html

[jk_14]

I maybe able to help you create native libraries, for instance, they would go here in the digitalcoin app that I made:
https://github.com/HashEngineering/digitalcoin-wallet/tree/prod/wallet/libs

and the code for these libraries are here:
https://github.com/HashEngineering/digitalcoinj/tree/master/jni

and the Android NDK must be installed to build the native libraries for as many as 7 platforms:
https://developer.android.com/tools/sdk/ndk/index.html

Thank you, now I'm happy enough with Java version:
https://www.reddit.com/r/vertcoin/comments/3h7146/android_wallet_refreshed_test_release/

but it's possible I will expand it to JNI some day (what is performance increase from JNI in case of X11 algo ?)


and the last issue:
what changes are necessary to handle auxpow in Android wallet (for merge-mined coin with Vertcoin, no special differences besides auxpow).
Maybe you have some nice example here, too?

[HashEngineering]

Performance increases could be 10 or 20 times faster with a native library.

For auxpow, my example is in namecoin:
https://github.com/HashEngineering/namecoinj

[rik8119]

Performance increases could be 10 or 20 times faster with a native library.

For auxpow, my example is in namecoin:
https://github.com/HashEngineering/namecoinj

Hi hashengineerng,

i used your namecoinj as template and now its downloading blocks.

However the last block is always connected as orphan and then it crashes due to a failed difficulty check.

Doing some debugging although the block is merged mined the program finds no merge mining info (mmBlock == null)
and then it takes the childchainhash which is higher than target.

It only happens with the latest block, do you had this problem or an idea what went wrong?

Rik

EDIT: We have a solution thanks again (The orphan blocks are missing the merged mining informations. I dont know why but the namecoinwallet always thinks the latest block is an orphan. It then iscard the mmm info and the diff. check fails- so we included the memi infos in orphan blocks).

[Crestington]

Hi HashEngineering!

I was wondering what options you have for android POS?

I am thinking I would want something similar to Bitcoin wallet which takes a smaller amount of space and doesn't hold the entire chain, nor does it need to Stake. What I am envisioning is where you have your own server/wallet Staking but the android wallet does not stake but can pick up those transactions for usable balance. Is this possible?

What options would I have for creating an android wallet for PayCon? https://bitcointalk.org/index.php?topic=937480.0

What do you charge for fees of services?

[HashEngineering]

Hi HashEngineering!

I was wondering what options you have for android POS?

I don't do POS wallets.  One idea is too look at the Blackcoin Wallet, which is for android.  Not sure if it is still supported.

[Crestington]

Hi HashEngineering!

I was wondering what options you have for android POS?

I don't do POS wallets.  One idea is too look at the Blackcoin Wallet, which is for android.  Not sure if it is still supported.

Have you looked at Coinami?

[HashEngineering]

Hi HashEngineering!

I was wondering what options you have for android POS?

I don't do POS wallets.  One idea is too look at the Blackcoin Wallet, which is for android.  Not sure if it is still supported.

Have you looked at Coinami?

Yes, I forgot that I have actually forked that wallet for a different coin.  However, that one requires electrum servers.

[Crestington]

Hi HashEngineering!

I was wondering what options you have for android POS?

I don't do POS wallets.  One idea is too look at the Blackcoin Wallet, which is for android.  Not sure if it is still supported.

Have you looked at Coinami?

Yes, I forgot that I have actually forked that wallet for a different coin.  However, that one requires electrum servers.

Would you be able to help me set it up?

Can pay in BTC.

[Crestington]

Hi HashEngineering!

I was wondering what options you have for android POS?

I don't do POS wallets.  One idea is too look at the Blackcoin Wallet, which is for android.  Not sure if it is still supported.

Have you looked at Coinami?

Yes, I forgot that I have actually forked that wallet for a different coin.  However, that one requires electrum servers.

So what Coin did you fork it for? I notice that electrum uses txindex=1 but not all Coins support that function (PayCon doesn't) so then would that need to be added to be able to use electrum servers? or is there a workaround?

[HashEngineering]

So what Coin did you fork it for? I notice that electrum uses txindex=1 but not all Coins support that function (PayCon doesn't) so then would that need to be added to be able to use electrum servers? or is there a workaround?

The coin was Groestlcoin and the developers had a different project that got the electrum servers running.  I don't know anything about how to set up an electrum server or its requirements from the client.

[rik8119]

Hi everybody,

do someone know how the number of the blocks in the cache can be reduced easily? 2000 is too much for my coin because the Coinbase transactions of the parent chain are too many using up too much memory on older phones i already reduced the "DEFAULT_NUM_HEADERS" in SPVBlockStore but it still loads 2k Blocks in he heap space crashing older devices..

[HashEngineering]

Hi everybody,

do someone know how the number of the blocks in the cache can be reduced easily? 2000 is too much for my coin because the Coinbase transactions of the parent chain are too many using up too much memory on older phones i already reduced the "DEFAULT_NUM_HEADERS" in SPVBlockStore but it still loads 2k Blocks in he heap space crashing older devices..

This is a good question.  The client has this in its code when another client requests headers (main.cpp, ProcessMessage):

Code:

else if (strCommand == "getheaders")
    {
        CBlockLocator locator;
        uint256 hashStop;
        vRecv >> locator >> hashStop;

Code:

        vector<CBlock> vHeaders;
        int nLimit = 2000;
        printf("getheaders %d to %s\n", (pindex ? pindex->nHeight : -1), hashStop.ToString().c_str());
        for (; pindex; pindex = pindex->pnext)
        {
            vHeaders.push_back(pindex->GetBlockHeader());
            if (--nLimit <= 0 || pindex->GetBlockHash() == hashStop)
                break;
        }
        pfrom->PushMessage("headers", vHeaders);

Based on this there is no way to ask another node for a specific amount of headers, it defaults to 2000.

[rik8119]

Hi everybody,

do someone know how the number of the blocks in the cache can be reduced easily? 2000 is too much for my coin because the Coinbase transactions of the parent chain are too many using up too much memory on older phones i already reduced the "DEFAULT_NUM_HEADERS" in SPVBlockStore but it still loads 2k Blocks in he heap space crashing older devices..

This is a good question.  The client has this in its code when another client requests headers (main.cpp, ProcessMessage):

Code:

else if (strCommand == "getheaders")
    {
        CBlockLocator locator;
        uint256 hashStop;
        vRecv >> locator >> hashStop;

Code:

        vector<CBlock> vHeaders;
        int nLimit = 2000;
        printf("getheaders %d to %s\n", (pindex ? pindex->nHeight : -1), hashStop.ToString().c_str());
        for (; pindex; pindex = pindex->pnext)
        {
            vHeaders.push_back(pindex->GetBlockHeader());
            if (--nLimit <= 0 || pindex->GetBlockHash() == hashStop)
                break;
        }
        pfrom->PushMessage("headers", vHeaders);

Based on this there is no way to ask another node for a specific amount of headers, it defaults to 2000.

I was afraid that this is answer but it helps a lot, thanks.

[HashEngineering]

Hi hash engineering 

I was wondering if there going to be a update to earthcoin and myriadcoin wallets?
I having problems with syncing them that i know of myriadcoin has had a fork as late.
If i get a trusted peer would that fix it 

Trusted peer settings will work, if your problem is having No valid peers.

I am not the dev of the earthcoin Wallet, though my email is in the app for crash reports.

I plan to get the myriad app ready soon.

[Digitalcoin Foundation]

Fantastic work on the Digitalcoin Android wallet!

Now that there are some permanent full nodes in place, maybe it's time to add those nodes and release the latest version?

Thanks for your work HashEngineering!

[densuj]

Dash coin on my phone it is great  thank you