No peer response

[theveloped]

No peer response

[stefanhuber]

I have followed the steps you proposed, additionally I also added the two socket plugins via:

• cordova plugin add https://github.com/MobileChromeApps/cordova-plugin-chrome-apps-sockets-tcp.git
• cordova plugin add https://github.com/MobileChromeApps/cordova-plugin-chrome-apps-sockets-tcpServer.git

I also added the code snippet with an IP from the DNS list you proposed. After deploying the app to a device (Samsung Galaxy S3) with ionic run -c -s -l I got the following errors in the command line:

0 324289 log Error in Success callbackId: ChromeSocketsTcp1188801479 : TypeError: Cannot read property 'lastError' of undefined
1 324363 error Uncaught TypeError: Cannot read property 'lastError' of undefined, http://192.168.0.101:8100/cordova.js, Line: 312

Do you know if any permissions are needed for using the sockets, within an android app? Next I will try an android version > 5 on an emulator, I hope there I can get more insight from the error log...

[theveloped]

Hi @stefanhuber,

This should be solved in the commit I just made. This was caused by the chrome-net module that was used that uses chrome.runtime for some of it's error handling. chrome.runtime is however not available on cordova.

I've forked the module to cordova-chrome-net that removes this dependency for chrome.runtime. Using this should remove the error you see. As far as I know no permissions are needed to use the sockets.

Notice however cordova-bitcore is still fully under development. I can only test for iOS at the moment and have not yet gotten everything to work. A set of extra eyes for the android part would be much appreciated.

[stefanhuber]

ok, that worked so far!

i can only confirm that the 'connect' event is triggered, and the socket as such is connected. Actually, also the version is sent, however there is never a response coming back. This seems like as if the message is not correctly encoded or something...

An option would be to create a version message with node and one on cordova and compare the two, this should reveal, if there is some difference.

[theveloped]

That are indeed the same conclusions I came to. Comparing both messages seems indeed the best way to go. Als one should compare the two after the .toBuffer() as this might be the source of the problem. Also take into account that the version messages contain a datetime field and should thus be generated using a static date for comparison.

I probably won't have time to further look into this before next week. But of course feel free to have a look yourself and send a pull request or inform me on your findings.

[stefanhuber]

Ok, i have checked the version message on cordova and node, with this snippet in cordova (looks similar in node):

var msgs = new bitcore.P2P.Messages();

var msg = msgs.Version({
  timestamp : new Date(1420066800)
});

$log.info(JSON.stringify(msg.toBuffer().toJSON()));
$log.info(JSON.stringify(msg.getPayload().toJSON()));

The outcome was that:

toBuffer() on Cordova:
{"type":"Buffer","data":[249,190,180,217,118,101,114,115,105,111,110,0,0,0,0,0,101,0,0,0,194,180,148,222,112,17,1,0,1,0,0,0,0,0,0,0,35,171,21,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,149,62,199,88,190,134,204,3,15,47,98,105,116,99,111,114,101,58,49,46,48,46,48,47,0,0,0,0,1]}

toBuffer() on Node:
{"type":"Buffer","data":[249,190,180,217,118,101,114,115,105,111,110,0,0,0,0,0,101,0,0,0,117,167,144,38,112,17,1,0,1,0,0,0,0,0,0,0,35,171,21,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,197,199,74,57,44,83,43,10,15,47,98,105,116,99,111,114,101,58,49,46,48,46,48,47,0,0,0,0,1]}

getPayload() on Cordova:
{"type":"Buffer","data":[112,17,1,0,1,0,0,0,0,0,0,0,35,171,21,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,123,100,113,215,226,217,48,84,15,47,98,105,116,99,111,114,101,58,49,46,48,46,48,47,0,0,0,0,1]}

getPayload() on Node:
{"type":"Buffer","data":[112,17,1,0,1,0,0,0,0,0,0,0,35,171,21,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,202,181,26,229,6,159,245,65,15,47,98,105,116,99,111,114,101,58,49,46,48,46,48,47,0,0,0,0,1]}

