The world’s cheapest full node is now a Lightning Network hub — and still pretty cheap!

In the previous post we’ve built a pruned bitcoin full node running on an old Android phone. Quite some people seemed to be interested in this (thank you for your encouragement!) and so I’ve decided to keep on experimenting in this direction and pass on my learnings.

Things I’ve learned since the last post

The first thing that might need clarification is that all that stuff we’re running does actually run on the Linux that is built into the phone. Termux is really just a terminal emulator that lets us access this native Linux — but a brilliant one at that. However, the binaries for bitcoind, LND and EPS wouldn’t work directly in Termux (mostly because of a different path layout), and so I’m running them inside a pseudo-root Ubuntu environment. More about this later on.

Secondly, I learned that you should really turn off auto-updates in google play, since this kills Termux (and all the processes running there) whenever it updates the package.

Thirdly, the limitation that kept me from running a Lightning client before was that the internal flash storage only held 16GB. This isn’t just impractical for running a Lightning client (because up to now, these only work with channels where they can inspect the funding transcation — so ideally, a pruned node should have all the blocks until back when Lightning started on mainnet — early 2018), but our server also writes to disk a lot (about 10-20 GB/day — iostat is your friend), which in the long term might wreck that internal eMMC.

Micro SD cards — a modern miracle

I researched a lot about micro SD cards, and it turns out that in practice they mostly do last longer than the 250-600 write cycles that they promise. And that might be good enough for you, especially given that you could just replace them when they do give in eventually (or the blockchain gets bigger than the 400GB you bought). So you might just go for that unpruned node.

However, there are also so called High Endurance cards from all major manufacturers which cost about double from the cheapest available micro SD cards, but last up to 25 times as many write cycles. Samsung Pro Endurance promises the best values here (and the tech there seems to be 3D MLC which should last considerably longer than 3D NAND), but costs again twice as much as the competitors here in Europe (but not in the US) ATM. Sandisk High Endurance cards have actually been tried by someone in a RaspBerry Pi forum (can’t find the link right now, but they gave up trying to break it after successfully writing 70TB to a 32GB card IIRC). Kingston ones are the cheapest but I couldn’t find any decent stats on them. I went for the Transcend 350V 128GB, which promises 170TBW. That’s about 10000 days of bitcoind and LND at current levels, which is about 30 years — good enough for me. Granted, it set me back about 35 Euro, so I can’t claim my node came for free anymore. Bummer. Still the cheapest in the world, I think. Plus, I absolutely expect SD card prices to fall way faster than the blockchain grows.

Let’s get this micro marvel working

Once you got the micro SD card, shut down bitcoind and Termux (yeah, I know it sucks), insert the card, restart Termux (and sshd) and do

termux-setup-storage 

This should set up everything that’s necessary to get a nice symlink in your home directory:

~/storage/external-1 

or similar. If you’re on Android 6 or newer you might have to explicitly allow Termux the access.

Unfortunately, there is currently no way to quickly unprune a bitcoind (IMHO it shouldn’t be so hard). So I ended up re-pruning a copy (!) of an unpruned full node on my laptop again (prune=110000) and copying the blocks and chainstate directories to the card — into

.Android/data/com.termux/files/    

If you have EPS, don’t forget to also resync that and copy wallet.dat over. Then set symlinks in .bitcoin with

ln -s /storage/sdcard1/Android/data/com.termux/files/chainstate .
ln -s /storage/sdcard1/Android/data/com.termux/files/blocks .

Now before you restart bitcoind don’t forget to edit bitcoin.conf (or it’ll reprune everything again!). It should look like this:

 proxy=127.0.0.1:9050
listen=1
bind=127.0.0.1
prune=110000
dbcache=1000
zmqpubrawblock=tcp://127.0.0.1:28332
zmqpubrawtx=tcp://127.0.0.1:28333

The zmq stuff already hints at LND, which is up next. But before that, make sure everything is running smoothly by restarting

tor

and in ubuntu:

bitcoind
electrum-personal-server config.ini

Summoning Lightning

