|
1921
|
Bitcoin / Bitcoin Discussion / Re: Yes, the Bitcoin.org Site and Forum were Down
|
on: December 21, 2010, 06:11:39 PM
|
It's now making daily backups to remote servers. Thanks for help ShadowOfHarbringer.
No problem. Are you planning to make some public site from which other people (such as myself) could download backups ? I can setup a backup server too (and act as a mirror backup), as i rent a few servers in datacenters here and there. You could probably setup a dedicated RSYNC server with bandwidth per user limit. There is even no need to give people SSH access actually. |
|
|
|
|
1922
|
Bitcoin / Development & Technical Discussion / Re: Bitcoin over GSM
|
on: December 21, 2010, 12:22:34 PM
|
I have this idea: how could we start a bitcoin-over-GSM phonecall service? It should be possible to send bitcoins over a phonecall as a modulated audio stream. The only problem would be the storage, which has to be as a recording or binary data (transforme by some software in the smartphone)
GSM networks only support well certain sound frequencies, but I'm sure it would be easy to encrypt digital 0s and 1s when using the correct frequency. This should not be very difficult actually. And BTW, this is an awesome idea. Even if they censor the internet (which is unlikely), we will still transfer bitcoins over phone. |
|
|
|
|
1923
|
Other / Off-topic / Re: Wtf...
|
on: December 21, 2010, 12:12:55 AM
|
creepy story. wtf...
This means war. War on freedom. |
|
|
|
|
1924
|
Bitcoin / Bitcoin Discussion / Re: Yes, the Bitcoin.org Site and Forum were Down
|
on: December 20, 2010, 07:00:36 PM
|
An attacker could mess up the original file that is pulled by the backup servers, but I'm not too worried about that happening. Old backups can be stored for at least a week or two.
Yes, but it is also easy to do automatic MD5/SHA1/SHA256 signing of every file. So this is a non-issue really. Just add 5 more lines to backup script. The server now makes daily backups automatically, but doesn't rsync them yet. Bzipped size about 50 MB.
Awesome. I can create a backup site myself easily. -------- Also, here is the examplary RSYNC command to backup a folder of one server to another: # rsync -rltgoDvzx root@server.1:/remote/backup/folder/path /path/to/local/backup/folder --inplace
If you want to check what will the command do, without actually executing it, add "-n" parameter, which will do a so-called DRY RUN: # rsync -rltgoDvzx -n root@server.1:/remote/backup/folder/path /path/to/local/backup/folder --inplace
If the remote sever is on a different port than standard 22, then use this: # rsync -rltgoDvzx -n root@server.1:/remote/backup/folder/path /path/to/local/backup/folder --inplace -e 'ssh -ax -c blowfish -p 40022'
This is also a dry run, no files will be transferred. 40022 is naturally the port number and blowfish is type of encryption used for connection (it's the fastest one for transferring files). The "- rltgoDvzx" parameters will make rsync transfer entire directory recursively with all possible subdirectories, without files/dirs from other mounted volumes in the path. Try # man rsync to see what all the options mean. |
|
|
|
|
1925
|
Bitcoin / Bitcoin Discussion / Re: Yes, the Bitcoin.org Site and Forum were Down
|
on: December 20, 2010, 10:33:16 AM
|
This implies that the attacker have permissions to delete. Hence it is - a threat.
The only thing that implies is that you do not understand how rsync works. RSYNC uses privileges of given SSH user when accessing remote server. So if you create an unprivileged user, only give SSH public keys only to trusted people, and make all backups read - only, really nothing can happen. Also, you can setup a separate server with SSH daemon, which will be used for storing backups... So potential attacker will never have access to the main server. If you are really really really paranoid, You can even set up a chain of servers ROOT -> A -> B -> C, where ROOT SSH-connects to A and stores backups there, then B connects to A to download the backups, and C connects to B to download backup copies. And you only give access to C to the outside world. But i seriously doubt such a security measure will be ever needed. |
|
|
|
|
1926
|
Bitcoin / Bitcoin Discussion / Re: Yes, the Bitcoin.org Site and Forum were Down
|
on: December 19, 2010, 11:16:30 PM
|
And to secure WAL-log (if its required, which is doubtful) it is better to use a pgp encryption
You can use simple automated script to compress the files, encrypt them with PGP or Truecrypt, and then RSYNC them. Simple enough, no need to involve any emails in this. The problem is that source of "creation_a_new_WAL_log_file" event is DB daemon, not a remote backup server. So ? Hence, the original server pushes backups to other servers. And backups will be erased when the original server has been hacked. That is not a problem when using RSYNC. By default, RSYNC does not delete files that are deleted from remote server. |
|
|
|
|
1927
|
Bitcoin / Bitcoin Discussion / Re: Yes, the Bitcoin.org Site and Forum were Down
|
on: December 19, 2010, 02:31:21 PM
|
And to secure WAL-log (if its required, which is doubtful) it is better to use a pgp encryption
You can use simple automated script to compress the files, encrypt them with PGP or Truecrypt, and then RSYNC them. Simple enough, no need to involve any emails in this. The problem is that source of "creation_a_new_WAL_log_file" event is DB daemon, not a remote backup server. So ? |
|
|
|
|
1928
|
Bitcoin / Development & Technical Discussion / Re: Bank Fraud, Is it possible?
|
on: December 18, 2010, 03:33:06 PM
|
Disclaimer: I have some experience in developing p2p network (freenet), but is a newbie in bitcoin. Please correct me if I am wrong. Observations - Generating private-club fake coins are easy
Get 100 notes from the "cloud", or a botnet. All "easy" coins are yours. - Getting fake coins accepted network-wide is hard
When the network grow large, it is impossible. - But you don't need it accepted network-wide
Banks, such as MyBitCoin, does not return the same coin you save. If you can make it accept your fake coin, you can get some real coin from it.
You can't make ANY "fake" coins accepted without first taking over more than 50% of the network processing power. Well - Actually you cannnot make "fake" coins at all. Even if you take over 51% of network, if any coin does not match the blockchain, it will be rejected by the rest (49%) of the network. The only thing you could do is double spend some transactions. |
|
|
|
|
1929
|
Bitcoin / Bitcoin Discussion / Re: Yes, the Bitcoin.org Site and Forum were Down
|
on: December 18, 2010, 07:43:42 AM
|
And to secure WAL-log (if its required, which is doubtful) it is better to use a pgp encryption
You can use simple automated script to compress the files, encrypt them with PGP or Truecrypt, and then RSYNC them. Simple enough, no need to involve any emails in this. |
|
|
|
|
1930
|
Bitcoin / Bitcoin Discussion / Re: Yes, the Bitcoin.org Site and Forum were Down
|
on: December 17, 2010, 03:55:54 PM
|
2. RSYNCed Backups on 10 other servers also cannot be deleted.
why? 1. Simple. Because the main server will not have access to the mirror servers. Only the mirror servers need access to root server, not the other way around. Neither the main server, or possible hackers don't need to know anything about what mirror servers are there, or how many of them is out there. 2. Once you do one backup, you can create a chain of backup servers, where server A backups ROOT server, server B backups A server, and server C backups B server, making it nearly impossible to hack or even trace where all the backups are. All of this can be done with few simple RSYNC scripts. If you are thinking about government trying to hack or interfere with main site & mirror servers to bring them down, then I'm telling you: not a chance. Just look at the wikileaks case. There are thousands of wikileaks mirrors now. And it is quite easy to create new ones. Very powerful people had interest in killing wikileaks, yet they failed. Internet is already far more powerful & resilient than everybody expected. Even Russia government with all their dirty methods would not be able to make all wikileaks mirrors go offline if they wanted to. The only way to do that is shut down the internet completely. |
|
|
|
|
1931
|
Bitcoin / Bitcoin Discussion / Re: BitDNS and Generalizing Bitcoin
|
on: December 16, 2010, 12:15:23 PM
|
1.) Different chains but same CPU pool.
2.) When solving a block give 50 BT and domain name.
Currency should stay currency, domains should stay domains. This should be separate things. It is stupid to push something like this on the main client / blockchain. |
|
|
|
|
1932
|
Bitcoin / Development & Technical Discussion / Re: Version 0.3.18
|
on: December 16, 2010, 10:38:23 AM
|
I'm relatively new and find this whole network intriguing. I come from a software development background. My outside opinion might not mean much, here it is for what it's worth.
I think Bitcoin should be just for currency. The whole idea of using it for DNS or for other purposes sounds like an abuse. If the distributed database concept brought to light by Bitcoin is viable for a DNS system, then great - may it be started as a completely independent blockchain and network. I don't see how marrying the two systems adds any value.
If when I came across Bitcoin I had also discovered it did "DNS", I'd have been turned off by that. There is already enough new territory for the average newcomer to conquer, let alone one with no idea how software worked. Imagine the New York Stock Exchange also traded tampons and framing nails. That's how the idea of Bitcoin DNS looks to me.
If I understand correctly, one of the core tenets of blocks is that they be prunable to the absolute minimum size (which I understand to be 80 bytes) to hold the "proof of work" hashes necessary to establish which chain is the longest. The idea of using them as permanent storage for convenience betrays this.
I do think there should be a spot for arbitrary data to be sent along with transactions, but I think it should be VERY limited - and by that, I mean no more than either 32 bytes, meant as a sender's transaction reference. 32 bytes should be enough to fit a short URL, or at most, a 256-bit hash. I know somebody gained infamy for thinking 640Kbytes should be good enough for "anybody", but this isn't the same. I think it's fair to say that 2^256 possible references should be enough for anybody - Bitcoin should not offer payloads of any kind other than bitcoins!
Besides, we expect Bitcoin users to have Internet access after all. Bitcoin users already have the means to communicate all the data they need, by reference.
My standard disclaimer is I'm welcome to being corrected if it appears I have misunderstood the system, as I feel I have a decent grasp but I'm still a newbie.
+ 1, you have my full support. |
|
|
|
|
1934
|
Bitcoin / Bitcoin Discussion / Re: Yes, the Bitcoin.org Site and Forum were Down
|
on: December 16, 2010, 10:24:06 AM
|
The main site could be mirrored, but keeping the forum database in sync on multiple servers sounds difficult. Automated backups of the database to a remote location would be useful if something unexpected happens with the hosting. Any ideas how to store the backups? Maybe encrypt them and distribute to multiple servers around the world. Distributing them through a single gateway (Dropbox, Tahoe-LAFS?) would save bandwidth.
Will be sufficient to WAL-log of database and send log files to gmail account at fixed intervals It is a reliable way, even in the case of hacking the server, this backup can not be deleted. 1. Gmailing backups is too complicated and slow. 2. RSYNCed Backups on 10 other servers also cannot be deleted. RSYNC is an extremely powerful, stable, fast & totally command-line-scriptable app. You can use it to create a system of webserver backups. In fact it is widely used for Linux mirrors (Gentoo Linux uses this in its package management system). |
|
|
|
|
1935
|
Bitcoin / Bitcoin Discussion / Re: No coins generated in 708 hours, normal?
|
on: December 14, 2010, 07:54:33 PM
|
Oh, mine is running for ~1400 khash/s, several orders of magnitude slower than your systems. I thought I could spare a laptop crunching some numbers since it doesn't draw a lot of electricity. But dedicating a power consuming gfx card for the crunching would lead to a noticeable cost. So I'm out for now and wish you good luck with your crunching. Perhaps I'll use your monetary system some time in the future though, even if not generating any new coins personally. Thanks for your explanations!
The idea of bitcoin is not to generate money and get rich... if you want to use bitcoins you can just buy them, like you buy currency on paypal or any other online system ....or you can simply use bitcoin for money transfers worldwide. |
|
|
|
|
1936
|
Bitcoin / Bitcoin Discussion / Re: Yes, the Bitcoin.org Site and Forum were Down
|
on: December 14, 2010, 11:34:27 AM
|
|
Since I know something about Linux administration (and i have done something similiar already), i think can help here.
OK, here is what needs to be done:
1. Create a dedicated read-only MySQL or PostgreSQL (whichever is being used) database slave on the main bitcoin server.
This slave will be used for doing quick full backups every hour or half an hour. That backups will be automatically packaged and put in a certain folder on the server.
2. Create a bash or php script (about 10 lines) that will
a) Backup the database and pack it to .tar.gz
b) Backup directory structure of the webserver and pack it to tar.gz
Every X minutes.
3. Create a low-privileged user on the main Bitcoin server, using which RSYNC/SSH will connect to the server and download backups.
4. Setup another backup webserver - with apache/nginx/mysql/postrgre/whatever.
5. Create a script that will regularly download current backups from the main server using RSYNC over SSH.
6. Create a script that will ping/wget the main server to check if it works. If not, then the script will unpack last posessed backup, and then mstart apache/nginx/mysql
7. Setup SSH public key authentication so that RSYNC can connect.
8. ?? ??
9. PROFIT !
|
|
|
|
|
1937
|
Bitcoin / Bitcoin Discussion / Re: Yes, the Bitcoin.org Site and Forum were Down
|
on: December 14, 2010, 11:18:01 AM
|
Automated backups of the database to a remote location would be useful if something unexpected happens with the hosting. Any ideas how to store the backups? Maybe encrypt them and distribute to multiple servers around the world. Distributing them through a single gateway (Dropbox, Tahoe-LAFS?) would save bandwidth.
That would be a good start. Tahoe-LAFS would be nice to use also. (There's also possible synergy between Tahoe and Bitcoin) I think we can handle trusting the seniors not to abuse the database data. Any possible timetable? Why so difficult ? Why make it complicated ? Make it simple. RSYNC, a simple-yet-advanced Linux program can distribute almost anything (even whole Linux partition) over SSH from server to server using public keys (passwords are not needed). An automated script ( about 10-30 lines of code) can automatically ping main server, restore last backup and start backup forum once the main forum fails. RSYNC is blazingly fast. It can distribute whole directory structure over SSH, being waaaaaaaaaaaaaaay much faster than any FTP. Quite easy to do actually. |
|
|
|
|
1939
|
Bitcoin / Bitcoin Discussion / Re: PC World Article on Bitcoin
|
on: December 14, 2010, 11:03:38 AM
|
If you change the graph to show only DEC 2010 it looks like we exceed a search index volume of 10. The previous slashdotting didn't get it quite that high.
The first slashdotting is higher than of the second slashdotting attempt. Did you change the timline to DEC 2010? I think in the big graph it is getting averaged down and we won't see it on that one for another week or something. I confirm. It is at least the same high, or higher. |
|
|
|
|
Show Posts
