Skip to content
This repository has been archived by the owner on Aug 18, 2020. It is now read-only.

add extra guard to fail if trying to submit a too big transaction #4131

Merged
merged 2 commits into from
May 13, 2019

Conversation

KtorZ
Copy link
Contributor

@KtorZ KtorZ commented May 2, 2019

Description

This can happen because we only estimate the maximum number of inputs allowed for the coin selection.
As a result, the transaction generated as a result of the coin selection may be slightly bigger than
the maximum sized allowed by the network (currently 8kb). So, having an extra sanity checks prevent
wrong transactions to be submitted (and added to our pendin set)

Linked issue

?

Type of change

  • 🐞 Bug fix (non-breaking change which fixes an issue)
  • 🛠 New feature (non-breaking change which adds functionality)
  • ⚠️ Breaking change (fix or feature that would cause existing functionality to change)
  • 🏭 Refactoring that does not change existing functionality but does improve things like code readability, structure etc
  • 🔨 New or improved tests for existing code
  • ⛑ git-flow chore (backport, hotfix, etc)

Developer checklist

  • I have read the style guide document, and my code follows the code style of this project.
  • If my code deals with exceptions, it follows the guidelines.
  • I have updated any documentation accordingly, if needed. Documentation changes can be reflected in opening a PR on cardanodocs.com, amending the inline Haddock comments, any relevant README file or one of the document listed in the docs directory.
  • CHANGELOG entry has been added and is linked to the correct PR on GitHub.

Testing checklist

  • I have added tests to cover my changes.
  • All new and existing tests passed.

QA Steps

Screenshots (if available)

How to merge

Send the message bors r+ to merge this PR. For more information, see
docs/how-to/bors.md.

This can happen because we only _estimate_ the maximum number of inputs allowed for the coin selection.
As a result, the transaction generated as a result of the coin selection may be slightly bigger than
the maximum sized allowed by the network (currently 8kb). So, having an extra sanity checks prevent
wrong transactions to be submitted (and added to our pendin set)
@KtorZ KtorZ self-assigned this May 2, 2019
Right meta -> return $ Right (taTx $ txAux, meta)
let sz = fromIntegral $ BL.length $ serialize txAux
maxSz <- Node.getMaxTxSize (walletPassive activeWallet ^. walletNode)
if sz > maxSz then

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@KtorZ, just to make sure, we don't need sz >= maxSz here (most probably not, but asking just to be safe :) )

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure how cardano-sl approaches maximum actually and whether it treats it as an inclusive or exclusive boundary 🤔 ...

@@ -177,7 +177,7 @@ pay activeWallet spendingPassword opts accountId payees = do
Right (txAux, partialMeta, _utxo) -> do
let sz = fromIntegral $ BL.length $ serialize txAux
maxSz <- Node.getMaxTxSize (walletPassive activeWallet ^. walletNode)
if sz > maxSz then
if sz >= maxSz then
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👌

@disassembler
Copy link
Contributor

@piotr-iohk can you approve the PR so I can merge it?

Copy link

@piotr-iohk piotr-iohk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@disassembler
Copy link
Contributor

bors r+

iohk-bors bot added a commit that referenced this pull request May 13, 2019
4131: add extra guard to fail if trying to submit a too big transaction r=disassembler a=KtorZ

## Description

<!--- A brief description of this PR and the problem is trying to solve -->

This can happen because we only _estimate_ the maximum number of inputs allowed for the coin selection.
As a result, the transaction generated as a result of the coin selection may be slightly bigger than
the maximum sized allowed by the network (currently 8kb). So, having an extra sanity checks prevent
wrong transactions to be submitted (and added to our pendin set)


## Linked issue

<!--- Put here the relevant issue from YouTrack -->

?



Co-authored-by: KtorZ <matthias.benkort@gmail.com>
Co-authored-by: Samuel Leathers <samuel.leathers@iohk.io>
@disassembler
Copy link
Contributor

bors r+

iohk-bors bot added a commit that referenced this pull request May 13, 2019
4131: add extra guard to fail if trying to submit a too big transaction r=disassembler a=KtorZ

## Description

<!--- A brief description of this PR and the problem is trying to solve -->

This can happen because we only _estimate_ the maximum number of inputs allowed for the coin selection.
As a result, the transaction generated as a result of the coin selection may be slightly bigger than
the maximum sized allowed by the network (currently 8kb). So, having an extra sanity checks prevent
wrong transactions to be submitted (and added to our pendin set)


## Linked issue

<!--- Put here the relevant issue from YouTrack -->

?



Co-authored-by: KtorZ <matthias.benkort@gmail.com>
Co-authored-by: Samuel Leathers <samuel.leathers@iohk.io>
@iohk-bors
Copy link
Contributor

iohk-bors bot commented May 13, 2019

@iohk-bors iohk-bors bot merged commit 2318269 into develop May 13, 2019
@iohk-bors iohk-bors bot deleted the KtorZ/tx-max-size-guard branch May 13, 2019 14:53
disassembler added a commit that referenced this pull request May 22, 2019
jbgi pushed a commit that referenced this pull request Jun 3, 2019
jbgi pushed a commit that referenced this pull request Jun 3, 2019
@jbgi jbgi mentioned this pull request Jun 7, 2019
12 tasks
jbgi pushed a commit that referenced this pull request Jun 11, 2019
jbgi pushed a commit that referenced this pull request Jun 11, 2019
jbgi pushed a commit that referenced this pull request Jun 11, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants