path: root/ea/f20117b2524800dc816ef47bc7003a3af7824e

Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <pmlyon@hotmail.ca>) id 1X73Pc-0002uy-HE
	for bitcoin-development@lists.sourceforge.net;
	Tue, 15 Jul 2014 14:08:56 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of hotmail.ca
	designates 65.55.111.76 as permitted sender)
	client-ip=65.55.111.76; envelope-from=pmlyon@hotmail.ca;
	helo=BLU004-OMC2S1.hotmail.com; 
Received: from blu004-omc2s1.hotmail.com ([65.55.111.76])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.76) id 1X73Pb-0003Vm-B6
	for bitcoin-development@lists.sourceforge.net;
	Tue, 15 Jul 2014 14:08:56 +0000
Received: from BLU170-W39 ([65.55.111.71]) by BLU004-OMC2S1.hotmail.com with
	Microsoft SMTPSVC(7.5.7601.22712); Tue, 15 Jul 2014 06:56:21 -0700
X-TMN: [TtLPDiRVUTZW2K1IrQuQA0u81L+kioBU]
X-Originating-Email: [pmlyon@hotmail.ca]
Message-ID: <BLU170-W39B40D1EFE92850D2AE3B6A5F60@phx.gbl>
Content-Type: multipart/alternative;
	boundary="_6ee2a025-56d5-43bb-85ee-8b8474780adc_"
From: Paul Lyon <pmlyon@hotmail.ca>
To: Mike Hearn <mike@plan99.net>, Richard Moore <me@ricmoo.com>
Date: Tue, 15 Jul 2014 10:56:20 -0300
Importance: Normal
In-Reply-To: <CANEZrP3RfYRoiwg_f9K0sf=vvpY=Wx78Q97Qp8uosK1GPV9QRg@mail.gmail.com>
References: <35E6FF51-F9C4-4973-8489-B364E7C27C14@ricmoo.com>,
	<CANEZrP3RfYRoiwg_f9K0sf=vvpY=Wx78Q97Qp8uosK1GPV9QRg@mail.gmail.com>
MIME-Version: 1.0
X-OriginalArrivalTime: 15 Jul 2014 13:56:21.0739 (UTC)
	FILETIME=[8F25B3B0:01CFA034]
X-Spam-Score: -0.5 (/)
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
	(pmlyon[at]hotmail.ca)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
	no trust [65.55.111.76 listed in list.dnswl.org]
	1.0 HTML_MESSAGE           BODY: HTML included in message
X-Headers-End: 1X73Pb-0003Vm-B6
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Self-dependency transaction question...
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: Tue, 15 Jul 2014 14:08:56 -0000

--_6ee2a025-56d5-43bb-85ee-8b8474780adc_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Thankfully those two duplicated transactions were never spent when they fir=
st appeared. Because of that=2C I chose to not not add them to the UTXO at =
all when they first appear. When the duplicates appear they get added to th=
e UTXO successfully because the earlier=2C conflicting versions are not pre=
sent. That way you can carry on assuming that all transaction hashes are un=
ique=2C and enforce that rule over the entire blockchain.

Date: Mon=2C 14 Jul 2014 13:18:22 +0200
From: mike@plan99.net
To: me@ricmoo.com
CC: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Self-dependency transaction question...

Conceptually all transactions in the block chain lie on a single timeline. =
The fact that we quantise that timeline into blocks is in many ways neither=
 here nor there - it's still a strict line. =0A=

What can happen and you must be aware of is duplicated transactions. Satosh=
i sort of assumed this could never happen because everything is hash based=
=2C but forgot that duplicating coinbases is possible and at one point this=
 did happen. It was banned by a rule change afterwards but you still must b=
e able to process the older parts of the chain that have this. There is a B=
IP that covers the new rule.=0A=

=0A=

---------------------------------------------------------------------------=
---=0A=
Want fast and easy access to all the code in your enterprise? Index and=0A=
search up to 200=2C000 lines of code with a free copy of Black Duck=AE=0A=
Code Sight=99 - the same software that powers the world's largest code=0A=
search on Ohloh=2C the Black Duck Open Hub! Try it now.=0A=
http://p.sf.net/sfu/bds
_______________________________________________=0A=
Bitcoin-development mailing list=0A=
Bitcoin-development@lists.sourceforge.net=0A=
https://lists.sourceforge.net/lists/listinfo/bitcoin-development 		 	   		 =
 =

--_6ee2a025-56d5-43bb-85ee-8b8474780adc_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style><!--
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 12pt=3B
font-family:Calibri
}
--></style></head>
<body class=3D'hmmessage'><div dir=3D'ltr'>Thankfully those two duplicated =
transactions were never spent when they first appeared. Because of that=2C =
I chose to not not add them to the UTXO at all when they first appear. When=
 the duplicates appear they get added to the UTXO successfully because the =
earlier=2C conflicting versions are not present.&nbsp=3BThat way you can ca=
rry on assuming that all transaction hashes are unique=2C and enforce that =
rule over the entire blockchain.<br><br><div><hr id=3D"stopSpelling">Date: =
Mon=2C 14 Jul 2014 13:18:22 +0200<br>From: mike@plan99.net<br>To: me@ricmoo=
.com<br>CC: bitcoin-development@lists.sourceforge.net<br>Subject: Re: [Bitc=
oin-development] Self-dependency transaction question...<br><br><div dir=3D=
"ltr"><div class=3D"ecxgmail_extra"><div class=3D"ecxgmail_quote"><div>Conc=
eptually all transactions in the block chain lie on a single timeline. The =
fact that we quantise that timeline into blocks is in many ways neither her=
e nor there - it's still a strict line.&nbsp=3B</div>=0A=
<div><br></div><div>What <i>can</i>&nbsp=3Bhappen and you must be aware of =
is duplicated transactions. Satoshi sort of assumed this could never happen=
 because everything is hash based=2C but forgot that duplicating coinbases =
is possible and at one point this did happen. It was banned by a rule chang=
e afterwards but you still must be able to process the older parts of the c=
hain that have this. There is a BIP that covers the new rule.</div>=0A=
<div><br></div></div></div></div>=0A=
<br>-----------------------------------------------------------------------=
-------=0A=
Want fast and easy access to all the code in your enterprise? Index and=0A=
search up to 200=2C000 lines of code with a free copy of Black Duck=AE=0A=
Code Sight=99 - the same software that powers the world's largest code=0A=
search on Ohloh=2C the Black Duck Open Hub! Try it now.=0A=
http://p.sf.net/sfu/bds<br>_______________________________________________=
=0A=
Bitcoin-development mailing list=0A=
Bitcoin-development@lists.sourceforge.net=0A=
https://lists.sourceforge.net/lists/listinfo/bitcoin-development</div> 		 	=
   		  </div></body>
</html>=

--_6ee2a025-56d5-43bb-85ee-8b8474780adc_--