[DEAD] DeepBit.net PPS+Prop,instant payouts, we pay for INVALID BLOCKS too

[-ck]

Effect of poolhoppers is negligible, I'm trying to scare them off

How? It's obviously not with your payment scheme since it's pure prop, unless it's not truly that...

[1714011992]

1714011992

[1714011992]

1714011992

[TT]

Please fix your send code to use multisend and to use the public key hash for 1VayNert3x1KzbpzMGt2qdqrAThiRovi8 instead of the full public key for the change output while you're at it!

You're polluting the block chain unnecessarily and slowing down your own confirmations.

[DeepBit]

Please fix your send code to use multisend and to use the public key hash for 1VayNert3x1KzbpzMGt2qdqrAThiRovi8 instead of the full public key for the change output while you're at it!

Actually using public key makes those transactions on average 9% smaller than with a key hash, so I'm using full key for a reason.

[kano]

Effect of poolhoppers is negligible, I'm trying to scare them off

How? It's obviously not with your payment scheme since it's pure prop, unless it's not truly that...

Actually, what is happening is that deepbit is moving shares that users send them from one block into other blocks when they do the payment calculation to reduce payments for some ...

[DeepBit]

Actually, what is happening is that deepbit is moving shares that users send them from one block into other blocks when they do the payment calculation to reduce payments for some ...

No, the payment scheme is pure Proportional.

The mentioned situation was caused by a bug in round end detection routine and happened only a few times.

[organofcorti]

Effect of poolhoppers is negligible, I'm trying to scare them off

How? It's obviously not with your payment scheme since it's pure prop, unless it's not truly that...

Actually, what is happening is that deepbit is moving shares that users send them from one block into other blocks when they do the payment calculation to reduce payments for some ...

You aren't being serious, are you kano? Or do you have some proof? I'd be very interested in seeing it if you do.

If DeepBit did what you suggest, they'd no longer be paying proportionally, and it wouldn't be hard for a pool hopper to figure that out and post a "scammer!" notice. I've noticed for the last couple of months that DeepBit's hashrate for short rounds isn't boosted the way it was when I first looked at it. Last time I looked I couldn't see any significant pool hopping hashrate increase.


My guess is that DeepBit is scaring them off by using their mountain of btc to buy goon squads to send to pool hoppers' homes and then raping and pillaging their computers. Unfortunately this method will only lead to an arms race which might lead to the end of the world as we know it.

I think that this method is much simpler and more effective than what you suggest

[DeepBit]

You aren't being serious, are you kano? Or do you have some proof? I'd be very interested in seeing it if you do.

This actually happened a few times in last month, and I'm glad that some hopper contacted me and explained what is going on so I can fix it.
Some shares were left in "temporary cache" and were accounted for later blocks, but since this was a bug and share movement was not controlled (some later blocks were shorter and some longer) it didn't caused any serious effect on rewards.

[kano]

Well ... lets just say that there is a REALLY easy way to prove if it is happening,
with a small change to probably almost any miner program ...

Anyone want code suggestions?

[Tittiez]

Well ... lets just say that there is a REALLY easy way to prove if it is happening,
with a small change to probably almost any miner program ...

Anyone want code suggestions?

Do we take cgminer and make it use are gpu's to divide by zero?

[mjsbuddha]

wtf I thought this was fixed. miners still down and cant reach the site via web

[organofcorti]

Site's up for me.

[DeepBit]

wtf I thought this was fixed. miners still down and cant reach the site via web

Can you please be more specific - is it mining or web ?
Your signature looks not down to me. What is your expected hashrate ?

[kano]

Well ... lets just say that there is a REALLY easy way to prove if it is happening,
with a small change to probably almost any miner program ...

Anyone want code suggestions?

Do we take cgminer and make it use are gpu's to divide by zero?

You forgot to add 42 ...

Anyway, I was the one who actually changed cgminer to display the proper share values and report found blocks so that people could actually verify that the pools weren't cheating in certain ways - so I certainly do understand what info is currently available.

I was being facetious before asking if anyone wanted to know coz I expect any programmers of any miner would see the simplicity of verifying if a pool is doing this.

Every getwork you are sent tells you the previous block hash ... it's well, sorta necessary
So if the miner simply displayed the 2nd 32bits next to the share details then you can easily see that a given share was in the block after the one shown.

