|
My only comment is to make sure that the user is informed in some way that they must absolutely not lose the password, or they will be unable to recover their money. That there is nobody who will be able to recover their money. Unless that's made absolutely clear, I fear that users will inevitably bitch on the forums that they lost their password and ask why we can't recover it. "I mean, PayPal has a forgot password link, why don't you?"
|
|
|
|
I've been rolling around several algorithms for processing transactions in a robust way and have had several ideas, none of which were very good. Last night I talked about them in #bitcoin-dev and got some good feedback, and I think I've arrived at one that will work well and require only one minimal change to bitcoind. (In fact, I have already made it and tested the patch.) The problem is how to reconcile transactions received by bitcoind with the state in another database, without even the possibility of missing a transaction or processing the same transaction twice. This solution takes into account that a previously-processed transaction can be removed from the block chain and re-inserted into another block later, if the bitcoind discovers that another, stronger chain exists. To support this detection, bitcoind must be modified to include the block hash in listtransactions output. Let me explain the process. First, you must have some table where you store processed transactions. The table should contain bitcoin transaction ID and block ID (hash, not sequence number) columns. Then, you poll bitcoind periodically like so: - Request the last N transactions, where N is an arbitrary number.
- Walk the returned list backwards (most recent transaction first) looking for transactions that you consider confirmed (1 or 3 or 6 confirmations, or whatever your requirements indicate). For each transaction:
- Look up the transaction ID in your transaction table. If it does not exist, this is a new transaction; process it and insert the transaction ID and block ID into the table. (Using transactions, of course, to force the processing to be atomic.)
- If the transaction ID does exist, compare the block hash in your table to the block hash in the transaction returned from bitcoind. If they match, then you have processed all new transactions and should now terminate/return. If they do not match, this is a transaction that has been processed already, but has been moved into a new block due to orphaning of the original block you saw the transaction in. Update the block hash ID in the table and continue processing, since it's possible that a new transaction still exists prior to this one in the block chain.
- If you reach the beginning of the transaction list then you haven't found any transaction that you've already processed and that has the correct block hash. Increase N (add something to it or multiply it by something) and start the whole process over.
I believe this to be the simplest process that will correctly account for any changes in the block chain. If you can see a problem with this algorithm, or a way that it can be simplified (especially if changes to bitcoind aren't necessary) please let me know. |
|
|
|
i only get an xml-parsing error when trying to access /admin/ XML Parsing Error: XML or text declaration not at start of entity
Location: http://blah/admin/
Line Number 2, Column 1:<?xml version="1.0" encoding="UTF-8"?> guess it's just a blank line hiding somewhere, but i can't find it. Yeah, there's definitely a blank line being output prior to the XML header. I don't see the same behavior on my install, in fact the dashboard validates as XHTML strict (as should every other page, but I just checked the dashboard right now and it validates). I can't find anywhere in the code where the blank line would be getting written. |
|
|
|
When I connect Phoenix, it tells me 'failed to connect, retrying'. When I examine my apache error log, I see this:
[Fri May 06 01:30:05 2011] [error] [client xxx.113] PHP Notice: Undefined index: lpurl in /home/rrb/bitproxy/index.php on line 70
This notice is expected. PHP likes to whine if you access array keys that aren't defined, but it's impractical to always check if they're set first.  [Fri May 06 01:30:05 2011] [error] [client xxx.113] PHP Notice: Undefined variable: http_response_header in /home/rrb/bitproxy/common.inc.php on line 117
This is a bit troubling, as $http_response_header is a reserved variable. Which version of PHP are you using? Did you make sure to enter "http://" at the beginning of each pool URL? (Something like "deepbit.net:8332" will not work; you need " http://deepbit.net:8332".) You may also get this error if the HTTP host can't be reached at all, for example due to a DNS lookup failure. [Fri May 06 01:30:05 2011] [error] [client xxx.113] PHP Warning: Invalid argument supplied for foreach() in /home/rrb/bitproxy/index.php on line 215
This is related to the previous issue; fixing it should make this one go away. Additionally, you might find this of interest. When I hit the admin url, the admin interface seems to work fine but merely hitting /admin/ throws the following into the apache error log:
[Fri May 06 01:31:15 2011] [error] [client xxx.252] PHP Notice: Undefined index: format in /home/rrb/bitproxy/mvc.inc.php on line 38
[Fri May 06 01:31:15 2011] [error] [client xxx.252] PHP Notice: Undefined index: tempdata in /home/rrb/bitproxy/common.inc.php on line 177
[Fri May 06 01:31:15 2011] [error] [client xxx.252] PHP Notice: Undefined index: tempdata in /home/rrb/bitproxy/common.inc.php on line 177
Yes, this is PHP being picky again. You can ignore these. 1) In your database schema, in the worker_pool table, the type for the 'enabled' field is a tinyint and should be boolean it looks like, unless you have some special state info to store that's not 0 or 1?
MySQL does not have a real boolean type; BOOLEAN is an alias for TINYINT(1). 2) I discovered #1 while attempting to go back and edit the workers and pool info that I'd setup the first time, in an effort to debug what was happening with the behavior I reported above. While using the various "edit" dialogs, I'm hitting blank pages being returned, i.e. in the "edit pool" dialog at http://xxx/admin/pool.php?id=1&action=edit - it returns nothing in View Source as well. Hmm, this is almost certainly a bug. Can you edit other pools, or is it just this one? Does anything show up in the Apache logs when you hit this page? Having said that, and after editing the databases by hand (because it looks like I had the port number to the pool AND my login credentials entered incorrectly), I got further with the miner now (I'm guessing before it would not connect because the credentials at the pool were incorrect. Here's what happens now:
[06/05/2011 03:18:17] Connected to server
[06/05/2011 03:18:23] Disconnected from server
[06/05/2011 03:18:23] Result: 5b433c62 rejected
[06/05/2011 03:18:24] Connected to server
[06/05/2011 03:18:26] Disconnected from server
[06/05/2011 03:18:26] Result: 9e17d0db rejected
[06/05/2011 03:18:27] Connected to server
[06/05/2011 03:18:31] Disconnected from server
My first instinct was to turn on keepalives in the webserver, I did so and set them to allow an unlimited number with a 30 second timeout, but it only prolonged the generation of the same errors by 10 or 20 seconds. In the end it still disconnected my client from the server. I tried m0mchil's miner with similar results:
06/05/2011 03:25:22, Unexpected error:
Traceback (most recent call last):
File "BitcoinMiner.pyo", line 141, in mine
File "BitcoinMiner.pyo", line 168, in sendResult
File "BitcoinMiner.pyo", line 177, in getwork
File "BitcoinMiner.pyo", line 204, in request
TypeError: string indices must be integers
248779 khash/s
This after running 10 to 20 seconds also. Not seeing anything in the logs that would give me any indication of the problem. Without cranking up a sniffer, I'm out of ideas; any suggestions?
This is definitely weird. I use poclbm without any issues, so you should be able to use it too. I'm mostly worried about the rejected shares in the first example. Were all shares rejected or just those two? Using a sniffer might be a good idea, since it's hard to tell just from these logs exactly what's going wrong. |
|
|
|
Thanks for the release! I'll dedicate some time to pulling and installing it tomorrow, and pass that money along once it's up. After all, a promise is a promise Thanks again. Cool, thanks! Hope the software works for you. If you run into any trouble, let me know. I intend to support the software I publish. (That goes for everyone.) |
|
|
|
Hah, just found this thread. Thanks again for the opportunity to participate. I had fun trying to remember my image manipulation skills. |
|
|
|
Alright, I've cleaned up the repo and finished adding the final touches (for now...). Grab the code: https://github.com/cdhowie/Bitcoin-mining-proxySetup directions are in the INSTALL file. Please read the whole thing before asking questions; I took a long time writing it and proofread it several times to make sure it's complete and correct. Let me know if anything is unclear or broken. And please feel free to use GitHub's issue tracking to report issues. If you like the software and find it useful, there is a GPG-signed Bitcoin address on the about page where you can send donations. Any amount would be appreciated. For those interested in reliability information, I've been running one miner against it consistently for a full month, and a few other miners against it sporadically. The getwork proxy has always worked 100% for me in my deployed copy, except during power failures.  @pwnyboy: Thanks for offering the bounty! I was already getting it ready for release when you posted, so you don't have to send the bounty if you don't want (since it really wasn't responsible for motivating me; I just finally got off my lazy butt since everyone's been waiting for it). But I won't turn it down either. If you still want to send, feel free to use the donation address. |
|
|
|
|
How are you transferring the games to the buyer? Are you proxy buying, or do you have game keys, or...
|
|
|
|
You must be new to Free Talk Live. Ian has said many times that you can redistribute, remix or do whatever you want with the show content.
Newish, yeah. I've been listening for a few months, but not consistently -- it's on at 8PM here, so I only really listen when I'm late leaving work. But yeah, Ian already sent me an email to this effect, so I will be posting edited audio later today. |
|
|
|
Hey I just listened to the show and you did a good job explaining it imo.
Cool, thanks. I've emailed the show for permission to post an edited version here as well as on my blog, so if it's all ok with them I will post a link to audio of just the Bitcoin-related content here. |
|
|
|
Yesterday (May 3rd), Bitcoin came up again as a topic of conversation on Free Talk Live. You can download the show and give a listen if you want. I called in around 1:20:00 to address Ian's reservations about Bitcoin addresses, which I hope were adequately explained. Technical details were less important than the general idea, so some statements in my explanation were not technically correct, but I was trying to keep it short and understandable. Ian, if you're reading this, thanks for the opportunity to explain Bitcoin just a bit more. I enjoy talking about things I like, and I had fun on the air. Maybe I'll call in again sometime to clarify more details about Bitcoin's operation if the subject arises. |
|
|
|
Bump. Surely someone wants to pay for WoW game time using BTC!
Maybe when my current time is up in a couple of months. Ok. Also, bump. I've added Zynga cards, lowered my fees, and added an option for mailing the card. |
|
|
|
Did you ever post the git repository?
No, I have a backlog of projects I'm trying to get ready for release and this is one of them. |
|
|
|
I'll do it for free if you let me copy your wallet.dat wallet is completely empty, you can take it away if you wish  Just FYI, the client generates 100 key pairs in advance, for future use. So if someone copies your wallet file, they can spend money sent to the next N <= 100 addresses you give out to people. |
|
|
|
I'm having trouble connecting to mining.bitcoin.cz:80, chrome tells me ""
This has been the case for about 10 hours now, my ip is/was: 85.176.112.67
Weirdly enough, I can connect through tor (using exit 46.19.138.242)
Any explanation?
Can you try a TCP traceroute? I don't know if such a tool is available for Windows, but there is one for Linux. It will essentially do a traceroute with TCP packets by setting the SYN packet's TTL to 1 initially and incrementing it for every packet sent thereafter, in an attempt to discover where the traffic is really going (using the ICMP TTL exceeded errors to determine the path, similar to how regular traceroute works). This is an effective technique for discovering transparent proxies or other bizarre/evil things done by your ISP or any router between you and the destination. |
|
|
|
What's the value of a PS3 that has been smashed up, Office Space style? That's what I plan to do with it, so that's what I'm willing to pay.
At least take out the blu-ray player and hard drive first... the hard drive is SATA and the blu-ray player might be adaptable to a PC or resold as a spare. The rest is garbage. |
|
|
|
If they don't accept, then everybody will have their funds sent back to the originating address.
Addresses you mean? (One transaction can use multiple other transactions, which don't need to have any addresses in common...) |
|
|
|
how are sell orders processed when there are numerous offers @ same price
which offer is picked first?
I believe it's a first-in-first-out system. In other words, if multiple offers are present at the same price, it will use the first offer that was placed. (Or, if that offer would not complete your offer, it will take the first N offers.) |
|
|
|
|
+1 Distribution. Loaned BTC to him and he repaid as agreed, smooth transaction all the way around.
|
|
|
|
|
Bump. Surely someone wants to pay for WoW game time using BTC!
|
|
|
|
|
Show Posts
