|
SHA-256 handles messages larger than 512 bits by breaking the message into blocks that are 512 bits long. The first block input is fed into the hashing function and that output (h0) is combined with the second input block and that output (h1) is combined with the third input, etc, etc, until all inputs have been hashed. This is how a message of arbitrary size (even say a 4GB ISO) can be reduced to a single 256 bit value.
The "zeroes" are simply spacing bits. They could be anything as long as the format of the final block (partial hash not bitcoin blocks) remains the same length and ends with a 32 bit nonce.
The current bitcoin block header is 640 bits long
This means the first 512 bits is hashed and the output of the function is stored h0
The next 128 bits is then hashed with the output of h0 to produce h1. This is then hashed again because Bitcoin uses SHA256d.
Now ASICS are "dumb" they really have no idea what they are hashing. Since h0 remains relatively static (the nonce is in the second block), the mining software (local miner) will compute the h0 partial hash and feed that plus the 96 bits in the second block to the ASIC. The ASIC appends the 32 bit counter (nonce) and computes the hash incrementing internally as needed and returning results.
So to remain compatible with existing ASICS requires two things:
a) a 256 bit h(x) partial hash value
b) the last block (partial hash input) must consist of exactly 96 bits + a 32 bit nonce.
Anything different would result in a format that existing ASICS don't understand.
The comment about "must be zero do not use" just means it is padding and must be consistent in the protocol it could be anything all zeroes, all ones, ASCII code for "Satoshi Rules 123...." as long as it is 48 bytes long. There is no actual requirement that the protocol/standard must only use zeroes. If a different format was used the padding would be smaller or longer to to ensure that 96 bits + a 32 bit nonce are the only elements in the final partial hash. This way no matter how large you want the header to be it will still hash down to a h(x) partial hash plus 96 bits + a 32 bit nonce and be compatible with existing hardware.
Personally I have considered a change like this but I would propose a modified structure. I would use a 64 bit nonce in the last segment (replacing the nonce, nonce2, and nonce3). This would support for miners as powerful as 18,446 PH/s without overflowing the nonce. The larger nonce field could be supported by existing hardware in a backwards compatible mode in a similar manner to how 32 bit values are stored in 64 bit CPU registers. The upper 32 bits would simply be zeroed. The existing miners (who only understand the concept of a 32 bit nonce) would simply hash a value which ends with 00000000 plus a 32 bit nonce. The local miner (cgminer) could increment the upper 32 bits to provide support for higher hashrate hardware. In time ASIC developers would release "enhanced" hardware which uses a larger nonce space internally to handle higher throughput.
|
|
|
|
1. Do transactions ever time out if not accepted into the block chain?
e.g. if I create a transaction today, and it happens to be invalid, is it possible it will unexpectedly get accepted, e.g. with a later release of the bitcoin block chain code that has policy changes, maybe in x years time? (assuming transaction this would have to be accepted by miner *and* the block chain code)
Or for another example, maybe one less far fetched, consider a non-standard transaction, that isn't included in the block chain any time soon. Is it possible that a miner could unexpectedly process this transaction at any undetermined point in time in the future of bitcoin? Or will the transaction eventually expire? They do not expire once broadcast. It is possible that the tx will be added to a block by a miner at any point in the future. The tx can be made invalid by double spending the same inputs in a new tx. Once the double spend is included in a block the first tx never will as that tx is now invalid in any block in the same blockchain as the original. |
|
|
|
|
2112 got it. W=V * A only applies to DC circuits for AC circuits you need to account for Power Factor W * PF * V * A. Your meter may have an option/setting to show the PF as the Wattage display is accounting for it. The good news is that unless you are a major industrial customer you only pay for watts not VoltAmps so a low PF doesn't directly affect your bill.
|
|
|
|
thanks for the book reference  yes, Boltzmann constant multiplied by circuit temperature, which is why the graphic says "cooled to absolute zero". Perhaps the image should be a frozen sun, nes pa? Well the power source wouldn't be near absolute zero, the computer would be. The higher the temp the higher the min energy requirement. The background temp of space is pretty close to 0 K, at room temp it would need a lot more energy. |
|
|
|
P.S. why would quantum computers be "boring" ?
They are boring for hashing algorithms as Shor's algorithm is not applicable against cryptographic hashes. But... Shor's algo can be applied to ECDSA right? Yes Which uses a hash function within it... No although you are signing a digest (hash of the message). Attacking a private ECDSA key using quantum computing would require a general purpose QC capable of implementing Shor's algorithm on 512 bit keys (tens of thousands of qubits) AND the PubKey must be known. |
|
|
|
P.S. why would quantum computers be "boring" ?
They are boring for hashing algorithms as Shor's algorithm is not applicable against cryptographic hashes. |
|
|
|
Nonetheless, the discussion of how quantum computers relate to breaking sha 256 is pretty interesting. Quantum computers will be very boring when it comes to SHA and all other hashing algorithms. The image above with the solar system sized "perfect-computer" is cute, but it lacks detail. What's the valuation of "least engery possible to record a change of state"?
The second law of thermodynamics and Boltzman constant. If it isn't clear the required energy only applies to "classical computing" and a brute force attack. It is possible that someday ECDSA will be weakened such that it doesn't provide 256 bits of security, or quantum computing would allow breaking keys with a significant reduction in required energy, or that reversible computing allows for computers which use less or potentially no energy. Of course we have no idea if those methods will ever become practical in our lifetime or even in the next milenium. We do know that keys can be brute forced using classical computing however the number of possible values in a key with 256 bit security and the limits of the laws of thermodynamics mean that while it is "possible" it has energy requirements which make it infeasible. Here is a quote from Applied Cryptography (a dated but very good book for those interesting in understanding cryptography) One of the consequences of the second law of thermodynamics is that a certain amount of energy is necessary to represent information. To record a single bit by changing the state of a system requires an amount of energy no less than kT, where T is the absolute temperature of the system and k is the Boltzman constant. (Stick with me; the physics lesson is almost over.)
Given that k = 1.38×10-16 erg/°Kelvin, and that the ambient temperature of the universe is 3.2°Kelvin, an ideal computer running at 3.2°K would consume 4.4×10-16 ergs every time it set or cleared a bit. To run a computer any colder than the cosmic background radiation would require extra energy to run a heat pump.
Now, the annual energy output of our sun is about 1.21×1041 ergs. This is enough to power about 2.7×10^56 single bit changes on our ideal computer; enough state changes to put a 187-bit counter through all its values. If we built a Dyson sphere around the sun and captured all its energy for 32 years, without any loss, we could power a computer to count up to 2^192. Of course, it wouldn't have the energy left over to perform any useful calculations with this counter.
But that's just one star, and a measly one at that. A typical supernova releases something like 10^51 ergs. (About a hundred times as much energy would be released in the form of neutrinos, but let them go for now.) If all of this energy could be channeled into a single orgy of computation, a 219-bit counter could be cycled through all of its states.
These numbers have nothing to do with the technology of the devices; they are the maximums that thermodynamics will allow. And they strongly imply that brute-force attacks against 256-bit keys will be infeasible until computers are built from something other than matter and occupy something other than space. |
|
|
|
|
It is easier to use a client like armory but the steps can all be done by RPC calls
listunspent - (online) return a list of outputs which can be used to create a new tx
createrawtransaction - (online) create an unsigned tx
signrawtransaction - (offline) sign the unsigned tx (copied from online wallet)
sendrawtransaction - (online)broadcast the signed tx (copied from offline wallet)
|
|
|
|
|
That is not the standard procedure no. After step 4 the wallet will believe the tx has been broadcast and will not immediately attempt to rebroadcast it.
The normal procedure is to use an online wallet to construct a raw transaction. Copy raw transaction to offline wallet. Have offline wallet sign the raw transaction. Copy signed raw transaction to online wallet. Have online wallet broadcast the signed transaction.
|
|
|
|
|
Block explorer is just a website it is not part of the bitcoin protocol. All nodes verify all transactions. If the tx are encrypted then nodes couldn't verify they are valid. There are methods to improve privacy but they involve more complex cryptographic systems than simply encrypting transactions. Ring signatures and zero knowledge proofs are two potential systems to improve privacy.
|
|
|
|
|
Thanks and that opens up even more questions. Not sure why a key would be removed from the keypool and returned. Will need to dig into the code.
|
|
|
|
|
Yes. In the bitcoin-core client (QT) you need to enable coin control first and then you can select which outputs on which address you want to spend by clicking on [Inputs].
|
|
|
|
I will follow all tax regulations so am I correct in assuming there is legally nothing they can really do to stop me making these large cash outs? They won't be able to seize any products I buy etc.? If your government can and does seize private property when you follow the law well you got bigger problems. $40K is enough for tax authorities to get interested. Make sure you understand your tax liability (if any) and report/pay your taxes and you should have no problems. Also be smart and careful if you are meeting anonymous people using localbitcoins. |
|
|
|
|
There are about 6 million addresses which have at least one unspent output. Understand bitcoin doesn't work on "balances" that is just an abstraction to make it easier to use. The network current has ~11M unique unspent outputs and collectively they reference 6M PubKeyHashes* which are decoded addresses.
* There are also a small but growing number of native multisig, P2SH, and non-standard outputs.
|
|
|
|
What does "keypool reserve" & "keypool return" in the debug log indicate? 2014-05-26 16:34:01 keypool reserve 9028
2014-05-26 16:34:01 keypool return 9028
2014-05-26 16:34:01 keypool reserve 9028
2014-05-26 16:34:01 keypool return 9028
|
|
|
|
|
The tx is high priority but without any fee. Miners generally devote a small portion of the next block to the highest priority tx even with no fee so it will eventually be included in a block. Depending on how many other free tx are waiting it might be the next block or sometime in the next hundred blocks. In the future if you want prompt confirmation it would be recommended to include a small tx fee with the tx. Paying 0.1 mBTC per KB will almost always get you in the next block unless there is some other issue with the tx.
|
|
|
|
The code as released doesn't solve the nothing at stake problem. It also can be hard forked by creating an alternate chain longer than 720 blocks. NXT promises there is some magical code (EC and TF) which will resolve these problems but the world isn't ready for it yet. |
|
|
|
At the end of the day, distributing crypto-equity through fixed algorithms is fundamentally flawed because it does not consider market forces.
That is nonsense. If the exchange rate rises the market value of the money supply also rises. If miners receive 1% of the money supply annually it doesn't matter if a BTC is worth $1 or $100,000. The network isn't distributing "equity" it is providing compensation for securing the network. The subsidy is merely a bootstrapping mechanism. In the future users will pay for security and if they pay 1% to PoW miners or 1% PoS stakeholders they are still paying for security. You didn't refute my point at all.... If miners receive 1% (which is an underestimate, it is more along the lines of 9% at its current rate) when the price of bitcoin goes up then there compensation goes up regardless of added efficiency or security of the network. So if you have a spike from $1 to $100,000 the cost of securing the network went from 10 cents to $1,000. Except we are not longer in that price range which is why the cost of mining is now more than $500 million. The same is true with PoS. Yes you have proven that 1% of a large number is larger than 1% of a small number. |
|
|
|
The important thing is the efficiency is getting better and better, and we are getting more security for the dollar...and bitcoin is in good shape.
Agreed. It just important to understand efficiency can't reduce cost only improve security (by eliminating the potential for an attacker to reduce cost by using more efficient tech). What you called a pointless distinction earlier is not pointless, because of the ratios of hardware to electricity. I think I almost had a good point. It doesn't matter if it is paid for in hardware or electricity. Also improvements in efficiency come from Moore's law. The cost per transistor also falls at the same rate (actually power has been lagging behind transistor cost over the last couple generations). |
|
|
|
|
AES isn't used by Bitcoin. Hashing functions are effectively immune to the potential of quantum computing. Shor's algorithm can not be used against hashing functions or symetric cryptography.
To say quantum computing is "advancing rapidly" is an overstatement. In 2001 the largest number to be factored by a general purpose quantum computer using Shor's algorithm was 15. By 2011 the largest number to be factored was 143. That is from 4 bits to 8 bits in the span of a decade. We are a long way from factoring even 256 bit numbers and 256 bit ECDSA keys are even harder (~3,072 RSA key = integer factorization).
Nobody said 256 bit encryption will be secure forever. It is infeasible to brute force a 256 bit key using classical computing. Quantum computing may someday break it but it may not, quantum decoherence is a bitch. It is possible ECDSA has some flaw and cryptanalysis will someday weakened it to a point it is economical to attack it. That could be next year or not in the next century.
|
|
|
|
|
Show Posts
