wished i would have read this thread before withdraw
https://blockchain.info/tx/aa112f1953102450180f1549a2bba4626596484d375b8ba3152d7decca263725
i sent it to shapeshift. for return address, i put my own wallet addy in there instead of mp addy i withdrew from.
will this be ok?
Topic: ⎛🌟🔴🌟🎲🌟🔴🌟MONEYPOT.com -- Crypto Casino Suite and Web Wallet 🌟🔴🌟🎲🌟🔴🌟 - page 15. (Read 30130 times)
March 11, 2017, 03:24:07 PM
March 10, 2017, 05:42:18 PM
My withdrawal request went to pending then manually pushed through and it was sent with 34S/b transaction fee along with many dust inputs 
Be careful when withdrawing it will most likely get stuck until Moneypot fix this issue
Be careful when withdrawing it will most likely get stuck until Moneypot fix this issue
March 10, 2017, 06:52:33 AM
I know it's not a very high priority at the moment, but any ETA on when socketpot will be fixed? It's having a very negative effect on my DiceBot app even though the main betting isn't dependant on the socketpot.
very interested to hear the answer for this question. thx for asking cause I thought I am the only one
March 10, 2017, 06:50:23 AM
I know it's not a very high priority at the moment, but any ETA on when socketpot will be fixed? It's having a very negative effect on my DiceBot app even though the main betting isn't dependant on the socketpot.
March 09, 2017, 07:25:11 PM
I personally have attempted to abandon the transaction. The RPC states that the transaction is not eligible for abandonment.
FWIW all wallet transactions are eligible for abandonment, abandonment is not something that spreads on the network or anything -- it's purely a local thing to stop it continually broadcasting it. In your case, as you've credited his account you'll want to abandon it to make it less likely to confirm (and easier to conflict).
The only reason I can think you'd have trouble abandoning it, is if you've got child transactions from it (which you need to abandon first) or if you haven't cleared your mempool
I've cleared the mempool. The possibility of child transactions does exist. I will continue to investigate.
March 09, 2017, 06:46:44 PM
I personally have attempted to abandon the transaction. The RPC states that the transaction is not eligible for abandonment.
FWIW all wallet transactions are eligible for abandonment, abandonment is not something that spreads on the network or anything -- it's purely a local thing to stop it continually broadcasting it. In your case, as you've credited his account you'll want to abandon it to make it less likely to confirm (and easier to conflict).
The only reason I can think you'd have trouble abandoning it, is if you've got child transactions from it (which you need to abandon first) or if you haven't cleared your mempool
March 09, 2017, 06:23:01 PM
My question is regarding this "Relay time : Wednesday, March 8th 2017, 21:29:39 -05:00" - Noticed that appearing there last night, is 'relay' meaning it's after 3 days that a miner / node first saw this tx as potentially mineable, or is it the time at which it was 'relayed' back to sender (and would now be sitting in some MP wallet other than my account balance, as the sending user) ..?
Just curious what that entry really means
Just curious what that entry really means
The "first seen" is self-descriptive, it's the time that blocktrail first saw the transaction. This was went it was first made. The "relay" time is the *last* time it saw it. Wallets like bitcoin core will continually rebroadcast transactions (every 24h?) so that the network doesn't forget about it (most nodes expire mempool transactions after 48-72h). In your case, this is the opposite of what you want (I guess they forgot to `abandontransaction` on it).
The simplest solution would be to use CPFP to push the transaction through. Either you could do that (using the output they sent to) or moneypot could do it (using the change address) and it would confirm with ~30 minutes or so
I personally have attempted to abandon the transaction. The RPC states that the transaction is not eligible for abandonment.
The user above's account has been credited. I believe his question was more out of curiosity.
Thanks for your explanations Ryan & Craig, as always
Today I learned
So I guess this explains what happened.. this whole time I had thought MP had decided to wait until this tx was fully abandoned before crediting me haha, it's rather that they thought they had done so, probably based on the messages exchanged earlier in the thread, but then other things must've got mixed up and someone forgot to actually do it.
Maybe it's when DogeD sent me BTC from his wallet to one of my off-site wallets, and then I tipped him on MP to his account ; That was not a case of me being tipped/credited to my MP account, and the amount is different than 6666 anyway.
I checked each MP account, no 6666 bits received (or 5666 - you can fairly charge me that full withdraw fee for failed tx) in my balances anywhere. The withdraw had been done Sunday on this account. Assuming it will be credited by ~tomorrow or so :s
Again sorry to be a bother w/ such "small" amount - I wouldn't normally, except that I busted and there is an MP contest going on =P
Thanks
March 09, 2017, 05:51:45 PM
My question is regarding this "Relay time : Wednesday, March 8th 2017, 21:29:39 -05:00" - Noticed that appearing there last night, is 'relay' meaning it's after 3 days that a miner / node first saw this tx as potentially mineable, or is it the time at which it was 'relayed' back to sender (and would now be sitting in some MP wallet other than my account balance, as the sending user) ..?
Just curious what that entry really means
Just curious what that entry really means
The "first seen" is self-descriptive, it's the time that blocktrail first saw the transaction. This was went it was first made. The "relay" time is the *last* time it saw it. Wallets like bitcoin core will continually rebroadcast transactions (every 24h?) so that the network doesn't forget about it (most nodes expire mempool transactions after 48-72h). In your case, this is the opposite of what you want (I guess they forgot to `abandontransaction` on it).
The simplest solution would be to use CPFP to push the transaction through. Either you could do that (using the output they sent to) or moneypot could do it (using the change address) and it would confirm with ~30 minutes or so
I personally have attempted to abandon the transaction. The RPC states that the transaction is not eligible for abandonment.
The user above's account has been credited. I believe his question was more out of curiosity.
March 09, 2017, 05:32:46 PM
My question is regarding this "Relay time : Wednesday, March 8th 2017, 21:29:39 -05:00" - Noticed that appearing there last night, is 'relay' meaning it's after 3 days that a miner / node first saw this tx as potentially mineable, or is it the time at which it was 'relayed' back to sender (and would now be sitting in some MP wallet other than my account balance, as the sending user) ..?
Just curious what that entry really means
Just curious what that entry really means
The "first seen" is self-descriptive, it's the time that blocktrail first saw the transaction. This was went it was first made. The "relay" time is the *last* time it saw it. Wallets like bitcoin core will continually rebroadcast transactions (every 24h?) so that the network doesn't forget about it (most nodes expire mempool transactions after 48-72h). In your case, this is the opposite of what you want (I guess they forgot to `abandontransaction` on it).
The simplest solution would be to use CPFP to push the transaction through. Either you could do that (using the output they sent to) or moneypot could do it (using the change address) and it would confirm with ~30 minutes or so
March 09, 2017, 05:01:25 PM
Ah 
I'm gonna look a bit like a fool here since I don't know after all this time the details of how tx failure is handled on the network ; But I thought transactions were dropped from mempool / returned to sender after 3 days - it's been 90 hours now and still trying to confirm this mistake..?
My question is regarding this "Relay time : Wednesday, March 8th 2017, 21:29:39 -05:00" - Noticed that appearing there last night, is 'relay' meaning it's after 3 days that a miner / node first saw this tx as potentially mineable, or is it the time at which it was 'relayed' back to sender (and would now be sitting in some MP wallet other than my account balance, as the sending user) ..?
Just curious what that entry really means
I'm gonna look a bit like a fool here since I don't know after all this time the details of how tx failure is handled on the network ; But I thought transactions were dropped from mempool / returned to sender after 3 days - it's been 90 hours now and still trying to confirm this mistake..?My question is regarding this "Relay time : Wednesday, March 8th 2017, 21:29:39 -05:00" - Noticed that appearing there last night, is 'relay' meaning it's after 3 days that a miner / node first saw this tx as potentially mineable, or is it the time at which it was 'relayed' back to sender (and would now be sitting in some MP wallet other than my account balance, as the sending user) ..?
Just curious what that entry really means
Eventually, miners will drop it from their unconfirmed backlog and the transaction will remain spent in our wallet. If we wish to use these funds, we would need to create a double spend.
The fund will not be re-credited to the address owner on MP's system if that is what you are asking?
March 09, 2017, 04:51:00 PM
Ah I'm gonna look a bit like a fool here since I don't know after all this time the details of how tx failure is handled on the network ; But I thought transactions were dropped from mempool / returned to sender after 3 days - it's been 90 hours now and still trying to confirm this mistake..?
My question is regarding this "Relay time : Wednesday, March 8th 2017, 21:29:39 -05:00" - Noticed that appearing there last night, is 'relay' meaning it's after 3 days that a miner / node first saw this tx as potentially mineable, or is it the time at which it was 'relayed' back to sender (and would now be sitting in some MP wallet other than my account balance, as the sending user) ..?
Just curious what that entry really means
I'm gonna look a bit like a fool here since I don't know after all this time the details of how tx failure is handled on the network ; But I thought transactions were dropped from mempool / returned to sender after 3 days - it's been 90 hours now and still trying to confirm this mistake..?My question is regarding this "Relay time : Wednesday, March 8th 2017, 21:29:39 -05:00" - Noticed that appearing there last night, is 'relay' meaning it's after 3 days that a miner / node first saw this tx as potentially mineable, or is it the time at which it was 'relayed' back to sender (and would now be sitting in some MP wallet other than my account balance, as the sending user) ..?
Just curious what that entry really means
March 08, 2017, 10:28:40 PM
How long for a withdrawal to be processed?
Your request exceeded the hot wallet. We once the top off confirms we will send your transacation.
March 08, 2017, 10:15:17 PM
How long for a withdrawal to be processed?
March 08, 2017, 06:03:47 PM
With the 1 BILLION'th Game on MoneyPot
BTCDragon Casino has added its own additional Promo
https://btcdragon.com
BTCDragon Casino has added its own additional Promo
https://btcdragon.com
March 08, 2017, 11:43:50 AM
Good luck guys.
Hey!! Getting pretty close to ONE BILLION! Hard to keep up but at around 992,636,382 & counting fast. Just wanted to say thanks for the wonderful promotion once again and wish everyone good luck. *Since I finished typing this we are up to bet ID 992640610
Also - Wonderful update on Slot & Go Poker for Bit-Exo, J_Roc - Lots of fun. A very creative & well-made game my friend.
March 06, 2017, 02:42:27 PM
The inputs are not feasible to spend. We have had several transactions that we have paid very large transaction fees on. We have had a few that were .1 for .005 transactions.
That's such a waste of money to miners, the bitcoin protocol allows so easily. Ridiculous. No way ready for anything remotely close to business mainstream adoption. I'd be beyond enraged even as an entrepreneur if I spent $130 fees for $6 items - that's completely past 'cost of doing business'.
March 06, 2017, 10:18:18 AM
everyone is invited to give his vote to our MP related Poll
https://bitcointalksearch.org/topic/m.18072174
https://bitcointalksearch.org/topic/m.18072174
March 06, 2017, 12:50:21 AM
.. for the time being we capped fees as it was generating large unnecessary fees.
I don't really understand this. The fees are based on (kilo)bytes and bitcoind should be able to calculate this properly. Therefor it would be large necessary fees 
Right now it seems players make withdrawals that will never be confirmed. That is only annoying for your real players and also for you, as you will have to manually verify/credit them again after 72h.If the micro deposits didn't get credited and the inputs are feasible to spend (which it indeed is), you would not lose money even if you have large fees? Again, might be better to make 1 big transaction. Or like RHavar said, lock those outputs and make 1 big transaction when mempool is low.
Either way, temporarily stopping withdrawals and fixing the problem (by locking inputs either by that code commit or manually) seems better than sending withdrawals with way too low fee IMO
The inputs are not feasible to spend. We have had several transactions that we have paid very large transaction fees on. We have had a few that were .1 for .005 transactions.
March 06, 2017, 12:32:07 AM
.. for the time being we capped fees as it was generating large unnecessary fees.
I don't really understand this. The fees are based on (kilo)bytes and bitcoind should be able to calculate this properly. Therefor it would be large necessary fees Right now it seems players make withdrawals that will never be confirmed. That is only annoying for your real players and also for you, as you will have to manually verify/credit them again after 72h.If the micro deposits didn't get credited and the inputs are feasible to spend (which it indeed is), you would not lose money even if you have large fees? Again, might be better to make 1 big transaction. Or like RHavar said, lock those outputs and make 1 big transaction when mempool is low.
Either way, temporarily stopping withdrawals and fixing the problem (by locking inputs either by that code commit or manually) seems better than sending withdrawals with way too low fee IMO
March 06, 2017, 12:30:31 AM
It looks like some of the inputs from the transaction posted above have only one transaction ever sent to it. Did the attacker have you generate a bunch of deposit addresses and then deposit very small amounts to each of them? Or how did the attacker get so many of your addresses?
If it is fairly clear that a single customer was behind the attack, and his account was not credited anything from the spam deposits, then I would suggest that you simply make a large transaction with a market fee (according to https://bitcoinfees.21.co/ or some other site), and use the money as you wish.
If however the spam deposits went to addresses that appear to be associated with random accounts, then I would do something to make bitcoind ignore these inputs, as they were very likely intended to break your customer's privacy. If they were guessing that 100 addresses belong to MP, knew with certainty that 25 of the addresses belonged to MP, then if you sign a transaction with a private key to an address that the attacker both knew belonged to MP, and that he guessed to belong to MP, then the attacker will be able to use blockchain analysis to discover more of your addresses and will know when some of your customers have deposited into MP, a fact that some customers may have wanted to keep secret.
If it is fairly clear that a single customer was behind the attack, and his account was not credited anything from the spam deposits, then I would suggest that you simply make a large transaction with a market fee (according to https://bitcoinfees.21.co/ or some other site), and use the money as you wish.
If however the spam deposits went to addresses that appear to be associated with random accounts, then I would do something to make bitcoind ignore these inputs, as they were very likely intended to break your customer's privacy. If they were guessing that 100 addresses belong to MP, knew with certainty that 25 of the addresses belonged to MP, then if you sign a transaction with a private key to an address that the attacker both knew belonged to MP, and that he guessed to belong to MP, then the attacker will be able to use blockchain analysis to discover more of your addresses and will know when some of your customers have deposited into MP, a fact that some customers may have wanted to keep secret.
Jump to: