 Show Posts
|
|
Pages: [1]
|
Just to be a little bit picky, the netstat output is slightly different between BSD-like Unix and GNU/Linux.
The port is separated by a dot on the BSD-like Unix. So maybe the pattern matching /:8333/ could be
reviewed to include also the other output... but beside that, this is just fine.
Well, darn. Could you provide a sample few lines of output from a BSD netstat -an? It would take more than changing the /:8333/ pattern to fix this, if I understand your description correctly. There is also the awk split on the ":" which would have to be fixed as well. This is all doable with a little bit of regular expression hacking (something I do easily.) But I should see the exact BSD netstat -an output first, to be sure I understand it correctly. I think this could do the trick in awk for the matching : && (/:8333/ || /\.8333/) and for the split, an if block to match the : and another if block to split on dot. It will start to be unreadable for an one-liner ;-) FYI, here is output: tcp4 0 116 192.168.1.2.8333 80.217.82.59.45167 ESTABLISHED
tcp4 0 0 192.168.1.2.8333 68.103.101.19.29297 ESTABLISHED
tcp4 0 0 192.168.1.2.8333 79.184.79.110.1191 ESTABLISHED
tcp4 0 0 192.168.1.2.8333 61.94.216.38.10100 ESTABLISHED
tcp4 0 0 192.168.1.2.8333 113.22.164.48.10020 ESTABLISHED
tcp4 0 0 192.168.1.2.8333 85.232.113.117.8597 ESTABLISHED
tcp4 0 0 192.168.1.2.8333 46.109.12.201.3328 ESTABLISHED
tcp4 0 0 192.168.1.2.8333 62.103.58.117.3230 ESTABLISHED
|
|
|
|
Let's just make the final count with awk too... #!/bin/sh
# Display foreign IP addresses coming from port 8333 --or-- connected to local port 8333.
# Append line at end with date and count of addresses displayed.
netstat -an |
awk -v date="$(date)" '$6 == "ESTABLISHED" && /:8333/ { split($5, a, ":"); print a[1] ; n++ }
END { print "# " date " : " n " bitcoin clients seen." }'
Just to be a little bit picky, the netstat output is slightly different between BSD-like Unix and GNU/Linux. The port is separated by a dot on the BSD-like Unix. So maybe the pattern matching /:8333/ could be reviewed to include also the other output... but beside that, this is just fine. |
|
|
|
NVIDIA is geared towards floating point, while bitcoin's SHA256 algorithm wants integer math.
ATI GPUs are better at this.
You are maybe right, I don't know well the inner set of instructions per GPU-brand/type. The instructions usually used for SHA-256 (IMHO, all the SHA-2 implementation as they use the same scheme just the size is different) implementations are all the bit-wise (AND, OR, NOT and XOR) operators on 32-bit word, the right shift instruction but also the rotate right/left instructions. A comparison of all cycles required for all the instructions per type FPGA, GPU, Cell-like or other SIMD could be useful. I don't know if someone in the forum already made this along with a rough estimation of the cost per technology. On the other hand, building something for SHA-2 that can be reused for other projects relying on SHA-2 is not a waste of time/money. If you or someone else build something in that scope, I will be willing to invest some time and money in the project. |
|
|
|
bitcoin maintains a database of P2P addresses. Obtaining addresses via netstat is rather sub-optimal, when you could use bitcointools to extract addresses directly from the bitcoin database. As to the larger point... HTTP and DNS bootstrapping should be pursued. Much more efficient than IRC. Right, that's why I was pursuing on that way. By the way, I made a test with bitcointools to dump the address out of the database : python2.7 dbdump.py --datadir ~/.bitcoin/ --address
...155.6:36128 (lastseen: Sat Dec 18 21:09:42 2010)
68.52.60.203:36128 (lastseen: Sun Dec 26 15:28:48 2010)
68.53.17.115:36128 (lastseen: Thu Dec 16 18:56:57 2010)
68.56.241.235:36128 (lastseen: Sun Dec 26 17:32:34 2010)
68.62.250.145:36128 (lastseen: Sun Dec 26 15:39:33 2010)
....
Even if the netstat approach could be suboptimal, there is an advantage over relying on the addr dump from the database. If you get the address from the TCP Established session, these are really the active Bitcoin clients and from the database, you are guessing out of the lastseen information where you have already a lot of dead addresses. And picking the appropriate time delta can be tricky except if there is already something in the database structure to just list the active ones. On the other hand, the Berkeley database need to be only accessed by one process at a time and you need to shutdown the existing the current database. Maybe another appropriate way might be to read the addr message passing over the TCP sessions (using pcap) and extract the addresses and publish that stream to the HTTP/DNS directory. What's the most appropriate techniques to get the currently active Bitcoin addresses? |
|
|
|
To have a full-blown Bitcoin client in shell scripting might be a bit difficult especially with the cryptographic aspect required (except if everything could be called from command line using OpenSSL...) but nothing is impossible.
Is it possible to use ECDSA with openssl ? I've looked for this in the openssl manual page, but I haven't found anything apart from DSA and RSA. Anyway indeed most of the parts of the program would be called with command line programs, especially cryptographic stuffs. I think so to generate an EC key: openssl ecparam -out ec_key.pem -name sect571k1 -genkey
and for signing something like this: openssl dgst -sha1 -sign ec_key.pem -out filetobesigned.txt.signed filetobesigned.txt
and to verify the signature: openssl dgst -sha1 -prverify ec_key.pem -signature filetobesigned.txt.signed filetobesigned.txt
But I don't know the exact elliptic curves used by Bitcoin. You can get the one supported by OpenSSL by doing an: openssl ecparam -list_curves
Is there a table of the EC properties used by Bitcoin somewhere? I suppose the easiest is to read the source code... My reply (being out of scope of the HTTP bootstrapping) should be under your new post
about the implementation of a Bitcoin client in shell scripting (http://bitcointalk.org/index.php?topic=2461.0).Hope this helps a little bit, (PS. you don't have to put a whole pipe in a same line. The '|' character can end a line.)
I know but I suppose this shows my laziness when doing a paste into the forum ;-) |
|
|
|
Oh this is cool. I confess I didn't know the commant netstat.
It could be cleaned a bit I think :
netstat -an |
awk '/8333/ && /ESTA/ { print $5 }' |
sed 's/:8333//' |
tee >(echo "# $(date) $(wc -l) Bitcoin clients seen.")
Thanks for the cleanup. I have also updated the code to get the current remote IP of my Bitcoin client and added a correct Content-Type... Reading a bit the code of the Bitcoin client, the client is using a simple trick to know its remote IP via the IRC server ( https://github.com/bitcoin/bitcoin/blob/master/irc.cpp#L333). That's why I added another script http://btc.fo.vc/getip to get your current remote IP and add it into the list and I'm finally sorting the IP addresses. netstat -an | awk '/8333/ && /ESTA/ { print $5 }'
| cut -d. -f1,2,3,4 | (tee -a >(curl -s http://btc.fo.vc/getip))
| sort -t . -k 1,1n -k 2,2n -k 3,3n -k 4,4n | (tee >(echo "# $(date) $(wc -l) Bitcoin clients seen."))
The best would be to add an additional addip to merge all the IP announced by each clients with some minimal control to avoid non-Bitcoin client to announce faked IP addresses via HTTP. I think that seems reasonable to add HTTP bootstrapping into Bitcoin. Regarding the port used, it seems that the current client pushing the information on the IRC channel is also pushing the TCP port used. Is there a lot of Bitcoin clients using a different port than the standard one (8333)?
PS#2. I like this idea a lot. Especially since it's quite easy to install a mini http server such as thttpd for instance.
This makes me even dream of a full implementation of bitcoin via pure shell scripting. The http server could also publish his blocks, that could be requested by giving the hash of the block via a simple HTTP GET request.
To have a full-blown Bitcoin client in shell scripting might be a bit difficult especially with the cryptographic aspect required (except if everything could be called from command line using OpenSSL...) but nothing is impossible. Have a nice day, |
|
|
|
Hi Everyone, Reading a bit about the bootstrapping[1] of the P2P protocol, I was wondering why the client is not including by default a HTTP bootstrap as an alternative to IRC (often IRC is blocked or some antivirus/anti-malware products tag the Bitcoin application to be suspicious just because of the IRC traffic). For the test, I setup a page where I publish the IP seen by my Bitcoin client: http://btc.fo.vc/ (accessible in IPv4 and IPv6[2]) The IP addresses are collected with a simple script like this: netstat -an | grep 8333 | grep ESTA | awk '{print $5}' | cut -f1,2,3,4 -d"." > /tmp/bitcoin
(date | awk '{print "# " $0 " Bitcoin clients seen"}') >>/tmp/bitcoinand push on the remote server. Until now, I didn't dig into the code of Bitcoin but I suppose including an alternative bootstrap to the IRC (and 8333) is not something unrealistic. Let me know what you think. adulau [1] http://www.bitcoin.org/wiki/doku.php?id=network[2] We never know, maybe Bitcoin will support IPv6 in the future |
|
|
|
I'm slowly working my way through though. I will definitely use GnuPG and not RSA finally, for GnuPG is much more known. I'll just have to read the manual page many times.
The nice thing with OpenPGP messages (GnuPG is mainly a good implementation of the OpenPGP standard - http://tools.ietf.org/html/rfc4880) that you can extend the algorithms (check section 9.1 of the standard) used to make the signature while still using the same message format. Don't forget that is depending of the OpenPGP private key used you might use RSA as signing algorithm as the key might be in RSA... Kind regards, PS: Thank you for the BC donation to Forban. |
|
|
|
At some point I wanted to use ECDSA signing capabilities of bitcoin address. But it's not easy, and the bitcoin client doesn't provide any tool for that. And I was convinced that it should not.
Using GnuPG would be nice, but I realised that it's a pain in the ass to program with. It realy doesn't seem to me that it is suitable for scripting.
I felt your pain when dealing with GnuPG scripting especially with how file handles are managed. Until I discovered the Perl API to access GnuPG called GnuPG::Interface (made by Jesse Vincent): http://search.cpan.org/dist/GnuPG-Interface/http://search.cpan.org/dist/GnuPG-Interface/lib/GnuPG/Interface.pmThis is working great and avoid the classical glitches. Hope this helps, |
|
|
|
I have tried DiabloMiner on MacOS X but I have some errors when DiabloMiner is creating the command queue: [12/25/10 5:18:52 PM] Started [12/25/10 5:18:52 PM] Added GeForce 9400M (#1) (2 CU, local work size of 256) [12/25/10 5:18:54 PM] Added GeForce 9600M GT (#2) (4 CU, local work size of 256) [12/25/10 5:18:54 PM] ERROR: [CL_DEVICE_NOT_AVAILABLE] : OpenCL Error : clCreateCommandQueue failed: Device 0x1020331f0 is not available. [12/25/10 5:18:54 PM] ERROR: Failed to allocate queue [12/25/10 5:18:54 PM] ERROR: [CL_INVALID_COMMAND_QUEUE] : OpenCL Error : clEnqueueWriteBuffer failed: invalid command queue 0x0. Exception in thread "DiabloMiner Executor (GeForce 9600M GT (#2)/0)" java.lang.NullPointerException at org.lwjgl.opencl.APIUtil.releaseObjects(APIUtil.java:506) at org.lwjgl.opencl.APIUtil.releaseObjects(APIUtil.java:502) at org.lwjgl.opencl.CL10.clReleaseCommandQueue(CL10.java:565) at com.diablominer.DiabloMiner.DiabloMiner$DeviceState$ExecutionState.run(DiabloMiner.java:568) at java.lang.Thread.run(Thread.java:680) I opened a ticket at github with more information : https://github.com/Diablo-D3/DiabloMiner/issues#issue/3Thank you for your work, |
|
|
|
Dear bitcoins enthusiasts, Forban is a simple link-local opportunistic p2p client. Forban allows to do local p2p file sharing while not depending on Internet with all the computers connected on the same shared LAN or wireless network. In the spirit of promoting p2p technologies, Forban is only accepting Bitcoins donation to its address : 13Q8TCJqLQ8tfL7rhoa16PmgQrBTjkZ26i . For more information about Forban: http://www.foo.be/forban/ and the github development page: https://github.com/adulau/ForbanThank you, |
|
|
|
|
