Eligius pool POLL: New minimum payout

[Luke-Jr]

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?

[LegitBit]

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.

[horrorshow]

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!

[cpunks]

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

[Sukrim]

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?

[cpunks]

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)

[Sukrim]

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.

[cpunks]

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

[cpunks]

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:

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

[cpunks]

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.

[Sukrim]

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

[Artefact2]

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

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.

[Sukrim]

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?

[Luke-Jr]

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.

[Sukrim]

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.

[Luke-Jr]

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.

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

[hughes]

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.

[WNS]

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.

[Wildfire]

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?

[Luke-Jr]

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.