From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YiZAC-0000fc-9J for bitcoin-development@lists.sourceforge.net; Thu, 16 Apr 2015 02:04:20 +0000 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; Received: from mail-wi0-f174.google.com ([209.85.212.174]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YiZA7-0007ll-OG for bitcoin-development@lists.sourceforge.net; Thu, 16 Apr 2015 02:04:20 +0000 Received: by widdi4 with SMTP id di4so176366822wid.0 for ; Wed, 15 Apr 2015 19:04:09 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.92.65 with SMTP id ck1mr567001wib.78.1429149849748; Wed, 15 Apr 2015 19:04:09 -0700 (PDT) Received: by 10.28.30.19 with HTTP; Wed, 15 Apr 2015 19:04:09 -0700 (PDT) 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: From: Allen Piscitello To: s7r@sky-ip.org Content-Type: multipart/alternative; boundary=f46d043c80762009e90513cde14a 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: 1YiZA7-0007ll-OG Cc: bitcoin-development Subject: Re: [Bitcoin-development] 75%/95% threshold for transaction versions X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 02:04:20 -0000 --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 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
If I had a time locked signed transaction where I threw aw= ay 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@s= ky-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 = 9;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<= br> transactions in the latest 1000 blocks are version 'n' mark all pre= vious
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]
http= s://bitcoin.stackexchange.com/questions/35904/how-much-of-bip-62-dealing-wi= th-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 exercise= s
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp= -virtual- event?utm_
source=3DSourceforge_BPM_Camp_5_6_15&utm_medium=3Demail&utm_campaig= n=3DVA_SF
_______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment

--f46d043c80762009e90513cde14a--