Draft Pizarro ISP "Good Neighbor Policy" Rewrite

Here is a non-exhaustive list of behavior for which Pizarro will kick customers, refuse refunds, and deny recourse:

  • Monkeying with the LAN (including but not limited to binding to IPs your box was not provisioned with, ARP shenanigans, obvious sniffing)
  • Bandwidth hogging
  • If your intended use of Pizarro services involve activity actively prosecuted by pretend fiat sovereigns, ask if Pizarro is a good fit for your risk profile. We are particularly uninterested in hosting child pornography, the proliferation of which appears to be exclusively conducted by criminal gangs masquerading as law enforcement.
  • Carrying out dubious activity that jeopardizes Pizarro's ability to continue providing internet services1 without first inquiring brings substantial risk of damage to your reputation and ability to participate in commerce at all.

The above are guidelines, non-exhaustive and non-exclusive.


  1. This includes the sending of spam email.  

Draft Pizarro Shared Hosting Ad Copy

*This is an exercise in producing draft ad copy for Pizarro, it is not a live advertisement for hosting services*

Provision Your Website the right way with Pizarro Shared Hosting. Most Providers oversubscribe and oversell their harware, leaving you with no idea where your shit actually is. Our current machines offering shared hosting are:

UY1:

  • 128 GB ECC RAM
  • 2x 16-core AMD Opteron 6376 (2.3 GHz) (32 Cores)
  • Reserved Space, Just for you on a 1.7 TB RAID 10 Array composed of  Samsung Solid State Drives
  • Apache, MySQL, PHP 5.6
  • Located in safe and politically stable Montevideo, Uruguay outside of NATO or other belligerent states

Plans Available on UY1 Include:

FTP Basic Account

Host your site on Pizarro's server. For [price] BTC per month, you get FTP access to an account with 5 GB in storage.

Hosted Shell Account

Shape your environment. For [price] BTC per month, you get full shell access to the server, and 5 GB of storage.

Hosted Shell Plus

Power and configurability, for [price] BTC per month you get full shell access to the server, and 10 GB of storage.

Account Security And Creation

All interactions with Pizarro are authenticated and secured by Public Key cryptography.

  1. Generate a GPG keypair, the public key will serve as your identity in dealings with Pizarro. We don't require credit cards or other personal information.
  2. Register your public key with Deedbot.
  3. Connect to the #Pizarro channel on the Freenode IRC network
  4. Contact BingoBoingo or ben_vulpes to set up your account. Have an SSH public key ready. Your SSH key will be used for logging into your shell or ftp account on the server.
  5. Your account will go live when payment is confirmed.

Billing

Monthly, quarterly, and annual billing are available with all prices, invoices, and payments in Bitcoin.

Need Something More?

If your needs include still more power, storage, or separation, Pizarro offers colocation and dedicated single board servers. Inquire in #Pizarro on Freenode.

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 http://download.oracle.com/berkeley-db/db-4.8.30.NC.zip
    unzip db-4.8.30.NC.zip
    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 0.5.3.1 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…