get rid of TransactionInput/TransactionOutput.parent

[schildbach]

Problems with the parent fields, and their getParentTransaction() accessors:

• They pull information about how/where Input/Output are used into Input/Output themselves, and with it quite some business logic that depends on it.
• We can't make Input/Ouput and Transaction entirely immutable as long as the parents exist, because of the circular reference.
• It makes a number of methods more difficult to use than it should be, because a parent tx need to be supplied.
• Unit Tests that only deal with inputs or outputs need to make up a fake parent transaction.

To get rid of the parents, I think we must:

• Find better places for any business logic that involves using the parent. I expect in most, if not all, cases this would be Transaction.
• TransactionOutput will then only be a touple of value and script – both pretty arbitrary and certainly not enough to identify a particular output. This means:
• All places in the business logic that currently use TransactionOutput to identify an output would need to use TransactionOutPoint, which is exactly meant for this. This involves e.g. CoinSelector , CoinSelection, Wallet.unspents.

[msgilligan]

This is a good start for thinking about this. I will sleep on it.

One thought: maybe we are approaching this "bermuda triangle" from the wrong direction. We've been trying to work up from outpoints, outputs, and inputs eventually getting to transaction. Maybe we should look at the transaction use cases and the "types" of transaction objects and work down to see which "types" of outpoints, outputs, and inputs they need?