Finally, we get to deploy one of these infamous, centralized, global player banks — a Lightning Network hub! Eclair doesn’t seem to support pruned nodes and the server version would probably need a little more RAM than the alternatives anyway. I guess cLightning would have the smallest fingerprint, but AFAIK only LND implements static channel backups — a key feature that allows us to rescue funds in a channel, were our high availability hardware ever to fail. So LND it is; and again, our ubuntu-in-a-proot-jail allows us to simply download and verify the binary release. Then

tar xzvf lnd-linux-armv7-v0.6.1-beta.tar.gz
mkdir /storage/sdcard1/Android/data/com.termux/files/.lnd
ln -s /storage/sdcard1/Android/data/com.termux/files/.lnd .
lnd-linux-armv7-v0.6.1-beta/lnd --bitcoin.active --bitcoin.mainnet --bitcoin.node=bitcoind --tor.active --tor.v3 --listen=localhost --tor.streamisolation &
lnd-linux-armv7-v0.6.1-beta/lncli create

Copy the seed somewhere safe and wait for lnd to sync. Voila! It’s that simple!

Alex Bosworth gave us an elegant minimal backup solution: copy the channel.backup to the internal storage whenever it changes. Others have made more elaborate schemes including google drive, scp and many more. (Update: This step isn’t necessary anymore when you use RTL (see below). The latest version includes automatic channel backups)

A little more comfort

This is a good enough setup for CLI enthusiasts. But Ride-the-Lightning (RTL) is a nice web frontend for managing our node that can be easily added for extra comfort. Just (in Termux)

pkg install nodejs-lts

and follow the installation instructions over at RTL. I did get error messages (probably because of the node-sass dependency) during the installation, but it worked all the same.

And there you have it. A routing always-on full-node-backed Lightning node with backups and a web frontend, all for the price of a micro SD card (and an old broken phone).

Future work

Of course, this is still a kind of experimental setup. It works for me, and it can work for you, if you aren’t afraid of the command line. But there is room for improvement:

First, I’m not fully satisfied with the proot approach. It’s easiest for experimentation, but not only does it make the installation process more complex, it also has a performance cost. And with all my current setup, I have a system load of 6–9 at all times (on a 4-thread cpu). I’d really like to find out how much this can be improved by compiling proper termux binaries. It appears esotericnonsense has done work on compiling bitcoin-core in Termux years ago. So I guess it should be do-able. LND should be even easier, since it’s in go. Same thing with EPS in python.

Once this is done, running everything in a nice, simple service system like runit should be much more convenient and scalable in the long run than my manual tmux approach.

And then it doesn’t seem far-fetched to arrive at a simple script that automates the entire process. I’m not sure if making it even more one-clickable makes much sense, since this remains a server, and working on the unix command line remains the best way to work with servers that I know of.

I hope you could use some of my experiences and let me know some of yours!

June 18, 2019

Posted In: Code

Tags: , , , , , , , ,

Leave a Comment

I’ve built the world’s cheapest bitcoin node — and so can you!

It uses very little power. And it didn’t really cost anything except my time.

OK, so arguably this means it was not actually cheap at all. But it might be if we figure out how to make it easier. This guide is an attempt to start with this learning process by recording what I have learned building it.

Turning a phone into a server

I had this old smartphone lying around. Sony Xperia Z — a flagship phone from 2013 that I had bought used in 2015, broke the glass back cover by trying to replace the battery (don’t try this if you’re as clumsy as me!) and lugged around the world until the touch screen reacted less and less (it seems completely useless now) and I had to replace it in 2017. It had always bothered me that this beautiful, broken thing was useless now. So I bought a USB OTG (on-the-go) cable and connected an old-fashioned mouse to it: behold — I could use it again — if only while it wasn’t charging.

What I am trying to say here is: if you have an old phone lying around or not — you can certainly get one from ebay or whereever for basically free and there are many ways in which these things can be broken as a phone but still work perfectly fine as a server.

From Android with love

I wanted to run a full node (well, a pruned full node — more about that later), and luckily, there is a great project producing an app that does this natively on Android — ABCore. So I tried that first. Unfortunately, there isn’t much documentation there, and the process is far from painless. For starters, on my phone, the app never acknowledged that bitcoind was actually running, though it did. It slowed down the entire phone brutally. And inspecting the logs for what might be the problem was a drag — slow and riddled with strange errors — “wrong password” and such. Worst of all I couldn’t find out how to import a presynced blockchain because I couldn’t find/access the directories where ABCore stores its blockchain. So I let it sync for about 6 weeks only to notice it seemed to slow to a crawl at about 28% of the blockchain. And I couldn’t find out why! There had to be a better way!

We need a proper Linux here

Turns out there are many ways of running Linux on an Android phone — after all, Android is just a Linux variant itself. I tried and really liked Termux, because it doesn’t need a rooted phone, it seems quite mature and is itself a basis for many similar projects. It also has an API which lets you control all the fancy phone hardware — though I haven’t used that so far.

But best of all, is supports the wonderful PRoot package. Its official description is “Emulate chroot, bind mount and binfmtmisc for non-root users”. What this means, though, feels really magical to me: It gives you a pseudo root server running pretty much any linux distro you’d like — there are ready-made images available from Arch to Alpine. So I got myself a pretty standard Ubuntu root shell (rather minimal, and on armv7l, of course) — mind you, running inside Termux, inside Android, on a non-rooted Phone!

From there, it’s not such a long way to a (pruned) bitcoin full node, garnished with Tor and Electrum Personal Server.

Give me the How-To!

OK, so you need to get Termux (from the Google app store, e.g.), then in Termux install openssh and run sshd, as detailed here. You might also want to give Termux a wakelock directly from the notification it is displaying in Android. (Update: Yes, you should do that. I got System call interrupted failures from my bitcoind after a while without the wakelock) From now on, no need to touch the server anymore. Work comfortably from your laptop!

To make things even more agreeable, I have discovered Mosh (mobile shell), a fantastic tool (also available on Termux, of course) that converts your fallible ssh connection into something that is much quicker and survives any network change, putting your laptop to sleep and so on! Optional, but highly recommended!

Also optional, but highly recommended, and working perfectly in tandem with Mosh is tmux, a brilliant screen replacement that allows you to have multiple tabs open inside your ssh/mosh-session and simply reattach to this session if you ever get disconnected (even though that never happens with Mosh — but you might choose to connect from a different device — no problem).

pkg install tmux 

Using tmux properly is an art and takes some learning, so there are many introductions (even a book) available. Find your own path!

Once you’re most comfortably logged into Termux and have as many shells open and persisted as you need, you can now follow this quick howto to get an Ubuntu root shell. Now you could probably easily compile your own bitcoind, but there are even binaries available at Bitcoin Core for Arm 32bit! Just

wget https://bitcoin.org/bin/bitcoin-core-0.18.0/bitcoin-0.18.0-arm-linux-gnueabihf.tar.gz

then verify (don’t trust) as described there,

tar xzvf bitcoin-0.18.0-arm-linux-gnueabihf.tar.gz

and you are ready to run bitcoind (it’s in the bin subdirectory)! I had a problem directly wgetting from Termux, because their wget version seems not to support https. So either do it from inside Ubuntu or scp it from your laptop like me.

That’s the first milestone, your full node should be running now! It also should be running out of space pretty quickly if you haven’t used something like

bitcoind -prune=550

This is the minimum allowed pruning size. It aims at 550 MB of historical blocks, but it sometimes overshoots quite a bit. Also, and I guess that might have been the problem with my ABCore trials, I had forgotten that a pruned node does NOT just need the specified storage for the blocks it keeps, but in any case it also needs to store the entire UTXO set, which is a little over 3GB at the moment. So if you’re like me you might need to clean up your old phone a bit. Or try adding an SD card. You can find explanations for how to mount that in Termux, but I haven’t tried. (Update: I’ll say more about that in another article.)

Now that I have a full node, what can I do with it?

