From: Paul Lyon <pmlyon@hotmail•ca>
To: Mike Hearn <mike@plan99•net>, Richard Moore <me@ricmoo•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Self-dependency transaction question...
Date: Tue, 15 Jul 2014 10:56:20 -0300 [thread overview]
Message-ID: <BLU170-W39B40D1EFE92850D2AE3B6A5F60@phx.gbl> (raw)
In-Reply-To: <CANEZrP3RfYRoiwg_f9K0sf=vvpY=Wx78Q97Qp8uosK1GPV9QRg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1815 bytes --]
Thankfully those two duplicated transactions were never spent when they first appeared. Because of that, 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, conflicting versions are not present. That way you can carry on assuming that all transaction hashes are unique, and enforce that rule over the entire blockchain.
Date: Mon, 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.
What can happen and you must be aware of is duplicated transactions. Satoshi sort of assumed this could never happen because everything is hash based, 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 be able to process the older parts of the chain that have this. There is a BIP that covers the new rule.
------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck®
Code Sight™ - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists•sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[-- Attachment #2: Type: text/html, Size: 2244 bytes --]
next prev parent reply other threads:[~2014-07-15 14:08 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-13 23:32 Richard Moore
2014-07-14 2:25 ` Aaron Voisine
2014-07-14 2:51 ` Jeff Garzik
2014-07-14 11:18 ` Mike Hearn
2014-07-15 13:56 ` Paul Lyon [this message]
2014-07-14 20:51 ` Matt Whitlock
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=BLU170-W39B40D1EFE92850D2AE3B6A5F60@phx.gbl \
--to=pmlyon@hotmail$(echo .)ca \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=me@ricmoo$(echo .)com \
--cc=mike@plan99$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox