Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.212.174 as permitted sender)
	client-ip=209.85.212.174;
	envelope-from=allen.piscitello@gmail.com;
	helo=mail-wi0-f174.google.com; 
MIME-Version: 1.0
In-Reply-To: <552EF785.7000207@sky-ip.org>
References: <552EF785.7000207@sky-ip.org>
Date: Wed, 15 Apr 2015 21:04:09 -0500
Message-ID: <CAJfRnm6E=huM6GYnmjqF2Wjwcp_79axktwu8+tTriF+rx8Oi8Q@mail.gmail.com>
From: Allen Piscitello <allen.piscitello@gmail.com>
To: s7r@sky-ip.org
Content-Type: multipart/alternative; boundary=f46d043c80762009e90513cde14a
Cc: bitcoin-development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] 75%/95% threshold for transaction versions
Precedence: list

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

If I had a time locked signed transaction where I threw away the key, this
would potentially invalidate my transaction.

What is the point of such a rule?

On Wed, Apr 15, 2015 at 6:43 PM, s7r <s7r@sky-ip.org> wrote:

> Hi,
>
> Would it be wise to add a consensus rule like the one we have for blocks,
>
> (if > 75% from last 1000 blocks are version 'n' mark version 'n' as
> standard for blocks and if > 95% from the last 1000 blocks are version
> 'n' mark previous block versions as invalid)
>
> 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.
>
> At this moment, the standard in consensus is v1, but nothing is enforced
> in the network related to transaction versions.
>
> Regarding BIP62, as it can be read here [0] it is said that it requires
> v2 transactions. It is also said that transaction version 2 will be
> skipped and jump directly to v3, for an even version for transactions
> and blocks (?). Might as well add the rule for invalidating previous
> transaction versions if the majority updates - could this break anything
> or affect functionality in any way?
>
> BIP62 adds a newer transaction version which is optional and does not
> mark previous v1 as non-standard or invalid. This means bitcoin core
> will treat both v1 and v2/v3 transactions as standard and relay/mine
> them with the same priority, regardless of the tx version?
>
>
> Thanks.
>
> [0]
>
> https://bitcoin.stackexchange.com/questions/35904/how-much-of-bip-62-dealing-with-malleability-has-been-implemented
>
>
> ------------------------------------------------------------------------------
> 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
>

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

<div dir=3D"ltr">If I had a time locked signed transaction where I threw aw=
ay the key, this would potentially invalidate my transaction.<div><br></div=
><div>What is the point of such a rule?</div></div><div class=3D"gmail_extr=
a"><br><div class=3D"gmail_quote">On Wed, Apr 15, 2015 at 6:43 PM, s7r <spa=
n dir=3D"ltr">&lt;<a href=3D"mailto:s7r@sky-ip.org" target=3D"_blank">s7r@s=
ky-ip.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
Would it be wise to add a consensus rule like the one we have for blocks,<b=
r>
<br>
(if &gt; 75% from last 1000 blocks are version &#39;n&#39; mark version &#3=
9;n&#39; as<br>
standard for blocks and if &gt; 95% from the last 1000 blocks are version<b=
r>
&#39;n&#39; mark previous block versions as invalid)<br>
<br>
but for transaction versions? In simple terms, if &gt; 75% from all the<br>
transactions in the latest 1000 blocks are version &#39;n&#39;, mark all<br=
>
previous transaction versions as non-standard and if &gt; 95% from all the<=
br>
transactions in the latest 1000 blocks are version &#39;n&#39; mark all pre=
vious<br>
transaction versions as invalid.<br>
<br>
At this moment, the standard in consensus is v1, but nothing is enforced<br=
>
in the network related to transaction versions.<br>
<br>
Regarding BIP62, as it can be read here [0] it is said that it requires<br>
v2 transactions. It is also said that transaction version 2 will be<br>
skipped and jump directly to v3, for an even version for transactions<br>
and blocks (?). Might as well add the rule for invalidating previous<br>
transaction versions if the majority updates - could this break anything<br=
>
or affect functionality in any way?<br>
<br>
BIP62 adds a newer transaction version which is optional and does not<br>
mark previous v1 as non-standard or invalid. This means bitcoin core<br>
will treat both v1 and v2/v3 transactions as standard and relay/mine<br>
them with the same priority, regardless of the tx version?<br>
<br>
<br>
Thanks.<br>
<br>
[0]<br>
<a href=3D"https://bitcoin.stackexchange.com/questions/35904/how-much-of-bi=
p-62-dealing-with-malleability-has-been-implemented" target=3D"_blank">http=
s://bitcoin.stackexchange.com/questions/35904/how-much-of-bip-62-dealing-wi=
th-malleability-has-been-implemented</a><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><br></div>

--f46d043c80762009e90513cde14a--