AFAIK there are 2 open databases of orphan blocks, https://www.biteasy.com/ and https://blockchain.info/ . However, they don't have data before 2014. Also, it seems blockchain.info reports more orphan blocks than biteasy.com but I haven't matched the results. I wonder if anyone is keeping a database of all orphan blocks. I know it is not easy to define "orphan blocks" because it is trivial to fork the chain when the difficulty was low. I'm particularly interested in those "buggy forks", e.g. the negative value output in 2010 and the v0.8 fork in 2013, and forks with double spending. (I thought there was also a fork related to P2SH in 2012 but I'm not sure. I learnt bitcoin after BIP16 was done) |
|
|
|
|
With the ever-growing blockchain, storing and verifying blockheader may become a problem for extra-light SPV clients. Would that be beneficial to include the merkleroot of blockheaders in coinbase (as a soft-fork)? Therefore, SPV clients will only need to store headers of relevant blocks.
|
|
|
|
In BIP62, it says Zero-padded number pushes Any time a script opcode consumes a stack value that is interpreted as a number, it must be encoded in its shortest possible form. 'Negative zero' is not allowed. See reference: Numbers. The native data type of stack elements is byte arrays, but some operations interpret arguments as integers. The used encoding is little endian with an explicit sign bit (the highest bit of the last byte). The shortest encodings for numbers are (with the range boundaries encodings given in hex between ()).
0: OP_0; (00)
1..16: OP_1..OP_16; (51)..(60)
-1: OP_1NEGATE; (79)
-127..-2 and 17..127: normal 1-byte data push; (01 FF)..(01 82) and (01 11)..(01 7F)
-32767..-128 and 128..32767: normal 2-byte data push; (02 FF FF)..(02 80 80) and (02 80 00)..(02 FF 7F)
-8388607..-32768 and 32768..8388607: normal 3-byte data push; (03 FF FF FF)..(03 00 80 80) and (03 00 80 00)..(03 FF FF 7F)
-2147483647..-8388608 and 8388608..2147483647: normal 4-byte data push; (04 FF FF FF FF)..(04 00 00 80 80) and (04 00 00 80 00)..(04 FF FF FF 7F)
Any other numbers cannot be encoded.
In particular, note that zero could be encoded as (01 80) (negative zero) if using the non-shortest form is allowed. If I try to use non-standard push in the scriptPubKey, without zero-padding, would that be allowed? For example, is the scriptPubKey "5101019C" spendable under BIP62? OP_1 OP_PUSHDATA(01) OP_NUMEQUAL Currently, I think this is spendable with an empty scriptSig. |
|
|
|
tx malleability could cause big trouble. I think all devs agree that we have to fix it some point in the future. However, due to the risk involving soft-fork, this could only be done very slowly. Now we have BIP66 but there are still many forms of malleability to be fixed. I propose to have to a technique called "semi-soft-fork" as a remedy before a real soft-fork is done. Currently, transactions are divided into standard and non-standard. I propose to divide it into 3 types: - Standard tx (ST): a valid tx with a strict set of scriptSig and scriptPubKey, with all known malleability issues fixed
- Type 1 non-standard tx (NST1): any mutated standard tx, otherwise valid
- Type 2 non-standard tx (NST2): any other valid tx not in the previous categories
A block with only ST is a standard block (SB). A block with at least 1 NST1 non-standard tx is a Type 1 non-standard block (NSB1). A block with no NST1 but with at least 1 NST2 is a Type 2 non-standard block (NSB2). SB, NSB1 and NSB2 are all valid blocks, just with different level of standardness Miners joining this semi-soft-fork will still try to mine the longest chain, no matter the blocks in it are SB, NSB1, or NSB2. However, if there are forks with same length, the miner will always switch to the fork with least number of NSB1. If there are enough miners joining this semi-soft-fork, it will provide incentive for the rest of miners to avoid NST1 and NSB1. Therefore, the risk of tx malleability is reduced. And since this is not a consensus rule change, it is easily reversible if anything goes wrong. It will also allow us to test the anti-malleability code before we migrate to a real soft-fork. |
|
|
|
|
I'm running armoryd.py in supernode mode (on Linux) but it is scanning very slowly. I want to add some RAM but can't do that without interrupting the scan. How could I stop it gracefully?
|
|
|
|
|
Is it possible to count the number of tx in a block without downloading the whole block? (e.g. only using the Merkle tree)
|
|
|
|
|
Reviving this thread.
With all the discussion in blocksize fork, could we consider to implement this public-key-free signature? It will save about 15% space for a standard 226 bytes 1-input-2-outputs transaction.
Roughly speaking, CPU speed and network speed doubles every 18 and 21 months respectively. Therefore, it makes sense to shift the burden from the network to CPU. Also, it is always possible to fall back to the traditional signature verification.
|
|
|
|
Targets: 1. DIY: A 10-year old child should be able to do it 2. High quality: true 256bit randomness 3. Human verifiable: using CCD noise or radioactive decay is not acceptable because it is difficult to verify the randomness 4. Low cost: cheap, not too time-consuming to generate a random number ---------- Procedures: 1. Buy a deck of at least 43 blank, name card sized, white paper cards. All cards should be perfectly same size 2. Pick a card, write "1" and "2" on it in this way:  3. Flip to the other side, write "3" and "4" in the same way 4. Pick another card, write "5", "6", "7", "8" in the same way 5. Repeat for totally 43 cards (1 to 172) 6. Put the cards into a big black bag 7. Shake the bag really really vigorously and randomly 8. Stake the cards without looking a them 9. Determine the "upper side" of the deck without looking at it. (To determine the upper side, there are 2 dimensions) 10. By the order of the cards, write down the numbers on the upper side 11. You have a sequence of 43 numbers with 261bit entropy. Do whatever you want with it  Permutation of 43 cards give you 175 bits, and the orientation of each card gives you 2 extra bits ------------------- If you are able to find some perfectly square cards, you can reduce the number of cards to 38 by doing like this:  So each card will have 8 numbers on it. Permutation of 38 cards give you 148 bits, and the orientation of each card gives you 3 extra bits. Totally you get 262 bits. You can also do the same with 34 perfect octagon cards. Having smaller number of cards will not only save you some time, but also make the shuffling easier and thus more random ------------------- Why not standard playing cards? A full deck of 54 cards give only 237 bits, and more cards means more time to record the results Other ideas are welcomed |
|
|
|
Dell accepting bitcoin could be MUCH bigger than you think http://ww4.sinaimg.cn/bmiddle/6d9e93aajw1eii0tf52tgj20hs0h6ac5.jpgAndy, a Chinese, shared his experience on Weibo (Chinese Twitter). With the 10% discount, he bought an Alienware 14 ( http://www.dell.com/us/p/alienware-14/pd.aspx) for 6442CNY in bitcoin The same item is selling at 11999CNY in China: http://item.jd.com/1107676.html . He saved 46% You may wonder why he couldn't buy it from dell.com directly before. Due to strict foreign exchange control, Chinese people could hardly have a "foreign currency credit card", and usual credit cards could not pay bills in USD or other foreign currency. As Dell now accepts bitcoin, Chinese people could order from dell.com directly, asking them to deliver to the US address of Haitao ( http://www.haitao.com/ ), who will then ship the item to China. This is only the beginning. |
|
|
|
|
For security reasons I prefer not to upgrade the offline wallet of 0.86.3, but now it seems it's incompatible with the latest version. Any solution?
|
|
|
|
|
We know there is a number of losers in the auction. They all think they are outbid (i.e. someone offer higher price than them). Is it possible that the US gov actually has a hidden reserve price for these bitcoin, and some or even all bitcoin were not sold? This is possible according to the FAQ. I don't think it's likely and if this is true, it is extremely bullish.
|
|
|
|
由於本區討論質素日益低下, 本人決定設立一系列之高質討論專區, 並由本人直接管理. 本人亦不會再參與中文區內任何其它討論 規則: 1. 本專區由本人管理, 違反規則者可不作警告直接刪貼, 如不喜歡者請不要在此發言 2. 本專區只限討論技術問題. 投資, 政策等題目請勿在此發言 3. 本專區絕不容忍刷貼及一切軟硬廣告, 將直接刪除 4. 任何轉貼文章, 必須附上原出處之連結, 經提醒後不改正者可被刪除 5. 任何翻譯文章, 必須附上原語言文章之連結, 經提醒後不改正者可被刪除 6. 發佈不實信息, 被指出後仍重覆發佈, 視情況可被刪除 7. 有關山寨幣的技術問題, 如非與Bitcoin直接有關, 可被刪除 8. 本專區歡迎任何人發言, 但對於Activity愈低者, 規則會執行得愈嚴格 本人文章如註明CC BY-NC-SA 3.0, 表示轉載者必須引述本人名稱(jl2012@bitcointalk), 不得用於商業用途, 分享時亦必須以相同條款分享. 具體條款見: http://creativecommons.org/licenses/by-nc-sa/3.0/ . 如需用作商業用途, 或以其它條款重新發佈, 請先與本人聯絡 如果你喜歡我的原創技術文章, 請考慮捐款, 謝謝! |
|
|
|
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. |
|
|
|
|
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?
|
|
|
|
The block interval follows exponential distribution of lambda=1/10, with mean = 1/lambda = 10 and variance = square of the mean = 100. It is not uncommon to see block intervals of >1 hour and that could be really annoying. Having two blocks too close to each other is also a waste of block space. As the variance is the square of the mean, we may decrease the variance by decreasing the mean but that would have other side effects. It is possible to decrease the variance to 50 while keeping the mean as 10: 1. A miner will first mine the following message |Version|hashPrevBlcok|hashCoinbase|Bits|Nonce-a| until it is below the target. The difficulty is determined to archive an average successful rate of 5 minutes. hashCoinbase is the 256-bit hash of the desired reward transaction. The miner won't broadcast the message 2. When a valid hash is found in the step 2, the miner will start to hash the following message: |Version|hashPrevBlcok|hashCoinbase|Bits|Nonce-a|hashMerkleRoot|Time|Nonce-b| until it is below the target. The average successful rate is also 5 minutes. This is the valid block to broadcast to the network 3. A block is valid if it satisfies all the following requirements: - Hash of |Version|hashPrevBlcok|hashCoinbase|Bits|Nonce-a| is below the 5-minutes target
- Hash of |Version|hashPrevBlcok|hashCoinbase|Bits|Nonce-a|hashMerkleRoot|Time|Nonce-b| is below the same 5-minutes target
- Hash of the reward transaction is same as hashCoinbase
- All other existing rules, e.g. all transactions are valid, timestamp requirements
The block time interval will follow Erlang distribution ( http://en.wikipedia.org/wiki/Erlang_distribution) with lambda=1/5 and k=2. The mean is k/lambda=10, and variance=k/(lambda^2)=50 The block header size will be expanded from 80bytes to 116bytes. We can further decrease the variance by decreasing the difficulty while requesting more nonce. For example, we can decrease the difficulty to 1/3, then: First step: |Version|hashPrevBlcok|hashCoinbase|Bits|Nonce-a| Second step: |Version|hashPrevBlcok|hashCoinbase|Bits|Nonce-a|Nonce-b| Final step: |Version|hashPrevBlcok|hashCoinbase|Bits|Nonce-a|Nonce-b|hashMerkleRoot|Time|Nonce-c| The mean block time interval is still 10, but the variance decreases further to 33.33 For each additional nonce requested, 4 bytes additional bytes are needed Why need a hashCoinbase? We need to make sure people can't steal the partially completed block of other miner It may make some types of one-confirmation double spend attack easier. I'm not very sure. Any comments? |
|
|
|
|
Show Posts
