[In Development] Bitcoin.jl - A Julia bitcoin library


#1

Hi All,

Following an intense seminar on bitcoin development, I began to implement a bitcoin library in native Julia. At time of writing, functionalities are limited to address generation and slowly moving towards full node functionalities.
Anyone might have a look at GitLab, comments are always welcome - I am discovering Julia along this project :slight_smile:


Blockchain
#2

FYI: It’s GPL licensed.


#3

Is there any particular reason you chose a GPL license? The Julia community tends to use MIT licenses, which prevents people from even looking at GPL licensed code.


#4

Yes: I am against intellectual property and since MIT doesn’t require modifications to be open sourced whereas GPL does, the later “ensures” work derived from it must be open sourced as well.
In short, I would not like to see my work used in a proprietary app.


#5

Just because Julia is MIT, there’s no reason to expect packages to follow the same licensing IMHO. It should be completely up to the author. Also, “which prevents people from even looking at GPL licensed code” is a little hyperbolic in my view - it’s an extreme interpretation of the inherent uncertainty in defining a “derived work” for GPL.


#6

I don’t think that the GPL prevents this — they would just have to make the source public :smile:


#7

I have a fairly well working parser for the Bitcoin blockchain which I wanted to put on Github at some point. Base58.jl and Ripemd.jl are the parts I already made public. Maybe we should coordinate a little bit.

Looking at your repo, standard practices in Julia are:

  • Julia packages should be small units, so this should probably be a number of small packages instead of a monolithic Bitcoin.jl.
  • You are implementing ECC cryptrography, maybe the name or the package should reflect this.
  • These packages should be collected in a single Bitcoin Github organization.
  • I think you have every right to publish your code under the GPL license and to use Gitlab (especially as Github belongs to Microsoft now), but you have to be aware that this makes collaboration less convenient.

#8

I also disagree a little here. Some julia developers have divided everything into small packages in an organization, others not. In my personal view, the only real purpose of the organizations is to allow a group of people to collaborate on a project. And the reason for dividing functionality into small packages is to separate functionality so people can depend only on relevant subsets of the code.


#9

In Bitcoin there is a lot of self-contained and reusable functionality: encodings, cryptography, consensus algorithms, serialization.


#10

Are we talking about Bitcoin specifically here or more generally about blockchain?


#11

I am indeed relying on your Ripemd.jl package, thanks for that :slight_smile:
Regardless of other projects such as yours, I was planning at implementing basic node functionalities from the ground up for two main reason: get to know Julia as much as possible and deepen my bitcoin knowledge.
That being said, I am more than happy to collaborate to release some smaller package. i.e. now that I manage to implement base58 in my project, I’ll have a look at your implementation and contribute as I can while removing base58 code from Bitcoin.jl and adding dependency to Base58.jl
Kinda step by step but code to understand first…

That make sense, I’ll implement ECDSA first and split code to an ECC package

I am prepared at giving away convenience for the free software cause :wink:
I was planning at releasing all package under gitlab.com/braneproject which I owe but I am also ok at creating a BitcoinJulia organization on Github if that suits you better for any reason


#12

Bitcoin specifically.
However, most of the code could be used for other cryptocurrencies with little tweaks - most of being forks of bitcoin code.


#13

I wrote the bitcoin blockchain parser for the same reason you are writing your implementation, to get a better understanding of the technology behind it. My goal was never to write a complete bitcoin client from scratch, but to analyse transactions, etc. Therefore I never touched the asymmetric crypto part and the consensus/network protocols. So I think our goals complement each other pretty well.

For me there are a lot of time constraints because it is entirely unrelated to my everyday job. If you want to take the lead on this, I will be happy to follow when my schedule allows it to do so.


#14

Fair enough.
I’ll move forward learning Julia and Bitcoin protocol by coding and will try to split code in smaller package that anyone could use for other purpose than Bitcoin.
I’ll use my GitLab repo at first but this isn’t written in stone, I’m flexible here.
I’ll update this topic as my code develops: next target is to have a working ECDSA.


#15

I’ve just implemented ECC in a separate package to be published shortly: ECC.jl
Bitcoin.jl will be amended to use the former.


#16

Except it does (unless GPL code in a separate process). You’re mixing up commercial and proprietary. The compiled binaries from GPL code need to be non-proprietary, not just the source code (LGPL and MPL with lesser copyleft allows binaries to be propriety however).


#17

I am not sure what that means in this context. But you can definitely charge money for the compiled program.

https://www.gnu.org/licenses/gpl-faq.html#DoesTheGPLAllowMoney
https://www.gnu.org/licenses/gpl.html#section6


#18

From what I understand, you’re welcome to charge money for GPL binaries and/or sources (such as when distributing CDs with Linux on them), however you must make the source available in some manner compliant with the GPL. I don’t know if there are any rules on how much you can charge to distribute the source though.

EDIT: Found this on SO, no clue how accurate it is, but it makes sense to me: https://law.stackexchange.com/questions/18499/is-it-a-gplv3-violation-for-a-project-to-charge-a-fee-for-downloading-binaries


#19

The detailed rules are in the second link I provided, but the relevant excerpt is

a price no more than your reasonable cost of physically performing this conveying of source

if you insist on a physical distribution channel.