BTC change being displayed as a received TX after a send

[tshifty]

Overview

When doing a send on app.shapeshift.com of BTC we display the send and also the change back from the UTXO in transaction history. This could be problematic for people that want a CSV of deposits and withdrawals for tax purposes as this is BTC they have already held in their wallet being swept.

Steps To Reproduce:

1. Go to app.shapeshift.com
2. Do a send of BTC to another wallet
3. Notice that there are two new transactions in your history. One for the send and a receive from the change being sent back

Reference

Needs engineering

Acceptance Criteria

Users should only be able to see their original send and not the change back from the same TX with BTC

Screenshots/Mockups

Ownership

• [X] If my bounty needs engineering or needs product I have added the respective labels on the right
• [X] As the sponsor of this bounty I will review the changes in a preview environment (ops/product) or review the PR (engineering)

[DiggyDiggy2]

Product reviewed- just need to not include the change address.The acceptance criteria covers it. Thanks!

[0xdef1cafe]

@0xApotheosis @kaladinlight is this something we can handle more gracefully with a parser now? utxo coins are weird.

[kaladinlight]

@0xApotheosis @kaladinlight is this something we can handle more gracefully with a parser now? utxo coins are weird.

I want to say we can accomplish this in the parser. There will need to be an additional param for change addresses so we can more intelligently "skip" parse transactions on change addresses and also take into account we are not returning these transactions anymore and therefore need to to additional math for proper accounting on the send address for the associated transaction. Down to talk more in detail once the cosmos epic is wrapped.

[0xdef1cafe]

@cjthompson @elmutt this issue, thorchain trades, and FOXy rebase events all need to be handled in the same fashion from a client perspective

we need some sort of "synthetic transaction event" (with a nicer producty name) that captures all of these things that a user cares about, but aren't strictly on chain transactions. e.g. a THORChain trade can cross chains, and we want to see both sides, a rebase event is emitted by the FOXy contract and isn't a real tx on chain, and bitcoin change transfers on the address level don't make sense to a user from a tx perspective.

we need to discuss this with @DiggyDiggy2 @SS-FOX-McCloud @reallybeard as we'll have to change what we're rendering from the raw txs to these "synthetic ones". we probably still want to use the raw txs on the tx history export page

[0xdef1cafe]

still low pri, and my comment above is still valid - let's deal with this when we do a "blockchain activity" epic with UI that covers all these cases

[0xdef1cafe]

not an information theory problem - we have the right data in the context of lib (where tx's are parsed and we know the xpub) - we can reduce over this to ignore change and display this to web like a single tx

still not a high priority - users have never asked about this.