The post is old, and I've not seen this issue since a quite long time.
Guess it has been fixed in most recent client releases.
Ehm, I forgot to give you the deserved credit for the script, looks very nice  Thanks! And: the issue ( https://github.com/bitcoin/bitcoin/issues#issue/48) is not solved. There's new comments now. BlueMatt looked into it and we chatted a bit yesterday on #bitcoin-dev. It seems it will need some serious debugging. I'm trying to help him as much as I can (testing). |
|
|
|
sooooo if you dont use the pool anymore...... may i have your login for the pool!?  Wait untill tomorrow, please I'm assuming this means you're reopening signup soon? If not: would you be opposed to me lending my account to someone? |
|
|
|
Heck, the hashing rate of the network is doubling 27 days for the past 15 months. Don't under-estimate the propensity of geeks to throw hardware, sweat and reputation at wild and woolly ideas and 1 in a 10,000 bets ... it happens in college bars every weekend night. Bitcoin is a bit like going to a Swiss private bank and being attended by a punk sporting facial tattoos and a ripped anarchy t-shirt. +1, classic. This quote needs to go into a cartoon or similar ... a "not your grand-daddy's money" kind of meme (quite powerful seeing as grand-daddy's money has failed) Not directly related, but I actually thought about giving a group of punks on the street a large amount of bitcoin somehow (like give them a private key and the word "bitcoin" on a piece of paper and the words: "this is a lot of money") and then watch what happens... maybe document it somehow. This crowd should really love bitcoin, because when they say "fuck capitalism", they dont necessarily mean money per se. Wonder how long it would take until they have a big party going payed for by bitcoins. |
|
|
|
I like to imagine that we're in a beginning of a exponential take-off.
Me too. Heck, the hashing rate of the network is doubling 27 days for the past 15 months.
Hehe, I don't want to see exponential growth on that variable so much. I rather want to see it on mtgox and the amount of stuff being offered for bitcoin. We don't need miners, we need users/dealers/consumers... the miners will inevitably follow. |
|
|
|
Also, I have to wonder how many non-technical people just will not be able to accept that bitcoin could work at all. If you don't understand the cryptography then you have to take it on faith that the system could work as designed. It's easy for them to brand bitcoin advocates as kooks (see "Time Cube").
Unfortunately its still not proofed if it works (NP=P) . So even the technical people cant be really sure  Good point. But (at least at this stage), if P prooves to be equal to NP, we got other troubles on our hands. |
|
|
|
You could probably build one for a little cheaper, not much, though. maybe 2000 BTC.
I built my dual dual 5970 setup for ~800. How? One 5970 costs $600 last time I checked. Let alone two of them! |
|
|
|
cool! I don't use the pool any more, but still I love this. I noticed a problem, though (chrome): changing any of the settings (except reload) reloads the page. so far so good. unfortunately after the reload, the setting is back to default value and not active (can't see mhash/s, for example) Can I fix this somehow? |
|
|
|
You could probably build one for a little cheaper, not much, though. maybe 2000 BTC. |
|
|
|
Need help from a math wizard. My goal is to make $10000 per year supplemental income by mining bitcoins. My cost per kW is $0.10. What kind of investment do I need to make to create this much money? How long will it take to recoup the investment and start generating income?
I faced a similar problem in January before I started mining. My goal was to merely break even some time and have some fun in the community, building the hardware and mining (latter part worked out) I simply made an excel "simulation" sheet with one line every 2 weeks and entered starting values into the 1st line and formulas to go from one line to the next. Worked fine. The problem with all this is: you need to "guess" 2 values over time: the difficulty and the exchange rate. I completely underestimated difficulty growth. Calculated 20% every 2 weeks. Now look for yourself at http://bitcoin.sipa.be/speed-lin-10k.png to see what really happened  . (I started in mid-Jan) Fortunately I also underestimated exchange rate growth, so that I just about could get my investment back if I exchanged my BTC to EUR now. If you dont care about strengthening the network, you could just buy bitcoin, the price is currently rather low. If I had invested the €600 euro into bitcoin back when I started, I would now have made a profit of around €1000. But note: that's pretty much a gamble and I'm not giving investment advice here. On the other hand: your power cost is pretty low. I expect a lot of hardware will be sold when earnings are less than power cost in the more expensive places (germany: $0.3). You could buy hardware then. But to make BTC 5000, you'll need a lot of 5970s. If you project the 2 values (exchange rate and difficutly (need a function over time here, or a growth rate)) for me, I can make you a nice calculation on how much hashing power you would need to reach your goal. |
|
|
|
It is possible (albeit rare) that you found a block but within seconds somebody else also found a block and he transmitted it to more nodes (or not necesseraly more but the node that found the next block) and "won" the race of including it in the blockchain. It's also possible the the network connection to the outside world was down at the time and your bitcoin daemon hasn't transmitted the block you found. I checked my logs and it appear it's a former case. My bitcoin received your block but also the competing one: http://blockexplorer.com/block/000000000000a3f568a8da7609081b020d13a19bb77ca59df0141148330d9aa1The competing one was the block that the next miner included and you lost the race. Analyze the debug.log of the bicoin daemon you are running but I'm afraid you were very unlucky. Oh man, this makes me sad. This guy actually found a block (should take him 17 days to find one at 150Mh/s) and he got beaten to it  |
|
|
|
I wrote a little bash a while back, because I'm on a dynamic ip connection and bitcoin doesn't behave so nicely with changing IPs. (see https://github.com/bitcoin/bitcoin/issues#issue/48 for more info (while the gui still displays connections, the node may in fact be disconnected)). Since I still wanted to mine solo, I wrote this script. I've been using it for 6 weeks now, have been mining solo using it for 2 weeks now without problem and I thought it's ripe for sharing: http://pastebin.com/tFJwFwnsIt works by comparing an "official blockcount" (e.g. from blockexplorer.com) with the local one from rpc interface. To use it, you should check/edit some variables at the beginning of the script: BITCOIN_BIN, PING_HOST and OFFICIAL_URL Then just go ahead and run it. If you want, you can also adjust some timing variables. Feedback is welcome, also symbolic (0.01 BTC or so) donations to the address in my signature are of course appreciated and also good for your karma
|
|
|
|
First, thanks for answering. Unfortunately, I'm even more confused now ;( Now 2 things strike me as odd:
1.) targetH is passed as 0xffff0000 (BitcoinMiner.py around line 293). why not 0? doesn't H have to be 0 even for a difficulty 1 block?
2.) (parts) of the calculation of G is commented out in the kernel code (likely to save some cycles, assuming that G is not going to be needed)...
...but G is used in the solution condition. So since G is some intermediary value of sha256 and targetG is 0, why does this even work?
1.) Excuse me for this mildly obfuscated code. target[0] and [1] are actually A and B of original target - I'm using them just to pass a made up 32 bit target. Why are you passing a made up 32 bit target (0x00000000ffff0000)? If you look at kernel parameters you'll see that target[0] (0xFFFF0000) is passed as G.
It's passed as Parameter number 16, which is in BitcoinMiner.cl, "targetG", no? Or what do you mean by "passed as G"? 2.) G is used in belowOrEquals because I didn't managed to understand why this leads to better/faster assembler I left it there wondering when someone will ask this question. So you're saying that "targetG" is in fact the 2nd-last value of the real target or is it 0xffff0000 or what is it and why does it work at all comparing that to some G that is not even the 2nd-last value of the hash? |
|
|
|
emansipator: thanks so much for summing up that crazy thread! you saved me hours! as for my trust in Mt.Gox: yes, I trust him quite a bit. He's responsive to email and the money I wired him once showed up in my account on time. I actually trust him more to not rip me off than I trust my traditional bank, which I know is ripping me off |
|
|
|
I've been looking at code and now I'm confused, maybe someone can help me out: At the end of BitcoinMiner.cl (the kernel) there's a condition for outputting a solution candidate: if (belowOrEquals(H, targetH, G, targetG))
Now 2 things strike me as odd: 1.) targetH is passed as 0xffff0000 (BitcoinMiner.py around line 293). why not 0? doesn't H have to be 0 even for a difficulty 1 block? 2.) (parts) of the calculation of G is commented out in the kernel code (likely to save some cycles, assuming that G is not going to be needed)... //W13 = W13 + (rotr(W14, 7) ^ rotr(W14, 18) ^ (W14 >> 3U)) + W6 + (rotr(W11, 17) ^ rotr(W11, 19) ^ (W11 >> 10U));
//C = C + (rotr(H, 6) ^ rotr(H, 11) ^ rotr(H, 25)) + (B ^ (H & (A ^ B))) + K[61] + W13; G = G + C;
//G+=0x1f83d9abU;
...but G is used in the solution condition. So since G is some intermediary value of sha256 and targetG is 0, why does this even work? I'm clearly missing or misunderstanding something and I would be happy if someone took the time to explain what's going on. |
|
|
|
My thoughts exactly...the value of a transaction has no bearing on the cost to process it...so valuein has should have no bearing on priority. I think the winning formula is to base priority on a combination of age, fee, size, and time since the last transaction involving one of the accounts in the transaction (to deal with the spam issue). That last one should be carefully tweaked to better deal with the recent delay issues experienced with slush's pool. This priority would govern the forwarding behavior of the clients. In addition, clients should factor this priority calculation into the decision on whether or not to accept blocks. Blocks that seem to be grossly out of alignment with these priority assessments should be treated with great suspicion.
The value of a transaction does have bearing. People are far less likely to spam using 10000 BTC transactions. Faster confirmations for bigger sums encourages use of bitcoin for larger amounts, which is always a good thing for the economy. And as ArtForz pointed out, it encourages sending larger amounts per tx, which implies less block chain size for the same volume of currency flow. Less likely, but, I wouldn't completely discount the possibility. The fee has the same effect though. If adding a fee gets faster processing, and you want faster processing, then you pay the fee right? Well, if you want to jump the queue with smaller values, thats fine but that means the fee will be a larger percentage of your total value. I think I agree with carp on this point. After all, the amount in a spam transaction is not lost to the spammer, he can just self-send it. The fee however is lost to him. I'm still not convinced we should remove amount from priority calculation, although I can't seem to find a good reason against it. After all, we're not trying to maximize volume, are we? The goal is "merely" to have transaction processing that is effective and cost-efficient enough for users. |
|
|
|
Can we make it easier to create multi-output txn for peole like slush to distribute to large lists?
I'm quoting from #bitcoin-dev: ArtForz> hmmm... doesnt look like adding a rpc interface to send to multiple outputs simultaneously would be too hard
ArtForz> looks like the cleanest way woudl be to extend CreateTransaction so it takes a vector of (scriptPubKey, nValue) pairs
sipa> i was thinking exactly the same
|
|
|
|
I don't agree with eliminating free transactions...in fact, I believe the likely trajectory of things is that transactions will be remain free (I mean just look at all the unprofitable mining that's happening now). Merchants, exchanges and many others have an interest in facilitating transactions and will always step in to ensure they get processed, even the free ones. In fact, everyone using bitcoins has an interest in free transactions. It's a good selling point and a way to attract new users (and without new users, this experiment will fail).
Point taken. A question: What would happen if we removed all special handling of "free" transactions, but still allow transactions with fee == 0.00 and somehow include the fee into priority value calculation (iirc fee is not part of that atm, it's currently "sum(valuein * age) / txsize"). Maybe "sum(valuein * age) * fee / txsize"? In the current situation this might be better, because there's actually still space left in the blocks, just no "special space for free tx". So the network is not living up to it's transaction processing potential. If this is true (I might be missing something, though), this suggestion should actually be in your "tx should remain free"-spirit, because it gives more room for free transactions, right? Another thought: I see in the code that after calculcation of priority value for each transaction, the dependencies of the ones that are included are pulled in. What about packaging transactions into groups by dependency first and then calculating priority values for these groups instead of single transactions? Would that change anything significantly? |
|
|
|
|
Digesting all comments, maybe this could a workable consensus:
1.) remove "free transaction space" altogether. Argument (by many): free transactions are not going to make it in the long run anyways, where probably never intended to. This would generate a market for transaction processing by miners, which was intended from the beginning and will be their main income after generation ends. Regarding the pool issue: This moves the problem to the originator (where it belongs): the pool-miner receiving very small payments has to either pay the price by using higher tx-fee to spend it or avoid the problem by increasing his payout treshold. This also mitigates DoS attacks.
2.) make smaller transaction fee (down to 0.0001) possible. Argument: 0.01 might be too much as minimum fee. There are poor people.
3.a) Client should also warn about low priority transactions and suggest a fee to increase chance for inclusion.
3.b) Make it possible to increase transaction fee of an already broadcast transaction. Argument: this would obsolete 3.a) and introduce transaction fees to users in a nice fashion (user sees transaction not being confirmed, user sees the fee is 0.00, some gui hint tells him he can speed things up by increasing fee)
4.) Let existing backlog trickle in slowly, don't automatically expire or allow reclaiming of transactions in any way. Argument (by Steve): Expiring transaction would open up the possibility of clients deliberately crafting transactions to fail (in order to get something for nothing)
|
|
|
|
Hey man, got your message on github, but for anyone else reading I got a protocol implementation, for android, with crypto, open source, with the aim of implementing a full android client, here: https://github.com/dirtyfilthy/bitcoin-walletConstructive feedback/criticism greatly appreciated. where should I point my feedback? I'm missing build instructions... no build.xml? |
|
|
|
The mining stats are delayed by two hours, among other things. Yeah, I see that now (noob). But was actually wondering if it is possible to get a PROOF OF WORK RESULT for an unsuccessful block, i.e. one not credited to the pool, does that sense? Currently, no, that's not possible. The pool will calculate reward based on shares commited per round. A round starts when a block was found and ends when the next one is found. Therefore, currently every share (PROOF OF WORK RESULT) you find counts and generates a reward for you. |
|
|
|
|
Show Posts
