Zen Protocol stays up to date with what’s happening on Bitcoin. Miners add Bitcoin block headers to Zen, then everyone—miners and nodes—agrees on which headers are in the Bitcoin chain with the most work.
Zen Protocol stays up to date with what’s happening on Bitcoin. Miners add Bitcoin block headers to Zen, then everyone—miners and nodes—agrees on which headers are in the Bitcoin chain with the most work.
Finding SHA256 partial collisions via the Bitcoin blockchain
This is not a cryptocurrency post, per se. I used Bitcoin's blockchain as a vehicle by which to study SHA256. The phrase "partial collision" is sometimes used to describe a pair of hashes that are "close" to one another. One notion of closeness is that the two hashes should agree on a large number of total bits. Another is that they should agree on a large number of specific (perhaps contiguous) bits. The goal in Bitcoin mining is essentially (slight simplification here) to find a block header which, when hashed twice with SHA256, has a large number of trailing zeros. (If you have some familiarity with Bitcoin, you may be wondering: doesn't the protocol demand a large number of leading zeros? It does, kind of, but the Bitcoin protocol reverses the normal byte order of SHA256. Perhaps Satoshi interpreted SHA256 output as a byte stream in little endian order. If so, then this is a slightly unfortunate choice, given that SHA256 explicitly uses big endian byte order in its padding scheme.) Because Bitcoin block header hashes must all have a large number of trailing zeros, they must all agree on a large number of trailing bits. Agreement or disagreement on earlier bits should, heuristically, appear independent and uniform at random. Thus, I figured it should be possible to get some nice SHA256 partial collisions by comparing block header hashes. First, I looked for hashes that agree on a large number of trailing bits. At present, block header hashes must have about 75 trailing zeros. There are a little over 2^19 blocks in total right now, so we expect to get a further ~38 bits of agreement via a birthday attack. Although this suggests we may find a hash pair agreeing on 75 + 38 = 113 trailing bits, this should be interpreted as a generous upper bound, since early Bitcoin hashes had fewer trailing zeros (as few as 32 at the outset). Still, this gave me a good enough guess to find some partial collisions without being overwhelmed by them. The best result was a hash pair agreeing on their final 108 bits. Hex encodings of the corresponding SHA256 inputs are as follows: 23ca73454a1b981fe51cad0dbd05f4e696795ba67abb28c61aea1a024e5bbeca a16a8141361ae9834ad171ec28961fc8a951ff1bfc3a9ce0dc2fcdbdfa2ccd35 (I will emphasize that these are hex encodings of the inputs, and are not the inputs themselves.) There were a further 11 hash pairs agreeing on at least 104 trailing bits. Next, I searched for hashes that agree on a large number of total bits. (In other words, hash pairs with low Hamming distance.) With a little over 2^19 blocks, we have around (2^19 choose 2) ~= 2^37 block pairs. Using binomial distribution statistics, I estimated that it should be possible to find hash pairs that agree on more than 205 bits, but probably not more than 210. Lo and behold, the best result here was a hash pair agreeing on 208 total bits. Hex encodings of the corresponding SHA256 inputs are as follows: dd9591ff114e8c07be30f0a7998cf09c351d19097766f15a32500ee4f291e7e3 c387edae394b3b9b7becdddcd829c8ed159a32879c156f2e23db73365fde4a94 There were 8 other hash pairs agreeing on at least 206 total bits. So how interesting are these results, really? One way to assess this is to estimate how difficult it would be to get equivalent results by conventional means. I'm not aware of any clever tricks that find SHA256 collisions (partial or full) faster than brute force. As far as I know, birthday attacks are the best known approach. To find a hash pair agreeing on their final 108 bits, a birthday attack would require 2^54 time and memory heuristically. Each SHA256 hash consists of 2^5 bytes, so 2^59 is probably a more realistic figure. This is "feasible", but would probably require you to rent outside resources at great expense. Writing code to perform this attack on your PC would be inadvisable. Your computer probably doesn't have the requisite ~600 petabytes of memory, anyway. The hash pair agreeing on 208 of 256 bits is somewhat more remarkable. By reference to binomial distribution CDFs, a random SHA256 hash pair should agree on at least 208 bits with probability about 2^-81. A birthday attack will cut down on the memory requirement by the normal square root factor - among ~2^41 hashes, you expect that there will be such a pair. But in this case, it is probably necessary to actually compare all hash pairs. The problem of finding the minimum Hamming distance among a set doesn't have obvious shortcuts in general. Thus, a birthday attack performed from scratch would heuristically require about 2^81 hash comparisons, and this is likely not feasible for any entity on Earth right now. I don't think these results carry any practical implications for SHA256. These partial collisions are in line with what one would expect without exploiting any "weaknesses" of SHA256. If anything, these results are a testament to just how much total work has been put into the Bitcoin blockchain. Realistically, the Bitcoin blockchain will never actually exhibit a SHA256 full collision. Still, I thought these were fun curiosities that were worth sharing.
Attacking bitcoin with classical simulation of quantum computers?
Bitcoin is a digital currency based on blockchains. Each block in a blockchain contains transaction information, and bitcoin miners "mine" each block in order to verify the transactions. When a miner mines a block, he receives a hefty reward (6.25 bitcoins). To mine a block, a miner has to do this: SHA256(SHA256(bitcoin block header info))) to produce a hash with a certain amount of leading zeroes. Now, let's say I want to produce a hash with 94 bits of leading zeroes. If we use the classical brute force method, we would need to iterate through 2^94 SHA256(SHA256(x))) hashes before finding a valid hash output. However, if we use quantum computers, which implement Grover's algorithm, which provides a quadratic speedup, we would only need to iterate through 2^47 hashes. Is this doable with a quantum computer simulator on a classical computer? If we need to iterate through 2^47 hashes, then 47 qubits should suffice. From what I know, 47 qubits can be simulated on a classical system. Therefore, if we use a 47-qubit quantum computer simulator, can we find a bitcoin block hash with 94 bits of leading zeroes? If so, how long would this take (months? years?)? I'm not very familiar with quantum computers yet; I'm only starting to learn about it.
Newbie here. I'm not yet familiar with bitcoin mining, just a bit interested. The bitcoin block header, as we all know, is consisted of the nonce, the timestamp, the Merkle root, nBits, and the hash of the previous block. Miners usually increment the nonce by 1, until they exhaust all 2^32 possibilities and find the solution. However, I have read that it is very common for miners to exhaust all 2^32 combinations and not find a solution at all. As a result, they have to make slight changes to the timestamp and/or the Merkle root to calculate even more combinations. Therefore, what is the probability of a miner exhausting 2^32 combinations without finding a valid nonce in a specific block? Does it have something to do with the bitcoin mining "difficulty" thingy? I'm so confused right now......
I brought BTCRelay up to date again in preparation for the relaunch of ethereumlottery.io
BTCRelay gives Ethereum smart contracts access to Bitcoin block headers. Some of you might have noticed that for the last half year or so no one had submitted block headers to BTCRelay and it had fallen behind the Bitcoin main chain. Over the last few weeks I have worked on bringing it up to date again in preparation for the relaunch of ethereumlottery.io - a lottery which determines the winner based on the hash of a specific Bitcoin block. As of today it is fully synced again. Shout-out to ConsenSys as well, who were very helpful in the process. Thanks! For the near future I plan to keep BTCRelay updated and for now will set the access fee to zero. That means free access to recent Bitcoin data! I hope you build something cool! :-)
Idea on combining bitcoin and ethereum via contract and sidechain
I think would be super neat is if it was possible to make a sort of bridge between Ethereum and Bitcoin. I've yet to develop any smart contracts so take this idea with a grain of salt / not sure if it's possible but seems like it could be. If there was an eth contract that kept updated with Bitcoin block headers you could have contracts which called into it and could tie transactions to blocks and future block heights. This could be done by allowing multiple competing chain and realigning the forks after so many blocks. On Bitcoin side there could be some colored coin or sidechain which allowed linking to the above listed subcontract. If a sidechain could follow different rules ie would watch Ethereum subcontract and when it was fulfilled could finish the Bitcoin transaction (this I know absolutely 0 on, not sure if possible). This could enable using Bitcoin as the medium of exchange while keeping $ transferred in Bitcoin (minus the fees required to use Ethereum gas). Why not just use Ethereum for this and sidestep Bitcoin completely? If we assume Bitcoin Cash will continue to have cheaper transaction fees than Ethereum (which I think is fair to assume, at least for this thought experiment) you could have very many transactions completed on Bitcoin when the contract was fulfilled, allowing for lower fees overall for the end users. Curious on what you think of this idea. If it is completely unfeasible then... we should find out how to make it happen! The way I see Ethereum is that it is the king of smart contracts-- but this flexibility has a price. I see Bitcoin cash as the king of cheap dumb transactions-- but it is quite limited in its ability. If we could better unify them I think it'd be a force multiplier!
New BIP: Hardfork warning system | Johnson Lau | Dec 01 2016
Johnson Lau on Dec 01 2016: This BIP defines a change in consensus rules regarding to block nVersion, and define a concept of generalized block header to implement a hardfork warning system for full nodes and light nodes. For better formatting, visit github https://github.com/jl2012/bips/blob/hfwarning/bip-hfwarning.mediawiki BIP: ? Title: Hardfork warning system Author: Johnson Lau Status: Draft Type: Standard Created: 2016-12-01 Abstract This BIP defines a change in consensus rules regarding to block nVersion, and define a concept of generalized block header to implement a hardfork warning system for full nodes and light nodes. Motivation Softfork and hardfork are the 2 majors categories of consensus rules change. Generally, softforks make some previously valid blocks invalid, while hardforks make some previously invalid blocks valid. Bitcoin has successfully introduced a number of new functions through softforks. A built-in warning system is also available in many implementations to warn users for the activation of any unknown softforks. Some features, however, may not be easily introduced with a softfork. Examples include expanding maximum block resources limits, and changing the average block time interval. When such features are implemented with a hardfork, existing full node implementations would consider such blocks as invalid, and may even ban a peer for relaying such blocks. They are effectively blind to such hardfork rule changes, leaving users to unknowingly transact on a system with potentially different token value. On the other hand, light nodes may blindly follow a hardfork with unknown rule changes and lose the right to choose the previous system. This BIP defines a change in consensus rules regarding to block nVersion, and define a concept of generalized block header to implement a hardfork warning system for full nodes and light nodes. Definitions Valid block A block that satisfies all the consensus rules being enforced by a bitcoin protocol implementation. An implementation may intentionally (e.g. a light node) or unintentionally (e.g. unaware of a softfork) not enforcing any part of the current netwrok rules. Valid blockchain A blockchain constituting of only valid blocks. Best valid blockchain The valid blockchain with highest total proof-of-work. Valid blockchain fork A valid blockchain sharing a common ancestral block with the best valid blockchain, but with less total proof-of-work Generalized block header Any serialized hexadecimal data with exactly 80 bytes (byte 0 to byte 79). The bytes 4 to 35 are the double-SHA256 hash of another generalized block header. The bytes 72 to 75 are nBits, the target of this generalized block header encoded in the same way as normal bitcoin block header. The 2 most significant bits of the byte 3 are the hardfork notification bits. The semantics of other data in a generalized block header is not defined in any general way. It should be noted that a normal bitcoin block header is a special case of generalized block header. Generalized block header chain A chain of generalized block header. A header chain of valid blocks is a special case of a generalized block header chain. Specifications Block nVersion softfork A softfork is deployed to restrict the valid value of block nVersion. Upon activation, any block with the second highest nVersion bit set becomes invalid (nVersion & 0x40000000) This softfork will be deployed by "version bits" BIP9 with the name "hfbit" and using bit 2. For Bitcoin mainnet, the BIP9 starttime will be midnight TBC UTC (Epoch timestamp TBC) and BIP9 timeout will be midnight TBC UTC (Epoch timestamp TBC). For Bitcoin testnet, the BIP9 starttime will be midnight TBC UTC (Epoch timestamp TBC) and BIP9 timeout will be midnight TBC UTC (Epoch timestamp TBC). Any bitcoin implementation (full nodes and light nodes) supporting this softfork should also implement a hardfork warning system described below. Validation of generalized block header A bitcoin protocol implementation should consider a generalized block header as valid if it satisfies all of the following criteria:
• It is a descendant of the header of a valid block in a valid blockchain (the best valid blockchain or a valid blockchain fork). • It satisfies the proof-of-work requirement: its double-SHA256 value MUST be smaller than its target (encoded as nBits). • Its target MUST NOT be greater than the target of its last ancestral valid block by more than 1024 times. An implementation may decide to use a different threshold (or dynamic threshold), depending on its tolerance against potential DoS attacks by generating many low difficulty headers. However, if the value is set too low, a hardfork with lower difficulty may not be detected.
In general, a bitcoin protocol implementation should keep an index of all known generalized block header chains, along with the valid blockchain(s). However, if a generalized block header chain is grown on top of a very old valid block, with total proof-of-work much lower than the current best valid bloackchain, it may be safely discarded. Hardfork warning system in full nodes Hardfork with unknown rules If a generalized block header chain with non-trivial total proof-of-work is emerging, and is not considered as a valid blockchain, a hardfork with unknown rules may be happening. A wallet implementation should issue a warning to its users and stop processing incoming and outgoing transactions, until further instructions are given. It should not attempt to conduct transactions on or otherwise interpreting any block data of the hardfork with unknown rules. A mining implementation should issue a warning to its operator. Until further instructions are given, it may either stop mining, or ignore the hardfork with unknown rules. It should not attempt to confirm a generalized block header with unknown rules. Setting of one or both hardfork notification bits is, as defined by BIP34 and this BIP, a hardfork, and should be considered as an indication of a planned hardfork. If a hardfork with unknown rules is happening without any hardfork notification bits set, it is probably an accidental consensus failure, such as the March 2013 fork due to a block database bug (BIP50), and the July 2015 fork following the BIP66 activation. Hardfork with multiple valid blockchains If a valid blockchain fork is emerging with non-trivial total proof-of-work, a consensus disagreement may be happening among different miners. A wallet implementation should issue a warning to its users and stop processing incoming and outgoing transactions, until further instructions are given. A mining implementation should issue a warning to its operator. Until further instructions are given, it may either stop mining, or mine on top of the best valid chain by its own standard. Hardfork warning system in light nodes Light node (usually wallet implementations) is any bitcoin protocol implementations that intentionally not fully enforcing the network rules. As an important part of the hardfork warning system, a light node should observe the hardfork notification bits in block header, along with any other rules it opts to validate. If any of the hardfork notification bits is set, it should issue a warning to its users and stop processing incoming and outgoing transactions, until further instructions are given. It should not attempt to conduct transactions on or otherwise interpreting any block data of the hardfork blockchain, even if it might be able to decode the block data. Applications Hardfork notification bits There are 2 hardfork notification bits defined in this BIP. The higher bit has been forbidden since BIP34, and the lower bit is disabled by this BIP. For nodes supporting this BIP, the semantics of the 2 bits are the same: a hardfork is happening. For legacy node, however, setting the higher bit would make them fail to follow the hardforking chain. In a soft-hardfork design (described below), the lower notification bit should be used. The hardfork warning system is able to detect the following types of hardforks: Soft-hardfork (with the lower hardfork notification bit) A soft-hardfork is a technique to implement a hardfork by pretending to create blocks with only a zero output value coinbase transaction, and commit the real transaction Merkle root in the coinbase scriptSig field. With the lower hardfork notification bit set, a node following this BIP will consider this as a hardfork and enter the safe mode, while a legacy node not following this BIP will be effectively broken due to seeing the continuously empty blockchain. Redefining the nTime field As the warning system does not interpret the nTime field, redefining it through a hardfork would be detectable. For example, overflow may be allowed to overcome the year 2106 problem. Redefining the Merkle root hash field and changing block content validation rules The 32-byte Merkle root hash could be redefined, for example, with a different hashing algorithm. Any block resources limitation and transaction validation rules may also be changed. All such hardforks would be detected by the warning system. Changing average block interval or difficulty reset Since the warning system is not bound to a particular proof-of-work target adjustment schedule, a hardfork changing the average block interval or resetting the difficulty will be detectable. Introducing secondary proof-of-work Introducing secondary proof-of-work (with non-SHA256 algorithm or fixing the block withholding attack against mining pools) may be detecta...[message truncated here by reddit bot]... original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-Decembe013332.html
BIP draft: Hardfork bit | jl2012 at xbt.hk | Jul 23 2015
jl2012 at xbt.hk on Jul 23 2015: Please feel free to comment, for technical issues and language BIP: ?? Title: Hardfork bit Author: jl2012 <jl2012 at xbt.hk> Status: Draft Type: Standard Track Created: 2015-07-23 Abstract This document specifies a proposed change to the semantics of the most significant bit of the “version” field in Bitcoin block headers, as a mechanism to indicate a hardfork is deployed. It alleviates certain risks related to a hardfork by introducing an explicit “point of no return” in the blockchain. This is a general mechanism which should be employed by any planned hardfork in the future. Motivation Hardforks in Bitcoin are usually considered as difficult and risky, because: 1) Hardforks require not only support of miners, but also, most importantly, supermajority support of the Bitcoin economy. As a result, softfork deployment mechanisms described in BIP 34 or BIP XX “Version bits” (https://gist.github.com/sipa/bf69659f43e763540550) are not enough for introducing hardforks safely. 2) Full nodes and SPV nodes following original consensus rules may not be aware of the deployment of a hardfork. They may stick to an economic-minority fork and unknowingly accept devalued legacy tokens. 3) In the case which the original consensus rules are also valid under the new consensus rules, users following the new chain may unexpectedly reorg back to the original chain if it grows faster than the new one. People may find their confirmed transactions becoming unconfirmed and lose money. The first issue involves soliciting support for a hardfork proposal, which is more a political topic than a technical one. This proposal aims at alleviating the risks related to the second and third issues. It should be employed by any planned hardfork in the future. Definitions See BIP YY “Motivation and deployment of consensus rules changes” https://github.com/jtimon/bips/blob/bip-forks/bip-forks.org Specification Hardfork bit: The most significant bit in nVersion is defined as the hardfork bit. Currently, blocks with this header bit setting to 1 are invalid, since BIP34 interprets nVersion as a signed number and requires it to be >=2 (with BIP66, >=3). Among the 640 bits in the block header, this is the only one which is fixed and serves no purpose, and therefore the best way to indicate the deployment of a hardfork. Flag block: Any planned hardfork must have one and only one flag block which is the “point of no return”. To ensure monotonicity, flag block should be determined by block height, or as the first block with GetMedianTimePast() greater than a threshold. Other mechanisms could be difficult for SPV nodes to follow. The height/time threshold could be a predetermined value or relative to other events (e.g. 1000 blocks / 10 days after 75% of miner support). The exact mechanism is out of the scope of this BIP. No matter what mechanism is used, the threshold is consensus critical. It must be publicly verifiable with only blockchain data and the programme source code, and preferably SPV-friendly. Flag block is constructed in a way that nodes with the original consensus rules must reject. On the other hand, nodes with the new consensus rules must reject a block if it is not a flag block while it is supposed to be. To achieve these goals, the flag block must 1) have the hardfork bit setting to 1, 2) include a short predetermined unique description of the hardfork anywhere in its coinbase, and 3) follow any other rules required by the hardfork. If these conditions are not fully satisfied, upgraded nodes shall reject the block. The hardfork bit must be turned off in the decedents of the flag block, until the deployment of the next hardfork. The requirement of coinbase message is also limited to the flag block. In the rare case that multiple hardforks share the same flag block, the coinbase shall include all relevant messages and the ordeposition of the messages shall not be consensus critical. Although a hardfork is officially deployed after the flag block, the exact behavioural change is out of the scope of this BIP. For example, a hardfork may not be fully active until certain time after the flag block. Automatic warning system: When a flag block is found on the network, full nodes and SPV nodes should look into its coinbase. They should alert their users and/or stop accepting incoming transactions if it is an unknown hardfork. It should be noted that the warning system could become a DoS vector if the attacker is willing to give up the block reward. Therefore, the warning may be issued only if a few blocks are built on top of the flag block in a reasonable time frame. This will in turn increase the risk in case of a real planned hardfork so it is up to the wallet programmers to decide the optimal strategy. Human warning system (e.g. the emergency alert system in Bitcoin Core) could fill the gap. Compatibility As a mechanism to indicate hardfork deployment, this BIP breaks backward compatibility intentionally. However, without further changes in the block header format, full nodes and SPV nodes could still verify the PoW of a flag block and its descendants. This proposal is also compatible with the BIP XX “Version bits”. The version bits mechanism could be employed to measure miner support towards a hardfork proposal, and to determine the height or time threshold of the flag block. Also, miners of the flag block may still cast votes for other concurrent softfork or hardfork proposals as normal. After the flag block is generated, a miner may support either fork but not both. It is not possible for miners in one fork to attack or overtake the other fork because the forks are mutually exclusive. original: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009576.html
Spoonnet: another experimental hardfork | Johnson Lau | Feb 06 2017
Johnson Lau on Feb 06 2017: Finally got some time over the Chinese New Year holiday to code and write this up. This is not the same as my previous forcenet ( https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013472.html ). It is much simpler. Trying to activate it on testnet will get you banned. Trying to activate it on mainnet before consensus is reached will make you lose money. This proposal includes the following features:
A fixed starting time. Not dependent on miner signalling. However, it requires at least 51% of miners to actually build the new block format in order to get activated.
It has no mechanism to prevent a split. If 49% of miners insist on the original chain, they could keep going. Split prevention is a social problem, not a technical one.
It is compatible with existing Stratum mining protocol. Only pool software upgrade is needed
A new extended and flexible header is located at the witness field of the coinbase transaction
It is backward compatible with existing light wallets
Dedicated space for miners to put anything they want, which bitcoin users could completely ignore. Merge-mining friendly.
Small header space for miners to include non-consensus enforced bitcoin related data, useful for fee estimation etc.
A new transaction weight formula to encourage responsible use of UTXO
A linear growth of actual block size until certain limit
Sighash O(n2) protection for legacy (non-segwit) outputs
Optional anti-transaction replay
A new optional coinbase tx format that allows additional inputs, including spending of immature previous coinbase outputs
Specification [Rationales]: Activation:
A "hardfork signalling block" is a block with the sign bit of header nVersion is set [Clearly invalid for old nodes; easy opt-out for light wallets]
If the median-time-past of the past 11 blocks is smaller than the HardForkTime (exact time to be determined), a hardfork signalling block is invalid.
Child of a hardfork signalling block MUST also be a hardfork signalling block
Initial hardfork signalling is optional, even if the HardForkTime has past [requires at least 51% of miners to actually build the new block format]
HardForkTime is determined by a broad consensus of the Bitcoin community. This is the only way to prevent a split.
Main header refers to the original 80 bytes bitcoin block header
A hardfork signalling block MUST have a additional extended header
The extended header is placed at the witness field of the coinbase transaction [There are 2 major advantages: 1. coinbase witness is otherwise useless; 2. Significantly simply the implementation with its stack structure]
There must be exactly 3 witness items (Header1; Header2 ; Header3)
**Header1 must be exactly 32 bytes of the original transaction hash Merkle root. **Header2 is the secondary header. It must be 36-80 bytes. The first 4 bytes must be little-endian encoded number of transactions (minimum 1). The next 32 bytes must be the witness Merkle root (to be defined later). The rest, if any, has no consensus meaning. However, miners MUST NOT use this space of non-bitcoin purpose [the additional space allows non-censensus enforced data to be included, easily accessible to light wallets] **Header3 is the miner dedicated space. It must not be larger than 252 bytes. Anything put here has no consensus meaning [space for merge mining; non-full nodes could completely ignore data in this space; 252 is the maximum size allowed for signal byte CompactSize]
The main header commitment is H(Header1|H(H(Header2)|H(Header3))) H() = dSHA256() [The hardfork is transparent to light wallets, except one more 32-byte hash is needed to connect a transaction to the root]
To place the ext header, segwit becomes mandatory after hardfork
A “backdoor” softfork the relax the size limit of Header 2 and Header 3:
A special BIP9 softfork is defined with bit-15. If this softfork is activated, full nodes will not enforce the size limit for Header 2 and Header 3. [To allow header expansion without a hardfork. Avoid miner abuse while providing flexibility. Expansion might be needed for new commitments like fraud proof commitments]
Hardfork network version bit is 0x02000000. A tx is invalid if the highest nVersion byte is not zero, and the network version bit is not set.
Masked tx version is nVersion with the highest byte masked. If masked version is 3 or above, sighash for OP_CHECKSIG alike is calculated using BIP143, except 0x02000000 is added to the nHashType (the nHashType in signature is still a 1-byte value) [ensure a clean split of signatures; optionally fix the O(n2) problem]
Pre-hardfork policy change: nVersion is determined by the masked tx version for policy purpose. Setting of Pre-hardfork network version bit 0x01000000 is allowed.
Only txs with masked version below 3 are counted. [because they are fixed by the BIP-143 like signature]
Each SigHashSize is defined as 1 tx weight (defined later).
SIGHASH_SCALE_FACTOR is 90 (see the BIP above)
New tx weight definition:
Weight of a transaction is the maximum of the 4 following metrics:
** The total serialised size * 2 * SIGHASH_SCALE_FACTOR (size defined by the witness tx format in BIP144) ** The adjusted size = (Transaction weight by BIP141 - (number of inputs - number of non-OP_RETURN outputs) * 41) * SIGHASH_SCALE_FACTOR ** nSigOps * 50 * SIGHASH_SCALE_FACTOR. All SigOps are equal (no witness scaling). For non-segwit txs, the sigops in output scriptPubKey are not counted, while the sigops in input scriptPubKey are counted. ** SigHashSize defined in the last section Translating to new metric, the current BIP141 limit is 360,000,000. This is equivalent to 360MB of sighashing, 2MB of serialised size, 4MB of adjusted size, or 80000 nSigOp. See rationales in this post: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013472.html Block weight growing by time:
Numbers for example only. Exact number to be determined.
Block weight at HardForkTime is (5,000,000 * SIGHASH_SCALE_FACTOR)
By every 16 seconds growth of the median-time-past, the weight is increased by (1 * SIGHASH_SCALE_FACTOR)
The growth stops at (16,000,000 * SIGHASH_SCALE_FACTOR)
The growth does not dependent on the actual hardfork time. It’s only based on median-time-past [using median-time-past so miners have no incentive to use a fake timestamp]
The limit for serialized size is 2.5 to 8MB in about 8 years. [again, numbers for example only]
New coinbase transaction format:
Existing coinbase format is allowed, except the new extended header in the coinbase witness. No OP_RETURN witness commitment is needed.
A new coinbase format is defined. The tx may have 1 or more inputs. The outpoint of the first input MUST have an n value of 0xffffffff, and use the previous block hash as the outpoint hash [This allows paying to the child of a particular block by signing the block hash]
ScriptSig of the first (coinbase) input is not executed. The size limit increased from 100 to 252 (same for old coinbase format)
Additional inputs MUST provide a valid scriptSig and/or witness for spending
Additional inputs may come from premature previous coinbase outputs [this allows previous blocks paying subsequent blocks to encourage confirmations]
Witness merkle root:
If the coinbase is in old format, the witness merkle root is same as BIP141 by setting the witness hash of the coinbase tx as 0 (without the 32 byte witness reserved value)
If the coinbase is in new format, the witness hash of the coinbase tx is calculated by first removing the extended header
The witness merkle root is put in the extended header 2, not as an OP_RETURN output in coinbase tx.
The witness merkle root becomes mandatory. (It was optional in BIP141)
Other consensus changes:
BIP9 will ignore the sign bit. [Setting the sign bit now is invalid so this has no real consensus impact]
An experimental implementation of the above spec could be found at https://github.com/jl2012/bitcoin/tree/spoonnet1 Not the same as my previous effort on the “forcenet”, the “spoonnet” is a full hardfork that will get you banned on the existing network. Haven’t got the time to test the codes yet, not independently reviewed. But it passes all existing tests in Bitcoin Core. No one should use this in production, but I think it works fine on testnet like a normal bitcoind (as long as it is not activated) Things not implemented yet:
Post-hardfork support for old light wallets
Wallet support, especially anti-tx-replay
New p2p message to transmit secondary header (lower priority)
Full mining and mempool support (not my priority)
Potential second stage change: Relative to the actual activation time, there could be a second stage with more drastic changes to fix one or both of the following problems:
SHA256 shortcut like ASICBoost. All fixes to ASICBoost are not very elegant. But the question is, is it acceptable to have bitcoin-specific patent in the consensus protocol? Still, I believe the best way to solve this problem is the patent holder(s) to kindly som...[message truncated here by reddit bot]...
Bitmain - Regarding Recent Allegations and Smear Campaigns
This is an automatic summary, original reduced by 87%.
Bitmain has shown the ability to adapt and thrive in the constantly changing and extremely challenging Bitcoin mining environment. Bitmain has continuously been advocating for increasing the Bitcoin block size. If all mining equipment could use ASICBOOST, it will lower the J/GH cost and the total network hash rate will increase, making the Bitcoin network even stronger. The ASICBOOST method is not a "Covert attack" on the Bitcoin PoW function. The best method to leverage ASICBOOST is by using the Bitcoin block header's version bits. Maxwell has previously attacked one of most important Bitcoin maintainers Gavin Andresen, one of the earliest public Bitcoin advocates and investors Roger Ver, founder and CEO of one of the largest Bitcoin exchanges Brian Armstrong, the first author of Lightning Network Joseph Poon, and now Bitmain's co-CEO Jihan Wu. He has even called his fellow Core contributors who signed the Hong Kong agreement "Dipshits".
ELI5: Gregory Maxwell’s Inhibition Proposal – Jimmy Song – Medium
This is an automatic summary, original reduced by 77%.
The coinbase transaction is the transaction with the reward for miners when they find a block with sufficient proof-of-work. The witness commitment is specified in BIP-141 and contains the Merkle Root of the witness transaction id's. If you look at the Bitcoin block header specification, the first 64 bytes are the version, previous block hash and 28 of the 32 bytes of the Merkle Root, which is sort of a fingerprint of all the transactions in the block. This includes all transactions, not just Segwit transactions, but assumes the coinbase transaction has a hash of all 0's. This means that calculating the Merkle Root is less efficient since the Coinbase transaction has to change anytime any transaction is changed even slightly, including changing position. This matters because normally, changing one side of the Merkle Tree doesn't affect the other, but in this case, changing the right side of the Merkle Tree changes a large chunk of the left side which contains the coinbase transaction. What if Segwit doesn't activate? Would this proposal change anything?In case Segwit doesn't activate, the proposal would still require the witness commitment of the transactions.
How to retrieve latest block header data in the bitcoin network?
Hi, I'm trying to find out how to get information in a C program by connecting to the bitcoin network? I don't really know much about HTTP and internet retrieving, I need information such as merkleroot, target, version etc. of a blockheader so I can find the nonce value (solution) to them. Can someone point m in the right direction?
Bitcoin mining: how is a block header of 80 bytes processed in SHA-256? Isn't it too big?
The whole process of bitcoin mining was making sense to me until a moment of madness an hour ago, if there is 80 bytes of data to be processed in SHA-256, that's 640 bits of data to be processed in SHA-256. In this 80 bytes we have: 4 bytes (version), previous block hash (32 bytes), merkle root (32 bytes), time (4 bytes), bits (4 bytes), nonce (4 bytes). I thought SHA-256 accepted 512 bits of data, so that's 64 bytes of data. And on top of that, I need to add the length of the data to be processed in the last 64 bits of this 512 bits input but 64 bytes is well over the limit. What am I missing here? Can someone help hear it up for me? Thanks
Any Bitcoin miner who successfully hashes a block header to a value below the target threshold can add the entire block to the block chain (assuming the block is otherwise valid). These blocks are commonly addressed by their block height —the number of blocks between them and the first Bitcoin block (block 0, most commonly known as the genesis block). For example, block 2016 is where ... The header is actually an 80-byte long string, comprised of the 4-byte long Bitcoin version number, 32-byte previous block hash, 32-byte long Merkle root, 4-byte long timestamp of the block, 4-byte long, difficult target, and 4-byte long nonce used by miners. Block Headers¶. Block headers are serialized in the 80-byte format described below and then hashed as part of Bitcoin’s proof-of-work algorithm, making the serialized header format part of the consensus rules. learn me a bitcoin. By Greg Walker. Home; Beginners; Technical; Explorer; $13,010.81/BTC Buy. Subscribe. Tools. Hash256. Hash160. Reverse Bytes. Hexadecimal. Satoshis. Block Header. A summary of the data in the block. A block header is like the metadata at the top of a block of transactions. The fields in the block header provide a unique summary of the entire block. Example . Here’s the ... Bitcoin uses: SHA256(SHA256(Block_Header)) but you have to be careful about byte-order. For example, this python code will calculate the hash of the block with the smallest hash as of June 2011, Block 125552. The header is built from the six fields described above, concatenated together as little-endian values in hex notation: >>> import hashlib >>> header_hex = ("01000000 ...
perfect video for background or header of a blockchain ICO website Thank you for checking out our video, if anyone reaches out to us we have the following se... In these tutorials I teach you how become a bitcoin/altcoin developer. I will be going through the entire bitcoin developer reference and in each tutorial I will explain one or more key concepts ... Live Bitcoin Trading With Crypto Trading Robot DeriBot on Deribit DeriBot Alternative channel 932 watching Live now Crypto Mining Difficulty 101 - Everything You Need to Know - Duration: 18:40. Blockchain/Bitcoin for beginners 7: Blockchain header: Merkle roots and SPV transaction verification ... content and creation of bitcoin blocks - Duration: 46:48. Matt Thomas 11,094 views. 46:48 ... The main way of identifying a block in the blockchain is via its block header hash. The block header is part of a block. It contains at least these five attributes: Timestamp Previous block header ...