Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool - page 644. (Read 2591928 times)
September 08, 2012, 08:44:28 AM
Thanks. The setup would probably be different enough that it wouldn't gain me anything anyway.
September 08, 2012, 07:49:36 AM
I have two jalapenos on pre-order and was wondering if it would be a waste of time to go ahead and try to get set up using cpu mining just to have the set up partly done when the jalapenos get here (if they ever do, that is)? For one thing, I wouldn't want to do anything that would negatively impact the pool. I realize I probably wouldn't get ANY bitcoin from it. Please excuse me if this has already been asked.
I would not use CPU mining.
M
September 08, 2012, 07:11:28 AM
I have two jalapenos on pre-order and was wondering if it would be a waste of time to go ahead and try to get set up using cpu mining just to have the set up partly done when the jalapenos get here (if they ever do, that is)? For one thing, I wouldn't want to do anything that would negatively impact the pool. I realize I probably wouldn't get ANY bitcoin from it. Please excuse me if this has already been asked.
September 08, 2012, 02:48:30 AM
i have more to point towards p2pool--> about 4 GHs!
Wanted to try first, to understand how it works
Yes, it is working correctly.Wanted to try first, to understand how it works
On current pool rate you should get share about every 3hrs (using 250MH power).
If you want point more miners to your pool on local network just point miners to http://ip.of.your.node:9332, just be sure that you have port 9332 open.
Also try open port 9333 for incoming connection to get faster info about p2pool shares and new bitcoin blocks.
September 07, 2012, 11:46:53 PM
i have more to point towards p2pool--> about 4 GHs!
Wanted to try first, to understand how it works
Wanted to try first, to understand how it works
September 07, 2012, 06:53:31 PM
im trying p2pool now
I have sucessfuly installed it on my win 7 machine and im pointing 200MH/s to it.
How do the statistics work? They are not displaying anything atm? (Does this need time?)
I want to use P2Pool, bitcoind and my miner on three separate machines. HOw can i get this to work?
What does this mean? is it working properly?
Thx for hlp
I have sucessfuly installed it on my win 7 machine and im pointing 200MH/s to it.
How do the statistics work? They are not displaying anything atm? (Does this need time?)
I want to use P2Pool, bitcoind and my miner on three separate machines. HOw can i get this to work?
Code:
P2Pool: 17433 shares in chain (17222 verified/17437 total) Peers: 10 (0 incoming)
Local: 250MH/s in last 10.0 minutes Local dead on arrival: ~0.0% (0-10%) Expected time to share: 2.9 hours
Shares: 0 (0 orphan, 0 dead) Stale rate: ??? Efficiency: ??? Current payout: 0.0000 BTC
Pool: 277GH/s Stale rate: 6.7% Expected time to block: 11.6 hours
New work for worker! Difficulty: 0.999985 Share difficulty: 591.506619 Total block value: 50.511625 BTC including 622 transactions
Local: 250MH/s in last 10.0 minutes Local dead on arrival: ~0.0% (0-10%) Expected time to share: 2.9 hours
Shares: 0 (0 orphan, 0 dead) Stale rate: ??? Efficiency: ??? Current payout: 0.0000 BTC
Pool: 277GH/s Stale rate: 6.7% Expected time to block: 11.6 hours
New work for worker! Difficulty: 0.999985 Share difficulty: 591.506619 Total block value: 50.511625 BTC including 622 transactions
What does this mean? is it working properly?
Thx for hlp
With that small hash rate, you might want to check out p2pmining.com. It seems to work better for smaller miners, and you get merged mining.
M
September 07, 2012, 06:45:38 PM
Looks like it is working correctly. Go to http://127.0.0.1:9332 in your browser to see some more info. You can run P2Pool on one computer and direct your miners to that computer's IP address instead of the localhost address.
September 07, 2012, 03:37:31 PM
im trying p2pool now
I have sucessfuly installed it on my win 7 machine and im pointing 200MH/s to it.
How do the statistics work? They are not displaying anything atm? (Does this need time?)
I want to use P2Pool, bitcoind and my miner on three separate machines. HOw can i get this to work?
What does this mean? is it working properly?
Thx for hlp
I have sucessfuly installed it on my win 7 machine and im pointing 200MH/s to it.
How do the statistics work? They are not displaying anything atm? (Does this need time?)
I want to use P2Pool, bitcoind and my miner on three separate machines. HOw can i get this to work?
Code:
P2Pool: 17433 shares in chain (17222 verified/17437 total) Peers: 10 (0 incoming)
Local: 250MH/s in last 10.0 minutes Local dead on arrival: ~0.0% (0-10%) Expected time to share: 2.9 hours
Shares: 0 (0 orphan, 0 dead) Stale rate: ??? Efficiency: ??? Current payout: 0.0000 BTC
Pool: 277GH/s Stale rate: 6.7% Expected time to block: 11.6 hours
New work for worker! Difficulty: 0.999985 Share difficulty: 591.506619 Total block value: 50.511625 BTC including 622 transactions
Local: 250MH/s in last 10.0 minutes Local dead on arrival: ~0.0% (0-10%) Expected time to share: 2.9 hours
Shares: 0 (0 orphan, 0 dead) Stale rate: ??? Efficiency: ??? Current payout: 0.0000 BTC
Pool: 277GH/s Stale rate: 6.7% Expected time to block: 11.6 hours
New work for worker! Difficulty: 0.999985 Share difficulty: 591.506619 Total block value: 50.511625 BTC including 622 transactions
What does this mean? is it working properly?
Thx for hlp
September 07, 2012, 03:42:11 AM
...
well, you probably have more connections than the avg bitcoin user.
many will only have 8
9 on my main one and 8 on my secondary one well, you probably have more connections than the avg bitcoin user.
many will only have 8
September 07, 2012, 02:14:00 AM
... or as I've stated before ...
Only transfer the block header, coinbase txn and merkle tree by default then get the recipient to say if it wants the transactions and which ones (a list) from the merkle tree.
Most bitcoinds already have ALL txn but the coinbase, so that is a massive waste and always has been.
Secondly, why are the txn's re-validated, shouldn't they have been validated when they were received the first time?
Only transfer the block header, coinbase txn and merkle tree by default then get the recipient to say if it wants the transactions and which ones (a list) from the merkle tree.
Most bitcoinds already have ALL txn but the coinbase, so that is a massive waste and always has been.
Secondly, why are the txn's re-validated, shouldn't they have been validated when they were received the first time?
I'm certainly by far not an expert at this.. but I would assume that you there is a "trust no one" factor here, you can't safely assuming incoming transactions are validated already.
A single request not multiple.
Very simply to know what is missing since the merkle tree lists all the txns and thus the reply would be those at the bottom of the tree you don't already have.
As for 10%? Where do you get that figure from?
I wrote a little transaction processing module to add to bitcoind (that I run all the time), that, among other things, specifically tells me the number of missing transactions.
After about a day from a restart, it was EXTREMELY rare for it to not have every txn except of course the coinbase (which no one will already have except the person/pool who found the block - and why of course I said that should always be sent)
I'd very much doubt that 10% number.
However, even if it was as extremely high as 10%, it would be way faster to send back a reply of 10% of the transaction numbers, then get those 10%, than sending the full 100% every time when 90% of them are unnecessary.
As for the memory pool txn's - why would there be a txn in there that wasn't already verified?
What extra verification is done when the txn's are received with a new block that isn't already done as each txn comes in?
many will only have 8
September 06, 2012, 12:49:57 PM
... or as I've stated before ...
Only transfer the block header, coinbase txn and merkle tree by default then get the recipient to say if it wants the transactions and which ones (a list) from the merkle tree.
Most bitcoinds already have ALL txn but the coinbase, so that is a massive waste and always has been.
Secondly, why are the txn's re-validated, shouldn't they have been validated when they were received the first time?
Only transfer the block header, coinbase txn and merkle tree by default then get the recipient to say if it wants the transactions and which ones (a list) from the merkle tree.
Most bitcoinds already have ALL txn but the coinbase, so that is a massive waste and always has been.
Secondly, why are the txn's re-validated, shouldn't they have been validated when they were received the first time?
I'm certainly by far not an expert at this.. but I would assume that you there is a "trust no one" factor here, you can't safely assuming incoming transactions are validated already.
A single request not multiple.
Very simply to know what is missing since the merkle tree lists all the txns and thus the reply would be those at the bottom of the tree you don't already have.
As for 10%? Where do you get that figure from?
I wrote a little transaction processing module to add to bitcoind (that I run all the time), that, among other things, specifically tells me the number of missing transactions.
After about a day from a restart, it was EXTREMELY rare for it to not have every txn except of course the coinbase (which no one will already have except the person/pool who found the block - and why of course I said that should always be sent)
I'd very much doubt that 10% number.
However, even if it was as extremely high as 10%, it would be way faster to send back a reply of 10% of the transaction numbers, then get those 10%, than sending the full 100% every time when 90% of them are unnecessary.
As for the memory pool txn's - why would there be a txn in there that wasn't already verified?
What extra verification is done when the txn's are received with a new block that isn't already done as each txn comes in?
September 06, 2012, 07:44:49 AM
what the devil
2012-09-06 06:53:54.077480 GOT BLOCK FROM MINER! Passing to bitcoind! http://blockexplorer.com/block/000000000000013fcf0d071e54c00838654cc2328b463bea33894ed51eec96dd
2012-09-06 06:53:54.101687 GOT SHARE! 1eec96dd prev 699c48c8 age 8.58s DEAD ON ARRIVAL
http://nogleg.com:9332/static/share.html#000000000000013fcf0d071e54c00838654cc2328b463bea33894ed51eec96dd
ok, so i knew it did it with orphans, but 'dead on arrival'?
(ed: hmm, no, that's not it... bizarre)
it looks like i trumped myself by it being passed to bitcoind and acknowledged there first?
It IS possible 2012-09-06 06:53:54.077480 GOT BLOCK FROM MINER! Passing to bitcoind! http://blockexplorer.com/block/000000000000013fcf0d071e54c00838654cc2328b463bea33894ed51eec96dd
2012-09-06 06:53:54.101687 GOT SHARE! 1eec96dd prev 699c48c8 age 8.58s DEAD ON ARRIVAL
http://nogleg.com:9332/static/share.html#000000000000013fcf0d071e54c00838654cc2328b463bea33894ed51eec96dd
ok, so i knew it did it with orphans, but 'dead on arrival'?
(ed: hmm, no, that's not it... bizarre)
it looks like i trumped myself by it being passed to bitcoind and acknowledged there first?
P2pool is checking every share because every can BE a block solution, but not every share can fit into p2pool share chain because of fast long pooling.
Thats why it is crucial to miner software send stale shares
Sometimes orphaned/doa share CAN be a bitcoin block This way you only lost one pool share, but get block
September 06, 2012, 07:18:04 AM
what the devil
2012-09-06 06:53:54.077480 GOT BLOCK FROM MINER! Passing to bitcoind! http://blockexplorer.com/block/000000000000013fcf0d071e54c00838654cc2328b463bea33894ed51eec96dd
2012-09-06 06:53:54.101687 GOT SHARE! 1eec96dd prev 699c48c8 age 8.58s DEAD ON ARRIVAL
http://nogleg.com:9332/static/share.html#000000000000013fcf0d071e54c00838654cc2328b463bea33894ed51eec96dd
ok, so i knew it did it with orphans, but 'dead on arrival'?
(ed: hmm, no, that's not it... bizarre)
it looks like i trumped myself by it being passed to bitcoind and acknowledged there first?
2012-09-06 06:53:54.077480 GOT BLOCK FROM MINER! Passing to bitcoind! http://blockexplorer.com/block/000000000000013fcf0d071e54c00838654cc2328b463bea33894ed51eec96dd
2012-09-06 06:53:54.101687 GOT SHARE! 1eec96dd prev 699c48c8 age 8.58s DEAD ON ARRIVAL
http://nogleg.com:9332/static/share.html#000000000000013fcf0d071e54c00838654cc2328b463bea33894ed51eec96dd
ok, so i knew it did it with orphans, but 'dead on arrival'?
(ed: hmm, no, that's not it... bizarre)
it looks like i trumped myself by it being passed to bitcoind and acknowledged there first?
September 05, 2012, 07:56:24 PM
... or as I've stated before ...
Only transfer the block header, coinbase txn and merkle tree by default then get the recipient to say if it wants the transactions and which ones (a list) from the merkle tree.
Most bitcoinds already have ALL txn but the coinbase, so that is a massive waste and always has been.
Secondly, why are the txn's re-validated, shouldn't they have been validated when they were received the first time?
Only transfer the block header, coinbase txn and merkle tree by default then get the recipient to say if it wants the transactions and which ones (a list) from the merkle tree.
Most bitcoinds already have ALL txn but the coinbase, so that is a massive waste and always has been.
Secondly, why are the txn's re-validated, shouldn't they have been validated when they were received the first time?
I'm certainly by far not an expert at this.. but I would assume that you there is a "trust no one" factor here, you can't safely assuming incoming transactions are validated already.
September 05, 2012, 07:41:24 PM
... or as I've stated before ...
Only transfer the block header, coinbase txn and merkle tree by default then get the recipient to say if it wants the transactions and which ones (a list) from the merkle tree.
Most bitcoinds already have ALL txn but the coinbase, so that is a massive waste and always has been.
Secondly, why are the txn's re-validated, shouldn't they have been validated when they were received the first time?
Only transfer the block header, coinbase txn and merkle tree by default then get the recipient to say if it wants the transactions and which ones (a list) from the merkle tree.
Most bitcoinds already have ALL txn but the coinbase, so that is a massive waste and always has been.
Secondly, why are the txn's re-validated, shouldn't they have been validated when they were received the first time?
I'm certainly by far not an expert at this.. but I would assume that you there is a "trust no one" factor here, you can't safely assuming incoming transactions are validated already.
M
September 05, 2012, 06:40:34 PM
... or as I've stated before ...
Only transfer the block header, coinbase txn and merkle tree by default then get the recipient to say if it wants the transactions and which ones (a list) from the merkle tree.
Most bitcoinds already have ALL txn but the coinbase, so that is a massive waste and always has been.
Secondly, why are the txn's re-validated, shouldn't they have been validated when they were received the first time?
Only transfer the block header, coinbase txn and merkle tree by default then get the recipient to say if it wants the transactions and which ones (a list) from the merkle tree.
Most bitcoinds already have ALL txn but the coinbase, so that is a massive waste and always has been.
Secondly, why are the txn's re-validated, shouldn't they have been validated when they were received the first time?
September 05, 2012, 03:43:53 PM
Some orphans now from people with horrible connections.
I know blockchain.info is missing tons of IPs and isn't very accurate, but if you see an orphaned block that was only relayed to a couple nodes, then you know there must have been a good 10-15 seconds in there before it was broadcast.
Why not use a p2pool with a decent connection that'll have a nice up-to-the-second bitcoind? It wouldn't result in any more rejects or orphans, would it?
Hmm, unless the problem is a bitcoind that doesn't allow incoming connections and only has 8 outgoing (and not to any good nodes).. time to make use of addnode? Might I suggest 5.9.24.81? My max is 1000.
There is a known problem with Bitcoin relaying blocks. Every step of relaying a block, the node needs to 1) finish downloading it completely, 2) verify the block header and ALL transactions are valid, and 3) upload the entire block to the each peer node in sequence.I know blockchain.info is missing tons of IPs and isn't very accurate, but if you see an orphaned block that was only relayed to a couple nodes, then you know there must have been a good 10-15 seconds in there before it was broadcast.
Why not use a p2pool with a decent connection that'll have a nice up-to-the-second bitcoind? It wouldn't result in any more rejects or orphans, would it?
Hmm, unless the problem is a bitcoind that doesn't allow incoming connections and only has 8 outgoing (and not to any good nodes).. time to make use of addnode? Might I suggest 5.9.24.81? My max is 1000.
The obvious (but very non-trivial to implement with Satoshi's codebase) solution is to parallelize block distribution; that is, as soon as you receive the 80 byte block header:
- verify it is
- a valid header
- the header for a block after the most recent one
- meets the required difficulty
- immediately send all peers the "incoming block" message
- upload the block to peers as fast as they can take it, as it is received
September 05, 2012, 01:39:30 PM
Some orphans now from people with horrible connections.
I know blockchain.info is missing tons of IPs and isn't very accurate, but if you see an orphaned block that was only relayed to a couple nodes, then you know there must have been a good 10-15 seconds in there before it was broadcast.
Why not use a p2pool with a decent connection that'll have a nice up-to-the-second bitcoind? It wouldn't result in any more rejects or orphans, would it?
Hmm, unless the problem is a bitcoind that doesn't allow incoming connections and only has 8 outgoing (and not to any good nodes).. time to make use of addnode? Might I suggest 5.9.24.81? My max is 1000.
I know blockchain.info is missing tons of IPs and isn't very accurate, but if you see an orphaned block that was only relayed to a couple nodes, then you know there must have been a good 10-15 seconds in there before it was broadcast.
Why not use a p2pool with a decent connection that'll have a nice up-to-the-second bitcoind? It wouldn't result in any more rejects or orphans, would it?
Hmm, unless the problem is a bitcoind that doesn't allow incoming connections and only has 8 outgoing (and not to any good nodes).. time to make use of addnode? Might I suggest 5.9.24.81? My max is 1000.
September 04, 2012, 04:54:27 PM
It bothers me that Gavin has try to convince Tycho (of deepbit) of his multi-sig proposal before he can implement it, because if deepbit decides to not use the new code, it's dead in the water.
As opposed to having to convince the author of cgminer to implement it, and then get all the p2pool users to upgrade?
Other than that being a quote from 8 months ago ... what has it to do with cgminer?
Or have you misquoted and are referring to moving all the pool work into cgminer coz some fools came up with the idea of doing that rather than fixing the size of the nonce?
September 04, 2012, 03:10:39 PM
It bothers me that Gavin has try to convince Tycho (of deepbit) of his multi-sig proposal before he can implement it, because if deepbit decides to not use the new code, it's dead in the water.
As opposed to having to convince the author of cgminer to implement it, and then get all the p2pool users to upgrade?
Jump to: