Track malleated tx events #607
Conversation
|
Probably a stupid Q: why parent transactions or transaction wrapping are/is needed? |
tendermint relies on the hash of the tx that the user is submitting to be the same as the tx that is committed to. This isn't the case for us, the hash of By arbitrarily replacing the the tx hash with it's "parent" hash, we are hacking tendermint to notify the user that their transaction was actually committed to. That's why this solution, along with the mempool one that working via the same mechanism, is hacky and we should be able to do better. In the mean time though, this unblocks the DALC, which is overdue. |
types/tx.go
Outdated
| // passed is not a tmproto.ChildTx, since the schema for PayForMessage is kept | ||
| // in the app, we cannot perform further checks without creating an import | ||
| // cycle. | ||
| func UnwrapChildTx(tx Tx) (parentHash []byte, unwrapped Tx, isChild bool) { |
There was a problem hiding this comment.
Maybe orthogonal to this PR, but semantically should this not return an error instead of a Boolean?
Would it help if the names were different? The parent Tx is essentially the original Tx, the submitted Tx, the mempool Tx, while the child Tx, is the (processed/malleated) block Tx. But we can also bikeshed about the name later. Just wanted to ask if it would make things clearer (I think it would for me). On another note: created a branch protection rule to apply to v[0-9].[0-9][0-9].x-celestia |
good point, changed ChildTx to Malleated and ParentTx to OriginalTx ff465e2
definitley!! can someone with appropriate repo permissions do this? It would be much appreciated. |
|
The proto linter fails because we're not using will hopefully fix with #566 |
Description
This PR adds an additional check when publishing an event to see if the tx was malleated. If so, it uses the "parent"'s (the tx before being malleated) hash as a key.
This solution works in a similar way to #581, and has the same downsides. Those being that it's a rather hacky solution, requires an extra hash be stored with each
PayForMessage, and that each time a transaction event is published, there is an extra check.While this works, more thought should be put into finding a better solution.
Closes: #590
Unblocks dalc #17
Unblocks celestia-app #171