path: root/cd/5c772b63a7820cd227375a42831bdc90900b77

Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
	helo=mx.sourceforge.net)
	by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <natanael.l@gmail.com>) id 1WGOPL-0007OA-D4
	for bitcoin-development@lists.sourceforge.net;
	Thu, 20 Feb 2014 07:50:59 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.212.172 as permitted sender)
	client-ip=209.85.212.172; envelope-from=natanael.l@gmail.com;
	helo=mail-wi0-f172.google.com; 
Received: from mail-wi0-f172.google.com ([209.85.212.172])
	by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1WGOPJ-0000ta-9r
	for bitcoin-development@lists.sourceforge.net;
	Thu, 20 Feb 2014 07:50:59 +0000
Received: by mail-wi0-f172.google.com with SMTP id e4so5563756wiv.17
	for <bitcoin-development@lists.sourceforge.net>;
	Wed, 19 Feb 2014 23:50:51 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.180.77.74 with SMTP id q10mr931074wiw.39.1392882651141; Wed,
	19 Feb 2014 23:50:51 -0800 (PST)
Received: by 10.194.54.10 with HTTP; Wed, 19 Feb 2014 23:50:51 -0800 (PST)
Received: by 10.194.54.10 with HTTP; Wed, 19 Feb 2014 23:50:51 -0800 (PST)
In-Reply-To: <CAJfRnm6itmEv6wsFyZGMYVLXSms5v9Q9BfhFfZEoJLxMMiP_2g@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>
	<CAJfRnm6itmEv6wsFyZGMYVLXSms5v9Q9BfhFfZEoJLxMMiP_2g@mail.gmail.com>
Date: Thu, 20 Feb 2014 08:50:51 +0100
Message-ID: <CAAt2M1-wLn9n00ADjGni+i1JTDEAg5a8QEz83K+dCSRsMZRCLA@mail.gmail.com>
From: Natanael <natanael.l@gmail.com>
To: Allen Piscitello <allen.piscitello@gmail.com>
Content-Type: multipart/alternative; boundary=f46d043bdf6aa29e6a04f2d1c348
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
	(natanael.l[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: 1WGOPJ-0000ta-9r
Cc: 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 07:50:59 -0000

--f46d043bdf6aa29e6a04f2d1c348
Content-Type: text/plain; charset=UTF-8

You could pregenerate entire "trees" of alternative outcomes where you pick
one branch / chain to broadcast based on the real world events as they
happen.

But I see another problem regarding use of oracles, if you have a P2SH
address with 2-of-3 signatures or similar in the chain, amd some
transactions following it, then the oracle needs to pregenerate both
transactions for both outcomes in advance. But the oracle probably don't
want to actually share it in advance to any third party before the event
happened.

This can be solved if the oracle only shares the transaction hash in
advance and then hands out a Zero-knowledge proof of that transaction with
the given hash is following the agreed upon rules, so you can trust the
transaction chain anyway and still being able to pregenerate a full tree of
transactions.

And then the oracle will release one of the possible transactions after the
event in question has happened, so you can broadcast the chain of choice.

This unfortunately breaks down if the number of possible outcomes becomes
too many as you would need to both generate and store a tree of possible
outcomes that is massive.

- Sent from my phone
Den 20 feb 2014 02:29 skrev "Allen Piscitello" <allen.piscitello@gmail.com>:

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

--f46d043bdf6aa29e6a04f2d1c348
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">You could pregenerate entire &quot;trees&quot; of alternativ=
e outcomes where you pick one branch / chain to broadcast based on the real=
 world events as they happen. </p>
<p dir=3D"ltr">But I see another problem regarding use of oracles, if you h=
ave a P2SH address with 2-of-3 signatures or similar in the chain, amd some=
 transactions following it, then the oracle needs to pregenerate both trans=
actions for both outcomes in advance. But the oracle probably don&#39;t wan=
t to actually share it in advance to any third party before the event happe=
ned. </p>

<p dir=3D"ltr">This can be solved if the oracle only shares the transaction=
 hash in advance and then hands out a Zero-knowledge proof of that transact=
ion with the given hash is following the agreed upon rules, so you can trus=
t the transaction chain anyway and still being able to pregenerate a full t=
ree of transactions. </p>

<p dir=3D"ltr">And then the oracle will release one of the possible transac=
tions after the event in question has happened, so you can broadcast the ch=
ain of choice. </p>
<p dir=3D"ltr">This unfortunately breaks down if the number of possible out=
comes becomes too many as you would need to both generate and store a tree =
of possible outcomes that is massive. </p>
<p dir=3D"ltr">- Sent from my phone</p>
<div class=3D"gmail_quote">Den 20 feb 2014 02:29 skrev &quot;Allen Piscitel=
lo&quot; &lt;<a href=3D"mailto:allen.piscitello@gmail.com">allen.piscitello=
@gmail.com</a>&gt;:<br type=3D"attribution"><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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" target=3D"_=
blank">https://bitcointalk.org/index.php?topic=3D260898.10</a></div><div cl=
ass=3D"gmail_extra"><br></div><div class=3D"gmail_extra">I haven&#39;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. =C2=A0Perhap=
s there are some tricks to pull off to get it to work, but I haven&#39;t be=
en working on this for 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><br type=3D"attribution"><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1=
px;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 =C2=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" 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>
<br></blockquote></div><br></div></div>
</blockquote></div>

--f46d043bdf6aa29e6a04f2d1c348--