Why doesn't Ethereum use Javascript for it's "high level language", since it's easy as hell to write and there are plenty of fast javascript parsers out there?

SkUDfLxWJYhbgGLV9Xm3yu2KZj93uGYRKA

the faucet never works, either it's "invalid request" or "Node is offline, no requests can be made at this time. Please try again later."

You are missing tests for transaction.js, script.js and wallet.js and not taking in consideration third party modules (like jsbn and crypto-js).

You got some defined functions that arent being used (therefore tested if working), for example in index.js, rotl, rotr and endian.

You need to make tests cover exceptions being thrown (haven't found any in any file). since you are using qunit, assert.throws should do it.

On the derive of HDWallet, you are checking for this.priv, but the pub is not being covered (in case priv is false).

None of the base64 functions from convert.js are being covered.

This is what I got so far.

Btw, you should enable issues in your repo (since when you fork on github, it's not enabled by default)

hey flangefrog, no idea, didn't even knew the existance of that repo. seems pretty new (first commit 21 days ago), so I'll check it out and report back

EDIT: It is a full fledged stratum pool, instead of stratum server and client module (my library have no pool funcionality whatsoever, its up to the developer to implement them). "stratum-pool" is more of a framework that is focused on building work to deliver to miners. although there are no tests or test coverage data for that library yet.

With my library, you can build pools, proxies, network endpoints for miners, etc, and implement in other types of libraries/frameworks, that aim to provide stratum support along with other functionalities, like a web interface, or other protocols, like X-Pushthrough. And I take stability and code congruence really seriously, along with tests and code coverage.

just updated it, when I have more spare time, I'll make 100% test coverage, only 2 parts to go.

I was just going to post about this... what can be done? I don't have an ASIC and need to use testnet using a CPU for testing purposes, but having to wait 10 minutes for the test to accomplish is a pain.

I'm speechless... the DOT / COMMA problem is really an issue (like being discussed in another thread)

Exactly my point. If you already have trust in the coder behind the binary, how trusting his auto update hurt you more than installing manually?

All 'alt coins' fork from Bitcoin-QT, not multibit. And it's not a matter of recommendation. Bitcoin-qt is also available in bitcoin.org. And even if the majority of users use multibit (which I'm not sure unless numbers are brought up), it doesn't have a 'check new version' as well, and serious 0day exploits can lead to losing wallets, coins, address collision attacks, etc

gitian is an answer for people that know what they are doing (aka developers, system administrators, etc), that most of users of bitcoin-qt/daemon aren't. they download binaries from a link. unless it's implemented in the client itself, which I think would be overkill, they will just click a link and download. Plus, if you get this gist https://gist.github.com/devrandom/806265 it still uses sourceforge as a source, so it defeats the purpose anyway.


Well, you just contradicted yourself.

Right, the auto update / push feature "vulnerability" makes sense now, even though, by downloading it, you are already trusting a binary and/or source code, otherwise Bitcoin wouldn't exist, if there was no trust for the first place, no one would ever use it, so it's not introducing a "vulnerability" per se, if you already installed it, you have made a conscious choice for trusting it.
But since the client would be using only official repos (as most coins are using), and the binaries are downloaded from the same place, doesn't it make sense to have the check for a changelog or news about versions of it, like the recent changes that had vulnerabitilies fixed? this way people would decide whether to download or install it by themselves. Like it or not, even being open source, the source is already centralized either on github or sourceforge, if you want to see it that way.

And even further, only conscious users check the MD5 signature of binaries when downloading them, or decide to build from the source themselves, which is the minority, but most non-techie users don't.

Another thing, right now, it's not always possible use the bleeding edge compiled version of bitcoin-qt for testing purposes, because would be a hassle for core developers to keep with nightlies. Of course, reading git status is simple (with their public API), if the client makes this check on-demand by the user, it can be possible, or after a big commit that changes the inner workings a lot, like Firefox Aurora. You are mistaking a decentralized NETWORK (that Bitcoin is and will always be) with a centralized distribution of binaries, thats a formal fallacy that it will always be decentralized.

where do you get your client btw? isn't from the same place you get the source? your comment makes no sense

We are in 2013, in the era of "browser apps" and self updating software, and all coins, even though coded in C++, have no reason to not have an auto update / push update feature for critical bugs / exploits / etc. How many people get stuck and clueless about new versions, since the Qt client have no "check for new version" button, unless they check the forums? It's understandable, for a pool owner, to not have auto updating software because it can break everything, so it could be disabled. But for the end user, there's no excuse.

Coin developers should try to get to a consensus and implement a simple hash version checking against the tags on github / sourceforge for example, at least to warn users about new versions (and even a distributed changelog / news about the new version, take a look at Filezilla that is open source)

Imagine having 16 coin clients installed on the computer, and manually having to check for new versions for each one? An auto-update makes sense doesn't it?

if you want a faster confirmation, just up your fee. simple as that (even though you now have 41 confirmations).

the only thing that I haven't actually tried is that if the underlaying database used in bitcoind / bitcoin-qt has some sort of locking. if 2 or more daemons are connected to the network, they will (expected) receive the same info from the network, and try to work the same data to the database, right?

there are cross platform solutions that can be wired to a command line or HTML/javascript frontend, that are made in python, node.js, PHP, etc. I myself, created a RPC library that got a client interface https://github.com/pocesar/node-jsonrpc2 so you can easily couple this with, for example, Express.js, and create a browser client for this.

you can change your rpcport in bitcoin.conf to any other port you'd like to use (that's the easiest part that I can tell from your problem).

yes, using the RPC interface, there are a couple of RPC clients and libraries that can do this communication. Bear in mind that opening a remote daemon to the internet is a very risky thing to do. Unless you use SSL and a really strong password, and take all the necessary measures to avoid having your wallet/funds stolen.

I'm trying to figure out a way to reuse existing blockchain database to multiple spot instances, so I don't have to download the blockchain per each spot instance everytime they go up on auto scaling on AWS. The thing is, datadir needs a disk path, how could I create a on-demand instance to keep the blockchain so each spot instance can take advantage with the lastest blockchain? would many daemons writing to the same blockchain database be a problem?

like so:

Worked a bit on the project on this weekend, after a long pause working on it because of work