[BTC-TC] TAT.ASICMINER New Micro-share Passthrough!

[GGGGG]

@TAT

Here's another willing to return the extra dividend.

[mem]

Speaking for myself and the Girlfriend we will be happy to return the extra payouts.

[killerstorm]

Even if he refreshed the page, which is completely underestimating burnside if you think it would

FWIW I once bought twice the amount by clicking 'buy' button twice. Apparently it DOES NOT detect double form submission.

[Eric Muyser]

Even if he refreshed the page, which is completely underestimating burnside if you think it would

FWIW I once bought twice the amount by clicking 'buy' button twice. Apparently it DOES NOT detect double form submission.

Oh really? I'll check that sometime. But it *does not submit again on refresh* and this is not the case of him clicking submit twice - see the timestamps and I saw it with my own eyes.

The double click submit is a more common one, but people started handling that by disabling the button more commonly in 2011ish, so burnside is behind on that one.

[erpbridge]

If you are going to go the route of forcefully removing funds from user's accounts (which I would highly suggest against), make sure it is well published and that there is very transparent listing of what the amount is for each individual (even if its just a private lookup), and that there is plenty of forewarning.

Take the example of NoTroll.in, where the admin decided, due to a software bug, to go around and just remove funds from user's accounts with no warning, then publishing the reasoning afterwards. This led to a very serious backlash against the admin AND his service, and ultimately led to user's abandoning it in droves to the point that it shut down. This is definitely not the kind of thing you want happening to yourself, earning such a major blackspot on your record, by forcefully going around and removing funds.

The proper response is probably a hybrid of options offered here: When the problem is ultimately discovered as to source, whether user error or software error, both sides decide on an option in which TAT.ASICMINER is resolved. One of a couple options will probably present themselves.

Option A: TAT.ASICMINER puts dividends on hold for next week, as was suggested. (And make sure the reasoning for this is well announced ahead of time)
Option B: TAT and Burnside opt to collaborate to refund TAT.ASICMINER the funds (13.84 BTC) that were accidentally disbursed. This is a prime example of why an insurance of some sort needs to exist, to provide for errors such as this. If an insurance does not exist, then probably a withholding of profit or mandatory payment from one or both parties involved, in which each party puts in some money to refund the issue, perhaps even in a scheduled payment plan.
Option C: Combine Option B and also request voluntary payback of dividend. Record payback.

(I personally would suggest an announcement that Option A has been chosen, with the reasoning clearly stated. Another possibility would be, rather than flat out putting the dividend on hold, to pay out at a reduced rate... ie pay at 50 percent normal dividend for 2 weeks, or 75 percent dividend for one month. This is not the most ideal solution, as due to increased shares week over week, holding back 50 percent each of two weeks would probably come out to even more than the original overpayment was... But it is an option.)

Again, I would VERY HIGHLY suggest against a one-sided clawback of funds, as that is not a very good image for publicity.

[Eric Muyser]

If you are going to go the route of forcefully removing funds from user's accounts (which I would highly suggest against), make sure it is well published and that there is very transparent listing of what the amount is for each individual (even if its just a private lookup), and that there is plenty of forewarning.

Take the example of NoTroll.in, where the admin decided, due to a software bug, to go around and just remove funds from user's accounts with no warning, then publishing the reasoning afterwards. This led to a very serious backlash against the admin AND his service, and ultimately led to user's abandoning it in droves to the point that it shut down. This is definitely not the kind of thing you want happening to yourself, earning such a major blackspot on your record, by forcefully going around and removing funds.

The proper response is probably a hybrid of options offered here: When the problem is ultimately discovered as to source, whether user error or software error, both sides decide on an option in which TAT.ASICMINER is resolved. One of a couple options will probably present themselves.

Option A: TAT.ASICMINER puts dividends on hold for next week, as was suggested. (And make sure the reasoning for this is well announced ahead of time)
Option B: TAT and Burnside opt to collaborate to refund TAT.ASICMINER the funds (13.84 BTC) that were accidentally disbursed. This is a prime example of why an insurance of some sort needs to exist, to provide for errors such as this. If an insurance does not exist, then probably a withholding of profit or mandatory payment from one or both parties involved, in which each party puts in some money to refund the issue, perhaps even in a scheduled payment plan.
Option C: Combine Option B and also request voluntary payback of dividend. Record payback.

(I personally would suggest an announcement that Option A has been chosen, with the reasoning clearly stated. Another possibility would be, rather than flat out putting the dividend on hold, to pay out at a reduced rate... ie pay at 50 percent normal dividend for 2 weeks, or 75 percent dividend for one month. This is not the most ideal solution, as due to increased shares week over week, holding back 50 percent each of two weeks would probably come out to even more than the original overpayment was... But it is an option.)

Again, I would VERY HIGHLY suggest against a one-sided clawback of funds, as that is not a very good image for publicity.

Agree. The obvious is I don't think $1730 is worth it to burnside to do a forceful undo. Much better to let it slide, and announce it as a gift of sorts. Hey, it's not the worst bug in the world, and so long as he fixes it.

[daemondazz]

(I personally would suggest an announcement that Option A has been chosen, with the reasoning clearly stated. Another possibility would be, rather than flat out putting the dividend on hold, to pay out at a reduced rate... ie pay at 50 percent normal dividend for 2 weeks, or 75 percent dividend for one month. This is not the most ideal solution, as due to increased shares week over week, holding back 50 percent each of two weeks would probably come out to even more than the original overpayment was... But it is an option.)

The issue with that is:

1) I have shares now, I sell them all, I get to keep extra dividend.
2) I have no shares now, I buy some, I don't get any dividend next week.

I'd suggest Option C.

[Lorren]

(I personally would suggest an announcement that Option A has been chosen, with the reasoning clearly stated. Another possibility would be, rather than flat out putting the dividend on hold, to pay out at a reduced rate... ie pay at 50 percent normal dividend for 2 weeks, or 75 percent dividend for one month. This is not the most ideal solution, as due to increased shares week over week, holding back 50 percent each of two weeks would probably come out to even more than the original overpayment was... But it is an option.)

The issue with that is:

1) I have shares now, I sell them all, I get to keep extra dividend.
2) I have no shares now, I buy some, I don't get any dividend next week.

I'd suggest Option C.

I don't like option A.  With that option, there's nothing to stop someone from selling their shares for two weeks, putting their money somewhere else for a little bit, and then repurchasing when the reduced dividends are over.  I have a little bit in BTC that I have to reinvest after liquidating my AMC shares, but I'm less likely to invest in TAT for a couple of weeks if I know that there are dividends that other people received that causes me to get less money.  That could affect the price of TAT relative to AM over the dividend repayment period as well.

[freedomno1]

Option A
Seems easiest but as TAT pointed out not fair to new investors for the week that said it would be only one week
Option B
Taking the hit makes it seem like were just running away with the money
That said building a small insurance provision in case of accidents might be the solution if the board wants to pay a microfee for that
Or forcing an improvement of the software which works well for the most part to be closer to perfect to prevent these errors And prevent future incidents although no system is perfect taking responsibility for software errors would build up goodwill and be a darn good incentive to prevent errors from happening again That said I don't feel like putting the blame on them so would choose C myself
Option C
Well that's fine as well

Not bad for an options list would not recommend a force seizure but then again the argument would be that it's not technically their dividends
Also A NOTICE IS IMPORTANT Nottrollin was definitely exhibit A of a fail took a flat fee from all accounts for a 1 week period even if they had a lot of holdings before that incident
13 BTC is not to much at this point but still is a fair amount

There are transaction ID's on all the users that received dividends so B probably works and so waits for burnside and TAT

[TadpolesIsAWinner]

