BitcoinCash/CHIP-VM-Limits
1
Fork 0
Code Issues Pull Requests Releases Activity

nits

Browse Source
This commit is contained in:
bitcoincashautist
2024-08-29 13:53:01 +02:00
parent 4c7ddd7de8
commit 004adaad11
2 changed files with 3 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files
rationale.md
+1 -1
View File
@@ -16,7 +16,7 @@ With the density-based approach, we can have maximum flexibility and functionali
We could consider taking this approach further: having a shared budget per transaction, rather than per input.
This would excerbate the effect of density-based approach: then users could then add filler inputs or outputs to create more budget for some other input inside the same transaction.
This would allow even more functionality and flexibility for users, but it has other trade-offs.
Please see [Rationale: Use of Input Length-Based Densities](#use-of-input-length--based-densities) below for further consideration.
Please see [Rationale: Use of Input Length-Based Densities](#use-of-input-length-based-densities) below for further consideration.
What are the alternatives to density-based operational cost?