The Readme says insight requires a running bitcoind to communicate to over RPC, does bitcore require the same? or is bitcore like a reimplementation of bitcoind?
Absolutely. Most of what the Bitcoin reference client supports is possible, including the signing and transmitting of transactions. Multiple signature transactions are also supported, something that the reference client does not yet include.
BitPay is focused on Bitcoin, but Bitcore itself is agnostic as to which blockchain is utilized. We'll gladly review pull requests increasing the utility of this as a tool for cryptofinance in general.
Yes, please! That would be great. Personally, I don't download or use anything with Bitcoin that isn't signed by a reputable party, or else I audit the entire codebase.
I find that really strange as well. I haven't seen a Node library that uses exceptions for flow control before this, I wonder why they decided to start here.
Shameless plug: https://github.com/cryptocoinjs (Bitcoin JavaScript fork of the original BitcoinJS) Right now, we're focused on Bitcoin, but we're moving fast and will be expanding support for altcoins. Also, if you're interested in the intricacies of addresses and Bitcoin, I'd encourage to read a very detailed article that I wrote on Bitcoin Addresses and JavaScript: http://procbits.com/2013/08/27/generating-a-bitcoin-address-... Doesn't use CryptoCoinJS yet as the article was written before I started CryptoCoinJS.
Among other things, pg and anyone with physical access to the HN server should have the capability to determine which users voted on a given comment, since the server needs to store that so it knows to not let you vote twice.
I was actually experimenting yesterday with cryptocoinjs on dogecoin. It works with very few changes, if you find and change a few options/constants among the various modules (mainly btc-p2p and p2p-node), eg by modifying the installed packages in your ~/node_modules directory. The port needs to be 22556, the DNS seed to seed.dogecoin.com, and the "magic bytes" to 0xC0C0C0C0.
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.
Really the only difference between "altcoins" and Bitcoin is the version number in the address, often not even that. "Support" isn't so much needed as incidentally created. Minor fiddling with the POW (often breaking core functionality in the process) doesn't affect things like transaction creation and address validation.
Depends. This is mostly true, but there's also things like Ripple, Mastercoin, and even Dogecoin that have reasonably significant differences from the other 'tweaked some parameters' altcoins.
Dogecoin has no significant changes. The coinbase value is detirministic, the POW is altered slightly and some other values are changed. Nothing interfacing with it needs alterations, other than things with validate blocks and so forth.
node-bitcoin is just an interface to bitcoind, so you also need to run bitcoind. bitcoinjs, cryptocoinjs, (and now bitcore) are stand-alone javascript implementations which replace bitcoind.
This is great. It looks like there is already functionality to connect to peers and send and receive transactions. Is there any functionality to store and query the blockchain as well?
If there was a list of a use cases for typed, "safer" languages, crypto-currency would be near the top of the list.
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.
I think part of the reason you might see some bugs in the Bitcoin code is because it is C++ code managing low level things like memory and threading.
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.
C++ is not for scared kids.. C++ is the katana of programming languages: powerful, but you must know how to use it to avoid cut yourself.. and i think the bitcoin core in c++ is being implemented in other softwares as well.. and im pretty sure that this is happening BECAUSE it was created in C++ (only C could also be a fit here)
Quick note to anyone looking to build bitcoin-based apps - although something like this is probably useful for some applications, you don't actually need a complicated bitcoin client library to interface with the blockchain.
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.
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.
Yes but with the caveat that what you can do is limited.
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.
The node/js implementations provide a stream interface to bitcoin, for watching transactions live and doing real-time updates. Its very difficult to do that with the bitcoind API because it is only polling functions. Whereas push/event-based handlers and filters are natural on a node implementation (eg watch all new transactions for a particular bitcoin address, how to do that using bitcoind, without long polling?).
IMO, bitcoind is a terrible idea. The huge deal-breaking problem with bitcoind is that it provides no way to query for transactions associated with a specific address unless you import that address into the client and give it the private key. This severely restricts your freedom to do your own wallet management, and compromuses security if you want to have many Bitcoin nodes on many semi-secure servers for redundancy.
> The huge deal-breaking problem with bitcoind is that it provides no way to query for transactions associated with a specific address unless you import that address into the client and give it the private key.
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
I don't understand how this problem might manifest in the real world. Can you give any examples of transactions that could not be recognized without the associated private key?
That's not a problem in practice; if you give someone an address and they use it to pay with any conforming client, the resulting transaction will conform to one predictable, easily parsed format. Yes, there are numerous other transaction types possible with the same underlying public key, but they are represented by different addresses in all cases.
That sounds like one of those "serious in theory, trivial in practice" problems. Like it or not, there ARE only 3 types of standard transactions, and even the network-level protocol recognizes this. Each of them has a specific address convention.
This is why so many people (used to?) get stolen their hot wallets. This was the bog standard way of doing things in the Bitcoin world up to mid-2012 or so.
The things you can do with Bitcoind in real time that are not suicidal to do on a server are very limited.
bitcoind is not designed to scale at all. Just look at the transaction malleability issue that has been terrorizing the exchanges. This has to do with them writing shitty wallet software to overcome bitcoind's limitations.
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)
That depends. If the software is fully understood by its creators, and if it has been thoroughly tested, there's no reason to doubt its reliability.
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.
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."
> That depends. If the software is fully understood by its creators, and if it has been thoroughly tested, there's no reason to doubt its reliability.
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.
> How, exactly, is it "fully understood by its creators"? How do you know that it's "thoroughly tested"?
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.
I'm torn between "The record for bug-free C or Java code are not exactly inspiring" and "Wait wait wait in a system with Bitcoin and Javascript you think Javascript is the probable source of problems?"
My question implicitly defined the scope of the conversation to be programming languages. I like how you broke out of that, and pointed out that Bitcoin might have bigger problems that need to be tackled first. Every time I try to think about how to solve Bitcoin's problems, I return to the traditional banking paradigm: you pay someone else to take the risks of managing the money, and they will thus reimburse you if something bad happens.
80 comments
[ 1.4 ms ] story [ 145 ms ] threadHow 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.
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...
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..
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]
1. http://blog.bitpay.com/2014/02/14/introducing-bitcore.htmlConsider 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?