path: root/3a/268fcaf5eeea328cc7fd91a48508ffe03c331b

Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <allen.piscitello@gmail.com>) id 1WGIRu-0004Vw-VJ
	for bitcoin-development@lists.sourceforge.net;
	Thu, 20 Feb 2014 01:29:14 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.212.177 as permitted sender)
	client-ip=209.85.212.177;
	envelope-from=allen.piscitello@gmail.com;
	helo=mail-wi0-f177.google.com; 
Received: from mail-wi0-f177.google.com ([209.85.212.177])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1WGIRr-0001mZ-DK
	for bitcoin-development@lists.sourceforge.net;
	Thu, 20 Feb 2014 01:29:14 +0000
Received: by mail-wi0-f177.google.com with SMTP id e4so1273766wiv.10
	for <bitcoin-development@lists.sourceforge.net>;
	Wed, 19 Feb 2014 17:29:05 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.194.179.69 with SMTP id de5mr31451893wjc.4.1392859745240;
	Wed, 19 Feb 2014 17:29:05 -0800 (PST)
Received: by 10.194.76.135 with HTTP; Wed, 19 Feb 2014 17:29:05 -0800 (PST)
In-Reply-To: <CAAt2M1-YC8Bv=11AuT=0ATpX60R=g-PhhK+mBK=VHfEO3xLvxQ@mail.gmail.com>
References: <CAPg+sBgPG+2AMbEHSRQNFn6FikbRzxkWduj5MSZLz-O6Wh940w@mail.gmail.com>
	<CALf2ePwc=es-aDSeJO2DZwu9kyHwq9dcp5TrMAhN-dvYwNjy-w@mail.gmail.com>
	<52FBD948.906@monetize.io> <201402122252.31060.luke@dashjr.org>
	<CAPWm=eV9YP3wAbCFt1JcSqJ6Jc3kY_546MVk3cHT+X8seC8vRw@mail.gmail.com>
	<CAAS2fgSwjGohhiXuwhG3bJ5mLxSS8Dx0Hytmg7PhhRzwnw7FNQ@mail.gmail.com>
	<EFA82A3F-2907-4B2B-9FCB-DCA02CA4EC63@mac.com>
	<CAPg+sBgnuNygR7_yny1=+wGWmeLcub0A8_ep3U-5ewmQJk71jw@mail.gmail.com>
	<601EE159-9022-4ADF-80AC-7E1C39E86A65@mac.com>
	<CAPg+sBg9=XK=PGSW8DcU1LR85oeTDmpS4U-vYUXbraZQpU+edg@mail.gmail.com>
	<CAAt2M1-YC8Bv=11AuT=0ATpX60R=g-PhhK+mBK=VHfEO3xLvxQ@mail.gmail.com>
