Pages:
Author

Topic: Security update: duplicate transaction vulnerability fix (Read 14503 times)

legendary
Activity: 2576
Merit: 1186
FWIW, this issue has been assigned CVE-2012-1909
legendary
Activity: 2576
Merit: 1186
is there an ebuild and / or a USE flag for bip30 in the gentoo ebuild ?
There are 0.4.4 and 0.5.3 ebuilds. It's not optional, so no USE flag.
legendary
Activity: 1072
Merit: 1174
full member
Activity: 146
Merit: 100
Do we have an ETA on the patch getting merged and included in rc3 or whatever?
This is already part of 0.4.4rc3 and 0.5.3rc3.

 is there an ebuild and / or a USE flag for bip30 in the gentoo ebuild ?
hero member
Activity: 769
Merit: 500
Do we have an ETA on the patch getting merged and included in rc3 or whatever?
This is already part of 0.4.4rc3 and 0.5.3rc3.

I guess the question was, when will an 0.6 RC3 be released, that includes this fix Smiley. I use RC2 and don't want to switch back to 0.5.x.

Dia
legendary
Activity: 2576
Merit: 1186
Do we have an ETA on the patch getting merged and included in rc3 or whatever?
This is already part of 0.4.4rc3 and 0.5.3rc3.
hero member
Activity: 626
Merit: 504
Very unlikely.  Someone would need to plan the attack very carefully, have huge amounts of hashing power hiding offline, and gain essentially nothing from it.
I don't see very much as unlikely when you're talking about challenging the global banking cartel.
Exactly. When you see these kind of guys rolling out of blue, and security fix is coming up, it makes you think twice before you do anything. Bankers can gain from this one thing, the only thing they want is total control. If BTC is destroyed, then there is no alternative. Or, it would have to be done all over again, from scratch, taking into account all previous mistakes.
Cheers,
May the BitForce be with you  Grin
legendary
Activity: 1190
Merit: 1000
www.bitcointrading.com
Wow, I'm glad you guys are so smart.  I posted this on BitcoinTrading.com to spread the word.  Keep up the good work.
hero member
Activity: 568
Merit: 500
I'm running a CentOS 5.6 build that I had to compile myself. Major alterations had to be made to the make file and tons of libraries had to be prepared. And I really, really don't want to do that again.

Any chance of a CentOS binary anytime soon? I know a lot of merchant sites could really use one. And if not - what happens if we don't upgrade?
hero member
Activity: 742
Merit: 500
All of this technical stuff is way over my head, but I'd like to share my ignorant thoughts anyways.

It seems to me that 8 days is not enough time for people to really do their research on the matter. If I were a miner, or the operator of a mining pool, I would want to know EXACTLY what I'm doing before I made any serious changes.

Secondly, even if 8 days is enough time there is something unsettling about this. What you essentially have is a few highly skilled coders in the know. If they can dupe the mining community into something, anything, nefarious it could destroy Bitcoin. Obviously, I'm not saying that they will, but posit this:

Imagine highly skilled feds, or any other criminal organization, infiltrated the upper echelon of Bitcoin coders. They spent long hours making it better and building a reputation for themselves, slowly but surely dominating the entire field of coders. Then, one day, it's time to destroy Bitcoin and they issue some sort of scenario similar to the one we're dealing with now, for the mining community to go to a new blockchain or something, and the mining community takes their word for it, and BAM, Bitcoin is hashed forever.

I understand this is conspiracy theory stuff, but can anyone unsettle my fears about this scenario?

Simple. As long as the process is completely transparent and open there's really nothing anyone could "sneak" past everyone else in order to cause damage. And if you checked the OP, it pretty much doesn't get any more transparent then how they're going about with this fix. I mean you can even read the mailing list how the devs formulated the fix..

Two more questions then:

Is 8 days really enough time to vet a potentially nefarious plan?

What if a few people DO see something nefarious in it, will they be listened to, or ignored?

Also (all?) of the coders are known by real name. If they f*ckup bitcoin, they will be known by everyone as the person who screwed things up.
That would be the same as destroying many peoples money, and time invested and many companies and that is not like something you would like to do, ofcourse there is allways the possibility that they are threatened by jail or whatever unless they do this. But in this case its far from very likely.

No one is going to jail for destroying someone else's bitcoins until a government considers bitcoin a currency.
donator
Activity: 826
Merit: 1039
It seems to me that 8 days is not enough time ...
Anyone who can't satisfy themselves about this change in an hour or two isn't trying.
legendary
Activity: 1764
Merit: 1002
kjj
legendary
Activity: 1302
Merit: 1024
Did you all choose sf.net for mailing list because no one likes it? I'm not clear on the technical details of this but from a higher-level view it seems that the devs should, if not already, think about how to push updates out.  i.e. decentralize the software

I'm not sure how to do what I'm getting at but having everyone update, in the way that's needed to implement this change, isn't going to scale into the future.
Has this been discussed already? Some kind of enforcement that would prevent unsupported software access to the network? Am I making any sense at all?

I realize pushing updates out automatically would be unpopular so another model would be needed. Not sure what model would work.

