Topic: Eligius pool POLL: New minimum payout (Read 5097 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?
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.
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.
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?
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.
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.Basically: should the pool pay you after you reach at least 0.16… BTC, or continue requiring a minimum of 1 BTC?
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 !
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. Basically: should the pool pay you after you reach at least 0.16… BTC, or continue requiring a minimum of 1 BTC?
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.
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.
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?
Could you read the password to set the payout limit?
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.
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.
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.
Would be cool to have a version number on these builds, I suspect them to be still a beta version.
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.
Would be cool to have a version number on these builds, I suspect them to be still a beta version. The current method avoids more transaction fees.
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.[Edit: As far as I understood it, as long as coins are generated at the same address, it shoudn't matter if they are 100* 1 Bitcent or 1*1 Bitcoin --> but if you switch accounts after each payout (for whatever reason?!) this might be a viable concern.]
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.Didn't Eligius US fail yesterday because of this?
Disk space is consumed by shares, not balances (which are only kept in memory for a short period when it calculates a getwork).miner transfers 4 BTC to marketplace <-- probably a 0.01 BTC fee
miner transfers 2 BTC to marketplace <-- probably a 0.02 BTC fee[/color
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.miner transfers 2 BTC to marketplace <-- probably a 0.02 BTC fee[/color
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.
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?
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
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
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
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.
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.
Hmm. So I read the protocol description for a "tx" (transmit bitcoins) message from the Wiki.
https://en.bitcoin.it/wiki/Protocol_specification#tx
...where it explains some fields of the "tx" message thusly:
...and if you then skip forward to "Example tx message", you should find a sample like this:
The commentary about the sample "tx" message speaks of the possibility of multiple "inputs" and multiple "outputs". This is where I got the idea about generated balances existing separately in the block chain (and of joining up multiple small balances, no matter if they were generated or received, being a more "expensive" operation, since it produces longer "tx" messages with really many "inputs", and I read elsewhere that fees are counted per kilobyte).
I'll try to find a simpler explanation of it, though, since I'm not really well aware of the Bitcoin protocol, and could be still misunderstanding this...
...especially with regard to the question of "how is it ensured that no fees are accrued from spending bitcoins earnt with generation fees". The likely explanations so far seem "generation fees all joined into a single output inside the block" and "they are under some pre-defined limit of value, and thus processed free of charge by most, if not all, miners".
https://en.bitcoin.it/wiki/Protocol_specification#tx
...where it explains some fields of the "tx" message thusly:
Code:
1+ tx_in count var_int Number of Transaction inputs
41+ tx_in tx_in[] A list of 1 or more transaction inputs or sources for coins
1+ tx_out count var_int Number of Transaction outputs
8+ tx_out tx_out[] A list of 1 or more transaction outputs or destinations for coins
...and if you then skip forward to "Example tx message", you should find a sample like this:
Code: ("sample tx message")
Message header:
F9 BE B4 D9 - main network magic bytes
74 78 00 00 00 00 00 00 00 00 00 00 - "tx" command
02 01 00 00 - payload is 258 bytes long
E2 93 CD BE - checksum of payload
Transaction:
01 00 00 00 - version
Inputs:
01 - number of transaction inputs
Input 1:
6D BD DB 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D - previous output (outpoint)
12 66 E9 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29
00 00 00 00
8B - script is 139 bytes long
48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 C7 36 - signature script (scriptSig)
7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A 59 23
3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 0E 41
83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D 35 BD
96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF C9 7E
F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 2A CD
2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC 4E 02
53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F 14 04
2F 46 61 4A 4C 70 C0 F1 4B EF F5
FF FF FF FF - sequence
Outputs:
02 - 2 Output Transactions
Output 1:
40 4B 4C 00 00 00 00 00 - 0.05 BTC (5000000)
19 - pk_script is 25 bytes long
76 A9 14 1A A0 CD 1C BE A6 E7 45 8A 7A BA D5 12 - pk_script
A9 D9 EA 1A FB 22 5E 88 AC
Output 2:
80 FA E9 C7 00 00 00 00 - 33.54 BTC (3354000000)
19 - pk_script is 25 bytes long
76 A9 14 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E - pk_script
FD A0 B7 8B 4E CC 52 88 AC
Locktime:
00 00 00 00 - lock time
The commentary about the sample "tx" message speaks of the possibility of multiple "inputs" and multiple "outputs". This is where I got the idea about generated balances existing separately in the block chain (and of joining up multiple small balances, no matter if they were generated or received, being a more "expensive" operation, since it produces longer "tx" messages with really many "inputs", and I read elsewhere that fees are counted per kilobyte).
I'll try to find a simpler explanation of it, though, since I'm not really well aware of the Bitcoin protocol, and could be still misunderstanding this...
...especially with regard to the question of "how is it ensured that no fees are accrued from spending bitcoins earnt with generation fees". The likely explanations so far seem "generation fees all joined into a single output inside the block" and "they are under some pre-defined limit of value, and thus processed free of charge by most, if not all, miners".
OK, thanks for pointing out the other possibility.
I'll try to dig a little in my transaction history, to see if it matches your description better (and then if I still don't undertand it sufficiently, I guess reading the wiki and protocol descriptions is what I should do next).
I'll try to dig a little in my transaction history, to see if it matches your description better (and then if I still don't undertand it sufficiently, I guess reading the wiki and protocol descriptions is what I should do next).
As far as I understood it:
3 BTC total balance in total on account X
Every transaction between 0.1 and 3 BTC --> free, no matter how many tiny transactions there might be in this account.
Anyways, Luke-Jr even made a patch to Bitcoin that uses the Eligius fee model (always fees, but VERY small ones), so by just using a different Bitcoin Version I don't see real issues with this, as transactions should anyways be accepted latest when Eligius mines a block.
3 BTC total balance in total on account X
Every transaction between 0.1 and 3 BTC --> free, no matter how many tiny transactions there might be in this account.
Anyways, Luke-Jr even made a patch to Bitcoin that uses the Eligius fee model (always fees, but VERY small ones), so by just using a different Bitcoin Version I don't see real issues with this, as transactions should anyways be accepted latest when Eligius mines a block.
To better clarify the considerations regarding fees, this is how I understand it. If someone knows better, please correct me! Thanks in advance. :)
Generation involves no fees.
However, if I remember it correctly, to transfer multiple balances created by separate generations, they must be joined together into a single transaction. It is my understanding that this process likely requires fees, and their size depends on the size of the transaction in kilobytes. I will try to demonstrate below:
Scenario 1:
miner generates 1.06220433 BTC <-- no fee
miner transfers 1.06220433 BTC to marketplace <-- no fee
miner sells 1.06220433 BTC <-- no fee
Scenario 2:
miner generates 1.06220433 BTC <-- no fee
miner generates 1.22000111 BTC <-- no fee
miner generates 1.81293888 BTC <-- no fee
miner transfers 4 BTC to marketplace <-- probably a 0.01 BTC fee
miner sells 4 BTC <-- no fee
(the transaction of taking 3 source balances and producing 2 result balances is sufficiently complex to require a fee for processing)
Scenario 3 (smaller payouts)
miner generates 0.17211322 BTC <-- no fee
miner generates 0.16623322 BTC <-- no fee
miner generates 0.16811342 BTC <-- no fee
miner generates 0.17211322 BTC <-- no fee
miner generates 0.16823322 BTC <-- no fee
miner generates 0.17411342 BTC <-- no fee
miner generates 0.19211322 BTC <-- no fee
miner generates 0.16723322 BTC <-- no fee
miner generates 0.17211342 BTC <-- no fee
miner generates 0.17212322 BTC <-- no fee
miner generates 0.16623322 BTC <-- no fee
miner generates 0.16611342 BTC <-- no fee
miner generates 0.16823322 BTC <-- no fee
miner transfers 2 BTC to marketplace <-- probably a 0.02 BTC fee
miner sells 2 BTC <-- no fee
(the fee size differs because the transaction complexity differs: 13 source balances and 2 result balances is more complex, and likely takes more kilobytes to describe)
Generation involves no fees.
However, if I remember it correctly, to transfer multiple balances created by separate generations, they must be joined together into a single transaction. It is my understanding that this process likely requires fees, and their size depends on the size of the transaction in kilobytes. I will try to demonstrate below:
Scenario 1:
miner generates 1.06220433 BTC <-- no fee
miner transfers 1.06220433 BTC to marketplace <-- no fee
miner sells 1.06220433 BTC <-- no fee
Scenario 2:
miner generates 1.06220433 BTC <-- no fee
miner generates 1.22000111 BTC <-- no fee
miner generates 1.81293888 BTC <-- no fee
miner transfers 4 BTC to marketplace <-- probably a 0.01 BTC fee
miner sells 4 BTC <-- no fee
(the transaction of taking 3 source balances and producing 2 result balances is sufficiently complex to require a fee for processing)
Scenario 3 (smaller payouts)
miner generates 0.17211322 BTC <-- no fee
miner generates 0.16623322 BTC <-- no fee
miner generates 0.16811342 BTC <-- no fee
miner generates 0.17211322 BTC <-- no fee
miner generates 0.16823322 BTC <-- no fee
miner generates 0.17411342 BTC <-- no fee
miner generates 0.19211322 BTC <-- no fee
miner generates 0.16723322 BTC <-- no fee
miner generates 0.17211342 BTC <-- no fee
miner generates 0.17212322 BTC <-- no fee
miner generates 0.16623322 BTC <-- no fee
miner generates 0.16611342 BTC <-- no fee
miner generates 0.16823322 BTC <-- no fee
miner transfers 2 BTC to marketplace <-- probably a 0.02 BTC fee
miner sells 2 BTC <-- no fee
(the fee size differs because the transaction complexity differs: 13 source balances and 2 result balances is more complex, and likely takes more kilobytes to describe)
I'm an idiot and clicked before thinking about it. Please leave it at 1 BTC. I also do not want increased fees. Thank you!
There are 0 fees anyways on Eligius, as the payouts are done via generated transactions.[Edit: As far as I understood it, as long as coins are generated at the same address, it shoudn't matter if they are 100* 1 Bitcent or 1*1 Bitcoin --> but if you switch accounts after each payout (for whatever reason?!) this might be a viable concern.]
I'm pro 16 bitcents (or 10 or 20 for that matter, to have a "nicer" number), as it would give faster/more regular payouts for smaller miners and also reduce the number of balances that need to be cached for max. 1 week. Didn't Eligius US fail yesterday because of this?
I don't have a strong opinion on the subject.
I voted "1 BTC", but I wouldn't mind it going either way.
There is a valid countrpoint to the way I voted: in future, 1 BTC is going to require much work to mine.
On the other hand, paying out too small amounts indeed increases fees -- when the miner finally wants to transfer their coins from the account which generated it, pretty much to anywhere else, they will have to create more complex transactions (more kilobytes), joining together many small amounts, and getting that into a block will cost fees.
I too suspect that perhaps a change in the "inactivity payout" would be of additional help. I imagine that if it were smaller, then if someone needed a payout (but was not close to reaching 1 BTC, or whatever the limit is at that point in future)... they could switch (e.g. from the US to the EU) server, and the server they left would send them a payout in X days (where perhaps, X could be less than 7).
I voted "1 BTC", but I wouldn't mind it going either way.
There is a valid countrpoint to the way I voted: in future, 1 BTC is going to require much work to mine.
On the other hand, paying out too small amounts indeed increases fees -- when the miner finally wants to transfer their coins from the account which generated it, pretty much to anywhere else, they will have to create more complex transactions (more kilobytes), joining together many small amounts, and getting that into a block will cost fees.
I too suspect that perhaps a change in the "inactivity payout" would be of additional help. I imagine that if it were smaller, then if someone needed a payout (but was not close to reaching 1 BTC, or whatever the limit is at that point in future)... they could switch (e.g. from the US to the EU) server, and the server they left would send them a payout in X days (where perhaps, X could be less than 7).
I'm an idiot and clicked before thinking about it. Please leave it at 1 BTC. I also do not want increased fees. Thank you!
The current method avoids more transaction fees. Besides, after one week of inactivity the rest is paid correct?
Maybe you should just lower that to 3 days for the impatient.
I certainly don't want more BTC being lost to transaction fee's for using your pool.
Maybe you should just lower that to 3 days for the impatient.
I certainly don't want more BTC being lost to transaction fee's for using your pool.
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?
Basically: should the pool pay you after you reach at least 0.16… BTC, or continue requiring a minimum of 1 BTC?
Jump to: