charged with storing child poem by default for having an encrypted file on your dash cam.
Posting from your phone? DAMN YOU AUTOCORRECT!!! |
|
|
|
The sun is powered by fusion which generates less radioactive waste. The reactors here on earth are powered by fission.
O rly? Give it time. Nothing generates more radioactive elements than stars. The sun will itself easily generate far more radioactive elements than will all the nuclear fission reactors earth will ever use, combined. Just give it a chance.  This. Everything heavier and more complex than hydrogen has only one source, so all nuclear waste as well as we creatures who produce it are the long-term byproducts of the death of stars. We are, as Carl Sagan put it, "star stuff contemplating the stars, organized collections of ten billion billion billion atoms, contemplating the evolution of nature, tracing that long path by which it arrived at consciousness here on the planet earth, and perhaps throughout the cosmos." |
|
|
|
I assure you, quite serious. I'm now going back and trying to do MACD on a log scale over the same time period to see if I can confirm or deny your crossover indicators. I suspect there will be quite a bit of confirmation.
Keep in mind that what I posted was a moving average with a very large number of days. If you're looking for something accurately representing the real time at which the crossovers occurred, here's an SMA 60, EMA 20 and daily median price plotted the same way: http://bitcoinreference.com/sites/default/files/u1/6-month-log-trends-all.png |
|
|
|
pure art
You know, usually I smirk and repeat the old saw about log charts showing anything you wish to see. But that was just pure art. It's hard to find fault with the way you've drawn the trend line, nor the staring me in the face pattern. I'm in awe. That makes my crude charting look like bison drawn on cave walls with feces. There you have it, technicals and fundamentals seem to agree. Now is not the best time to buy.  Edit: also, when 1 BTC was a third of a cent would have been the best time to buy. Now is good but then was better |
|
|
|
|
If you're testing then use testnet. The difficulty is low enough to be trivially mined and the testnet faucet has thousands of coins which it still gives away 5 at a time for the extremely lazy.
|
|
|
|
If everybody would just mine and hold or buy and hold until they can't get out at a profit, the price would always go up.
That's the definition of the suckers in a pyramid scheme. If you've been in the game for half an hour and you don't know who the patsy is, you're the patsy.DRINK! Bitcoin don't need an ever-expanding pool of suckers. We need the software that makes them more useful. It's coming, but I don't know when. Agreed, to an extent. Value is driven by scarcity and scarcity per capita increases when the demand pool is growing faster than the supply pool, so an ever-increasing pool of users increases value proportionally. The difference is whether we're calling them "suckers" or "users" and that's a pretty fine line right now. Bitcoins admittedly have no value other than what we agree they do as a market, but of course the same can be said for the US Dollar and any other world currency - what CAN'T be said about them is that they're hard to use and few people accept them. Apparent legitimacy and ability to use as payment regularly is what pushes us over the line into "user" territory. That said, we're an android app or credit-card-like embedded system away from being equivalent to an early paypal instead of an early eGold (y'know, minus the centralized shut-down-able nature of eGold). |
|
|
|
If everybody would just mine and hold or buy and hold until they can't get out at a profit, the price would always go up.
That's the definition of the suckers in a pyramid scheme. Indeed, this is prisoner's dilemma meets free market. As long as everyone hoards and nobody sells artificial scarcity means everyone looks wealthy on paper. Problem is, right NOW this pyramid is starting to wobble. 2/3 of the mining capacity is less than 30 days old. We newbies aren't the faithful, we've got power bills to pay and hardware to re-invest into if we want to catch up to you old fogies. With [H]ocp possibly even more "easy money" miners are coming in. This means that while in the past the vast majority of mined coins were hoarded that's definitely not true now. We really could have most of the mined coins being sold within a week of being produced. In which case, without fresh injection of funds, you'd see action much like what you see in the market -- someone stabilizing the buy side with fake buy walls (and notice how other 'buyers' are too timid to step far away from that wall) while they themselves slowly cash out. I saw a 400+ coin buy taken out quickly, while the tiny orders were left alone. Short term bear, long term bull is my take on it. Trees don't grow to the sky. I can't agree more:  60-day SMA on a log scale with my best estimate of a trendline drawn in. I imagine a self-correcting market oscillating like a sine wave around a trendline and so far that's what I see. More charts and full writeup at my site. I'm certainly not claiming to have the whole thing figured out but as someone who is in this thing for the long haul, the long-term trend is still looking good enough that I'm sticking around to see where it goes. Short term bear while we're under the trendline, probably another big rally to get us back over it followed by another bear and so on until we reach peak market saturation, which is quite some time off yet. |
|
|
|
I have to disagree - The solution to "Block stealing by pool operators" would be to allow third party audits. The Pool software records every share found in the database it's connected to. along with the actual hash it is recorded whether bitcoind accepted that hash as a valid solution
DELETE FROM shares WHERE hash = 'stolen block hash'; now audit me.  *checks the SQL logs* heeeeyyyyyy..... |
|
|
|
Someone needs to fire up Tor/I2P/etc and make a "Coin Wash" site.
Someone sends in an arbitrary amount of BTC along with multiple new addresses. The BTC that go in are broken into randomly-sized portions and sent to the new addresses at random intervals, interleaved with other transactions (minus a fee of course). If multiple coin washers existed they could also send coins to each other with instructions to forward. If such nodes also ran their own private testnet of sorts (zero fee) and sent mountains of arbitrary transactions with the right format it could be quite difficult even for even the ISP to sort the real transactions from the fake (see: chaffing and winnowing).
I think the above should be sufficient to beat analysis-based attacks, using Tor or I2P beefs up protection against analysis a bit more and I trust that the security already bundled in the bitcoin client should cover the rest.
Have I missed anything?
never used it but think this is something like that http://bitcoinlaundry.com/can listen to more about it here http://agoristradio.com/?p=407The problem with something as simple as bitcoinlaundry is that simple network analysis undoes your anonymity. If Alice wants to send Bob 3.14 BTC without it being traceable, bitcoinlaundry says "hand it to Charlie and have Charlie hand it to Bob" which, in the context of bitcoin, is a good start because at least it keeps your address off the books and all someone could conceivably discover is that you sent coins to Charlie, right? Problem #1: if Dave has the ability to watch what Charlie sends and receives, he can pretty easily see that Alice sent in 3.14 BTC and soon after Charlie sent that exact amount to Bob - unless your transaction is an amount that a huge volume of others will be sending (1 BTC even perhaps) it is easily identified. Charlie could also be scrutinized by watching the timing of several known transactions and then observing the money in/out timing of unknown transactions. Problem #2: Since Charlie operates on the open internet under his real name his equipment (and wallet) could be seized by the authorities quite easily. It's very difficult to do this sort of thing properly without keeping at least temporary records of where money came from and where it is destined. Problem #3: Even if you solve problem 1 and 2, chances are that Charlie isn't performing enough transactions each day to properly disguise who sent what to whom. Even if he is, such data is not made available and neither Alice nor Bob have any way of knowing whether their transaction will be securely hidden among the transactions of others. Charlie could easily generate many fake transactions to hide the valid ones, but I don't know how similar testnet (or namecoin or any blockchain branch really) traffic looks to valid BTC traffic when sniffed offhand, I may be barking up the wrong tree on this one. Much like running an exchange the security and thought process that must go into a coin washer are NOT trivial. Unlike an exchange, the first time one of these gets hacked it'll probably be by the government and people will probably go to jail as a result, so if anyone takes this and runs with it - DO IT RIGHT. |
|
|
|
|
Someone needs to fire up Tor/I2P/etc and make a "Coin Wash" site.
Someone sends in an arbitrary amount of BTC along with multiple new addresses. The BTC that go in are broken into randomly-sized portions and sent to the new addresses at random intervals, interleaved with other transactions (minus a fee of course). If multiple coin washers existed they could also send coins to each other with instructions to forward. If such nodes also ran their own private testnet of sorts (zero fee) and sent mountains of arbitrary transactions with the right format it could be quite difficult even for even the ISP to sort the real transactions from the fake (see: chaffing and winnowing).
I think the above should be sufficient to beat analysis-based attacks, using Tor or I2P beefs up protection against analysis a bit more and I trust that the security already bundled in the bitcoin client should cover the rest.
Have I missed anything?
|
|
|
|
|
So my big question is: what percent of all transactions go to 0/unconfirmed and never actually verify? Is there any way to find this number and compare it to the percent of all credit card transactions which are reversed, transaction fees and CC fraud?
Most merchants are pretty accustomed to a plethora of possible fees and reversal scenarios for CC payments and as such have typically rolled an amount of expected loss into their business plans. The point of bitcoin is to make reversals impossible and blockchain errors rare - no matter what we do there will still always be a margin of error and a small bit of fraud. What's important isn't creating a flawless system, what's important is creating a BETTER system. If we can (provably) show that the expected rate of loss for BTC is drastically lower than credit card transactions and make it easy to use, merchants will adopt it more readily.
|
|
|
|
|
OK so maybe I'm just too impatient but --statsdump creates an empty file and hasn't populated anything yet. How often does this file get written to?
|
|
|
|
|
If storage is cheap enough to use decimal/numeric in your database instead of floats then why can't you spend the extra storage to max out that field when you made it in the first place. MySQL allows up to 65 digits in the decimal data type, and MS SQL allows 38. Since these are the two most common database engines you'll encounter in the wild, I'd suggest limiting orders around the least common denominator: decimal(38,8).
I've written a couple personal projects that store BTC and USD values in a database and I assure you every such field is decimal(38,8) - I'd never even consider using anything else.
|
|
|
|
|
In all honesty, I think the Mt Gox attack is going to be good for BTC in the long run:
1. It forces providers of vital services like exchanges and eWallet providers to really re-consider their security measures, which is good for all of us.
2. It will help to cement public opinion of bitcoin as something with real value - after all, most people won't go out of their way to hack and steal something with no real value, right?
|
|
|
|
I wonder if the anti-nuclear-power folks realize that the sun (source of all energy and life on earth) is itself a gigantic nuclear reactor. Granted I'd be much less comfortable with the sun's presence if it weren't so far away but still |
|
|
|
|
I haven't had a chance to look into the Yubikey all that much. Mt Gox says that the yubi they send you is useable with their service only but is that the case for most such keys or could a standard yubikey be used to auth to multiple sites?
|
|
|
|
As far as fail over goes, try using the new poclbm. It haa built in failover to whatever your back up pool its at whatever -f you have for your main pool. Even if poclbm isn't as fast for you as whatever you're using, it might be worthwhile until bitHopper is working properly for you.
Don't really feel like changing all of my miners and re-building all my scripts around a new executable. Might be minor for those of you who have two or three nodes but I'm playing with 14 Edit: For the record, since I'm pretty sure I haven't stated before, I'm running puddinpop's opencl miner under winxp |
|
|
|
Yet another wall of errors and half my hashrate is going to my backup pool (running at -f60 priority in case the proxy fails)  Request.finish called on a request after its connection was lost; use Request.no
tifyFinish to keep track of this.
[00:09:22] RPC request [] submitted to bitclockers.com
caught, Final response/writing
Request.finish called on a request after its connection was lost; use Request.no
tifyFinish to keep track of this.
Caught, jsonrpc_call insides
TCP connection timed out: 10060: A connection attempt failed because the connect
ed party did not properly respond after a period of time, or established connect
ion failed because connected host has failed to respond.. |
|
|
|
2) Crashes on that line?
Removed it. Not needed. I'm unsure why it was sucking so much work though... I did up the timer for the stalls to half a second a piece. It looks like your miner is timing out too quickly. I got these sorts of stalls with poclbm. Phoenix stalls less although it will try and double submit shares.
EDIT: Actually I think it is a server side LP issue. Which I think I just fixed. I accidentally had error'd LP calls call the lp handler
Updated, it appears to be running and I haven't seen another error yet. I'm keeping my eyes open and fingers crossed though  Thanks! (damn you work fast) |
|
|
|
Getting the following a lot: Unhandled error in Deferred:
Unhandled Error
Traceback (most recent call last):
File "D:\Python27\lib\site-packages\twisted\internet\defer.py", line 361, in c
allback
self._startRunCallbacks(result)
File "D:\Python27\lib\site-packages\twisted\internet\defer.py", line 455, in _
startRunCallbacks
self._runCallbacks()
File "D:\Python27\lib\site-packages\twisted\internet\defer.py", line 542, in _
runCallbacks
current.result = callback(current.result, *args, **kw)
File "D:\Python27\lib\site-packages\twisted\internet\defer.py", line 1076, in
gotResult
_inlineCallbacks(r, g, deferred)
--- <exception caught here> ---
File "D:\Python27\lib\site-packages\twisted\internet\defer.py", line 1020, in
_inlineCallbacks
result = g.send(result)
File "D:\bitHopper\work.py", line 140, in jsonrpc_getwork
request.finish()
File "D:\Python27\lib\site-packages\twisted\web\http.py", line 866, in finish
"Request.finish called on a request after its connection was lost; "
exceptions.RuntimeError: Request.finish called on a request after its connection
was lost; use Request.notifyFinish to keep track of this. Doesn't seem to crash or anything, it recovers quickly, just thought I'd notify you Edit: Scratch that, it is now happening so often that I'm getting more errors than actual traffic and an unreasonable amount of hashing power is falling to my backup pool, I've switched back to a previous build that still seems to work just fine, but whatever this is, it's BAD. |
|
|
|
|
Show Posts
