BitPay introduces Bitcore
bitcore.io
bitcore.io
The bitcoin daemon, bitcoind, handles the protocol for you and can run as a headless server. It has a simple JSON-RPC protocol that you can use to create wallets, send and receive transactions, etc. You could write your own client for it in any language quite easily, and for most languages, there's an OS implementation already.
https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_Calls...
In fact, I'd argue that running a cluster of bitcoind servers is probably a better approach, due to separation of concerns. Also, I'd guess that the C++-based and widely used bitcoind is probably faster and more stable than this node-based implementation. Not to knock this project - it's just going to difficult to compete.
The bitcoind rpc interface exposes blockchain information about your local wallet and addresses you own only.
So it is great for that. However, let's say you wanted to do something like have the user input their bitcoin address into an input and you returned the balance or a history of transactions from that address. You couldn't actually do that unless you also got and imported the user's private key (effectively giving you control of it).
blockchain.info and similar services use custom code to do that stuff.
I personally recommend either SX (see http://github.com/vbuterin/node-sx for an HTTP pass through server, and I have one running at http://multisig.info:3001) or if you are okay with centralization then plain old blockchain.info.
The reason bitcoind doesn't provide the feature you're after is because it's not actually possible to tie an address to a comprehensive set of transactions.
Addresses are hashes of public keys... public keys which may or may not have been used in isolation, or in one of several common conventions, to make a transaction. Only a particular implementation programmed to parse a predetermined set of transaction script types can actually determine what subset of transaction outputs are spendable, and what consistutes your wallets balance. The protocol itself has no concept of wallets or balances
The things you can do with Bitcoind in real time that are not suicidal to do on a server are very limited.
Is it easier to implement a dynamic cold storage system for wallets without bitcoind?
We need more implementations that interact with the blockchain that work at scale. However, this Bitcore just seems to sit on top of bitcoind, making it not very interesting imho [1]
It is designed to run server side on node.js or client
side in a web browser and interect with a trusted bitcoin
node (i.e. a bitcoind instance)
There's an example of using getData on the transaction hashes inside "inv" (inventory) messages. it works, but you get hex public keys. So remember to use version bytes of 30 (decimal integer) to a base58check encoding function, to get the dogecoin addresses that begin with "D". Well, at least the output addresses are easy enough. I'm still having trouble parsing the input addresses.
[edit] here's the getData example: https://github.com/cryptocoinjs/btc-p2p/blob/master/examples...
It is designed to run server side on node.js or client side in a web browser
and interect with a trusted bitcoin node (i.e. a bitcoind instance)
Javascript: the new native.
I can't think of any technical, risk-related, or financial justification for implementing a core piece of crypto-currency infrastructure in Javascript, on Node.
It seems fairly clear that while Bitcoin itself may be a very well designed crypto protocol, the people doing the implementation are woefully underqualified.
You don't get static typing with nodejs, but you can probably simplify the implementation somewhat by not dealing with low level details and therefore actually get some safety. But aside form that justification there is also the fact that a lot of people won't touch C++ and a code base like this allows a lot more developers to read and understand the protocol.
I guess the ideal implementation would be a modern statically typed language like Rust, Go, or Haskell.
So kudos to Satoshi whoever he is for this..
How similar is this to Electrum?
Is there more doc ? This could be interesting.
In theory they should provide a "TryValidate" or similar but it doesn't look like they do at the moment.
Consider that, in strongly types languages, things go wrong anyway. Once an officer aboard a U.S. Navy capital ship entered a zero into a program, the zero caused a divide-by-zero error, and the error propagated through the ship's network and disabled the entire system. The ship had to be towed back to port. So much for strong typing.
http://en.wikipedia.org/wiki/USS_Yorktown_(CG-48)#Smart_ship...
Quote: "On 21 September 1997, while on maneuvers off the coast of Cape Charles, Virginia, a crew member entered a zero into a database field causing an attempted division by zero in the ship's Remote Data Base Manager, resulting in a buffer overflow which brought down all the machines on the network, causing the ship's propulsion system to fail."
How did you arrive at that conclusion? How, exactly, is it "fully understood by its creators"? How do you know that it's "thoroughly tested"?
Type systems allow one to assert these ideas declaratively and provably, and depending on the type system, more or less of the design can be asserted.
> Consider that, in strongly types languages, things go wrong anyway ...
That's not an argument against strong typing, that's an argument against your understanding of type systems.
On top of which, you've deployed an illogical assertion: that because things anecdotally CAN go wrong with what you presume was a type-safe language, the failure rate is EQUIVALENT to a non-typesafe language.
That doesn't make any sense.
Here's what I said: "If the software is fully understood by its creators, and if it has been thoroughly tested, there's no reason to doubt its reliability."
Read it again. Note the word "if" repeated twice.
> On top of which, you've deployed an illogical assertion: that because things anecdotally CAN go wrong with what you presume was a type-safe language, the failure rate is EQUIVALENT to a non-typesafe language.
As is often the case in Internet debates, you have invented a position I have never taken to argue with (a "straw man"). I don't have to defend a position I've never taken.
> That doesn't make any sense.
So? It's your opinion, not mine. You defend it.
> That's not an argument against strong typing, that's an argument against your understanding of type systems.
"My understanding?" Was I present on the Navy capital ship that lost its way after a zero was entered into a strongly typed software system? Did I write the code? No to both.
I understand typed systems perfectly well, and they're sometimes helpful in avoiding problems. But the reliability difference between typed and untyped schemes is overrated.
So you predicted what their documentation says on the homepage?