I started selling yesterday and finished today. But selling at $20 and buying again at $40 doesn't mean you lost any money. It just means you missed an opportunity. And the fear of missing an opportunity has driven men beyond counting to ruin.  Good advice. But, buying again at $40 was a good trade only in retrospect. And was that not fear of missing an opportunity? TA is uncertain and we will see false breakouts. Selling to "buy again" on a false breakout and not only did you miss an opportunity, you also lose money. That's why selling to buy dips, in an uptrend, is a losing strategy. You are very lucky to beat the market and if you keep playing, your gains will almost certainly (eventually) be less than the market. I should know. I have only about 1/3 of the coins I had at $2.00, and I don't ever expect to recover them trading. This market is too bullish even for me. I could kick myself for trying to sell tops and buy dips ever since $2, even more than for not selling at $30 in '11 (doubled my coins rest of the way down). If one is going to trade, there will be good trades and bad ones. You don't get to look back and say "if only I had made only the good ones and none of the bad." You take the good with the bad. So, I'm not saying that you should never take gains. But I am saying that if (like me) you can't help yourself from trading , an "all out/all in" strategy is extremely risky (due to false breakouts). If you want to pick tops, my advice (for whatever its worth) is to be patient and scale out in small portions through target ranges. Adjust your holding percentage to your degree of certainty. There is much volatility ahead, and the less panic trading, the better (both individually and collectively). |
|
|
|
|
Proudhon, will you please wait until single digits (even for a split second) before saying you "called it". I'll eat my dirty socks, if it turns out you did.
|
|
|
|
damn you crazy BTC. I give up trying to sell high buy low, all I end up doing is sell high, buy higher.
That has always been my experience too. You know what, I had this exact same dialogue with ribuck around $2.00 on April 28 2011. I have stopped daytrading/weektrading for the time being. Selling is just too risky. Agreed. I have got it wrong every time that I have sold, and I have ended up buying back into Bitcoin at a higher price. |
|
|
|
Lol ^ they said the same thing about IPv4 when it was invented, who would need more than 4,294,967,296 IP addresses? Time for "Bitcoin-IPv6" databases, which 0.8 already uses.
In 0.8 BerkeleyDB was replaced with LevelDB. |
|
|
|
We pay a small fee, or just kill off s.dice until we can get a better fix.
A small fee will more or less kill off 90% of s.dice transactions anyway.
If you kill S.DICE, you will kill bitcoin. S.DICE has attracted many new and wealthy users to bitcoin. We don't have much else in bitcoin economy (just miners and hoarders speculators). Bull. Various company/stock "share" scams are not the bitcoin economy. That's just what the pirate investor and pass-through operators wanted people to believe. GLBSE is now gone and was barely a blip. I would be extremely careful with S.DICE and other "shares". IMO, shares are worth about as much as the paper you could print them on. Hoarding, speculating, and operating services are the main activities which add value to the bitcoin economy. But every attempt so far to do deposits-for-interest has resulted in either lost or stolen coins. |
|
|
|
Now I understand, thanks for taking the time to explain. So we actually hit some arbitrary limit that existed all along because of the used BDB libraries, so developers will need to emulate it in future software versions until all network upgrades, then we can be sure no hard forks happen for this reason. Quite interesting to study but rather painful to experience when using it.
The BDB limit is the default set_lk_max_locks (max locks) setting of 10000. It is easily fixed by including a DB_CONFIG file in the 0.7 bitcoin application directory with a higher max locks setting. That DB_CONFIG file should allow 0.7 clients to accept blocks up to the 1MB hard/protocol limit without choking, as the developers were expecting when they released 0.8 and asked pools to raise their target block sizes to the 1MB limit. |
|
|
|
That is not correct. v0.7 nodes accepted a 1MB block on testnet. The issue was more complex then just the size of the block. By the protocol the block which was rejected by some nodes SHOULD have been accepted. The 250kb soft limit was simply a default for block construction. Even with it in place nodes should have accepted properly constructed blocks up to the 1MB limit. It also appears not all v0.7 nodes were affected. Some accepted the problem block and some didn't. The defect/limit in BDB wasn't documented and didn't occur in all versions/platforms. It appears the number of transactions being changed as a result of the block validation crossed some "magic code" not in the Bitcoin source code but undocumented in some implementations of BDB.
v0.7 reliance on BDB caused it to be fundamentally broken/flawed. Its actions weren't consistent with the documented protocol, the higher level source code, or anyone's understanding/expectation of what should have happened. Nobody was saying/thinking oh yeah if you make a block with more than x transaction it will abort, cause a rollback, and result in a rejection. It was a landmine.
The problem was lack of a DB_CONFIG file in the bitcoin application directory. Without that file, BDB simply chose to use default settings. The default setting of 10000 for set_lk_max_locks is not enough to handle larger blocks with many transactions (inputs and outputs). Easy fix. |
|
|
|
|
This why any settings should always be set explicitly, even if they have defaults. It makes it harder to forget about them.
|
|
|
|
He lost BTCguild's entire hot wallet in under 60 seconds. But that was due to a different issue with the way his pool software messed up while upgrading to 0.8 (miners were suddenly being credited at difficulty=1). It was a separate issue from the blockchain fork. |
|
|
|
This is not accurate.
There was, indeed, testing on the testnet with a full (1 MB) block. This was accepted by both the 0.7 and 0.8 versions. There is no concern here.
Slush's block should have produced the same valid block. However, the block was structured carefully as to expose a problem in 0.7 that was never discovered. Not only was this an extremely difficult problem to catch, but its finding would in fact not have been accelerated with a mixed testnet. The introduction of 0.8 into the equation would actually delay finding the bug, as it would mean less time spent testing edge cases on 0.7.
Source? @dree12: Do you mean it was done on purpose? Source? It wasn't done on purpose. The bad block was produced by the slush pool (mining.bitcoin.cz) after he upgraded to 0.8 and set his max block size to 1MB. The problem was that the BDB (Berkeley database) settings (max_locks) used in the pre-0.8 clients were not sufficient to handle a large and complex (many txins and txouts) block. berkeleydb was replaced with leveldb in 0.8. #bitcoin-dev IRC channel<jgarzik> sipa: so what was special about the block in question? <gavinandresen> jgarzik: 998,081 byte, 1700+ transaction block <@gmaxwell> samurai1200: there is a target blocksize. It defaults to 250k. With txn slow last week due to SD being 90+% of all blocks, Gavin and Mike went around and nagged pools to increase their target sizes.. so its not surprising that someone was running with a big setting. The target size is just a commandline option. <@gmaxwell> Arguably any setting over 500 is exposing undertested parts of bitcoin, because prior to 0.7.x (?) the target size was hard coded at 500. <EvilPete> basically, the slush pool generated a larger block (within protocol limits) and the old 0.7 bitcoind stuff tripped over its bdb usage and dropped it, causing the fork. <@gmaxwell> The soft limit change was slush manually setting his target blocksize to 1MB. <LightRider> Which was encouraged by Gavin. <gmaxwell> Indeed. But although people did say "uh. yuck" no one suggested this kind of risk as far as I know. <@gmaxwell> One mistake we made here in hindsight was exposing the target going over 500kb without doing more testing with >500kb blocks.  <@gmaxwell> BlueMatt: Can you get a blocktester test in that tries to get a extreme maximum number of distinct inputs+outputs? Like 4000 in and 5000 out? <petertodd> gmaxwell: Testnet doesn't have much in the way of large blocks, the only ones >500KB are the ones I made, and they're just single transactions. <gmaxwell> petertodd: There are some with >2000 TXN and such, but they don't have large numbers of txins because I was spending 50 tnbtc blocks. <TradeFortress> would fuzz testing have prevented this bug? <gmaxwell> TradeFortress: no. We do fuzz test. Perhaps a very specialized kind of fuzztester (that produced valid blocks with random txn, e.g. simulating a whole network) would. Hello everyone,
Í've just seen many reports of 0.7 nodes getting stuck around block 225430,
due to running out of lock entries in the BDB database. 0.8 nodes do not
seem to have a problem.
In any case, if you do not have this block:
2013-03-12 00:00:10 SetBestChain: new
best=000000000000015aab28064a4c521d6a5325ff6e251e8ca2edfdfe6cb5bf832c
height=225439 work=853779625563004076992 tx=14269257 date=2013-03-11
23:49:08
you're likely stuck. Check debug.log and db.log (look for 'Lock table is
out of available lock entries').
If this is a widespread problem, it is an emergency. We risk having
(several) forked chains with smaller blocks, which are accepted by 0.7
nodes. Can people contact pool operators to see which fork they are on?
Blockexplorer and blockchain.info seem to be stuck as well.
Immediate solution is upgrading to 0.8, or manually setting the number of
lock objects higher in your database. I'll follow up with more concrete
instructions.
If you're unsure, please stop processing transactions.
--
Pieter
|
|
|
|
|
Pull it and replace with a staircase. Then watch the price climb.
|
|
|
|
I think we should forget about stability for next year. rising so high will not lead price to stability.
Indeed, +/- 10 USD swing will become our routine, 2011-style massive plunge could happen on a weekly basis. +/- 10 USD of a price in the triple digits, where it would only be a <10% change. But 2011-style volatility will not become the norm. There would be too many losers in a market that inefficient. Losers leave, and trading volume decreases until it basically flatlines. That's what happens after penny stock pump and dumps. In contrast, with bitcoin we are seeing the second growth cycle in an efficient market (as efficient as any market of its size). The fact that we have a second growth cycle suggests that the overall trend is sustainable, with more cycles to come. |
|
|
|
|
warped linear chart is linear. post it in log scale FFS
|
|
|
|
I think we'll get close to or maybe go over 50 and crash hard again, we'll do this for a few weeks, and then finally start going down where we will find stability at ~20$
why is $20 your magic number? |
|
|
|
This thread's title makes no sense at all.
verdict: bubble topDo you have enough conviction this time to take some bets on it? |
|
|
|
let me also open with a well-defined hypothesis:
"Since there exist time-dependent autocorrelations in price data, past performance sometimes correlates with future results."
That's not a hypothesis. You have a premise "there exist autocorrelations", and then you restate that premise in the form of a definition. There is no inference/conclusion, so no hypothesis here. evidence against TA would be evidence that time-dependent autocorrelations do not exist in price data.
Of course there exists time-dependent autocorrelations in price data. Why else would people be buying on speculation? Because there's an upward channel going up, a (highly correlated) time-dependent autocorrelation. Pretty much everybody here loves TA, I don't know who you are talking about by making a general address to "TA nay-sayers". You should qualify it by bearish TA nay-sayers. do you see what i see?
I don't know, what do you see? Are you (again) calling the top, a reversal? |
|
|
|
36
well.. that's what i get for bragging about a $33.8 buy. |
|
|
|
33
My turn to be that lucky guy..  I very rarely do intra-day.. this was a very lucky best ever  |
|
|
|
Adjusted for inflation, this thread is at 602...
$100/BTC by the 1000th page. |
|
|
|
$35 is probably a good wall. more should be built there may last short term 5 days I'm guessing $35 is not a good spot, a pullback from resistance there would like a false breakout above $32. It should go high enough that it can pullback and bounce off $32. |
|
|
|
|
Show Posts
