Last summer I was in the top tier of electricity usage, which at the rates in central California means I was paying $0.40/kWh on the last couple kWh of electricity I used. I've made a few changes to my house this year, but I'm sure I'll be hugging that line of top tier costs again, even without counting the 3 mining rigs I'm now running.
I've prepared my rigs based on an estimated cost of $0.40 USD per kWh, and only about 35% of the BTC generated (at $1.1/BTC) needs to be allocated towards electricity. The rigs should pay themselves off within 4 months even assuming a worst case scenario of summer electricity rates.
Have you considered the additional air conditioning load during summer?
|
|
|
Is there some way to download this video? My downloader plugin cannot see the file.
|
|
|
I am watching it at http://onlyonetv.com/#1 . Had to switch to 240p resolution to have it without breaks. Great job guys. Good luck with your trip TheRealPlato. That link works without complaint, thanks.
|
|
|
That's not quite correct. Miners can include whatever stuff they want into a block and solve it. Broadcasting it does not mean it will be accepted by other nodes. Bitcoin verifies the blocks follow the rules regardless of whether they are mining or not.
Yes. This was the key point that Tim B. Lee missed. If a miner includes a 100 BTC generation inside a block, rather than the normal 50, all bitcoin nodes except that miner would reject the block as invalid. If several miners collude to create 100 BTC blocks, everyone else -- namely people holding bitcoins, an audience that matters to miners -- would reject those blocks. Like a democracy, people would have to vote for a bitcoin change by downloading and running the new software. The miners cannot go completely "off the reservation" without agreement from users. And even clients that do not generate get a vote, by simply refusing to propagate rejected blocks to their peers. Much of the network wouldn't even see those modified blocks.
|
|
|
I can't watch it, what format is it in?
|
|
|
Philippe, could you go even another level higher? You want to do physical transactions, like using mobile phones?
If you want to have confidence in a transaction without being able to check it for yourself (a zero confirmation transaction) then the way to do it is connect to a bunch of full nodes and wait until they all announce that transaction to you. If you trust your internet connection isn't being tampered with, the fact that many nodes accepted it means it's very likely to confirm. A "miner backbone" of the sort discussed before would make that assurance even better.
Yes, this would work, because an honest client will not propagate an invalid transaction. But if a smartphone had Internet access, what advantage does an entirely independent lightweight client have over a lightweight client that uses a trusted full client back at the office? I can't imagine a situation that such a client, for the purpose of accepting payments, would be useful.
|
|
|
Yes, the problem with your proposal is it doesn't protect you against double spends. Verifying the txins exist is not enough.
Well, it can be enough, depending on how much you trust the counter-party. However, the normal situation of a lightweight client sending to a full client (i.e. a customer inside a brick&mortar shop) mitigates the double spend risks by limiting the window of time that can be done into miliseconds, because the full client can not only check the transaction's validity but also scan the live transaction queue for transaction that use the same inputs. But this trick functionally requires a full client with continuous Internet access.
|
|
|
Thank you for all your answers,
Let me give you the scenario I am trying to implement. - The use case does not require the light client to know the balance of its own account - The light bitcoin client receives a transaction message from the p2p network or any other insecure source - Without waiting for the transaction to be accepted by the network (by way of block creation) the light client wants to verify that the input transaction actually has money in it.
I understand that this introduces a security risk for the light client, but it is a tradeoff for usability that the user can live with since it is going to be used only for transactions with a physical presence. Thus, I am trying check the following: 1) Have the coins from the input transaction have already been accepted by the network 2) The coins from the input transaction have never been redeemed (double spent) in another transaction
Any ideas are welcomed,
Philippe
I've been thinking about this further, and I think that a lightweight client (such as would be found on a smartphone) would be one geared toward spending coins rather than receiving and verifying transactions. That said, a lightweight client, or any client, that was disconnected from the Internet could still check that a transaction was valid by pulling the relevant block headers and merkle trees from the sending client via the same connection that the transaction itself was transmitted across. Granted, this isn't safe, as it would be possible to spoof, but it certainly wouldn't be an easy thing to do. Even if both clients were lightweight, the sending client would need to have at least a skeleton copy of the blocks that confirm his own balance. This, of course, could only tell you that the coins were once owned by the sender, within a reasonable doubt; but not if the transaction is actually valid, as there still seems to be no way to check for a prior spend without scanning all the transactions in blocks that have occurred since. Such a transaction could still be accepted with the risks.
|
|
|
LOL !
Sad but almost true...
My buddy Neil Sedaka used to tell me all the time, "Some day I'm gonna read your name in Forbes."
Well, after you send him the link, he will have been right all along!
|
|
|
A single-piece plastic token containing a private key inside.... good idea! They'd still have to be hard to counterfeit, so that you'd know the token really was issued by a trustworthy source (else you might be unpleasantly surprised when you try to break the token open and redeem it).
Which is why I mentioned an RFID chip as well, which could contain the address that the private key (keypair) hidden inside refers to. So anyone with an RFID reader could check the address against a blockchain to see if the address still had the coins.
|
|
|
Wait, are you in Cuba?
Yes. Bitcoin use in an other-than-first-world nation? Unpossible! Let this thread be an object lesson to those detractors who claim that Bitcoin can't work in such places; not only do we have Chinese nationals on this forum using Bitcoin, but we now have a real communist!
|
|
|
Aren't Bill Gates and Warren Buffet paying taxes?
Relatively speaking, this is questionable. Warren Buffet has been quoted as saying that he pays less in federal income taxes than his own secretary. The point he was trying to make was that the tax code is so complicated that one needs a professional in order to utilize it to one's full advantage, which he can afford and his secretary cannot.
|
|
|
Thank you for all your answers,
Let me give you the scenario I am trying to implement. - The use case does not require the light client to know the balance of its own account - The light bitcoin client receives a transaction message from the p2p network or any other insecure source - Without waiting for the transaction to be accepted by the network (by way of block creation) the light client wants to verify that the input transaction actually has money in it.
Sounds like a portable POS system, wherein the light client is only used to accept payments, not send them. Under what conditions would such a crippled client be useful? You could do exactly the same thing using a remote client, as long as you had real time access to the Internet.
|
|
|
Please ignore all of the frustrated 'oldies', but honestly you should have tried to answer your own questions before posting this. We see this kind of thing every week, and it gets old.
For some, perhaps--but that's not the fault of a new user. It doesn't cost anything to be silent This goes both ways. When I was a newbie here, I chose to sit back a read for a while before posting anything, and once I did post it wasn't "is Bitcoin a scam"? That's comparable to seeing a hot chick in a bar and opening with the pickup line, "I guess you don't put out?". It's pretty much certain to attract an impolite response.
|
|
|
I have a new, unused mobile phone. I'm willing to sell it for some BTC. If you or your friend have a relative in Havana and want to send him/her the phone as a present, just let me know.
Please PM if you're insterested.
Wait, are you in Cuba?
|
|
|
To a stranger it looks ridiculous. Generating money either devalues the total bitcoin amount vs dollar exchange rate, or it steals your money. How can you realistically "generate" money??
Yes, it does look crazy until you understand what the client is actually doing. Please ignore all of the frustrated 'oldies', but honestly you should have tried to answer your own questions before posting this. We see this kind of thing every week, and it gets old. That said, "generating" or "mining" doesn't create money, it is a continuous attempt to solve a proof-of-work compuational problem before anyone else does in order to be the first user to verify the next block in the blockchain. The blocks contain transaction records, and the blockchain is a huge ledger of all the transactions that have occured between cryptographic accounts, ever. If your computer is the first to solve a block, and that is accepted as a fact by the network, then you are rewarded for your success with 50 newly issued bitcoins. In 2013, this block reward drops to 25, and continues to half every four years so that the total number of bitcoins in circulation approaches 21 million. This proof-of-work combined with a massive, collective and distributed ledger is how Bitcoin can be both distributed without any single point of failure and still prevent double spending of digital funds.
|
|
|
"Is Bitcoin a scam?"
Yes. So send me all your bitcoins, and you may leave unharmed.
|
|
|
Once miners like myself grow large enough to be able to buy electricity on half hourly auctions and mining at night and/or not mining at peak hours the hobbyist are going to be driven out of the mining market and I bet it will happen by 2012-2013.
There are some singular miners that you can't undercut. I don't really understand why I have to keep pointing this out, but much mining occurs in the tiny efficienty type flats of young gaming geeks. Who live in tiny flats with only electro-resistive heating, and would buy an high end graphics card anyway, most of whom already had one before learning anything about Bitcoin. This may not be your situation, but there are certainly people who do live in such a situation, and there is no professional mining setup that can drive these guys out of the mining business. I'd have thought that the market experiences with GNU/Linux and other open source software would have long proven that for-profit companies cannot compete with geeks who don't expect to make a profit. And when the heat demand for those guys drops off, then the heat demand for their peers in the Southern Hemisphere will go up.
|
|
|
As far as I'm concerned Mining profits = Solar panels Anyone ever actually looked into the time to break even on a solar panel purchase? Yes, I have. Considered getting a set put on my roof. With government subsidies and a purchasing contract from an Ohio power company, ROI was just over 7 years. Without the subsidies, ROI would have exceeded the average life expectancy of the panels themselves. Of course, I wasn't considering them for their investment value, but more for their ability to limit my own family's 'detrimental reliance' on the electric grid.
|
|
|
Plastic casino chip like tokens would work well too, and could use RFID tags inbedded into the plastic to hold the public key. And even the private key could be micro-etched onto a thin piece of metal imbedded into the plastic, so that the holder of the plastic token could tear it apart to get at the private key.
|
|
|
|