You realize that the current hashrate is like 100TH/S so they would have to add another 75TH to that in order to own 75% of the hashrate. They would need 75 1TH machines which would cost them 169425$ (Antminer S1's). For a government that kind of money is only a shit in the corner of their chest but would they really risk that kind of money for something like this?
My calculations might be a little off (I did some Google search and found that 100TH from there) so the sum might even be bigger!
No, it's WAY off. If the current hashrate is 100TH, you need to add 300TH to own 75% of the hashrate |
|
|
|
Do we need a system to detect blockchain fork, both intentional (an attack) and accidental (the March 2013 fork)? As the value of bitcoin increases, the cost of mining an invalid block becomes very high. Therefore, all nodes should relay a block, even an invalid one, as long as it's hash is not significantly higher than the target (say 3%), is not significantly larger than the block size limit (say <1.05MB), and does not take too much resources to verify (cf. other block limits like sigop restriction). A few percent room is suggested to detect any unexpected behaviour in these edge cases. Regardless of the block content, a block header is always relayed if there were enough PoW or just slightly above the target. Miners will include their public keys in the coinbase. For safety reason, this key-pair shouldn't be associated with any bitcoin as it has to be hot stored. For anonymity reason, the same miner may use a new public key for each block he finds. When a owner of the last X blocks (say X = 2016) see a new valid block, he will sign a message ("Block witness report") and broadcast to the network: I am running <bitcoind version>. The block, with <hash>, is first seen at <timestamp>. This is the <first/second/third.....> block of height <height> I have ever seen. I think this block is valid This timestamp is the time he first saw the block header If he thinks the block is invalid, he will sign this: I am running ..........(same as above). I think this block is invalid because <reason> If he just got the block header, he will sign this: I am running ..........(same as above). I see the block header only A miner shouldn't sign any conflicting Block witness report, or his public key will be black-listed. Nodes will relay Block witness reports as long as they are signed by eligible miners. The bitcoind will run in safe-mode if there are long competing forks. Merchants will be able to detect a fork early, and refuse to deliver until the fork is resolved. What if a miner tries to abuse this system to DoS the network? 1. They may deliberately mine a invalid block. Therefore, the red flag should be raised only if there is an invalid chain with >1 blocks, not just a single invalid block. Anyway, an attack like this is very costly and the effect is limited. 2. They may troll us by claiming valid blocks as invalid. Therefore, the red flag should be raised only if there is an actual fork, not just a invalid chain. Therefore, the attacker has to mine a side chain to make the attack successful. With <50% mining power, he will most likely lose all mining reward. ------------ If this system was implemented in the Mar 2013 fork, what would it look like? All clients will see 2 competing chains growing For 0.7 clients, although they think the v0.8 fork is invalid, they will notice that all v0.8 nodes think it is valid, while all/most v0.7 nodes think it is invalid. Even worse, the invalid chain becomes longer and longer. The safe-mode is triggered For 0.8 clients, although they think both chains are valid, they will find all/most v0.7 nodes reject the v0.8 chain (the longer chain), and some people are mining on top of the v0.7 chain (the shorter chain). The safe-mode is triggered ------------- If an attacker suddenly release a chain of 6 blocks, outpacing the current chain, all bitcoin nodes will go to safe-mode. Human intervention is required. By looking at all the Block witness reports, it will be easy to identify the attacker's chain. Participation in block witness is optional. But once a miner decided to join the system by including his key in the coinbase, nodes on the network will expect Block witness reports from this miner for the following 2016 blocks. If the miner failed to continuously submitting reports, he will be blacklisted. This will make an attack more difficult because while the attacker is mining a fork secretly, he has to acknowledge the honest fork or his power as witness is lost. To make it more difficult to cheat, we may have "witness report for block witness report", which eligible miners will timestamp and sign other miners' block witness reports. |
|
|
|
Your proposal won't work, because there is no centralized timing source.
Well, if that would be true then the difficulty adjustment would also not work. In order to be able to adjust the difficulty you need to know how long it took to generate the last 2016 blocks. So there *is* some knowledge of time. It is not exact, but it is there and it is sufficiently precise to make adjustments of difficulty that keep the block generation from getting runaway. My idea is to use these ideas from that code that do the difficulty adjustments to implement the scenario described. Regarding the time source I was thinking about some sort of NTP-like time propagation protocol which the clients would use to track something called "current network time". A NTP service could be used by random nodes to obtain the current time but the real NTP queries should be very infrequent and made only by a few nodes, essentially the network should collectively keep track of time. The nodes shall poke throughout the network, asking random node about the time (and JUST only about the time) and then update their clock accordingly. Difficulty adjustment works because it happens only once in 2016 blocks. An attacker trying to manipulate timestamp will only produce a very small effect on the difficulty. There are already many discussion saying why it is a bad idea to adjust difficulty for each single block As mentioned earlier, if we had a reliable decentralised NTP service, we don't even need a blockchain in the first place. Your proposal is like trying to lifting yourself off from the ground with your own hands. And finally, if someone owning 99% of hashing power decides to attack the network, there are many many ways to do so. Even if you system could be successfully implemented, the attacker could keeping mining empty blocks so no transactions may go through. |
|
|
|
|
If the computer does not connect to network at all, any OS would be fine
|
|
|
|
As I remember, in the BIP50 fork, Gavin first thought we should follow the longest chain, and Luke suggested to orphan the longest chain.
As someone who was there and involved in dealing with it I don't recall any _dispute_, I'm really unhappy about the history revisionism people throw around hwere— it was obvious what needed to be done: there was a chain that was acceptable to all nodes, and a chain that was acceptable to a small minority (which, on quick testing didn't include many major businesses)— because of the consolidation of hash-power around pools the mining deployed software looked very much unlike the systems overall, but even if it had been a slim majority only one was acceptable to all nodes. Being acceptable to all nodes meant that the issue could be healed back to consensus immediately— as soon as the acceptable-to-all chain was also the longest, the other side would have meant weeks of split consensus as people gradually fixed their software. I am not saying that there were any dispute. At least we may have some SOP: in case there is an accidental fork, we prefer the more restrictive one until a better solution is available. I hope this won't eventually make the rules too restrictive. |
|
|
|
From that same article: "Caballero’s team has big plans aside from Facebook and is currently working on a universal tipping platform for WordPress, Drupal, Joomla, Xenforo, PHPBB and others."
But that is not good news for bitcoin, is it? It is a competitor, not an adopter. Those scam coins will eventually be doomed to fail. The main point is Facebook allows crypto coin apps It says "Universal tipping platform" so I guess that includes Bitcoin. All of these as-of-yet BTC-unaware Joe Averages will start to see things popping up such as "Like my article/blogpost/video/whatever? Fund/support/tip me with some WhateverCoins" and that should lead to them having to buy those WhateverCoins first because of course mining is way to complicated for your Joe Average. Also it could lead to a leveling of the Altcoin playing-field when a mass of those crypto-unaware users can buy whatever coin they deem fit for their needs which to me seems like one big step in the direction of mass adoption of cryptos in general which, correct me if I'm wrong, is what we're all waiting for. Besides: >700 on Monday Future's bright, nuff' said  That facebook apps supports like 10 crypto coins, not including bitcoin. Although Joe Average may start with a scam coin, he will eventually find that's worthless and will go to bitcoin |
|
|
|
|
Not possible: CPU is just an ASIC.
|
|
|
|
From that same article: "Caballero’s team has big plans aside from Facebook and is currently working on a universal tipping platform for WordPress, Drupal, Joomla, Xenforo, PHPBB and others."
But that is not good news for bitcoin, is it? It is a competitor, not an adopter. Those scam coins will eventually be doomed to fail. The main point is Facebook allows crypto coin apps |
|
|
|
|
Your proposal won't work, because there is no centralized timing source.
|
|
|
|
and many political debates could be avoided. There has never been a single political debate about buggy behavior like that, and I never expect there to be one. Non-determinism in a consensus system is a fatal error, no one has any impression that it ought to stay. A document also will not reliably resolve non-deterministic behavior, since the behavior that would have been non-deterministic would simply have not been specified in the document. As I remember, in the BIP50 fork, Gavin first thought we should follow the longest chain, and Luke suggested to orphan the longest chain. I am not criticizing the decision, but this decision made the double spend against OKPay possible. If we had a document, I think the most natural decision was to follow the longest fork, as it apparently had nothing wrong. |
|
|
|
Talking about RFC, I think Peter will use the SIGHASH_SINGLE example again ( https://bitcointalk.org/index.php?topic=260595.0 ). Yes, there could be many undiscovered bugs in the code. However, as a start, the RFC may just mention some fundamental rules, such as the block reward schedule and structure of block headers. As we learn more and more about the code, we could then document more sensitive parts of it. |
|
|
|
You can sync up a totally unmodified 0.2.10 node, or initial release if you add a gateway to deal with the checksum on the version handshake. They're just not reliable in the face of reorgs and can get stuck. If you drop in the one line bdb config change, they're even somewhat reliable (but SLLLLLLLLLLLLLOOOOOOOOOOWWWWWWWW). I think the "one line bdb config change" is already a hard fork. Anyway, it just depends on the precise definition of "hard fork". We may have one more type of forks: to turn a non-deterministic behavior into a deterministic one. The worst fact revealed, however, is the existence of non-deterministic behavior in the rules of bitcoin, and we won't be sure if there were still other undiscovered non-deterministic rules. There were some debates on whether we should have an RFC of bitcoin rules. If we had a RFC, all non-deterministic behaviors (like BIP50) and bugs (like BIP42) could be fixed based on the document and many political debates could be avoided. However, some argued that RFC won't be helpful because eventually only the actual source code matters. Having an RFC is just translating C++ into English, and one could never do it perfectly. I think having an RFC, agreed by most stakeholders, is still better. The RFC is not an English transaction of C++, but a contract that all bitcoin users agreed to. Otherwise, it is always arguable that Satoshi put the indefinite monetary supply there intentionally and BIP42 is actually violating the "real" spirit of bitcoin. |
|
|
|
On page 4, that article by Academic Prof. Kristoufek says For examination of the relationship between the USD and Chinese Renminbi (CNY) Bitcoin markets, we use prices and volumes of the btcnCNY market which is by far the biggest CNY exchange. But "btcnCNY" is BTC-China, which at the time the article was written (after MtGOX was found to be insolvent) was essentially dead. No wonder his fancy wavelet method found no influence of "China" on the USD price. He must be excused however, since his source for price series is www.bitcoincharts.com -- which STILL refuses to admit the existence of any Chinese exchange other than BTC-China. Your account opened on Dec 2013. Do you even know anything about bitcoin before that? BTCChina was always the leading exchange in China, until they started to charge fee in mid-December 2013. Kristoufek's analysis is mainly about the pre-2014 price, so he should look at nothing but BTCChina |
|
|
|
You're missing a few early ones:
The max blocksize was reduced from 32MiB (an accidental limit?) to the present 1MB.
Various limits were added/lowered on PUSHDATA length, sigops, etc. (this happened multiple times)
OP_RETURN marks tx as invalid was also associated with changing the scripting system to evaluate scriptSig and scriptPubKey separately, rather than concatenated together with OP_CODESEPARATOR in the middle.
Also the Berkely DB bug is arguably not really a hard-fork as it wasn't deterministically triggerable - only most, not all, 0.7 nodes had issues with it.
If most pre-0.8 nodes couldn't process our current chain, it's already a hard fork. Actually, no one is running a pre-0.8 node: https://getaddr.bitnodes.io/dashboard/How about BIP-0030 Duplicate transactions? Is it also a soft-fork? https://github.com/bitcoin/bips/blob/master/bip-0030.mediawikiI'd also like to clarify the status of the 2 violations of BIP-0030. Does it mean 100BTC was permanently burnt? |
|
|
|
|
I want to single list for all consensus rules changes in the history. I am referring only to those affecting block validity. Other protocol rules, e.g. isStandard, is not counted.
Terminology:
Hard-fork: an invalid block under old rules may become valid under new rules
Soft-fork: 1. a valid block under old rules may become invalid under new rules; 2. not a hard-fork
These are the rules changes I am aware of since version 0.1. All of them are soft-fork except BIP-0050
CVE-2010-5137; July 2010; v. 0.3.5; OP_LSHIFT and some other OP codes disabled *
CVE-2010-5141; July 2010; v. 0.3.5; OP_RETURN marks tx as invalid
CVE-2010-5139; Aug 2010; v. 0.3.11; fixing output value overflow
BIP-0016; Apr 2012; P2SH
BIP-0034; Mar 2013; v.2 block. block height in coinbase
BIP-0050; Mar/May 2013; v. 0.8.1; Discovery/fix of Berkeley DB "bug" (the only hard-fork in the history?)
BIP-0042; Jun 2014; v. 0.9.2; zero block reward after block 13,440,000
* Currently, CAT, SUBSTR, LEFT, RIGHT, INVERT, AND, OR, XOR, 2MUL, 2DIV, MUL, DIV, MOD, LSHIFT, RSHIFT are disabled. Were they disabled in the same fix?
Have I listed all consensus rules changes?
|
|
|
|
|
看樓上的回應, 我觀察到有一個有趣的現象: 從前很多認為央行封殺就是末日的言論, 現在都沒有了. 看來那些沒信心的, 不懂比特幣的, 在多次封殺後都被洗走了. 這是一個好現象
|
|
|
|
How long have we waited brothers to see the 1 week macd turn green? Its been a long 6 months but we're on the cusp guys.
I have created a "combined" BTC price by putting together the major exchanges https://www.tradingview.com/e/lrCSkda8/guess what? weekly MACD has crossed to green It is crossed on Huobi but not stamp nor btc-e |
|
|
|
|
Show Posts