(I personally would suggest an announcement that Option A has been chosen, with the reasoning clearly stated. Another possibility would be, rather than flat out putting the dividend on hold, to pay out at a reduced rate... ie pay at 50 percent normal dividend for 2 weeks, or 75 percent dividend for one month. This is not the most ideal solution, as due to increased shares week over week, holding back 50 percent each of two weeks would probably come out to even more than the original overpayment was... But it is an option.)

The issue with that is:

1) I have shares now, I sell them all, I get to keep extra dividend.
2) I have no shares now, I buy some, I don't get any dividend next week.

I'd suggest Option C.

BUT, he has a list of everyone who received the double dividend, so the decreased dividends would only be sent out to those on the list, not new shareholders.

As far as people who sold their shares "now" and kept the extra dividend, I don't think there's anything he can do about that, but at least the decreased dividends option would cut his losses a bit.  If they tried to buy back in later after the dividend decrease was over, they'd still have his username on their list!  You're on the god damned list buddy!  If the person decided to sell, create a new user, then transfer funds to that user, then buy back after the dividend decrease was over, then he could very well be losing $ since the buy back price in a month will probably up around 3BTC (wishful thinking), and it wouldn't be worth all that effort.  

(Not bad for my first post out of the newbie forum!)

[Bitcycle]

There is no perfect option, and any of them allow for unscrupulous people to exploit them. 

Having said that, option C does look best.  Notify everyone of the error and ask for them to return the money.  I certainly will, and I imagine most will as well.


If they do decide to remove the funds in some non-voluntary way, they must MUST MUST communicate this clearly and effectively to the users, preferably several times in as many channels as possible. 

They'd be risking reputation with that path, and their reputation affects us all.  Communication is absolutely essential on that path.

[circuitry]

I have a meager 25 TAT shares, but I'm happy to return the extra dividend money.

[killerstorm]

Oh really? I'll check that sometime. But it *does not submit again on refresh*

I've just checked: you're wrong. I've just submitted two orders instead of one this way, both on litecoinglobal and on btct. It is easily reproducible:

You need to wait until it shows redirect page, and then hit F5 before redirect happens Browser asks whether you want to submit form again.

And it is trivial to reproduce multiple click on a button problem too.

While we are here, I'll explain how it should be done:

1. There should be protection entirely on server side. You cannot rely on things which happen outside of your server. Doing a redirect DOES NOT solve the root problem. Blocking buttons with JS DOES NOT solve the problem.

