So, why not just comply with the SEC and make GLBSE legal? I know easier said than done, but doable, right?
Not enough: money, brains, business acumen, future revenue, etc. Not doable at all with the current executive team and the current board of directors. |
|
|
|
It seems that each of the 8 asic chips has their own 3 or 4 phase vrm. Why would this be necessary? or even preferred? it seems like it would cut down on reliability and raise cost. If a 4 phase vrm can handle a 5870 chip at 150 watts why can't it handle all 8 asic chips at less than 100w
Au contraire. Multiple smaller regulators increase reliability and increase overall device yield. The hashing chips are http://en.wikipedia.org/wiki/Embarrassingly_parallel . If one (or more) of the many regulators fails the whole device continues to work at a reduced speed. And vice versa: the device can be populated with partially defective hashing chips. If the testing discovers a fault in some section of some hashing chip that section could be simply powered down and the whole device will remain useable. It is quite possible that in order to save money and time the individual hashing chips are only minimally tested before packaging and soldering into the board. The full tests are run only in the final shipping device. Finally, if the regulators are software-controlled this configuration would allow individual under/over-volting of the individual sections within individual chips. The comparison to the graphic card is simply invalid because the Bitcoin hasher uses no RAM whatsoever and does not require any high bandwidth bus interface like AGP/PCI/PCIe. It also has no high bandwidth output to the video monitor. |
|
|
|
Why not sqlite for the wallet (and maybe the blockchain) ?
In my opinion, even sqlite is overkill for the wallet. It's yet another dependency (something you don't like, right?), and all we need is a simple key-value store that is read at startup and loaded into memory. Probably we'll move to a very simple custom append-only format with checksums. For the blockchain: performance. LevelDB is exactly what we need: not more than a key-value store with atomic writes, with very good performance and consistency. It seems like almost every technical thread about bitcoin{d,-qt} needs to take a detour into the DB-land. I just wanted to stress that the "append-only" is the key concept to understand what is required architecturally to implement Bitcoin efficiently. Incidentally it is also a key ingredient to make any Bitcoin implementation GAAP-compliant. It is alway scary experience to post here a link to some Microsoft's web property. But this thread already has at least 2 posters who aren't scared of MSFT, so here it goes: http://blogs.msdn.com/b/pathelland/archive/2007/06/14/accountants-don-t-use-erasers.aspxLevelDB unfortunately will not be "exactly what we need" unless a significant reachitecturing is undertaken. Mike Hearn had explained this succintly. I'll find the link and post it here. https://bitcointalk.org/index.php?topic=94453.msg1048149#msg1048149Gavin Andressen had estimated that the rearchitecturing of storage layer could take up to 3 years anywhere from 1 to 3 years while seriously impacting other intended deliverables. Again I'll find the link and post it here. https://bitcointalk.org/index.php?topic=101011.msg1170970#msg1170970 |
|
|
|
You have clearly demonstrated that you are an asshole. But that doesn't mean I won't accept advice from you. Everyone has their own deficiencies, and clearly yours is a social deficiency, having no tact (or desire to try being tactful) in your expressions that everyone is dead wrong unless they are exactly right. But I have thick skin, and can look past this. Especially because you tend to have valuable input somewhere in your asshole ramblings. After all, extreme technical competence usually comes with quirkier personalities. I'll assume that's what your problem is...
(a): The Makefile is there because I put it there. I wanted to distribute everything with the executable, because it's all part of the same project. Perhaps the organization of the files could be improved, but the only people looking for it will know what to do with it when they find it. I'm not sure what your point was about this.
(b),(c): You have a good point that static linking is a security benefit, in addition to being easier to distribute. I will look to see how much more stuff I can static-compile.
(d): I do not agree about duck-typed languages being such a problem. Sure, they leave room for poor/inexperienced programmers to make messier, more error-prone code. But the quality of the final product is on the programmer, not the language they used. Type-checking and error handling is superfluous throughout Armory code, and I am constantly testing everything I can. I know you're probably going to be an asshole and point me to 10 different lines of code out of the 25,000 lines throughout Armory, where I didn't check variable types, or demonstrated some poor coding practice. Well, go ahead. I might even fix those lines. But I won't apologize for having bugs in my, or doing something sub-optimal. We can't all be good at everything.
If you want to continue to discuss this, please do so on the Armory thread, or PM. As I said, I'm happy to take reasonable advice from you. However, your attitude is very likely to turn off others who otherwise would listen to your advice, but brush you off because you are so abrasive.
Thank you very much for your understanding about my lack of style. I'm more worried that my rant was lacking clearness in the description of the possible avenues of attack. Basically (a) & (d) are about the same idea: the distribution of source code should be clearly separated from the distribution of the compiled code. By mixing the two you inadvertently opened Armory to the attack by overriding/redefining some of its function/classes by dropping the overriding source anyplace where the Python interpreter could pick it up. I didn't wanted to spark the discussion about benefit/drawbacks of static-typing vs. duck-typing. As far software security the duck-typed dynamic compiler/interpreter has a serious drawback of being able to accidentaly pick up leftover/changed code from many places in the file system which only Python expert will be able to locate. The mixing of source/compiled representation also effectively nullifies the benefits of signing the compiled/executable code: anything in it can be changed by a very short (less than 100 bytes) .py file placed away from Armory appication directories. Another thing that I didn't explained clearly is that Armory Online and Armory Offline have drastically different security postures. I was under impression that you actually understand this differentiation and posted in this thread to spark discussion how to further differentiate the two. Anyway, it is great that you were able to rise over the presentation style used. I'm going to post a single link to very neutral/matter of fact presentation about offline system security. http://gaming.nv.gov/index.aspx?page=51then search for "Technical Standards for Gaming Devices". For everyone who thinks that they will be better served by a ultra-polite, glad handing and slick presentations: please review the posts of vadimg and shtylman about the BitFloor. https://bitcointalk.org/index.php?action=profile;u=37089;sa=showPostshttps://bitcointalk.org/index.php?action=profile;u=37090;sa=showPostsAgain thanks to etotheipi for understanding the substance over the style. |
|
|
|
The weakest point of Armory offline security is USB auto-run viruses, which unfortunately exist for all OS.
Not in my opinion. In my opinion the weakest point of Armory is a side-effect-channels created by the convoluted tangle of dependencies that are required to run Armory: 1) Ubuntu/Windows 2) C++ & C++ dynamic runtimes 3) Python & Python dynamic dependencies 4) Tcl/Tk; I'm not kidding, the official distributions of Python have a plethora of dependecies on Tcl/Tk, I did a classic "WTF?" when I first saw this. I am thinking that cypherdoc is your example target user of Armory. If I were a bigger asshole that I already am, I would have no problem whatsoever to be helpfull to cypherdoc; help him with the upgrade of his secured/air-gapped installation of Windows/Ubuntu; and then steal all his Bitcoin stash. But I'm just a very small, pinprick size, of an asshole, so I'm going to say this: a) I looked at your py2exe distribution downloads. They are obfuscated. But do you know why are you distributing the Linux makefile in your Windows executable download? b) don't be afraid to be assertive in your support for linking with *.a instead of *.so when some ArchLinux user challenges your choice. You need to understand why are you doing that and be able to explain your choice. c) in your long term goals aim to minimize the attack surface by statically linking as many things as practical. d) understand the Python duck typing and how the class override/overload mechanism is the greatest enemy of software security and how are you going to mitigate that. I want to reiterate that the above is just a friendly advice. Feel free to ask for a full refund if you are not satisfied with my advice. |
|
|
|
The vast majority of lawsuits are either abandoned or settled before trial.
So very true, with the focus on "abandoned." Three reasons: 1) People who lost legitimate money, but it was OPM (Other People's Money). They just need to a piece of paper to CYA (Cover Your Ass, in this sentence Cover Their Ass) 2) People who lost illegitimate money. The possibility of having to document the legitimate source for the money lost is way more frightening than the amount of money lost. Remember this is Bitcoin, something that the majority of people involved use for laundering, tax evasion, spouse evasion, run-of-the-mill fraud, etc. 3) Plain embarassement. The amounts lost may still be small enough that the financial loss is smaller than the dignity loss suffered when having to make a deposition about the circumstances of the loss. Edit: Here's the very poignant advice from Gavin regaring (3): If you "invest" in them then please lick your wounds quietly when they implode.
|
|
|
|
I'm disappointed. I thought you were going to tell me how to override the write-protect. You've got me wondering how difficult it is to do it...
For the ones I've seen in the past this was relatively easy: using SCSI command blocks: get MODE SENSE(6), clear the appropraite bits (READD,WRITED,FORMATD,LOCKD), issue MODE SELECT(6) and then again MODE SENSE(6) to verify which bits took the change. Afterwards just do a "remount -o rw /dev/sdX". Other devices had more complex protocol, but it seems that "Lockable Mass Storage Specification" is no longer secret and is available at www.usb.org. |
|
|
|
You infer a lot...I was not describing a utopian world.
It isn't much of an inference but more of a pattern matching. The writing style, the rhetoric, the hypothetical examples, etc. It is probably unconscious to most of the American (US-ian) writers here: but the class struggle rhethoric is just hard to not notice. Of course the "workers" are replaced with "Internet knowledge elite", "dictatorship of the proletariat" with the "dictatorship of the blockchain", so on and so on... This is partially what makes reading of this forum such a great, intellectually stimulating entertainment. |
|
|
|
I'm not sure exactly what you're referring to, but I didn't mean to imply that bitcoin would take over the entire market for monetary instruments. I meant when bitcoin is simply being used for exchange and savings rather than as a speculative/growth investment as it largely is today.
OK, I apologise. The humor in your posts requires a specific previous background to understand. It probably shouldn't be called humor at all on this forum. The utopian world that you described in this thread resembles the syndicalist world-vision rooted in marxism/leninism. I'm talking here purely about economics, not about the other political/social aspects. Whatever bad can be told about marxism/leninism at least most of the people agree that their analysis/critique of capitalism is internally consistent and has predictive power. In comparison with its m/l-roots the syndycalist economics is considerably weakened; primarily by disregarding internal inconsistences and replacing them with wishful thinking. In particular the bolded part "everyone holding as much as they want to hold" is just one of the more hackneyed and ridiculed statements from a certain syndycalist manifesto. My political-economics textbooks are in storage on a different continent, so I will not be able to give you a good citations and other scholarly backup for my posts here. |
|
|
|
of which 70-80% may be usable or a yield of 150 usable dies.
They manufacturing yield on a Bitcoin mining chip will be eiher 0% or 100%. The structure is so repetitive and the failure modes are inconsequential: coin mining is essentially buying the lottery tickets really fast. On top of that almost every SHA256 implementation is essentially self-testing: it either always works or always doesn't work, so the post manufacturing tests are trivial. |
|
|
|
I tried to grab a ton of info from the USB key, with the write protect in both states.
idVendor 0x0b27 Ritek Corp.
idProduct 0x0165
Thank you very much. Ritek Corp. device 0x0165 is not on my shortlist of known fraudulent devices. (Fraudulent meaning: fake encryption plus maybe fake write protect and other misrepresentations.) |
|
|
|
When Bitcoin fully saturates the market (everyone is holding has much as they want to hold and using as much as they want to use in transactions) and is past its growth phase, the value of a bitcoin will rise and fall as people's preference for savings vs consumption (or riskier investment) changes.
Wow, talk about crackpot economy. As somebody had said a while back: Bitcoin is backed by gold, comedy gold. Don't you ever put anyone on ignore because you may miss the best comedy moments. |
|
|
|
Well, okay. I don't want to get into another useless-or-amazing debate, but I imagine there's still some value in it. Both Linux and Windows refuse to mount in any way other than read-only. Maybe I'm a n00b. But, I just did some googling and didn't find anything, do it must not be trivial to do. Therefore, even if true hardware switches aren't 100% foolproof, it probably does it make the attacker's job much more complicated (and probably restricts it to the few people that know how to read the manual in whatever native language it's written in).
You aren't wrong. But you have to make a conscious choice whether you are trying to achieve security or security theater or cargo-cult security. I would advise you to use the means of communication between the machines that you are sure you can understand. I don't like USB flash drives because of awfull and non-obvious failure modes they create. I do like OSTA-UDF formatted CD-R / CD-RW / DVD-RAM. It makes many thing obvious, eg. that the data actually stays there after the deletion, how to completely destroy the data, documentation is in the open, there is an open-source UDF format checker, etc. The audio interface also looks like splendid idea for the near-field communication. |
|
|
|
to basically remove all the USB key risks? Basically turn it into a smart serial port? Maybe that's an oversimplification (and I'm sure 2112 will let me know just how much). But there's clearly a lot of stuff that goes on under the hood when you plug in a USB key, and I'm sure most of it is completely unnecessary if you know you are going to use the USB drive for exactly one purpose: to move a few kB of text back and forth.
Indeed, "a lot of stuff that goes on under the hood is completely unnecessary". This USB flash business is extremely competitive and very prone to fraud. I'm not talking about "format 4GB drive as 16GB drive" fraud. I'm talking about various supply chain manipulation schemes that would require separate essay. You may think that the drive you use has a hardware write protect. But somebody who can read the Chinese or Russian documenation to the controller IC used therein will know that you are just couple of ioctl() calls away from disabling the write protect and enabling the USB CD-ROM drive functionality. The only way to be safe is to know exactly what is the exact controller model used and know how to verify its operation. The popular Silicon Motion ICs are one of the worst offenders. Trawl the Internet for ChipGenius and then trawl the Chinese and Russian web sites for various utilities. Can you post what "lsusb -v" says about your USB drives with write protect? |
|
|
|
I was just reading about how the security industry doesn't like the "air gap" network concept (apparently) because it gives a false sense of security:
I tried to find some historical information about the use of the term "air gap" in network security. Curiously most of the original sources are now gone. The guys who popularized it in the USA were the Israeli dudes from Whale Communications. They were later acquired by Microsoft. http://en.wikipedia.org/wiki/Microsoft_Forefront_Unified_Access_GatewayThe original "air gap" was a RAM-disk (physical RAM sticks) with a SCSI interface and dual SCSI controllers. But the most memorable were their sales seminars. They were always scheduled in the rooms with tall dropped ceilings and sometime in the midst of the sales spiel they would have an armed SWAT team to land in the room through the ceiling and secure the presentation area. (Not a real SWAT, some sort of a rent-a-cop SWAT.) As you may understand this sales tactic received a very bifurcated response. Some were clearly impressed; some considered it ne-plus-ultra in cheesiness. I could not find any left over photo essays from that era. I guess the opinion about "air gaps" will have to stay bifurcated forever. |
|
|
|
I mean, the credibility of bitcoin community may collapse if we are giving this kind of news to the world?
The credibility is already so low that any real legal action taken by the victims will increase the overall respectability. Anyway, it looks like vadimg is doing well, so it may be willing to settle for buying everyone their lost bitcoins. This is Vadim. I helped start bitfloor, but I haven't been involved with its operations since December of last year, due to personal reasons. I officially signed over all my shares and intellectual property, etc earlier this year.
There's no reason I would hack roman, as he is one of my best friends. Also, I make a great living and definitely don't need the money.
The address listed also isn't my address. I haven't lived there for 7 years. Please don't harass the people living there now.
Death&Taxes is already doing some good work, but it is in the USD space and only tangentially related to bitcoin: https://bitcointalk.org/index.php?topic=106565.0 |
|
|
|
Yeah, definitely save in memory. It will help people learn how to recognize a long con. This board is so dominated by the opportunist short cons that a real confidence men are hard to recognize. I'll save some posts for history: We are in the process of developing a better bitcoin exchange. Based in New York City and written by financial industry professionals, our goal is to be the fastest, most stable, and most secure bitcoin exchange. We currently have a: - simple web trading interface - simple REST JSON API - streaming TCP and UDP API Currently we are running a testnet with fake USD and testnet BTC while we work on polishing up the system. We are inviting everyone to check it out and appreciate any feedback you provide. You can signup here: http://testnet.bitfloor.com/signupYou can see sample traders here: http://github.com/bitfloorWe are currently writing up some detailed information on our security. The bitcoin wallet and database is on a different machine than the rest of the system, and is not connected to the internet. Therefore, an attacker would have to hack the webserver and then use that to hack into the wallet/database server. All passwords are hashed with bcrypt so even in the unlikely chance that an attacker compromised the database, your password would not be decrypted even if it was weak. We have multiple bank accounts, so if the bank closes the account we are using we will simply start using another one. There may be some delays in USD withdrawals during that time but banks are not allowed to just take your money; we will get it eventually. Currently we use dwolla for everything, so there is no bank account to close.
We are pleased to announce that we are now offering a rebate for providing liquidity on our exchange. This means that if your order was on the book when it gets paired with another trade, you will be paid a rebate instead of being charged a fee. A more detailed explanation is on our blog: https://blog.bitfloor.com/?p=6We have a page which details some of our security practices here: https://bitfloor.com/docs/securityWe believe that from a systems engineering and cryptography standpoint, we have the most secure bitcoin exchange. Here's an example of the poor security practices at mtgox: http://news.ycombinator.com/item?id=2676781Sign up for an account and start trading! https://bitfloor.com/Hopefully this site will not met the fate of fuckedcompany.com and the future generations will be able to access it for reference. |
|
|
|
What specific technology would you rather we use?
Just clearly abstract the storage pool layers. There are two storage pools in the Satoshi client: A) public: blockchain and peer addresses and some settings B) private: wallet and some settings Any, literally any well know traditional ACID database technology would be fine. Just create the free account at Oracle's OTN and download whatever suits your fancy. If you aren't a Microsoft hater then obtain access to MSDN/Bizspark/Dreamspark/Technet and use the database technologies available there. The things that need deep and far reaching changes in the current implementation: 1) store blockchain in a database, not in a stdio/iostream file 2) blkindex is just an index, it doesn't need full transactional logging, the lightweight metadata-only logging is sufficient 3) blkindex is just an index, if there's something wrong with it, provide a "reindex" operation, maybe as a side effect of "checkblocks/checklevel" operation 4) provide a way of obtaining sincere ledger / audit log for the transactions with multiple timestamps: 4a) true time when first seen on the p2p net 4b) true time when first seen in a block 4c) block time when seen in a block 4d) true time when some block caused a reorg and un-confirmed the transaction 4e) true time when other block reconfirmed the transaction 4f) block time when reconfirmed 4g) etc.. for each subsequent chain reorganization The above is just a first step. The next step would be to actually integrate with any middleware: 5) get rid of "blocknotify" and support normal commit/rollback hooks supported by pretty much all distributed transactional technology, including the free Microsoft DTC. In summary: the above isn't a "patch" or "git pull request" that can be submitted. This is a change of a mindset that would need to happen amongst the core development group. The GAAP isn't just a ruleset/certification that happens once and then you have it. It is an ongoing commitment. |
|
|
|
What's the problem with getting bitcoins compliantt with GAAP???
It requires extensive modification of the Satoshi client. The upcoming v0.7 requires at least one modification less: "'blocktime' and 'timereceived' fields were added". No matter what, the core development group is dead set against using any auditable database technology for storage, so the cost of modifications will continue to be very high. |
|
|
|
|
Show Posts