The people that need to update to make the change stick network-wide are already aware of this, and have committed to updating their nodes.  See the second post.

The way this has been handled is appropriate for the problem at hand and the network of today.  When either of those are different, different methods will be (have been) used to update things.

Getting more than half of the hashing power onboard is all that is needed for this fix, and that is already done.  The fix does open a tiny sliver of a window of vulnerability where people who are doing things that they know they should not be doing might be at a slight risk if an attacker expends great effort for no gain.

The people that want to eliminate that tiny risk and keep being irresponsible have the option to upgrade.

Also, from your other (crazier) post, github has a copy of the bitcoin source, but the developers collectively have the bitcoin source.
member
Activity: 70
Merit: 10
Did you all choose sf.net for mailing list because no one likes it? I'm not clear on the technical details of this but from a higher-level view it seems that the devs should, if not already, think about how to push updates out.  i.e. decentralize the software

I'm not sure how to do what I'm getting at but having everyone update, in the way that's needed to implement this change, isn't going to scale into the future.
Has this been discussed already? Some kind of enforcement that would prevent unsupported software access to the network? Am I making any sense at all?

I realize pushing updates out automatically would be unpopular so another model would be needed. Not sure what model would work.
member
Activity: 70
Merit: 10
Quote from: Daily Anarchist
All of this technical stuff is way over my head, but I'd like to share my ignorant thoughts anyways.

It seems to me that 8 days is not enough time for people to really do their research on the matter. If I were a miner, or the operator of a mining pool, I would want to know EXACTLY what I'm doing before I made any serious changes.

Secondly, even if 8 days is enough time there is something unsettling about this. What you essentially have is a few highly skilled coders in the know. If they can dupe the mining community into something, anything, nefarious it could destroy Bitcoin. Obviously, I'm not saying that they will, but posit this:

Imagine highly skilled feds, or any other criminal organization, infiltrated the upper echelon of Bitcoin coders. They spent long hours making it better and building a reputation for themselves, slowly but surely dominating the entire field of coders. Then, one day, it's time to destroy Bitcoin and they issue some sort of scenario similar to the one we're dealing with now, for the mining community to go to a new blockchain or something, and the mining community takes their word for it, and BAM, Bitcoin is hashed forever.

I understand this is conspiracy theory stuff, but can anyone unsettle my fears about this scenario?

You might as well throw out the label  "conspiracy theory".  History, long past, and recent, has shown that discerning minds often reveal the truths behind events. So don't let lesser minds diminish accurate perception.
What inspired BTC? Bored geeks?  Current world events?

Recall the debian ssl "issue". It can happen here too. What did the spooks talk about with Andresen when he went to visit them?
Oh and have a look at github notification about recent security breach.  Isn't bitcoin code stored there?
The question is not if but when. The spooks always have a control point. They don't rest until they do and even then they hedge because that's the game.
hero member
Activity: 714
Merit: 500
Glad to see you guys killing this annoying bug.
hero member
Activity: 531
Merit: 505
Is there an official Bitcoin.org Twitter account? This would be great place to post notifications, warning, new version release, and so on.
legendary
Activity: 1764
Merit: 1002
IMO, you haven't made clear whether or not all users NEED to upgrade to 0.6 to facilitate/support this transition!

edit: by "support" you mean upgrade to 0.6?

Support was meant in a general sense: such a network rule change can only happen when the community agrees to it.

If you are a miner or pool operator: yes, please upgrade quickly, as the higher the percentage enforcing the new rules, the less chance for (temporary and short) block chain splits one could try to create.

Apart from that, if all goes well, eventually everyone will upgrade, but as a normal user, there is relatively little risk in keeping an old version. The more people running a version that enforces the new rule, the smaller the effects of an attacker can be. 0.6.0 will still take some time to be released, but there will be a bugfix-only 0.5.3 soon.


thats a little better.  let me repeat and if i'm wrong please correct:

Anyone who mines needs to upgrade to 0.5.3 as soon as it comes out to minimize the chances of a blockchain fork.

i'm not trolling; seriously it needs to be spelled out.
legendary
Activity: 1072
Merit: 1174
IMO, you haven't made clear whether or not all users NEED to upgrade to 0.6 to facilitate/support this transition!

edit: by "support" you mean upgrade to 0.6?

Support was meant in a general sense: such a network rule change can only happen when the community agrees to it.

If you are a miner or pool operator: yes, please upgrade quickly, as the higher the percentage enforcing the new rules, the less chance for (temporary and short) block chain splits one could try to create.

Apart from that, if all goes well, eventually everyone will upgrade, but as a normal user, there is relatively little risk in keeping an old version. The more people running a version that enforces the new rule, the smaller the effects of an attacker can be. 0.6.0 will still take some time to be released, but there will be a bugfix-only 0.5.3 soon.
legendary
Activity: 1764
Merit: 1002
IMO, you haven't made clear whether or not ALL users, or just miners, NEED to upgrade to 0.6 to facilitate/support this transition!

edit: by "support" you mean upgrade to 0.6?
Pages:
Jump to: