Topic: . (Read 2033 times)
Sukrim: That's a great solution for large pools, but it's totally impractical for small pools (IE - those that solve blocks in terms of hours, not minutes - which means most pools). If this were done, then the transactions wouldn't get processed for hours or days in some cases. It's a nice idea, but totally impractical.
This might be true if BTC were an actual currency. However, since it's just stored value in a specific system for all intents and purposes, I'm not sure what sort of legal repercussions could be brought to bear since BTC have no intrinsic value in and of themselves. I think the only marginally potential legal repercussion that could be brought to bear is a lack of payment for work performed, but that would be a really shaky legal position to take, since there is just an implied contract and nothing official.
In either case, I agree in principal that sane defaults are the way to go. I don't want to keep BTC around in case something does happen. I keep backups and such but that wouldn't help in the case of being hacked. Fortunately, most users withdraw most of the their BTC from my pool so I haven't been too worried about it.
Quote
However, by allowing users to store coins in the pool, pool operators effectively become depositary institutions i.e. banks. This could have all kinds of negative implications and risks for both users and pool operators. In some countries it is probably unlawful or even illegal to hold deposits (i.e. being a bank) without appropriate license. Hacking and theft it seems a commonplace these days. Why take risks and hold user deposits when they can be pushed out to user's accounts automatically as soon as money come in (or on some schedule).
This might be true if BTC were an actual currency. However, since it's just stored value in a specific system for all intents and purposes, I'm not sure what sort of legal repercussions could be brought to bear since BTC have no intrinsic value in and of themselves. I think the only marginally potential legal repercussion that could be brought to bear is a lack of payment for work performed, but that would be a really shaky legal position to take, since there is just an implied contract and nothing official.
In either case, I agree in principal that sane defaults are the way to go. I don't want to keep BTC around in case something does happen. I keep backups and such but that wouldn't help in the case of being hacked. Fortunately, most users withdraw most of the their BTC from my pool so I haven't been too worried about it.
As pools are verifying + processing transactions, the latest possible time a 100% free payout is possible is the next time the pool finds a block. However nearly no pool operators modify bitcoind to include custom transaction schemes, and some even pay forced transaction fees on their own for payouts! 
Mainframe currently allows a threshold settings defined by the user all the way down to 0.10 BTC. Any amounts exceeding a users threshold setting are paid out every 60 secs if we have a valid bitcoin payment address from you on file. We also pay out to the full 8 decimals.
We are contemplating making the default setting 0.10 BTC for all new users and retroactively setting this value to the same for any users currently having no threshold set at all. Its just a bit of a gray area i think because as Inaba states, there may be users who PREFER (for whatever reason) to keep their balance in the pool.
Im beginning to lean towards the idea that if users want a pool to act as a bank for their bitcoins, there should be some fees associated with that as there is some amount of risk involved with carrying large balance of coins for your users whether it be in hot or cold storage. The question is just what amount of risk exactly and should that be passed on to the user who wants to use a pool as a banking institution.
But generally speaking, Im with Vladimir in the sense that there should be no reason for a pool to be holding on to users' funds. It only introduces unnecessary risk for both the pool operator and the user.
We are contemplating making the default setting 0.10 BTC for all new users and retroactively setting this value to the same for any users currently having no threshold set at all. Its just a bit of a gray area i think because as Inaba states, there may be users who PREFER (for whatever reason) to keep their balance in the pool.
Im beginning to lean towards the idea that if users want a pool to act as a bank for their bitcoins, there should be some fees associated with that as there is some amount of risk involved with carrying large balance of coins for your users whether it be in hot or cold storage. The question is just what amount of risk exactly and should that be passed on to the user who wants to use a pool as a banking institution.
But generally speaking, Im with Vladimir in the sense that there should be no reason for a pool to be holding on to users' funds. It only introduces unnecessary risk for both the pool operator and the user.
http://ozco.in has an automatic payout script that runs hourly.Pays out entire balance to 8decimals when balance goes greater than the threshold that members set (minimum 0.1BTC).I guess we could run that every minute, but seems a bit pointless as we only pay out after 100 confirmations.
If funds are required more urgently members can chose to empty thier wallet by using the "manual payout" option.
What surprises me is the number of members that set a high auto payout limit and choose to store thier coins in the pools wallet.
"mindlessly" eh? we put a quite a lot of thought into what we do at Ozcoin.
Whilst "forced" payouts might suit you Vladimir obviously they dont suit everyone.
Thanks for your input but maybe you should look around at more pools if the ones you use do these bad things to you
If funds are required more urgently members can chose to empty thier wallet by using the "manual payout" option.
What surprises me is the number of members that set a high auto payout limit and choose to store thier coins in the pools wallet.
"mindlessly" eh? we put a quite a lot of thought into what we do at Ozcoin.
Whilst "forced" payouts might suit you Vladimir obviously they dont suit everyone.
Thanks for your input but maybe you should look around at more pools if the ones you use do these bad things to you
Just set higher payout limits then. What Vladimir wants to address I think, is that some pools don't offer automatic payouts at all, only manual.
Especially if you mine for some time and then want to purchase something, you first have to request a payout on the pool and wait until it gets into a block and then pay and wait again until this gets into a block. Because the transactions are fast after each other, the 2nd payment might even cost you fees. This is unnecessary somehow.
Especially if you mine for some time and then want to purchase something, you first have to request a payout on the pool and wait until it gets into a block and then pay and wait again until this gets into a block. Because the transactions are fast after each other, the 2nd payment might even cost you fees. This is unnecessary somehow.
It so happened that traditionally almost every pool for some reason has a setting 'send me money if my balance is above number'. Perhaps Slush have done this in his pool half a year ago and everyone mindlessly copied it.
Half a year ago, one bitcoin was almost nothing and I didn't want to spam every mined coins to wallets. For example, some users used (and they're still using) threshold in tens of BTC, to keep their wallets 'clean'. Actually I'm thinking about some high limit, because I don't want to keep high deposits. But still, everybody can set up threshold as low as 0.01 BTC, if he don't want to risk his BTC, so I don't see any issue in this. By default, threshold is already 1BTC, as you're proposing.
Today there's no reason to not pay all decimal places, except that somebody have to code&test it
. Dear pool operator,
It so happened that traditionally almost every pool for some reason has a setting 'send me money if my balance is above number'. Perhaps Slush have done this in his pool half a year ago and everyone mindlessly copied it.
This is bitcoin, once you got customers address there is no reason to keep any customer's bitcoins (let's say above 1BTC due to fees) in the pool unless pool operator wants to become a depositary institution or pull out mybitcoin or bitomat stunts.
Please do consider implementing forced payouts regime. For example, if you have customer's bitcoin address transfer all balances over 1 BTC, let's say, hourly or daily. The block chain is ALWAYS online.
It so happened that traditionally almost every pool for some reason has a setting 'send me money if my balance is above
This is bitcoin, once you got customers address there is no reason to keep any customer's bitcoins (let's say above 1BTC due to fees) in the pool unless pool operator wants to become a depositary institution or pull out mybitcoin or bitomat stunts.
Please do consider implementing forced payouts regime. For example, if you have customer's bitcoin address transfer all balances over 1 BTC, let's say, hourly or daily. The block chain is ALWAYS online.
Interesting, i've never actually thought about it that way, ill talk to everyone else and see what they say and we might implement it.
To add to this:
There is no reason not to send the whole 8 decimals out on each payment. Older clients don't magically delete these, they just don't display the correct amount.
Just write a warning message next to your payout field or whatever to make sure your users use the most current version of the bitcoin client.
Also:
Do some research about sendmany as well as how to hack bitcoind to allow your own transactions for free in your own blocks always. This guarantees that latest when you find your next block, all your own transactions will be included completely for free, no matter how "spammy" the client rates them.
A last warning:
Bitdust (tiny payout transactions) will increase transaction size and thus needs to settle down some time or it will cause forced transcation fees by the current bitcoin client implementation.
There is no reason not to send the whole 8 decimals out on each payment. Older clients don't magically delete these, they just don't display the correct amount.
Just write a warning message next to your payout field or whatever to make sure your users use the most current version of the bitcoin client.
Also:
Do some research about sendmany as well as how to hack bitcoind to allow your own transactions for free in your own blocks always. This guarantees that latest when you find your next block, all your own transactions will be included completely for free, no matter how "spammy" the client rates them.
A last warning:
Bitdust (tiny payout transactions) will increase transaction size and thus needs to settle down some time or it will cause forced transcation fees by the current bitcoin client implementation.
Jump to: