On bitcoin data spam, and evil data

What happens if somebody puts evil data in the blockchain?  What responses are available?

It is a truly awful situation, and difficult to address.

What happened?

The easiest way to explain what happened here is through analogy. Imagine if someone picked a penny stock on the NYSE and made a sequence of apparently pointless trades. Then they announced that the prices of their stock trades actually encoded links to some "evil" websites. You know, maybe $0.01 means "a" and $0.02 means "b", etc. Stock market tickers are public, lots of places archive that data, so now lots of people have "links to evil data". Except really they don't. What they have is a list of stock trades. You'd need special software to turn that into some other kind of data.

This is what someone has done with Bitcoin. They sent a series of monetary transactions that did not actually represent real trades, and then announced that with a special program you could turn them back into some text. That text then contains links to, well, I don't actually know what because I haven't looked. But let's assume it's bad stuff.

What solutions are available?  Software update?

The answer is very complex, with implications that travel to the heart of bitcoin's value.

Sending bitcoins requires two pieces of data: a bitcoin address, and an amount (number of bitcoins).  There is no "comments field" or anything of that nature.  A bitcoin address is just a random 20-byte piece of data.  Normally those 20 bytes are derived from the RIPEMD160 and SHA256 algorithms, but a valid 20 bytes cannot be distinguished from an invalid 20 bytes.  Therefore, if you are willing to waste money -- albeit very small fractions like 0.00000001 bitcoins -- by sending that money to invalid bitcoin addresses, you essentially have created a channel for random data transmission.

The bitcoin blockchain is in one sense a massively replicated ~7GB database that stores data for all eternity.  There remains the open question of what happens if somebody dumps data into the blockchain, unrelated to currency.  Maybe a government finds that data illegal.  Smart people argue the legal theory mens rea and similar mitigating factors are applicable.  But it remains an unknown.  The vast majority of people are burdened with this awful data they don't care about, simply to use the bitcoin payment system they do care about.

There are many conflicting motives and incentives (very Brave New War-ish):

• Anarchist activists want to publish this information, to force authorities to act (or not) when this illegal data is published.
• Bitcoin activists want to publish this information, to force developers (us) to address The Filter Issue (see below).
• Some people see more value in bitcoin as "eternity data storage", if expensive and inefficient, than bitcoin as a currency.
• It is, quite literally, impossible to prevent use of bitcoin for data transmission.  It is a purely digital currency.  Who can say which digits are "evil" or "good", allowed or disallowed?  You can detect certain patterns, and possibly filter those.
• Many bitcoin users are using bitcoin for its intended purpose, as currency transfer, and dislike carrying the costs for these data transmission uses.
• As this carrying-data issue rears its head, it increases the costs for anyone running a P2P node on the all-volunteer bitcoin P2P network.  This shrinks the total number of bitcoin P2P nodes.
• As such, due to both legal and resource-usage issues, "data spam" has long been theorized as an attack vector.

 

The "Filter Issue"

There are very large ramifications to filtering out transactions, even ones that are obviously data spam.

Fungability: currently, all bitcoins have the same value.  My 1.0 BTC and your 1.0 BTC are equivalent in value.  Once you start filtering transactions, you are injecting policy-based censorship into the mix. Some bitcoins are accepted by all, some bitcoins are only accepted by a few.  A value of a bitcoin itself becomes a product of its ancestry.  If this policy is implemented, perhaps by court order to a bitcoin mining pool, it could lead chain forks, where i.e. bitcoin users in the United States see a different set of spendable bitcoins than users outside the US.  That would be a disaster for bitcoin.

It is widely speculated, based on common forum comments in the crypto-anarchist community, that this current round of data spam is intended to force bitcoin users, developers and governments of the world to take action to censor -- or not -- certain bitcoin transactions.  Trying to force the issue, to establish a precedent one way or the other.  Or, more pessimistically, a party could be simply trying to shut down bitcoin.

The bitcoin community is very staunchly anti-censorship, but if data spam were to threaten the life of bitcoin, I imagine ideology-neutral "it looks like data, not currency" filtering might appear.  Bitcoin is ultimately a product of voting -- you vote by choosing which software version and software ruleset to download.

