Re: [Bitcoin-development] Malleability and MtGox's announcement

[Nick Simpson <nick@mynicknet.com>]

[-- Attachment #1: Type: text/plain, Size: 6483 bytes --]

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 <hozer@hozed.org> 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

[-- Attachment #2: Type: text/html, Size: 7430 bytes --]