 Show Posts
|
|
Pages: [1]
|
I'd like to announce Scallion, an OpenCL vanity .onion address generator. It gets around 600MH/s on a 6870 (similar on a 5770), allowing it to generate an 8-character prefix in just 15 minutes on average. It's written in C# and runs in both Linux (on Mono) and Windows. Update (23 Nov 2013): I'm now generating vanity .onion addresses for a small fee. See the Scallion as a Service documentation for more details. In particular, 7 and 8 character .onion addresses are free if you send me a dirty limerick featuring Tor in some way.  Contact me through the email given above or with a PM here. I mentioned this in a thread over in off-topic, but that's not really the right spot for a project announcement. Features: 1) Blindingly fast - 600MH/s vs. 2MH/s for shallot 2) Performs PKCS #1 v2.1 sanity checks via openssl's RSA_check_key function 3) FOSS - MIT licence 4) Support for 1024, 2048, or 4096 bit keys 5) Estimates time required to generate a key (on average) Check out the Github page: http://www.github.com/lachesis/scallionor skip straight to the binaries: https://github.com/downloads/lachesis/scallion/scallion-v0.9.zipIf you have any problems, reply to this thread or open an issue on github. Donations: 1onion1PNeM2x9LhdqWn6uVFyU2iSpy7M |
|
|
|
|
I'd like to suggest some really basic SEO:
1) Modify robots.txt to hide all URLs with "?action=printpage;" in them. These "Print Page" results often come up first in the Google search results, which kinda sucks because their formatting is far worse for screen reading.
2) Configure Apache to rewrite all requests to the forum's IP (174.143.149.98) to the official forum URL. These show up in Google results and often trigger SSL errors.
Just try searching for "bitcoin dnsseed" on Google to see what I'm talking about.
|
|
|
|
Hello, I'd like to buy a Feitian FTCOSPK01C ( http://www.gooze.eu/feitian-pki-smartcard-ftcos-pk-01c) from Gooze. Unfortunately, under French law, they're not permitted to export these cards from the EU. Since I live in the USA, this means I can't buy it. So, I'll offer enough BTC to cover the cost of purchase, VAT, shipping to your residence, shipping to my residence in the US, and another few Euros worth for your time and hassle. From what I understand, it's perfectly legal for citizens of some other EU countries (Germany) to export this crypto hardware, but IANAL. You accept all legal risk associated with this. Additionally, please ship with insurance. If I do not receive the product, I will not pay you the BTC. It should cost around €13,80 to get the product shipped from Gooze to anywhere in the EU. I don't know how much it costs to get shipped from your country to the US. Please provide me with a quote in your reply. I have a good rating on Gribble (lachesis on IRC as well as here). As such, and owing to the time-delayed nature of this transaction, I'd like to keep my BTC until I actually receive the smart card. We could also use clearcoin or similar if you'd like. You pay any escrow fees. I'm flexible with regards to quote time. That is, I can guarantee the number of Bitcoins that you'll receive when I get the smart-card beforehand if you'd like, or we can wait until I actually get it to determine this amount. Obviously if you expect Bitcoin to go up in value, you want a quote now, but if you expect it to drop, you want one at the end. Thanks, Lachesis -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iF4EAREIAAYFAk3sRPEACgkQM9Zg6f/HQg27GQD+MveYiyCZBsWn1qZHd8PO5YYh EOEQXOhrqh7xWtq7o1IBANADH8+lvCyMBdmYU+Rn5QwHmbguXDqlzhmZ7jNgwiwS =Vb5E -----END PGP SIGNATURE----- |
|
|
|
I noticed from a hint that Satoshi dropped in the JSON-RPC password thread about so-called "Multiple Invocation" support in Bitcoin's JSON-RPC. As I run a site that polls bitcoind for payments to a large number of addresses twice a minute, I was intrigued. First of all, this isn't JSON-RPC 2.0's "Batch" support, where requests are submitted in an array and responses are received the same way: request = [
{"jsonrpc": "2.0", "method": "sum", "params": [1,2,4], "id": "1"},
{"jsonrpc": "2.0", "method": "subtract", "params": [42,23], "id": "2"},
{"jsonrpc": "2.0", "method": "get_data", "id": "9"}
]
response = [
{"jsonrpc": "2.0", "result": 7, "id": "1"},
{"jsonrpc": "2.0", "result": 19, "id": "2"},
{"jsonrpc": "2.0", "result": ["hello", 5], "id": "9"}
]
Instead, it's something different, and I can't figure out how to parse the responses in Python. Here's a screen capture of a telnet session to the Bitcoin RPC server: $ telnet localhost 8332
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
POST / HTTP/1.1
Content-Type: text/plain
Content-Length: 97
{"params":[],"id":1,"method":"getconnectioncount"}
{"params":[],"id":2,"method":"getdifficulty"}
HTTP/1.1 200 OK
Connection: close
Content-Length: 33
Content-Type: application/json
Date: Sat, 08 Jul 2006 12:04:08 GMT
Server: json-rpc/1.0
{"result":8,"error":null,"id":1}
HTTP/1.1 200 OK
Connection: close
Content-Length: 49
Content-Type: application/json
Date: Sat, 08 Jul 2006 12:04:08 GMT
Server: json-rpc/1.0
{"result":181.5432893640505,"error":null,"id":2}
Connection closed by foreign host.
As you can see, the server replies with two complete HTTP 200 responses instead of (as I would have expected) one response with the two lines concatenated as I did in the request. I can't figure out how to parse that with anything at all semi-automated in Python. urllib2 and httplib both return after the first response and drop the second one on the floor. Has anyone encountered this problem before? Does anyone know of a Python library that can handle this strange multi-request behaviour? |
|
|
|
Hello all, I've made a patch against svn-r102 that adds three RPC methods: ListGenerated [pendingOnly=false] Returns a list of generated transactiosn. If pendingOnly is true, includes only accepted but not yet matured transactions. Here's an example output: [ { "value" : 50.00000000000000, "maturesIn" : 0, "accepted" : true, "confirmations" : 8184, "genTime" : 1275586091 }, { "value" : 50.00000000000000, "maturesIn" : 0, "accepted" : true, "confirmations" : 7545, "genTime" : 1275963218 } ] I released a similar patch is the past, but this one is finally production-quality. I also added two more functions: gethps and getkhps Those just return the hash rate and the hash rate / 1000. getkhps was also added as a key in getinfo. Anyway, this patch can be downloaded at: http://www.alloscomp.com/bitcoin/patches/bitcoin-svn-102-rpccalls-2010-07-14.patchIf you're using Linux x86_64, you can try out my binaries at: http://www.alloscomp.com/bitcoin/binaries |
|
|
|
|
Bitcoin has obviously outgrown the initial experiment stage. It's getting robust and has gained at least 400 clients today (according to the counts in #bitcoin on LFnet). As a result, it needs to grow some new features.
1) Bundle the first 80% of the blocks with the client download!
It really hammered the network to slowly distribute the blocks, and a lot of people talked about how annoying a problem this was for new users.
2) Disconnect from the IRC when the outside port (8333) isn't connectible.
We gain NOTHING by having Bitcoin idle on the IRC channel when nobody can connect to it, and we hit the server harder and annoy privacy-minded people.
3) Allow different ports than 8333 and 8332.
Right now, it is trivially easy to block Bitcoin at a network level, and nothing has used fixed ports since BIND. We can do better.
4) Allow exporting the wallet for backups.
People might actually backup then!
I'm sure there are others, but those are my top four. This is based upon participating in the chat in #bitcoin-dev. The other request was to drop wxWidgets from the daemon, but having read the code, that seems like too much trouble to do now.
I'm sorry if this post sounded harsh, but these are some nice (and fairly simple) things to do to make Bitcoin more new user friendly.
|
|
|
|
|
I'd like to see an option (with an RPC interface as well) to limit the number of connections that a Bitcoin client accepts. My home client is connected to 70 different nodes and my poor wimpy router just can't keep up. It's starting to slow my network down, to the point where I'll need to force Bitcoin to ignore connection requests (with -connect=<a node>) if this keeps up.
A connection limiting option would be a great alternative.
|
|
|
|
|
Hello all,
I'm looking to buy a relatively new 4GiB flash drive to use as a root device for a Debian machine that I'm building. Anyone interested?
|
|
|
|
|
A mathematician friend of mine pointed out that there are very few if any hash protocols that have survived for 10 years or more. What would Bitcoin's solution be if SHA256 were to be cracked tomorrow?
|
|
|
|
|
I think a nice feature would be the ability to keep multiple Bitcoin "accounts" in your wallet.db. Perhaps one account for spending money, one to save for your monthly payments, etc etc. You would then be able to choose what account each receiving address fed into.
It would be nice for people like gavinandresen who is running [link=http://freebitcoins.appspot.com/]The Bitcoin Faucet[/link] or casino operators. That way, the casino's "bank" or faucet's "tank" or whatever could be kept separate from other coins in the same wallet.
|
|
|
|
|
I can't build r80 from the SVN with -O2 in the makefile. I'm running Ubuntu 10.04 LTS 64-bit on an Intel Core 2. If I remove -O2 (switch back to -O0), it builds fine.
The problem seems to be line 15 of net.h. My googling suggests that statement-expressions, some non-standard, GCC-only extension to C++, are not allowed outside of functions at that level of optimization. htons is implemented as a statement-expression for linux. I managed to get it to build by replacing the htos(8333) with 0x8D20, which is 8333 in network byte order. This compiles and runs fine on my Intel processor, but probably wouldn't work on a big endian processor like a PowerPC.
Is anybody else experiencing this bug?
Also, I'm somewhat disappointed. -O2 didn't help me generate hashes any faster. Perhaps I'll try -O3.
|
|
|
|
Hello all! This thread is exactly what the title says: a place to post about the node(s) that you are running, including their performance and hardware. To find out your performance, you'll need to build from source with laszlo's patch. The performance in hashes / second will be listed in the UI where it used to say "Generating..." and will spam your debug.log. I'm currently running Bitcoin on three machines (and I tested it on a fourth, but that one is for a business, so I can't keep it running). My Workstation Specs: HP HDX 16t - 16" laptop Intel Core 2 Duo P8700 (x64) @ 2.53GHz w/ 3072KB cache 4GiB DDR2 RAM nVidia GeForce GT 130M (OpenCL needs to get its act together!) Ubuntu 10.04 LTS 64-bit (2.6.32-22) Performance: **Perf - thread 3 : 446k iter/sec **Perf - thread 4 : 451k iter/sec **Perf - total : 897k iter/sec (2 threads) My Home Server Specs: 1400MHz Intel Celeron w/ 512KB L2 Cache 512MiB of (ancient) RAM Debian testing 32-bit (not sure the kernel version) Performance: **Perf - total : 169k iter/sec (1 threads) Puny!  My Xen VPS Specs: Not 100% sure about this, but it's using 4 cores. 256MiB of (fast) RAM Ubuntu 10.04 LTS 64-bit (not sure the kernel version) Performance: **Perf - thread 1 : 436k iter/sec **Perf - thread 2 : 410k iter/sec **Perf - thread 3 : 419k iter/sec **Perf - thread 4 : 429k iter/sec **Perf - total : 1694k iter/sec (4 threads) So, anybody else? |
|
|
|
|