This would probably also be the only way to use your newly running full node for backing a Lightning client, as I originally planned to. Both clighting and LND have started supporting pruned nodes in principle, but at the moment they both only work with channels that have been opened during the time that you have non-pruned blocks for. At 550 MB, this is maybe three days. Not very useful. Adding a large SD card might help here, 128GB would probably get you beyond the Lightning advent block in early 2018. But it appears people are working on adding support for small pruned nodes as well. In keeping with my “free, as in beer” philosophy, I’ll wait until either this happens or an SD card comes my way. Update: I’ve gotten a high endurance 128GB flash card and got LND working now. More details in another writeup.

Syncing and configuring your full node is next. My phone was syncing at about 7% a day, but I was impatient, so I just synced and pruned the node I had on my laptop, and copied the blocks and chainstate directories over to the phone (after shutting down both nodes). You might have to delete any wallets that were created if you had started bitcoind before, lest the new node complains that the wallet was created too early and you have to resync. Voila — a fully synced fullnode!

How to disappear completely

I like Tor, so I tried following this guide. Interestingly, Termux includes Tor, while ubuntu needs a special repo as per the Tor project. But I’m not sure if bitcoind, running in Ubuntu, can (at least automatically) control tor running in Termux, so I tried to follow the guides in Ubuntu. It seems, however, that ubuntu does not add a tor user. Nevertheless, in the end it appears to just work. Please let me know if you have found a more elegant way to do this.

Simply do in Termux:

pkg install tor

Then edit $PREFIX/etc/tor/torrc and add (or rather uncomment) the following lines:

ControlPort 9051 
CookieAuthentication 1
CookieAuthFileGroupReadable 1

Now, edit .bitcoin/bitcoin.conf (in Ubuntu) and add these lines:

proxy=127.0.0.1:9050 
listen=1
bind=127.0.0.1

Finally, start

tor

in Termux and restart

bitcoind

in Ubuntu. That should do it. When you see something like

 tor: Got service ID XXXXXXXXXXX, advertising service XXXXXXXXXXX.onion:8333 

appear in the bitcoind logs, you know it’s working and XXXXXXXXXXX is your new public tor address.

But what is it good for?

Well, aside from strengthening the bitcoin network, a full node allows you to use wallets that are secure and private. I wouldn’t necessarily recommend running the wallet itself on the phone. It might not be the most secure (it would still be a hot wallet, on an Android phone), and it certainly isn’t pretty to use (though some people might like cli wallets).

However, Electrum offers the best of all worlds. Relatively nice UI, supports hardware wallets and multisig (yes, even multisig of multiple hardware wallets!), and can be configured to only talk to our new humble full node via Electrum Personal Server (EPS). The howto there is relatively straightforward. Unless you want to add a wallet that already has a history (isn’t brand new). That turns out to be not directly possible with a pruned node, but Chris Belcher has already noted the issue and proposed a somewhat arduous workaround: “if you have an unpruned node you could rescan the wallet on it, and then copy over the wallet.dat file to your pruned node.”. I did that, it took quite some time. Then the EPS on the phone reimported my addresses and asked for another rescan! I still don’t know exactly why, but the same thing happened on my non-pruned node when I tried to restart EPS there. The fix seems to be to just do it once again. EPS -rescan (on the non-pruned node), EPS (without -rescan, on the non-pruned node), just to make sure it works, copy wallet.dat over to phone, EPS (on the phone).

And that, ladies and gentlemen, gives you a private and secure wallet backed by the cheapest bitcoin full node in the world!

Addendum: How not to trash your flash storage

As /u/RageTester pointed out on reddit, bitcoin nodes will write to disk quite a lot (new blocks and rewriting the UTXO set), which might endanger the flash media inside the phone in the medium to long term. I’ve found advice by Pieter Wuille that increasing dbcache (in bitcoin.conf, in MB, default 300, I set it to 1000) will decrease the rate of rewriting chainstate. However, with this setup, my node still writes a lot: One can get at least an upper bound of the bytes written by watching /proc/xxxx/io where xxxx is the PID of your bitcoind process. Find it by

