Careful with BTC-E, they have an outrageous BTC withdrawal fee.
And have the lowest trading fee |
|
|
|
The EU forced Cyprus' hand. Why would Japan force Japan to seize bank funds so that Japan will bailout Japan.
Exactly, the Japanese government can print more yen to bailout their banks |
|
|
|
that was just a standard reorg.
No, new v1 blocks should be rejected and not shown at all |
|
|
|
|
v2 227940 is found
000000000000017760e964f1e54abad7b2aebefb9023f42324ea4548db9b373
|
|
|
|
Yes, that's strange. I'm using 0.8.1 and does not see the v1 blocks at all |
|
|
|
The latest 2 blocks (227938, 227939) are both version 1. What's going on??? A fork?? Something strange happened..... I'm running 0.8.1 and only have 00000000000001f205a713a6e23dd2f8c3eed42ffbd765bdfe54d353757ee18a (227938, v2) However, blockchain.info has no record of 00000000000001f205a713a6e23dd2f8c3eed42ffbd765bdfe54d353757ee18a, and have 0000000000000124fefda3e554e72cd08aad4b9caaa6e4c3221ae93238180c0c (227938, v1) and 000000000000025fcc58a882db6c3b47ea90935b522c08d279e415b9529de41d (227939, v1) instead |
|
|
|
The latest 2 blocks (227938, 227939) are both version 1. What's going on??? A fork?? |
|
|
|
|
What happens to the few coinbase transactions with duplicate transaction id? Are the coins irrecoverably lost?
|
|
|
|
Currently waiting to transfer flights in Europe, this week should be fun.
You have a new Cypriot client?  |
|
|
|
I'll give OP a bitcoin if it hits $1000/BTC this year. Will not happen.
Didn't you sell all your bitcoin at $10? |
|
|
|
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.  For a long-term bitcoin believer, selling at 20 and buying back at 40 is losing 50% of bitcoin Good luck with your double top call. This pattern has happened many times in the past 2 months. |
|
|
|
LOL! 1. See a double top at 20ish 2. Sell your bitcoin 3. Buy back at 40ish 4.  5. Profit As I'm planning to make some large purchases of BTC, I decided to perform an in-depth price analysis as I would before taking any significant position in any market. I come from a background in equities, futures and FOREX and I'm still learning the ins and outs of the Bitcoin exchange market and "Bitconomy", but technical analysis abstracts away most of the underlying fundamentals and allows a trader to focus on the market action / data itself. It amounts to a form of "mass psychology", allowing the analyst to make "forecasts" on asset prices. So what I've done here is spent a little time analyzing the BTC/USD rate and attempting to decipher the ebb and flow of the market from the charts and data. Some people swear by the technicals, and some hate it... But it's made me several small fortunes over the years, and that's enough for me.  Here we go... The overall picture I have of the BTC/USD rate is one with a very bullish long-term future; but due for a short-term correction. The resistance we have seen in the $22.00 neighborhood has proven much stronger than most would've thought, and there it seems that sell orders are stacking up. There are also a lot of traders on OTC trying to liquidate their holdings of several hundred BTC. I think we're simply over-extended at these levels, and need a healthy correction. Lots of speculative $ are stacked up in the BTC and trigger fingers are itchy... Let's look at the chart-work: First we need to take a look at a 3-month chart, to get an idea of what's been happening over a wider time-frame:  It seems apparent we've been on a major tear, and the bulls haven't been able to keep running. That is one big divergence in our moving averages, and the MACD is indicating a big drop in momentum. I think it won't be long before we have a cross in the MACD and the rolling correction (if we get one) begins. As of right now we're merely hovering just beneath resistance and just above the EMA-14. Volume has sloped off as well. A little bit of selling pressure can trigger a much bigger move. Now we'll take a look at what has happened in the last 10 days:  I have added numbers on this chart to comment on each thing... 1) The most troubling bearish signal I see here is the classic double-top pattern. This is a bearish pattern in which the market reaches a high point, falls back, attempts to reach a new high but fails -- followed by a correction or sell-off. 2) This shorter time-frame gives us a snapshot of MACD as it is approaching the signal line for a cross. Falling below the signal line typically indicates a high potential for downward momentum which will carry on for a while. There is also a growing negative divergence, which is evident by looking at the expanse of the histogram. 3) The #3 points to the tightest resistance line, found around $21.50. We have tested this resistance line twice, and have failed both times. This strongly suggests we're not ready to take out this conceptual barrier just yet -- we've already had a tremendous move. 4) Both of our exponential moving averages (EMAs) are beginning to take a negative attitude and are rapidly converging. We should watch for a cross in the EMA-14 and EMA-60 and interpret it as a signal the correction may be beginning. 5) Volume, volume, volume!!! Where has all the buying volume gone off to? I can tell you: people are feeling iffy about this current price level after this huge move up. This has a very bearish echo, in my opinion, as it suggests new buyers/speculators are not pumping the $ into BTC at this level. People (by which I mean regular users) are complaining about Bitcoins being "expensive" to buy, and that means a slowdown for Bitcoin sellers. A slowdown for sellers means less buy orders on the exchanges, and we all know what that means. They say "price is king", but volume can speak volumes.  I'd like to say a few things to conclude my analysis and break-down... By looking at the EMA-60 on the 3mo chart (the first picture), we can estimate that support will fall around the $16 level. Prices tend to stick to longer-term moving averages in corrections, and that's the one I've got my eye on. I think it's best we take some profits here and now and let this thing cool off. It's not good to stretch too far too fast -- you create big bubbles that can bust a whole economy. So don't view a correction as a bad thing but rather a very good thing. It will give us all the opportunity to make an intelligent and thoughtful re-entry into the BTC market and enjoy the next leg-up. But keep in mind that technical analysis is NOT about "predicting" markets -- none of this is set in stone. Technical analysis is a never-ending quest to become a master of data and chart interpretation and make better risk management and trading decisions. Personally, I'm planning to buy a large amount of BTC right away. But I'm actually going to transfer it all to my new MtGox and exchange accounts to sell and hold in the form of fiat, giving the correction some room to run. As the price falls I will be buying BTC in increments, in a pyramid-shaped fashion -- this "dollar cost averaging" will allow me to progressively improve my entry point into the market and actually lower my average unit cost. Of course, I'm also accumulating a lot of gold and silver. In dollar terms, gold and silver are a bargain -- and we have another round of QE underway. The good thing about holding gold and silver during a BTC/USD correction is I get a lot more bang for my buck when I sell my bullion and move back to cheaper BTC. Regards, --ATC-- ____________________________________________________________________ If you enjoyed my market analysis send a tip to: 13M9QLc5BDQe2iuB1N3Br58fYvJF5ixihTI'll start doing this on the regular and in a lot more depth/detail if people enjoy it. |
|
|
|
可以转到一个地址，也可以转到多个地址，可以小于25BTC，但是不能大于25BTC，全部由挖出来的矿工(通常是矿池)决定。
普通交易需要inputs，造币交易不需要。
應該是25BTC加上交易費 |
|
|
|
Ambiguous limit like 48xx or a varying limit due to a bug is unacceptable. That's why a new limit (4500) was added. This is a NEW rule. Aren't we talking about the fork (when the bug (your so-called "rule") placed a limit at 48xx)? Yes, the unacceptable nature of that rule is why we created a new rule as soon as we learned about it. Pretending it was never a rule is just distorting the facts. Also, note that in most cases the 48xx is an exact (unknown) number. It just wasn't worth anyone's time to figure out what it was. You are basically saying that it is NOT an exact number. To be a rule, "most cases" is not enough, it has to be true for EVERY cases. |
|
|
|
Ambiguous limit like 48xx or a varying limit due to a bug is unacceptable. That's why a new limit (4500) was added. This is a NEW rule. Aren't we talking about the fork (when the bug (your so-called "rule") placed a limit at 48xx)? |
|
|
|
https://en.bitcoin.it/wiki/BIP_0050A rule should be something agreed to every nodes. However, according to BIP0050: This would be an issue even if the entire network was running version 0.7.2. It is theoretically possible for one 0.7.2 node to create a block that others are unable to validate, or for 0.7.2 nodes to create block re-orgs that peers cannot validate, because the contents of each node's blkindex.dat database is not identical, and the number of locks required depends on the exact arrangement of the blkindex.dat on disk (locks are acquired per-page). As there is no consensus even among the same version (unless you can prove the otherwise), this is absolutely a bug, not a rule. There is indeed a bug in pre-0.8 versions, but part of that bug was also a protocol rule. Which part is you referring to? Please elaborate. A rule should be something reproducible in every single node of the same version. (e.g. the CHECKMULTISIG bug could be considered as a rule) "No more than 48xx unique transaction references per block" The exact number was never identified (a new limit of 4500 was added to be safer), and in some edge cases (due to the bug) could vary, but in no circumstance except a 50% attack would cause a blockchain fork. To be a rule, you need an exact number like 4823, i.e. a block is accepted by every node if it has 4823 unique tx references, and rejected by every node if it has 4824 unique tx references. Ambiguous limit like 48xx or a varying limit due to a bug is unacceptable. |
|
|
|
https://en.bitcoin.it/wiki/BIP_0050A rule should be something agreed to every nodes. However, according to BIP0050: This would be an issue even if the entire network was running version 0.7.2. It is theoretically possible for one 0.7.2 node to create a block that others are unable to validate, or for 0.7.2 nodes to create block re-orgs that peers cannot validate, because the contents of each node's blkindex.dat database is not identical, and the number of locks required depends on the exact arrangement of the blkindex.dat on disk (locks are acquired per-page). As there is no consensus even among the same version (unless you can prove the otherwise), this is absolutely a bug, not a rule. There is indeed a bug in pre-0.8 versions, but part of that bug was also a protocol rule. Which part is you referring to? Please elaborate. A rule should be something reproducible in every single node of the same version. (e.g. the CHECKMULTISIG bug could be considered as a rule) |
|
|
|
Miners have no incentive to employ monitoring of the blockchain via multiple clients like Eligius did to avoid mining any blocks on the invalid chain, if they're just going to be reimbursed anyway.
Except that in this case 0.8 miners were technically mining on a good chain and it was quite hard to detect that there was a problem. My pool has been always checking if it has the same blockchain as some other nodes, obviously this cannot cover all possible cases. No, you mined an invalid block (under the standing Bitcoin rules) and other 0.8 miners were building on top of an invalid chain. If you were testing against multiple implementations, you could have caught the problem as Eligius did. (Not to say you are at fault for the hardfork, but these are the reality of it) You are really crazy. Yes, start off with an ad hominem. Fits your post pretty well. Slush was creating blocks with "official" client and following the dev's advise to increase the block size. There is no such thing as official, and I already agreed he isn't at fault for the problem. The block is accepted by every 0.8 nodes. What do you mean by "an invalid block under the standing Bitcoin rules"?
EDIT: If a bug could be considered a "rule", should we all move back to v0.1 as it represents the "orthodox" bitcoin rules? There was a hardfork around the move to 0.3, so that is the oldest that would work to any extent with the standing Bitcoin rules. Changes in rules require advance planning and notification, and the consent of the economic majority (note, not the mining majority). Nobody had any notice of 0.8's rule change (because nobody knew about the rule), and the majority of Bitcoin users (including the economic majority) enforced the standing rules. 0.8 was the "odd man out" disagreeing over the network rules. All* the other clients agreed the block was invalid. The objective way to look at the situation is to pretend 0.8 was a completely new client with unknown source/origin introduced to the network by an unknown party. * The only other exception I am aware of was Coinbase's proprietary node, which I think can be agreed does not make a difference on its own.A rule should be something agreed to every nodes. However, according to BIP0050: This would be an issue even if the entire network was running version 0.7.2. It is theoretically possible for one 0.7.2 node to create a block that others are unable to validate, or for 0.7.2 nodes to create block re-orgs that peers cannot validate, because the contents of each node's blkindex.dat database is not identical, and the number of locks required depends on the exact arrangement of the blkindex.dat on disk (locks are acquired per-page). As there is no consensus even among the same version (unless you can prove the otherwise), this is absolutely a bug, not a rule. |
|
|
|
|
Show Posts
