Topic: [BTC-TC] TAT.ASICMINER New Micro-share Passthrough! - page 12. (Read 37852 times)
No worries, thanks:)
Hi Burnside,
Quick question if I may on the automatic re-investment option - does that only work for the same stock, or will it re-invest all dividends into what's set up? Eg, will it re-invest dividends from ASICMINER-PT into TAT.ASICMINER?
Thanks
Quick question if I may on the automatic re-investment option - does that only work for the same stock, or will it re-invest all dividends into what's set up? Eg, will it re-invest dividends from ASICMINER-PT into TAT.ASICMINER?
Thanks
It works only for the stocks you have it turned on for and works by adding up how much you get in divs on that single stock over time until enough has come in to be able to afford more of that particular stock. Important note here, it does not reserve the funds, so it's on you to leave the div funds in place while it adds up.
It would be interesting to try to do something that pooled all the stocks you selected, but it would be very tricky since there's a wide array of prices and the exchange does not do fractional shares.
Thank's for fixing this. Kind of shows that mistakes happen but it appears you handled this very professionally, Burnside.
I am happy with the way BTC-TC is setup and running as an end user.
I am happy with the way BTC-TC is setup and running as an end user.
Hi Burnside,
Quick question if I may on the automatic re-investment option - does that only work for the same stock, or will it re-invest all dividends into what's set up? Eg, will it re-invest dividends from ASICMINER-PT into TAT.ASICMINER?
Thanks
Quick question if I may on the automatic re-investment option - does that only work for the same stock, or will it re-invest all dividends into what's set up? Eg, will it re-invest dividends from ASICMINER-PT into TAT.ASICMINER?
Thanks
This whole thing reminds me of Animal Farm
Great to see that you guys are resolving this professionally and promptly. This small bump (in the whole scheme of things), isn't any worse than the flash crashes that happen in individual stocks all the time. (yes, totally different, I am just speaking in terms of severity).
or the complete botching of the Facebook IPO, or the whole "oh no some HFT asshat caused a flash crash! lets reverse the trades so they don't lose any money because it wouldn't be fare to make them pay for being asshats who try to time the market and skip the queue when making trades", or any number of SEC sanctioned screwups that are always 100% designed to protect institutional interests and screw retail.
/rant
Great to see that you guys are resolving this professionally and promptly. This small bump (in the whole scheme of things), isn't any worse than the flash crashes that happen in individual stocks all the time. (yes, totally different, I am just speaking in terms of severity).
FYI Burnside, my second div payment is still there and is also equal to the first payment in amount.
Lots of good questions.
- Unfortunately in the interest of expediency I did not script this fix via site code. I did it using a shell script making bitcoind requests. This means there is not (yet) a database record of what was recovered, it's all in bitcoind transactions.
- The script was setup to not send accounts negative. If an account didn't have the funds, we just moved on to the next account. There were a few of these, I suspect mostly due to the dividend reinvestment feature spending it.
- The account balance differences show up somewhat delayed because the site caches your balance until you do an operation like a withdrawal or trade.
- The selection for how much to pull out was done manually by taking the logs of each dividend process and doing a merge. Thus situations where the share counts lined up were no problem, and I pulled out all the dupes by hand where the payout was higher. This left all of the payouts that were the same or lower for my script to process.
Hope that all makes sense. I still need to write a second script to send everyone an email and remove the database entries for the extra deposits. I'll try to get that going today.
Cheers
- Unfortunately in the interest of expediency I did not script this fix via site code. I did it using a shell script making bitcoind requests. This means there is not (yet) a database record of what was recovered, it's all in bitcoind transactions.
- The script was setup to not send accounts negative. If an account didn't have the funds, we just moved on to the next account. There were a few of these, I suspect mostly due to the dividend reinvestment feature spending it.
- The account balance differences show up somewhat delayed because the site caches your balance until you do an operation like a withdrawal or trade.
- The selection for how much to pull out was done manually by taking the logs of each dividend process and doing a merge. Thus situations where the share counts lined up were no problem, and I pulled out all the dupes by hand where the payout was higher. This left all of the payouts that were the same or lower for my script to process.
Hope that all makes sense. I still need to write a second script to send everyone an email and remove the database entries for the extra deposits. I'll try to get that going today.
Cheers
Thanks for resolving this smoothly, just one more thing:
+1 to this, isn't there any way to remove it? Because AFAIK, if I do the math right now (i.e. try to hold a correct accounting / settlement using API), I will have a mismatch because of the 'shadow' transaction, or am I wrong about this?
Furthermore, the duplicate dividend should have to be removed from the history too, otherwise it would screw up the statistics (both the asset statistics and the personal ones).
+1 to this, isn't there any way to remove it? Because AFAIK, if I do the math right now (i.e. try to hold a correct accounting / settlement using API), I will have a mismatch because of the 'shadow' transaction, or am I wrong about this?
Kudos on a quick and professional solution to the problem.
...
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 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.
...
Personally, I have no problem with that.
I would also expect that your "lesser dividend selection algorithm" will not fail if both dividends are exactly the same to the single Satoshi. :-]. This is my case.
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
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
Im happy with that , fair is fair.
What happens if the double payment recovery makes one's balance go negative?
I didn't realize a bug had happened at first and reinvested in TAT shares (the overpayment amount to a little over a dollar, so I'm not worried about paying it back- I just don't want my account closed or something).
I didn't realize a bug had happened at first and reinvested in TAT shares (the overpayment amount to a little over a dollar, so I'm not worried about paying it back- I just don't want my account closed or something).
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
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 very much for the information and fix! Keep up the great work!
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?
[...] 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?)
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
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
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
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!
Thank you.
Jump to: