Some Quick Meta-Qntra Updates

  1. On November 12th Qntra ceased to utilize Quantcast's services for determining an approximate visitor count, for reason relating to Quantcast's interface "going retarded."
  2. Qntra has been back online for a few days now after several days of downtime.
  3. Frontend and backend improvements continue. It is a distinct point of pride that Qntra is ready to take Bitcoin news to the GPRS internet connection of Africa and the rest of the under served world.

Qntra Style and Draft Content Guide

Please see:

Now that Qntra has just a bit more than a year's worth of content behind it and processed a number of submissions, there's a more solid idea of just what Qntra is about. This guide is going to cover two subjects: the formatting of submissions and the content of submissions. The guidelines for formatting submissions are open to comment and effective immediately. The content guidelines are open for comment and will go into effect after there has been time for the dragons of #bitcoin-assets to mull them over. Continue reading

Notes on Building Bitcoin-qt on OpenBSD

This week I embarked on the experiment of seeing how much Bitcoin client you can build on OpenBSD. I might as well use this space to consolidate the mental notes on the process I used. Some particular details have likely slipped my mind already, so consider this an abridged guide. The version I ended up building with this process was 0.7.2, it builds fine with or without upnp support and with or without QR code support. Going earlier in version to 0.5.3 or the 0.6 series should be fine too, you just might have to make some different changes in the source and flags.

Building any later version which uses leveldb for blockchain storage might not be possible on OpenBSD. The Bitcoin source tarball for later versions includes its own leveldb source and hammering that into a shape that will compile into something useful on OpenBSD is a challenge too far. Note that around the 0.8 release with the move to leveldb is when the effort on Bitcoin in the OpenBSD work in progress ports tree dropped precipitously.

  • Your first order of business is acquiring a source tarball from somewhere. Ask a friend. Download it from Github. However you acquire it is your business.1
  • To minimize headaches I installed the version of BDB this version of Bitcoin-qt expects:
    pkg_add unzip
    curl -O
    cd db-4.8.30.NC/build_unix
    ../dist/configure --prefix=/usr/local --disable-replication --enable-cxx --enable-shared=yes
    make install

Now that there's a base it's time to extract the tarball, fire up a text editor and start chopping at code. It's fire up the text editor and chop because reading is good, and understanding is good.2

  • The first change is to wallet.cpp as described here. In OpenBSD world rand() is the shitty C standard compliant deterministic random and arc4random() is the good random. As the man page explains arc4random isn't based off of arc4 anymore so the mnemonic is now "A Replacement Call for Random" and the backend remains liable to change in the future. The need for this will likely be changing after OpenBSD 5.7, but until then this change is explicitly necessary.
  • For the second change we consult the Bitcoin Foundation's patchset for bitcoind particularly its BDB database configuration patch. Simply read the changes and make the changes. This protects against the great blockchain fork of March 2013's dilemma.
  • For the third change we consult the foundation's Alert snipping patch. The patch cannot be used as is because the alert code's been move around since version 0.5.3 but it still informs of changes that can be made in 0.7.2 to remove the system. I futzed with the public key strings in Alert.cpp and deleted from main.cpp most of the alert invocation code. It is especially important though to remove the parts where your version would impose a denial of service penalty on nodes sending it bad alerts. Removing the Alert stuff is critical for making sure your node can function as is indefinitely into the future.
  • Update: Originally I neglected that in protocol.cpp you need to add#include <netinet/in.h>
    #include <sys/socket.h>
  • In the makefile change the invocation of -libboost-thread to -libboost-thread-mt and LIBS += -lrt when qmake gives you a makefile.

Address compiler errors as they come up. If everything worked out well the result should be a functioning version of Bitcoin-qt which will take advantage of multiple cores on your machine and as far as I can tell work. For initial sync you will want to do it from the network in the wild to make sure it is actually a Bitcoin implementation. Built against LibreSSL 2.0 it should make it past the first wedge block 168001 fine. Mine is still in the syncing process.

Expect it to die a few or a lot of times as it hits the 512 MB RAM limit during initial sync. You can avoid this by letting OpenBSD give it more memory, but the reason memory usuage is bloating so much are bastard fatherless blocks fed to you which fill your memory as you get fed more and more blocks you lack the precedent to verify. It is both kinder and faster to let malloc() kill the process when it hits them memory limit, and then just script restarting it.

When in doubt about something read. OpenBSD has wonderful manual pages. The depth and quality of documentation they contain is beautiful.

  1. There's multiple ways to do things. You are responsible for making your own decisions. I offer these notes without warranty and with the disclaimer that I am an amateur when it comes to building software assembled by other people. Building dependencies you choose from ports or doing pkg_add it's your call.  If instead you just really want to gamble there are places for that.  

  2. Also I can't emphasize this point enough, but I am an amateur to the point I haven't had occasion yet to learn the unix patch utility. Maybe if I had I'd submit this to the ports tree, but my actual self is the one putting this information together so…  

Bowl Season

So Mizzou's regular season ended with a hard fought loss against Alabama. As close as the game got in the third quarter… the most notable trend of the game was that it was like a third grade team playing a first grade team. Just the disparity in size between the players that both teams were able to summon to man the line. It's hard to win a game of chess if your opponent's pawns are invincible, and it's hard to make plays in football when you can't control any space on the field. At least if Mizzou keeps making the conference championship game, maybe it might become possible for them to some day recruit some giants so they can make plays too. Whooping the shit out of Minnesota on New Years Day in the citrus bowl might help too.

Oh, that's right I titled this bowl season. The definitive preview of the Bitcoin Bowl is up and gives an overview of UCF and North Carolina State. If nothing else the two teams seem to be evenly matched. It seems right that a co-champion of the AAC would match up well against a team from the middle of the ACC in the standings. I just don't know if the thing is going to be interesting enough for someone to stake the bet on BitBet. I haven't seen line betting odds on the game yet, but they'll probably be close.

For Posterity

Hash: SHA512

[quote author=Vod link=topic=881488.msg9723874#msg9723874 date=1417576969]
[quote author=feverpitch link=topic=881488.msg9723860#msg9723860 date=1417576809]
And just why the hell are you disclosing something of this nature? Not that I condone or know what DPR did, but working in close proximity to lawyers for most of the day, I have a lay understanding that you probably shouldn't be openly disclosing this type of thing to anyone, let alone on the internet.

I'd say it sets a good precedent. It's nice to know when justice is happening, even if we don't know why in this case.

Even though this is a private forum, it still has to obey laws. I find that comforting.

This is an abominable precedent. When the subpoena arrives, the subpoena should go up. Not to mention that this thread was born well after the prosecution's discovery should have been submitted to the defense in the Ulbricht case.

Maybe this is the first time Theymos experienced a formal subpoena, but I have trouble believing that this is the first time he experienced a law enforcement inquiry. Especially considering the FBI and Treasury Department showed up at my front door because I used DBordello's BTCPak service way back in the day, Per:

Whatever DPR or Ulbricht or the Alleged suspect did, the rule of Just law is paramount and people in the position to disclose requests for this information ought to disclose these requests as they are received. Sure, running or patronizing a darknet drug market is one of the stupidest things a Bitcoin user could do, but it is also very shitty for a trusted member of the community running a venue to just go "Hey I got a subpoena" without offer its contents.
Version: GnuPG v1.4.11 (GNU/Linux)


It's amazing how fast these weeks are moving now

Bitcoin price continues to bounce with another USMS auction coming up soon. As time winds down $817 by this Christmas seems increasingly unlikely supporting the idea that on price, this is just a lost year for Bitcoin. Of course a lost year in price growth is a chance to build infrastructure for the next climb, so behold tiny bits of design that have slowly found their way into Qntra: Continue reading


It's getting cold. The air is becoming almost unbearably dry. At least it looks like Buterin's waterfall might be on the verge of breaking. Qntra continues to grow in both content and presence. Once the persistent DDoSing became manageable the growth in Qntra's traffic and presence has been encouraging. Now, if this present $300 to $500 price movement is analogous to late 2012's $4 to $6 movement which precedes an early 2015 surge… happy times.