Dark Web is where you can buy black market credit cards for sale. But have you ever wondered about the consequences or tough time you might be facing while doing so? Well, there is nothing to worry about. Dark Web Link is here to help you with all the information on how to get to the black market credit cards or the .onion sites links.
You can Check This Web site for more details :https://darkweblink.com/
Topic: A successful DOUBLE SPEND US$10000 against OKPAY this morning. (Read 124047 times)
January 03, 2019, 07:18:55 AM
Five years later, no block explorers still show Macbook-air's original transaction that had gotten double-spent after the block reorg.
Here's a list of seven transactions that (allegedly) had been confirmed on the v0.8 side of the fork, but were later double spent on the v0.7 side of the fork.
12814b8ad57ce5654ba69eb26a52ddae1bff42093ca20cef3ad96fe7fd85d195
cb36ba33b3ecd4d3177d786209670c9e6cdf95eb62be54986f0b49ca292714af
7192807f952b252081d0db0aa7575c4695b945820adaf7776b7189e6b3d86f96
355d4ea51c3b780cf0b10e8099a06a31484e0060bc140b63f3d6e5fb713ace5e
b961bc0c663a46893afd3166a604e7e2639533522d9fec61fdb95eb665e86f5a
138063e4bdb76feaa511f1e7f9c681eb468ef9140c141671741c965e503b84c6
a10bd194cdbf9aa4c12eb0b120056998a081a9b0d93d70570edff24dec831f90
Source: https://pastebin.com/raw/wctJU3Ln
Here's a list of seven transactions that (allegedly) had been confirmed on the v0.8 side of the fork, but were later double spent on the v0.7 side of the fork.
12814b8ad57ce5654ba69eb26a52ddae1bff42093ca20cef3ad96fe7fd85d195
cb36ba33b3ecd4d3177d786209670c9e6cdf95eb62be54986f0b49ca292714af
7192807f952b252081d0db0aa7575c4695b945820adaf7776b7189e6b3d86f96
355d4ea51c3b780cf0b10e8099a06a31484e0060bc140b63f3d6e5fb713ace5e
b961bc0c663a46893afd3166a604e7e2639533522d9fec61fdb95eb665e86f5a
138063e4bdb76feaa511f1e7f9c681eb468ef9140c141671741c965e503b84c6
a10bd194cdbf9aa4c12eb0b120056998a081a9b0d93d70570edff24dec831f90
Source: https://pastebin.com/raw/wctJU3Ln
This is part of the history!
* https://99bitcoins.com/price-chart-history/
* https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki
* https://99bitcoins.com/price-chart-history/
* https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki
I think of a double spend as a spend with confirmation followed by another spend of the same balance.
Which is what happened in March, 2013. If you were using the v0.8 client there was a transaction that had more than six confirmations but later the fork which pre-v0.8 clients were mining surpassed the one the v0.8 were using and that transaction became invalid. What happened was a user noticed the fork, created a new transaction that spent the same funds, used a custom client that repeatedly broadcast the double spend attempt and eventually that new transaction got included in the pre-v0.8 blockchain fork.
So yes, a double spend of a transaction that had six or more confirmations on what was at the time the longest chain is something that has occurred.
The gist of the problem was that miners starting up with the v0.7 client had an empty memory pool and thus no knowledge of the transactions that had already confirmed in the blockchain fork mined by the v0.8 clients. So then it simply is a race -- whichever transaction (of the two that were spending the same coin) that reached those miners first is the one that was being hashed. For that specific weakness, there are solutions that had been discussed but not implemented as far as I know. For instance, when the miner is shut down the unconfirmed transactions in the memory pool could be written to the filesystem and then those transactions get loaded first when the miner starts back up. That would likely have made the result of that March 2013 fork be that no double spends had occurred.
What is your definition of double spend?
Are you including operator error and self-inflicted (ie. allowing 0-confirmations)? The network (and access) isn't always fast enough for every use case either.
I think of a double spend as a spend with confirmation followed by another spend of the same balance. Without confirmation it seems to me that the protocol is behaving as designed and, as you mention, it's an operator error. I also don't think that it counts if it happened on the test net.
A true double spend in the wild would spook me. If a method were found to do that, it would be the most serious threat to bitcoin so far.
There has never been a double spend.
It seems like many have to believe this for their world to continue spinning but it is patently ludicrous to put your faith in a negative statement that by definition cannot be proven.
There HAVE been double spends and there will continue to be double spends.
If we truly want this experiment to survive we must identify these edge cases and provide solutions instead of burying our heads in the sand afraid of the bad publicity.
What is your definition of double spend?
Are you including operator error and self-inflicted (ie. allowing 0-confirmations)? The network (and access) isn't always fast enough for every use case either.
Your .gif was not accurate.
2013 turned out to be a great year for BTC.
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?
Yes, the failures in the automated alert systems have been addressed, so services should be able to disable themselves when a long fork is detected:https://github.com/bitcoin/bitcoin/pull/2658
How serious is this please. Double spends I thought were impossible . 
it's impossible.
when you wait the 1 confirmation (1 block) ... anyway.
Correct me if I'm wrong, but forks are only possible with a certain amount of hash power, and to gain enough hash to fork the Bitcoin chain would be very expensive and thus impractical.
yeah you're wrong.
Forks happen anytime 2 miners solve a block referencing the same previous block.
But usually one of the forks gets chosen by consensus right? And after 6 of so confirmations it is extremely unlikely to change.
When this thread was opened there was a bug (or bug fixed) with the latest version of the software which means that the new version of the software chose a different branch to the old, which is a very different and horrible problem. IIRC the developers told people to downgrade to the old version and the associated fork became the chosen fork, and thus losing transactions made in the unchosen fork.
Hammer me if this isn't 100% accurate but I think it is the gist.
Usually forks are OK and get resolved. This thread is about a different 'hard' fork cause by software issues.
Correct me if I'm wrong, but forks are only possible with a certain amount of hash power, and to gain enough hash to fork the Bitcoin chain would be very expensive and thus impractical.
yeah you're wrong.
Forks happen anytime 2 miners solve a block referencing the same previous block.
Correct me if I'm wrong, but forks are only possible with a certain amount of hash power, and to gain enough hash to fork the Bitcoin chain would be very expensive and thus impractical.
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.
Good thing you added that last line, because you are dead wrong. Forks are expected. They will always happen. That is a core feature in how Bitcoin is designed.
There has never been a double spend.
It seems like many have to believe this for their world to continue spinning but it is patently ludicrous to put your faith in a negative statement that by definition cannot be proven.
There HAVE been double spends and there will continue to be double spends.
If we truly want this experiment to survive we must identify these edge cases and provide solutions instead of burying our heads in the sand afraid of the bad publicity.
ok, if you guys think it is not "double spend", let's call it "reversed transaction". That's not the main point here.
Actually the opposite is true. OKPAY got cheated because they were using the latest client (0.
. If they did not update, they would never see the original transaction confirmed.
Quote
what happened is that businesses did not update the clients
Actually the opposite is true. OKPAY got cheated because they were using the latest client (0.
. If they did not update, they would never see the original transaction confirmed. There has never been a double spend.
It seems like many have to believe this for their world to continue spinning but it is patently ludicrous to put your faith in a negative statement that by definition cannot be proven.
There HAVE been double spends and there will continue to be double spends.
If we truly want this experiment to survive we must identify these edge cases and provide solutions instead of burying our heads in the sand afraid of the bad publicity.
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.
Like others have said, the same coin has never been spent twice in the history of bitcoin; when we say "double spend," we mean that someone thought they got paid but later found out that they didn't.
There are many ways one can protect himself against such events. In the case described in the OP, the event took place during a planned hard fork of the protocol. If we feel it necessary to fork the code again (and we likely will), I think it would be wise for exchanges to require a full day of confirmations for large deposits. Once it is clear that the fork was handled properly, services can reduce the confirmation requirements back to normal.
Non-planned forks (large orphans) are rare. It is rarer still that the funds confirmed in the now-orphaned chain wouldn't also be confirmed in the new longest chain (it would strongly imply malicious intent, careful planning, and a large financial investment). But one should still dynamically track confirmed coins and in the very very unlikely event that coins are not confirmed in the new chain, the service should immediately freeze the accounts in question.
There is also nothing special about the number "6": personally, if I ran a large exchange I would likely require less than 6 confirmations for most deposits, but more than 6 for, say, 10 000 BTC.
There has never been a double spend.
All time UTC+08:00:
08:08 – Well before I knew what later have happened, I deposited $10000-worth Bitcoins to BTC-e over OKPAY's Bitcoin payment, I paid OKPAY address 12z2n8YCJw1BEsJhhQPLCTuLqwH341nKnE 211.9093 BTC and 0.0005 BTC as transaction fee.
09:30 – The transaction was included in version 0.8's fork, block 225446
10:08 – Deposit completed, $9800 credited to my BTC-e account
12:53 – After some study, I recognized, the transaction, though included in version 0.8's fork, was never confirmed by the pre-0.8 fork, so I decided to make two double spend transactions on two of the vins of the OKPAY transaction, and broadcasted them with the raw transaction API, 0.001 BTC transaction fee included in each transaction.
13:01 – The double spend transaction was included in pre-0.8 fork block 225446
You should know what happens next...
I bet merchants would think twice before they decide to accept Bitcoins after the incident.
08:08 – Well before I knew what later have happened, I deposited $10000-worth Bitcoins to BTC-e over OKPAY's Bitcoin payment, I paid OKPAY address 12z2n8YCJw1BEsJhhQPLCTuLqwH341nKnE 211.9093 BTC and 0.0005 BTC as transaction fee.
09:30 – The transaction was included in version 0.8's fork, block 225446
10:08 – Deposit completed, $9800 credited to my BTC-e account
12:53 – After some study, I recognized, the transaction, though included in version 0.8's fork, was never confirmed by the pre-0.8 fork, so I decided to make two double spend transactions on two of the vins of the OKPAY transaction, and broadcasted them with the raw transaction API, 0.001 BTC transaction fee included in each transaction.
13:01 – The double spend transaction was included in pre-0.8 fork block 225446
You should know what happens next...
I bet merchants would think twice before they decide to accept Bitcoins after the incident.
well this is why there should be inventory watchers, and this is why there has to be someone to over look these transactions as this can be avoided.
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.
technically its not a double spend.. there is only one "receipt" of BTC that got confirmed on this main blockchain, meaning there is not 2 bunches of bitcoins that originated from one single bitcoin source on this main blockchain.
what happened is that businesses did not update the clients to be using the correct blockchain. thus the business does not see the correct transaction and ends out paying FIAT twice.
what needs to be done is to ensure forks dont happen, and in the small chance that a fork does occur, that businesses are not lazy about updating their clients, or double checking transactions before releasing different forms of funds or goods. (which would have prevented malleability issues if businesses had proper double checking methods in place)
there is not one single extra bitcoin on the blockchain that was cloned or not originate from a verified block reward. ill say it again a double spend is where 1 btc can be used twice. no coin has been used twice. all that has happened is that businesses have not had adequate checking processes in place. the bitcoin protocol and the blockchain does not show more confirmed coins then what has been released through blockchain rewards
Jump to: