Well this is what I wanna do before I get more confused, I have a warehouse with a panels that has a 3 phase 208v layout. I have 6 cointerras ready to be plug in but i wanna switch to 240 so I can be a bit more efficient. what do i do?
That's only doable with the agreement with your electrical utility. I believe it is called "high leg delta" 3-phase. Unless the utility offers 240V there (which is doubtful), you can't. Okay, you could get boost transformers to convert to 240V, but the loss in the transformers would negate any small efficiency gain you might get in the downstream power supplies. Have you examined the efficiency curves for the supplies to see what the efficiency difference would be?
No additional transformers are required with the "high leg delta" hookup. But the efficiency difference will be minuscule. There maybe a surcharge from the utility for supplying this old-style, asymmetric power that will negate any efficiency savings. http://en.wikipedia.org/wiki/High-leg_deltaAnyway, you clearly need to talk to certified electrician and the warehouse owner, because the change to "high leg" may make the rest of the warehouse unsafe. |
|
|
|
Well Im looking to set 5 cointerra miners at a shop using 208 v, some I was looking to get a PDU3VN10G60 which supposedly can feed up to 12600 watts but then when I was reading the specs says that I will only take 35 amps of input. here is the link http://www.tripplite.com/sku/PDU3VN10G60/Can anybody explain to me how this works?? How will I ever put 12600 watts on a PDU that can only take 35 amps?? I would really appreciate any feedback, thanks. Nico It is a 3-phase device. Maximum output current is in each phase is 20A. 3*20A*208V=12480W. Basic introduction to 3-phase systems: http://en.wikipedia.org/wiki/Three-phasehttp://en.wikipedia.org/wiki/Three-phase_electric_power5 Terraminers have 10 power cords, each drawing 2100W/2/210V = 5A. You can't distribute them evenly amongst 3 phases. The closest is 3+3+4. So it will be drawing 15A+15A+20A. One circuit is at its maximum. Any further asymmetry and they will start tripping the breakers. It could work if all the Terraminers have perfect power supplies with perfect load sequencing. |
|
|
|
|
I think that SEC should have a mirror image title to an "accredited investor": an "accredited dumbass". Accredited investor title was meant to protect the proverbial "widows and orphans" from investment scams and the onus is on the sales agent to discover if the investor is accredited.
Accredited dumbass would be a mirror image of this title: somebody who is beyond the reproductive age (or submits to an appropriate for their sex medical procedure) an such a person would would carry a card allowing them to invest in absolutely anything and indemnify the sales agent who sold them their investment.
Accredited dumbass would also be ineligible for unemployment and any other social benefits.
I think nobody would apply for this title unless the card would say "accredited smartass" or some other passive-aggressive platitude.
Edit: Also, the successful applicants for this title should not only receive a card but get a tattoo/branding saying the above, probably on their ass. And the laws that require the hospitals to accept anybody regardless of their ability to pay should be amended to allow throwing out anyone who shows up without valid prepaid insurance and have the accredited dumbass tattoo.
|
|
|
|
That image needs to be marked NSMV (not safe/may vomit).
The lady doth protest too much, methinks. |
|
|
|
Is that James Gibson on the far right, and did they pay for that flight with bitcoins via Skytour via GoCoin?
According to Gawker this is Tommy Johnson. I don't know anyone pictured in any of those stories (in this thread or in Gawker), I just know quite well some of the folks working in the entertainment industry and whose names were mentioned there. And certainly did meet the types of folks who frequent those parties (Edit:) as well as those who would like to frequent those parties but need to come out of their closet first. |
|
|
|
|
If I may have a small suggestion related to this issue:
On the user stats page display "total post count (including deleted posts)". This should be a very simple SQL query that doesn't create much overhead in the software. This could save a lot of people additional manual work, and that includes moderators and administrators.
You are mostly concerned with scammers, whereas my concern is mostly with flip-floppers, people who habitually post strawmen or impulsive and emotional posters.
|
|
|
|
It's more than "additional configuration" if one's router doesn't support IPSEC. Plus, and this is more to the point, if the pool doesn't support securing the other end this won't even be an option. Of course this will protect only up to the pool boundary, but I'm not going to go there...  In my experience these days even the cheapest "ADSL modem & WiFi gateway router" (that are practically given away by ISPs) do support IPsec. And even if they don't support IPsec directly they support passthrough of IPsec tunneled in UDP. It really is a matter of expending some effort to configure the endpoints, be they routers or the hosts. All the well-known OSes support IPsec for about a decade now. Also in my experience the reluctance to enable IPsec on somebody's behalf typically points to other problems: 1) generally lousy network infrastructure with high BER 2) inside jobs at vendors/clients who then try to blame MITM or bitsquatting or whatever esoteric enough 3) generally incompetent operations/sysop/sysadmin staff 4) some other "layer 8" political/religious problems in the organizations In my experience cost was never a problem. In addition to the above doing a "show crypto ipsec" (in Cisco IOS or equivalents in other routers) was the surest way to get the problem escalated to the appropriate personnel at the ISP, NOC, DC, etc. in the rare cases that there was an actual problem somewhere in the infrastructure. |
|
|
|
A man in the middle attack can accomplish the same effect as bad hardware. This might be more than a spiteful attack, it could even be profitable if the cost of being a MITM can be made low enough. The attacker would mine solo or on other pools that he is not attacking. The payoff would come in a lower difficulty. There are various ways that this attack can be detected if miners are looking for it.
Nowadays the cost of the defense against MITM is also extremely low: IPsec. AH is sufficient, more complex ESP is not required. No software changes are required either, only some additional configuration on the routers. I've discussed this already with Slush in the original "Stratum" thread, not the later "Stratum Mining" thread. |
|
|
|
OK, D&T again went into the mode where he posts some strawman arguments then deletes them. I'll have to paraphrase: Mining ASICs are nearly 100% deterministic, more precisely (100% - allowable fault rate). The problem we are facing is that thus far only "false positive" faults were measured by the mining software. Maybe the threat of the block withholding attacks will force everyone to cooperate on the measurement of the "false negative" fault rate. Hopefully vendors will cease to obfuscate like this: It won't work. Our miners for example don't check all nonce range, and a lot of cgminer generated jobs get dropped. Also we use ntime-rolling differently from other pools. It's impossible to know what the miner will generate from stratum template.
or like eldentyrell did with the timebomb in his Tricone Mining bitstream for Xilinx Spartans. |
|
|
|
I assume you are confused because you believe that hardware normally checks all nonces all the time.
Dude! I have to assume that you've again went into the mode where you can't read with comprehension and started arguing with the voices in your head. I normally agree with over 90% what you say, except when you start ranting like when you've claimed that Apple Computer doesn't take money orders. Please chill out or maybe switch to decaf? Obviously this test has to be hardware specific, because e.g. bitfuries only test 768/1024 of the available nonce space. This would have to be even more complex to account for failed sub-engines in the multi-engine chips.
Anyway, I think that the problem is solvable. Maybe a Bloom filter of "hashing blind spots". It certainly would require a cooperation from the ASIC vendors with the developers of the miner and the pool software. As most of the things in Bitcoin mining it will be some sort of probabilistic solution, not a mathematical proof of failure. The first person posting on this forum about false negatives in mining was hardcore-fs with his XUPV5 FPGA miner, but I don't think that he published his results nor code. Likewise Spondoolies made promises of their ASIC designer to start posting on the forum after Passover, but apparently they haven't had time to do this yet. In general, I'm optimistic that problem will be solved. Nowadays, who remembers when the long-polls were the major problems for mining pools? From my experience in the electronic and software industry: one person's problem is other person's opportunity. For example: NTSC started as "Never Twice the Same Color" and ended up where even the cheapest TV set receiver chipsets have been precisely calibrating themselves 29.97 times per second (using Vertical Interval Reference and Ghost Canceling Reference). And that was done quite effectively over all-analog broadcast retransmission networks including satellite links, where the end-users were completely oblivious to the problems in the transmission channel. All it took was to build a reasonable model of the distortion and run the tests frequently enough. Quoting below just for future reference: You are correct that there isn't any observable difference between the 2 types of problems. And in practice, I think it's extremely unlikely that someone with hardware that has catastrophic levels of false negative errors is unaware of the issue, so the intent is likely equivalent as well.
When you have people of very questionable competence designing silicon on crash schedules it's inevitable that serious hardware defects are going to be in play. And with the money involved, if there is a way to externalize the cost of failure to pool participants people are going to choose that over eating the loss themselves.
I think it's an absolute must that stratum allow pools to send test jobs to validate hardware integrity in a blind way that allows detection of malicious withholding as well. Without that, I expect the days of public pools are numbered, and with them all hope of even modest decentralization will go as well.
It has nothing to do with hardware errors (although they are another minor source of false positives). Simple version: If nonce 728937289 solves the block for a given unit of work and a particular hardware for a variety of reasons doesn't check nonce 728937289 it is not going to find a solution. If a user doesn't return a solution is it because he is cheating or is it because his hardware didn't check that nonce with that work? The answer is there is absolutely no way to know. It isn't a hardware fault or error. If nonce 728937289 solves the block for a given unit of work and a particular hardware for a variety of reasons doesn't check nonce 728937289 it is not going to find a solution. It is that simple. I assume you are confused because you believe that hardware normally checks all nonces all the time. Nothing could be further from the truth. There are dozens of reasons why a nonce wouldn't be checked and no software is going to report that as an error. HW errors as reported by cgminer and the like are the result of the hardware reporting that work A + nonce B produces a hash of particular difficulty and it doesn't. I think that Stratum Mining protocol can be extended to allow the client to send to the pool server the maps of the "blind spots" in the nonce space. It isn't a static range. Say you have an ASIC with 64 cores the designer may decide to take the nonce range (2^32) and break it into 64 chunks. It does this by assinging an offset to each core. So all the cores get the same work, each one starts at a difference nonce value and they all increment 2^26. However due to yields not all chips will have all 64 cores operating. The seller may have designed it around 60 cores being "good enough" to achieve the hashrate. So if 4 cores are "off" then that means millions of nonces will never even be attempted. Most ASICs also work on dynamic load so as the hardware error rate and/or temp rise it shuts off the cores. So the same nonces won't be covered all the time. Still it goes way beyond just which nonces are checked. Both the ASICs and the mining software queue work. So what happens when a miner has 30 seconds worth of work queued up and you send him the "test work". Are you going to hold the block for 30 seconds which would mean a >7% orphan rate? What happens if due to latency the miner returns the proper solution but only after you have broadcast the block? If he cheating or just slow or just had a lot queued up? How are you going to avoid the attacker just sharing info between workers? Say you send the test work to 10% of workers and wait 30 seconds. You probably will end up with hundreds maybe thousands of false positives AND 7%+ orphan rate (on top of whatever you are losing to attacks). If the attacker had say 30 accounts there is a less than 3% chance that 1 and only one would be given the test work and end up withholding it. So 3% of the time you will catch the worker, due to false positives lets say you don't boot someone until they fail 3 times. That means on average the attacker will pass 99 blocks before failing out. However you are only testing him 10% of the time so you MIGHT (I doubt it) catch him after he withholds or attempts to withhold 990 blocks. Of course even your legit users are going to start working against you (or just flee to where they aren't attacked by the pool). Those who want to stay will probably design a work relay system so they can identify your test works if for no other reason than to be falsely kicked out (especially if you confiscate the work completed). The attacker could join those relay networks and all but guarantee he would pass all tests. Also don't take this is exhaustive I just don't feel like covering every possible scenario. These issues are just the tip of the iceberg. The only way to prevent these types of attacks is for the pool to know something the miner doesn't. The current block hashing protocol doesn't make that possible. |
|
|
|
|
Can someone explain to me how is "block withholding attack" different from the "false negative" type of hardware fault? I mean in the observable symptoms, not in the intent.
The last time I looked into the miners source codes (late FPGA era,early bitfuries) I've only seen the "false positives" counted as "hardware errors": nonce comes up as gold, but software re-check shows that it isn't.
I haven't seen any published source code that does the opposite check for "false negatives": chip should find a golden nonce but hadn't.
From the skimming of the available hardware documentation I see that only Spondoolies has a BIST operation that allows to cheaply test for false negative. By "cheaply" I mean "cheaper than doing a regular, full scan".
Obviously this test has to be hardware specific, because e.g. bitfuries only test 768/1024 of the available nonce space. This would have to be even more complex to account for failed sub-engines in the multi-engine chips.
I think that Stratum Mining protocol can be extended to allow the client to send to the pool server the maps of the "blind spots" in the nonce space. Then the pool can sensibly proctor the tests meant to discover withholding attacks.
|
|
|
|
I didn't realize I had posted enough detail for you to draw such a conclusion, but if that is indeed the case, by all means, please educate me. I don't mean to be sarcastic. I would truly appreciate your input. How would you make it better?
Oh, sure. I already posted my suggestions. But let me restate them: 1) Figure out a way to plug into industry-standard transaction monitor systems. Any or all, your choice 2) Figure out a way for bitcoind to operate in some sort of two-phase commit protocol. Start by understanding why the old fashioned credit card charge actually consists of "authorization" and "capture". 3) bitcoind uses BerkeleyDB for wallet storage. BDB in turn supports X/OPEN transaction monitor interface. Research if it is possible to actually enable that functionality without doing major re-factoring of the existing code. And actually at a top priority: 0) Implement just about any school-grade, educational example of a working distributed transaction system, e.g. something like I've suggested in my first message in this thread: two programs from Microsoft Office on two Windows machines using MSDTC. If you don't like Windows then work with Linux/Tuxedo/free VM images provided by Oracle (I wrote about this a while back already). |
|
|
|
seat-of-the-pants
I just realized that this was a bad choice of metaphor on my part. Here is a better one: And when talking about "enterprise-grade" accounting most here have something like this on their mind: or, apparently, something like that: Credit goes to Mike Caldwell for clueing me on the "receipts-on-a-spike" metaphor some years back. |
|
|
|
Look, if the point you're trying to make is "you don't have the skills to build this project"*, why not just get involved? If you are too busy to code, perhaps you can get involved in an advisory role? Every post on the topic of account management seems to eventually lead to "the stuff built into bitcoind is not good enough and may be removed in the future; build your own." The moment you're separating account functionality out of bitcoind and into a separate process you're already dealing with distributed transactions. Would it not be better to have a publicly scrutinized and tested subsystem for this? *even though you have absolutely no idea who I am and what my experience level is, and you've apparently concluded this based on a few paragraphs I wrote and what I do for a living Many people tried to influence the Bitcoin core development team towards the use proper ACID techniques. You can review my past posts as well as several other members of bitcointalk.org. It isn't going to happen for many reasons: 1) it isn't a priority for them 2) nobody there has any appreciable experience with DBMS and OLTP, and they don't have time to acquire it 3) majority of Bitcoin users demand lightweight solutions even if they are seat-of-the-pants and aren't ACID-compliant 4) in the history of patches submitted to the project leader there were several that purported to provide some enterprise-level functionality, but also changed the core Bitcoin protocol behavior with respect to the chain reorganizations. This has understandably soured him to accepting any more "enterprise" contributions 5) Bitcoin milieu has already experienced several fraudsters (or "criminally optimistic people") that made promises very similar to yours You may think of yourself as a trailblazer and Bitcoin do-gooder, but thus far you've pretty closely followed the footsteps of some previous scams. The onus is actually on you. I don't care about your credentials or experience or who you work for. Just post something that shows your technical competence in the OLTP domain and not in the domain of writing sales blurbage and the use of Microsoft Visio. What you've posted thus far would be graded as a fail by any professor at any OLTP-related course at any reputable school. |
|
|
|
Why? The interpreter is already protected against this. Once the opcode limit is exeeded, the execution terminates, the transaction is rejected, and the peer is DoS banned.
So in other words in Bitcoin the equivalent of Ethereum's "gas limit" is a single #define (or const int)? Stack-based does not mean Forth. Just like LISP does not mean Common Lisp.
I suggest you look into Joy, Cat, Kitten, or one of the many other newer generation "concatenative" languages.
Some links and concrete examples of advantages from you would be helpful. There is a lot of newfangled research in front-ends that I admittedly don't follow because I care too much about back-ends and overall quality and breadth of the implementations. |
|
|
|
For example, take the P2SH idea where the PubKey is a script hash and apply it recursively— so a script opcodes and interior hash nodes (you could then think of the script as a merkelized abstract syntax tree). From an implementation perspective, you can think of this as having a OP_choice which takes one serialized script and one scripthash. What you reveal to the network then is not the whole program, but just the parts covered under the taken branches, for the rest you only give their hashes. Other nodes don't care about what happened behind untaken branches, only that the branches which were taken ultimately resulted in acceptance.
Verification time then, is, as before, linear in the size of the signature.
The way you describe it, I'm not sure I understand you properly. To me it reads somewhat like: a dynamic linker of scripts that uses late binding. Unlike conventional ld.so it does it not by name but by hash of the "_text" section. Verification is then optimized because the actual linking wasn't really performed. But getting back couple of pages to the requirements of resistance to DoS attacks (stated by Gavin), you'll still have to design your interpreter to be able to defend itself against somebody implementing a factorial or even an Ackermann function using the mutual recursion of a set of P2SH. maybe a derivative of Forth that doesn't have conditionals or loop statements? that would make things much more manageable.
In light of P2SH it would be more like "stack of Forth derivatives" not a "single Forth derivative". Lisp is actually not ideal here. Some sort of stack-based language with strong static typing would be an optimal choice (see, for example Kitten & Joy). But yes, Ethereum is re-inventing a square wheel here.
I'm not trying to say that Lisp is ideal. But in school I had to maintain both Forth and Lisp interpreters and deal with the bugs and improvement requests. Lisp tends to bunch all the pain at the beginning of the project. Forth projects start easily but continue to bleed you later on. If you consider a task: "write a program in language X that takes another program in language X and transforms it in a certain way or verifies if it satisfies a certain condition" then for X == Lisp those programs tend to be the shortest or have already been written and debugged. This is the reason why I advocated Lisp for scripting in cryptocurrencies. |
|
|
|
IMHO, the biggest drawback to this is complexity. Building, debugging, supporting and verifying this software is not going to be cheap or fun. Therefore it must require the involvement of investors to exist. Can we make a simpler system that supports our needs- most certainly, I outlined it above.
Sometimes Simple Wins. It just seems very un-Bitcoin.
From the purely-computer-science point of view the required interpreters, compilers, theorem-provers, etc. already exist and are well-debugged. They are available in every decent CS library under the very dirty and dusty keyword: Lisp. In one of those books there is a maxim: Those who don't know Lisp are doomed to reinvent it. Obviously, Lisp doesn't directly plug into the Ethereum implementation. But knowing it would certainly remove lot of "fun" from reinventing the wheels for the Ethereum. |
|
|
|
on personal (and permanente) connexion of bitcoin-core ... i set 4 connexions max. = 5ko/s of UPLOAD
on p2pool server support with bitcoin-core, the minimal connexion must be set to 12. = 10-20ko/s of UPLOAD
ko? French...
Ah, ko == kilooctets. Merci bien. |
|
|
|
It doesn't seem like you've ever done any distributed transaction processing.
At my day job I design data warehouse systems for large financial firms. Do you have any specific concern, question, or constructive comment? Thanks and I'm sorry for not responding timely. What you've just told me is that you have no OLTP experience and moreover you don't even have an interest in OLTP technology. "Large financial firms" are the mainstay of the vendors of the http://en.wikipedia.org/wiki/Teleprocessing_monitor and pretty much every of their product internally uses the http://en.wikipedia.org/wiki/Two-phase_commit_protocol . My following comment will be constructive for the prospective users of any such Bitcoin accounting package that portends to use the bitcoind RPC calls in the "enterprise" environment: Simple test of robustness and idempotency: suspend the bitcoin daemon right after it received the "send*" RPC call. Do it with "kill -STOP" or store the ".bitcoin" directory on a Fibre Channel and fail the disk. Wait for the upper layer to timeout and then either resume the daemon with "kill -CONT" or plug back the disk. Oftentimes the recipients will receive exactly double of the intended amount. This isn't some theoretical scenario, it had already happened to GLBSE and ASICminer when they used the naive integration of bitcoind with their SQL server without observing the 2PC. Obviously bitcoind wasn't intentionally suspended by them, it was just made arbitrarily slow by either simultaneously running backups of the same physical hard drives or by excessive swapping of the host machine. |
|
|
|
|
Show Posts
