|
Title: Python client Post by: Cdecker on July 04, 2010, 11:22:50 AM I was wondering whether someone here might be interested in creating an alternative client to the Project, which would not only make it easier for some people to get going with BitCoin but also would make it easier to write customized clients and take the load off the main development team.
For this to work we'd have to know exactly how the protocol is designed. I could reverse engineer it but I probably won't be able to explain everything :) BTW: Python is not my first choice when it comes to programming languages but for this I think it'd be the most flexible. Edit: just thought of it: Google App Engine supports Python so there's another application area :D Title: Re: Python client Post by: Gavin Andresen on July 04, 2010, 12:50:26 PM I've started reverse-engineering and documenting the wallet and block databases, and have written some Python code that deserializes many of the Bitcoin data structures. I was going to let it ferment a little more before announcing, but Mr. Google will surely find and index it soon, and it should be a good head start for anybody who wants to start a Python bitcoin client.
Open source, MIT license, at: MOVED TO git: http://github.com/gavinandresen/bitcointools Title: Re: Python client Post by: andrew on July 26, 2010, 03:49:50 PM Are you going to be working on a full client yourself? ;D
Title: Re: Python client Post by: Gavin Andresen on July 26, 2010, 05:16:43 PM Are you going to be working on a full client yourself? ;D I've been tempted... but no, I'm more interested in doing web-based Bitcoin apps, and extending the existing C++ implementation's JSON-RPC API is a whole lot less work than re-implementing the whole shebang.Title: Re: Python client Post by: mtve on July 26, 2010, 05:35:47 PM Hi!
I had almost working pure perl client, but since I've heard alt clients are not welcomed, i've abandoned that project. -- mtve Title: Re: Python client Post by: NewLibertyStandard on July 26, 2010, 10:37:43 PM Hi! Where did you hear that?I had almost working pure perl client, but since I've heard alt clients are not welcomed, i've abandoned that project. -- mtve Title: Re: Python client Post by: mtve on July 27, 2010, 04:41:30 PM http://bitcointalk.org/index.php?topic=221.0 etc
Title: Re: Python client Post by: Cdecker on July 27, 2010, 07:21:30 PM I strongly believe that a system like BitCoin is only destined to survive for a long time if the protocol is standardized and split from the Mainline client development.
A minimalistic, but clean, Python implementation of the client could be used as a reference for future clients that could then be custom tailored to the needs of its users. Title: Re: Python client Post by: Cdecker on July 27, 2010, 10:12:07 PM I'm starting to reverse engineer the protocol, but my C++ is incredibly rusty ;)
As far as I understand it the protocol is based on simple messages each 16 bytes long with variable argument lists. Each message starts with the sequence {0xf9,0xbe,0xb4,0xd9}, and the command itself is 12 bytes (0x00 padded). Depending on the type of the message we have to parse some arguments. Thus far I've analyzed the "version" command, whose goal is to exchange some initial information (both parties send and receive a version message): version
Anyone else interested in byte-guessing ;D Title: Re: Python client Post by: lachesis on July 28, 2010, 01:16:58 AM According to main.cpp:1761 (svn r113):
Code: // Message format Title: Re: Python client Post by: Cdecker on July 28, 2010, 01:49:03 AM That sounds reasonable :-)
Any idea what Checksum algorithm this is? And is the header (4bytes and message type) also considered in the checksum and message size? Edit: Just checked: the size is the number of bytes following the size byte itself, I guess that the checksum is for that range also. Title: Re: Python client Post by: lachesis on July 28, 2010, 02:02:21 AM That sounds reasonable :-) From my research, the header is _not_ considered in the size. It cannot be considered in the checksum, since the checksum would have to be known to calculate the checksum.Any idea what Checksum algorithm this is? And is the header (4bytes and message type) also considered in the checksum and message size? Here's the relevant code. Some comments added. I don't know what exactly the Hash() function does yet. Code: // Set the size The problem I'm having is parsing the version command's data. Version _should_ be made of these things serialized, as per net.h:580: Code: PushMessage("version", VERSION, nLocalServices, nTime, addrYou, addrMe,However, VERSION = 304 according to my client, and here's the hex dump of the data I'm getting: Code: eswanson@eswanson-laptop:~$ python read.py --EDIT-- Alright, I've been playing with the "version" message the client sends automatically when you connect to it. First of all, as much as I respect Satoshi, I really don't like this format. Something like protocol buffers would have been much neater and more efficient. Secondly, I suspect that this message doesn't have a checksum because it can't be sure if the client it is talking to has a version > 209 until it gets a verack or version message. I'll play with that next, but I think the checksum is omitted initially to deal with older clients. Here's my analysis of the components of the data section of this message: Code: VERSION - int (4b) Now for the address struct, here's the IMPLEMENT_SERIALIZE block: Code: IMPLEMENT_SERIALIZE From what I can tell, this indicates that the over the wire format is: Code: nServices - uint64 (8b) Title: Re: Python client Post by: NewLibertyStandard on July 28, 2010, 08:47:14 AM http://bitcointalk.org/index.php?topic=221.0 etc Well I think clients in other languages would be very valuable. I would particularly enjoy looking through a Java client. There may be some unknown danger to connecting a different client to the production Bitcoin network, but you can aways just code it to only connect to the test network and include a note in the source code requesting that people not connect to the production network. I'm sure if it was very thoroughly tested and received plenty of attention, eventually no one would have a problem with it connecting to the production server.Title: Re: Python client Post by: Cdecker on July 28, 2010, 02:43:07 PM From what I can tell, this indicates that the over the wire format is: Great, I was able to reconstruct the IP address from my dump and it turns out correctly. So just to sum it up:Code: nServices - uint64 (8b)
version
Title: Re: Python client Post by: lachesis on July 28, 2010, 07:19:33 PM --EDIT--
Here's my (sloppy) Python script to read and parse the initial version message. Run it with no arguments to connect to localhost or one argument to connect to the computer at that IP / hostname. http://www.alloscomp.com/bitcoin/version.pys I also decided to host the code on GitHub and create a Google Code page. I'll be happy to give commit access / read-write privs to the Google Code page to anyone who's interested. http://code.google.com/p/pybitcoin/ and http://github.com/lachesis/pybitcoin Sample output:Code: "version" 87b (checksum: 0) Pretty close.
Code: 0x7E 0x81 0x50 0x4C 0x00 0x00 0x00 0x00 [/li][li]A subversion string ".0" in my case[/li][/list] I'm getting some weird stuff here: my string is 3 bytes long and starts with 0x02:"0x02 0x2E 0x30" ("\02.0"). It's also not 0x00 terminated. On an older client with no subversion string, it's just one 0x00. Oh nevermind: it's one byte of length followed by the string. So 0x02: ".0". On the older client, the string's length is 0. That's much better than I anticipated. Everything else in your summary looks good! Finally, it looks like checksum is only calculated when message size > 0. That's wise. Checksum also doesn't appear to be sent for "version" messages even when one client knows the other is new enough to accept the checksum. Upon connecting to one another, both clients send a "version" message. With that complete, they both send "verack" upon receiving the other's version message. Then one sends an "inv" message that appears to contain a list of transactions IDs that node knows about. The other node then queues the transactions it doesn't know about to "mapAskFor" and executes a getdata request (or several - it cuts them when their size > 1000) for those transactions. Title: Re: Python client Post by: Cdecker on July 29, 2010, 10:56:25 AM --EDIT-- The on google code or github wiki looks very nice to document our efforts. Could I get access to it?Here's my (sloppy) Python script to read and parse the initial version message. Run it with no arguments to connect to localhost or one argument to connect to the computer at that IP / hostname. http://www.alloscomp.com/bitcoin/version.pys I also decided to host the code on GitHub and create a Google Code page. I'll be happy to give commit access / read-write privs to the Google Code page to anyone who's interested. http://code.google.com/p/pybitcoin/ and http://github.com/lachesis/pybitcoin Title: Re: Python client Post by: lachesis on July 29, 2010, 10:37:56 PM The on google code or github wiki looks very nice to document our efforts. Could I get access to it? Sure. I sent you a PM. Anyone who wants to be part of the project just drop me a PM with your Google Account / Gmail email address. Title: Re: Python client Post by: Cdecker on July 31, 2010, 02:47:45 PM The on google code or github wiki looks very nice to document our efforts. Could I get access to it? Sure. I sent you a PM. Anyone who wants to be part of the project just drop me a PM with your Google Account / Gmail email address. Title: Re: Python client Post by: Cdecker on July 31, 2010, 02:51:33 PM I started the Wiki page here http://code.google.com/p/pybitcoin/wiki/BitcoinProtocol
So far we have the version message pretty worked out, except the nLocalServices, nLocalHostNonce and the nBestHeight, which I can't fathom what they are used for. As for the other messages I have identified these so far:
Title: Re: Python client Post by: lachesis on August 03, 2010, 02:18:29 AM I started the Wiki page here http://code.google.com/p/pybitcoin/wiki/BitcoinProtocol Nice work! I made some small changes.So far we have the version message pretty worked out, except the nLocalServices, nLocalHostNonce and the nBestHeight, which I can't fathom what they are used for. nBestHeight is the number of blocks minus one, which means it's probably the index of the last block the host knows about. That's so the nodes can choose who should ask for blocks after the initial version message exchange. I don't know what the rest of those are, except that nLocalHostNonce is used (at least partially) to make sure the client isn't connecting to itself and nLocalServices appears to always be 1.[/quote] As for the other messages I have identified these so far: Don't forget "tx", used to insert a transaction.Title: Re: Python client Post by: jgarzik on August 03, 2010, 02:38:22 AM I'm not sure about that list; this is what I see:
Code: [jgarzik@bd bitcoin.hacks]$ grep '(strCommand ==' main.cpp Title: Re: Python client Post by: Cdecker on August 03, 2010, 11:10:13 AM Your right of course, I was grepping for PushMessage(" instead of strCommand :)
Apparently though subscribe, sub-cancel, publish and pub-cancel are never used in the code, at least I was unable to ever capture one of the messages. By the way, the "version" message does not include a version number only a string, where is the version number transferred? Title: Re: Python client Post by: lachesis on August 03, 2010, 12:35:34 PM By the way, the "version" message does not include a version number only a string, where is the version number transferred? It includes the version number as the first four bytes (host byte order) of the message. That number is converted to the 0.3.6 notation that you see in the client:Code: init.cpp:191: printf("Bitcoin version %d.%d.%d%s beta\n", VERSION/10000, (VERSION/100)%100, VERSION%100, pszSubVer);http://www.alloscomp.com/bitcoin/messages/version.html Title: Re: Python client Post by: lachesis on August 03, 2010, 10:36:12 PM On a slightly more meta note, here's the protocol for making a transaction:
Transaction is built and the hash is taken. My client sends "inv" message to every other host to which it is connected. If the other client doesn't already know about the tx, it responds with a "getdata" message with the same data (and therefore checksum). My client then responds with a "tx" message. I've been decoding the tx message, but I haven't gotten it down yet. These messages are or will be decoded on the wiki here http://code.google.com/p/pybitcoin/wiki/BitcoinProtocol. Title: Re: Python client Post by: Cdecker on August 22, 2010, 12:40:56 PM @lachesis: I started my own bitcoin client to play with the protocol and I have to say you did a great job with your Writer and Reader classes, I adapted them slightly as to have a socket writer/reader and a string writer/reader, they are just so much easier than to use pack and unpack all over the place ^^
Title: Re: Python client Post by: Gespenster on August 22, 2010, 05:15:33 PM I'm looking into the possibility of integrate Bitcoin functionality into an existing GPL software product, the problem is that it seems to be hard. The one true implementation brings with it some additional dependencies such as wxWindows (which is actually pointless if you're just interested in the functionality and not the GUI), BerkeleyDB (which is a bit much for storing just a bunch of keypairs), openSSL (which is reasonable as it's use is very wide-spread, but i'm not entirely sure why it is required as the set of crypto functions in Bitcoin is fairly limited afaik) and Boost (which is huge to introduce in an existing project when it's only needed for Bitcoin functionality). Especially on Windows is including those libraries far from a straightforward task and building a 64-bit binary for Windows is just a pain.
I don't really have a problem with the fact that a one true implementation is preferred, because I understand more implementations will introduce complications in this early stage, the examples where this method is successful are few (Perl is maybe one of the very few exceptions probably because it's very well-documented). I think in the long run multiple implementations are going to be required if Bitcoin is to grow (a lot) larger. Keep in mind that in time perhaps other devices with much more esoteric platforms may want to be able to have Bitcoin functionality as well (smartphones were already mentioned, but think about automated payment servers, set-top boxes, vending machines, pay-toilets, ...). Bittorrent, which is mentioned here as an example, is currently running on the firmware of some people's networked harddrives. Maybe on-chip implementations of Bitcoin will be made one day. Being able to run Bitcoin in javascript (with an AJAX proxy) would be a significant advantage for the application I'm thinking about. I think what would be needed is a very low-dependency reference implementation, which can easily be translated into other programming languages without introducing new bugs or incompatibilities. In time the protocol should be standardized and perhaps even go for recognition by standards bodies. That's the best way to guarantee long-term survival of the network. Every platform in the world that could be capable of using Bitcoin has at least a decent C compiler and the current de facto standard way to have a low-dependency reference implementation is to have C library which can be easily compiled on all major platforms without (or with absolute minimal) dependencies. The stock client should also use that C library. Title: Re: Python client Post by: Cdecker on August 23, 2010, 01:51:06 PM I think what would be needed is a very low-dependency reference implementation, which can easily be translated into other programming languages without introducing new bugs or incompatibilities. In time the protocol should be standardized and perhaps even go for recognition by standards bodies. That's the best way to guarantee long-term survival of the network. Every platform in the world that could be capable of using Bitcoin has at least a decent C compiler and the current de facto standard way to have a low-dependency reference implementation is to have C library which can be easily compiled on all major platforms without (or with absolute minimal) dependencies. The stock client should also use that C library. My point exactly, the protocol needs to be standardized and well documented. In its current state the Protocol would pass no standardization process anyway, variable headers with/without checksums, variable length size fields, 30% of all fields are just placeholders, ... Anyway I'm trying to work on a python client that has no dependencies except the default python installation ;D Title: Re: Python client Post by: vess on August 30, 2010, 08:00:10 AM I agree with the sentiment that a small reference client would be hugely helpful. I would like one that ran on Google App Engine, for instance, and as you say, a reference javascript version would be totally fabulous.
Title: Re: Python client Post by: Gavin Andresen on August 30, 2010, 10:23:34 PM I agree with the sentiment that a small reference client would be hugely helpful. I would like one that ran on Google App Engine, for instance, and as you say, a reference javascript version would be totally fabulous. Neither of those are feasible-- both App Engine and Javascript don't allow arbitrary socket connections, and a full bitcoin client needs to maintain a persistent connection to at least one other bitcoin client to get transaction messages."Background servers capable of running for longer than 30s" is a feature on Google's roadmap (http://code.google.com/appengine/docs/roadmap.html), so maybe a 100% App Engine bitcoin client will be possible in the future. Title: Re: Python client Post by: vess on August 31, 2010, 12:25:27 AM Hmm,
GAE cron jobs could probably keep up to date or close. Javascript in the browser would not work as a full client for the reasons you suggested, but there is node.js. I think a javascript port of a minimal client would find plenty of uses. For instance, maprejuice.com just launched -- they claim 200,000 web clients already. I imagine one would be interested to run block generation there. Title: Re: Python client Post by: grondilu on December 10, 2010, 07:28:04 PM Personnaly I think Satoshi's code is quite tough to understand, that's why I'd like to see other implementations, for instance in python. I also wonder whether it could be possible to split the program into different parts. For instance, blocks could be downloaded and shared with a standard P2P program. One file per block. I know that may be beyond the maximum number of opened files on most OS but... I'd like also to see those files in ASCII, and not in binary. Same for wallets. Performance is not an issue with bitcoin anyway, execpt for generation. So ASCII could be fine. Also, the libcrypto++-utils package contains command line tools to use cryptographic functions, such as ECDSA. Using standard P2P program, command line tools and ASCII files could allow to write the full bitcoin client in a bash script. I think this would be pretty cool. Title: Re: Python client Post by: davout on December 10, 2010, 08:21:48 PM +1
Title: Re: Python client Post by: gene on December 14, 2010, 10:02:35 AM I'm looking into the possibility of integrate Bitcoin functionality into an existing GPL software product, the problem is that it seems to be hard. The one true implementation brings with it some additional dependencies such as wxWindows (which is actually pointless if you're just interested in the functionality and not the GUI), BerkeleyDB (which is a bit much for storing just a bunch of keypairs), openSSL (which is reasonable as it's use is very wide-spread, but i'm not entirely sure why it is required as the set of crypto functions in Bitcoin is fairly limited afaik) and Boost (which is huge to introduce in an existing project when it's only needed for Bitcoin functionality). Especially on Windows is including those libraries far from a straightforward task and building a 64-bit binary for Windows is just a pain. I don't really have a problem with the fact that a one true implementation is preferred, because I understand more implementations will introduce complications in this early stage, the examples where this method is successful are few (Perl is maybe one of the very few exceptions probably because it's very well-documented). I think in the long run multiple implementations are going to be required if Bitcoin is to grow (a lot) larger. Keep in mind that in time perhaps other devices with much more esoteric platforms may want to be able to have Bitcoin functionality as well (smartphones were already mentioned, but think about automated payment servers, set-top boxes, vending machines, pay-toilets, ...). Bittorrent, which is mentioned here as an example, is currently running on the firmware of some people's networked harddrives. Maybe on-chip implementations of Bitcoin will be made one day. Being able to run Bitcoin in javascript (with an AJAX proxy) would be a significant advantage for the application I'm thinking about. I think what would be needed is a very low-dependency reference implementation, which can easily be translated into other programming languages without introducing new bugs or incompatibilities. In time the protocol should be standardized and perhaps even go for recognition by standards bodies. That's the best way to guarantee long-term survival of the network. Every platform in the world that could be capable of using Bitcoin has at least a decent C compiler and the current de facto standard way to have a low-dependency reference implementation is to have C library which can be easily compiled on all major platforms without (or with absolute minimal) dependencies. The stock client should also use that C library. Emphasis mine. I registered just to reply to this and offer some insight. As a unix-type, I insist that modularity is important. By reimplementing specific cryptographic transforms rather than using something like openssl, the programmer risks all sorts of problems (recall the debian openssl fiasco a while back). The work has already been done by competent experts and is well-tested. Rolling in specific algos in lieu of calling openssl encourages "getting cute" with important components which are best left alone, especially when dealing with financial crypto. The best approach is to standardize protocols (RFCs) and provide an open (BSD/GPL) modular "reference" implementation. An excellent example of a successful execution is GnuPG. P.S. Someone, in either this thread or another, raised the point that communicating via IRC seems to be a rather obvious point of failure. I may be totally misinformed, but if this is true, it goes to my point about the importance of protocols over implementation details. A de facto reference implementation already exists; perhaps it is time to aggressively tackle some other problems via protocols. I am confident that an ecosystem of implementations will emerge naturally, similar to bittorrent. Title: Re: Python client Post by: grondilu on December 14, 2010, 10:08:37 AM The best approach is to standardize protocols (RFCs) and provide an open (BSD/GPL) modular "reference" implementation. An excellent example of a successful execution is GnuPG. I don't understand everything but I agree with that. Title: Re: Python client Post by: Luke-Jr on March 04, 2011, 07:45:46 PM I had almost working pure perl client, but since I've heard alt clients are not welcomed, i've abandoned that project. I would welcome a Perl implementation of various parts of BitCoin.I also suggest new development try to stick to an abstract 4-piece infrastructure documented on https://en.bitcoin.it/wiki/Infrastructure so end users can choose to run different combinations of wallets/UIs/etc. Title: Re: Python client Post by: TiagoTiago on March 05, 2011, 07:21:51 AM IRC is just the default, i read someone saying there are a couple different fallbacks for when IRC isn't avaiable or desired by the user.
A python client that only depends on python would indeed be awesome. Title: Re: Python client Post by: genjix on March 11, 2011, 09:59:24 AM Not much to add here, except that if you had a basic reference implementation written in Python, then that'd be excellent.
Bitcoin should be broken down, and then there should be a core from which all the other components are built around. Imagine something *really* basic and difficult to use but very flexible for people to add new features to. Title: Re: Python client Post by: HostFat on April 13, 2011, 02:00:50 PM "Background servers capable of running for longer than 30s" is a feature on Google's roadmap (http://code.google.com/appengine/docs/roadmap.html), so maybe a 100% App Engine bitcoin client will be possible in the future. Is it possible right now? :)http://googleappengine.blogspot.com/2010/12/happy-holidays-from-app-engine-team-140.html Title: Re: Python client Post by: alkor on April 14, 2011, 01:57:21 AM Some work on a python implementation of bitcoin is done here:
https://github.com/phantomcircuit/bitcoin-alt Although, I am not really sure how close this is to an actual working client. Title: Re: Python client Post by: Luke-Jr on April 14, 2011, 04:51:20 AM Spesmilo is a fully functional PySide GUI, FWIW. https://gitorious.org/bitcoin/spesmilo (https://gitorious.org/bitcoin/spesmilo)
|