Wekkel
Legendary
Offline
Activity: 3108
Merit: 1531
yes
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 12, 2013, 08:50:27 PM |
|
A great opportunity to upgrade the software ![Cool](https://bitcointalk.org/Smileys/default/cool.gif)
|
|
|
|
Gabi
Legendary
Offline
Activity: 1148
Merit: 1008
If you want to walk on water, get out of the boat
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 12, 2013, 08:51:57 PM |
|
Clients didn't crash, they just refused the "weird" block. Or did they crash?
|
|
|
|
molecular
Donator
Legendary
Offline
Activity: 2772
Merit: 1019
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 12, 2013, 08:52:26 PM |
|
[..] Hmm, that begs the question: why run the instances yourself in the first place? Why not simply ask a bunch of clients about their opinion about the latest block (height and hash or whatever) via the protocol itself? Would that also be workable or does that approach have a problem?
could be something like this be implemented on the client to measure a potential fork? probably. I don't know enough about the protocol myself to answer this question. But say you have 8 connections and one reports a different hash for the newest block (or a lower chain height)... this wouldn't in itself mean much. You'd have to have access to a larger sample, so maybe it'd make sense to implement this as a service with an api that publishes some kind of "alert level" to be used by merchants to halt accepting bitcoin above a certain treshold.
|
PGP key molecular F9B70769 fingerprint 9CDD C0D3 20F8 279F 6BE0 3F39 FC49 2362 F9B7 0769
|
|
|
etotheipi
Legendary
Offline
Activity: 1428
Merit: 1093
Core Armory Developer
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 12, 2013, 09:01:34 PM Last edit: March 12, 2013, 09:47:29 PM by etotheipi |
|
gmaxwell answered it: a large majority of mining power switched to running 0.7 -- which meant restarting the miners and clearing their memory pools. With the right dynamics, a rebroadcast would not repropagate because most nodes had not been restarted and would not rebroadcast it. Thus, those miners that restarted, started mining without it, and accepted the double-spend as a first-spend.
That particular theory, if correct, suggests that it's safer to have saved memory pools between loads, to make the keep/drop decision deterministic. It would also appease those that want to do far-future locked transactions, whose transactions cannot, by definition, survive a software update cycle. At least it would give clients/miners a choice about their locked-tx policy, rather than having it decided for them (drop all tx on restart).
|
|
|
|
jago25_98
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 12, 2013, 09:11:05 PM |
|
Out of interest, how far did the spend get before the 0.8 chain went dominant? I take it that it didn't even get to 1 confirmation? How many confirmations was OKPay requiring at the time? 6 confirms at gox annoys me so it's a useful case study.
|
Bitcoiner since the early days. Crypto YouTube Channel: Trading Nomads | Analyst | News Reporter | Bitcoin Hodler | Support Freedom of Speech!
|
|
|
dooglus
Legendary
Offline
Activity: 2940
Merit: 1333
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 12, 2013, 09:14:07 PM |
|
That particular theory, if correct, suggests that it's safer to have saved memory pools between loads
Would that have helped in this situation? The first spend had already been mined on the 0.8 chain, and so wouldn't have been in the mempool any more. Even if the mempool persisted when the miner switched to 0.7, the first spend wouldn't be known and so the double spend would still be added to the mempool when broadcast.
|
Just-Dice | ██ ██████████ ██████████████████ ██████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████ ██████████████ ██████ | Play or Invest | ██ ██████████ ██████████████████ ██████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████ ██████████████ ██████ | 1% House Edge |
|
|
|
Aseras
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 12, 2013, 09:18:06 PM |
|
Any guesses as to the reason it didn't show up in the pre-0.8 branch? I don't see any reason that the original transaction could be systematically rejected by one branch and not the other. Even transactions that hadn't made it into blocks in the pre-0.7 branch should still be in the nodes' memory pools and double-spends rejected.
Has this been answered? Perfect timing, the second transaction went in because it was mined, and at the same time enough pools reverted while the chain was reloaded that it was 51% and the other block was considered orphaned so it was included.
|
|
|
|
molecular
Donator
Legendary
Offline
Activity: 2772
Merit: 1019
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 12, 2013, 09:24:54 PM Last edit: March 12, 2013, 09:42:13 PM by molecular |
|
gmaxwell answered it: a large majority of mining power switched to running 0.7 -- which meant restarting the miners and clearing their memory pools. With the right dynamics, a rebroadcast would not repropagate because most nodes had not been restarted and would not rebroadcast it. Thus, those miners that restarted, started mining without it, and accepted the double-spend as a first-spend.
gmaxwell and gwillen just enlightened me a little further on #bitcoin-dev. The scenario seems likely to me now especially after I got the info that only about 10% of the miners had been on 0.7 before the split. They probably had the initial TX, but just didn't find a block in time. I also understand why the 0.7 chain was chosen: if the 0.8 chains was chosen, double-spends would even now still be possible against merchants who are still asleep about the issue, which is worse. A question still: rebroadcast? How does that work? Who would rebroadcasts the tx and triggered by what? That particular theory, if correct, suggests that it's safer to have saved memory pools between loads, to make the keep/drop decision deterministic.
Saved memory pools, or maybe something in the protocol that enables syncing of the mempool from other peers? Sounds good, but again I don't know enough. EDIT: fixed 0.7/0.8 mixup
|
PGP key molecular F9B70769 fingerprint 9CDD C0D3 20F8 279F 6BE0 3F39 FC49 2362 F9B7 0769
|
|
|
molecular
Donator
Legendary
Offline
Activity: 2772
Merit: 1019
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 12, 2013, 09:27:57 PM |
|
That particular theory, if correct, suggests that it's safer to have saved memory pools between loads
Would that have helped in this situation? The first spend had already been mined on the 0.8 chain, and so wouldn't have been in the mempool any more. Even if the mempool persisted when the miner switched to 0.7, the first spend wouldn't be known and so the double spend would still be added to the mempool when broadcast. Probably true.
|
PGP key molecular F9B70769 fingerprint 9CDD C0D3 20F8 279F 6BE0 3F39 FC49 2362 F9B7 0769
|
|
|
TheSeven
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 12, 2013, 09:34:21 PM |
|
I also understand why the 0.8 chain was chosen: if the 0.7 chains was chosen, double-spends would even now still be possible against merchants who are still asleep about the issue, which is worse. That's exactly the wrong way round. The 0.7 chain was chosen, because this would have happened if the 0.8 one would have been chosen.
|
My tip jar: 13kwqR7B4WcSAJCYJH1eXQcxG5vVUwKAqY
|
|
|
molecular
Donator
Legendary
Offline
Activity: 2772
Merit: 1019
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 12, 2013, 09:42:24 PM |
|
I also understand why the 0.8 chain was chosen: if the 0.7 chains was chosen, double-spends would even now still be possible against merchants who are still asleep about the issue, which is worse. That's exactly the wrong way round. The 0.7 chain was chosen, because this would have happened if the 0.8 one would have been chosen. thanks, fixed in my post
|
PGP key molecular F9B70769 fingerprint 9CDD C0D3 20F8 279F 6BE0 3F39 FC49 2362 F9B7 0769
|
|
|
bitcoinbetas
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 12, 2013, 09:48:43 PM |
|
If I am reading this correctly, it could only happen during this weird period when we had several blockchains floating around. Is that correct?
Correct. Nothing to see here....
|
|
|
|
Largo
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 112
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 12, 2013, 09:52:40 PM |
|
I also understand why the 0.8 chain was chosen: if the 0.7 chains was chosen, double-spends would even now still be possible against merchants who are still asleep about the issue, which is worse. That's exactly the wrong way round. The 0.7 chain was chosen, because this would have happened if the 0.8 one would have been chosen. If the 0.8 chain was chosen, no double spends would have happened since RPC interface on 0.7 clients was stopped and client showed a 'you might need to upgrade/downgrade' message. At least for me, ironically it made me upgrade to 0.8, because i noticed it before the threads started.
|
|
|
|
Fiyasko
Legendary
Offline
Activity: 1428
Merit: 1001
Okey Dokey Lokey
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 12, 2013, 10:51:45 PM |
|
Oh my god... Do we blame the services? Or the client upgrade?
|
|
|
|
|
|
Piper67
Legendary
Offline
Activity: 1106
Merit: 1001
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 12, 2013, 11:37:38 PM |
|
|
|
|
|
iCEBREAKER
Legendary
Offline
Activity: 2156
Merit: 1072
Crypto is the separation of Power and State.
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 12, 2013, 11:44:58 PM |
|
How does one detect a fork?
Run several versions of Bitcoin and if they start to mutually deviate over three blocks then that is either a fork or is, a least, sufficient reason for merchants to go into safe mode. Sounds to me like a business opportunity. Actually, if this is implemented, it would make it much safer for alternative full Bitcoin clients to operate because we could detect the inevitable chain splits quickly and safely. You're reading my mind bro. Any service handling serious amounts of BTC should be running a .7 (stable) and a .8 (beta) while checking the outputs for diff. Also, why didn't .7's large block problem show up on testnet?
|
██████████ ██████████████████ ██████████████████████ ██████████████████████████ ████████████████████████████ ██████████████████████████████ ████████████████████████████████ ████████████████████████████████ ██████████████████████████████████ ██████████████████████████████████ ██████████████████████████████████ ██████████████████████████████████ ██████████████████████████████████ ████████████████████████████████ ██████████████ ██████████████ ████████████████████████████ ██████████████████████████ ██████████████████████ ██████████████████ ██████████ Monero
|
| "The difference between bad and well-developed digital cash will determine whether we have a dictatorship or a real democracy." David Chaum 1996 "Fungibility provides privacy as a side effect." Adam Back 2014
|
| | |
|
|
|
jubalix
Legendary
Offline
Activity: 2632
Merit: 1022
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 13, 2013, 12:03:37 AM |
|
well this is a fine mess one block chain goes sailing of into the abyss, but on the way people still think it ok and so cash in on int
it was the *other block chain* that was actually the real one, with no record of what is no longer the truth.
Oh look my moneys back!!!
Oh look i did not get those bitcoins!
|
|
|
|
sd
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 13, 2013, 12:22:57 AM |
|
Also, why didn't .7's large block problem show up on testnet?
I suspect because nobody was testing for this problem. Client testing needs to be radically improved if bitcoin is going to be a success.
|
|
|
|
|