If you ever have issues in that regard you could check which and how many shares were in which block.

However, even at the moment you can check within a reasonable accuracy by seeing the number of shares accepted between LP's
So the change would only help with identifying possible rare out-of-ordering of shares vs LPs
(the out-of-ordering isn't incorrect, it's just that the messages are not guaranteed to always be received in the expected order, by the miner)

[TT]

Please fix your send code to use multisend and to use the public key hash for 1VayNert3x1KzbpzMGt2qdqrAThiRovi8 instead of the full public key for the change output while you're at it!

Actually using public key makes those transactions on average 9% smaller than with a key hash, so I'm using full key for a reason.

Hmm, let's see:

Using the full public key:
04a39b9e4fbd213ef24bb9be69de4a118dd0644082e47c01fd9159d38637b83fbcdc115a5d6e970 586a012d1cfe3e3a8b1a3d04e763bdc5a071c0e827c0bd834a5 OP_CHECKSIG

Using the hash:
OP_DUP OP_HASH160 0568015a9facccfd09d70d409b6fc1a5546cecc6 OP_EQUALVERIFY OP_CHECKSIG

Each opcode is one byte.

Therefore, using the full public key requires 66 bytes while using the hash requires 24 bytes for the change output script.

That's to say, using the full public key makes the transaction about 233 bytes whereas using the hash would only require about 191 bytes. Your transactions are about 22% larger than they would be if you used the hash.

And you have littered the block chain with 321053 of them as of the writing of this post!

And you pay nothing to other miners who graciously include them in their blocks while giving them low priority in your own blocks.

Only satoshi dice comes close to polluting the block chain as much as deepbit...but one could argue that satoshi dice requires individual transactions per play whereas there is absolutely NO REASON WHATSOEVER for deepbit to be sending separate transactions for each payout.

[DeepBit]

That's to say, using the full public key makes the transaction about 233 bytes whereas using the hash would only require about 191 bytes. Your transactions are about 22% larger than they would be if you used the hash.

My transactions are usually 233-234 bytes, that's right. And standard transactions are 257-258.

You just forgot about redeeming.

Redeeming public key hash is like:
3045022100fdcd44b107e9ceebc64dcbbccff123ce99d8a116215b041335a074d5a020292902207 2505c04ebba34240c850ccab05e0a9bfdc82dbf87b52c65de07cb0d1b8bd28f01 04a39b9e4fbd213ef24bb9be69de4a118dd0644082e47c01fd9159d38637b83fbcdc115a5d6e970 586a012d1cfe3e3a8b1a3d04e763bdc5a071c0e827c0bd834a5

Redeeming the same public key is...
3046022100c514d362cd29acd33bbf8938096a1485d3a8ccdd16a830c4ffdf003407136e0c02210 0de9e57f5c231aff030e81e787b81404490961476fcfe15c0b9821adce783eae501

[TT]

I apologize. You're right about redeeming scripts being shorter.

Regardless, the issue of whether or not you use the full public key is practically negligible compared to the issue of sending each payout in a separate transaction.

[Fiyasko]

Stupid fucking DDoS' Nobody should give these scrpt kiddies a single fucking cent, If they think they can profit off of it, They'll continue doing it.

Goddamnit it just pisses me off to see script kiddies trying to demand money from pool operators by attempting to DDoS their servers.
I can understand trying to "shrink the mega pool via DDoS" But majority of the pools are being attacked, And are getting demands of "pay me and this will stop" If you think for just a second. Dont pay them, And it will stop, Because they're wasting thier fucking time if your not going to pay them.
Pay them, And it will stop untill they demand more money (wich they will do forever) So NOT ONE CENT should goto them.

[DeepBit]

The site is down? Hello?

Everything looks fine to me. At least total hashrate is the same.

Check what pool's IP do you see and PM it to me.

[cowhead2oo3]

The site is down? Hello?

Everything looks fine to me. At least total hashrate is the same.

Check what pool's IP do you see and PM it to me.

Early yesterday, I can not enter deepbit.net

And I think you just said that the server is fine ... is that my English is not very good

[ChiangYay]

How to change pay per share to proportional and viceversa.

Thanks ChiangYay