From: Nick Simpson <nick@mynicknet•com>
To: Troy Benjegerdes <hozer@hozed•org>,
Pieter Wuille <pieter.wuille@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Malleability and MtGox's announcement
Date: Mon, 10 Feb 2014 10:57:03 -0600 [thread overview]
Message-ID: <2d588a9e-9a85-41c1-82ce-e26c791a1022@email.android.com> (raw)
In-Reply-To: <20140210161402.GI3180@nl.grid.coop>
[-- 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 --]
next prev parent reply other threads:[~2014-02-10 17:22 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-10 12:28 Pieter Wuille
2014-02-10 16:14 ` Troy Benjegerdes
2014-02-10 16:57 ` Nick Simpson [this message]
2014-02-10 18:02 ` Troy Benjegerdes
[not found] ` <CANOOu=_rQfRORmbEWz=1MVk9dK26ddiCeyeHMaua6iyioBUr4g@mail.gmail.com>
2014-02-10 17:54 ` Troy Benjegerdes
2014-02-10 19:47 ` Oliver Egginger
2014-02-10 20:40 ` Gregory Maxwell
2014-02-10 20:47 ` Tier Nolan
2014-02-10 20:55 ` Gregory Maxwell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2d588a9e-9a85-41c1-82ce-e26c791a1022@email.android.com \
--to=nick@mynicknet$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=hozer@hozed$(echo .)org \
--cc=pieter.wuille@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox