Topic: Eligius pool POLL: New minimum payout (Read 5080 times)

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?

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.


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.

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.

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?

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.

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


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

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.

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.

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.

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.

That's actually not a bad idea. To deal with multiple (and potentially fraudulent) miners, you'd have to record the desired minimum payout for each share received, or at least group them by similar payouts. For 99.9% of miners, they would all end up being the same value. If you wanted to split payout values between minimum machines, your stats page would have one sub-page per payout value. This way, the experience of most users wouldn't change at all, and if somebody decides to mess with you by mining for you with some arbitrarily large payout value (maybe we need a MAXIMUM payout value?), his shares won't mess with yours, and will show up on another page. Gonna suck a bit for artefact2 to rewrite the stat script, but it seems like it would work pretty well. Any glaring errors that I've missed?

this

Since the pw is noise at Eligius, just reuse the space for pay threshold, say as an integer in mBTC.

Could you read the password to set the payout limit? For example, I log in with --pass=0.5 then when I get to 0.5btc it pays out.

For people with multiple miners, I'm not sure how you'd manage that.

Also potentially open to people mining on your behalf and messing with your threshold.

Anyone is welcome to upload their own builds if they want to make a different version

Would be cool to have a version number on these builds, I suspect them to be still a beta version.

Fees are incurred based on the difference from what you received to how much you're sending. If most of your sends are 0.5 BTC to 5 BTC, 1 BTC is ideal. But if most are 0.01 BTC to 0.5 BTC, 0.16 BTC payouts make more sense. While combining tiny coins incurs fees, so does spending young coins-- and you keep getting young change by splitting a big coin.
This is incorrect. The Bitcoin spending structures are ignorant to addresses. Spending 5 coins from the same address is the same as spending 5 coins from different addresses.
Disk space is consumed by shares, not balances (which are only kept in memory for a short period when it calculates a getwork).
You can get much lower fees by using an Eligius branch. Qurashee made some Windows builds (use at your own risk! they might contain viruses, who knows), or you can build from source.

And on a per-address basis? As long as someone mines for me, I'd be happy to accept the income - I don't care if it's my own PC or someone else who wants to donate something...

By the way, is there code in place that verifies "usernames" (=adresses) first for validity or does income generated by invalid adresses go to the rest of the pool?

Impossible at the moment, as there is no way to prove that someone owns a Bitcoin address. The payout limit simply cannot be set on a per-user basis at the moment.

Ok then, maybe give users an option? I guess it would be easier/better for Luke-Jr to have smaller payout limits (as it reduces the time he has to keep data from active miners) but some (bigger!) miners might still prefer 1 or even 2 or more BTC limits.

I'm not 100% if/how it's technically feasible to have mixed limits in this situation, but there could be a default value of 16 bitcents (or whatever Luke-Jr would deem useful) and by setting your worker password to "1.337" your new payout limit becomes 1.337 BTC.

Problems that may arise:
2 workers on the same account with 2 different passwords --> a lot of switching each time they request something (Solution: First limit per block/per 5 blocks/per 10 blocks...(?) found is "locked in")
People might maliciously set extremely high limits for others

Now I finally found a sample of what I had in mind, from my own transaction history. I'll try to exaplain it as well as I understand it, sorry for any gaps. :)

Summary: I was transferring 5 BTC for sale to "bitmarket.eu".

My source account: 1ATSRrK2XW2mxSpeYZ421ZhEJbDNzsRoW6
My remainder account: 1KWGSbDxGioCjmnTpVUS7evZQ2HyScRsyj
My account on Bitmarket.eu: 15MSgyNFp2i1WqB3X2hM5aQwBdc3EnM7u2

The transaction can be viewed here:

http://blockexplorer.com/tx/23c2237d28c3a9d1e0ff32c7fb2f1fb45340771bcb221e81792fe2ac9cb35e8e

The transaction consumes 5 different inputs, valued together 5.07507305 BTC.
The transaction produces 2 outputs.
Of the outputs, 5 BTC goes to my personal account on "bitmarket.eu".
Of the outputs, 0.06507305 BTC goes back to me (remainder account).
The difference of inputs and outputs, 0.01 BTC, goes to the generator.

The block containing my transaction is here:

http://blockexplorer.com/block/0000000000001cbe54fa11f218469b928dde15e13de83d70630b77c65d9a5819

From the block, you can notice that my transaction data size was about 1 KB. This should be possible to conduct without a fee, but I paid one anyway. However, it my transaction had consumed more inputs, it would have been larger... and for 20 inputs, perhaps it could have easily been 2 KB in size.

It is my understanding that larger transactions accrue fees on every kilobyte, and that generating (or buying) many small sums will make your transactions larger, if you want to join them together.