 Show Posts
|
|
Pages: [1] 2 3 4 5 6 7 »
|
|
DBsS2XZfteCWGPz19nEAWc8XJTKLfT651D
Thanks!
|
|
|
|
|
I am also waiting on an InstaWallet claim.
I did accept my claim, though I was a bit late to do so since I was never notified that I needed to, and because accessing the instawallet.com domain without the www stopped working so every time I tried to check on my wallet it looked to me like Instawallet had gone offline.
It now shows my status as PENDING_PAYMENT.
I message Boussac a couple days ago, so hopefully he responds.
|
|
|
|
Namecoin has unique features which ArtForz and I both recognize that will make it almost impossible to patch.
No Namecoin doesn't use Time Adjustment, but other functions in NMC open this up. 51% is not required for Namecoin. Could you point give us or point us to a description of the Namecoin problem? I haven't been able to locate documentation of it myself. |
|
|
|
Why does the blockchain format accommodate arbitrary text anyway? Who's idea was that? Mr Nakamoto.
If there's currently space for random text, couldn't the blockchain just be smaller instead?
It would be very difficult to prevent arbitrary text since it needs to store arbitrary data. A standard address is just a sequence of 20 bytes. What is stopping anyone from making those bytes an ASCII string? As soon as you need additional tools to unlock the content, these tools themselves become problematic and can be blocked/outlawed much more easily and with less harm to Bitcoin itself.
How would we restrict the tools? As long as Bitcoin is open-source, the blockchain storage format is openly available. As far as I see it, it would be wrong to try to block or outlaw tools for parsing the blockchain. People should be able to freely analyze its contents. If we have a problem with content in the blockchain, we need to either find a way to deal with it or learn to accept it. Hiding it won't make it go away. |
|
|
|
|
I see no reason to change the storage format over this. It might obfuscate transaction messages in the blockchain, but they will still be there. If people care enough to read the messages, they will use an old client or parse the new format.
|
|
|
|
|
I received a response from the hosting company from which the email originated stating that the account has been closed. Unfortunately, the phishing site itself seems to be hosted elsewhere (fwef33.tmweb.ru.)
|
|
|
|
Of interest from the email headers: Return-Path: <fewfewef@xm33.hostsila.org>
Received: from xm33.hostsila.org (xm33.hostsila.org [194.28.87.253])
...
Received: from fewfewef by xm33.hostsila.org with local (Exim 4.69)
(envelope-from <fewfewef@xm33.hostsila.org>)
I sent off a quick message to the .TK abuse email letting them know about the issue. |
|
|
|
|
Try C:\Documents and Settings\<User>\Application Data\Bitcoin. If that doesn't work, go to Start then Run and enter "%APPDATA%\Bitcoin". That should have the wallet and blockchain, just like .bitcoin on your Mac.
|
|
|
|
I agree with hashcoin's assessment. An investigator could collect public keys by agreeing to buy from people or pay them for some reason and/or by gaining access to an exchange, pool, or other service that pays people. These people then become easily trackable. Warning, brainstorm below: Would it not be better to randomize t instead of incrementing it? Instead you send the coins to h = hash160(concat(c, t)) where t is a large (256-bit?) random number. That way, it seems to me that even someone with public key couldn't determine if a given h was generated from a given c without knowing the t used. Although then again, I don't see how such a transaction could be redeemed by the receiver without some out-of-band communication of t. Maybe you could encrypt t to that public key and insert that into the transaction as well? This would let the receiver be able to see when he received the coins, but in order to prove ownership when spending the transaction, it seems like he'd have to reveal t, giving up the privacy. Maybe some form of non-interactive zero-knowledge proof could be used? |
|
|
|
The official Bitcoin Windows binary isn't built with VC, but it does use the Microsoft Visual C++ Runtime (msvcrt.dll).
What do you know. You're right! I just tested it with InspectExe and indeed msvcrt.dll is in the list of dependencies. That is the C RTL not the C++ RTL, and indeed mingwin uses the msvcrt dll to avoid the need for gpled code at runtime. Yes, it is C standard library specifically, but it is considered a Microsoft Visual C++ Runtime Library (there is no Microsoft Visual C) and I'm guessing that is what the error message is referring to. |
|
|
|
|
Thanks for the help. We made it to the next retarget. Although now we need to cut back on mining. Testnet is generating blocks too fast and will soon jump right back up in difficulty.
|
|
|
|
A forum member told me that it could be a trojan suggest me to post in this section becuase BTC client does not use VC in any way.
The official Bitcoin Windows binary isn't built with VC, but it does use the Microsoft Visual C++ Runtime (msvcrt.dll). This file might be corrupt. You can try running "sfc /scannow" from an administrator command prompt. This will attempt to find and repair bad system files. |
|
|
|
|
You get better speeds with Bitcoin Plus than with a normal miner program? What CPU to you have, and what miner did you try? For me, CPU mining with Ufasoft's miner gives me over ten times the hash rate of Bitcoin Plus, and even mining with Bitcoin's built-in generation capability gives me about four times that of Bitcoin Plus.
|
|
|
|
Some of you are missing my point, or I didn't explain it well. IPv6 will make it MUCH easier to firewall based on location. Yes, I know you can get geographical info of current IPv4 addresses now, but I'm saying with v6, it will be easier. It might be easier with IPv6, but it is easy enough now with IPv4. If a government wants to restrict Internet by country of IP address, they will do it. In fact, the decision to do so would probably be made by people who neither know nor care exactly how the filtering works on a technical level. |
|
|
|
|
I get no error. The SHA1 fingerprint of the certificate I get is bf5d728ac70686806c6fe7da2a7f1fe98daf98f1.
|
|
|
|
This is for folks that can't access sorceforge, IE embargoed countries.....
I think he was suggesting you copy that file and put it somewhere other than Sourceforge, such as in this topic. It does have the advantage that it is PGP-signed by a developer. -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
4909c17a1cc025c6f6c88d036f0b487c51c510f6 bitcoin-0.3.24-linux.tar.gz
fed0afebe0b0c0f77a637600ac4abecbe5d098ed bitcoin-0.3.24-macosx.zip
58531249230f769fdc755822b41e0f18ba59512c bitcoin-0.3.24-src.tar.gz
d4b5425eff673551a326d5326b92a06359dc1a3d bitcoin-0.3.24-win32-setup.exe
520aed70ee28a0a91ed49dd983639cb1fab2a93c bitcoin-0.3.24-win32.zip
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIVAwUBTiTMHNodwg8tvwyoAQL8CRAAgraSWP12lbwrhpiElvB7LIWoPbiE1dUx
i2ZO4MVJYKMbyuHu55j1Uq7a4ZqpNhXqq7U6efnoDTCl9sdpyhKxiql0SpsYBLs1
IehX4UEVGVMUE5uepmOs+cYnYuAhNzvxNqKFPv3D7uEOXPmSxlUa4s0GEnTgVR1l
0GFYf2T615MoGAak3+afahp4WB4XlHshttHT2P3o2/7N4Oh7iwFFtkmOj/Sb3Prc
C8skW83kUZ4i8W1HlZTmtr4YlQbKnx6bF6mbkTY1aQa1AV/8htenALkmR2+eCgsd
EY9WM8qruxnVLt/ao+VYw5jYLSYVKHt31ZD4rJM+5lKcTtU1NmNsGloen+hdLwC+
hggqnUQmvBzM7SKqvg4zI9SbgGR5fS3poTrFX7yDKZyLSPcjBND/lWi8evRiSEP0
yftCKL7zotdRy6QTG7tI1Fye1fyYuQdTB1nimE+7VJ8Q2O4DwE0iZKMuXm3GfaOr
T20Znvns9caMKED9T1gg42QgYM6EMMbeukBUkIXPt2tloDnn2tMzvvrKzgGBS1Lc
qv2ndhBCunBxNCQCHly4T2Rz8TJnm2XglS0d/VygcMuMSL0San5DwXYNnN4P0xD/
MXOdqrxcusIzKBbSHWPqInRmYUTymDtcqXWK3Cz6kRUXjBkRoSvDs8PBAvnaC236
1xol6uyMqZo=
=aMy0
-----END PGP SIGNATURE----- |
|
|
|
I don't really get it, how can I possibly protect others when the binaries I serve can potentially be malicious and I can potentially have malicious intentions ? Should I post checksums ? Doesn't work : - if I have malicious intentions the checksums will match the malicious binaries. - if the binaries get changed without me knowing it means that the server got compromised, the checksums shouldn't then be trusted either - if I post a link to SF, that won't help since some users won't be able to access it and it also could be compromised Let's face it, if you're truly paranoid, you read the source and then you compile it. Oh wait, you'd need to compile gcc too  If you have better ideas than the couple I exposed I'm open. But I'd rather give no checksums than a false sense of security. Actually I do compile gcc, but not for security reasons, lol. And you are right about it being better to provide no checkfiles then provide a false sense of security. What you could do is also mirror http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.24/SHA1SUMS.asc/download and provide a link to http://bitcoin.org/jgarzik-exmulti.asc which an earlier post said is the right signature to verify. Now you have not only provided a way to check your mirrored files, but that no one has changed the sf ones since you mirrored them. The idea is that you would have Jeff's PGP already, and not simply download it whenever you are checking a new binary. When you get the key for the first time, as with all PGP public keys, you should not trust its validity until you are convinced it is correct. You make this decision based on several factors such as where you obtained the key, what other sources agree that this key is legitimate, the PGP web-of-trust, etc. Jeff's key could use more signatures. Somebody make him attend a keysigning party. |
|
|
|
|
