Bitcoin API

Private email with Martti Malmi (sirius-m) · 5 messages · from 3 February 2010 · with Satoshi Nakamoto, mmalmi@cc.hut.fi

Read in Satoshi Mail Archive source

mmalmi@cc.hut.fi to satoshin@gmx.com · 3 February 2010, 09:27 UTC · original

Have you decided upon the inter-process calling method of the Bitcoin API yet? An easy solution would be the socket interface provided by wxWidgets: http://docs.wxwidgets.org/trunk/overview_ipc.html. The Bitcoin program running a wxServer could be then accessed by calling the bitcoin executable from the command line or by coding your own wxClient app. Another option would be to just use the plain BSD sockets. Can you send me a 64-bit Linux binary of Bitcoin if you have one? I tried compiling on the VPS, but it ran out of memory. Tried the 32-bit version (with ia32-libs) also, but it didn't find the shared libraries.

Satoshi Nakamoto to mmalmi@cc.hut.fi · 3 February 2010, 20:25 UTC · original

Is there any way to find out what the missing shared libraries are? It would help to know. It probably needs the gtk libraries, in which case you'll have the same problem with the 64-bit version. I would like to have a single executable that can also run on a UI-less system, but I'm not sure how on linux to link to things but still be able to run and not use them if the library is not present. Maybe we should statically link the GTK. Licensewise, it's LGPL, but since it's only used on unix, that would be OK. (we can't link LGPL stuff on windows because we provide the OpenSSL DLL, but on linux OpenSSL comes with the OS) My 64-bit (debug stripped) executable is attached. It includes untested changes that are not in SVN yet: UI changes and the wallet fSpent flag resync stuff. I've been researching options for interprocess calling. I want something that will be easy for a variety of server side languages to call, particularly PHP. Cross-platform to windows is a plus. I'm not sure if I want it to be something that can be accessed across the network. That would introduce security issues. If it can only be accessed on the local system, then local security authentication covers it, and it is incapable of being hacked remotely. At surface level, not looking into any details yet, the current front runners are: D-Bus: local system only used by qt, gnome and skype bindings: c, python, java, c++, php listed as "in progress" .net listed as unmaintained not sure how ready it is on windows XML-RPC: widely used, built in libraries on PHP it's more for web clients to talk to server, transport is http, so its a security question Is it possible to open a socket that can only be accessed locally?

mmalmi@cc.hut.fi wrote:
Have you decided upon the inter-process calling method of the Bitcoin API yet? An easy solution would be the socket interface provided by wxWidgets: http://docs.wxwidgets.org/trunk/overview_ipc.html. The Bitcoin program running a wxServer could be then accessed by calling the bitcoin executable from the command line or by coding your own wxClient app. Another option would be to just use the plain BSD sockets. Can you send me a 64-bit Linux binary of Bitcoin if you have one? I tried compiling on the VPS, but it ran out of memory. Tried the 32-bit version (with ia32-libs) also, but it didn't find the shared libraries.

mmalmi@cc.hut.fi to Satoshi Nakamoto <satoshin@gmx.com> · 4 February 2010, 17:47 UTC · original

Is there any way to find out what the missing shared libraries are? It would help to know.

This is what "ldd bitcoin" says: linux-gate.so.1 => (0xf778c000) libcrypto.so.0.9.8 => /usr/lib32/i686/cmov/libcrypto.so.0.9.8 (0xf762a000) libgtk-x11-2.0.so.0 => not found libgthread-2.0.so.0 => not found libSM.so.6 => /usr/lib32/libSM.so.6 (0xf7621000) libstdc++.so.6 => /usr/lib32/libstdc++.so.6 (0xf7533000) libm.so.6 => /lib32/libm.so.6 (0xf750f000) libgcc_s.so.1 => /usr/lib32/libgcc_s.so.1 (0xf7502000) libc.so.6 => /lib32/libc.so.6 (0xf73b0000) libdl.so.2 => /lib32/libdl.so.2 (0xf73ac000) libgdk-x11-2.0.so.0 => not found libXinerama.so.1 => /usr/lib32/libXinerama.so.1 (0xf73a8000) libgdk_pixbuf-2.0.so.0 => not found libX11.so.6 => /usr/lib32/libX11.so.6 (0xf72b9000) libpango-1.0.so.0 => not found libgobject-2.0.so.0 => not found libglib-2.0.so.0 => not found libpthread.so.0 => /lib32/libpthread.so.0 (0xf72a1000) libpng12.so.0 => /usr/lib32/libpng12.so.0 (0xf727e000) libz.so.1 => /usr/lib32/libz.so.1 (0xf7269000) libICE.so.6 => /usr/lib32/libICE.so.6 (0xf7251000) /lib/ld-linux.so.2 (0xf778d000) libXext.so.6 => /usr/lib32/libXext.so.6 (0xf7243000) libxcb-xlib.so.0 => /usr/lib32/libxcb-xlib.so.0 (0xf7241000) libxcb.so.1 => /usr/lib32/libxcb.so.1 (0xf7229000) libXau.so.6 => /usr/lib32/libXau.so.6 (0xf7226000) libXdmcp.so.6 => /usr/lib32/libXdmcp.so.6 (0xf7220000) Notfounds seem to be gtk-libraries indeed. I have those files in my /usr/lib folder, but maybe they're ignored because they're 64bit, or maybe only /usr/lib32 is searched. I haven't tested on other 64bit machines.

My 64-bit (debug stripped) executable is attached. It includes untested changes that are not in SVN yet: UI changes and the wallet fSpent flag resync stuff.

The package doesn't open, it says "not in gzip format".

Is it possible to open a socket that can only be accessed locally?

Yes, you can use IPC sockets ("Unix domain sockets") which are local only. That's done in the wx-api by using a filename in place of a port number. I committed an example of how the wxServer-Client communication is used, you can revert if you want to. Now there's the -blockamount command line option which asks the running instance for the block chain length. I think this command line method could already be used from PHP, but it might be lighter if php itself could call the socket server directly. The wx's IPC overview mentions wxSocketEvent, wxSocketBase, wxSocketClient and wxSocketServer as being "Classes for the low-level TCP/IP API", which might be easier to use from php than what I used now (wxServer, wxClient, wxConnection). I'll look more into it.

Satoshi Nakamoto to mmalmi@cc.hut.fi · 4 February 2010, 18:50 UTC · original

I must have accidentally typed j instead of z. It's bz2 format. Rename to .tar.bz2 or just do tar -jxvf

The package doesn't open, it says "not in gzip format".

Satoshi Nakamoto to mmalmi@cc.hut.fi · 4 February 2010, 19:59 UTC · original

Good, then no need to consider d-bus. Is there something like IPC sockets on Windows? I guess we could look how wx does it, or maybe the XML-RPC library will already know what to do. Windows has named pipes, maybe that's the best analogue. I don't think I want to invent my own RPC protocol, I want to use an existing standard. PHP, Java, Python or anything will be able to talk to the server directly the same way the command line commands do. I'm going to start reading on XML-RPC. It's coming up in searches as the most widely used protocol and widely supported. PHP includes it in its standard libraries.

> Is it possible to open a socket that can only be accessed locally? Yes, you can use IPC sockets ("Unix domain sockets") which are local only. That's done in the wx-api by using a filename in place of a port number. I committed an example of how the wxServer-Client communication is used, you can revert if you want to. Now there's the -blockamount command line option which asks the running instance for the block chain length. I think this command line method could already be used from PHP, but it might be lighter if php itself could call the socket server directly. The wx's IPC overview mentions wxSocketEvent, wxSocketBase, wxSocketClient and wxSocketServer as being "Classes for the low-level TCP/IP API", which might be easier to use from php than what I used now (wxServer, wxClient, wxConnection). I'll look more into it.