Eligius pool POLL: New minimum payout

[WNS]

The password is not accessible without hacking pushpoold, and has obvious security issues. Using it is out of the question. Any kind of per-user configuration can wait for signmessage.

Okay, how about changing how the username is parsed? If a standard format string is added, say -1000 (dash+4 digits, mBTC) to the end of the username, just use everything before the dash as an account address, and set the payout if the number is in range.

[1714970017]

1714970017

[1714970017]

1714970017

[1714970017]

1714970017

[1714970017]

1714970017

[Wildfire]

That's not a bad idea. Especially considering that it could be any amount of time before signmessage is implemented, if it ever is at all.

[josell]

Poll seems pretty straightforward. Please only vote if you mine on Eligius regularly, and actually understand the question.

Basically: should the pool pay you after you reach at least 0.16… BTC, or continue requiring a minimum of 1 BTC?

I think it would be cool if the user states the payount limit in the password field, which has no such function in your pool.

[Artefact2]

Poll seems pretty straightforward. Please only vote if you mine on Eligius regularly, and actually understand the question.

Basically: should the pool pay you after you reach at least 0.16… BTC, or continue requiring a minimum of 1 BTC?

I think it would be cool if the user states the payount limit in the password field, which has no such function in your pool.

Did you even read this thread ? He said that's not an option.

The password is not accessible without hacking pushpoold, and has obvious security issues. Using it is out of the question. Any kind of per-user configuration can wait for signmessage.

Okay, how about changing how the username is parsed? If a standard format string is added, say -1000 (dash+4 digits, mBTC) to the end of the username, just use everything before the dash as an account address, and set the payout if the number is in range.

What's the difference ? It's still a mediocre solution to an already-solved problem. Just wait ! 

[WNS]

Okay, how about changing how the username is parsed? If a standard format string is added, say -1000 (dash+4 digits, mBTC) to the end of the username, just use everything before the dash as an account address, and set the payout if the number is in range.

What's the difference ? It's still a mediocre solution to an already-solved problem. Just wait ! 

Eligius is already committed to the elegant kludge of Address as username, I'm suggesting leveraging this out-of-band data space for an additional purpose, which could be taken to arbitrary extremes, but I don't think my suggestion does that.

In addition I would argue that the signmessage solution is likely more problematic, as it requires processing resources to verify the threshold setting requests. This is an unnecessary liability, since threshold really does not need to be secure, as long as it is defined within reasonable limits. It opens up an obvious DDoS vulnerability for the pool server(s) on top of all the potential security problems with signmessage itself, as has already been discussed elsewhere.

[Man From The Future]

The issue here is, someone else can screw up your payout value by mining witha  different setting with your address... which one should be used?

[Artefact2]

Eligius is already committed to the elegant kludge of Address as username

You see that as a kludge. I see it as an elegant solution. Having to register to mine is not convenient and introduces another layer of potential bugs and security issues. If you don't trust me, see what happened to Deepbit a few weeks ago.

[WNS]

Eligius is already committed to the elegant kludge of Address as username

You see that as a kludge. I see it as an elegant solution.

I submit that it is both. The "right" way would be to modify the pool management daemon to not think in terms of username/password, but, as discussed, this has not been done. The daemon has instead been fooled into passing the address as username, a great worse-is-better solution, that solves the problem, without breaking anything, a brilliant kludge that does not need to be fixed.

Since the out-of-band data pathway has already been exploited, why stop there? We have one obvious piece of data that could be passed as well by using the same trick.

The issue here is, someone else can screw up your payout value by mining witha  different setting with your address... which one should be used?

I don't really see a problem here if the value is sensibly constrained, perhaps more than my original suggestion, say 2 digits from 0.1BTC to 9.9BTC. Use the last value that came with a share (so the trickster must actually pay you in shares for the privilege of changing your threshold), I would be interested in a scenario in which such a prank would matter to the recipient.

[anodyne]

Couldn't it somehow be possible to set up and track payout levels using the pool URL, by using different sub-domains for each level – with 05btc.mining.eligius.st, 1btc.mining.eligius.st and so on?