ps ax | grep bitcoind

This seems to easily do a few Gigamegsbyte per day, so caveat emptor! I’m not sure if the flash inside my phone does wear leveling, but even with that, it’s probably not safe to expect it to be overwritten more than a few hundred times. So if you want this thing to last longer, it would be advisable to write blocks and chainstate to a larger and more modern micro SD card. Best would be MLC/endurance products which seem to do about 3k rewrites but are also much more expensive. Or even SLC, which gets you >10k but is absurdly expensive. But normal 3DNAND with wear leveling should already last quite some time when chosen large enough. Which should also make running a Lightning node possible … I’ll let you know when I get there.

May 25, 2019

Posted In: Code

Tags:

Leave a Comment

Bitcoinprivacy is dead – long live bitcoinprivacy!

As you have probably noticed, our block explorer is gone. After many prolonged outages we have decided to take it down for the time being. We’re sorry.

Bitcoin Graph Explorer, the software behind the website, which we have been working on since 2011, has lately been ageing and rotting, and we never seemed to find the time to keep up with its decay. So we pulled the plug for now.

We have learned a lot from this project, and we’re deeply grateful that we took the time to work on it and that people have actually noticed and used our work. Priorities change, though, and it took us some years to realize we weren’t putting in the time needed to keep it running in a way we could be proud of.

Nowadays, every time we look at the code base, we notice there are so many things that we would do very differently if we were to start anew. Plus, today there are many similar projects that do what we have done, and arguably do it better.

So what is next for bitcoinprivacy? To be frank, we don’t know yet. We might just use it as a blog for now. We might try and use a different backend to get the explorer back online. We might come up with a brand new idea.

What is next for Bitcoin Graph Explorer? As they say, we are handing it over to the community. We have no plans to keep maintaining it at the moment, but you are free to take it and build on it, as you always have been.

What is next for us? As Satoshi said we’ve moved on to other things. But don’t worry, we’re still adding our little efforts to the greatest project of our time, Bitcoin.

So long and thanks for all the fish …

February 14, 2019

Posted In: News

Tags: , , ,

Leave a Comment

We’re back online, sorry for the downtime – Here’s why it took so long

After Jorge had dockerized the entire platform and it had been running for a few months, I noticed some dubious stats that didn’t make sense (more wallets than addresses with positive balance, some wallets with a negative balance). I guess our updateBalanceTables code is still not perfect. This is really hard to get right, because it directly works with the databases in order to avoid having to recalculate all the balances every block (which takes about half an hour nowadays!), and there are quite some edge cases. I was actually thinking about rewriting this part in Haskell, but now I’m not sure if BGE is still worth investing so much time in, with alternatives like BlockSci proliferating.

Anyway, unfortunately while trying to debug I noticed an unwanted side effect of docker: the common way of killing docker containers is absolutely brutal and even though we had already spent considerable time making BGE pretty much safe to kill in any state, this brutality was just too much: our databases became corrupted.

That’s a pity because rebuilding everything from scratch takes a few days ATM with the blockchain growing and growing. But what’s really frustrating is when you have just waited 3 days for FastBlockReader to finish and then an assert throws an exception, because somehow some blocks are missing!

Now Jorge had similar issues in the winter when dockerizing and switching servers, and the culprit seems to be somewhere between bitcoind and bitcoinJ. BitcoinJ’s master version is still not being segwit compatible, forcing us to use a rather unmaintained segwit branch. In addition, our assumption that it was safe to use bitcoind’s on-disk block files through a bitcoinJ loader seems to have been unwarranted. We’re still not sure why, but for now the only way to avoid this problem was bootstrapping with the PeerSource giving us the blocks one by one over the internal network. This process takes a bit longer, more like 5 days ATM.

So we really ought to implement saner process killing in our docker containers, completely rewrite BGE in a microservice architecture and finally get away from BitcoinJ. Or just try BlockSci. Which is a little hard as long as our systems are running, because it needs 50G RAM 😉 What do you think?

