Pages:
Author

Topic: A successful DOUBLE SPEND US$10000 against OKPAY this morning. - page 2. (Read 123958 times)

legendary
Activity: 1176
Merit: 1015
It has been more than a year. I think this is the only instance of successful double spending of a 6-confirmation transaction. Have anything been done to address this problem? Comparing with those fancy applications, this involves the very fundamental principle: transaction irreversibility. If it is not fixed, I am sure it will happen again when we have another unexpected fork and the harm could be much more serious.

I wonder how it can be fixed?

Perhaps the client once seeing two similar chains is put into safe mode until an obvious longer chain emerges. Once one chain is perhaps 6 confirm ahead then automatically go out of safe mode and resume using the longest chain.

This solution would require no central control and can be automated by the nodes.

The important aspect would be the detection mechanism and watching two chains until there is a clear winner.
legendary
Activity: 1778
Merit: 1008
It has been more than a year. I think this is the only instance of successful double spending of a 6-confirmation transaction. Have anything been done to address this problem? Comparing with those fancy applications, this involves the very fundamental principle: transaction irreversibility. If it is not fixed, I am sure it will happen again when we have another unexpected fork and the harm could be much more serious.

Because this required a fork, I don't think there's anything that can be done. I mean, the entire system of bitcoin relies on forks not occurring. I'm no Dev though, so don't take my word as law.
legendary
Activity: 1792
Merit: 1087
It has been more than a year. I think this is the only instance of successful double spending of a 6-confirmation transaction. Have anything been done to address this problem? Comparing with those fancy applications, this involves the very fundamental principle: transaction irreversibility. If it is not fixed, I am sure it will happen again when we have another unexpected fork and the harm could be much more serious.
legendary
Activity: 1358
Merit: 1002
why is ok support using a comma and decimal point in the same post

Probably both values copy pasted from previous messages or one of them c/p and the other written by the support person.
legendary
Activity: 1344
Merit: 1000
Just received a telephone call from OKPAY. The double spend money has been refunded to them. They promise me to send me my 64.xxx BTC within 15 minutes after they receive my refund. Please see if they respect their promise: 1J1F3U7gHrCjsEsRimDJ3oYBiV24wA8FuV This address should receive 64.xxx BTC before 09:30 UTC.



This is not the way to do customer service. If not this incident, I don't know when they start to care me and return me the 64.xxx BTC.

why is ok support using a comma and decimal point in the same post
legendary
Activity: 1778
Merit: 1008
Maybe the problem it that there is one implementation (bitcoind / bitcoin-qt) that decides what is right and what is not for the majority of the network. Bitcoin relies on a state when the vast majority of the network agree on the rules. That may not be the case when a single bug affects a large portion of the network. Under these conditions the whole proof of work mechanism becomes unreliable.

If we had a variety of implementations, a bug in one of them would have much smaller impact. Only users of the buggy client would be required to upgrade. We would not have to take the generally wrong way of downgrading to a buggy version.

this is why the discussion of a "bitcoin spec" is ongoing and of worth. check the dev sub forum.
sr. member
Activity: 462
Merit: 250
Maybe the problem it that there is one implementation (bitcoind / bitcoin-qt) that decides what is right and what is not for the majority of the network. Bitcoin relies on a state when the vast majority of the network agree on the rules. That may not be the case when a single bug affects a large portion of the network. Under these conditions the whole proof of work mechanism becomes unreliable.

If we had a variety of implementations, a bug in one of them would have much smaller impact. Only users of the buggy client would be required to upgrade. We would not have to take the generally wrong way of downgrading to a buggy version.
sr. member
Activity: 324
Merit: 260
I later manually corrected the issue with another transaction, thus double spend.

For post-mortem analysis, would you mind sharing how that raw transaction was broadcast?  Through bitcoin-Qt/bitcoind I presume?   But was this just connecting to peers or had you actually explicitly connected to a mining pool or well connected node?

The question is that most peers would have rejected it because they should already have known of the original transaction (12814b8ad57ce5654ba69eb26a52ddae1bff42093ca20cef3ad96fe7fd85d195) and not relayed your double spend (762443f6373b7c8b3833d4ad23578fc3099cc29b86d1359d0c0565e3c8614f91).  

With all the nodes reverting to 0.7 and/or starting up with an empty memory pool it is not impossible for your node to have reached one of them with no knowledge of the original transaction and then because your double spend transaction was perfectly valid for that node to relay your transaction got relayed to other new nodes as well.  Eventually then there would be a path that would reach the miner who eventually mined 225466 (the block with the double spend) -- BTC Guild [Edit: Yes, confirmed BTC Guild, per the coinbase].


Code:
$ git diff src/rpcrawtransaction.cpp
diff --git a/src/rpcrawtransaction.cpp b/src/rpcrawtransaction.cpp
index e634ed7..1f045e8 100644
--- a/src/rpcrawtransaction.cpp
+++ b/src/rpcrawtransaction.cpp
@@ -164,8 +164,6 @@ Value listunspent(const Array& params, bool fHelp)
             CBitcoinAddress address(input.get_str());
             if (!address.IsValid())
                 throw JSONRPCError(RPC_INVALID_ADDRESS_OR_KEY, string("Invalid Bitcoin address: ")+input.get_str());
-            if (setAddress.count(address))
-                throw JSONRPCError(RPC_INVALID_PARAMETER, string("Invalid parameter, duplicated address: ")+input.get_str());
            setAddress.insert(address);
         }
     }
@@ -520,9 +518,11 @@ Value sendrawtransaction(const Array& params, bool fHelp)
     {
         // push to local node
         CTxDB txdb("r");
-        if (!tx.AcceptToMemoryPool(txdb))
-            throw JSONRPCError(RPC_DESERIALIZATION_ERROR, "TX rejected");
-
+        if (!tx.AcceptToMemoryPool(txdb)) {
+            SyncWithWallets(tx, NULL, true);
+            RelayMessage(CInv(MSG_TX, hashTx), tx);
+            throw JSONRPCError(RPC_DESERIALIZATION_ERROR, string("TX rejected, relay anyway ")+hashTx.GetHex());
+        }
         SyncWithWallets(tx, NULL, true);
     }
     RelayMessage(CInv(MSG_TX, hashTx), tx);
