600 lines, however the codebase is quite unreadable.
Typically, code written in python is rather readable and easy to follow, but this is heavily condensed and somehow completely void of any sort of pythonic code. Programs are the communication of thoughts between fellow software writers, readability should be your #1 priority.
Yeah. The author says they are following pep8 but I thought spaces between functions was part of those guidelines. Definitely trying hard to reduce the lines below 600. Yet I feel like if the bragging rights had been "under 1000 lines" we still would be equally interested.
Very little of this follows PEP8. The code appears to have been written as tersely as possible, even in cases where it would have utterly no effect on the 600 SLOC limit.
Wouldn't it be even easier to just use Git for most of the heavy lifting?
- Ledger is a file in a Git repo
- Blocks are confirmed by committing them with a SHA1 with sufficiently many leading zeros (adjust a nonce in the commit msg until it fits)
- Some bot accepts all pull requests into the Github repo that are fast-forward and whose commits have sufficiently many leading 0s (possibly after confirming that the booking is valid ;)
We could call that... oh I don't know, DvcsCoin or so.
Millions of currencies. I was standing at the back of the room when Andreas said that and I was like, yeah, I can see it.
The blockchains deliver trusted communication of stored work to us. The network has value in and of that function alone. That I can verify you have thing of X value and I have thing of Y value and that the ratio of X to Y is such as established by these market APIs/feeds. Which themselves are running on a trusted computing platform that is a fair and accurate representation of what is what in this world, up to a point.
That there will be a million blockchains working together in a mishmash of interconnected markets, is no more difficult than imagining a million seperate computer networks, each of which is using a private address block 10.0.0.0/24. Some things are meant to be highly distributed, some are not.
Why would you ever expect a cryptocurrency based on the thesis of high distribution to ever be a singleton itself?
Unless I'm missing something, the only advantage of it being only 600 lines of code is for educational purposes. But condensing the code in such way to reduce line count goes against such objective. Any other reason to advertise brevity in LoC?
It just happens to be 600 lines right now, and it is now functioning properly.
I am hoping that it's small size will make people less afraid to take part.
I am not trying to do it in the minimal lines possible. It just happens to be that short.
Honest suggestion: Change the tagline to "less than 1000 lines" or exclude the GUI or whatever, but don't just not include line breaks anywhere.
You have 7 very sensible, and indeed admirable, style guidelines and while no line breaks only clearly violates one of them (PEP8), it's not really in the spirit of the others either. I opened gui.py and immediately was overwhelmed, rather than compelled to dive in and digest your small codebase.
Basically unreadable. Not sure what you were going for, but I think it was the wrong thing.
Off the top of my head:
1.) There's no reason not to use newlines. They have no chance of introducing bugs in any reasonable language and they aid readability.
2.) You're using closures all over place and I haven't checked every occurrence, but I strongly suspect that almost all of them are unnecessary and unhelpful. Closures are not free in terms of code complexity. Use them only when necessary.
I am bother by the desire to get smaller and smaller. A secure implementation will have a lot of code to verify incoming data and handle exceptions.
It is fun to learn and implement HTTP server from the raw socket module (I did that once for my security project in my computer security class too), but if you are just looking for a simple server that you can handle GET and POST look into bottle.py
A single file / pip install write into setup.py and you are good to go.
This I consider as educational, which I assume is the case by the desire to go smaller and implementing such socket server.
I have to say I think crypto currencies is an area where the keep it simple approach is extremely beneficial. If it means fever optimizations, and leads to a greater dependency on off chain transactions, so be it. For genuinely wide spread adoption, more important than speed and transaction volumes, are an ironclad faith in the integrity of the underlying code itself.
It's awesome idea but..could you add comments?
(hint: you don't need to count the comments when counting lines of code :) it's normal to have more comments than code for a dense code, and it make things easier to understand )
The idea seems legit ; however trying to reduce the number of lines of code by a "no skipped lines & no comments" policy is not helping the ease of modification, which seems to be one of the target.
I find it depressing that someone puts into the work to make a cool library and 2/3rds of the comments are whining about the author using the "wrong" number of newlines and other stylistic issues.
Sadly, the core client has the job of being capable of bootstrapping itself starting at the genesis block and ending at the most recent block.
That means that, barring a huge design change in Bitcoin itself, the core client has to support every single feature ever implemented in Bitcoin, no matter how half-assed or poorly thought out.
That's why things like the way P2SH got implemented really grind my gears. Bitcoin has a few idiosyncratic and unintuitive design additions that make it really hard to make simple clients.
There has to be some place(s) online where peers register their existence, to find others to connect with.
Near as I can tell, this app doesn't have a feature for this yet. I'd argue it isn't a cryptocurrency unless there's a mechanism for finding other peers included in the code.
(That said, this is still an awesome proof of concept, and I'm going to work through all the source code carefully.)