The users can always vote data spam off the island...  but will they? Is data transmission a valid use of bitcoin?  The users themselves choose the definition of "valid."

On a personal note, as a father of two young children, this whole affair is morally disgusting.

What solutions could be deployed right now?

Currently being discussed is avoiding the relay of economically worthless (under $0.0001 dollars, say) bitcoin transactions.  Thus, higher transaction fees would be required to send out lots of data, directly raising the cost.

Related

See Gregory Maxwell's post, "to prevent arbitrary data storage in txouts — The Ultimate Solution" for a proposed solution.

Bitcoin block size thoughts

As pasted from an IRC discussion today:

•  (a) I once posted a patch to change max block size, so I thought about this long before forum readers ever woke up to the issue,
• (b) I have since backed down from that radical position,
• (c) it seems likely that max block size will change sometime in bitcoin's future,
• (d) block size is VERY MUCH like bitcoin's 21M limit, so a lot of care must be taken when changing MAX_BLOCK_SIZE logic.  Block size is an economically limited resource whose production is tightly defined and controlled by algorithm, with an intentionally steady production rate (the 1MB limit). 
• (d.1) Nonewithstanding the major impacts of a hard fork, in and of itself.
• (e) I lean against solutions that are feedback-based (average of last 1000 block sizes, etc.), as they can be gamed too easily
• (f) implementation will likely be:  if (now > chosen hard fork future date) { do it }
• (g) my default rhetorical position will be to push back against changes, for now, since there is no demonstrated need for hard fork.
• (g.1) Block sizes are nowhere near maximum, and
• (g.2) Competition for space encourages efficient solutions, whereas a too-loose block size policy incentivizes the opposite: dumping into the block chain
• (h) when I ran asic + p2pool, I set max block size at 900k and free tx at 300k.  That reflects my personal (not official dev team etc.) preferences.  I filtered out 1e8 outputs from mempool. We are nowhere near competing for block space at this point.
• And very importantly, (i) it is a mistake to increase block size simply because people are too lazy to implement layers on top of bitcoin.  Bitcoin will forever be a zen balance of applications and layers that sit on top of the blockchain, and those that directly use the blockchain itself as their comm/functional layer (c.f. SatoshiDICE).

So I generally agree with a lot of gmaxwell's points, and it is important therefore to not arbitrarily increase blocksize, simply because that makes some apps easier -- because they free-ride on the blockchain itself. Maybe one future state of The Mainnet Blockchain is simply a high security merged mining root for several important chains, who can say?

Block size is a core economic resource, like the number of bitcoins itself. Not merely the number of transactions we can support... it influences fees and many other factors.

My off-the-cuff guess (may be wrong) for a solution was:  if (todays_date > SOME_FUTURE_DATE) { MAX_BLOCK_SIZE *= 2, every 1 years }  [Other devs comment: too fast!]  That might be too fast, but the point is, not feedback based nor directly miner controlled.

Conclusions:

1. Block size does not need to change right now.
2. If and when block size changes, implement a simple rule, and let the free market figure out the rest (which might include a more complex rule years later, when the picture is more clear).

Standard disclaimer:  speaking only for myself, not any other dev or organization.

P.S. That was more than I intended to type, about block size.  It seems more like The Question Of The Moment on the web, than a real engineering need. Just The Thing people are talking about right now, and largely much ado about nothing.

Avalon miner: power usage

Power usage snapshot, raw numbers:

     66.3 Ghps / 620 Watts / 5.6 Amps

thanks to Kill-A-Watt.  See previous post for the more complete review.

Let the efficiency and electricity cost calculations begin!

cgminer status snapshot, showing hash speed, temperature, etc. at the time of the power measurements:

   [Elapsed] => 2186
   [MHS av] => 66320.47
   [Found Blocks] => 0
   [Getworks] => 73
   [Accepted] => 2060
...
   [miner_count] => 24
   [asic_count] => 10
   [fan1] => 0
   [fan2] => 1920
   [fan3] => 1920
   [temp1] => 27
   [temp2] => -1
   [temp3] => 48
   [temp_max] => 49

