Actually the RSA's design isn't tough. It is very resilient because of the eyelet attachment turns freely and completely avoids the shear stress.

If you are going to die-cast the metal ask the mold designer to optimize the eyelet for the manufacturability instead of just plainly making a bid for the existing design. As it is right now you'll have cracks in the left, narrowest portion of the eyelet and the possibility of voids in the bottom, widest portion. I'm pretty sure that your current design could be spin-molded properly (rotocasting). But for the standard die-casting the metal will have to flow to the widest, bottom, portion of the eyelet through the two much narrower branches. The eyelet will be under internal stress just from the uneven thermal shrinking of the metal after the casting is done.

The original design was obviously optimized for the best manufacturability: the narrowest portion is even and farthest away on the path of the metal flow. Although it does look weird to someone unfamiliar with the area rule.

Form follows function? Mind over matter?  

Both are very nice, but in the original design the eyelet was much stronger.

http://en.wikipedia.org/wiki/Stress_concentration

Perhaps you should consider moving the old eyelet to the new position, but maintaining the original shape that had smooth radius-of-curvature changes. It will be cheaper than the metal inlay reinforcement that companies like RSA (or car manufacturers) use in their keyfobs.

I really don't want to interfere with your design, but my feeling is that a rarely-changing session_id will not be sufficient.

Fundamentally, you have a problem of synchronizing two state machines over a channel with erasures.

I'm not sure that the above problem has any simpler solution that the "sequence number" patterned after TCP over IP (or X-MODEM or Kermit protocol.)

The session_id would be then equivalent to seqence numbers starting with a value different than zero and different for each session.

Again, those are my feelings. I don't have a concrete proof, neither for nor against.

Edit: On the other hand I still remember the lesson you taught me in the Stratum thread: the protocol has to be conceptually simple enough to be reasonably implemented by the majority of the Bitcoin application programmers. If the price is an occasional, rare failure then it is worth to pay it.

pooler's cpuminer will mine both Bitcoins and Litecons. You'll have to recompile to take advantage of the new instructions and massive multithreading. To fully utilize the long vector units you'll probably need to restructure to loops somewhat.

https://bitcointalk.org/index.php?topic=55038.0

Unrelated to the above, there is one more design decision that you may need to make.

It seems that as it stands right now the protocol may be training the user to blindly press the button without actually looking at the LCD screen.

In the medical device field there is an ongoing discussion: what is the correct level of interaction required to dismiss a dialog about potentially dangerous and irreversible action.

1) pressing always the same button to approve after hearing a beep or always another button to cancel and hear another acknowledgement tone;

2) pressing exactly one of 4-10 buttons after reading the message, and where the message tells which button to press and the number of the button needs to change with repeated presentation of the same message. Pressing any other button than indicated in the message is interpreted as cancellation.

In case of the Piglet the button on the device would be still the same, single one, but the user would be required to look at the screen and the screen would tell the user which key to press on the computer's keyboard.

The medical field apparently still cannot agree which way to go on this.

In my experience the response to the Ping message should contain a non-optional sequence number. This is particularly important in case of the device like yours that may require slight physical rotation to be able to read the LCD and/or may be jostled while pressing the button.

Theoretically the OS should issue USB disconnect/connect events in case of the brief interruption sensed on the USB port, Windows even plays a warning chime. But in practice this doesn't work 100% reliably and the USB device may get reset while being handled by the user to complete the required interaction.

There could be also an opposite situation where the USB device is plugged to the powered USB hub. The user interaction could cause hub disconnection, but the device's internal state would not be affected, despite the application receiving and handling the disconnect/connect events. If the application can detect that the device hadn't lost the internal state it may save the user some aggravation caused by a repeated initialization and retry.

I now understand where I made a mistake. I want  to apologize and make a correction.

When I wrote yesterday:
I had in mind the effects of the following events from middle of last year:

1) Bitcoin Consultancy touring continental Europe, establishing an office in Warsaw,Poland and having various promotional meetings there:

https://bitcointalk.org/index.php?topic=26919.msg338755#msg338755

2) 1000 BTC bounty for getting a major business to accept Bitcoins as payment:
 
https://bitcointalk.org/index.php?topic=46646.msg555039#msg555039

Because of the above efforts some people have privately offered a "bitcoind Enterprise Edition" (based on the private branch of the public 0.3.23 code):

https://bitcointalk.org/index.php?topic=42444.msg531318#msg531318
https://bitcointalk.org/index.php?topic=46646.msg558545#msg558545

I was involved in an informal code audit of those offerings. They were spectacularly bad and I allowed my perception of that code to influence my perception of the wider Bitcoin community. The multiple discussions with lawyers even influenced my writing style, as observed by Mr. marcus_of_augustus .

I want to publicly apologize for my unqualified statements made yesterday. I also want to publicly thank:

a) Mr. casascius for publicly pointing to me my errors,
b) Mr. Transisto for privately pointing to me that my posts yesterday were flawed.

I'm sorry.

Yeah, you are 100% right. As written the document pretty much assumes that the reader has a Master of Science in Computer Engineering or equivalent and some past experience reading patent applications in the relevant field.

The more plain-spoken description of "digital prospectus" is: a cryptographically signed machine-executable description of the rules of the block validity. As opposed of the solemny sworn human-language statements of the core development group that they aren't going to materially change the rules for the valid blocks.

As with all "far-looking forward statements" the readability here is low. But the law is what it is and readability comes second after unambiguity.

I'm planning to re-edit the document in the future, once I collect enough feedback how to do it without transoforming it into a meaningless marketing drivel. It isn't an offer to sell anything.

Edit: and by the way, here's the pointer with explanation why it stays 2112 as opposed to the number that it go assigned.

https://bitcointalk.org/index.php?topic=61575.msg723630#msg723630

The answer to "why not" is two pronged.

1) The mills of justice turn slow, but grind exceedingly fine. Just read the first paragraph of my BIP 2112 proposal. As a technical advisor/export to a plaintiff all my Bitcoin-related correspondence is potentialy subject to the discovery by the defendant counsel. I don't want to get involved in some sort interferrence accusactions, conflicts of interests, etc. I use my "social capital" to post here as a premier cryptocurrency forum to assure that everything technical I wrote is a matter of public domain and cannot become some sort of submarine patent. It really is secondary whether somebody implements my ideas or not. They just have to be matter of public domain.

2) IMHO another real-time, reflective, in-vivo alt-chain is not the way to go and waste of the effort. IMHO the cryptocurrency field will be stagnant until some enterprising biz-school grad or doctoral student does some sort of in-vitro discrete-time simulation experiments using GPSS or some such. When the headline will be something like "100-years of Bitcoin evolution simulated overnight" it will mean that the crypto-currencies have arrived as a field of research.

I mean I don't mind and even support you and others discussing alternatives. It is important to keep the ideas in the open, public domain. But it somewhat resembles the philosophical "what if?" discussions I've heard in the theological departments. But when the "what if?" are much-faster-than-real time animations then the actual scientific discovery will happen and the whole field will move forward. Either as a field of research or as an venture investment opportunity.

Nice, fast-moving WebGPSS or similar animations sell better than the walls of text or pages of certifiably-secure cryptographic algorithms. My contributions are really mundane, on the par of "how to make a good oil-pan washer so your engine won't seize even on the bumpiest road".

You wrote a very nice argument, with which I mostly agree. It is just your use of the word "make". If you meant "make = force", then I'm fully with you.

But if you meant "make = induce" or "make = enable", then in my opinion you are wrong. Especially on the purely software technical side this project became a great enabler and inducer for incompetent programmers.

Looking purely at the effects it is hard to distinguish incompetence from the opportunistic treachery, cf. bitfloor fiasco. But the end result can be widely observed: Bitcoin started as a rather low-quality proof-of-concept code. It had no (or very few) remote exploit-style faults and this somehow became equivalent to the claim that Bitcoin is almost perfect "Mona Lisa"-quality financial code, cf. Dan Kaminsky presentation.

Well, the reality is that Bitcoin is far from perfect (in the financial software engineering realm) and has an unfortunate property of attracting some of the worst programming anti-talent. The profession of software engineering is completely unregulated, neither legaly nor morally. This is unlike eg. construction engineering, where enough people died in collapsed structures or simply lost the roof over their head to understand the value of the "building code". Similarly, one doesn't have to be electrical engineer to understand the value of "electrical code" or a firefighter to understand the value of "fire safety code".

There's still not enough people who lost their savings or operating funds to make the broad Bitcoin users community understand the value of high-quality software.

At least the bitomat.pl operator did his share and is now a perfect example of what will happen if you disregard the word "ephemeral" in the documentation of Amazon Web Services.

Edit: This post unfortunately lacks propert contextual qualification. I'm posting an apology below.