Other than the timestamp, the payload contains also a Randomnumber (getNonce()) which alters the two outputs slightly. Appart from that I think this somewhat looks similar. Naively, I would say that the message is generated correctly. Maybe there is some problem at a deeper level, I cannot tell.

[theveloped]

It seems the only discrepancy could indeed be caused by the nonce value. I would suggest to be completely sure the nonce should also be precomputed and handed to the message generation as an option.

If this does not turn out to be the problem than it seems the problem is more low level maybe in the chrome.sockets.tcp plugin.

[stefanhuber]

I tried the naive way and this works, I suppose the best way to go, is to implement the necessary socket interface of net for the Peer oneself, instead of changing chrome-net. This requires browserifying Buffer and Buffers to work on cordova...

chrome.sockets.tcp.create(function(createInfo) {
  chrome.sockets.tcp.connect(createInfo.socketId, 'bitcoin-peer-ip', 8333, function(result) {
    if (result === 0) {
      var inputBuffer = new Buffers();
      var msgs = new bitcore.P2P.Messages();
      var version = msgs.Version();

      chrome.sockets.tcp.send(createInfo.socketId, version.toBuffer().buffer, function(result) {
        if (result.resultCode === 0) {
            $log.info("Version info sent");
        }
      });

      chrome.sockets.tcp.onReceive.addListener(function (info) {
        inputBuffer.push(new Buffer(new Uint8Array(info.data)));
        var message = msgs.parseBuffer(inputBuffer);
        $log.info(message.command);
      });
    }
  });
});

[theveloped]

Good to hear you've had some good results. So the snippet above indeed receives the verack command on sending the version message? If this is indeed true I will have a look in the future as to how much work it would be to port the entire peer api.

[stefanhuber]

Yes, all kind of other messages are also received, like: verack, version, ping, inv, whatever... This seems to be the behaviour of bitcoind. I must admit, I didn't go through chrome-net code in detail. However, in my opinion the additional "layer" of complexity is not really necessary.

Two options come to my mind:

• Changing Peer.js so chrome.sockets are used
• Create a Socket, which only implements the interface used by Peer.js

Obviously, the second option would be better...

[stefanhuber]

has it worked? I have added a gist with all the code: https://gist.github.com/stefanhuber/7f26dec78d9cd4ee566e

[theveloped]

Hi @stefanhuber I indeed got your snippet working finally some progress! Also I found the problem with chrome-net. Updating cordova-chrome-net to version 1.0.3 should solve the problems we had. One should now be able to use at least the peer and pool module.

To let the pool be initiated from seeds we would have to get some form of dns resolve going on cordova. It already works using initial trusted seeds though.

On top of this I think a standard SPV client could be build using AngularJS. Is this the route you are going to take too @stefanhuber?

[stefanhuber]

For the DNS in pool a simple solution would be, to use a http interface to dns.

e.g.

• http://api.statdns.com/seed.bitcoin.sipa.be/a for ip4
• http://api.statdns.com/seed.bitcoin.sipa.be/aaaa for ip6

Considering the cordova-chrome-net I think this is a great project, which would make sense for other people as well (not necessarily bitcoin related). Still, the cordova-chrome-net project implements the full node net interface, which is not all required for the bitcoin p2p purpose. So a simpler approach would be, to only implement the necessary api oneself... Eitherway, this needs some automated tests on cordova deployments, to be reliable enough, in my opinion. Might be done with travis.

For the spv-client there were some new inputs in the bitcore forum.

[stefanhuber]

My proposal would be the following

• create an organization on github cordova-bitcoin
• host all projects we develop together under this organization

Maybe we can have a skype call or similar

[theveloped]

I agree that cordova-chrome-net is a little over featured for the bitcoin p2p network. I would however like to spend most of my time on development of cordova projects using cordova-bitcore as is. Development of a barebones api will therefore has a low priority at least for me. Although I fully agree that would be the more desirable option.

On setting up automated testing. I'm all for it! although I have no experience with this what so ever.

Furthermore I agree it would be nice to collect the project build in one place (cordova-bitcoin). For me however this project has to be cramped in my already sparse free time. I therefore don't know or I can make a lot of contributions. Will send you a pm to setup a Skype meeting on this.