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; 
MIME-Version: 1.0
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
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with
	malleability
Precedence: list

--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--