Bitcoin QT failed 3 times while I was rebuilding the blockchain database.
Once at 94% it got one bad block 'block checksum mismatch', why can't it just delete that 1 block and redownload it? Yes it did this in the past! Why do I have to reindex the whole thing, that takes 18-30 hours? This happens nearly every time I restart the client.
If there's any way to fix this please tell me, I am losing my patience with QT. I have no problems with it on my other computer running Windows 8. I am running Mac OS X 10.10 right now.
I tried building from source and got this error:
configure: error: Could not find a version of the boost_system library!
Even though the boost::system library is available.
I am trying to switch wallet. But I can't, my BTC is in multisig address, and I don't know how to get it out.
I am going to try giving it its own storage, I have a spare SSHD with nothing on it. If this fails I'm going to get a SSD.
Yes I absolutely need to get this fixed to get my bitcoins out of this multi sig address in Armory.
Could you use your other computer to get your coins out? |
|
|
|
If someone would like to review my code, I'd be glad - https://github.com/hhanh00/offlinesig - but it's not easy to get someone to do it. I didn't rewrite a crypto library. I used bouncycastle and provided a generator for k following the RFCxxxx. The only values exchanged are (r, s) and I don't see any other sidechannel since it works offline. |
|
|
|
|
Ok. I wrote my wallet app partly because I thought about this vulnerability too. One can't be too careful.
|
|
|
|
|
Thanks, I trust my offline wallet implementation of the rfc as much as I can. Under this condition, is there an attack?
I know about binding signatures from open transaction and zkp from zerocash but it seems to be accademic for the moment.
|
|
|
|
|
Not the same thing. Shared Secret => you don't pick the value, it's calculated. Multi sig, you bring your own key. The later is more flexible but requires native support.
|
|
|
|
Well not pedantically. Its most logical to consider the compressed/uncompressed flag to be part of a private key... in that logically a private key is _all_ the information required to create a pubkey and to prove you created the pubkey. Of course, if you permit twiddling arbitrary parts of a private key I can create countless pubkeys.
- snip -
Interestingly, this would seem to indicate that there are actually 2 257 private keys rather than the often quoted 2 256. Additionally, each address would seem to have, on average, both 2 96 different private keys with the "compressed bit" that can provide a valid signature AND an additional 2 96 different private keys without the "compressed bit" that can also provide a valid signature. Not exactly. Technically, there are less than 2^256 different values because of the order of the underlying finite group but it's not important. Once you have the exponent and therefore the EC point, there is an infinite way to serialize it. Early version of bitcoin core used the 'uncompressed' DER form. Once hashed and base58 encoded , it gives the address. Because different serializations lead to different addresses, the private key is marked with an additional byte to indicate the usage of compression. Now we can invent new representations at will - it's just a change of coordinates. In jacobian form, the coordinate is a triplet and introduces an additional degree of freedom. Hence ~2^256 more combinations. But at the end though it's the same points. If bitcoin core accepted this form, the private key would have to add 32 bytes and surely, we surely wouldn't have created 2^512 keys. |
|
|
|
Better to just sign twice and compare the results: they should be identical.
I found a company that was having unauthorized transactions from their corporate bitcoin address in small amounts over a long period. I asked to review their code, and the guy they hired to code the system had basically used H( tx ) where H is 281 rounds of sha256 as a "deterministic" k and had secretly stolen the private key by looking at the blockchain. (as the tx was public knowledge and the only secret was the iteration count... which he knew.) Using your check twice method, signing the same tx twice would give the same k... but still be unsafe. The point is to check from two different devices that are supposed to implement the deterministic signature RFC. Blind signatures are good too unless both online & offline devices were compromised. |
|
|
|
|
Will they implement deterministic ecdsa after this incident?
|
|
|
|
|
When you sign a document when a pen, you always use the same signature. A forger can duplicate it if he's good. On the contrary, a digital signature varies with the document signed. It still can be verified but it won't work on another document. Since in Bitcoin, you use digital signatures to sign the transactions, you won't be signing the same document twice.
Moreover, you can sign offline because once the document is prepared, the signature is a mathematical operation that doesn't require an internet connection.
|
|
|
|
I would like to make a script that checks certain addresses against an MPK to verify you own the addresses. If this were possible I was thinking there are 2 ways it could work. 1, generate addresses until one of them equals the address you are checking or 2, just be able to check if the address belongs to the MPK. Is the 2nd one even possible? Because that is the more desirable option.
In all likelihood, every address belongs to you after a sufficiently large number of iterations. It's because the mpk produces an address by adding to your first secret key a deterministic offset which is a hash. The later should eventually cover every possible value. It's not a proof - there could be a cycle, but it would make the hash function distinguishable from random IMO. You don't need a script cause you own them all  |
|
|
|
I agree that it would be a good idea to define a language agnostic spec for the communications protocol, and I haven't heard a single valid argument against it.
The communications are already speced out in reasonable enough detail that multiple people have implemented talking to it from just the documentation. (e.g. from he developer guide and Bitcoin Wiki/ I can attest that it's possible to write a client without looking at the reference code. @erik777 - what do you think a standardization process would add? Bear in mind that HTML 5 doesn't have an official spec and is still used by most of the internet. |
|
|
|
|
Probably messed up.
1d7749c65c90c32f5e2c036217a2574f3f4403da39174626b246eefa620b58d9
|
|
|
|
|
If the signing device is offline and the implementation of the deterministic signature trusted to follow the prescribed algorithm, what sidechannels attack do you see?
In other words, the online device transfers the digest and pubkey to the signer. The signer returns (r, s) where k follow RFC 6979. The online device builds the transaction and the user checks that the inputs/outputs are what he expects.
Can something still go wrong?
|
|
|
|
The main issue I have with all these 'proof' of difficulty is that they assume it's perfectly random. In fact, they ignore the type of encryption used and focus exclusively on the length. 256 bits then 2^256 possibilities. Way higher than the age of universe to hack - agreed. But then why is a PGP 256 bit key (RSA to be pedantic) completely unsafe but the Bitcoin 256 bit key safe? Reference Cryptographic key length recommendations: http://www.keylength.comYou answered your own question partially. It's all about the type of encryption and how many bits of security it really provides, not the key length. And this in turn is based on the kinds of algorithms that can find a solution most efficiently. Elliptic curve cryptography is excellent because it it only requires 2 characters for each bit of security. from http://en.wikipedia.org/wiki/Elliptic_curve_cryptography: Since all the fastest known algorithms that allow one to solve the ECDLP (baby-step giant-step, Pollard's rho, etc.), need O(\sqrt{n}) steps, it follows that the size of the underlying field should be roughly twice the security parameter. For example, for 128-bit security one needs a curve over \mathbb{F}_q, where q \approx 2^{256}. This can be contrasted with finite-field cryptography (e.g., DSA) which requires[17] 3072-bit public keys and 256-bit private keys, and integer factorization cryptography (e.g., RSA) which requires a 3072-bit value of n, where the private key should be just as large. However the public key may be smaller to accommodate efficient encryption, especially when processing power is limited. So you get 128 bits of security with Bitcoin. This is further increased to 160 bits for an unspent address because of RIPEMD-160 hash. Hehe - I know, I have to admit I was trolling.  Now that you confirmed that. What about the following picture which has fancy words like 'thermodynamics', 'dyson sphere', and my personal favorite - "the laws of the universe" - mmm?  Though it's a nice photoshop and I'm sure it won't be the last time it shows up. |
|
|
|
The main issue I have with all these 'proof' of difficulty is that they assume it's perfectly random. In fact, they ignore the type of encryption used and focus exclusively on the length. 256 bits then 2^256 possibilities. Way higher than the age of universe to hack - agreed. But then why is a PGP 256 bit key (RSA to be pedantic) completely unsafe but the Bitcoin 256 bit key safe? Reference Cryptographic key length recommendations: http://www.keylength.com |
|
|
|
|
The bottleneck in my app is the creation of the UTXO db. Even with a ram disk and leveldb, building it takes about 1h for the current blockchain. In comparison, script verification is only ~15 mn because it is CPU bound and easily parallelizable. Leveldb spends a large portion of time deleting and recompacting its sorted tables because tx hashes are basically random.
I haven't found a way to improve that part. It's not so bad since it's only done once but still.
|
|
|
|
|
Today mining is easier since it is possible whereas a brute force hack is not.
But mining adjusts its difficulty. It has 256 bits to work with and hacking has 160 bits.
In theory, mining can become harder than hacking. Though
In practice both are unfeasible by brute force.
However brute force is the dumbest way to hack. Bullies don't make good hackers.
|
|
|
|
|
In general proof of XXX shows that you are willing to spend some resource, i.e. that what you provide was not free to produce.
Proof of work: resource = work = energy
Proof of stake: resource = coin * days = you keep your coins but the number of days is reset.
Proof of burn: resource = coins. You are spending your coins.
The last case is most used in the first distribution of an altcoin. You burn your bitcoin and in exchange you receive altcoins.
|
|
|
|
|
A cryptographic hash like SHA-256 produces hashes that are indistinguishable from a uniform distribution. This is why there is no bias in the 'lottery'. It can act as a pseudo random number generator (even though there are subtleties related to sizes and it is not recommended to do so).
|
|
|
|
lol. If you know the private key, you don't need the signature to calculate the public key.
Obviously without knowing the private key. The public key is not completely unambiguous from the signature. (nor is R, technically)
Yes but it can be lifted if we know the address. |
|
|
|
|
Show Posts