2. Each form should get an extra field with unique ID generated on server. (If you feel like that you can make it server-signed, then it doubles as CSRF protection. But it isn't necessary. Any random ID is fine in this context.)

3. When server receives POST request it should check whether form with such ID was already submitted. If yes, cancel and show error. If no, add ID to database and perform the action. (If you use proper SQL database you can just rely on unique constraint: DB won't allow you to add ID more than once, so it is secure against all sorts of race conditions as long as SQL database is properly implemented.)

People who write web applications usually only consider how it works in ideal case when communication is instant and there is no way to get it aborted in process.

But they really should understand that client and server communicate with each other with use of a certain protocol. The fact that we have HTML and JS on one side and PHP on other side changes nothing, it is still a protocol.

And so if you have a protocol message which submits an order, you need to consider a scenario where such message gets sent twice. As there is non-instantaneous communication there is no way to make sure that client and server state are synchronized (Byzantine general problem is applicable here), so... see above.

Blocking buttons is only a cosmetic solution, you can't really rely on it...

It's a bit easier to understand this when application is AJAX because at least you see an "API", but still developers fail to understand that communication between client and server isn't perfect. ICBIT.se got a lot of flak because of a problem with  client and server state not in sync.

[burnside]

I had a whole reply put together on my laptop and the battery died, so I'm stuck retyping this on my phone. 

Here's what happened:

Div 1: scheduled
Div 1: started processing a minute later
Div 1: cancelled (~10 mins after it started processing)
Div 2: scheduled
Div 1: completed
Div 2: completed

The cancel failed because the div was already being processed.  I have fixed the system so you can now see when a div is in progress and it will not cancel.

I have reimbursed TAT for the double div and I have initiated a recovery process whereby anyone that received a double dividend will see a balance reduction of whichever was the lesser of the two dividends.  This way no one gets burned if they traded between when the first div processed and when the second div processed.

The site's going to lose ~1 BTC on this bug, but hopefully this resolution is as fair as possible to everyone involved.

Cheers

[freedomno1]

I had a whole reply put together on my laptop and the battery died, so I'm stuck retyping this on my phone.  

Here's what happened:

Div 1: scheduled
Div 1: started processing a minute later
Div 1: cancelled (~10 mins after it started processing)
Div 2: scheduled
Div 1: completed
Div 2: completed

The cancel failed because the div was already being processed.  I have fixed the system so you can now see when a div is in progress and it will not cancel.

I have reimbursed TAT for the double div and I have initiated a recovery process whereby anyone that received a double dividend will see a balance reduction of whichever was the lesser of the two dividends.  This way no one gets burned if they traded between when the first div processed and when the second div processed.

The site's going to lose ~1 BTC on this bug, but hopefully this resolution is as fair as possible to everyone involved.

Cheers

Thanks for the reply and I FUU when my laptop battery dies on me *_*
Just curious when will I get an e-mail notification on one of the two balances
And Thanks for resolving this

[Lorren]

Thank you.

[ThickAsThieves]

I had a whole reply put together on my laptop and the battery died, so I'm stuck retyping this on my phone. 

Here's what happened:

Div 1: scheduled
Div 1: started processing a minute later
Div 1: cancelled (~10 mins after it started processing)
Div 2: scheduled
Div 1: completed
Div 2: completed

The cancel failed because the div was already being processed.  I have fixed the system so you can now see when a div is in progress and it will not cancel.

I have reimbursed TAT for the double div and I have initiated a recovery process whereby anyone that received a double dividend will see a balance reduction of whichever was the lesser of the two dividends.  This way no one gets burned if they traded between when the first div processed and when the second div processed.

The site's going to lose ~1 BTC on this bug, but hopefully this resolution is as fair as possible to everyone involved.

Cheers

Thanks Burnside, I knew I could count on you to not only solve this, but do so cleanly and professionally!

[Franktank]

I had a whole reply put together on my laptop and the battery died, so I'm stuck retyping this on my phone. 

Here's what happened:

Div 1: scheduled
Div 1: started processing a minute later
Div 1: cancelled (~10 mins after it started processing)
Div 2: scheduled
Div 1: completed
Div 2: completed

The cancel failed because the div was already being processed.  I have fixed the system so you can now see when a div is in progress and it will not cancel.

I have reimbursed TAT for the double div and I have initiated a recovery process whereby anyone that received a double dividend will see a balance reduction of whichever was the lesser of the two dividends.  This way no one gets burned if they traded between when the first div processed and when the second div processed.

The site's going to lose ~1 BTC on this bug, but hopefully this resolution is as fair as possible to everyone involved.

Cheers

Props on handling it in a professional way

[m_yaw]

[...] I have initiated a recovery process whereby anyone that received a double dividend will see a balance reduction of whichever was the lesser of the two dividends.  [...]

I don't see this balance reduction yet.

Also, I hope this fix will solve the case where the double dividends are equal in value? (i.e. amount of shares stayed the same?)

[daemondazz]

I have reimbursed TAT for the double div and I have initiated a recovery process whereby anyone that received a double dividend will see a balance reduction of whichever was the lesser of the two dividends.  This way no one gets burned if they traded between when the first div processed and when the second div processed.

Very glad you've been able to determine the problem and resolve it. Making systems more resilient is always good!

I am not sure what my balance was before you initiated the recovery process, and there is no withdrawal listed in my wallet page, so how do I determine if you've completed the recovery action?