path: root/8c/a087bef4f9d4a4e835747935b5a2e22e05dd27

Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <Nick@mynicknet.com>) id 1WCuYj-0003jK-OS
	for bitcoin-development@lists.sourceforge.net;
	Mon, 10 Feb 2014 17:22:17 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of mynicknet.com
	designates 207.12.89.62 as permitted sender)
	client-ip=207.12.89.62; envelope-from=Nick@mynicknet.com;
	helo=WIN-QA4TGA8C8S1.mynicknet.com; 
Received: from [207.12.89.62] (helo=WIN-QA4TGA8C8S1.mynicknet.com)
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES128-SHA:128)
	(Exim 4.76) id 1WCuYi-000275-0X
	for bitcoin-development@lists.sourceforge.net;
	Mon, 10 Feb 2014 17:22:17 +0000
Received: from 90-82-42-51.pools.spcsdns.net (66.87.78.90) by
	WIN-QA4TGA8C8S1.mynicknet.com (207.12.89.62) with Microsoft SMTP Server
	(TLS) id 14.1.438.0; Mon, 10 Feb 2014 11:57:09 -0600
User-Agent: K-9 Mail for Android
In-Reply-To: <20140210161402.GI3180@nl.grid.coop>
References: <CAPg+sBi-phaw3hDgguk-LYrPsKX4M5snTJBv_NsQML1M=XgZEw@mail.gmail.com>
	<20140210161402.GI3180@nl.grid.coop>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----FCFQPA78ODZ32N3QYLAL2D41URN538"
From: Nick Simpson <nick@mynicknet.com>
Date: Mon, 10 Feb 2014 10:57:03 -0600
To: Troy Benjegerdes <hozer@hozed.org>, Pieter Wuille <pieter.wuille@gmail.com>
Message-ID: <2d588a9e-9a85-41c1-82ce-e26c791a1022@email.android.com>
X-Spam-Score: 0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	1.0 RDNS_NONE Delivered to internal network by a host with no rDNS
X-Headers-End: 1WCuYi-000275-0X
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Malleability and MtGox's announcement
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Mon, 10 Feb 2014 17:22:17 -0000

------FCFQPA78ODZ32N3QYLAL2D41URN538
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"

You must be new here. MtGox very rarely comments on things like this public=
ly, outside of irc or their website.=20

Second, MtGox problem is a MtGox problem. You have no right to demand acces=
s to their private code. If you feel wronged as a customer, sue them. Other=
wise, 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> wr=
ote:
>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=20
>manipulation power to the selected cabal of company insiders who are
>discussing things 'off-list'.=20
>
>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=20
>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=20
>employment contracts that provide plausible deniability of insider=20
>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.=20
>
>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=20
>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,
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> The first is something that needs to be done correctly in software -
>> it just needs to be aware of malleability.
>>=20
>> 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.
>>=20
>> 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:
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> --=20
>> Pieter
>>=20
>>
>--------------------------------------------------------------------------=
----
>> 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=3D121051231&iu=3D/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=3D121051231&iu=3D/4140/ostg.=
clktrk
>_______________________________________________
>Bitcoin-development mailing list
>Bitcoin-development@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/bitcoin-development

------FCFQPA78ODZ32N3QYLAL2D41URN538
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

<html><head></head><body>You must be new here. MtGox very rarely comments o=
n things like this publicly, outside of irc or their website. <br>
<br>
Second, MtGox problem is a MtGox problem. You have no right to demand acces=
s to their private code. If you feel wronged as a customer, sue them. Other=
wise, they have no obligation to you.<br>
<br>
I believe you are &quot;barking up the wrong tree&quot;.<br>
<br>
Respectfully,<br>
<br>
Nick<br><br><div class=3D"gmail_quote">On February 10, 2014 10:14:02 AM CST=
, Troy Benjegerdes &lt;hozer@hozed.org&gt; wrote:<blockquote class=3D"gmail=
_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204,=
 204, 204); padding-left: 1ex;">
<pre class=3D"k9mail">Okay, why the everloving FUCK is there not someone on=
 this list with a<br />@mtgox.com address talking about this?<br /><br />I =
started using bitcoin because I could audit the code, and when the<br />dev=
eloper cabal does stuff 'off-list' what you do is hand over market <br />ma=
nipulation power to the selected cabal of company insiders who are<br />dis=
cussing things 'off-list'. <br /><br />The people having a 'private' discus=
sion about how to solve this are<br />TAKING MONEY from everyone else, by h=
aving access to insider information.<br /><br />I don't think any of the de=
velopers actually have a clue this is the <br />result, because a good chun=
k of them are employed by for-profit companies<br />funded by venture capit=
al, and VC lawyers are very good at writing <br />employment contracts that=
 provide plausible deniability of insider <br />trading.<br /><br />The pre=
ss MAKES MONEY (okay, takes money) by manipulating markets,<br />and ventur=
e capitalists pay lots
of money to ensure the market is<br />manipulated in ways they can profit f=
rom.<br /><br />Private market manipulation is one of the costs of anonymit=
y and privacy,<br />and I don't really like paying for some off-list discus=
sion of what appears<br />to be a serious scalability and usability problem=
.<br /><br />Bitcoin is such a powerful tool because it broadcasts transact=
ions to<br />the network for everyone to see. <br /><br />Can we please bro=
adcast some more technical details to this mailing list,<br />including exa=
ctly what MtGox is doing, and how they wish to resolve it?<br /><br />If yo=
u gave me the entire code stack that MtGox runs on under an AGPLv3<br />lic=
ense, I'm pretty sure I, along with everyone else here could come up<br />w=
ith a workable solution. I think a code release would be a huge win <br />f=
or MtGox as well, and would cement their position as market leader in<br />=
transparent cryptocurrency trading.<br /><br />Otherwise we are just a bunc=
h of dinghys getting
capsized one by one<br />in a sea of market-manipulating white whales. Isn'=
t the closed door<br />market manipulation of the big banks one of the reas=
ons we all started<br />using Bitcoin in the first place?<br /><br />Why do=
 revolutions always put the same old bullshit back in power?<br /><br />Wha=
t we need is some transparent code evolution.<br /><br />On Mon, Feb 10, 20=
14 at 01:28:42PM +0100, Pieter Wuille wrote:<br /><blockquote class=3D"gmai=
l_quote" style=3D"margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf=
; padding-left: 1ex;"> Hi all,<br /> <br /> I was a bit surprised to see Mt=
Gox's announcement. The malleability of<br /> transactions was known for ye=
ars already (see for example the wiki<br /> article on it, <a href=3D"https=
://en.bitcoin.it/wiki/Transaction_Malleability">https://en.bitcoin.it/wiki/=
Transaction_Malleability</a> it,<br /> or mails on this list from 2012 and =
2013). I don't consider it a very<br /> big problem, but it does make it ha=
rder for infrastructure to
interact<br /> with Bitcoin. If we'd design Bitcoin today, I'm sure we woul=
d try to<br /> avoid it altogether to make life easier for everyone.<br /> =
<br /> But we can't just change all infrastructure that exists today. We're=
<br /> slowly working towards making malleability harder (and hopefully<br =
/> impossible someday), but this will take a long time. For example, 0.8<br=
 /> not supporting non-DER encoded signatures was a step in that direction<=
br /> (and ironically, the trigger that caused MtGox's initial problems<br =
/> here). In any case, this will take years, and nobody should wait for<br =
/> this.<br /> <br /> There seem to be two more direct problems here.<br />=
 * Wallets which deal badly with modified txids.<br /> * Services that use =
the transaction id to detect unconfirming transactions.<br /> <br /> The fi=
rst is something that needs to be done correctly in software -<br /> it jus=
t needs to be aware of malleability.<br /> <br /> The second is something I=
 was unaware of and
would have advised<br /> against. If you plan on reissuing a transaction be=
cause on old version<br /> doesn't confirm, make sure to make it a double s=
pend of the first one<br /> - so that not both can confirm.<br /> <br /> I =
certainly don't like press making this sound like a problem in the<br /> Bi=
tcoin protocol or clients. I think this is an issue that needs to be<br /> =
solved at the layer above - the infrastructure building on the Bitcoin<br /=
> system. Despite that, I do think that we (as a community, not just<br /> =
developers) can benefit from defining a standard way to identify<br /> tran=
sactions unambiguously. This is something Mark Karpeles suggested<br /> a f=
ew days ago, and my proposal is this:<br /> <br /> We define the normalized=
 transaction id as SHA256^2(normalized_tx +<br /> 0x01000000), where normal=
ized_tx is the transaction with all input<br /> scripts replaced by empty s=
cripts. This is exactly what would be<br /> signed inside transaction signa=
tures using
SIGHASH_ALL (except not<br /> substituting the previous scriptPubKey to be =
signed, and not dealing<br /> with the input being signed specially). An im=
plementation is here:<br /> <a href=3D"https://github.com/sipa/bitcoin/comm=
its/normtxid">https://github.com/sipa/bitcoin/commits/normtxid</a>.<br /> <=
br /> Note that this is not a solution for all problems related to<br /> ma=
lleability, but maybe it can make people more aware of it, in<br /> tangibl=
e way.<br /> <br /> -- <br /> Pieter<br /> <br /><hr /><br /> Managing the =
Performance of Cloud-Based Applications<br /> Take advantage of what the Cl=
oud has to offer - Avoid Common Pitfalls.<br /> Read the Whitepaper.<br /> =
<a href=3D"http://pubads.g.doubleclick.net/gampad/clk?id=3D121051231&amp;iu=
=3D/4140/ostg.clktrk">http://pubads.g.doubleclick.net/gampad/clk?id=3D12105=
1231&amp;iu=3D/4140/ostg.clktrk</a><br /><hr /><br /> Bitcoin-development m=
ailing list<br /> Bitcoin-development@lists.sourceforge.net<br /> <a
href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development">h=
ttps://lists.sourceforge.net/lists/listinfo/bitcoin-development</a><br /></=
blockquote><br /><hr /><br />Managing the Performance of Cloud-Based Applic=
ations<br />Take advantage of what the Cloud has to offer - Avoid Common Pi=
tfalls.<br />Read the Whitepaper.<br /><a href=3D"http://pubads.g.doublecli=
ck.net/gampad/clk?id=3D121051231&amp;iu=3D/4140/ostg.clktrk">http://pubads.=
g.doubleclick.net/gampad/clk?id=3D121051231&amp;iu=3D/4140/ostg.clktrk</a><=
br /><hr /><br />Bitcoin-development mailing list<br />Bitcoin-development@=
lists.sourceforge.net<br /><a href=3D"https://lists.sourceforge.net/lists/l=
istinfo/bitcoin-development">https://lists.sourceforge.net/lists/listinfo/b=
itcoin-development</a><br /></pre></blockquote></div></body></html>=

------FCFQPA78ODZ32N3QYLAL2D41URN538--