|
I am interested in whether this pushpool of yours even supports Stratum. Pushpool by default doesn't, I've been thinking of implementing it, but the specifications are a bit lacking.
|
|
|
|
|
You have a few very small outputs and a very small fee. It is possible that apart from the fact that it's not in any miner's memory pool, that they also didn't like the low fees.
|
|
|
|
|
It's simply easy enough to block mtgox.org via the hosts file on Windows. It should be relatively easy to do under Linux as well.
|
|
|
|
|
Don't know who I'm looking at, but the woman seems very familiar to me.
|
|
|
|
bitcoin-qt 4.8.3 ?? Current version is 0.8.1
*grins* that's the QT version, a library used by bitcoin-qt.
You're using the old client, everybody had to upgrade on May 15!
oh yeh. I'm using 0.8.0-beta I did upgrade after the fork. I upgraded too 0.8.1. Just as I suspected....it didn't work. I've read in different posts and I have to say, I'm damned confused and frustrated. I have thousands of dollars in that wallet. Where do I begin? I know it has to do with the thousands of bitvisitor deposits that I've had.... Yeah, dust transactions...bad for you. That doesn't help any. That's stupid that transactions are bad for you....damned stupid. So what do I do? I have $21,000 worth of bitcoins in the wallet, so I would appreciate some help before I have a heart attack. What if you try to send smaller amounts? |
|
|
|
bitcoin-qt 4.8.3 ?? Current version is 0.8.1
*grins* that's the QT version, a library used by bitcoin-qt.
You're using the old client, everybody had to upgrade on May 15!
oh yeh. I'm using 0.8.0-beta I did upgrade after the fork. I upgraded too 0.8.1. Just as I suspected....it didn't work. I've read in different posts and I have to say, I'm damned confused and frustrated. I have thousands of dollars in that wallet. Where do I begin? I know it has to do with the thousands of bitvisitor deposits that I've had.... Yeah, dust transactions...bad for you. |
|
|
|
|
Yeah, I think I saw enough of scrypt. How about some SHA256?
|
|
|
|
|
Coin is dead...low difficulty at startup...and a pre-mine.
|
|
|
|
|
Same thing happened to me, but on the BitParking pool. The website was opening fine via a browser, but as soon as I point my miner to the pool, cgminer would not connect.
|
|
|
|
That address would actually take billions of years to generate, it's valid, but the creator most certainly doesn't have the private key for it. However, take a look at https://bitcointalk.org/index.php?topic=25804.0If you want to create an address exactly like that, sorry, I can't help you. |
|
|
|
|
As of Jan 03 2009, Satoshi mined the genesis block.
|
|
|
|
You really need to re-read the Bitcoin protocol.
The other thing to keep in mind, is that if that miner (who solved an "empty" block) had been working on a block that had transactions, then the nonce he found (by working on the "empty" block) wouldn't have been a valid nonce for the block with transactions. Therefore, you can't really compare that miner working on a "full" block vs. that same miner working on an "empty" block, since the more realistic comparison would be that miner solving that "empty" block vs. some other miner solving a "full" block later. As do you, along with some studies in probability and randomness. Assuming that we are both talking about the same thing here, I'm pretty confident in what I'm saying. I suspect that our disagreement stems from each of us discussing a different scenario without realizing it. Otherwise, you need to re-think what you are trying to say. Obviously a block with transactions and a block without transactions will have different merkle roots. The merkle root changes very often. |
|
|
|
If they are contributing a significant amount of hash power, then they will increase the difficulty at the next difficulty adjustment. This could delay those future transactions after the difficulty adjsutment, but at the current difficulty, they are not significantly delaying anything (no more than a fraction of a second).
I'm not talking about additional hashing power. Assume hashing power remains constant over time. On average a block is found every ten minutes. Some percentage of these block is empty. If it is 50%, we get a non-empty block every twenty minutes. If it is 0%, then we get a non-empty block every ten minutes. Empty blocks still add confirmations for transactions that are already in the block chain, but they add no first confirmations. Doesn't it follow that first confirmations are delayed even though block creation isn't? It depends on how much hashing power they are providing and how long they've been providing that much hashing power. Using your 50% empty blocks. If 1,008 of the blocks broadcast prior to the last difficulty adjustment were from the miner who is solving "empty" blocks, then the difficulty would adjust such that the rest of the network would only solve a block on average every 20 minutes for the next 2,016 blocks. This 20 minutes for a FIRST confirmation would exist even if the miner who was solving "empty" blocks stopped mining immediately after the adjustment. The 20 minutes for a FIRST confirmation would exist even if the miner who was solving "empty" blocks suddenly doubled his hash power immediately after the adjustment (and there for started broadcasting 66% of the solved blocks). You really need to re-read the Bitcoin protocol. Anyway, what you are describing is an attack whereby a miner with a lot of hashing power suddenly stops mining before the next difficulty adjustment, at which point when the new difficulty comes(which will be higher depending on the hashing power) then yes, it will be sort of as you say, but we aren't talking about that. |
|
|
|
While variance plays a huge role here, if we accept that a miner mines a block with only a coinbase tx, a user would need wait up to 10 more minutes, of course this means the miner of the next block needs to add include the said TX.
I keep telling you that this isn't true. I'm not sure how else to explain it. What a "0 transaction miner" does do is affect the future difficulty adjustment. This can delay the FIRST confirmation for future transactions after the next difficulty adjustment, by increasing the difficulty. It does not increase the amount of time for a FIRST confirmation at the current difficulty as compared to that "0 transaction miner" choosing not to participate in mining. And I keep telling you that you are wrong. A miner that mines only the coinbase tx still moves the blocks and doesn't delay the difficulty adjustment at all. Difficulty is adjusted every 2016 blocks. |
|
|
|
That's a good point, but it does affect the average rate of non-empty blocks per unit of time, doesn't it? And that does delay transactions a bit.
(no more than a fraction of a second). Transactions always get relayed to nodes regardless of whether blocks get solved or not. https://en.bitcoin.it/wiki/Block#What_is_the_maximum_number_of_blocks.3Fblocks just keep getting added to the end of the chain at an average rate of one every 10 minutes. While variance plays a huge role here, if we accept that a miner mines a block with only a coinbase tx, a user would need wait up to 10 more minutes, of course this means the miner of the next block needs to add include the said TX. |
|
|
|
I meant that it would take one confirmation longer, which on average is ten minutes. The calculations have to restart when a new block is found.
The calculations restart every time a miner calculates a hash that doesn't solve a block. That means that the calculations are already restarting more than 100,000,000,000,000 times every second. Think about the dice, and (assuming that you understand that when you roll a 1 on a die it has no bearing on how many more rolls until I roll a 1 on my die) you'll realize that the empty block is not delaying anyone else's blocks significantly. Re-read my posts. I said that blocks which have only a coinbase transaction delay the confirmation of new transactions. I know what you said. I'm telling you that they don't. You don't believe me, and I'm not sure how to help you understand this. No you don't understand. A transaction's FIRST confirmation is achieved when a miner includes the transaction in his block. |
|
|
|
I meant that it would take one confirmation longer, which on average is ten minutes. The calculations have to restart when a new block is found.
The calculations restart every time a miner calculates a hash that doesn't solve a block. That means that the calculations are already restarting more than 100,000,000,000,000 times every second. Think about the dice, and (assuming that you understand that when you roll a 1 on a die it has no bearing on how many more rolls until I roll a 1 on my die) you'll realize that the empty block is not delaying anyone else's blocks significantly. Re-read my posts. I said that blocks which have only a coinbase transaction delay the confirmation of new transactions. I've never said or implied that such blocks delay the finding of new blocks. |
|
|
|
Funny, if a Bitcoin developer worded the sentence in the same way you wouldn't have said that.
I'm not sure what you mean by that? This is why I secured my post by saying on average. It all depends on variance.
But the code in Bitcoin has been made so that blocks are found on average every 10 minutes.
Yes, in the same way that you'll roll a 1 on a six sided die every 6 rolls on average. But the point is, if you roll your own die and get a 1, it has no bearing on whether or not my next roll will be a 1. The fact that you "solved" a block before me, does not delay my ability to solve a block (ok, perhaps I'm delayed by a fraction of a second while I build a new block header, but it isn't enough of a delay to really matter as far as this discussion goes). I have not said anything about delays. Mining is random, yes. |
|
|
|
I think OP means that transactions don't get confirmed this way.
Sure, if zero transaction blocks are all we have. True, but if a block is found on avg every 10 minutes, and one is found but has only a coinbase transaction, then a user must wait an additional 10 minutes for his TX to confirm. OK, that's true.
No it is not. Block solutions are random. The fact that someone just found a block has no bearing on how long it will take to find the next block. The dice don't remember what the previous roll was. (And neither do the hashing functions). Funny, if a Bitcoin developer worded the sentence in the same way you wouldn't have said that. This is why I secured my post by saying on average. It all depends on variance. But the code in Bitcoin has been made so that blocks are found on average every 10 minutes. |
|
|
|
There's nothing wrong with blocks that only contain a coinbase transaction, they still add proof of work to secure the block chain.
I think OP means that transactions don't get confirmed this way. Transactions from previous blocks do get confirmed this way. mmeijeri is correct. Yes, but new ones won't. |
|
|
|
|
Show Posts