Avalon ASIC miner review

Here is a review of the Avalon ASIC miner.

Photos and video

Prior posts included photos.  No video was taken.  And the machine is performing its intended function -- receiving bitcoins to validate data -- so it will not be ripped apart for further pictures (however I want to see that, just as much as you). It is expected that upcoming press events and other third parties will provide this.

Shipping and packaging

The unit was packed very tightly and securely, with multiple layers of packaging, bubble wrap and Styrofoam.   No instructions or wifi antenna were included, and the included power cord was for a Chinese outlet.  These seem like excusable oversights, given the special shipping procedures and rush to get out The First Package.  Yifu notes here that US customers will receive a US power cord and other accessories.

Grade: A

Exterior

No precise measurements were taken, but the unit is as heavy as a desktop tower machine. The metal case is very solid, with precise CNC/mill cuts.  A modular, six-piece design that is easily assembled or disassembled.  No logos or other decorations.  The outer shell was enclosed in protective clear plastic, similar to how display screens are shipped.  Air flow is unobstructed, flowing from rear intake to front exhaust.

The only negative was the small bolts securing the side to the case.  When not tightened, the bolts rest loosely on the lower casing via a small slot.  These bolts are an interesting design, but made re-securing the case-side difficult.

Grade: B. People looking for something super-stylish with dragons on the side would give it a C, due to boring exterior appearance.

Interior

Very clean.  Cables neatly tie-wrapped.  The three (3) ASIC modules are mounted securely.  Plenty of room to add a 4th ASIC module.  Avalon describes their design as highly modular, and it is.  All components appear easy to upgrade, and Yifu has indicated that many improvements are planned.

Because much importance is placed on using this unit, very little poking and prodding was done under the cable bundle.  The PSU displays an Antec logo.  One board was labelled "PDU v1.2 by ngzhang" and a normally-external USB cable was observed inside the case, connecting the wifi antenna block at the rear to a controller board inside.  A bit ad hoc, but the cable was glued to the controller's USB port, as an added precaution against movement during shipment or use.

Grade: A.  Great modularity; obviously built to be upgraded over time.

User Interface

The software is a modified version of cgminer 2.10.4, on top of OpenWRT "Barrier Breaker r35097" and Linux 3.6.11 w/ Avalon-specific device drivers. The primary user interface is via web browser, though SSH is also supported. It is the standard OpenWRT web interface, with two additions:

• cgminer configuration: supports three (3) pools, for which you supply URL, worker username and password.
• cgminer status:  example output

This miner's stock installation was statically set to IP address 192.168.0.100 and no root password, for configuration purposes.  This may change to DHCP in the future.  It was trivial to plug in an ethernet cable, and immediately begin configuring the miner over the network with a web browser.

Grade: A+

Performance

The only thing that really matters, in the end, is the amount of power used and the amount of shares submitted upstream.  Unfortunately my Kill-A-Watt is missing in action, so we only have half the picture, output.

Performance is much higher than announced.  60 Ghps was announced.  The unit's cgminer self-reports 67.5 Ghps.  mining.bitcoin.cz reports between 65 Ghps and 67 Ghps (see previous post).  This is a significant increase over the announced speed.  When you consider that it is possible to add a 4th ASIC module, it is even more impressive.

After 20 hours of mining, the unconfirmed + confirmed rewards equal  14.98832170 BTC.  Note that slush's pool was very lucky recently, in addition to some blocks with abnormally high TX fee income, so that number skews much higher than expected.

Grade: N/A  Want to write A+... but we cannot judge fully without power numbers.

Reliability

The miner is currently running on an already loaded residential house power circuit, while sharing a Back UPS ES 550 with another desktop machine.  The small office/lab in which it resides is poorly ventilated, and in the winter time, prone to being overly hot.  In other words, not ideal conditions.

After 30 minutes or so of mining, the lights in my room flickered, UPS's beeped and complained.  Because of some stupidity (plugged into 'surge-only' side of UPS), the miner restarted as well.  After some reconfiguration, this problem was solved.

Nevertheless, the unit has seen several cgminer restarts, and a few full machine restarts.  Machine restarts seem to happen every 4-6 hours.  Even ignoring more obvious means of restart detection (login and look at uptime, or ping-monitoring etc), a restart is a clearly audible event:  At startup, the fans race at full speed for a few seconds, before "calming down" to a more moderate pace.

One of the temperature monitors consistently reads close to 50, and "temp_max" is often 100-125, so it is possible or even likely that temperature is playing a factor in these restarts.  Yifu stated that this machine has several failsafes, where it will restart upon abnormal events.

Grade: N/A  Need to investigate non-miner problem sources, but warrants watching.  Given evidence, it is highly likely that external factors are adding unwanted heat.

Feb 01 Update: Laying the machine flat, and adjust heat/air flow in my office seems to have helped significantly.  No problems or restarts seen since that change, though as of this writing, it is too soon to tell for certain.

Pool testing

Pool testing is ongoing.  More will receive their units before this unit gets around to testing your favorite pool, but this unit will be rotated through several pools.

Slush's pool with Stratum works great.  No problems seen.

p2pool was tested.  After some very helpful advice from p2pool's author and #p2pool channel, it appeared to start working.  Then Strange Things Happened.  The miner and p2pool both started reporting very odd values for everything from hardware fan temperature to software share difficulty on the pool side.  Cannot rule out hardware or software at this point, but the miner seems quite happy on slush's stratum pool.

Update: Eligius was also tested.  Saw issues with duplicates that were similar to p2pool issues.  These issues disappeared when switching to Stratum mode.

Customer Support

First, a story.  Apparent Yifu was quite surprised when I received the unit on Wednesday.  It sounded like there was a carefully planned PR campaign to coincide with the arrival of the units on... Thursday or Friday.  That was the expected arrival of my unit.  Then, surprise!  This crazy American is already posting pictures of an ASIC unit.  Suddenly all my mobiles, emails and IRC windows were lighting up with "oh crap! please call me!" messages.

After connecting on the phone, and talking about fun bitcoin projects, he made sure all my questions were answered, and made sure I was happy with the unit.  Yifu was clearly excited to finally get the ASICs out into community hands.

Grade:  It is not fair to give them a grade here, because it was a highly unusual situation, and the CTO was phoning personally to provide support.  It is unlikely that most customers will get that kind of star treatment simply out of fiscal and employee-bandwidth necessity.

Disclaimers and disclosures

My mining unit was a full price unit, ordered and paid for during Batch #1's order window.  Unsolicited, at the time of ordering (months ago), Yifu returned 25 BTC back to me, as a thank you for core development.

On the day of release (Jan 20), also unsolicited, Yifu bumped me to the front of the line for receiving units.  I learned of this via private email at the same time forum participants learned that ASICs had shipped.  Yifu requested (but did not insist) that I write a review, in exchange for receiving the first unit.  That is the extent of any special treatment or private communication (though see phone call, below).  Everything else has been publicly disclosed, primarily through BitSyncom posts or this Bitcoin Magazine interview.

Avalon: tonight

Looks like the 3-module Avalon box is running as expected.  I'll rotate among p2pool and other pools, testing each with the ASIC miner.

Expect a much more detailed review in a day or two.

</liveblog>

Edited to add, for the geeks:

/proc/cpuinfo: http://pastebin.com/XKV0gifY
/proc/meminfo: http://pastebin.com/agMhtNaf
kernel dmesg: http://pastebin.com/GPKAqCJE

Avalon: it's alive!

Once Ethernet was configured, the web interface was accessible.  Got things going on slush's pool, for a little third party confirmation:

Snapshot of cgminer status: http://pastebin.com/g4BhvCXK

Avalon: modular, room to expand

Inside it looks modular, with room to expand to a fourth ASIC unit.  Xbox controller shown for size reference.  PSU is Antec, no other visible labels on the PSU.

Some custom controller boards visible under the wrapped cables, e.g. "PDU v1.2 by ngzhang"

No wifi antenna included.  No paperwork or instructions.  Power cable is for Chinese "I-SHENG" power outlets, not American.  Easy oversights if someone is rushing to ship it, I suppose :)

One hopes the PSU is auto-switching.