May 2, 2018

Posted In: Code

Tags: , , ,

Leave a Comment

Notes on the Bitcoin wealth distribution

We have received a few inquiries about the distribution of Bitcoin wealth as implied by our stats and richlist pages. Our site has also been used by some media outlets as a source for this kind of statistics. See, e.g. https://howmuch.net/articles/bitcoin-wealth-distribution.

We feel that we ought to give some qualifications about this kind of claim. Statistics about the distribution of bitcoin in addresses, or even in the kind of partial wallets we infer, are probably very misleading about the actual wealth distribution, because addresses are not people! This goes both ways: Neither do people just own one address (Most active bitcoin users would own at least hundreds and when they have been using best practices we do not associate these addresses as partial wallets), nor does every address just belong to one person (Consider the richest addresses, which are mostly exchange addresses. These can stand for millions of people!). Andreas has explained this most clearly here:

Before watching this video, I had always somehow assumed that the distribution in addresses can be used as an approximation of the true wealth distribution. But in fact this is highly dubious. Any given distribution (or Gini coefficient) on addresses could easily be transformed into an arbitrary wealth distribution by grouping or splitting addresses: Consider the edge cases where every address belongs to the same person or every address is shared by all users.

Jorge brought up an interesting view on this: The distribution we are measuring is really just the distribution of UTXO values, which could be seen analogously to banknote denominations in traditional money!

As an example, I tried calculating the Gini coefficient for the British Pound denominations given here. If my calculations (pen and paper!) are correct, it’s about 0.2654320. However, should this be read as an indication that British wealth is very evenly distributed? Hardly! It just means that their banknotes values don’t differ across multiple orders of magnitude.

Unlike the Bitcoin UTXO set, which clearly does. There are millions of outputs with just a few satoshis in them, as well as a few that have more than 100,000 BTC, which is about 10 trillion times as much! However, Bitcoin’s Gini coefficient means just that. Outputs vary very widely in value. This does NOT imply anything about the wealth distribution of Bitcoin hodlers.

Personally, the true wealth distribution remains an interesting question for me. In fact, it was what made me start this project. So how could we find more valid approximations? Well, exchanges might have a pretty good idea. Or web wallets. Have any of them published any statistics? Has the Mt.Gox leaked data been analyzed in this direction? If not, then maybe it’s time to do so!

 

April 27, 2018

Posted In: Uncategorized

Tags: , , , , ,

Leave a Comment

Charts with the BGE-API and dimplejs

Finally it is out! For almost two months we promised it. Due to some open issues in the real life, it was not easy to find spare time to work on it, but finally it is done!

We are proud to present you the first examples of charts using Bitcoin-Graph-Explorer API and dimple.js. Dimple is a Library that uses d3 and exposes a simplified usage of d3.

First of all we need to include d3 and dimple in our page, and jquery for simplicity of the ajax calls:

<script src="https://ajax.googleapis.com/ajax/libs/jquery/3.1.1/jquery.min.js">
<script src="http://d3js.org/d3.v3.min.js"/>
<script src="http://dimplejs.org/dist/dimple.v2.1.6.min.js"/>

With all that included, now we can start using the BGE server:

Continue reading Charts with the BGE-API and dimplejs

November 30, 2016

Posted In: Code

Leave a Comment

Bitcoin Graph Explorer 3.1 is here

As you probably know, our site is based on — and actually a kind of demo site for — our own blockchain analysis server Bitcoin Graph Explorer (BGE). The source code for this has always been available, but to be honest it would have been hard for anyone but us (well, including us) to actually use it.

So we have spent a few weeks thinking about how we could make the code more accessible, adding such niceties as a license, Readme, wrapper scripts, nix packages … in short, we are proud to be finally able to really tell you that Bitcoin Graph Explorer is open source software that we invite you to try out, use and improve with us.

