Does the Single need a powered USB hub? If not, is there a limit of the number of unpowered devices that can be hooked up to a single USB port on the motherboard?
No, it has an external power brick. But a powered hub often tends to be higher quality anyway, and you might not be able to get an unpowered version with a large number of ports. The limit is 100 BFL Singles per system. The USB limit is 128, including the hubs themselves. To expand on that. The USB spec also limits unpowered hubs (technically the term is bus powered because all hubs need power from somewhere) to 4 downstream devices. This is because there is a limit on how much power a USB port can provide. USB port need to be able to safely provide 500ma. The spec limits bus powered devices to 100ma ea. Since the hub also needs some power that means 1 hub + 4 full load bus powered devices can be safely powered from a single port. While BFL Singles aren't bus powered the spec limits the # of ports for bus powered hubs since self powered and bus powered devices are interchangeable. There are likely non-compliant bus powered hubs with more ports but given the low cost of powered hubs and very high cost of BFL Singles taking that risk to save a single power cord seems ... foolish. |
|
|
|
But this is not the way to do business. They got the30 K and after 4 months they split a full rig into two mini-rigs and delayed the delivery.
So what if I order a Mini Rig now and after 4 months they split it in 2 Nano Rigs and so on.
Its just insane!
Please tell me that I'm wrong. BFL delays are well documented with thousands (litterally thousands) of post on the topic. There is nothing you can add which hasn't already been said at least a couple hundred times. Their original product ("BFL Single") was also delayed. If the (very real) risk of further delays is too much for you then don't order. Before you hit "reply" I am being serious that anything you could possible think of saying right now (no matter how unique you are convinced it is) has probably already been debated back and forth ad naseum. It would be a good idea to search and skim through the thousands of post which already covered every possible angle of the issue. |
|
|
|
I bought my first btc by pp, and had no problem, but not everyone is honest. There is no risk BUYING w/ pp the risk is on the seller. You were honest but if you hadn't been the seller would have lost the funds and there is nothing he could have done about it. Technically depending on when the trade was even if you had honest intent you could change your mind now and chargeback the tx and the seller would still lose. |
|
|
|
The nodes are infinitely more reliable than that, because despite light clients taking hold, there should probably not be a DECREASE in the long-term as we see it now. Why? For some casual users an ewallet or exchange accounts works. The default client is large and clunky. I expect the number of nodes to continually decline for some time as other options fragment the user base. If an ewallet/exchange account/lite client works better (totally subjective and up to the user) most users aren't going to also keep running a node they don't use. |
|
|
|
|
You don't need a xfire board to use a 5970. For mining you won't even enable xfire. A 5970 will work fine in a PCIe1x slot (with converter or extender).
It either a defective motherboard or a conflict with your onboard video. Very weird your BIOS has no option to disable the onboard video. Never seen that before. If there is a conflict with onboard video and you can't disable it then I guess you are stuck.
The light turning on is not a good sign. It is indicating a problem with either the power connector or the expansion slot (some power comes from the slot and the BIOS has to let the slot run in high power mode).
|
|
|
|
It likely is asking too much but if you record the weekly average of each pool and then convert them to a % you could make a chart over time with the % of each pool (line chart or stacked bar chart, etc). i.e. something like (but in chart form)
Pool Week1 Week2 Week3 Week4
PoolA 10% 11% 12% 11%
PoolB 15% 13% 10% 8%
PoolC 9% 11% 12% 11%
|
|
|
|
|
depending on the MB you may need to disable onboard video.
Sorry can't help exactly because every BIOS labels things differently. Should be an option to disable onboard video and/or an option to set primary video device.
The 5970 has a little red light on the backside of the card. It will light up if it doesn't have sufficient power and disable the card. So if you don't see a light it should have sufficient power to at least post.
|
|
|
|
|
Would be nice to get the % of total hashrate (either instead of or along side nominal hashrate).
The % is more important to be (especially for the largest pools).
Blockchain.info has nice pie charts but I would love to see something showing the % over time.
|
|
|
|
No, seriously. H&R block said don't even bother coming in, that I have NO income. Once again just because you are broke it doesn't mean that Bitcoin ventures being considered a hobby are a good thing. It isn't surprising, the IRS is generally very conservative and often requires "convincing" to see non-traditional ventures as businesses. However "a hobby" doesn't erase your tax liability. If you made $100K from this "hobby" the IRS would want a cut (a very big cut) and the bad news is the hobby declaration would limit your ability to reduce the liability (things like carry forward prior year losses, use losses from your Bitcoin ventures to reduce taxes on other income, depreciate hardware, etc). That being said I would take H&R Blocks universal proclamation with a grain of salt. There is no universal rule. The IRS considers hobby vs business on a case by case basis. http://www.irs.gov/newsroom/article/0,,id=169490,00.htmlOne person's hobby is another persons business. Someone who uses gaming computer to mine some coins part time, has no records of expenses, and uses the same hardware, building, and internet connection for non Bitcoin uses = likely a hobby. Someone who invested $100K in mining hardware has them in a dedicated building, has filed as a LLC to limit personal liability, runs the rigs 24/7 in a dedicated fashion, keeps detailed profit and loss statements, and has a seperate business checking account = likely a business. Note the above two are intended to be extreme examples there are not "hard lines". In general, taxpayers may deduct ordinary and necessary expenses for conducting a trade or business. An ordinary expense is an expense that is common and accepted in the taxpayer’s trade or business. A necessary expense is one that is appropriate for the business. Generally, an activity qualifies as a business if it is carried on with the reasonable expectation of earning a profit.
In order to make this determination, taxpayers should consider the following factors:
Does the time and effort put into the activity indicate an intention to make a profit?
Does the taxpayer depend on income from the activity?
If there are losses, are they due to circumstances beyond the taxpayer’s control or did they occur in the start-up phase of the business?
Has the taxpayer changed methods of operation to improve profitability?
Does the taxpayer or his/her advisors have the knowledge needed to carry on the activity as a successful business?
Has the taxpayer made a profit in similar activities in the past?
Does the activity make a profit in some years?
Can the taxpayer expect to make a profit in the future from the appreciation of assets used in the activity?
The IRS presumes that an activity is carried on for profit if it makes a profit during at least three of the last five tax years, including the current year — at least two of the last seven years for activities that consist primarily of breeding, showing, training or racing horses.
If an activity is not for profit, losses from that activity may not be used to offset other income. An activity produces a loss when related expenses exceed income. The limit on not-for-profit losses applies to individuals, partnerships, estates, trusts, and S corporations. It does not apply to corporations other than S corporations.
If someone has a token amount of Bitcoin "income" (common definition not IRS definition) then it likely doesn't matter. However if you have a significant amount it would be a good idea to consult with an accountant and tax professional. The above post should be considered informational and not relied upon as tax advice. |
|
|
|
Well, 2 days ago I finally got my answer. After asking the 5 longest-working members at that particular H&R Block location AND after calling the IRS, the lady said that Bitcoin is a hobby. She knows that I buy precious metals with Bitcoin, knows that I have money in accounts all over the globe, and knows that I have conducted business deals and have provided services specifically dealing in Bitcoin. I even showed her an old TradeHill check of some of my profits. Long story short, I don't need to file any taxes this year  But then again, I was kinda hoping to write off some of my computer equipment as a business expense. Your statements and conclusion don't match. If the IRS considers your action a hobby they STILL want a cut of any profits BUT you can't deduct any losses, depreciate hardware, carry forward losses, etc like you can with a business. Essentially it is a worst case scenario. I have my mining operation filed as an LLC (to depreciate hardware, account for my labor costs, etc). We will see if IRS rejects my tax return.  |
|
|
|
This depends on the motherboard... For instance, my GA-990FXA-UD7 wouldn't even boot with 8 GPUs until I started disabling some devices in the BIOS (USB3, eSata, etc...). After a couple of tries, everything works and this box has been running stable for several months now. That is a good point. The BIOS maps all onboard functions to the virtual memory space. Most are not anticipating 8 GPUs. Good idea to turn off everything you don't need (it also saves some watts). From the NVidia cluster blog it loooks like BIOS designers are horribly inefficient with memory space allocating giant chunks of memory to each device. Still move >8 GPUs requires more "exotic" solutions. NVidia makes it easier since GPU are decoupled from xorg and have no driver level limit. AMD driver level limit and tight coupling make virtualization a requirement. GPU limitations: BIOS limitation - (NVidia cluster w/ 13 GPU required a custom BIOS built by manufacturer) Driver limit - AMD drivers have a hardcoded limit of 8 (NVidia has no driver level limit but doesn't support >8 due to other limits) Virtual space limit - >8 GPU likely mandates x64 OS Kernel limit - Large number of addressable devices may require changes to kernel xorg limit - xorg can't handle > 8 GPU (NVidia bypasses this by making drivers independent of xorg) So it is "hard" w/ Nvidia but downright impossible w/ AMD. Virtualization should work though ... maybe. |
|
|
|
Yeah, Gigabyte boards don't like to boot from USB with BAMT on them. It's a known problem.
Strangely the behavior of giga boards seems to vary from model to model and even bios version to bios version so you can get "lucky". That being said it is one reason I steer clear of gigabyte (I liked them pre-Bitcoin). I mean bootstrapping is one of those core BIOS functions. If a BIOS can't handle all supported methods of booting it shouldn't be sold. Period. |
|
|
|
I elected not to point out the gross error in your logic of 100 tps being 100 kbps. This, unfortunately, only holds true if you have 1 incoming connection and 0 outgoing connections. If this were the case for the network, there would be no network. There is the reason the wiki comes up with 8Gbit/s for 4,000 tps instead of 4Mbit/s. Good point totally blanked on that. The wiki assumes tx size will increase from ~500 bytes to 1000 bytes due to more complex tx but that is no longer a valid assumption due to p2sh. It does show why p2sh was such an important change. Very long multi-sig addresses would only make the problem worse. p2sh neatly bypasses the entire expanding address size issue by decoupling the complexity of the script from the address size. Compressed keys can reduce the address size by ~50% however implementing them in the protocol would be a breaking change so currently they are only used locally and decompressed to full length keys for broadcasting. So: 50 tps * (500 bytes - avg 2 input tx) * (20 peers) * 8 bits/byte ~= 4 Mbps. If we consider Paypal sized network an achievable medium term goal (over next decade) we are talking about a full node needing ~ 4Mbps. Using less peers (which should be fine for non-merchant nodes) would require roughly half that. The good news is that bandwidth outside last mile is much cheaper so even if one reached a point they couldn't host their own node but didn't want to use a 3rd party wallet they could put an node like electrum on a VPS and then connect their local lite clients to their dedicated trusted node. |
|
|
|
You know, I have tried to be civil. But when somebody is insulting in the face of their own stupidity, it gets harder and harder.
... nonsense snipped ...
You made a gross leap in logic and used that to draw a conclusion based on no evidence of any kind. Then threw insult after insult at me for pointing out this logical fallacy. Actually I said IF the same performance increase is possible while you said definitely that OpenCl won't help ECDSA acceleration. The reality is ECDSA acceleration already exists. https://raw.github.com/samr7/vanitygen/master/calc_addrs.clVanitygen acceleration ECC public/private keypair generation. There is nothing to indicate that verification couldn't also be accelerated. Also of course ECDSA can be parallelized. SHA-256 doesn't have intra hash parellization it uses macro-processes parallelization. Simply put it doesn't try to make processing a single hash faster it processes multiple hashes at the same time. Likewise since each ECDSA signature is independent one can process multiple signatures at the same time without needing to speed up the intra-hash process. Now Vantitygen is a "bad" benchmark because it performs multiple tasks: ECC public/private keypair generation RIPEMD-160 hashing SHA-256 hashing Pattern matching However computationally the ECC keypair generation takes much longer than the other three tasks combined. I will modify the vanitygen kernel to just perform ECC keypair generation since obviously nothing short of a definitive benchmark will make you realize that OpenCL acceleration is at least POSSIBLE. Nobody has looked into it simply because for Bitcoin that "bottleneck" won't be hit for likely a decade. BTW ECC accelerations exist in the business world too. |
|
|
|
The facebook/social network is just a marketing thing. They want to have access and see who you connect to so to get more customers. If you link to a fake one they won't know any difference. Which I have no problem with companies using social media to gain competitve advantage. What is disgusting is linking that "advertising" requirement to account verification. Had they launch a separate imitative where liking them on facebook and installing the Dwolla app (which links your Dwolla # to your facebook identity to make it easier for facebook users to send money to each other) got you 10 "free transfers" that would be a smart action by a reputable company. The integration into "fraud prevention" is just disgusting and shows the kind of culture that exists at Dwolla Inc. |
|
|
|
One potentially untapped area is OpenCL & AMD APU series of chips. APUs have a decent OpenCL capable "GPU" right on the chip. They are targeted for lower end systems. In SHA-256 hashing they acheive roughly 5x the throughput compared to high end quad core conventional CPU. Like I said it is early as there is no need yet but if the same multiple holds true we are talking about hundreds of tps (given an OpenCL "aware" client).
tps is not bottlenecked by hashing, it is bottlenecked by ECDSA. They operate very differently and openCL/APUs will not help this. So you have already written a ECDSA Kernel for OpenCL and can confirm that unlike virtually all other cryptgraphic functions it is impossible to accelerate ECDSA? What was the throughput you saw in terms of ECDSA verifications per second? Care to share your findings on what makes ECDSA acceleration infeasible? Still I did say IF the same multiple holds true. If it doesn't then Moore's law will still provide some help. The OP "benchmark" is bullshit. Today bitcoin tx processing is on the order of 300+ tps for a modern CPU (quad core @100% load). If we limit to 20% load that is "only" 60 tps. 60 tps is 600x larger than the current network and roughly Paypal sized. If it takes us a decade to grow to Paypal scale network the average computer will have roughly 30x as much computing power per watt. Even without OpenCL the "tx bottleneck" (600x current tx volume) becomes less of an non-issue. I'm not a cryptographer However you are an expert OpenCL kernel developer with extensive research on the limitations of OpenCL for acceleration cryptographic functions? |
|
|
|
One has to take into account that if Bitcoin continues to grow and become more mainstream, it's likely that at least 90%, possibly even close to 99% of Bitcoin clients will be lite nodes. Meaning that they are either client-server wallet solutions (such as Electrum) or E-wallets such as Blockchain.info. Therefore calculating how much it takes for a basic CPU to verify transactions etc is irrelevant. That stuff will be in the hands of non-average server hardware, which is much more capable than your average PC. On a long enough timeline that may be true but I think we have some room to grow. The trend in CPU has been the inclusion of GPU functionality. Currently (w/ avg tps being <0.1) there has been little need to improve tx processing performance. One potentially untapped area is OpenCL & AMD APU series of chips. APUs have a decent OpenCL capable "GPU" right on the chip. They are targeted for lower end systems. In SHA-256 hashing they acheive roughly 5x the throughput compared to high end quad core conventional CPU. Like I said it is early as there is no need yet but if the same multiple holds true we are talking about hundreds of tps (given an OpenCL "aware" client). Long before Bitcoin hits mainstream even low end computers will have access to relatively powerful OpenCL hardware in either their "on chip" GPU or low end discrete graphics card. CPU/GPU power shouldn't be an issue for a long long time. |
|
|
|
Technomage is completely right. Nobody should care if you and me can run a full node. Soon Bitcoin will be completely centralized, as banks. Nobody will be able to run a full node. Then banks will start changing the rules. Also, computers are disappearing, people will only use smartphones... Then why are we doing all this? Let´s just stop using Bitcoin and keep using USD or Argentinian Pesos. Or better, let´s use Google Wallet, whose app is really a thin client. Why did I spend some many nights writing such a paper? I should have been playing tennis with a banker. Best regards, Sergio. The world is full of gray and you are making ridiculous claims based on black or white. Gold mining for example is decentralized. No single entity controls more than ~10% of world's proven reserves (as in metal still in the ground) however it isn't decentralized to the point that every single person on the planet mines gold. 99.9% of people who want some Gold simply buy it. The market is still decentralized though. Central bank = absolute centralization. A single unelected board of 12 sets monetary policy for 300 million people. If Bitcoin full nodes consist of 1000 or so entities it is less decentralized than if every single person always ran a full node however it is many magnitudes more decentralized than a central bank. Today a large number of users CHOOSE to not run a node and instead use 3rd parties. That is when the requirements of running a node are trivial. I don't see a problem in that because the "market" for 3rd party wallets is DECENTRALIZED and OPEN (there are no licensing restrictions to create barriers to entry and keep the number of players artificially low). |
|
|
|
Actually, you picked exactly the wrong example of why legal tender laws don't matter. People are legally obligated to accept legal tender (even in ridiculous forms, such as a dump truck full of pennies) for the payment of debts (eg, taxes, mortgages, bills, etc) (however, non-legal tender may still be used to pay off debts if both parties agree to it).
That is a mismoner. No entity is required to accept legal tender in all forms (like for example a dump truck, or even any cash) they are just obligated to accept payment in some form of legal tender. As an example, my mortgage is held by a non bank entity. They have no offices/locations open to the public and federal law prohibits mailing cash (in any form). My old method of satisfying the debt is by check draft, money order, cashiers check, ACH, or bank wire. That doesn't violate any legal tender statutes. Now if the "bank" demand payment in gold or chickens it would. However them placing restrictions of what forms of payment they will accept are not unlawful. The purpose of legal tender laws is to ensure that a debtor holding legal tender has SOME mechanism to repay that debt not to obligate creditors to asinine restrictions (like requiring they accept a dump truck of pennies). Now the legal tender laws in Canada may differ. From the source (US Treasury) Question:
I thought that United States currency was legal tender for all debts. Some businesses or governmental agencies say that they will only accept checks, money orders or credit cards as payment, and others will only accept currency notes in denominations of $20 or smaller. Isn't this illegal?
Answer:
The pertinent portion of law that applies to your question is the Coinage Act of 1965, specifically Section 31 U.S.C. 5103, entitled "Legal tender," which states: "United States coins and currency (including Federal reserve notes and circulating notes of Federal reserve banks and national banks) are legal tender for all debts, public charges, taxes, and dues."
This statute means that all United States money as identified above are a valid and legal offer of payment for debts when tendered to a creditor. There is, however, no Federal statute mandating that a private business, a person or an organization must accept currency or coins as for payment for goods and/or services. Private businesses are free to develop their own policies on whether or not to accept cash unless there is a State law which says otherwise. For example, a bus line may prohibit payment of fares in pennies or dollar bills. In addition, movie theaters, convenience stores and gas stations may refuse to accept large denomination currency (usually notes above $20) as a matter of policy.
I picked that example on purpose. |
|
|
|
How does the client invalidate the bad blocks unless it has a source of valid blocks? The whole point here is that this is the only way to get the blockchain to some clients. All clients have the starting source ... the genesis block. The only way to validate block #1 is to ensure it meets block requirements and has the block hash from block #0. As such all full-clients must include the genesis block. From there every node can validate every tx from block #1 all the way to current block. As indicated above clients may also include hardcoded checkpoints. Nodes are NOT secure. They are inherently insecure. You have no idea how dishonest your fellow "peer" connections are. Hell they could all be the same attacker. As a result Bitcoin DISTRUSTS all blocks received from the network until validated and added to the chain tracing all the way back to the genesis block. A broadcast system for blocks wouldn't be any different. Right, but that doesn't help at all with new blocks, which is where any attack would play out  . New block is simply the tail of the block chain. Right now a peer node just gave you a block how do you make sure it is valid? |
|
|
|
|
Show Posts
