You must be new here. MtGox very rarely comments on things like this publicly, outside of irc or their website. Second, MtGox problem is a MtGox problem. You have no right to demand access to their private code. If you feel wronged as a customer, sue them. Otherwise, they have no obligation to you. I believe you are "barking up the wrong tree". Respectfully, Nick On February 10, 2014 10:14:02 AM CST, Troy Benjegerdes wrote: >Okay, why the everloving FUCK is there not someone on this list with a >@mtgox.com address talking about this? > >I started using bitcoin because I could audit the code, and when the >developer cabal does stuff 'off-list' what you do is hand over market >manipulation power to the selected cabal of company insiders who are >discussing things 'off-list'. > >The people having a 'private' discussion about how to solve this are >TAKING MONEY from everyone else, by having access to insider >information. > >I don't think any of the developers actually have a clue this is the >result, because a good chunk of them are employed by for-profit >companies >funded by venture capital, and VC lawyers are very good at writing >employment contracts that provide plausible deniability of insider >trading. > >The press MAKES MONEY (okay, takes money) by manipulating markets, >and venture capitalists pay lots of money to ensure the market is >manipulated in ways they can profit from. > >Private market manipulation is one of the costs of anonymity and >privacy, >and I don't really like paying for some off-list discussion of what >appears >to be a serious scalability and usability problem. > >Bitcoin is such a powerful tool because it broadcasts transactions to >the network for everyone to see. > >Can we please broadcast some more technical details to this mailing >list, >including exactly what MtGox is doing, and how they wish to resolve it? > >If you gave me the entire code stack that MtGox runs on under an AGPLv3 >license, I'm pretty sure I, along with everyone else here could come up >with a workable solution. I think a code release would be a huge win >for MtGox as well, and would cement their position as market leader in >transparent cryptocurrency trading. > >Otherwise we are just a bunch of dinghys getting capsized one by one >in a sea of market-manipulating white whales. Isn't the closed door >market manipulation of the big banks one of the reasons we all started >using Bitcoin in the first place? > >Why do revolutions always put the same old bullshit back in power? > >What we need is some transparent code evolution. > >On Mon, Feb 10, 2014 at 01:28:42PM +0100, Pieter Wuille wrote: >> Hi all, >> >> I was a bit surprised to see MtGox's announcement. The malleability >of >> transactions was known for years already (see for example the wiki >> article on it, https://en.bitcoin.it/wiki/Transaction_Malleability >it, >> or mails on this list from 2012 and 2013). I don't consider it a very >> big problem, but it does make it harder for infrastructure to >interact >> with Bitcoin. If we'd design Bitcoin today, I'm sure we would try to >> avoid it altogether to make life easier for everyone. >> >> But we can't just change all infrastructure that exists today. We're >> slowly working towards making malleability harder (and hopefully >> impossible someday), but this will take a long time. For example, 0.8 >> not supporting non-DER encoded signatures was a step in that >direction >> (and ironically, the trigger that caused MtGox's initial problems >> here). In any case, this will take years, and nobody should wait for >> this. >> >> There seem to be two more direct problems here. >> * Wallets which deal badly with modified txids. >> * Services that use the transaction id to detect unconfirming >transactions. >> >> The first is something that needs to be done correctly in software - >> it just needs to be aware of malleability. >> >> The second is something I was unaware of and would have advised >> against. If you plan on reissuing a transaction because on old >version >> doesn't confirm, make sure to make it a double spend of the first one >> - so that not both can confirm. >> >> I certainly don't like press making this sound like a problem in the >> Bitcoin protocol or clients. I think this is an issue that needs to >be >> solved at the layer above - the infrastructure building on the >Bitcoin >> system. Despite that, I do think that we (as a community, not just >> developers) can benefit from defining a standard way to identify >> transactions unambiguously. This is something Mark Karpeles suggested >> a few days ago, and my proposal is this: >> >> We define the normalized transaction id as SHA256^2(normalized_tx + >> 0x01000000), where normalized_tx is the transaction with all input >> scripts replaced by empty scripts. This is exactly what would be >> signed inside transaction signatures using SIGHASH_ALL (except not >> substituting the previous scriptPubKey to be signed, and not dealing >> with the input being signed specially). An implementation is here: >> https://github.com/sipa/bitcoin/commits/normtxid. >> >> Note that this is not a solution for all problems related to >> malleability, but maybe it can make people more aware of it, in >> tangible way. >> >> -- >> Pieter >> >> >------------------------------------------------------------------------------ >> Managing the Performance of Cloud-Based Applications >> Take advantage of what the Cloud has to offer - Avoid Common >Pitfalls. >> Read the Whitepaper. >> >http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk >> _______________________________________________ >> Bitcoin-development mailing list >> Bitcoin-development@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development > >------------------------------------------------------------------------------ >Managing the Performance of Cloud-Based Applications >Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. >Read the Whitepaper. >http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk >_______________________________________________ >Bitcoin-development mailing list >Bitcoin-development@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/bitcoin-development