Date: Wed, 19 Feb 2014 19:29:05 -0600
Message-ID: <CAJfRnm6itmEv6wsFyZGMYVLXSms5v9Q9BfhFfZEoJLxMMiP_2g@mail.gmail.com>
From: Allen Piscitello <allen.piscitello@gmail.com>
To: Natanael <natanael.l@gmail.com>
Content-Type: multipart/alternative; boundary=089e01493cae564ae204f2cc6ea1
X-Spam-Score: -0.6 (/)
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(allen.piscitello[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1WGIRr-0001mZ-DK
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with
	malleability
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: Thu, 20 Feb 2014 01:29:15 -0000

--089e01493cae564ae204f2cc6ea1
Content-Type: text/plain; charset=ISO-8859-1

This is somewhat problematic in my use case since some parts need to be in
the chain earlier than others and have the same ID as expected.

https://bitcointalk.org/index.php?topic=260898.10

I haven't gone back to see if there are any ways around it, but the main
problem here is I need the Contract TX to be in the chain much earlier than
redeeming, but I need the refund transaction to be in the chain much
earlier.  Perhaps there are some tricks to pull off to get it to work, but
I haven't been working on this for a while so I'm a bit rusty in that area.

This might be helpful enough to help a lot of use cases, but shouldn't be
final.

-Allen

On Wed, Feb 19, 2014 at 6:22 PM, Natanael <natanael.l@gmail.com> wrote:

> Regarding chains of transactions intended to be published at once
> together, wouldn't it be easier to add a "only-mine-with-child flag"?
>
> That way the parent transactions aren't actually valid unless spent
> together with the transaction that depends on it, and only the original
> will have a child referencing it.
>
> Then malleability is not an issue at all for transaction chains if you
> only need to broadcast your full transaction chain once, and don't need to
> extend it in two or more occasions, *after* broadcasting subchains to the
> network, from the same set of pregenerated transactions.
>
> If you need to broadcast pregenerated subchains separately, then you need
> the last child in the chain to be non-malleable.
>
> This would require all miners to start to respect it at once in order to
> avoid forking the network.
>
> - Sent from my phone
> Den 19 feb 2014 22:13 skrev "Pieter Wuille" <pieter.wuille@gmail.com>:
>
> On Wed, Feb 19, 2014 at 9:28 PM, Michael Gronager <gronager@mac.com>
>> wrote:
>> > I think that we could guarantee fewer incidents by making version 1
>> transactions unmalleable and then optionally introduce a version 3 that
>> supported the malleability feature. That way most existing problematic
>> implementations would be fixed and no doors were closed for people
>> experimenting with other stuff - tx v 3 would probably then be called
>> experimental transactions.
>>
>> Just to be clear: this change is not directly intended to avoid
>> "incidents". It will take way too long to deploy this. Software should
>> deal with malleability. This is a longer-term solution intended to
>> provide non-malleability guarantees for clients that a) are upgraded
>> to use them  b) willing to restrict their functionality. As there are
>> several intended use cases for malleable transactions (the sighash
>> flags pretty directly are a way to signify what malleabilities are
>> *wanted*), this is not about outlawing malleability.
>>
>> While we could right now make all these rules non-standard, and
>> schedule a soft fork in a year or so to make them illegal, it would
>> mean removing potential functionality that can only be re-enabled
>> through a hard fork. This is significantly harder, so we should think
>> about it very well in advance.
>>
>> About new transaction and block versions: this allows implementing and
>> automatically scheduling a softfork without waiting for wallets to
>> upgrade. The non-DER signature change was discussed for over two
>> years, and implemented almost a year ago, and we still notice wallets
>> that don't support it. We can't expect every wallet to be instantly
>> modified (what about hardware wallets like the Trezor, for example?
>> they may not just be able to be upgraded). Nor is it necessary: if
>> your software only spends confirmed change, and tracks all debits
>> correctly, there is no need.
>>
>> --
>> 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=121054471&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=121054471&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

--089e01493cae564ae204f2cc6ea1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra">This is somewhat problematic in=
 my use case since some parts need to be in the chain earlier than others a=
nd have the same ID as expected.</div><div class=3D"gmail_extra"><br></div>=
<div class=3D"gmail_extra">
<a href=3D"https://bitcointalk.org/index.php?topic=3D260898.10">https://bit=
cointalk.org/index.php?topic=3D260898.10</a></div><div class=3D"gmail_extra=
"><br></div><div class=3D"gmail_extra">I haven&#39;t gone back to see if th=
ere are any ways around it, but the main problem here is I need the Contrac=
t TX to be in the chain much earlier than redeeming, but I need the refund =
transaction to be in the chain much earlier. =A0Perhaps there are some tric=
ks to pull off to get it to work, but I haven&#39;t been working on this fo=
r a while so I&#39;m a bit rusty in that area.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">This might =
be helpful enough to help a lot of use cases, but shouldn&#39;t be final.</=
div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">-Allen<=
br><br>
<div class=3D"gmail_quote">On Wed, Feb 19, 2014 at 6:22 PM, Natanael <span =
dir=3D"ltr">&lt;<a href=3D"mailto:natanael.l@gmail.com" target=3D"_blank">n=
atanael.l@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-col=
or:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<p dir=3D"ltr">Regarding chains of transactions intended to be published at=
 once together, wouldn&#39;t it be easier to add a &quot;only-mine-with-chi=
