I fully support adding checks to the signing code to detect degenerate conditions, but finding k=d doesn't mean you got really lucky, it means your RNG is completely and totally broken and you need to alert the user.

That day was back in like 2009 or 2010.  A difficulty of 1 corresponds to an average of 1 valid block per nonce range.  At difficulty 2, you expect to find one valid block per 2 full iterations through the range (on average).

I use this in the binary for p2pcoin's bitcoind:


I also have command line options for -addtag and -addhextag that I use to add my personal tags.  They are done pretty much the same way.

p2pool already has several unique features that can be used to identify the blocks.

And if you want your signature in a block, the patch to bitcoind is trivial. 

This question is oddly difficult in bitcoin.  In bitcoin, the hashes are used as identifiers.

As pointed out by others already, cryptographic hashing systems are essentially lossy compression.  For a given sha256 output, there is at least one input that creates it, and possibly an infinite number.  A block header is 80 bytes long, and a sha256 output is 256 bits long.  If we assume an even distribution for both the bits of a header (known to be false) and for sha256 (see previous posts, and my addition below), we can expect about 2³⁸⁴ possible block headers per block ID, with 384 being 640-256.

It gets messy in reality.  Large portions of the block header are not evenly distributed, and several of those portions are moving targets.  Someone could probably work up reasonable estimates for the actual bits of freedom for a given block header candidate, and from that estimate how many such candidates we can expect per output.  I find it interesting enough, but it is late, and I'm tired, so I won't bother.

With that pointless aside out of the way, back to identifiers.  We use the block header hashes as identifiers for the block.  The network enforces uniqueness of these identifiers in an odd way.  Say you are hashing along, and you find a nonce that satisfies a header for the next block, but by a strange twist of fate, that hash just happens to be equal to a freakishly low hash previously found*, perhaps one listed in this thread.  Your node announces this to peers by sending them a message with the new block's identifier.  They all ignore you, because they already "have" that block and so there is no point asking you for the rest of it.  I'm actually not sure how your node would even handle it.  I'd have to check the code to see if it would overwrite the old block, or drop the new one.  Odds are good that we'll never find out the hard way.

With transactions, it is even worse.  The same mechanism exists, but nodes do not (by default) keep full track of all transactions, just unspent ones.  It is possible** to create a new transaction that happens to have the same hash as an old transaction.  Again, I'm not sure how it would end up without reading the code.

* I'm not sure if this would qualify for impossibly good luck, or impossibly bad luck.  Certainly one of these extremes though

**  Not really.  The birthday attack on 2²⁵⁶ is still impossibly huge.



Indeed.  The output space of sha256 is currently unknown.  We suspect (hope) that it is close to [0-2²⁵⁶], but we don't exactly know that.  Cryptographic hashes look a hell of a lot like random numbers, by design.  One of the standard tests is to generate pairs of hashes from pairs of inputs that differ by a single flipped bit.  We expect that about half of the output bits will change between pairs, on average, and we expect a fairly flat distribution of flip counts for each bit position, again, on average.  The sha family passes these tests, and from this, we gain confidence (but not certainty) about the distribution of outputs.

This (visibility) is the key point.

(I had more commentary, but the forums ate it.)

The rationale is that since a node cannot know the relay policy of the peers it connects to, it will only create transactions that it itself would relay if they came from a peer.

This was actually discussed quite a bit, but that change produced such a flood of crap posts...

A tiny little part of the problem goes away, sure.  But not the whole thing.

What would be needed is a general means to monitor specific scriptPubKeys.  There has been a lot of discussion on that topic over the last few months.  Check the mailing list and IRC logs to see why it isn't a simple change to make.

This is a frequent complaint.  Search the boards for many more examples of threads substantially identical to yours.

Accounts do not work the way you think they do.  They are not intended for the use you are attempting.

Multisig addresses are not useful as-is.  External tools of some sort are required.

The reference implementation could be improved to be sure, but it will never be able to be the whole infrastructure for multisig.

As jgarzik notes, there are tools available already that are suitable for infrequent multisig usage.

For something like this, a supermajority of miners have to move in lockstep, or there is risk of forking.

Looks like the pads are totally gone.

Ask BFL for the other points on the board that are tied to the same nets as the USB pins.  Then, have someone that knows what they are doing solder small wires to those points, and then to a socket.

Early on, there was some debate about the proper encoding.  See this discussion for information on why the bogus encodings were allowed (specifically a post from gmaxwell on July 2nd).

Multisig addresses are fully visible in blocks, just like regular addresses.

Paste is simply not suitable here.

Paste is intended to fill in microscopic gaps between a single package and a single heatsink.  It can not and will not work on multiple chips with a single heatsink.

The root problem is that multiple chips are never coplanar.  Hell, even single chips are rarely parallel to the board.  If you have a single chip with a single heatsink mounted with springs, you can use paste to fill in the microscopic gaps between them while the springs allow the heatsink to float relative to the board, matching the chip's bulk surface.

If you have multiple chips, they will all be at funny angles, and all at different heights.  A single heatsink will never make good contact, not with all of them, and usually not even with one of them.  For multichip designs, it is customary to back the heatsink off by a millimeter or two, use a rigid mounting to the board, and fill in the substantial gap with a thermal pad.

Something like tflex 600 (PDF) would be appropriate.

Really hard to have sympathy for this.  You could have addressed the batch 2 problems many months ago, but chose not to.  How many tickets for missing orders did you ignore in May, June and July?

Possible option "E":  His next_nonce function was something other than ++.

The proper solution, of course, is to practice good computer hygiene so that you don't get malware.  As has already been pointed out, it is foolish to hope for only "dumb" malware.

Or, you know, not holding it at all.  Like me, for example.  I placed my B2 orders on February 3rd and hadn't heard a peep from them until a few days ago.

I wish I could say the same.  When I contacted him, he asked for details.  Haven't heard a peep back since I provided them.