This also means you have less excuses for trusting our website with your data when you don’t want to. Just run your own copy of BGE! Admittedly, it still requires some commitment: Storing and analysing the blockchain takes a lot of memory and time. Blockchains come with a cost, you know. We recommend at least a 512GB SSD (the DB takes about 300G at the moment and grows quickly at about triple the rate of the pure bitcoind blockchain). Populating the DB takes about a day on our server. On a hard disk, that is probably more like a week. You should, however, be able to work with relatively little RAM since we have rebuilt BGE to replace RAM with LMDB where possible.

To summarize, there are now at least three options of using BGE: Directly on bitcoinprivacy.net, the public API (blog post forthcoming, overview in the github readme) at http://api.bitcoinprivacy.net, and on your own server (preferably via the API though you could also work with the DB directly). We hope you find this useful for your bitcoin projects.

September 26, 2016

Posted In: Code, News

Tags:

Leave a Comment

Site update 2016

It’s been more than a year since our last update. A lot has changed in this year, although bitcoinprivacy still looks kind of the same. We have focused a lot on making Bitcoin Graph Explorer more stable and more accessible, so other people can enjoy it as well. We are still writing READMEs and comparing licenses, but BGE 3.0 should be out any minute now. OK, within a month. Really. We will let you know here.

But you might have noticed that the site itself has changed a little, as well. The big one is that we are now reading blocks (and rolling them back if they become orphaned out) in real time, as they appear on the network. So you can use bitcoinprivacy as an almost up-to-the-minute (it might be two minutes behind) block explorer and check what the transaction you just pushed has done to your privacy.

Then there have been lots of changes in the background, and we intend to write a series of more technical posts to share our experiences as, for example, we have switched from mysql to postgres.

And then there’s the API. You can reach it at http://api.bitcoinprivacy.net and use it to build your own blockchain intelligence services even if you don’t want to run BGE yourself (I mean, of course you should, but then not everybody has a spare 300G — and growing quickly — SSD server). Jorge is busy writing a tutorial that explains what it can do, so expect that in the coming weeks, as well.

But in the mean time, enjoy bitcoinprivacy.net, stable and feature complete as never before (we hope!).

 

 

August 28, 2016

Posted In: News

Leave a Comment

Look, BitcoinPrivacy is all shiny and new!

OK, so it may have appeared that we didn’t put much work in lately, what with no visible changes and no database updates for weeks. We’re sorry, but the truth is, EVERYTHING has changed in the meantime, and we could hardly keep up with all the work that was necessary to make these changes.

So we are very proud today to present the new bitcoinprivacy.net! Please, check it out! The major new feature is the built-in blockchain explorer – no more links to blockchain.info! But aside from that …

Not only does the site look nicer (bootstrap 3), but it is much more scalable, performant, safe and extensible, because we rewrote the entire thing in Play! framework with Scala. This will make it much easier to add new features.

We also felt we outgrew sqlite, so we changed to mysql, which caused us major headaches along the way.

And finally we have been on a new server for a while. This was intended to make development easier, but has uncovered lots of little problems that needed to be addressed. Addressed they have been, and we have learned a lot that should help us make BitcoinPrivacy even nicer even faster.

We hope you enjoy the new BitcoinPrivacy and give us some feedback!

May 19, 2015

Posted In: News

Leave a Comment

Stop by and see all the beautiful new features!

bitcoinprivacy.net has seen another few rounds of improvements: we now have (mandatory) https (with a real certificate), the top 100 are now top 1000, a few new stats, and an entire new page:

Distribution of Bitcoin wealth: bitcoinprivacy.net/index.php/distribution.html – not only can you play and find out how many addresses own more than X Bitcoin, and how much of the total bitcoins this is: e.g., there are 311285 addresses with more than 1 bitcoin, totalling 13621839 bitcoins, 98.56% of all bitcoins. Did you know?

We also have finally implemented the one statistic that inspired me to start this project years ago: Gini coefficient (for addresses and for closures, too). Not surprisingly, it is astronomically high at about 0.98, even when capped at the dust limit of 546 satoshi.

All of these fine numbers continually updated about 1 hour behind the blockchain, of course. Enjoy!

February 10, 2015

Posted In: News

Leave a Comment