$ bitcoin createrawtransaction '[{"txid": "e6ee06cec15f8fab2c1aa81037e6ba9b1d7c7c4073a2795e847aa9ca5b84daf1", "vout": 1}]' '{"1J1F3U7gHrCjsEsRimDJ3oYBiV24wA8FuV": 137.35368622}'
0100000001f1da845bcaa97a845e79a273407c7c1d9bbae63710a81a2cab8f5fc1ce06eee60100000000ffffffff01ae17b132030000001976a914ba85dc466140d3ef2eac3f7e42088ec501315a4b88ac00000000
$ bitcoin signrawtransaction 0100000001f1da845bcaa97a845e79a273407c7c1d9bbae63710a81a2cab8f5fc1ce06eee60100000000ffffffff01ae17b132030000001976a914ba85dc466140d3ef2eac3f7e42088ec501315a4b88ac00000000 '[{"txid": "e6ee06cec15f8fab2c1aa81037e6ba9b1d7c7c4073a2795e847aa9ca5b84daf1", "vout": 1, "scriptPubKey": "76a914ba85dc466140d3ef2eac3f7e42088ec501315a4b88ac"}]'
{
    "hex" : "0100000001f1da845bcaa97a845e79a273407c7c1d9bbae63710a81a2cab8f5fc1ce06eee6010000008c493046022100d6e0dec64778c669a4869a73dc057959ac6f8c6fa390e9ceb03bb040d3eb0933022100f3dc55dccbde883e7aadf737a5d8531847fdab1cc2b80a2357ce5dc5378a8485014104054f0d458c4dc3d0a4bb35cd17e624eb76ea99b702561bd0bea0aefe34c6c860fafca4faae957bb009e0ece9cba07cccd30dc008512a9a3021dbcfd2127938fcffffffff01ae17b132030000001976a914ba85dc466140d3ef2eac3f7e42088ec501315a4b88ac00000000",
    "complete" : true
}
$ bitcoin createrawtransaction '[{"txid": "b53cbbf160f1a5c470dba13672338908c5c9099985f6fdc37d44a5facae957df", "vout": 1}]' '{"1J1F3U7gHrCjsEsRimDJ3oYBiV24wA8FuV": 62.64371378}'
0100000001df57e9cafaa5447dc3fdf6859909c9c50889337236a1db70c4a5f160f1bb3cb50100000000ffffffff01b2b86275010000001976a914ba85dc466140d3ef2eac3f7e42088ec501315a4b88ac00000000
$ bitcoin signrawtransaction 0100000001df57e9cafaa5447dc3fdf6859909c9c50889337236a1db70c4a5f160f1bb3cb50100000000ffffffff01b2b86275010000001976a914ba85dc466140d3ef2eac3f7e42088ec501315a4b88ac00000000 '[{"txid": "b53cbbf160f1a5c470dba13672338908c5c9099985f6fdc37d44a5facae957df", "vout": 1, "scriptPubKey": "76a914ba85dc466140d3ef2eac3f7e42088ec501315a4b88ac"}]'
{
    "hex" : "0100000001f1da845bcaa97a845e79a273407c7c1d9bbae63710a81a2cab8f5fc1ce06eee6010000008c493046022100d6e0dec64778c669a4869a73dc057959ac6f8c6fa390e9ceb03bb040d3eb0933022100f3dc55dccbde883e7aadf737a5d8531847fdab1cc2b80a2357ce5dc5378a8485014104054f0d458c4dc3d0a4bb35cd17e624eb76ea99b702561bd0bea0aefe34c6c860fafca4faae957bb009e0ece9cba07cccd30dc008512a9a3021dbcfd2127938fcffffffff01ae17b132030000001976a914ba85dc466140d3ef2eac3f7e42088ec501315a4b88ac00000000",
    "complete" : true
}
$ while true; do bitcoin sendrawtransaction 0100000001f1da845bcaa97a845e79a273407c7c1d9bbae63710a81a2cab8f5fc1ce06eee6010000008c493046022100d6e0dec64778c669a4869a73dc057959ac6f8c6fa390e9ceb03bb040d3eb0933022100f3dc55dccbde883e7aadf737a5d8531847fdab1cc2b80a2357ce5dc5378a8485014104054f0d458c4dc3d0a4bb35cd17e624eb76ea99b702561bd0bea0aefe34c6c860fafca4faae957bb009e0ece9cba07cccd30dc008512a9a3021dbcfd2127938fcffffffff01ae17b132030000001976a914ba85dc466140d3ef2eac3f7e42088ec501315a4b88ac00000000; sleep 10; bitcoin sendrawtransaction 0100000001f1da845bcaa97a845e79a273407c7c1d9bbae63710a81a2cab8f5fc1ce06eee6010000008c493046022100d6e0dec64778c669a4869a73dc057959ac6f8c6fa390e9ceb03bb040d3eb0933022100f3dc55dccbde883e7aadf737a5d8531847fdab1cc2b80a2357ce5dc5378a8485014104054f0d458c4dc3d0a4bb35cd17e624eb76ea99b702561bd0bea0aefe34c6c860fafca4faae957bb009e0ece9cba07cccd30dc008512a9a3021dbcfd2127938fcffffffff01ae17b132030000001976a914ba85dc466140d3ef2eac3f7e42088ec501315a4b88ac00000000; sleep 10; done
15e8729f4632f9542790e12e7e6891ac42ca9d109c38656e7259b58ee9133d2e
22b85b88ac4f18afaab9c06ee70b47df7da23201bd2ad646ca0b202d775aa999
15e8729f4632f9542790e12e7e6891ac42ca9d109c38656e7259b58ee9133d2e
22b85b88ac4f18afaab9c06ee70b47df7da23201bd2ad646ca0b202d775aa999
15e8729f4632f9542790e12e7e6891ac42ca9d109c38656e7259b58ee9133d2e
22b85b88ac4f18afaab9c06ee70b47df7da23201bd2ad646ca0b202d775aa999
......

