MIME-Version: 1.0
In-Reply-To: <552FDF73.6010104@sky-ip.org>
References: <552EF785.7000207@sky-ip.org>
	<CAPg+sBgAhdgPPjmT5i0PMYhQo=Hk6Weo8tpX_Wyn-NJ5Ye9D_A@mail.gmail.com>
	<552FDF73.6010104@sky-ip.org>
Date: Thu, 16 Apr 2015 10:34:31 -0700
Message-ID: <CAOG=w-vMjysbF5H8wWN2y45U3djFwpKMtXq3vCvB=-eFr7GqFg@mail.gmail.com>
From: Mark Friedenbach <mark@friedenbach.org>
To: s7r@sky-ip.org
Content-Type: multipart/alternative; boundary=001a113ec81a612e250513dae03f
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] 75%/95% threshold for transaction versions
Precedence: list

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

At this moment anyone can alter the txid. Assume transactions are 100%
malleable.
On Apr 16, 2015 9:13 AM, "s7r" <s7r@sky-ip.org> wrote:

> Hi Pieter,
>
> Thanks for your reply. I agree. Allen has a good point in the previous
> email too, so the suggestion might not fix anything and complicate things.
>
> The problem I am trying to solve is making all transactions
> non-malleable by default. I guess there is a very good reason why BIP62
> will not touch v1 anyway.
>
> I am trying to build a bitcoin contract which will relay on 3 things:
> - coinjoin / txes with inputs from multiple users which are signed by
> all users after they are merged together (every user is sure his coins
> will not be spent without the other users to spend anything, as per
> agreed contract);
> - pre-signed txes with nLockTime 'n' weeks. These txes will be signed
> before the inputs being spent are broadcasted/confirmed, using the txid
> provided by the user before broadcasting it. Malleability hurts here.
> - P2SH
>
> In simple terms, how malleable transactions really are in the network at
> this moment? Who can alter a txid without invalidating the tx? Just the
> parties who sign it? The miners? Anyone in the network? This is a little
> bit unclear to me.
>
> Another thing I would like to confirm, the 3 pieces of the bitcoin
> protocol mentioned above will be supported in _any_ future transaction
> version or block version, regardless what changes are made or features
> added to bitcoin core? The contract needs to be built and left unchanged
> for a very very long period of time...
>
>
> On 4/16/2015 8:22 AM, Pieter Wuille wrote:
> >
> > On Apr 16, 2015 1:46 AM, "s7r" <s7r@sky-ip.org <mailto:s7r@sky-ip.org>>
> > wrote:
> >> but for transaction versions? In simple terms, if > 75% from all the
> >> transactions in the latest 1000 blocks are version 'n', mark all
> >> previous transaction versions as non-standard and if > 95% from all the
> >> transactions in the latest 1000 blocks are version 'n' mark all previous
> >> transaction versions as invalid.
> >
> > What problem are you trying to solve?
> >
> > The reason why BIP62 (as specified, it is just a draft) does not make v1
> > transactions invalid is because it is opt-in. The creator of a
> > transaction needs to agree to protect it from malleability, and this
> > subjects him to extra rules in the creation.
> >
> > Forcing v3 transactions would require every piece of wallet software to
> > be changed.
> >
> > --
> > Pieter
> >
>
>
> ------------------------------------------------------------------------------
> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
> Develop your own process in accordance with the BPMN 2 standard
> Learn Process modeling best practices with Bonita BPM through live
> exercises
> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-
> event?utm_
> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

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

<p dir=3D"ltr">At this moment anyone can alter the txid. Assume transaction=
s are 100% malleable.</p>
<div class=3D"gmail_quote">On Apr 16, 2015 9:13 AM, &quot;s7r&quot; &lt;<a =
href=3D"mailto:s7r@sky-ip.org">s7r@sky-ip.org</a>&gt; wrote:<br type=3D"att=
ribution"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex">Hi Pieter,<br>
<br>
Thanks for your reply. I agree. Allen has a good point in the previous<br>
email too, so the suggestion might not fix anything and complicate things.<=
br>
<br>
The problem I am trying to solve is making all transactions<br>
non-malleable by default. I guess there is a very good reason why BIP62<br>
will not touch v1 anyway.<br>
<br>
I am trying to build a bitcoin contract which will relay on 3 things:<br>
- coinjoin / txes with inputs from multiple users which are signed by<br>
all users after they are merged together (every user is sure his coins<br>
will not be spent without the other users to spend anything, as per<br>
agreed contract);<br>
- pre-signed txes with nLockTime &#39;n&#39; weeks. These txes will be sign=
ed<br>
before the inputs being spent are broadcasted/confirmed, using the txid<br>
provided by the user before broadcasting it. Malleability hurts here.<br>
- P2SH<br>
<br>
In simple terms, how malleable transactions really are in the network at<br=
>
this moment? Who can alter a txid without invalidating the tx? Just the<br>
parties who sign it? The miners? Anyone in the network? This is a little<br=
>
bit unclear to me.<br>
<br>
Another thing I would like to confirm, the 3 pieces of the bitcoin<br>
protocol mentioned above will be supported in _any_ future transaction<br>
version or block version, regardless what changes are made or features<br>
added to bitcoin core? The contract needs to be built and left unchanged<br=
>
for a very very long period of time...<br>
<br>
<br>
On 4/16/2015 8:22 AM, Pieter Wuille wrote:<br>
&gt;<br>
&gt; On Apr 16, 2015 1:46 AM, &quot;s7r&quot; &lt;<a href=3D"mailto:s7r@sky=
-ip.org">s7r@sky-ip.org</a> &lt;mailto:<a href=3D"mailto:s7r@sky-ip.org">s7=
r@sky-ip.org</a>&gt;&gt;<br>
&gt; wrote:<br>
&gt;&gt; but for transaction versions? In simple terms, if &gt; 75% from al=
l the<br>
&gt;&gt; transactions in the latest 1000 blocks are version &#39;n&#39;, ma=
rk all<br>
&gt;&gt; previous transaction versions as non-standard and if &gt; 95% from=
 all the<br>
&gt;&gt; transactions in the latest 1000 blocks are version &#39;n&#39; mar=
k all previous<br>
&gt;&gt; transaction versions as invalid.<br>
&gt;<br>
&gt; What problem are you trying to solve?<br>
&gt;<br>
&gt; The reason why BIP62 (as specified, it is just a draft) does not make =
v1<br>
&gt; transactions invalid is because it is opt-in. The creator of a<br>
&gt; transaction needs to agree to protect it from malleability, and this<b=
r>
&gt; subjects him to extra rules in the creation.<br>
&gt;<br>
&gt; Forcing v3 transactions would require every piece of wallet software t=
o<br>
&gt; be changed.<br>
&gt;<br>
&gt; --<br>
&gt; Pieter<br>
&gt;<br>
<br>
---------------------------------------------------------------------------=
---<br>
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT<br>
Develop your own process in accordance with the BPMN 2 standard<br>
Learn Process modeling best practices with Bonita BPM through live exercise=
s<br>
<a href=3D"http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-=
" target=3D"_blank">http://www.bonitasoft.com/be-part-of-it/events/bpm-camp=
-virtual-</a> event?utm_<br>
source=3DSourceforge_BPM_Camp_5_6_15&amp;utm_medium=3Demail&amp;utm_campaig=
n=3DVA_SF<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>
</blockquote></div>

--001a113ec81a612e250513dae03f--