HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
bcoin-org
bcoin
JavaScript2014–2021
bcoin-org / bcoin

bcoin

Javascript bitcoin library for node.js and browsers

7Distinct people
9Mentions
0Explicit recommenders
3.1KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Javascript bitcoin library for node.js and browsers

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year9 dated mentions

Observed mentions: 2014-12-23 20:52:51 UTC to 2021-11-16 01:42:03 UTC.

01232014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20142015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 3 mentions; 2 submissions, 1 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments20172018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2021

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC101
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC000
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC321
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC202
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC000
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC101
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC101
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC101

What Hacker News says

9 sources
My first bitcoin reimplementation was written in node.js and called bcoin[1]. So this is my second time reimplementing the bitcoin protocol, albeit in a very different language. Bcoin was frequently used as a reference along with bitcoin core v0.8.0-v0.11.0 when I felt like double checking consensus functions (among other things). As an aside, I personally think bitcoin core v0.8.0 is the best version of core if you want to learn bitcoin from it. It's a lot more straightforward than later versions. I personally don't enjoy reading any version beyond v0.11.0. This is also the reason mako doesn't support taproot yet. That code is very new and isn't present in upstream bcoin. I could try to implement it from the BIPs alone, but I won't know what intricacies are present in the actual bitcoin core code until I actually read it. [1] https://git
Read the rest
In Show HN: Mako – a full Bitcoin implementation in C
This is great. I especially like that it follows the protocol's implementation for the most part. i.e. you still have utxos and script verification even if it doesn't actually support the array of script op codes. There is a fully compatible JavaScript implementation that you could use as reference to extend yours: https://github.com/bcoin-org/bcoin With my post, I tried to boil down the concepts as much as possible to save some mental bandwidth and make understanding the overall easier. We will see how that turns out
In Bitcoin From Scratch – Part 1
> Is there a good overview of the types of wallets, their architecture and evolution? A wallet is a userland abstraction where it groups together all of your keypairs. With each keypair (ECDSA) you have a public and private key. The address is derived from a hash and encoding of the public key. The private key is used to sign a script that unlocks the transaction outputs you have access to. For this reason, your balance is also a userland abstraction. A balance is the sum of all the outputs you have the ability to unlock by signing the input. Whats important to understand about transactions is that you need to spend the entire input. If you have 10 coin sitting in an output and want to send 7 to someone, you need to structure the transaction so that the 3 change goes back to you as well The way fees work is that the miner picks up any dif
Read the rest
ference between the outputs and the input, for ex. 10 input => output 1 = 7btc to address1 (recipient) => output 2 = 2.9btc to address2 (change) => diff 0.1 btc transaction fee You now have a balance of 0 in your input address, and you're left with 2.9btc in your change address which will become the input on your next transaction There is no reason why the change address cannot be the same as the input, but it means a loss of privacy since you can then see the 2.9 btc was change, thus output1 was the recipient, and you link the future transaction back to yourself as well. If you then want to send 11 coin to someone, you can combine other inputs: 2.9btc input => output 1 = 11btc to address3 (recipient) 10btc input => output 2 = 1.89btc to address4 (change) => diff 0.1 btc transaction fee This is how wallet identification works as described in the OP - you can assume that any inputs shared in a transaction are from the same owner since they were signed together. If you parse the blockchain and continue grouping common inputs like that you end up with a graph of wallets. Sometimes it only requires a single transaction to group together entire clusters - especially if you're using wallet software that selects inputs to use in sequence, doesn't create change correctly, or if you sweep all your smaller and smaller inputs into an aggregate address What the original wallets did, and what OP explains, is they would pre-generate the next 100 keypairs and add them to the end of the list, and with each transaction that requires change it would move the pointer for next change address up one All of your addresses start as either receive addresses, or as change addresses, and end up becoming your balance addresses until they are spent To backup these wallets you had to backup every key pair, which is why most modern wallets use deterministic keys usually derived from a mneumonic. HD wallets use a master key pair, where the private key is usually derived from a mneumonic. That key pair is then used to generate the key chains that are used as receive and change addresses. It means you only need to backup your master keypair or your master mnemonic and can then generate and check all the key chains The new wallet format is defined in bip32 [0] while the mnemonic to generate seeds is defined in bip39[1] - which you can test using a browser client app[2] (don't store coin using these - generate them securely) Most wallets now support these deterministic wallets, including bitcoin core The three main wallet types are full node, thin node (SPV) or web wallet You can run a full node with Bitcoin Core[3] or Bcoin[4] (a Javascript implementation) - both support pruning the blockchain at a specified block height The most popular SPV clients are Electrum[5] cross-platform, breadwallet for ios/android[6]. SPV uses block headers and peer queries (sometimes using bloom filters for privacy) to query your unspent transaction outputs and to verify transactions (there are variations of the architecture). The bcoin project also allows you to run an SPV client in the browser or via node (i'm really starting to like this project - they were the first to implement p2p authentication and encryption which is specified in bip150/bip151) Electrum supports Trezor and hardware wallets, multisig wallets, 2FA wallets and have their own mnumonic and deterministic wallet format (but it also just involves saving a seed for the master key) Web wallets store your wallet (usually) encrypted on their server and then unpack and decrypt in your browser client, then making HTTP API queries to verify transactions, get your unspents, broadcast transactions etc. The most popular are Blockchain.info[7] (disclaimer: I worked for them) and GreenAddress[8] - you can use blockchain.info via a tor hidden service at blockchainbdgpzk.onion Good ways of getting started if you're more interested in the tech is Electrum (web wallets tend to obfusacte a lot of what is going on to make them easy to use), a full node with Bitcoin Core or running bcoin - and running them on testnet so you can build and broadcast your own transactions without fear of losing funds (the scripting language has also evolved a lot). The other Javascript lib you can use to create transactions is bitcoinjs-lib[9] - there are libs available for deterministic wallets and some good transaction/script abstractions. [0] https://github.com/bitcoin/bips/blob/master/bip-0032.mediawi... [1] https://github.com/bitcoin/bips/blob/master/bip-0039.mediawi... [2] https://iancoleman.github.io/bip39/ [3] https://bitcoincore.org/ [4] https://github.com/bcoin-org/bcoin [5] https://electrum.org/ [6] https://breadwallet.com/ [7] https://blockchain.info/wallet/#/home [8] https://greenaddress.it/en/ [9] https://github.com/bitcoinjs/bitcoinjs-lib
In How the Bitcoins Were Stolen from Mt. Gox [video]
The project itself an alternative bitcoin full node, one of the few (along with btcd, bitcoinj, etc), and the only one that runs in the browser: http://bcoin.io/browser.html. I've posted it here before but no one seemed to be interested. It's probably not good if you want to index anything more than addresses, but you could easily modify it to index other things if you wanted to. The actual blockchain database resides here: https://github.com/bcoin-org/bcoin/blob/coinviews5/lib/bcoin... ^ That's the current branch I'm working on which, as it happens, optimizes a lot of the storage of utxos. Before, it was storing them the messy bitcoinj way. Now it uses coin viewpoints similar to bitcoind and btcd.
In We’re pretty happy with SQLite and not urgently interested in a fancier DBMS
It's an exciting time to be a JavaScript developer for Bitcoin. There are a number of JavaScript libraries for Bitcoin. Here is a comprehensive list of alternatives to Bitcore: - https://github.com/bitcoinjs/bitcoinjs-lib (one of the best) - https://github.com/indutny/bcoin (Indutny's work is found throughout Node.js and is the basis of elliptic curve cryptography in Bitcore) - https://github.com/ryanxcharles/fullnode (ex-developer of Bitcore and now engineer at Reddit behind Reddit's crypto currency initiative) - http://cryptocoinjs.com/ (disclosure: I started this one) Here is an older article that I wrote about understanding how an Address is created (still valid, but using an older version of bitcoinjs-lib): http://procbits.com/2013/08/27/generating-a-bitcoin-address-... The cool thing is that you can use test Bitcoins without any ris
Read the rest
k to learn how to program for Bitcoin. Use these faucets: http://tpfaucet.appspot.com/ and http://faucet.xeno-genesis.com/ Here is a very simple wallet that I built to demonstrate how easy it is to build one: https://github.com/coinbolt/simple-wallet Finally, an open source app to test the purchasing experience of Bitcoin: https://github.com/coinbolt/catshop
In Bitcore – A pure JavaScript Bitcoin API

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.