While gold and swiss Francs have climbed Climbed compared to what? My time? Moondust? Barbie dolls? USD? Different things are important to different people. On the list of why I value BTC "safe haven" isn't even in the top 10  |
|
|
|
Might be a good idea to try to email Bruce first before trying to defame him in public. From what I've seen he isn't a bad person and is genuinely working on things. It's not nice to make personal attacks on people without first trying to see what's up. I could understand if he made a bad reply or something but cmon  It's my understanding that the parent post had both been emailed and that it in no way is defamatory. On the contrary, I fully agree that Bruce is doing a great job evangelizing. What I support are the comments on the conference and the communication around it. |
|
|
|
|
I agree with the sentiment of the parent post.
(My plans have been to go to the conference, but I'm currently worried about the lack of updates/info. It would be a transatlantic business trip and for that I need to be able to motivate its validity)
|
|
|
|
|
Is the Mac build problem a case of trust (we only want one person handling it) or a lack of Mac users with the knowledge to compile it?
(Yes, "me too").
|
|
|
|
yes, SEPA costs cannot be more than the one for local within-country transfers (if same currency!). Hence, most of EURO banks (read: banks in countries which do have the EURO as their official currency) do not charge anything at all for wiring.
Not only countries with euro. The banks I know of in Sweden (still using SEK) also do free SEPA transfers. |
|
|
|
A better solution would be for a client to ask its peers for "elided blocks", which would allow the client to download elided blocks in a progressive manner. The client would indicate bitcoin addresses of interest and its peer would provide the elided blocks. I might misunderstand, but it sounds like there's a leak of pseudoanonymity at this stage. The peers would not only be able to associate IPs with specific addresses but also which addresses [likely] belong to the same wallet/user. Bitcoin users shouldn't trust their peers  |
|
|
|
|
Sort of.
If you steal BTC, you'd likely want to cash out as quickly as possible. Thus successful heists would cause large sell-offs. Like we're seeing right now, at the same time a lot of people are reporting both stolen wallets as well as transfers away from mtgox.
|
|
|
|
Reposting here from the 0.3.23 release thread. I have issues where one of my clients, solely relying on one of my other clients on the same LAN, get disconnected due to flood control. I don't recall seeing this in 0.3.21. FYI I'm having issues connecting my "internal" client (on one computer) with the one I run on another computer that's port mapped and listed on the IRC channels. The internal client does not go on IRC, isn't port mapped and the config file adds the other client on the local network using addnode. This worked well with at least 0.3.21, never really tried 0.3.22. With 0.3.23 it seems the connection gets dropped easily, and once it's been dropped it doesn't seem to come back up. Even when it's initally up (1 connection) there are very few blocks being received, and very slowly, though. From the internal client log, although it doesn't seem to be detailed enough: ThreadOpenConnections started
trying connection 192.168.0.123:8333 lastseen=-335573.5hrs lasttry=-363351.2hrs
ThreadMessageHandler started
connected 192.168.0.123:8333
sending: version (85 bytes)
...
ProcessBlock: ACCEPTED
socket closed
disconnecting node 192.168.0.123:8333
(Both computers are Macs) Is there a way to prioritize clients on the same local network? I'd like for my "external" client to feed blocks to the "internal" one as quickly as possible. Might've found the culprit. This is from the "external" client's log: sending: block (23423 bytes)
sending: inv (37 bytes)
socket send flood control disconnect (10030645 bytes)
disconnecting node 192.168.0.132:64860
If flood control is something recently added then I guess that would be where my problem comes from. It'd be great to be able to turn that off for clients on the same local network at least if not the possibility for a full whitelist. |
|
|
|
I'm having issues connecting my "internal" client (on one computer) with the one I run on another computer that's port mapped and listed on the IRC channels.
-snip-
Is there a way to prioritize clients on the same local network? I'd like for my "external" client to feed blocks to the "internal" one as quickly as possible.
Might've found the culprit. This is from the "external" client's log: sending: block (23423 bytes)
sending: inv (37 bytes)
socket send flood control disconnect (10030645 bytes)
disconnecting node 192.168.0.132:64860
If flood control is something recently added then I guess that would be where my problem comes from. It'd be great to be able to turn that off for clients on the same local network at least if not the possibility for a full whitelist. |
|
|
|
|
FYI
I'm having issues connecting my "internal" client (on one computer) with the one I run on another computer that's port mapped and listed on the IRC channels. The internal client does not go on IRC, isn't port mapped and the config file adds the other client on the local network using addnode. This worked well with at least 0.3.21, never really tried 0.3.22. With 0.3.23 it seems the connection gets dropped easily, and once it's been dropped it doesn't seem to come back up. Even when it's initally up (1 connection) there are very few blocks being received, and very slowly, though.
From the internal client log, although it doesn't seem to be detailed enough:
ThreadOpenConnections started
trying connection 192.168.0.123:8333 lastseen=-335573.5hrs lasttry=-363351.2hrs
ThreadMessageHandler started
connected 192.168.0.123:8333
sending: version (85 bytes)
...
ProcessBlock: ACCEPTED
socket closed
disconnecting node 192.168.0.123:8333
(Both computers are Macs)
Is there a way to prioritize clients on the same local network? I'd like for my "external" client to feed blocks to the "internal" one as quickly as possible.
|
|
|
|
UNENCRYPTED wallet on multiple websites?
This is the most shocking part for me... he actually uploaded a half-million-dollar wallet.dat to the internet in the clear. Wuala encrypts user side before uploading to the cloud, and I believe the same applies to Spideroak. OP mentioned he stopped using Dropbox as soon as he realized they don't. Don't know what's shocking about that since it's very much not "in the clear" or "unencrypted". However, this and other stories like it builds a case that there might be active attacks being made on Bitcoin participants, and if it's more than a few then meatspace explanations become statistically unlikely. I'd rather lean towards exploitable C-code in the client. |
|
|
|
Possibly there was a concern of a leak of private keys, so everything needed to be moved.
(Not sure what timezones the different times posted are in) If it fits with mtgox going offline for a while today that sounds plausible. If they suspect their infrastructure to be breached it would indeed be an obvious action to take. |
|
|
|
Bitcoin addresses don’t specify where something is.
Also I wonder what it means to be "non-compliant" in this case. It means not writing software according to the same mindset that gave you the Internet, World Wide Web, email and a host of other cool things I'm quite sure you use every day. I fail to understand your hostility towards best practices. |
|
|
|
Now, for the life of me, I fail to see how is this non compliant with relevant RFC. You would have to claim that commonly used http: URI's are non compliant as well to support 'non compliance' argument. http: serves files, bitcoin: wouldn't. Quoting from a comment by Fredrik on a relevant thread at Falkvinge's blog: The double slashes are to tell that a file is located on a remote computer. When not specifying a file they make no sense. Bitcoin addresses don’t specify where something is.
Local file, option 1:
/etc/passwd
file:/etc/passwd
Remote file:
//example.com/etc/passwd
http://ftp://example.com/etc/passwd
http://example.com/etc/passwd
https://example.com/etc/passwd
Local file, option 2, with empty host name:
///etc/passwd
file:///etc/passwd
It’s good to have something like the “mailto:” URI scheme because it’s simple, and it supports adding a subject line that users will like to log in their accounting. (One click transactions are not one click if you need to type a description for the transaction manually.)
(Falkvinge's own suggestion was bitcoin:amount/address) |
|
|
|
We can link to it or even open a tracker. I am telling you this is safe.
Download all the binaries of 0.3.22 and the source and then put them in the same folder as where you are going to download the torrent. They match. I didn't made a single change.
I'm not questioning your release, I'm saying we will have trust problems when users don't understand which of 50 different torrents is safe to download and which one isn't. (Linking helps somewhat, yes, it's a good suggestion. If so - state in the torrent descriptions that only torrents linked to from bitcoin.org should be implicitly trusted) |
|
|
|
As I said, source is included and I encourage you to compile from it. The binaries are provided for easy of use.
I will be in charge of torrenting the releases if you want. I am a trusted member.
Yes, but casual users don't know that (and they very much won't compile their own binaries or verify hashes - we're talking Bitcoin going mainstream here). It's a lot better having everyone going to a known place to download the official clients and being told that that's the only way of being sure, than having them trying to figure out which torrent is safe and which isn't. |
|
|
|
Since we are getting a lot of media, I prepared a torrent with the latest release for all released binaries - Windows, Windows(Zip), Mac OSX, Linux(UNIX) - in TPB. It also includes the sources and I encourage everyone to compile if they know how to. Please help seeding and passing around. This will ensure new users can still easily get the client. http://thepiratebay.org/torrent/6458302How did you solve the trust problem with there suddenly being 50 different torrents where 49 of them contains trojaned versions that steal bitcoins from users? |
|
|
|
I'm sure there's already some cloud-based solution for this, but how can you trust them? I'm sure they could disappear without a trace with the coins if they wanted to right? Secure cloud backup solutions exist: https://forum.wuala.com/viewtopic.php?f=11&t=1546(Your wallet is encrypted on your computer before being transfered, Wuala never has the technical possibility to decrypt it) |
|
|
|
Otherwise, there will be the need to explain our personal frames of references with every transaction, or risk a misunderstanding undermining our businesses.
We do this every day. Five bucks, 2 K's, a million etc. (Ok, so I don't do transactions of a million dollars every day, but .. ) |
|
|
|
|
Show Posts