(I cannot remember whether the last command returns simply txid or "error: {"code":-22,"message":"TX rejected, relay anyway txid"})

No. My fully synced bitcoind refused to execute any commands except getinfo. It simply reports error message: "Warning: Displayed transactions may not be correct! You may need to upgrade, or other nodes may need to upgrade." and exit.

So I had to set up a new bitcoind in Parallels Desktop's Ubuntu virtual machine and this bitcoind was not yet fully synced with the network. And it shouldn't have many connections as it was behind NAT.
newbie
Activity: 55
Merit: 0
Been meaning to do this since The Night of the Two Chains, finally got the time to do it today.

A list of all transactions included in the .8 fork but not the (current) main chain. i.e. possible double spends.
270 transactions out of 11914 fit that description (2.26%).


(got the data from here, for some reason that page doesn't work anymore)

I might go through all of these later and try to find any "special" ones. For now though I have to study... : /


p.s. sorry for the huge post. [spoiler] tag not working. how do I spoiler stuff on this forum ?
legendary
Activity: 2506
Merit: 1010
I later manually corrected the issue with another transaction, thus double spend.

For post-mortem analysis, would you mind sharing how that raw transaction was broadcast?  Through bitcoin-Qt/bitcoind I presume?   But was this just connecting to peers or had you actually explicitly connected to a mining pool or well connected node?

The question is that most peers would have rejected it because they should already have known of the original transaction (12814b8ad57ce5654ba69eb26a52ddae1bff42093ca20cef3ad96fe7fd85d195) and not relayed your double spend (762443f6373b7c8b3833d4ad23578fc3099cc29b86d1359d0c0565e3c8614f91).  

With all the nodes reverting to 0.7 and/or starting up with an empty memory pool it is not impossible for your node to have reached one of them with no knowledge of the original transaction and then because your double spend transaction was perfectly valid for that node to relay your transaction got relayed to other new nodes as well.  Eventually then there would be a path that would reach the miner who eventually mined 225466 (the block with the double spend) -- BTC Guild [Edit: Yes, confirmed BTC Guild, per the coinbase].
legendary
Activity: 924
Merit: 1004
Firstbits: 1pirata
Yes we resolved this situation.

Nice to hear that.

To prevent this happening again in the future consider implementing "bitcoind alerts", and do automatic emergency stop on all bitcoin transactions if an alert ever shows up. It's an elegant and easy way to be warned by the community, and with enough time to avoid being "double-spent".
legendary
Activity: 1106
Merit: 1001
Yes we resolved this situation.

On behalf of those of us wanting to use OKPAY and Bitcoin, please don't let the wilful actions of one individual affect your operations too much. By his own admission, he attempted a double spend once he saw what was happening... clearly, a hard fork is not desirable, but the last time there was one was in 2010 (technically, orphaned blocks happen all the time and could be considered mini forks, but we're talking about one that went beyond six confirmations).
legendary
Activity: 1946
Merit: 1035
I was wondering if this was the reason why OKPAY has still not resumed Bitcoin operations since the fork, while others already have?

I use OKPAY services including Bitcoin on a regular basis and I would hate that such events have long term consequences on OKPAY operations as well as other payment providers.
newbie
Activity: 7
Merit: 0
hero member
Activity: 793
Merit: 1016
Currently the merchant just polls the transaction for the number of confirmations.  The client never says "this one is non-reversible".  This kind of monitoring system would require the client to make a judgement call.

I don't think you even need to change the client, it's about if the merchant delivers the final goods or not, so it could be an additional system that just checks the blockchain for possible forks.

it's not quite that simple: which blockchain?

the longest one.  that's always the main chain.  that's why the two forks were called the 0.8 chain and the 0.7 chain.  chains that aren't the longest are the forks.  for a while the 0.7 chain was the fork until miners agreed with gavin that they should switch to it.  then it became the longest.
hero member
Activity: 784
Merit: 1000
Currently the merchant just polls the transaction for the number of confirmations.  The client never says "this one is non-reversible".  This kind of monitoring system would require the client to make a judgement call.

I don't think you even need to change the client, it's about if the merchant delivers the final goods or not, so it could be an additional system that just checks the blockchain for possible forks.

it's not quite that simple: which blockchain?

The simplest way is to  just query a third party, e.g., blockchain.info's API, I am sure there are many other methods, to those who are on the orphaned chain, the main chain is just their orphaned chain, you only need to decide if there is a big difference between the two chains, no need to decide which one is right.
newbie
Activity: 32
Merit: 0
Yes we resolved this situation.
newbie
Activity: 28
Merit: 0
Well done, guys.
One question: This guy has returned your money?
newbie
Activity: 32
Merit: 0
This is not the way to do customer service. If not this incident, I don't know when they start to care me and return me the 64.xxx BTC.
The payment has been successfully completed http://blockchain.info/tx/cf7121622d6b208357b2a115cc75a9be283f8996dd7d6f612923b30f600bcadd

Yup the "duplicate" payment has been payed out and thus the amount of 64 BTC was put on hold before user agreed to return the faulty payment. So everything could be solved much faster and easier by contacting support. I suppose it's always a tempting to try to get away with something that not belongs to you.
Pages:
Jump to: