Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

EIP-39: monotonic creation height rule #1865

Merged
merged 5 commits into from
Oct 14, 2022
Merged

Conversation

kushti
Copy link
Member

@kushti kushti commented Oct 9, 2022

In this PR, EIP-39 (ergoplatform/eips#80) is implemented as follows:

  • starting from block version Extension and votes fields was added to Header and Block #3 (5.0 soft-fork and after), the client is checking that for every output of a transaction, its creation height is not less than max creation height in inputs
  • note, only inputs are considered, data inputs are not
  • this rule is about soft-fork, as old nodes will continue to validate new blocks. So it will be activated in 5.0 soft-fork (can be merged with existing code even now). Also, the new rule is soft-forkable, so can be switched off (and so, replaced with another rule) via a soft-fork.


val tokens = boxCandidate.additionalTokens.map { case (id, amount) =>
if (java.util.Arrays.equals(id, assetId)) assetId -> deltaFn(amount) else assetId -> amount
}
Copy link
Member

Choose a reason for hiding this comment

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

The search over boxCandidate.additionalTokens happens 3 times. Passing an index in additionalTokens will be both faster and cleaner.

Copy link
Member Author

Choose a reason for hiding this comment

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

this is testing code

}

private def checkTx(from: IndexedSeq[ErgoBox], wrongTx: ErgoTransaction): Try[Int] = {
wrongTx.statelessValidity().flatMap(_ => wrongTx.statefulValidity(from, emptyDataBoxes, emptyStateContext))
Copy link
Member

Choose a reason for hiding this comment

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

please add comment on why it is called wrongTx?

Copy link
Member Author

Choose a reason for hiding this comment

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

Out of scope of this PR, renamed to tx anyway

kushti and others added 3 commits October 11, 2022 13:41
…ion.scala

Co-authored-by: Alexander Slesarenko <aslesarenko@users.noreply.github.com>
@scalahub
Copy link
Collaborator

  • its creation height is not less than max creation height in inputs

Do you mean "its creation height is not less or equal to than max creation height in inputs" ?
If not then we should be able to preserve the same (max) creation height from inputs (cc @greenhat)

@greenhat
Copy link
Member

  • its creation height is not less than max creation height in inputs

Do you mean "its creation height is not less or equal to than max creation height in inputs" ? If not then we should be able to preserve the same (max) creation height from inputs (cc @greenhat)

There are other inputs (with much higher heights) besides the pool box in the update tx.

@kushti
Copy link
Member Author

kushti commented Nov 24, 2022

  • its creation height is not less than max creation height in inputs

Do you mean "its creation height is not less or equal to than max creation height in inputs" ? If not then we should be able to preserve the same (max) creation height from inputs (cc @greenhat)

not less means equal or greater

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants