|
Not worried. It is a centrally controlled system, which means the trusted third party will be able to block, freeze, limit, and otherwise manipulate transactions and users. Also it is a payment platform (one that honestly is really needed because CC are just horrible for the internet they just happen to be the only option) which means the underlying "cash" or "money" is still the heavily inflated and centrally controlled federal reserve note.
If it gains any critical mass companies like OKPay, PayPal, Dwolla, et all are far more vulnerable. Depending on how the protocol works (irreversible?) it could be a very useful mechanism to move USD and thus facilitate greater peer to peer exchange of BTC for USD. I mean lets face it if you want to sell or buy BTC and you don't want to use an exchange, right now which is the "harder" half of the equation? Transferring BTC or transferring USD?
|
|
|
|
Bitcoin has the critical mass going for it, with many merchants accepting bitcoin for example as well as other companies creating easier methods of buying and selling.
This critical mass is important. For most on the cutting edge of development, they can only really concentrate effectively on one coin so as not to dilute their efforts. For the near future at least, it appears that Bitcoin is it.
I would tend to go along with this. Bitcoin is way out in front, so far in front of the rest that it would be hard to imagine any of the rest catching it now. However, I am also acutely aware that practically none of the big internet based companies that were around during the tech bubble, are market leaders these days or even still around. Without knowing a great deal about the technology I don't suppose it would be beyond the realms of possibility that there turns out to be some design flaw in Bitcoin that eventually renders it untenable over the long term. Perhaps the computational power required to keep the Bitcoin universe functioning will become to great or perhaps someone will crack the algorithm and start forging coins. Who knows, but history tells us that New Invention mk1, never lasts the duration and improvements are always required for a concept or technology to succeed. Who knows, perhaps one of the pump n dump coins will be in a good position to take Bitcoin's place should anything bring it down for whatever reason, or more likely is, that the Google or Facebook of crypto-currency is not yet with us. Bitcoin is more like a protocol. TCP/IP has a lot of issues but the network effect has kept it around despite theoretically superior alternatives. If TCP/IP didn't exist today and you were building a new protocol from scratch you wouldn't make it as crappy as TCP/IP is however the network effect has killed off the potential of an alternative. Does Bitcoin have a large enough network effect to hold back competitors? It remains to be seen but IMHO a competitor would have to be VASTLY superior not some improvements around the edge to displace it otherwise Bitcoin issues and all will be like TCP/IP. People will build around it to improve the rough edges. To stretch the metaphor somewhat TCP is stateless, oh noes that means you can't handle state on the internet right? No. It just means people designed higher level protocols to record user state at both ends while the underlying protocol (TCP/IP) remains stateless. Now someone reading this is likely thinking what about TCP/IP v6 (64 bit addressing). Well that is a good point. This is more an evolutionary change not a radical new protocol and the rollout of this evolutionary improvement has been glacially slow (timelines measured on a decade scale). Why? Is it because TCP/IP v6 will suck? No. It is just that the current protocol is "good enough". Who knows, perhaps one of the pump n dump coins will be in a good position to take Bitcoin's place should anything bring it down for whatever reason, Or not. They are 99% carbon copies. Anything that kills Bitcoin will likely kill them too. For example the most likely cryptogrpahic break will be in ECDSA. Hashing algorithms are generally pretty resistant to cryptoanlysis. Hell Bitcoin could have used SHA-1 and despite some theoretical breaks, everything would still work fine today. Public Key cryptography however is far more vulnerable both to Quantum Computing AND to good ole cryptoanalysis. If ECDSA is broken tomorrow (or the particular curve used by Bitcoin is found to be flawed) that break would affect every single clone coin. Every single one uses ECDSA. Hell not only do they all use ECDSA they all use the EXACT SAME CURVE. |
|
|
|
For me, altcoins and bitcoin will become closer and closer in value everyday.
Because altcoins do the exact same thing as BTC does, and more people realize that they can purchase more alt coins with the same amount of fiat to use at their company/organization.
So all coins will be approximately same in value in the future.
Although, all businesses can't accept 20 altcoins so it's more likely to there will be 2-3 major crypto-currencies and others are to be eliminated.
Why the mess with clones and using 2-3 crypto-currencies when one is enought. You can trade your altcoins to Bitcoin right before spending Because he owns 2 or 3 alternatives and obviously those will be the winners. |
|
|
|
I think Coinbase allows you to purchase Bitcoin with a card.
Where do people get these silly ideas. For the record neither exchange allows deposits by credit card. Credit cards are reversible so anyone selling Bitcoins for CC funds is taking a huge (as in eventually will be bankrupt) risk. |
|
|
|
Makes me wonder if it's cheap sd cards which have condensation trapped inside the casing when folks are powering them up, since it's cold outside and they're just opening the boxes quickly and connecting power.
Well the stock units don't use a sd card. The sd card slot is empty. BBB has both internal flash memory (2GB IIRC) and a SD card slot. If the internal flash memory is getting corrupted using SD card for image is a workaround. The BBB can boot either from internal memory or SD card. |
|
|
|
It is 2 hahes per clock. Each core is actually a "dual core" capable of 2 nonces per clock. So cut your speed requirement in half.
96 engines * 2 * 4 = 768 nonces per clock. 400 GH/s = 400,000 MH/s / 768 = 520 Mhz. Now that assumes 100% yield which is never going to be the case but say 550% with 90% core yield would achieve ~ 400 GH/s.
Now the radio silence is bad news, what bad news not sure but The chips as designed were designed to operate around 500 Mhz not 1.1 Ghz and processed 2 nonces per core.
I must have missed that.... if they only need to run 500Mhz though, what's all the fuss with the substrate? Edit: Oh by the way, this IS two SHA2 operations per clock right? Not two SHA operations per clock, which is the norm for SHA2, just wanna be clear. Yes it is two full SHA256(SHA256()) "Bitcoin hashes" at least according to the protocol doc. Even at ~500 Mhz (400 GH/s) @ 0.6 J/GH we are talking 300W or if you assume 0.7V nominal 430 amps. Compare that to the only other high current design, KNC and each board is "only" 180W or 250A. 430A is a lot of power so "only 500 Mhz" is still a power challenge. |
|
|
|
So just write the image to the SD card, pop it in and power it on. The unit just knows to boot off the card not internal memory automatically? wait this an october image, no? D&T you do have a November jup, right? Correct. If the issue is that the BBB is corrupting the internal memory for some reason (which given that settings are all trashed on reboot kinda makes sense) then this might work if there was a Nov img file available. It at least would be worth trying as I have nothing to lose at this point. |
|
|
|
|
Damn I just noticed the link is to an Oct image. I would need an uncorrupted copy of Nov image to test it out.
|
|
|
|
So just write the image to the SD card, pop it in and power it on. The unit just knows to boot off the card not internal memory automatically? |
|
|
|
iam using sd card for hdd beagleboard for now works
later i will send for RMA
maybe when shutoff power corrupt filesystem flash
this will happened is better if we use sdcard with custom OS knc
Can you provide exact steps? |
|
|
|
Yes. Tried both using the web GUI (with ASICs disconnected) and by doing the SD card flash procedure. Before someone else asked it was the 0.99e Nov firmware not accidentally some incompatible Oct firmware. Same exact outcome after flashing. No errors in flashing but all the same symptoms a) unresponsive to GUI b) unresponsive to SSH c) red & green lights of death on boot. d) (with ASICS disconnected) all config settings lost after power cycle Trust me I had a whole weekend with a unit that could (if it would just boot) produce 350 mBTC per day. I took the whole damn thing apart. Even disconnected the BBB from the controller and booted that separately to see if I could determine if the BBB was defective. I can always replace the BBB and if an ASIC is bad I can run the rig with the remaining modules but if the custom KNC controller board is bad well there is nothing I can do other than wait days (or weeks) for an RMA to be completed. |
|
|
|
My unit has IP address of 192.168.0.190. Going to http://192.168.0.190 gets "connection refused". SSH to 192.168.0.190 gets "connection refused". The unit never completes booting (red & green lights remain on). Just a thought, have you tried portscanning the unit during bootup and after it's sat awhile, to see what ports are open? If it pulled an IP, that's what I'd try. I get no response on any port. Yeah I am a nerd enough to try that. My guess is that when ASICs are connected something faulty in the control board is bricking the boot cycle before it ever connects to the network. I don't know for sure as I don't have a working unit (going on 4 days now) BUT my understanding is that the lights on the rig go from off, to both red & green on, to either only red (fault) or only green (mining). With rigs that have this issue the boot cycle never goes past both red & green on. You can wait minutes or hours and it will remain right there. Is there a jtag/serial connection somewhere to see output while it's booting? It looks like the PCB has a JTAG pinout but it is unlabeled and has no connector. I am not going to solder my under warranty unit and make it non under warranty. I am pretty convinced at this point it isn't a software issue. Since the BBB is just an off the shelf controller (and it works fine disconnected from the controller motherboard) my outsider (KNC should know more but they have been silent so far) view is the controller motherboard (the custom board which only KNC can replace) is defective on some units. Of course even basic testing before shipping would have caught this. My unit arrived with all mining configuration set to "X". |
|
|
|
All my machines from knc were unresponsive upon arrival... every one.
They were all fine, and just needed a bit of configuring...
If your miner seems unresponsive upon arrival....
one or more of these tips may help:
check your proxy.
1. no Http:// on stratum addresses.
2. Check your pool sign on credentials.
Make sure no space if you use the copy & paste... an empty character field can be hard to catch.
3. Make sure you turn DHCP OFF the first time you get into the GUI,
and...... assign an address before restarting, or you will have to sniff all over again.
good luck
I know you are trying to help but please try to read the problem first. None of that troubleshooting is any use. When I (and others with the same problem) say non-responsive I mean non-responsive as in a completely bricked rig. If you can get to the mining config or status page the rig isn't non-responsive. As an example. My unit has IP address of 192.168.0.190. Going to http://192.168.0.190 gets "connection refused". SSH to 192.168.0.190 gets "connection refused". The unit never completes booting (red & green lights remain on). So how exactly would I make sure the mining address is correct if the webpage is unresponsive? In this case unresponsive isn't an exaguration. The rig does ABSOLUTELY NOTHING as delivered. It doesn't even finish booting (red or green light turn off). Now if I (and others with the red & green lights of death) disconnect all ASIC boards, the rig can be accessed by the IP address (192.168.0.190 in this case). So this isn't some user error not sure of what the IP address is. Of course it doesn't matter. a) any settings entered are erased when you reboot (yes all mining config info is replaced with an "X" after reboot) and b) connecting any mining board (tried each of the 4 individually) returns to same red & green lights of death. Simple version: ASIC boards connected = a complete brick, no GUI, no SSH, no completed boot cycle (red & green lights of death). ASIC boards disconnected = GUI & SSH accessible, all settings lost when power cycled, connecting any ASIC board returns to the status above. |
|
|
|
This is exactly what mine does. I even booted it off a sd card and same issue when I plug a module in. You end up shipping your whole unit back?
Still waiting (4 days) on RMA at this point. Figure another 6 days round trip (due to weekend) even if they authorize an RMA today I am down 2.5 to 3.0 BTC and counting. I have one dead unit also. Just solid red light and solid green light. Have tried their solutions (because of time difference each solution takes another whole day and of course lost whole weekend for first answer). They have been responsive but have ignored RMA request while they suggest the SD card route that has failed. Controller seems bad. It is frustrating but they are trying at least. They may have tested individual ASIC boards but they weren't tested as fully assembled units (my unit arrived w/ mining config set to "X"). Had someone tried to even turn these units on it would not have gotten past QA. Hell just paying some guy min wage to pull units off the line which have red & green lights on simultaneously would have avoided this. They shipped a brick, it is a complete and utter brick. It isn't a unit that randomly crashes under some weird conditions, it isn't a unit when under load after hours one ASIC dies, it isn't a unit with excessively high hardware failures, it isn't a unit with a VRM that overheats and fails after days of high temp, no this is like putting a 10 pound brick in a box and calling it a mining rig. It does absolutely nothing so any testing no matter how basic would have caught this issue. Power on = does absolutely nothing. No login, no SSH, no ability to keep settings, hell even the red & green power lights don't go off ( my understanding is if red & green both stay on = your fucked signal). No possible way that got through any "testing". So KNC inability to even perform basic testing has now cost me ~$2,500 and counting. When you consider how front loaded lifetime revenue is there is no chance of ever recovering that. Hell if prior RMA hell stories are accurate I will be lucky to break even. Also just from this thread I have now seen four similar cases so my guess is this problem is certainly not an edge case. At this point I am considering just doing a chargeback (no not ask for a refund so they can delay their response until the chargeback window closes, just doing a chargeback so they get hit with the chargeback fee). If I was confident KNC could fix the problem in a timely manner (like shipping a new controller 4 days ago) it might be different but despite what the shills say the reality is with KNC if you get a fully functional unit you are fine but if you don't your fucked and it looks like by luck of the draw I ended up in the second camp. Hey KNC I KNOW YOU ARE TOO DAMN BUSY COUNTING YOUR MILLIONS TO ACTUALLY RESPOND TO THIS THREAD OR YOUR KNOW OWN CUSTOMER SUPPORT FORUM BUT ...... HERE IS A COMPLETELY GRATIS BUSINESS TIP FOR YOU, PLEASE TEST THE FUCKING UNITS BEFORE SHIPPING THEM. |
|
|
|
This is exactly what mine does. I even booted it off a sd card and same issue when I plug a module in. You end up shipping your whole unit back?
Still waiting (4 days) on RMA at this point. Figure another 6 days round trip (due to weekend) even if they authorize an RMA today I am down 2.5 to 3.0 BTC and counting. |
|
|
|
do they have serious issues?
What I am imagining is happening right now, is that they are finding that the dies do 800Mhz at 0.5W/Gh, 900Mhz at 0.7W /gh, 1000Mhz at 0.9W/Gh and 1100Mhz at 1.2W/Gh ... and are thinking something similar to "Holy fuck, now what? The boards are only designed for 350W max." (1 hash per clock, 95 engines per die, 4 dies per package, SHOULD equal 400GH... ergo needing to run at about 1100Mhz ) I think whats fair is for them to ship every baby jet with 2 modules and a 3 module sierra. Or, 2 sierras with 5 modules in total (preferred).
So that might very well be an option, shipping extra modules per unit. Or beef up the onboard power conversion, and ship single unit BJs that suck 600W at the wall... (add "2 weeks" for scramble board redesign, add "2 weeks" for PSU resourcing...) This is all purely speculative of course. It is 2 hahes per core per clock. Each core is actually a "dual core" capable of 2 nonces per clock. Why 96 cores capable of two nonces per clock instead of 192 independent cores? No idea but per the spec each chip is capable of 768 nonces per clock so the clocksped requirements are half (minus yield losses) of what you posted. 96 engines * 2 * 4 = 768 nonces per clock. 400 GH/s = 400,000 MH/s / 768 = 520 Mhz. Now that assumes 100% yield which is never going to be the case but say 550 Mhz with 90% core yield would still achieve ~ 400 GH/s. 650 Mhz with 95% output would be 474 GH/s. Now the radio silence is bad news, what bad news not sure but the chips as designed/specced should be ~500 Mhz and 768 nonces per clock (minus yield losses). |
|
|
|
So ONE YEAR LATER that same bitcoin is being transacted, THE ORIGINAL MINER still gets the coin. This is 100% wrong and no matter how many times you keep saying it, it won't get any more correct. Your understanding is flawed I corrected you and you cling to a flawed understanding. It might be a good idea to understand Bitcoin before trying to fix it. There is no such thing as the "ORIGINAL MINER" with respect to transaction fees. Fees go to the miner who places a tx into the block, that is always an active current miner. A miner who solves a block today gets the tx fees for all the transactions in the block. The fees don't go to anyone else other than the miner/pool that includes those tx in a block they solve. The miners will never get a single satoshi more in the future. Any future fees, on future txs, will go to whoever solves those future blocks. For example this block: https://blockchain.info/block-index/445880/000000000000000124725a59db557f3296ad70aac6e3ce5207238587c0656ddfthe miner includes 429 tx in the block. The sum of the tx fees for those 429 txs is 0.08670025 BTC. All 0.08670025 BTC goes to the miner (pool) which solved the block. No miner that solves a prior or future blocks gets any of that 0.08670025 BTC paid in fees. |
|
|
|
|
No that isn't how it works. First you keep using the word "blockchain" there is only one blockchain. Tx fees go to the miner who solves the BLOCK which contains the tx. i.e. if you solve a block TODAY, you get the tx fees TODAY for the tx in the block you mined TODAY.
|
|
|
|
|
If they aren't around anymore then they aren't mining, thus aren't solving any blocks, and the the tx fees aren't going to 'them' they are going to some active miner/pool who solved the most recent block.
|
|
|
|
|
Show Posts
