Bitcoin Forum
December 05, 2016, 07:00:33 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 [2]  All
  Print  
Author Topic: Python client  (Read 28181 times)
jgarzik
Legendary
*
Offline Offline

Activity: 1470


View Profile
August 03, 2010, 02:38:22 AM
 #21

I'm not sure about that list; this is what I see:
Code:
[jgarzik@bd bitcoin.hacks]$ grep '(strCommand ==' main.cpp
    if (strCommand == "version")
    else if (strCommand == "verack")
    else if (strCommand == "addr")
    else if (strCommand == "inv")
    else if (strCommand == "getdata")
    else if (strCommand == "getblocks")
    else if (strCommand == "tx")
    else if (strCommand == "block")
    else if (strCommand == "getaddr")
    else if (strCommand == "checkorder")
    else if (strCommand == "submitorder")
    else if (strCommand == "reply")
    else if (strCommand == "ping")

Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480964433
Hero Member
*
Offline Offline

Posts: 1480964433

View Profile Personal Message (Offline)

Ignore
1480964433
Reply with quote  #2

1480964433
Report to moderator
Cdecker
Hero Member
*****
Offline Offline

Activity: 487



View Profile WWW
August 03, 2010, 11:10:13 AM
 #22

Your right of course, I was grepping for PushMessage(" instead of strCommand Smiley

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?

Want to see what developers are chatting about? http://bitcoinstats.com/irc/bitcoin-dev/logs/
Bitcoin-OTC Rating
lachesis
Full Member
***
Offline Offline

Activity: 210


View Profile
August 03, 2010, 12:35:34 PM
 #23

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);
Here's an (ugly) colorized version of the version packet from my machine:
http://www.alloscomp.com/bitcoin/messages/version.html

Bitcoin Calculator | Scallion | GPG Key | WoT Rating | 1QGacAtYA7E8V3BAiM7sgvLg7PZHk5WnYc
lachesis
Full Member
***
Offline Offline

Activity: 210


View Profile
August 03, 2010, 10:36:12 PM
 #24

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.

Bitcoin Calculator | Scallion | GPG Key | WoT Rating | 1QGacAtYA7E8V3BAiM7sgvLg7PZHk5WnYc
Cdecker
Hero Member
*****
Offline Offline

Activity: 487



View Profile WWW
August 22, 2010, 12:40:56 PM
 #25

@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 ^^

Want to see what developers are chatting about? http://bitcoinstats.com/irc/bitcoin-dev/logs/
Bitcoin-OTC Rating
Gespenster
Newbie
*
Offline Offline

Activity: 15


View Profile
August 22, 2010, 05:15:33 PM
 #26

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.
Cdecker
Hero Member
*****
Offline Offline

Activity: 487



View Profile WWW
August 23, 2010, 01:51:06 PM
 #27

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  Grin

Want to see what developers are chatting about? http://bitcoinstats.com/irc/bitcoin-dev/logs/
Bitcoin-OTC Rating
vess
Full Member
***
Offline Offline

Activity: 141



View Profile WWW
August 30, 2010, 08:00:10 AM
 #28

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.

I'm the CEO of CoinLab (www.coinlab.com) and the Executive Director of the Bitcoin Foundation, I will identify if I'm speaking for myself or one of the organizations when I post from this account.
Gavin Andresen
Legendary
*
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
August 30, 2010, 10:23:34 PM
 #29

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, so maybe a 100% App Engine bitcoin client will be possible in the future.

How often do you get the chance to work on a potentially world-changing project?
vess
Full Member
***
Offline Offline

Activity: 141



View Profile WWW
August 31, 2010, 12:25:27 AM
 #30

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.

I'm the CEO of CoinLab (www.coinlab.com) and the Executive Director of the Bitcoin Foundation, I will identify if I'm speaking for myself or one of the organizations when I post from this account.
grondilu
Legendary
*
Offline Offline

Activity: 1134


View Profile
December 10, 2010, 07:28:04 PM
 #31


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.
davout
Legendary
*
Offline Offline

Activity: 1358


1davout


View Profile WWW
December 10, 2010, 08:21:48 PM
 #32

+1

gene
Sr. Member
****
Offline Offline

Activity: 252


View Profile
December 14, 2010, 10:02:35 AM
 #33

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.

*processing payment* *error 404 : funds not found*
Do you want to complain on the forum just to fall for another scam a few days later?
| YES       |        YES |
grondilu
Legendary
*
Offline Offline

Activity: 1134


View Profile
December 14, 2010, 10:08:37 AM
 #34

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.
Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



View Profile
March 04, 2011, 07:45:46 PM
 #35

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.

TiagoTiago
Hero Member
*****
Offline Offline

Activity: 616


Firstbits.com/1fg4i                :Ƀ


View Profile
March 05, 2011, 07:21:51 AM
 #36

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.

(I dont always get new reply notifications, pls send a pm when you think it has happened)

Wanna gimme some BTC for any or no reason? 1FmvtS66LFh6ycrXDwKRQTexGJw4UWiqDX Smiley

The more you believe in Bitcoin, and the more you show you do to other people, the faster the real value will soar!

Do you like mmmBananas?!
genjix
Legendary
*
Offline Offline

Activity: 1232


View Profile
March 11, 2011, 09:59:24 AM
 #37

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.
HostFat
Staff
Legendary
*
Offline Offline

Activity: 2282


I support freedom of choice


View Profile WWW
April 13, 2011, 02:00:50 PM
 #38

"Background servers capable of running for longer than 30s" is a feature on Google's roadmap, so maybe a 100% App Engine bitcoin client will be possible in the future.
Is it possible right now? Smiley
http://googleappengine.blogspot.com/2010/12/happy-holidays-from-app-engine-team-140.html

Eternity Wall: Messages lasting forever - The Rock Trading (ref): A good exchange / gateway Ripple, with support for multisig, since 2007. 
https://bitcointa.lk: Bitcointalk backup if offline - Bitcoin Foundation Italia - Blog: http://theupwind.blogspot.it
alkor
Full Member
***
Offline Offline

Activity: 137


View Profile
April 14, 2011, 01:57:21 AM
 #39

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.
Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



View Profile
April 14, 2011, 04:51:20 AM
 #40

Spesmilo is a fully functional PySide GUI, FWIW. https://gitorious.org/bitcoin/spesmilo

Pages: « 1 [2]  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!