[1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool

[rav3n_pl]

Who own's the BTC Adress
1FZ75WMKHmbTQiDyxMcu6XiDL2Yx7ScU1o


This adress Produce 100% Reject's on my node  http://p2pool-cologne.dyndns.org:9332  !!!!!!

Greets

OMG it is 4GH/s and making over 60% stales... someone is trying BFLs on p2pool?

[Subo1977]

Who own's the BTC Adress
1FZ75WMKHmbTQiDyxMcu6XiDL2Yx7ScU1o


This adress Produce 100% Reject's on my node  http://p2pool-cologne.dyndns.org:9332  !!!!!!

Greets

OMG it is 4GH/s and making over 60% stales... someone is trying BFLs on p2pool?

Total
-Mean: 3.78GH  = Jalapeno ?


Someone read this, the Rejects goes down.   

have a look at http://p2pool-cologne.dyndns.org:9332/static   and there on hour



 

[JayCoin]

Found 2 blocks for p2pool in the past 11 days with 4.5Gh/s.  I should play the LOTTO

[TheHarbinger]

Found 2 blocks for p2pool in the past 11 days with 4.5Gh/s.  I should play the LOTTO

All that mean is you used up all your l**k.  It means if you tried to solo-mine at this point, you wouldn't find a block for 11 years.   

[rav3n_pl]

About 20% of network updated already to new version, keep it coming

[spiccioli]

About 20% of network updated already to new version, keep it coming

hi rav3n_pl,

which new version?

Latest version is from june as far as I know https://bitcointalk.org/index.php?topic=18313.msg971005#msg971005

spiccioli

[rav3n_pl]

About 20% of network updated already to new version, keep it coming

hi rav3n_pl,

which new version?

Latest version is from june as far as I know https://bitcointalk.org/index.php?topic=18313.msg971005#msg971005

spiccioli

https://github.com/forrestv/p2pool
 commit 2adf77e726
forrestv authored 9 days ago
"advanced share version to 4"
For windows grab a  ZIP: https://github.com/forrestv/p2pool/zipball/master
But it NEED bitcoin 0.6.4 or higher! You need compile it form sources https://github.com/bitcoin/bitcoin
Easy on linux, pain on windows atm.
I`m runnig linux VM to keep bitcoind and p2pool up to date

[Luke-Jr]

But it NEED bitcoin 0.6.4 or higher! You need compile it form sources https://github.com/bitcoin/bitcoin

FWIW, that git tree is for 0.7 (not stable yet). For 0.6.4, you need http://gitorious.org/bitcoin/bitcoind-stable/

[spiccioli]

About 20% of network updated already to new version, keep it coming

hi rav3n_pl,

which new version?

Latest version is from june as far as I know https://bitcointalk.org/index.php?topic=18313.msg971005#msg971005

spiccioli

https://github.com/forrestv/p2pool
 commit 2adf77e726
forrestv authored 9 days ago
"advanced share version to 4"
For windows grab a  ZIP: https://github.com/forrestv/p2pool/zipball/master
But it NEED bitcoin 0.6.4 or higher! You need compile it form sources https://github.com/bitcoin/bitcoin
Easy on linux, pain on windows atm.
I`m runnig linux VM to keep bitcoind and p2pool up to date

Ok thanks,

I'll wait until it uses a stable bitcoind instead of a test one.

spiccioli

[Subo1977]

Who own's 16pZyakbCqPnxGaUpKLtuwzjNFezqJhd1N ?

he is throwing 40 GH/s on my node 

ist this BitForce Single 'SC' ? 

[nibor]

Who own's 16pZyakbCqPnxGaUpKLtuwzjNFezqJhd1N ?

he is throwing 40 GH/s on my node 

ist this BitForce Single 'SC' ? 

That address often forwards BTC to 1MikeR1S2DSzMT1DWfL9NeuXvxBywkYbSn
So at a guess someone called Mike!

[rav3n_pl]

But it NEED bitcoin 0.6.4 or higher! You need compile it form sources https://github.com/bitcoin/bitcoin

FWIW, that git tree is for 0.7 (not stable yet). For 0.6.4, you need http://gitorious.org/bitcoin/bitcoind-stable/

Thanks
0.7 is marked as rc1 so it is close to stable for me
I have backup of backup of backup of my wallet, so I can be a guinea pig

[doobeedoo]

But it NEED bitcoin 0.6.4 or higher! You need compile it form sources https://github.com/bitcoin/bitcoin

FWIW, that git tree is for 0.7 (not stable yet). For 0.6.4, you need http://gitorious.org/bitcoin/bitcoind-stable/

Thanks
0.7 is marked as rc1 so it is close to stable for me
I have backup of backup of backup of my wallet, so I can be a guinea pig

for me v4 works with bitcoind 0.6.3 without any errors.
maybe it depends on bintcoind running on the same, or a different machine. i use different VMs for p2pool, bitcoind and namecoind. All machines running Ubuntu 12.04.

[misterbigg]

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?

[kano]

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?

Eh?
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?

[zvs]

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.

[Luke-Jr]

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.

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

Then, distribution is accomplished in realtime, and all the bottleneck remaining is restricted to verifying transactions locally on each node.

[kano]

... 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?

[mdude77]

... 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?

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

[Luke-Jr]

... 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?

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.

He meant the clients might have already seen the transaction broadcast before, so would have validated it themselves already. That is indeed already cached, but there are a lot of transactions that don't get seen by any given node (about 10% IIRC), and the back-and-forth of requesting missing transactions would add delays - though it might make sense on top of the basic block distribution parallelization I mentioned, but it will need to be benchmarked.