From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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: <20140210161402.GI3180@nl.grid.coop> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----FCFQPA78ODZ32N3QYLAL2D41URN538" From: Nick Simpson Date: Mon, 10 Feb 2014 10:57:03 -0600 To: Troy Benjegerdes , Pieter Wuille 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 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 You must be new here. MtGox very rarely comments o= n things like this publicly, outside of irc or their website.

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> 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
dev=
eloper cabal does stuff 'off-list' what you do is hand over market 
ma=
nipulation power to the selected cabal of company insiders who are
dis=
cussing things 'off-list'. 

The people having a 'private' discus=
sion about how to solve this are
TAKING MONEY from everyone else, by h=
aving access to insider information.

I don't think any of the de=
velopers actually have a clue this is the 
result, because a good chun=
k of them are employed by for-profit companies
funded by venture capit=
al, and VC lawyers are very good at writing 
employment contracts that=
 provide plausible deniability of insider 
trading.

The pre=
ss MAKES MONEY (okay, takes money) by manipulating markets,
and ventur=
e capitalists pay lots
of money to ensure the market is
manipulated in ways they can profit f=
rom.

Private market manipulation is one of the costs of anonymit=
y and privacy,
and I don't really like paying for some off-list discus=
sion of what appears
to be a serious scalability and usability problem=
.

Bitcoin is such a powerful tool because it broadcasts transact=
ions to
the network for everyone to see. 

Can we please bro=
adcast some more technical details to this mailing list,
including exa=
ctly what MtGox is doing, and how they wish to resolve it?

If yo=
u gave me the entire code stack that MtGox runs on under an AGPLv3
lic=
ense, I'm pretty sure I, along with everyone else here could come up
w=
ith a workable solution. I think a code release would be a huge win 
f=
or MtGox as well, and would cement their position as market leader in
=
transparent cryptocurrency trading.

Otherwise we are just a bunc=
h 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 reas=
ons we all started
using Bitcoin in the first place?

Why do=
 revolutions always put the same old bullshit back in power?

Wha=
t we need is some transparent code evolution.

On Mon, Feb 10, 20=
14 at 01:28:42PM +0100, Pieter Wuille wrote:
 Hi all,
 
 I was a bit surprised to see Mt=
Gox's announcement. The malleability of
 transactions was known for ye=
ars 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 ha=
rder for infrastructure to
interact
 with Bitcoin. If we'd design Bitcoin today, I'm sure we woul=
d 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<=
br /> (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 fi=
rst is something that needs to be done correctly in software -
 it jus=
t 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 be=
cause on old version
 doesn't confirm, make sure to make it a double s=
pend of the first one
 - so that not both can confirm.
 
 I =
certainly don't like press making this sound like a problem in the
 Bi=
tcoin 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
 tran=
sactions unambiguously. This is something Mark Karpeles suggested
 a f=
ew days ago, and my proposal is this:
 
 We define the normalized=
 transaction id as SHA256^2(normalized_tx +
 0x01000000), where normal=
ized_tx is the transaction with all input
 scripts replaced by empty s=
cripts. This is exactly what would be
 signed inside transaction signa=
tures using
SIGHASH_ALL (except not
 substituting the previous scriptPubKey to be =
signed, and not dealing
 with the input being signed specially). An im=
plementation is here:
 https://github.com/sipa/bitcoin/commits/normtxid.
 <=
br /> Note that this is not a solution for all problems related to
 ma=
lleability, but maybe it can make people more aware of it, in
 tangibl=
e way.
 
 -- 
 Pieter
 

 Managing the =
Performance of Cloud-Based Applications
 Take advantage of what the Cl=
oud has to offer - Avoid Common Pitfalls.
 Read the Whitepaper.
 =
http://pubads.g.doubleclick.net/gampad/clk?id=3D12105=
1231&iu=3D/4140/ostg.clktrk

 Bitcoin-development m=
ailing list
 Bitcoin-development@lists.sourceforge.net
 h=
ttps://lists.sourceforge.net/lists/listinfo/bitcoin-development


Managing the Performance of Cloud-Based Applic=
ations
Take advantage of what the Cloud has to offer - Avoid Common Pi=
tfalls.
Read the Whitepaper.
http://pubads.=
g.doubleclick.net/gampad/clk?id=3D121051231&iu=3D/4140/ostg.clktrk<=
br />

Bitcoin-development mailing list
Bitcoin-development@=
lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/b=
itcoin-development
= ------FCFQPA78ODZ32N3QYLAL2D41URN538--