For all we know, they could be the same die throughout the entire Stratix III line or parts of it, with yield-disabled LEs, they could even have two or three base die masks where all can potentially be smaller products but only one or two of them could be SL150..., there could be different mask or process revisions throughout time affecting die size, etc.
It doesn't work like this in the FPGA business. You just cannot sell the chips with eg. half of the cache disabled, like CPU. The exact planar routing structure of any FPGA is discoverable. About the only permanent defect that can make a chip still sellable is in some of the I/O pads: the same chips are packaged in various carriers with different pinout counts. It is possible to market chips with various parts of the circuitry significantly derated. But those chips receive a different catalog number and internal identification number readable by eg. JTAG. Brand protection of the manufecturer demands such measures. |
|
|
|
Care to elaborate? Seems exactly the opposite would be true.
With connection-less trading a sudden trading spike is indistinguishable from a DDoS attack. Because setting up and tearing down TCP/IP connection involves several small packets you will learn that your networking infrastructure has two limits: bps (bits per second) and pps (packets per second) and you will be governed by the pps limit (while staying far away from bps limit) during the most important periods of the trading. The connection failure rates will greatly increase, this will be visible on your side as storms of inquisitive verbs (STAT, STATJSON, etc.) The quote/status dissemination during an active trading is just so much more efficient with the stream-oriented protocols that there isn't much room for discussion when comparing it with RPC-style polling. In addition to the above "ideal world" failure mode, in a "real world" case when somebody actually tries to DDoS you you can mount the defenses much cheaper and much more efficiently if you'll require keeping up the connection while trading. Socially, I find this RPC-trading phenomenon puzzling. The very same people who obsessively tune their gaming rigs for minimum lag suddenly are fine with the lag values several orders of magnitude higher when trading for real money instead of playing for toy money. |
|
|
|
One of the very few places that still define the word shill is Nevada Gaming Commission Control Board: Card game shill: An employee engaged and financed by the licensee as a player for the purpose of starting and/or maintaining a sufficient number of players in a card game.
I'm not aware of any recent rulings. But around 2000 there was a ruling about shilling on the trade show "World Gaming Expo" for the purpose of creating traffic in an exhibition booth. They were hiring women strippers to wear the business suits and show up in the booth and ask questions. They were ruled to be shills, regardless of what they were displaying on the badge or the business card. |
|
|
|
What could go wrong there? Should it take more time than just few ms to execute?
Probably a dedlock. If you can build the bitcoind yourself you can quickly debug it further with db_stat. Just build the BerkelyDB utilities with exactly the same settings as the BerkeleyDB library. Then create DB_CONFIG file containing single line "set_lg_dir database". After that you should be able to monitor the live BerkeleyDB environment using db_stat and db_deadlock. Well, at least this is how it worked with previous versions of bitcoind. I haven't tested this with the most recent ones. |
|
|
|
From the great comments to date, I may have to rethink this idea a tad. I see that most aspects have been covered in some way or another.
Whatever you come up with, you have to remember that phone numbers have country code. If you are going to post any more phone numbers in the format without country code eg. (1)(503)580-3900; +1.503.580-3900; etc. I reserve the right to tease you mercilessly. |
|
|
|
Pilzner :-D. I'm not sure if we can use that name because of trademark...
Well, all good names are already taken, eg. Česká zbrojovka. So maybe: Plzeňská zbrojovka? CZ has a good name recognition in the USA for their side-arms. So just maybe "Zbroyovka"? This way the name will be pronounced reasonably correctly by Anglophones. Misspelling of "j" as "y" should give you a reasonable trademark defense in the Czech Republic, no? |
|
|
|
|
Zbrojnice or Zbrojnica or Zbrojovka.
or the same with more Anglicized spelling:
Zbroynice or Zbroynica or Zbroyovka.
Also, any Czech product that has "pilzner" in the name is almost guaranteed to sell well worldwide.
|
|
|
|
Afaik these attacks are more teoretical than in daily use. I'm not saying that it is impossible to get seed with unrestricted physical access to the wallet and good laboratory equipment. But still wallet owner have enough time to send his coins outside the seed.
Even with those teoretical attacks, real safety of such wallet is much higher than any existing solution.
The good laboratory equipment is required only to design the attack. Once you have the attack developed it takes very cheap equipment to implement it, because you already know how and where to look on the chip-pin waveform. Maybe if people develop a habit of frequently connecting it their mobile phone or otherwise involve it in their daily routines their reaction to physical theft will be quick enough to prevent the logical theft of bitcoins. Edit: Actually I recalled a bit. I believe you are located in Prague, Czechia. There's a company there called BLADOX and there was a guy called Deian or Deyan that had found some very creative ways to abuse their products. |
|
|
|
http://www.nxp.com/documents/application_note/AN10968.pdfChapter 3 (page 4) describes security level of the chip we currently want to use. Do you know about some cheap and quick solution how to skip this protection and read the seed from the device? It is probably possible to read memory with high level laboratory equipment, but purpose of seed protection is that attacker need some time to read memory, so original owner can reload the seed to another device and send his coins out of compromised seed. I'm personally out of the hardware design business for many years now. But people like http://www.mcu-reverse.com/ could give an estimate. Now that you've given the intended part number interested people can look up the information about various side-channel attacks on those chips. From a brief description of your intended deterministic wallet design I presume that it will be sufficient to exfiltrate only 512 bits to empty the whole wallet. Thank you very much for your disclosure. Edit: I'm adding a link to my earlier post about how to strenghten an USB-powered device against side-channel attacks. I know that your chip of choice lacks NEON, but please read it to the end. https://bitcointalk.org/index.php?topic=78614.msg931995#msg931995 |
|
|
|
* Impossibility to obtain private keys from the device in a case of theft
Everything looks very nice, with the exception of this one point. Probably an average pirate TV-decoder-card vendor would be able to retrieve the private keys. Slush, would you kindly ask Mr. stick for additional information to substantiate the above claim? Thanks. |
|
|
|
So one distributes the source code under a FLOSS license, provides instructions on downloading the free as in free beer Visual Studio 2012 Express and compiling the software and bingo the censorship is effectively bypassed. In other words one can have software freedom, but only if one compiles the software oneself. A very interesting idea.
Yes, exactly. Thank you for extending the effort to understand this. I was afraid that my explanations are too convoluted or assume some advanced knowledge. It would be also good for the Bitcoin itself if more users could actually build the Bitcoin application themselves and not rely on the high priesthood to provide them with a pre-made build. |
|
|
|
It is a Windows RT device, which means that all software for this device must be distributed via the Microsoft store. It is a closed censored ecosystem like Apple iPhone / iPad.
Well, I don't have an actual device itself, but my coworker has some evaluation unit from Korea. He is saying that it works exactly like Apple iOS devices except that the cost of development license is zero. On your own device, with your own developer license, you can run whatever you like. This is why I said it would be a good test of open-source-ness: Satoshi Bitcoin client that anyone can build using free development tools (free as in free beer: Visual Studio 2012 Express). It would be a great experiment in portability and resilience of Bitcoin. |
|
|
|
Are you aware of the fact that you will not be able to use Bitcoin with this device without first obtaining permission from Microsoft?
Ultimately you are probably right. But the current situation is that anyone can get a developers license for free together with Visual Studio 2012. So for the moment this would be an actual test of open-source-ness. |
|
|
|
You're hedging positions WITH deposits. (This, IMO, is precisely what lead to the "thefts" at bitcoinica, which I continue to suspect to have been staged to cover up exactly this type of loss of customer deposits.)
Good thinking. But because of the "cold wallet" only a fraction of deposits would be available for hedging. |
|
|
|
Otherwise, this discussion is about two different mechanisms to achieve the same end result. My core argument is the the trie-based solution is much less complex overall, easier to implement and get right, and has numerous other benefits -- such as dead-simple rollbacks and the whole thing is parallelizable (different threads/CPUs/servers can maintain different sub-branches of a patricia tree, and report their results can easily be accumulated at the end -- this is not possible with BSTs). If you want to contribute to this discussion, then please do.
Again, the claim "this is not possible with BSTs" about impossibility of parallelism in b-trees is false. I wonder what is going on here? |
|
|
|
It will almost certainly require a specific implementation in every language clients need. This has dangers, but it's not impossible. Extensive test sets will be needed that have 100% coverage in a reference implementation, to be sure every edge case or weird rebalancing rule is tested.
I think the requirement for "every language" is a vast overkill. I would say from my past experience is sufficient to have a clean portable C implemenation (or C++ implementation in a C-style, without the reliance on the unstable C++ language features like std::* or boost::*). Once that's done in my experience the code can be transcribed to just about anything that is Turing-equivalent. But such C (or subset-C++) implementation will have to be correctly deal with endianness and alignment issues. I'm not sure if the core development team is willing to commit to an endian-correct (or endian-neutral) implementation of Bitcoin. |
|
|
|
Because the structure is guaranteed.
I am not buying this guarantee. In this Bitcoin milieu I've soo much confused-endian (or accidental-endian) code that I will not take anything for granted, least of which that there will be a sensible agreement on how to represent the bignums. Edit: Or maybe I will state it like this: The structure will be guaranteed so long as any implementor is confused the same way as the original authors of the Satoshi client and finds the implementation errors made in the original client obvious and natural. |
|
|
|
I generally approve of the idea of prototyping the meta-chain CONOPs, and let people/devs start thrashing out how to use it, how to improve it etc. However, if you're arguing for simplicity, then you must use the Trie/Patricia/De la Brandais tree. There is no need for snapshotting/backups. Put the data in. If a block has to be rolled back, remove them from the tree. For a given snapshot in time, all Trie-based implementations will agree. It's part of their design. This just won't be possible using BST's, though. It's not a matter of preference, it's a matter of standardization. If you use BST, you might be inclined to use STL map<a,b> in C++, or similar implementation in Java, etc. But the map<> data structure will be designed/optimized different for each architecture, compiler, and OS. There's no guarantee that a BST in Linux using gcc 4.3 will even match the BST implementation in Linux gcc 4.8 -- they might've changed the BST implementation under-the-hood, optimizing the rebalancing operations differently. And you'd never know, because underlying tree structure is not specified in the C++ standard for map<>. Only the expected run times of insert/delete/query/etc. So, miners won't be able to agree on the root hash unless they all build the BST exactly the same way, so they must agree on the BST algorithm to use. Who's writing that implementation? Will they create an implementation of the exact same algorithm in C, Java, C++, haskell, etc? This is why I keep pushing Trie-based algorithms -- any implementation of the Trie (or whatever variant is agreed upon) will work. A trie that is implemented in C++ by someone in China can be used to produce the same root hash as a Java implementation written by some kid in his basement in Idaho (assuming the implementations are correct). Yes, it's possible to BSTs, but it's a lot of work. And it's not simple. To design this data structure around BSTs requires every implementer of the meta-chain to use this specific BST algorithm. There is no such ambiguity with Trie structures -- you could look them up in any textbook. So, I agree that we should do this. It needs to be done and I think something like this is ultimately the future of BTC (especially lite nodes). If only I could get all my other priorities in Armory finished, then I would be focusing on this. The claim "This just won't be possible using BST's, though." is plain false. It confuses the data structure and algorithm with their implementation. This gotta be some sort of miscommunication, or maybe the author had too much fun at a party yesterday. |
|
|
|
If the exchange implements stateless by-payload security (such as the GPG scheme MPEx uses) then the exchange should also enforce unique-payload (either through hashing or some other method).
Hopefully to actually take the duplicate order you require at least a different IV (initialization vector) in the GPG armor and it is not sufficient to simply reformat the armored message. I personally don't like the houses where accepting duplicate(or otherwise confused) orders are part of the business plan. It always ends in litigation when somebody's cat steps on the keyboard and cleans the account. With the volume and frequency so low I'm inclined to think that the connection-less protocol is not a problem. It will be if the frequency of trades rises. In other words, a wizard does it?
I should've probably written "freakish" not just "extraordinary". It is more like a Rainman than a wizard. |
|
|
|
Anyway, given the interest Mr. P wrote out the specification a little, for this thing provisionally called BTC-UXP. All comments more than welcome. I did a quick look&see. It doesn't seem to have the protection against placing duplicate orders in case of transport failure/timeout. At the minimum all the imperative verb calls should have an OrderID argument that needs to be unique. There may be some sort of replay attack made out the above flaw, but I don't have a motivation to delve deeper. |
|
|
|
|
Show Posts
