Leios prototype tx-firehose: dynamically allow for txs with more outputs - #6658
Merged
Conversation
…are gone Two bugs stopped --outputs-per-tx > 1 from running for more than a few seconds, both showing up as "insufficient funds - total inputs (364400 lovelace) do not cover fee (1000000)". takeInputs picks by TxIn order, i.e. effectively at random, so it could select `target` dust entries and split their sum `target` ways — producing finer dust, and repeating. 364,400 lovelace sits exactly in the divide-by-5 sequence down from the original 30M ADA, with the value itself untouched (29,999,924,000,000 across 305 UTxOs) simply because it was never selected. takeLargest instead takes the `target` largest funds, extending with the next largest until they cover fee + target * outputFloor, so an output is never created too small to spend again and stranded dust gets consolidated rather than sharpened. That also subsumes the fan-out case, so takeFattest goes. Separately, keeping the inputs on a reject is right for a transient failure but wrong when the ledger says they are gone: takeInputs is deterministic, so the retry rebuilt the same tx and earned the same rejection until max-consecutive-errors. Worse at startup with a single UTxO and a fan-out target, where that one tx is the only one buildable. Measured on dozen-devnet: --outputs-per-tx 5 gives 648 B transactions, 5 in / 5 out, no failures.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two bugs stopped --outputs-per-tx > 1 from running for more than a few seconds, both showing up as "insufficient funds - total inputs (364400 lovelace) do not cover fee (1000000)".
takeInputs picks by TxIn order, i.e. effectively at random, so it could select
targetdust entries and split their sumtargetways — producing finer dust, and repeating. 364,400 lovelace sits exactly in the divide-by-5 sequence down from the original 30M ADA, with the value itself untouched (29,999,924,000,000 across 305 UTxOs) simply because it was never selected. takeLargest instead takes thetargetlargest funds, extending with the next largest until they cover fee + target * outputFloor, so an output is never created too small to spend again and stranded dust gets consolidated rather than sharpened. That also subsumes the fan-out case, so takeFattest goes.Separately, keeping the inputs on a reject is right for a transient failure but wrong when the ledger says they are gone: takeInputs is deterministic, so the retry rebuilt the same tx and earned the same rejection until max-consecutive-errors. Worse at startup with a single UTxO and a fan-out target, where that one tx is the only one buildable.
Measured on dozen-devnet: --outputs-per-tx 5 gives 648 B transactions, 5 in / 5 out, no failures.
Description
Add your description here, if it fixes a particular issue please provide a
link
to the issue.
Checklist
See Running tests for more details
CHANGELOG.mdfor affected packagecardano-node-chairman,cardano-submit-apiandcardano-testnetinstead need achangelog fragment in
<package>/.changes/, because theirCHANGELOG.mdis generatedfrom fragments at release time. Copy
_TEMPLATE.ymlfrom that directory, or runnix run github:input-output-hk/cardano-dev#herald -- new.cabalfiles are updatedhlint. See.github/workflows/check-hlint.ymlto get thehlintversionstylish-haskell. See.github/workflows/stylish-haskell.ymlto get thestylish-haskellversionghc-9.6andghc-9.12Note on CI
If your PR is from a fork, the necessary CI jobs won't trigger automatically for security reasons.
You will need to get someone with write privileges. Please contact IOG node developers to do this
for you.