Bitcoin Forum

I been implementing bitcoin in python3. The result can be found on Gitorious (http://gitorious.org/pycoin). It intended to work in largely the same way as bitcoind, with all frontend programs communicating by IPC.

It is implemented around a select loop and does not use threads at all (this is one thing that makes it unique). Currently it connects to a client at 64.22.103.150, comunicates for a bit and dies when it recieves a block message (usually the one it requests). It can connect to multiple clients at once, but makes not real attempt to do so (trying to connect to a machine that can't possibly exist doesn't count).

Donations welcome at 1FLjoKrqjCMZLLCZz8NJ5u4AsVhDYPYLWR.

yes! great work ;D

Python is cool, keep going!  :)

Cheers,

Good.  I'll definitely look into that.

Let me know if you want to move it under the bitcoin project to http://gitorious.org/bitcoin/pycoin

Can we get a real license on this? Your LICENSE/UNLICENSE files have no legal relevance in any jurisdictions*, thus this code is still under a default/standard copyright which forbids anyone else from copying it.

* IANAL and TINLA

Even if the wording of the UNLICENSE file its legally inadmissable, its presence obviously gives an implied license. The concept of implied license is recognised by courts in the US, the UK, the EU, and most Commonwealth countries, and probably most of the rest of the world too.

So go ahead and copy the unlicensed code.

What about using http://unlicense.org/ ?

Did you considered building pycoin on the top of ArtForz half-node source lying somewhere on the pastebin.com? I see that you duplicated some of his great job. I have also fork of his node running on the Twisted framework (in fact it needed only few tweaks), which is very robust and can be easily integrated with Qt, for example.

I didn't published my fork, because my job with the node isn't done yet, but if you're interested, I can send it to you right now. It would be nice to work on the same core and don't split the power between two very similar projects.

I have wet dreams about full bitcoin client implementation in python, so I appreciate any progress on it.

Edit: I'm talking about this client code (http://pastebin.com/ZSM7iHZw) written by ArtForz. There is newer version lying around, which solve storing the blockchain to the disk, but I cannot find the link.

I'm not the first to do this sort of thing (see this (http://esr.ibiblio.org/?p=2000)). It's basically the WTFPL, written by someone who was feeling philosophical rather than silly. The file UNLICENSE is not meant to be legally binding, it means "We won't complain, and you're not under any legal obligation, but please..." (it even says "see LICENSE").

Most of those meta-files are just plain silly anyway (particularly "configure").


Thanks for the pointer, I'l use it.

I'll rearrange those files and push the result.

Sorry, the functionality overlap is too great for it to deliver any benefit. A quick flick through was useful though, I think I should refactor the code to use file-like objects where I'm currently slicing up bytestrings.

I would be nice if someone could find/write some ECDSA signing code for python3 (probably using the c-api (http://docs.python.org/py3k/extending/index.html)). I'm not very interested in or familiar with that area.

What do you exactly mean? As I understand your project correctly, you're doing (yet another) bitcoin node implementation...

You may consider replacing
with
in the pycoin.py file to work in cases where Python3 is not installed in the default location.

I should have called it YABNI, damn!

Merging codebases is hard. I would need to write glue code to connect the two codebases and that would exceed any benefits. Linus Torvalds, notably, found himself in a similiar situation, had he known about 386BSD (ancestor of all Intel BSDs) he would never have started Linux.

Lots of node implementations is a good thing in some sense, because they cannot share security bugs and force clarity into standards (this is why the IETF requires "multiple, independent, and interoperable implementations" in it's standards).

This is true when those versions do something. Currently, we have many implementations where each does practically nothing. I preffer to have one alternative implementation which cover original functionality as much as possible than have many implementations where every can just connect to another node, receive a message and die. I call it "split of the effort".

I cannot say anything, because I didn't write any of those implementations, but writing YABNI from the scratch doesn't make sense for me.

Indeed.  ArtForz' node implementation (http://pastebin.com/ZSM7iHZw) was posted over 3 months ago.

I'll be interested once people can store and verify transactions and blocks, and handle a block chain switch.  Until then...  we have achieved 3x message encode/decode engines.  Color me unexcited :)

The best task for all these python programmers is a lightweight bitcoin client, one that only needs block headers, its own transactions and associated merkle branches.

My perl implementation can download all chain with verifications and ecdsa: http://bitcointalk.org/index.php?topic=231.msg5906#msg5906
I still didn't get the consensus - are alt clients good or bad?

Update: here it is http://frox25.no-ip.org/~mtve/wiki/BitcoinPl.html

Alternative clients strictly following official rules are wildly welcome (at least from me). Unfortunately, those rules are often badly documented, so it is pretty hard to follow them. When some alternative client with badly implemented rules takes significant part of Bitcoin network, there is a risk of blockchain split and then collapse of whole network.

+1 agreed here, too