https://bitcointalk.org/index.php?topic=6825.msg1337000#msg1337000

We had this discussion already. Search the past posts of etotheipi, Jan and  ThomasV for the analysis of various problems with these choices.

I have to repeat to you: hardware choice is secondary. The good protocol design comes first. The available hardware in the ARM space changes so furiously fast that it simply doesn't make sense to choose it now. Post the communication protocol-level suggestions related to the hardened crypto devices, not the hardware suggestions.

I'm still browsing around and I've found a ready made LPC11U37 kit with an LCD display, 8 touch sensors instead of buttons and various other expansion options for €69 and still within the 128kB limit of the free LPCXpresso IDE:

http://www.embeddedartists.com/products/app/lowpower_oryx

It has everything required to build a secure Bitcoin wallet without a need to solder a single wire. Only programming talent is required.

I'm not getting anything Cortex-M even if it is free. I really need to be able to run classic ARM code, not just Thumb.

Too complex. The real problem here is that most of the Bitcoin software developers are not familiar with the restrictions and challenges of bare metal embedded programming.

The choices of someone42/slush/stick are so great and so beautiful because anyone who tries them will have their first trivial embedded project working on the same evening that the package was delivered.

The real challenge now is not to be super-secure. It to to agree to a common hardware wallet protocol that could be sensibly implemented bare-metal on a simple hardware, not a discared Intel laptop or obsolete Android phone/tablet with their attendant problem of the security of the underlying OS.

I on the other hand think that sitck and slush made excellent choice. I only have an issue with the original claim that it is impossible to extract the keys from the device after a theft. Just reduce the claim somewhat and you'll be more than fine.

The main problem with using "real smartcard" device lies in the unvieldy development process for the "real crypto stuff".

On the other hand the choice displayed here (looks like LPCXpresso LPC1343) and in the similar thread https://bitcointalk.org/index.php?topic=78614.0 (mbed LPC11U24) is an excellent starting point for learning and development. It is important to stress that anyone involved in Bitcoin development will be about €30-€60 away from being able to actively test and develop the future Bitcoin wallet device protocol.


I know this forum is full of people capable of programming (or willing to learn programming) therefore I'm going to post some links for the people who may find this project interesting from the purely programmatic side, disregarding for now the actual design of the hardware.

The good starting devices are the two following: mbed LPC11U24 and LPCXpresso LPC1347 (LPCXpresso LPC1343 is now obsolete). The first one comes with an online IDE suite at http://mbed.org/handbook/mbed-Compiler , the second one is supported by a free (as in beer) LPCXpresso IDE http://www.code-red-tech.com/RedSuite5/lpcxpresso-5.php .

Both boards seem to be the designs from http://www.embeddedartists.com/ , they just differ in how they are marketed.

You probably will not be well served by buying the higher end mbed LPC1768 or LPCXpresso LPC1769 boards because they lack the on-chip EEPROM (a.k.a. parallel, byte-erasable NOR flash). You don't want to go into the tribulations of programming NAND flash in your first embedded project.

For me none of those choices is good because the Cortex-M processors in those controllers don't execute the legacy ARM code, only the new-fangled Thumb code. So I'm still looking for a nice small USB-powered ARM development board.

Thank you very much for the additional information you gave.

I clicked around on the NXP's web site to see how thin is the ice you are skating on. It is very thin: 32kB is the maximum firmware size in the chips you selected.

LPC11U2x family is 24-32/1-2-4/6-8 Flash/EEPROM/SRAM

LPC11U3x family is 40-48-64-96-128/4/8-10-12 Flash/EEPROM/SRAM

I didn't to a thorough price research but the random price comparison gave me $2.26 for 11U24 and $3.14 for 11U37.

The very important additional information is that the free version of LPCXpresso platform will allow the user to build an executable of any size, but there is a restriction in terms of code download which is 128kB.

The target market here is open-source tinkerers. They are not going to be much affected by a price difference of about $5.

So I suggest switch to the top-of-the-line LPC11U37 with the compatible package if possible. People will buy it just for the opportunity to tinker with it.

Edit: Thanks again for posting the address space utilization numbers. I wasn't really aware how thinly shaved some of the ARM-licensed designs are. I was talking about NEON and SIMD-like coding and these devices have a software integer division in ROM! Sorry. The oldest and smallest embedded design I ever worked on used full 8-bit address space of 64kB divided between DRAM and EPROM.

Among Bitcoiners the words "big endian" mean different thing than anywhere else. In a regular world computer scientists would call it "confused endian", "accidental endian", "crazy endian", "beginner's mistake endian", "consultant padding billable hours endian", "we made a mistake and are ashamed to admit it endian", "deranged endian", "tragicomic endian", etc.

It is a representation where a bignum quantity is first divided into words 4 bytes wide. The words are ordered starting with most significant word at the lowest position. The bytes within the words are ordered with the least significant byte at the lowest position.

Edit: OK, I've found a good name for this representation: mojibake endian. It should go well with Satoshi.

http://en.wikipedia.org/wiki/Mojibake

1) testnet coins version
2) any alt-coin version

With the amount of hate that alt-coins are getting on this forum some people will start trading the regular bitcoins on your site just to spite the alt-coiners.

Kano is trolling, but he's a constructive troll, so his message is worth replying to. I was trying to find a link to the source code of utility I used for testing, but I can't seem to locate it. It was an offshot of "ttcp".

1) RX/TX statistics in many modern NIC are always zero, unless explicitly enabled. Somebody explained to me that it has something to do with passing WHQL certification. There are (or were) apparently two levels of it: normal and certified-for-clusters. At the "normal" level it is apparently much easier to get the "compatible with Windows X" certification if errors are reported only in specific circumstances. To get uncensored statistics you'll may need to place the chip in the "enterprise" or "diagnostic" or "cluster" mode. (Not to be confused with 802.3ad link aggregation or similar stuff).

2) To get a real feel for real packet loss use "ttcp" and monitor "netstat -s". For deepest understanding use both TCP/IP and UDP/IP mode with various buffer sizes.

3) There used to be a version of "ttcp" that supported one-sided testing by connecting on the remote side to the "simple IP services": echo, discard, chargen. Nowadays they need to be enabled explicitly. They aren't really usefull for benchmarking, but they are greatly useful to see if your network hub/switch/router can really cope with many hosts talking simultaneously. Please post here if you find such an utility.

4) If you see the statistics jumping in multiplies of 16777216 instead of 1 then don't assume that the driver is majorly broken. It may simply use incorrect byte order. So swap the byte order by hand or write a short script to do byte swap.

5) Some older Unix-compatible systems still have the spray/sprayd pair of programs used for packet loss testing. You may need to explicitly enable it, but it is a very easy to use program.

Have fun.

I can't really fault your theoretical analysis. What you wrote is quite right, especially about the benefit of multicasting. But I really doubt that you've actually run such configuration for any significant period of time.

I actually have production experience with multiple clusters in multiple physical/organizational locations with quite similar properties to the ones you've described: about 50/50 mixture of multicast/unicast packets, traffic non-peaky but near-uniform, short packets.

It is our observation that to achieve effective 0% packet loss we needed to specify either Cisco Catalyst (or similar class) switches or
(quite strangely) old Allied Telesyn/NetGear ProSafe/Intel InBusiness/etc. fixed-speed (or managed) hubs. The popular unmanaged office switches like NetGear/D-Link/Cisco Linksys were all showing anywere from serval through several tens to hundred-something occurences of packet corruption/loss per day. The steady-state packet rate is 50Hz-100Hz (or pps).

Our conjecture about those rare but steady failures is that this is somehow related to how the small/cheap switches pass as FCC Class B. To get home-office rating vendors use spread spectrum clocking, which is in effect an intentional jitter. So in order to get best performance use either FCC Class A data-center grade devices or cheap obsolete hubs that passed FCC Class B because they work under CSMA/CD principle.

Oh, and an additional free piece of advice who want to build cheap multicast clusters with hubs: test whether your network adapters actually do support half-duplex. Quite a number of devices claim to support half-duplex but actually don't and need upgraded firmware or simply a replacement. Various versions of popular LNE100TX & KNE100TX are common culprits; but there are so many variants of them that you'll really need exact part numbers. Some versions of Intel PRO/100+ line drivers for Windows don't correctly work with half-duplex.

Actually if you measure the packet loss statistic you'll find that using only hubs (or even just one hub) will give you best results. Run-of-the-mill Ethernet switches have unfortunately quite bad error probabilities.

Even the top-of-the-line Ethernet switches with 802.3x and 802.1p are just about equaling error rates of a cheap fixed-speed 10BaseT or 100BaseTX hubs with all cards correctly supporting the collision detection/exponential backoff/retry.