The system is a chaotic multi-variable nonlinear system where all the parts are interlinked.  Please stop trying to make sense of it by inventing serial relationships that do not exist.

If you serialize it into a false string of A causes B causes C relationships, you can be absolutely positive that you will never understand it.

Edit: 2011-06-26, proofreading failure.  understanding

Should be trivial to recognize and allow a transaction that differs only in the fee (and thus, the change).

It might also be a good idea to alter the spend behavior to include a little change in the input even when not strictly necessary, so that the resend attempt doesn't need to add a new input.

I would still stick with Molex 8981.  People using bench supplies can easily stick a Molex on their wiring, and people using ATX are already set.  If you use a different connector, then everyone has to make custom cables.

And I would go with a 240 pin DIMM socket for the cards.  Figure on about a third of the pins being grounds.  Add a few for SPD, a few more for JTAG, a few more for whatever serial bus you come up with.  Still leaves you with plenty of open pins for power, even if you go with 8 or 10 pins for each likely voltage level.

Sounds like he and I came to the same conclusions, he just beat me by a month or two.

I really need to start hanging out on IRC.

I suspect that people will just say "milli" or "micro", just like we now say "cent" rather than "percent of a dollar".

And mBTC will never be confused for MBTC.  The context will always make it clear.

If the device does all of the wallet stuff itself, you can take it on the road.

I want this thing to be my wallet.  Not a glorified dongle that allows me access to the wallet stored on my PC.

Bitcoin is the first non-government money system that I think would be suitable for becoming an official currency.  The main problem right now is that the market is so tiny.  No one can really throw the Euro or the Dollar around, but with a couple million dollars someone could easily take BTC on a violent rollercoaster ride until everyone runs away puking.

These little countries use major reserve currencies because they are too big to mess with, not because they really care about the currency itself, or the nation that issues it.  Oh, and don't forget geography.  Using the same money as your neighbors is another big advantage.

So, to answer the OP, bitcoin needs to grow first.  And then it will be suitable to be granted legal tender status by some nation.

Your real wallet is in the device.  The PC on your desk can keep a copy of the public keys so that it can show you your current balance as a convenience, but that's it.  When you want to pay, it sends the destination address and the amount, only.  The device then creates the transaction all by itself, using transaction records it already knows.


Encrypting the whole thing would certainly work, but it is probably overkill.  You can't just encrypt the data using the keys themselves, or you provide the attacker with a whole lot of known plaintext to degrade your key with.  Most encrypted streams exchange session keys and do a whole lot of crap behind the scenes, and we would have to do all of that ourselves, all to protect stuff that doesn't really need to be protected.

Simple hashing seems sufficient.  At least for now.  Eventually, sure, we'll probably want the serial communication to be encrypted.  But for the first step, I'd like to be able to debug the thing with a 'scope.

Just like a regular bitcoin, but slightly larger.

I think the easiest way to do it would be to add BTC as a new currency on the existing system of magstripe readers. 

Of course, if you don't want to wait for Visa, MC or Discover to catch on, it'll have to be all online.  Start with a website, then add an API that lets ecommerce developers and POS vendors add your system as another payment method.

There will also be commercial services in the future to provide trustworthy information.  I might even do it myself if this ever catches on.

The secure device needs copies of all blocks involving keys that it contains, so that it can generate new transactions later.  It would use this request to ask for them.  As an aside, the secure device should only make this request upon a command from the user.  That way you can plug into your home box, which is probably honest, and update your information, but when you plug it into a retail POS, you don't give it the chance to give you bogus data.


Unless the tiny spec I read was missing something, there was no way in JSON to authenticate, that detail being left up to the layer below.  Since there is no layer below when using serial, either we make one, or we use digests to authenticate commands.

My first guess is that there is nothing in any of these commands or responses that needs to be kept secret, but a few things that we would like to have authenticated.

Correct.  The thread for it is buried deep, page 8.  That's a lot of new topics for 3 weeks.

At any rate, yes, posts 29 to 37 inclusive are about my proposal, and are sorta off topic for this thread.  I like to point out that these attacks can be changed from improbable to impossible, and it occasionally leads to the tangent seen above.


It would be pretty easy to code a startup mode where the client gets multiple copies of all blocks until it catches up.  And even if it does become a poisoned node, it still prevents a poisoned network.

Double the unpaired one.  https://en.bitcoin.it/wiki/Protocol_specification#Merkle_Trees

Cool thanks, Richard.  I don't get over that way very often, but I'll be sure to grab a beer the next time I do.

I have a highly scientific Bitcoin Value Predictor (dartboard) in my office.  Using careful analysis (mean of 3 sums of 3 throws), I calculate $27.333333 per BTC.

Grow some thicker skin.  I answered your question, and I only insulted you personally.  You, on the other hand insulted the entire community (very slightly) by disregarding forum etiquette.

Good luck with your post count and your mtgox account.

Even better.  You don't know which coins you are getting until you already have them.  So now you have to send the tainted coins back, which is nearly impossible with the current client, or you can continue the transaction just as if you didn't use the blacklist at all, or you have effectively stolen them.

I couldn't tell without looking at the function, and I despise Java, so...  Hopefully someone familiar with bitcoinj will pop in and help.  Maybe change the subject of the thread.

Usually the first problem people run into when trying to parse/hash this stuff is the difference between network byte order and host byte order.

I just ordered a couple of shirts.  I had to get I DIG RIGS in gray because it wasn't available in black.  Of course, for that one particular shirt, you'd have to invert the black art and text.  And, since I already ordered a gray one, I'm unlikely to order another if you make a black one.

At any rate, I'm firmly in the always wear black camp, and if places like thinkgeek and tshirthell are any indication, I've got plenty of company.  Then again, your target demographic might be different, and I'm hardly an authority on the shirt business.

While I've got your ear, any thoughts on polo/golf/work shirts?  I'm thinking like this one but with a bitcoin logo.  I never seem to have enough subversive shirts that I can wear around the office.