 Show Posts
|
|
Pages: « 1 2 3 4 [5]
|
|
I'm working on an alternate bitcoin client and I'd like to try it on the test network. Is there a list of bootstrap hosts for the test network somewhere, so I don't need to implement an IRC client at this point?
|
|
|
|
in 120DPI mode.
What is "120DPI mode"? Is that an actual setting somewhere? Sounds like an obscure enough candidate. I suppose it needs twice the resolution icon to fill the size of the upper left corner icon. Only one size is provided. In XP, display properties -> settings -> advanced. It basically makes all display elements a bit larger. |
|
|
|
|
Also happens here - Windows XP, 32-bit color depth, 1680x1050 LCD screen in 120DPI mode. Perhaps the use of an unusual DPI is breaking it?
|
|
|
|
It's ALIVE!  Source on git now has: + different genesis block + ridiculously easy minimum proof of work threshold + protocol message header bytes are { 0xfa, 0xbf, 0xb5, 0xda } instead of { 0xf9, 0xbe, 0xb4, 0xd9 } If you compile and connect and turn on coin generation you'll generate a lot of play money quickly... (I've turned off generation, but will keep my three clients -- two Linux, one Mac -- connected) 870 blocks already? How long will that take to bootstrap once it gets going?  |
|
|
|
Very good point about the genesis block.
Unfortunately, I'm not exactly sure HOW to generate a valid genesis block; I can tweak the data but need to generate a valid block hash... hmm, I see some time in gdb in my near future...
It should be sufficient to just change things to invert the hash in the prevBlock pointer or something... Then the genesis block doesn't need to change. |
|
|
|
Could this be fixed in the next release? We were just discussing what would happen if a flaw were found: Here we go, our first real test of the situation. Nope! At least, not easily - block and transaction identities are based on this hash, among other things, so this would break the chain. You'd need to do a phased rollout - first, add parsing support to all clients, then obsolete older clients, then roll out a new version which generates a new version of the block serialization format using the new hashing method. |
|
|
|
|
Changing the genesis block would be a VERY good idea - better yet, change the protocol version as well. This will help avoid the possibility of the two networks merging (peers do exchange address lists...)
|
|
|
|
As you can see, this tries to be more secure by hashing twice. However, this actually reduces security. To break pure SHA256, an attacker needs to find a d' such that SHA256(d') == SHA256(d), for a known d. This is also sufficient to break Hash(). However the attacker can also attack the outer layer of the hash, finding a d' such that SHA256(SHA256(d')) == SHA256(SHA256(d)), even though SHA256(d') != SHA256(d). As you can see, the double hashing here makes it _easier_ to break the hash!
If I understand correctly, you've got two chances to find a collision instead of one. So this decreases the security of SHA256 by a factor of 2... which is just Not a Big Deal. Bitcoin is using, essentially SHA255 instead of SHA256. It'll still take longer than forever to find a collision... It's true that it's not a big deal, but what concerns me is that someone went out of their way to implement an unproven hashing method, without thinking it through to realize that it actually decreases security. Things like this reduce one's confidence in the system as a whole - after all, if such a mistake exists, what other problems may be lurking? What we really need is a documented protocol, so it can be audited by third parties. I'm working on reverse-engineering it from the source, but it's slow going - the intent of much of the scripting system is poorly documented. |
|
|
|
|
Incidentally, a similar problem exists with Hash160, only worse - an attacker can break _either_ RIPEMD160 or SHA256, and win. At least with Hash() the attacker _must_ break SHA256.
|
|
|
|
Hi, The Hash() function in util.h forms the backbone of most of bitcoin's crypto: template<typename T1>
inline uint256 Hash(const T1 pbegin, const T1 pend)
{
uint256 hash1;
SHA256((unsigned char*)&pbegin[0], (pend - pbegin) * sizeof(pbegin[0]), (unsigned char*)&hash1);
uint256 hash2;
SHA256((unsigned char*)&hash1, sizeof(hash1), (unsigned char*)&hash2);
return hash2;
}
As you can see, this tries to be more secure by hashing twice. However, this actually reduces security. To break pure SHA256, an attacker needs to find a d' such that SHA256(d') == SHA256(d), for a known d. This is also sufficient to break Hash(). However the attacker can also attack the outer layer of the hash, finding a d' such that SHA256(SHA256(d')) == SHA256(SHA256(d)), even though SHA256(d') != SHA256(d). As you can see, the double hashing here makes it _easier_ to break the hash! A better solution would be something like: template<typename T1>
inline vector<unsigned char> HashV(const T1 pbegin, const T1 pend)
{
uint256 sharesult;
uint160 riperesult;
SHA256((unsigned char*)&pbegin[0], (pend - pbegin) * sizeof(pbegin[0]), (unsigned char *)&sharesult);
RIPEMD160((unsigned char*)&pbegin[0], (pend - pbegin) * sizeof(pbegin[0]), (unsigned char *)&riperesult);
vector<unsigned char> ret;
ret.insert(ret.end(), (unsigned char *)(&sharesult), (unsigned char *)(&sharesult + 1));
ret.insert(ret.end(), (unsigned char *)(&riperesult), (unsigned char *)(&riperesult + 1));
return ret;
}
The key is to concatenate the hashes, not merge them. This means the attacker has to break both hashes - even in the worst case, this cannot be less secure than a single hash. Unfortunately, changing hashes would break the chain... |
|
|
|
Why not just upload the file itself to rapidshare? |
|
|
|
Has there been a concerted effort to attack, subvert, or break Bitcoin? One way to test that it is secure from attack would be to actually try to undermine it, by double-spending coins, creating fake coins, posting false transactions, etc... and if flaws are found, better that they are found now than later, when the bitcoin economy is potentially larger and there is more to lose.
I agree. We the software needs to be vetted. For one thing, I just ran across some rates to rent time on a supercomputer: http://news.softpedia.com/news/Rent-Your-Own-Supercomputer-for-2-77-per-Hour-82166.shtml$2.77 / core / hr I would think EC2 would be a better option - $0.17/hr for two cores (using a high-cpu medium instance) that way. |
|
|
|
|
After performing about 2400 transfers of BC0.01 each, my wallet.dat grew to 340MB, and bitcoind crashed, asking me to run DB recovery. After I used BDB tools to dump and reload the wallet, I was able to get it to restart (alebit using 500MB of RAM), but trying to transfer out the remaining balance failed with:
error: Error: The transaction was rejected. This might happen if some of the coins in your wallet were already spent, such as if you used a copy of wallet.dat and coins were spent in the copy but not marked as spent here.
How do I recover my wallet now?
|
|
|
|
|
It seems the transaction went through after about an hour and a half.
|
|
|
|
|
I created a send coins transaction when my laptop was offline; now it's stuck at 0/unconfirmed and not visible to the recipient, even though other transactions I created later went through. How do I force the transaction to be re-sent to the network so it can make progress? Or alternately, how do I cancel the transaction so I can get my funds back?
|
|
|
|
|
