Actually no, transfering coins via IP address isn't encrypted. When you transfer coins to an IP, the recipient creates a new address just for that transaction and tells you to transfer coins to that address. A malicious exit node could sniff all Bitcoin traffic and intercept those transactions easily.
So for everyone: DO NOT USE IP ADDRESSES AS DESTINATIONS, ALWAYS USE BITCOIN ADDRESSES.
I suggest we disable IP transactions while the user uses a Proxy! Just to be on the safe side. |
|
|
|
Bitcoin addresses also provide better anonymity. In my opinion they are ideal. Otherwise it's necessary to use tor or the like also to guarantee anonymity.
Isn't that "unsafe"? Say I am an exit node listening for bitcoin transactions and grab them? Or is everything public/private key encrypted? [1][1]Which is my guess. |
|
|
|
|
I don't know that much about IPv6, but it sounds good, if it's possible.
How ever, keep in mind that as of now, 9/10th of the world still uses IPv4!
So it is a great idea, and developer(s) (how much does bitcoin have anyways?) should implement it in bitcoin (in my humbly opinion).
How ever, making it default to use IPv6 isn't a good idea.
It's totally viable when everyone will be using IPv6, it's just everyone still uses IPv4!
(And I see now that in my previous post I basically explained what other people adviced... Oops!)
|
|
|
|
We should have a separate section for trading.
I strongly agree on that, since we have no market to trade things for bitcoins, a separate forum board works just as well! A "General Questions and Comments" section might be good also.
Yeah, "Tech Support" ain't a good place to discuss general questions, or feed back! |
|
|
|
May I ask why the choice in software?
Simple, lightweight, took less than a minute to install, pages saved as .txt files. Do you think MediaWiki or something else would be better? Well, I prefer MediaWiki to be honest... but that's just me... |
|
|
|
|
BitcoinFX, I suggest using LFS (Linux From Scratch) to build a netboot image that when it generates a new block, it will send it to an bitcoin address or IP.
But that's just me.
(PS: It would be nice if someone created a bitcoin farmer/miner that does not run under a kernel but runs directly on the hardware, might improve speed!)
|
|
|
|
I guess it boils down to best bang for the buck.
Note: we also need to keep in mind the energy usage of each part, just sayin'. |
|
|
|
We have proper statistics running now. Here is a dump of our stats for the last few days:
Payment Stats
Total Number of Payments: 17
Total Value of Payments: $49.63
Estimated Monthly Income: $206.74 (BC33,830.93)
Estimated Daily Income: $6.89 (BC1,127.48)
Average Number of Daily Payments: 2.36
Average Value Per Payment: $2.92
Wow, so how does it feel to be the first company that adopted a new payment system?! |
|
|
|
So, you started your exchange and I could get 600-650 BTC for 1 EUR? Hmm, I should've bought some then, if only I knew about it!  |
|
|
|
I figured it out, thanks for the help anyways guys
Out of curiosity, what was the problem? |
|
|
|
Better yet -- run it in a sandbox / jail / virtual instance. That's what I do. But I am paranoid.  NEVER RUN A USERSPACE APPLICATION AS ROOT, EVER
Sorry about that, but using root for that is so foolish caps and bold is required.
It's unsafe for your security, it will get you laughed at, it will cause kittens to be raped. (Seriously, who doesn't like kittens?)
You could also run it on an entirely different machine locked out from the world by a firewall allowing traffic to only another machine's 8333 port which also has bitcoin running on there which actually connects to the network.  |
|
|
|
Run this and afterwards try bitcoin again: (just to be safe guys!) |
|
|
|
NEVER RUN A USERSPACE APPLICATION AS ROOT, EVERSorry about that, but using root for that is so foolish caps and bold is required. It's unsafe for your security, it will get you laughed at, it will cause kittens to be raped. (Seriously, who doesn't like kittens?)Anyhow, if it's installed it *should* work. Is it properly installed and findable? Run this:
|
|
|
|
|
I didn't think it wasn't gonna be MediaWiki, anyways, thanks!
|
|
|
|
|
As the title says, we need, or at least could use a wiki. (in my opinion, that is)
I don't have the resources to host one myself, maybe you (Satoshi) can host one on here?!
Any how, I will defiantly do some editing myself.
So, what do you guys (and gals, if there are any) think?
Edit: I can help administer the thing!
|
|
|
|
|
Bitcoin should not do that, maybe you don't have enough memory and your PC starts swapping?
|
|
|
|
DEB isn't a bad route, you'll hit the vast majority of desktop linux users, most of whom won't be buggered to try compiling in the first place, so I don't think it's entirely unreasonable.
Debian packages cover alot of distros, if bitcoin really gets big we want to make rpms too. |
|
|
|
Right now there isn't a port number setting to do that. It's a feature yet to be implemented.
So, if I somehow I forwarded port router:8333 to bitcoinhost1:8333 and router:8334 to bitcoinhost2:8333, we get undefined behavior? Because that seems like trivial to me, to keep track of port numbers in any p2p app. |
|
|
|
We all talk about bootstrapping systems, how ever, my idea might be a bit better. A user starts bitcoin on a host for the first time, and it will initially download a list of nodes that it will connect to. (until, of course, we have a lot of static nodes we can hard code into bitcoin...) Then, the client tries to connects to those IPs on that list it downloaded, or when it already has a list downloaded from the last time it started bitcoin, connect to those. When we're connected, the client asks every node for a list of nodes they know and updates its node list. Once a complete list is obtained, it is saved on the hard drive and a copy is kept in memory. (This is because we want to have a list of nodes without actually connect to that indexing server.) And finally, the node is completely connected to the network. When a new node connects (when it receives a "new node packet"), the list is both updated in memory and saved to the hard drive again. To make updating the list with new nodes so bandwidth friendly as possible, I suggest that every node "echoes" the IP of a new node connecting to the network to all the nodes it knows... Pros: * Has bootstrapping in mind. * Is distributed for clients that have a node list Cons: * Every new client needs to connect to a server to get a new node list until we're done with bootstrapping. This, in my eyes, seems like the best solution to our bootstrapping problem... PS: If we implement this, we might just wanna check if the "new node packet" we received contains bogus IPs, or IPs that resolve to .gov domains! |
|
|
|
Nodes stop trying to initiate connections once they have 15.
Are you sure about that? I get 30+ connections easily! I have port 8333 open, but I can't exactly believe everynode of the network connects to me. (I'm running version 0.2, downloaded from the website.) The client stops making outgoing connections once it has 15 connections but if your port is open it continues accepting incoming connections from other clients which haven't yet connected to 15 clients. If the port isn't open, it can't accept incoming connections so it will never connect to more than 15 clients. It does however seem unreal, if some people only get 8 and I can get 40+. We should make a user-pickable connection limit, for both incoming and outgoing connections. |
|
|
|
|
Show Posts
