I've been glancing through the Bitcoin Core code, but it'll take me awhile to piece everything together.  Hoping someone can drop some knowledge to help speed things up

My question is, during initial block sync, Bitcoin Core connects to a bunch of nodes.  Okay.  Now it needs to find the main chain.  So say we send

Code:

getheaders

to a bunch of them (.  Say some of them are lying and have fake chains.  So the

Code:

headers

you get back from different peers ends up being different.

Which chain do you choose to download?  Suppose there are several fake chains you get presented with, and 1 real chain.  How do you tell them apart without downloading all of them?  Maybe the fake chains have more work for awhile, and then (eventually) less work than the real chain?  What if the real chain has more work for awhile, but then less for a bit, until it eventually overtakes much later in the height.  What's the logic that allows you to find the real chain in those scenarios?

One thing I've thought of so far is to keep track of, say, 8 header chains.  Call

Code:

getheaders

repeatedly on all 8 of your peers, potentially forming a variety of header chains.  Do that until you've exhausted all potential chains.  This should only consume ~320MB of disk space right now, so easy enough.  Find the longest (most work).  Start downloading the blocks for it.  If you ever encounter an invalid block, store that block's hash in an invalid database, ban the peer that gave it to you and any peers that broadcast that header as part of their

Code:

headers

responses.  Delete that header chain.  Now begin downloading the next longest chain.  So forth and so forth until you find the longest valid chain.  You should eventually find it, because each time you find an invalid block you ban at least 1 peer and thus connect to 1 new peer.  So you'll sniff around the network until you find a trustable peer.

The only failure in that logic I see is if all 8 peers have totally valid, but truncated chains.  Presumably you could continually swap at least 1 peer every hour or so, and eventually find the real chain.

But watching Bitcoin Core's network logs, it looks like it begins calling

Code:

getdata

to download chains immediately after it gets its first

Code:

headers

back.  So is it doing more-or-less what I describe above, but just begins downloading the current best header chain optimistically?  I suppose the worse case there is it'll have wasted bandwidth and have to throw away a bunch of blocks.

Thanks!

I just finished the alpha version of www.BitcoinVoice.com

The recent debates about SegWit, Hardforking, etc and concerns about astroturfing led me to look for some way to cut through the bullshit. I wanted to build a platform where we could gauge the Bitcoin community's opinions, but in a way that's verifiable and meaningful; immune to astroturfing.

So I've spent the past few weeks putting together BitcoinVoice. Basically it's a list of polls, and anyone can vote in them. Votes are cast using Bitcoin signatures, so they can be verified. Each vote is weighted by the balance of the associated address. Proof of Stake without protocol changes!

I'm calling this an alpha release. It works just fine, but ... it's ugly as hell Sorry! Feedback, comments, etc are totally welcome! Please let me know what you think.

I really hope this can be useful!

Thanks for reading!

NOTE: The friendly folks over at #bitcoin informed me that a similar site already exists over at bitcoin.com ... which I didn't know about.  I guess ... at least BitcoinVoice isn't bitcoin.com?

[TL;DR]

Since KNC themselves have released no information on how to overclock our units.  I have started hacking the firmware myself to achieve that goal.  Here is what I have learned so far.

TL;DR
I have not yet succeeded in discovering how to change the hashing clocks.  It appears possible.
The VRM voltages should be easy to adjust over I2C.  Though I do not recommend it, yet.

initc

cgminer itself adjusts neither the voltage nor the clock.  Instead, there is a program called "initc" that runs on start-up.  The code for this program is not currently available.  This program appears to be responsible for a whole host of tasks.  It runs various self tests on the unit, loads the FPGA's bitstream, checks system configuration, etc.  Based on what I have seen poking around, (this is conjecture until confirmed) it is also responsible for setting up the VRMs, and the per-die PLLs.

Per Board EEPROM
It seems that every ASIC board has an EEPROM on it.  This EEPROM contains a checksum, serial number, PLL configuration data, a failure flag, and I'm not sure what else.  Only about 128 bytes of data or so.  They can be read like so: "cat /sys/bus/i2c/devices/X-0050/eeprom | hexdump -C" where X is 3, 4, 5, 6, 7, 8.  I have a Jupiter, so I have 3,4,5,6.

The checksum is the first 32 bytes.  I don't know what algorithm they're using for checksum.  I would have thought SHA-256, but that didn't seem to match.  Luckily it doesn't matter; we can just mod initc itself to calculate the checksum for us, when the time comes.

The PLL configuration data is 48 bytes long.  It's located at 0x60 in the EEPROM.  The first two bytes is the data length (48 bytes), and is not included in the length.  There appears to be 3 16-bit numbers for each PLL, with the addresses 0x84, 0x85, and 0x86 associated with them.  There are 4 PLLs per ASIC board, since each chip has 4 dies in it.  One of the numbers is always 0xd101.  The others I haven't figured out.  They appear to be completely random, which is odd.  It's entirely possible that they are encrypted somehow, if KNC had intended to restrict our ability to overclock.  If anyone has some insight here, that would be appreciated.

I know that initc loads this data, verifies the size of the PLL configuration data, and checks the checksum, but I haven't yet reverse engineered the parts of the code that would actually use this data ... if it's used at all.  I'm guessing the data is pushed to the ASICs over SPI.

Phone Home
I also discovered that initc contacts http://192.168.100.1:8080/%s?beagleserial=%s.  I don't know under what circumstances it does so, nor all the combinations of strings it'll format that with.  My guess: it is either part of factory set-up or their hosting facility.  Each miner, on bootup, contacts a master server to retrieve pool information and such.  Either this always happens, only happens once, or only happens when some flag is set.  But we won't know for sure until I finish reverse engineering the program.  This part of it isn't my priority though.

Reverse Engineered Source Code
I've manually de-compiled about 10% of initc so far.  It sure would be nice if KNC just released this code    This will have to suffice in the meantime.  I'm hoping initc manipulates the PLL configuration data, so we can gain more insight into its format.  At the very least, it'll be nice to know what this program is doing as a whole.


My EEPROM Dumps

Code:

root@Jupiter-6AB:~# cat /sys/bus/i2c/devices/3-0050/eeprom | hexdump -C
00000000  75 22 4a 27 1b d8 26 f5  fc c5 0c 5c 28 23 28 63  |u"J'..&....\(#(c|
00000010  4d 6c 01 9f 00 55 a2 4c  79 d9 73 62 d3 db 51 27  |Ml...U.Ly.sb..Q'|
00000020  41 31 30 30 30 30 30 37  42 39 41 30 45 00 00 00  |A1000007B9A0E...|
00000030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000050  04 00 00 00 00 00 00 00  ff ff ff ff ff ff ff ff  |................|
00000060  00 30 84 00 0d f1 84 01  c9 e7 84 02 f9 14 84 03  |.0..............|
00000070  91 65 86 00 01 d1 86 01  01 d1 86 02 01 d1 86 03  |.e..............|
00000080  01 d1 85 00 c2 cd 85 01  f5 31 85 02 eb 66 85 03  |.........1...f..|
00000090  03 01 aa 28 91 14 a0 64  12 16 f1 e5 a6 5d 1b a5  |...(...d.....]..|
000000a0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*

root@Jupiter-6AB:~# cat /sys/bus/i2c/devices/4-0050/eeprom | hexdump -C
00000000  5d 90 81 61 21 96 61 2f  79 aa da 0e b0 c2 97 1b  |]..a!.a/y.......|
00000010  96 a4 82 86 a3 eb cb 11  68 87 a0 6c a1 c6 ab d6  |........h..l....|
00000020  41 31 30 30 30 30 30 38  30 30 31 36 33 00 00 00  |A100000800163...|
00000030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000050  00 00 00 00 00 00 00 00  ff ff ff ff ff ff ff ff  |................|
00000060  00 30 84 00 94 50 84 01  82 5c 84 02 29 a8 84 03  |.0...P...\..)...|
00000070  ab 7b 86 00 01 d1 86 01  01 d1 86 02 01 d1 86 03  |.{..............|
00000080  01 d1 85 00 e6 d0 85 01  57 f8 85 02 60 5b 85 03  |........W...`[..|
00000090  b0 48 a7 af 63 41 fd 14  5e 7c f5 95 66 47 59 d0  |.H..cA..^|..fGY.|
000000a0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*


root@Jupiter-6AB:~# cat /sys/bus/i2c/devices/5-0050/eeprom | hexdump -C
00000000  5b 59 fc 0f 94 ab a3 d7  d8 7c 91 6b a5 29 d6 51  |[Y.......|.k.).Q|
00000010  4a 0f d6 6b e6 35 5e a5  a4 59 04 5f f1 26 1e 19  |J..k.5^..Y._.&..|
00000020  41 31 30 30 30 30 30 37  42 42 45 43 46 00 00 00  |A1000007BBECF...|
00000030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000040  00 00 00 00 00 00 00 00  00 00 00 00 00 01 00 00  |................|
00000050  08 00 00 00 00 00 00 00  ff ff ff ff ff ff ff ff  |................|
00000060  00 30 84 00 56 87 84 01  74 fa 84 02 c0 34 84 03  |.0..V...t....4..|
00000070  8f 7a 86 00 01 d1 86 01  01 d1 86 02 01 d1 86 03  |.z..............|
00000080  01 d1 85 00 db 11 85 01  b7 d7 85 02 3c ce 85 03  |............<...|
00000090  3d 1c e7 e3 75 f7 fe 65  21 ea 89 91 25 3a e7 ed  |=...u..e!...%:..|
000000a0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*


root@Jupiter-6AB:~# cat /sys/bus/i2c/devices/6-0050/eeprom | hexdump -C
00000000  7d 1c cb 21 6e a1 4a ad  65 29 bf af 12 de a3 cd  |}..!n.J.e)......|
00000010  76 93 dc e7 0f 8c 28 33  5f 49 b2 86 81 b4 19 d4  |v.....(3_I......|
00000020  41 31 30 30 30 30 30 37  42 41 35 38 41 00 00 00  |A1000007BA58A...|
00000030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000040  00 00 00 00 00 00 00 00  00 00 00 00 00 04 10 00  |................|
00000050  00 00 00 00 00 00 00 00  ff ff ff ff ff ff ff ff  |................|
00000060  00 30 84 00 f3 49 84 01  cb 1e 84 02 d9 dc 84 03  |.0...I..........|
00000070  b1 58 86 00 01 d1 86 01  01 d1 86 02 01 d1 86 03  |.X..............|
00000080  01 d1 85 00 cd 76 85 01  bd b6 85 02 fc f6 85 03  |.....v..........|
00000090  e9 05 cb d2 3f 91 df 4e  ac 30 d4 32 25 65 26 e7  |....?..N.0.2%e&.|
000000a0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|

If anyone wants to dump theirs as well, I would be interested in comparing the PLL configuration data.

There's also EEPROMs at 0-0050 and 1-0054.  One of those is an EEPROM on the Beagle board, I believe, and just contains the Beagle's serial number.  The other one I believe is on the IO board.

[Programmer Adventures in Modelling and Simulating Hash Functions]

Programmer Adventures in Modelling and Simulating Hash Functions

I've been curious about the properties of hash functions lately.  I had three questions, that I attempted to answer:

• What is the order of SHA-2 (x)?
• What is the order of SHA-2 (SHA-2 (x))?
• What is the order of PBKDF2 (x)?

For this research, I define order to mean the size of the output set of the given function (in other words, how many unique outputs there are).  Ideally, this would be 2^256 for SHA-256.  If the cost of executing the function is considered to be one operation, than the complexity of finding a collision is directly related to the order of the function.

When the input set is small, finding the order of a given function is easy.  Just run all possible inputs through the function, and count the number of unique results.  Unfortunately, the input set of SHA-256 is impossibly large (though technically finite).  Since I'm a programmer by nature, I chose to answer the above questions by modelling and simulating.

The model I use is a random oracle.  These represent perfect hash functions; they are impossible to invert except through brute-force.  For small input sizes, one can generate a random oracle easily.  It's just a random LUT!  To answer the first question using this model, we need to know the expected order of a random oracle.  This is equal to the average of all possible random oracles (for a given input size).  Again, we run into a problem, because the set of possible random oracles is too large.  So, instead, I estimate the expected order by generating a suitably large number of random oracles and averaging their orders.

To answer the last two questions, we do the same, but apply the random oracle in the specified construct.  e.g. Oracle (Oracle (x)).  With enough samples, we should hopefully get good estimates for the expected orders and thus have answers to my questions.  The Python code for all of this is listed at the bottom of this post.  In the meantime...

Results

Code:

Testing 8 bits
Oracle:  162.212890625
Exponential:  19.470703125
Chained:  120.920898438

Testing 12 bits
Oracle:  2589.109375
Exponential:  95.3359375
Chained:  1920.23925781

Testing 16 bits
Oracle:  41426.6992188
Exponential:  1278.45996094
Chained:  30704.7412109

Testing 17 bits
Oracle:  82854.8759766
Exponential:  2516.46582031
Chained:  61408.5410156

Testing 18 bits
Oracle:  165699.530273
Exponential:  5046.56347656
Chained:  122825.053711

Testing 19 bits
Oracle:  331412.545898
Exponential:  10073.0644531
Chained:  245653.294922

Testing X bits means running the simulations with an input set of size 2 ^ X.  Oracle is just the plain random oracle model.  Exponential is 101 iterations of a random oracle iteratively applied (e.g. Oracle (Oracle (x)), but with 101 Oracles).  Chained is similar to PBKDF2 (password and salt combined, no HMAC).

The results are certainly interesting.  Over all the tested input sizes, we see consistently that the estimated expected order of a hash function is only 63% of the input set.  In other words, based on these models, one would expect the order of SHA-256 to be ~2^255.3.  Pretty good!  On the other hand, SHA-256 in an Exponential construct is weaker, resulting in an order of ~2^250.3.  SHA-256 in PBKDF2 would be ~2^254.9.

None of this is particularly surprising, but it's educational to have some concrete numbers.  Of particular interest is the result for the Exponential construct.  Some have conjectured that double SHA-2 is weaker than regular SHA-2.  While this seems to be strictly true, the weakness is nowhere near significant.  After 100 iterations of SHA-2, one would expect to see the output space cut down to 1% of its usual size.  But 1% of 2^256 is still impossibly massive and impossible to search.  If we factor in increased computational complexity, searching the space is still more expensive than single SHA-2.  (NOTE: Doubling hash functions can have other benefits, too.  e.g. HMAC_SHA1 should remain strong in spite of SHA1's weaknesses)

Chained (pseudo-PBKDF2) is interesting too.  At its core it uses the hash function recursively like Exponential does, so seemingly the larger your iteration parameter for PBKDF2 is, the less pseudo entropy you're injecting into the system.  But the expected order is still quite large, and of course computational complexity grows drastically.

Perhaps all of this could have been easily proven using modern algebra, but I'm a better programmer than I am a mathematician.  So to all those crypto-interested programmers out there, I hope this has been useful.

The Code

Code:

import random
import os


# If True, causes the PRNG to be reseeded with entropy often.
EXTRA_RANDOM = True


# Represents an instance of a PseudoRandom Function
class PRF (object):
def __init__ (self, func, input_bits):
self.input_bits = input_bits
self.func = func

# Calculates the size of the output set
def output_order (self):
outputs = set ()

for x in xrange (2 ** self.input_bits):
y = self.func (x)
outputs.add (y)

return len (outputs)

# Estimates the size of the output set
def estimate_output_order (self, num_samples=2**16):
num_samples = min (num_samples, 2 ** self.input_bits)
inputs = random.sample (xrange (2 ** self.input_bits), num_samples)
outputs = set ()

for x in inputs:
y = self.func (x)
outputs.add (y)

return len (outputs) * (2 ** self.input_bits) / num_samples


# A real random oracle generator
class RandomOracle (object):
def __init__ (self, input_bits):
self.input_bits = input_bits

def generate (self):
if EXTRA_RANDOM:
random.seed (os.urandom (32))

permutation = [random.randrange (2 ** self.input_bits) for i in xrange (2 ** self.input_bits)]

def model (x):
return permutation[x]

return PRF (model, self.input_bits)


# Generates exponential versions of the given PRF generator.
# i.e. y = PRF (PRF (PRF (x)))
class ExponentialPRF (object):
def __init__ (self, prf, iterations):
self.prf = prf
self.iterations = iterations

def generate (self):
prf = self.prf.generate ()

def model (x):
U = x

for i in xrange (self.iterations):
U = prf.func (U)

return U

return PRF (model, prf.input_bits)


# Generates chained versions of the given PRF generator.
# i.e. y = PRF (x) ^ PRF (PRF (x)) ^ PRF (PRF (PRF (x))) ^ ...
class ChainedPRF (object):
def __init__ (self, prf, iterations):
self.prf = prf
self.iterations = iterations

def generate (self):
prf = self.prf.generate ()

def model (x):
U = x
T = 0

for i in xrange (self.iterations):
U = prf.func (U)
T = T ^ U

return T

return PRF (model, prf.input_bits)


# Given a PRF generator, estimates the expected size of the output set.
def estimate_family_order (generator, num_samples=1024):
total = 0

for i in xrange (num_samples):
prf = generator.generate ()
total += prf.output_order ()

return total / float (num_samples)


# Some tests
for bits in [8, 12, 16, 17, 18, 19, 20, 21, 22, 23, 24]:
print "Testing %d bits" % bits

oracle = RandomOracle (bits)
exponential = ExponentialPRF (oracle, 101)
chained = ChainedPRF (oracle, 101)

print "Oracle: ", estimate_family_order (oracle)
print "Exponential: ", estimate_family_order (exponential)
print "Chained: ", estimate_family_order (chained)
print ""

TL;DR: Recursively applying hash functions like SHA-2 insignificantly weakens the function, if one ignores computational complexity.  Blah, blah, blah, programming is fun and cryptography is awesome.

[Summary of RFC 6979]

I've seen this RFC mentioned once or twice on this forum, but could not find any extensive dialog about it.  I would like to implement this as part of my hardware wallet, but am hesitant to do so without seeing what others have to think about the approach.

Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)


Summary of RFC 6979
ECDSA signature generation uses a number k, which must be randomly and uniformly chosen each time a signature is created.  Under deterministic ECDSA, as proposed by RFC 6979, k is chosen deterministically.

We start by creating an instance of HMAC-DRBG, with the private key as the source of entropy, and the hash of the message as the nonce.  k is generated from the output of this HMAC-DRBG instance.  This makes k deterministic, given the message and the private key, but still uniformly distributed and ~impossible for an attacker to guess/calculate.

Most importantly, signatures generated this way are compatible with existing ECDSA signature verification implementations.


Why make ECDSA deterministic?
There are two major reasons to use a deterministic algorithm here.  In regular ECDSA, if two signatures are created (different messages) with the same k value, the private key can be calculated.  This means that ECDSA immediately fails if k is not chosen randomly.  The recent Android mishap led to such a problem.  Using deterministic ECDSA avoids this.

Secondly, it allows easy verification of ECDSA implementations, using fixed test vectors.  Regular ECDSA implementations cannot use signature test vectors, because the signatures are random by design.


Thoughts?

[Hash Phrase Github]

Hash Phrase Github

4ba38d48a60f1b29e9eb726eaff08b2e83d8d81e031666fee50e85900d7dc1ef
versus
Theologian examine writer walking desire

While working on my Hardware Wallet project, and while using Bitcoin in general, I often found myself manually comparing destination Bitcoin addresses.  This is a good practice, to ensure the destination address is not tampered with by malicious software.  However, addresses are base58 gibberish, and thus difficult for a human being to compare; they could be fooled by a partial collision attack.

In addition to that, I had the thought that a browser extension which displays a webpage's hash to the user would be helpful for security critical, static websites like brainwallet.  That would help prevent tampering.  But nobody is going to memorize a hexadecimal hash.

One solution is a human readable hash function; one which is easy for humans to read, memorize, and compare.  My first implementation, Hash Phrase, outputs a phrase composed of common English words.  For example, the Hash Phrase of my sig's Bitcoin address is "Random baptism coaches seymour parishes."  Easy to read, memorize, and/or compare!

I'm interested in discussion on this particular implementation, alternate solutions, and applications.  For example, this implementation suffers from entropy starvation; it can only reasonably represent ~64-bits.  Its phrases are also sometimes confusing and weird, which makes them difficult to remember.  A procedural image based hash function would likely be a better solution, but is more difficult to implement well.

I got tired of my mining rigs just making "whoooooosh" sounds.  So, I fixed it:

https://github.com/fpgaminer/listen-to-bitcoin-mining

http://www.youtube.com/watch?v=36zCtFHEOrg

Auction sniping (bidding within the last minute or two) is often considered a problem, especially in high profile auctions like those put on by ASICMINER.  Personally, I enjoy the thrill of those auctions, but a lot of people do not, and I agree that it is not ideal.

One solution is extending the bidding by a certain amount of time each time a bid is placed, if the bid is placed close to auction closing (typically up to a maximum date/time).  This is a viable solution, but can cause the auction to drag out for too long.

A thought occurred to me.  What if the end time is left unknown to all except the auctioneer?  I will show an example:

This auction will end on May 5th, 00:00:00 UTC, +- 1 hour.
SHA-256 hash of real ending time:  22948fb57ed49f3f351873d6c6ecc19e2051168d8a6e5e7db52f0fdc46e2c221

The actual end-date for the auction is left unknown to all bidders, but they know that it will be within an hour of the specified time.  At May 5th, 01:00:00 UTC (the maximum closing time) the auctioneer will officially announce the real ending time, like so:

Real ending time: secretsalt May 4th, 23:35:13

All bids posted after that time are invalid.  All participants can verify that the real ending time posted matches the one originally established, by checking its hash.  The ending time cannot be guessed beforehand, thanks to the secretsalt.

With this system, it's impossible to snipe, since the ending time is not known.  Unlike the extension method, the auction still has a fixed length.  And my guess is that the uncertainty is also likely to drive bids higher than usual.

Thoughts?

[Example:]

How Secure is Your Password?

One of the side effects of the Bitcoin network, is establishing a lower-bound on the cost of password cracking.  Suppose someone has a mining farm; they can either use their equipment to mine or crack passwords.  If the reward from cracking a password is less than they would earn mining, they will likely mine instead.  Hence, the price of a bitcoin, and the mining difficulty, can be used to figure out just how much it costs to crack your passwords!

http://bitcoin-password-cost.appspot.com/

The "Time to Crack" result assumes the entire Bitcoin network is attacking your password.  The "Cost to Crack" is agnostic to the attacker's hashing rate, though.


Example:
10 Character Password
Alphanumeric, Upper/Lowercase, Special Characters
PBKDF2_HMAC_SHA256 - 100,000 iterations

Time to Crack (50%): 1.06 Thousand Years
Cost to Crack (50%): 128.71 Billion USD


Notes
This is likely to be an underestimate.  In other words, it will probably cost a real attacker much more, since they also need to pay power costs, capital investment, and password cracking algorithms will be far less efficient compared to the current mining algorithms.  They are also likely to have only a fraction of the computing power relative to the Bitcoin network.  The effective cost to crack your password would remain the same for them, but the time would be much, much larger.  Anything much over a few years time seems too long for anyone to even attempt.

On the other hand, computing power tends to double every two years.

[http://bitcoin-talk-auctioneer.appspot.com/]

BitcoinTalk Auctioneer

Tired of manually, and tirelessly counting all those bids in the Auction sub-forum?  I am too!  So, I slapped together some code to help with the process of summarizing the current winning bids:

http://bitcoin-talk-auctioneer.appspot.com/

---------------------------------------------

Beautifying CSV Formatted Bids
You can specify the CSV formatted active bids, and it will spit out something like this:

Name	Quantity	Price	Remaining
VJain	10	1.05	390
rottenchris	10	1.05	380
Line	15	1.05	365
Melbustus	20	1.04	345
SilentSonicBoom	1	1.04	344
obom29	10	1.03	334
Haibi	10	1.03	324
gog1	100	1.03	224
lagmo	30	1.02	194
fpgaminer	10	1.02	184
Rodyland	20	1.02	164
batcoin	10	1.02	154
twobits	20	1.02	134
furuknap	11	1.02	123
aahzmundus	75	1.01	48
penta	48	1.01	0
penta	2	1.01	-2
imsaguy	25	1.01	-27
caoxg	100	1.01	-127
qwk	30	1	-157
acayne	100	1	-257
hephaist0s	11	1	-268
maxmint	10	1	-278
punin	100	1	-378

This part of the website is working quite well.  I used it in this auction to give fairly frequent updates.  The downside is, someone still has to monitor the posts to collect the CSV formatted bids.

NOTE: bids must be CSV formatted like so:

Code:

name,quantity,bid

For example:

Code:

qwk,30,1
acayne,100,1
hephaist0s,11,1
maxmint,10,1
punin,100,1
aahzmundus,75,1.01
penta,50,1.01
imsaguy,25,1.01
caoxg,100,1.01
lagmo,30,1.02
fpgaminer,10,1.02
obom29,10,1.03
Rodyland,20,1.02
batcoin,10,1.02
Haibi,10,1.03
twobits,20,1.02
gog1,100,1.03
furuknap,11,1.02
Melbustus,20,1.04
SilentSonicBoom,1,1.04
VJain,10,1.05
rottenchris,10,1.05
Line,15,1.05

---------------------------------------------

Automatic Summary
This tool can also attempt to figure out active bids automatically, given a URL to the thread.  This feature is a Work-In-Progress and it requires posters in the thread to follow some guidelines:

1) Bids should be submitted like so: "10 @ 1.045" which means "I want 10 pieces of what you're selling, and will pay 1.045 for each."
2) To cancel a bid, post "cancel 10 @ 1.045". This will cancel all of your previous bids that match that quantity and price.
3) Bids and cancels must not be formatted in anyway (no bolding, italics, etc), and must be on their own line in the post.  i.e. "Change to 10 @ 1.8" is not recognized.
4) There are no automatic bid replacements or cancels.  Posters must cancel previous bids if they so desire.

If posters follow those guidelines, it should work.  However, I'm still tinkering and testing it, so let me know what bugs you run into.  Also, it doesn't watch the date/time yet, so it will include bids posted after the auction's end.

Enjoy!

[Open Source Vanitygen for FPGAs]

Open Source Vanitygen for FPGAs

Source on Github

Animated Github Log



April 13th, 2013
The first Open Source Vanity Address Generation for FPGAs firmware is now available on Github!  This first release targets the Altera Cyclone III C120 Development Board, and is more a proof of concept than anything else.  It's functional, but only runs at ~40Kk/s.  Feel free to dive in and port to your own FPGA boards.

I have more performant code under development (unrolled/pipelined).

See the OP for links to the source code and such.




Original Post, March 12th, 2013.

[Bitcoin Hardware Wallet]

Bitcoin Hardware Wallet
Codename: Bitcoin Titan
by: FPGAMiner


Protects Your Bitcoins From Hackers and Thieves

This thread documents the progress on my Hardware Wallet project, code-named the Bitcoin Titan.  The Bitcoin Titan is a USB accessory which connects to a desktop/phone/tablet and safely stores a user's private keys (optionally encrypted).  Even when a hacker compromises your computer, or steals your Titan, the Bitcoins it secures will remain safe.

I have been working on this project off-and-on since May 2012.  As of May 2013, the firmware and software has entered the alpha testing stage; fully functional, but requiring further polish and testing.  The hardware design is undergoing its first revision.




June 25th, 2013: First Board Spin Working

The first board spin for this project has been assembled and tested, and is working beautifully.  Previously I was prototyping the Bitcoin Titan using existing development kits and other components.  This moves it to a custom PCB; no more wires sprawling everywhere!


The board itself



With the screen attached and running



In case you're wondering, those pins poking out the top and bottom are only for development and aren't normally attached.

The above picture also shows off part of the UI redesign.  Once the UI redesign is finished I'll release another demo video.



May 16th, 2013: Video Demonstration of Alpha Software

Today I am releasing a demonstration video of the Bitcoin Titan, now that the software/firmware is in alpha testing.  I demonstrate how to set up the Titan for the first time, receiving bitcoins, and securely send bitcoins.  Click below to watch!

Click to Watch the Video Demonstration







Original Post:
Submitted for your entertainment, one of my old projects back in May '12:

http://www.youtube.com/watch?v=bhWVv7_ecMY

The project is long since dead, since I got too busy to finish it.  Luckily it looks like slush and stick announced a similar project a few months ago (Trezor), so at least the community can finally move past storing private keys on their PCs.

For the curious folks out there, this was built on an STM32F4 Discovery Kit.



EDIT: Project ever so slightly revived:

I have a handful (~8) of old 5850's from when I was GPU mining (power cost is too high). Some still work, but most have dead fans and one needs the heatsink re-applied. So I'd have to sell them "as-is" and any buyers would need to repair the fan/heatsink. I don't know if they're even worth selling in this condition. Any comments would be appreciated.

[The Problem]

I'm hoping someone here can help me decipher this mystery. poclbm displays two hashing rates when it is running. The real hashing rate, and the estimated hashing rate:



The first rate is calculated directly from the number of hashes the GPU has processed. So it should be the most accurate number.

The second number is the estimated hashing rate, and it's calculated from the number of shares poclbm actually submits within a window of time (15 minutes by default). It should not directly reflect the GPU's actual processing speed, but rather it's a good estimate of "all things considered" hashing rate.


I made a small modification to the code for that second value:

Code:

if self.options.estimate == -1:
total_shares = self.share_count[1] + self.share_count[0]
estimated_rate = Decimal(total_shares) * (work.targetQ) / int(now - start_time) / 1000
else:

If I use the command line option "-e -1" it will now estimate hashing rate over the entire run-time of poclbm, and all submitted hashes, even rejected ones. I wanted this, so I could be sure that experimental kernels were really producing the expected hashrate. For example, if the kernel or myself screwed up nonce calculations it could end up re-hashing the same nonce, and hence reduce real performance.

The Problem: In the above screenshot, I ran with "-e -1" for a hair under a day now ... and estimated has remained at approximately 363MH/s since last night. That's 9 MH/s (2.5%) more than what should be the most accurate number. Can anyone figure out what might account for this discrepancy?

As far as I can tell, share_count should be accurate; no share should be counted twice.

All the code is here:
https://github.com/progranism/poclbm

And should be up-to-date with m0mchil's code except for my modifications.

I'm curious if there are any GPU rental services, VM-based or otherwise, which you can rent for short periods of time and just do whatever you want with? Where you can pay for a few hours up-front, and then SSH into the box to run some mining scripts or test out new GPU code. Most everything I've found is for month long contracts, and I'm really just interested in something convenient where I can rent time on demand.

Does such a service exist, at roughly the associated mining cost? i.e. I'd pay roughly how much that same machine would earn mining on its own.

I have had a lot of trouble with phoenix. The biggest issue being that it oftens gets stuck on "[0 Khash/sec] blah blah" and never reconnects to the server. This is especially bad when I have torrents running, even when I limit torrent traffic. The only reason I put up with it is because phoenix supports the phatk kernel, which gets me an extra 20MH/s per card.

Well, I got tired of it, so I forked poclbm and hacked it to support phatk. Here's my fork:

https://github.com/progranism/poclbm

So far so good, poclbm is happily running without any issues whereas my phoenix instances are freezing up  MH/s is about the same. 339 MH/s instead of the 340 MH/s I get on phoenix. Close enough.

Lemme know if this helps anyone else. 

One of my Sapphire 5850s now has a stiff fan. It only gets about 500 RPM, where it should be getting 5000. 

I took the card out, and manually turning the fan is stiff. It still turns, but not smooth and nice like the other cards. No idea what happened; it's a month old. Sapphire support will RMA it, but I have to pay shipping to their facility and I'm without a card for who knows how long.

All tech support could suggest is to "air dust" it and put WD40 on the fan. I doubt dust is to blame for a stiff fan, but I'll dust it regardless. As for the WD40 suggestion ... I'm not even sure how I would get WD40 onto the fan's internals. I guess I have to some how get the plastic casing on the card off, and carefully drip oil to the base of the fan. God knows what will happen if I accidentally get WD40 on the heat sinks 

Anyone have some ideas?

[$49.99]

I've got a coupon here for a free copy of DiRT 3. Came with a Radeon card I won at E3 

Retail price of the game is $49.99 at Steam right now, so PM or post your offers in BTC.



Thank you!

I'm curious if there are enough Bitcoiners attending E3 in Los Angeles this year to warrant a small meet-up? I think it'd be fun to at least hang out a bit at the show and shoot the breeze.

It's a bit late to be asking, since tomorrow (Thursday) is the last day 

[The Open Source FPGA Bitcoin Miner]

The Open Source FPGA Bitcoin Miner
https://github.com/fpgaminer/Open-Source-FPGA-Bitcoin-Miner


Kintex 7 K325T Maximum Performance: 400 MH/s
Cyclone 4 C75 Maximum Performance: 109 MH/s
Spartan-6 LX150 Maximum Performance: 100 MH/s
List of FPGA Performance per device and configuration
Note: The included configuration (for Cyclone 4), and source code, downclocks the chip to 50MH/s. 109MH/s requires cooling, and I didn't want to release something that would burn up your valuable chips.

This includes a pre-synthesized configuration file, ready to be loaded onto a DE2-115. The README.md includes easy instructions on how to load that into your FPGA and get up and running.

Please feel free to give me feedback, suggestions, critiques, and of course to submit Pull requests.



Compatible Board (and only purchase currently required):
Terasic DE2-115 Development Board
Note: This is not the only supported FPGA board, but it is the only board with mining binaries and instructions currently available. The software can be manually compiled for many different chips (Altera and Xilinx) and boards. More pre-built binaries and instructions will be made available as time allows.


News and Updates


June 2nd, 2011 - Flexible Unrolling Added
Thanks to the patch submitted by Udif, the code now supports a configurable amount of loop unrolling. The original design was fully unrolled, with 128 total round modules. By adjusting the CONFIG_LOOP_LOG2 Verilog define, you can choose to unroll to 64 round modules, 32, 16, 8, or 4. This makes the design smaller, at the equivalent cost of speed, which should allow it to run on many more FPGAs.

If you're interested in trying the code on a smaller FPGA, open the projects/DE2_115_Unoptimized_Pipelined project in Quartus. Then go to Assignments->Settings->Analysis & Synthesis Settings->Verilog HDL Input. You should see a CONFIG_LOOP_LOG2 macro setting, which you can set from 0 to 5. 0 gives full unrolling (largest, fastest), and 5 gives the smallest design. You will also need to go to Assignments->Device and choose your FPGA, and set the correct clock pin in Assignments->Pin Planner. Then just compile and program!


June 12th, 2011 - Xilinx and VHDL Ports Added
With many thanks to TheSeven and teknohog, their code has been added to the public repo. TheSeven did a re-implementation in VHDL, with support for Xilinx and ISE. teknohog did a straight port of the Verilog code to simply support Xilinx and ISE. Both include Python miner control scripts, and serial port communication with the FPGA board.

I made little to no modification to their code for this first commit. If you appreciate their hard work on this Open Source project, please send them your thanks and donations!

TheSeven: 14Jc8vWq1mPv7vWnP5VquZZgpLEtzW2vja
teknohog: 1HkL2iLLQe3KJuNCgKPc8ViZs83NJyyQDM


July 17th, 2011 - Code Updates and Minor Cleanup
teknohog's Xilinx Verilog port on the public repo has been updated. teknohog's serial modifications to makomk's code have been added as a separate project. OrphanedGland's port to Stratix devices, using VHDL, has been merged into the public repo. To top it all off, I updated the project's main README.md file, to prominently include a list of contributors and their donation addresses, because they deserve recognition for their hard work. I will modify the first post in this thread to include the same list

As it wasn't mentioned before on the first post, I am mentioning here that makomk made improvements to my base Verilog code. These changes improved both the overall performance of the design, and its area consumption, allowing the design to fit on a smaller, cheaper EP4CE75 chip. Great work makomk!


August 8th, 2011 - Spartan-6 Code Added and Working, Altera Mining Script Updated
Thanks to the efforts of makomk, the Spartan-6 series of chips are now supported, and achieve the highest performance per $ of any chip. Code has been verified working on my LX150 development kit, and can achieve up to 100MH/s of performance.

The Altera Tcl Mining Script has just received a massive update. No more need to edit mine.tcl to hack in your FPGA's hardware and device names; mine.tcl will automatically detect mining FPGAs connected to the system. Pool information has been moved to a config.tcl file for easy editing. No more dependency on TclCurl, so the script should be Linux friendly now. And best of all, the console output has been cleaned up to look like poclbm.




April 14th, 2013 - Kintex-7 Code Added and Working, Using The New DSP48E1 Design
I have just pushed the experimental KC705 code to the repo.  Here is the project.  This is a DSP48E1 based design, and I have compiled and run it at 400MH/s.  Included with this new design is a UART interface, instead of JTAG, since the KC705 kit has an on-board USB-UART bridge.  See the README for more information on how to use the UART interface.  As an additional surprise, this code includes support for the Kintex's on-die temperature sensor.  Temperature readings are reported over UART, allowing external software to monitor the chip.  In the future I will add automatic shutdown on over-temp conditions.



Contributors
These fellows have contributed to this Open Source project in various ways, and deserve recognition. If you appreciate their hard work on this Open Source project, please send them your thanks and donations!
Not listed in any particular order.

teknohog - 1HkL2iLLQe3KJuNCgKPc8ViZs83NJyyQDM

OrphanedGland - 1PioyqqFWXbKryxysGqoq5XAu9MTRANCEP

udif

TheSeven - 14Jc8vWq1mPv7vWnP5VquZZgpLEtzW2vja

makomk - 15XX7BhQcZFUg47S4VKyiLygPTHTs9234J

newMeat1 - 1LbqTCA1cnpbbdKbXzZZfHYMe7teiczQc2


NOTE: If you've contributed to the project, and are not listed here, or your donation address is not listed, please contact me. I do my best to keep track of everyone, but I'm only human.




-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

May 19th, 2011

First official release of the Open Source FPGA Bitcoin Miner.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)

iQIcBAEBAgAGBQJN1dF/AAoJEFFoGj2A5YKRl/IP/2pMRqNZ0R+Z5WTG/v9DyafJ
YChUTSW8Tc1su99hJWe4pXtVH3p/zsn6spy73DaTeGjHvjxlDAuRU/qq3ax5RdGG
e5DsUb9fRFVnkpFDjIqsHQLAeQxwgRC28JsFNXP0ow986wwnZwRIBMx6xykVUYIx
/ImV4Y/vbc92nMclsItuF2NCFtYcravbP6NsbYuhMGORIqTkTNUuczP2weRw9C9H
10ThsCpfDD2OgNrL3kDy2SSlOkMekpTTlkin5P2ax6vZUE/2o3ZaZW9ORGLYnM85
8VX2NfyKwstvIrPoyHuYAxQYyFB8FLDoyqbkBSdxR/xlv8lR1i9OzCfeEmXQGbOr
yUk96JIoQIZ9TDuVlpMtIv7lYudiMLQ/6cgc1BrHoCiyotNDdI3zFAVsMZe7iTk0
zFHu1dbK3I8IzE+U8U5YLIBQZKALAdQ8yv+1ZytcJOOOdbNv8t20epmh01LxeHRw
1Mqmhxt7Nj+Dx+0UgYPH+05FshREYxS9nI0CPF0e3Bvae+0Dre++qxWITWkfHUtP
9hWVn55GvJyLotQOesFHhCy1TrL43VNw/3+fh1H2crbQ2GY0d+j0Fo4V1srEQFY2
nJAjw4c5mRH+MoFcvtts/Cj4xAeIdLTJ66j61unBhmV4EjlJd6NNdhx299CaIrSr
UcXsHTrfpCUvNdQOChB/
=HGQa
-----END PGP SIGNATURE-----