ld flag&quot;?</p>
<p dir=3D"ltr">That way the parent transactions aren&#39;t actually valid u=
nless spent together with the transaction that depends on it, and only the =
original will have a child referencing it.</p>
<p dir=3D"ltr">Then malleability is not an issue at all for transaction cha=
ins if you only need to broadcast your full transaction chain once, and don=
&#39;t need to extend it in two or more occasions, *after* broadcasting sub=
chains to the network, from the same set of pregenerated transactions.</p>


<p dir=3D"ltr">If you need to broadcast pregenerated subchains separately, =
then you need the last child in the chain to be non-malleable. </p>
<p dir=3D"ltr">This would require all miners to start to respect it at once=
 in order to avoid forking the network. </p>
<p dir=3D"ltr">- Sent from my phone</p>
<div class=3D"gmail_quote">Den 19 feb 2014 22:13 skrev &quot;Pieter Wuille&=
quot; &lt;<a href=3D"mailto:pieter.wuille@gmail.com" target=3D"_blank">piet=
er.wuille@gmail.com</a>&gt;:<div><div class=3D"h5"><br type=3D"attribution"=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;=
padding-left:1ex">

On Wed, Feb 19, 2014 at 9:28 PM, Michael Gronager &lt;<a href=3D"mailto:gro=
nager@mac.com" target=3D"_blank">gronager@mac.com</a>&gt; wrote:<br>
&gt; I think that we could guarantee fewer incidents by making version 1 tr=
ansactions unmalleable and then optionally introduce a version 3 that suppo=
rted the malleability feature. That way most existing problematic implement=
ations would be fixed and no doors were closed for people experimenting wit=
h other stuff - tx v 3 would probably then be called experimental transacti=
ons.<br>


<br>
Just to be clear: this change is not directly intended to avoid<br>
&quot;incidents&quot;. It will take way too long to deploy this. Software s=
hould<br>
deal with malleability. This is a longer-term solution intended to<br>
provide non-malleability guarantees for clients that a) are upgraded<br>
to use them =A0b) willing to restrict their functionality. As there are<br>
several intended use cases for malleable transactions (the sighash<br>
flags pretty directly are a way to signify what malleabilities are<br>
*wanted*), this is not about outlawing malleability.<br>
<br>
While we could right now make all these rules non-standard, and<br>
schedule a soft fork in a year or so to make them illegal, it would<br>
mean removing potential functionality that can only be re-enabled<br>
through a hard fork. This is significantly harder, so we should think<br>
about it very well in advance.<br>
<br>
About new transaction and block versions: this allows implementing and<br>
automatically scheduling a softfork without waiting for wallets to<br>
upgrade. The non-DER signature change was discussed for over two<br>
years, and implemented almost a year ago, and we still notice wallets<br>
that don&#39;t support it. We can&#39;t expect every wallet to be instantly=
<br>
modified (what about hardware wallets like the Trezor, for example?<br>
they may not just be able to be upgraded). Nor is it necessary: if<br>
your software only spends confirmed change, and tracks all debits<br>
correctly, there is no need.<br>
<br>
--<br>
Pieter<br>
<br>
---------------------------------------------------------------------------=
---<br>
Managing the Performance of Cloud-Based Applications<br>
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.<br>
Read the Whitepaper.<br>
<a href=3D"http://pubads.g.doubleclick.net/gampad/clk?id=3D121054471&amp;iu=
=3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.net/gam=
pad/clk?id=3D121054471&amp;iu=3D/4140/ostg.clktrk</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla=
nk">Bitcoin-development@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</blockquote></div></div></div>
<br>-----------------------------------------------------------------------=
-------<br>
Managing the Performance of Cloud-Based Applications<br>
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.<br>
Read the Whitepaper.<br>
<a href=3D"http://pubads.g.doubleclick.net/gampad/clk?id=3D121054471&amp;iu=
=3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.net/gam=
pad/clk?id=3D121054471&amp;iu=3D/4140/ostg.clktrk</a><br>__________________=
_____________________________<br>

Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div><br></div></div>

--089e01493cae564ae204f2cc6ea1--