For PC to PC communication, you use a null modem cable.  Over time, I think that the more common case will eventually be PC to device, which would use a standard straight serial cable.  More likely, the hardware wallet can emulate a serial port over bluetooth or USB.  The USB option would pose a risk to the computer, but in this model, it is the hardware wallet that needs to be protected, so we don't care.

The nice thing about USB to serial is that it usually presents at a high level so that you don't need to mess with the gory details of working with a 8250/16550 UART chip.  As long as the two ends agree on the speed and framing (19200, 8N1 is common), you can usually deal with it as just a character stream.

I don't know if USB to parallel adapters are really usable in bidirectional mode.  In theory, they should all support a clean 8 bit channel, and can even be chained to connect multiple devices, but in practice, parallel links tend to be hacked up 5 bit point to point systems using custom cables and abusing the printer status registers.

There are two ways to do offline wallets.  In one system, the offline wallet doesn't need any block data at all, and merely signs transactions presented to it.  In the other system, the wallet needs a tiny subset of the block chain, just the transactions it wants to redeem, but it creates the entire transaction internally and signs it.

I prefer the second system, so that the wallet can't be tricked into signing a transaction that it doesn't understand.  But it means that the wallet must accept block data that it cannot confirm.  This doesn't seem to be too big of a problem, since the transactions would be sent either by the point of sale terminal that wants to get paid, or from the user's semi-trusted home computer.  The worst that an attacker could do would be to trick the wallet into creating an invalid transaction.

As to the format of communication between the two devices, I prefer JSON because it is so simple.  ASCII armor is more suitable if you are passing files around and need them to be portable across a bunch of different systems.  But if you have a live communication link, it doesn't seem ideal.

Don't write off serial just yet.  While new computers don't come with serial ports, thanks to USB, you can add a port to just about anything for like $10.  And two of the other things you listed, bluetooth and infrared, are just virtual serial ports.

Way back in June, I wrote up a plan to give the standard client the features that would be needed to let users detach their wallet nodes from their network nodes.  I saw it as the first step towards having small dedicated hardware wallets.

If you are planning to do a serious offline mode, you might want to take a look.

It is a very common compression library.  You should be able to install it with:

Because of the network provisioning, I get the best results with PXE booting and RAM drive.  No storage in my nodes at all.

Any suggestions for a new name?  I wanted to keep it similar to linuxcoin out of respect for Drgr33n's base that I built on, but clearly indicate that it uses p2pool.


Updates are super easy.  Just burn a new CD, write a new flash drive, or replace your PXE image, then reboot fully.

Fixed.  Not sure how my script missed that.  Thanks for pointing it out.

The offline 51% (or really 101%) attack problem is preventable if we want it to be.  No insurance companies or outside complications needed.

No, I'm talking about the increasing-overhead to scale problem.  Or, at least the apparent overhead.

The bigger your mining operation is, the harder it is to ignore your overhead.  A couple hundred megahashes per second requires no infrastructure, since it is just a video card or two that you already own, and a small fraction of your monthly power and network bills.  A couple of terahashes per second is going to need its own building(s) with dedicated generators and multiple internet connections.

The red line and the green line are noise.  Even the blue line is sketchy.

Wait a second.  You think that the monopoly miner will be able to leave most of their hashing power offline, as a fleet-in-being?  Won't that just make the scaling effects worse?

You can't just repeat your unfounded statement and expect anyone to believe it.  Adding a stupid hypothetical isn't enough either.

If you want someone to believe you, you are going to need to examine the huge piles of data that clearly show the exact opposite of what you are saying, and you need to point out how all of it is wrong.

Good luck with that.

Because all of the commercial SHA chips are designed for an operation that doesn't apply to bitcoin mining.

Bitcoin mining is done by hashing huge numbers of distinct two-block inputs.  SHA chips are designed to do small numbers of many-block inputs.

Think of the difference between a billion files of 1000 bytes each, and a thousand files of a billion bytes each.

If you are interested in p2pool mining, I've hacked up a version of linuxcoin for that.  I call it p2pcoin, for lack of a better name.  I think BAMT is also a dedicated mining distribution, but I don't know much about it.

Go back a few pages.  This is a known problem with bitcoind 0.6.0rc1.  You need to either upgrade to rc2, or add a -paytoscripthashtime option to your config file or command line.

Mine at a loss?  I thought that was what we were all doing already.

If we want to keep abusing the lottery analogy, I should point out that every single node on the entire network "wins" about once a week, just not all at the same time.

I had typed up a lengthy reply last night, but I paused to consider what you have said on the subject, and then I slept on it.

My conclusion is that you haven't actually read, or at least not understood, a thing that I've said.  I have two reasons for thinking that.

First, you have completely misunderstood the problem.  See here for example.  Important part quoted below.


And second, you have completely ignored the parts of my posts where I explain the mechanism to be used by nodes to resolve their temporary, local conflicts.  Example here.

Let me be very clear.  I propose that:
1. nodes temporarily reject blocks that they can identify as antisocial.  Nodes already temporarily reject blocks, but for different reasons.
2. nodes have a method whereby a block that was temporarily rejected can become accepted.  Again, nodes already do this.

Further, I assert that:
1. these will not lead to permanent or even long-lived chain forks, for exactly the same reason that the ordinary chain forks that we get about once a week are not permanent, and can't become permanent.
2. any method used to game the system to create blocks that include only dummy transactions created by the attacker to circumvent rejection will necessarily require more effort than simply doing the right thing (including ordinary transactions), giving the current antisocial miner(s) a strong incentive to become a positive part of the network.

Ok, that will work after they've achieved majority, as long as they hold majority, but will not help them become the majority.

If I could decree that everyone had to have a firm understanding of just one concept before getting out of high school, it would be the dynamic equilibrium.  You can hardly swing a cat without hitting dozens of things that appear to be static, but are actually just metastable points in the interaction of two opposing forces that feed back on one another.

A failure to understand this concept is responsible for the difficulty people have with understanding market processes, leading them to extrapolate things that ought not be extrapolated, and then to make economic claims that they ought not make.

If anyone reading this thread doesn't understand what realnowhereman posted above, please, I beg you, go to wikipedia and read about evaporation and precipitation until you understand the common process and can see it in everything around you.

Attractive is not a sufficient condition.  You also need to have a mechanism whereby the monopoly/oligopoly seekers are able to bar entry into the field.

Every three days (roughly) is rare to you?  I don't think you'll find many people to agree with that.  And it is only unpredictable if you need it to happen on a specific block.  If you don't care which block it happens on, then you just need to wait a bit.

The forks that would happen under this plan would be essentially identical to the forks that happen now, and they would be resolved in the same way, and in roughly the same amount of time.

P.S.  Your "flood the network with transactions" attack only works in a world without clocks.  In a world with clocks, like the one we live in, we can keep a count of how many valid transactions were visible X seconds ago, where X is greater than roughly double the mean latency of the network.  30 would be a good value for X.