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.

Sign up for GitHub

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

Jump to bottom

RFC: Transaction Payload #18

Merged
merged 36 commits into from
Nov 6, 2021
Merged

RFC: Transaction Payload #18

merged 36 commits into from
Nov 6, 2021

Conversation

luca-moser
Copy link
Member

@luca-moser luca-moser commented Jul 28, 2020 •
edited by Wollac
Loading

@Wollac Wollac mentioned this pull request Jul 28, 2020
Closed
@cvarley100 cvarley100 mentioned this pull request Jul 31, 2020
Closed
@Wollac Wollac mentioned this pull request Aug 2, 2020
Merged
@Wollac Wollac mentioned this pull request Aug 27, 2020
Merged
@wusyong wusyong mentioned this pull request Sep 2, 2020
Closed
@frohal
Copy link

frohal commented Sep 3, 2020 •
edited
Loading

Hi all - I assume that when this is first deployed, the complete balance on a address will be put into one UTXO ?
And when spending from a WOTS-address (like all have to do the first time they move funds) they would preferably send the complete output - Would the transaction be evaluated to 'invalid' if not all funds in one UTXO is actually accounted for in the outputs ? - Like - you have 5K in one address (now UTXO) and want to send 1K, you would now have to send 4k back to own address making a new UTXO for 4K ? Today one can just 'leave' the funds at the address, but that would probably no longer be possible ?

This would then immideatly avoid all the currenlty possible replay-thefts - right ?

@oopsmonk
Copy link

#32 SigLockedDustAllowanceOutput is missing in outputs and Syntactical Validation section.

m-renaud
m-renaud reviewed Apr 1, 2021
View reviewed changes
text/0000-transaction-payload/0000-transaction-payload.md Outdated
A `Blake2b-256` hash of the entire serialized data makes up <i>Transaction Payload</i>'s ID.

Following table structure describes the entirety of a <i>Transaction Payload</i>'s serialized form:
* [Data Type Notation](https://github.com/GalRogozinski/protocol-rfcs/blob/message/text/0017-message/0017-message.md#data-types)
Copy link

Choose a reason for hiding this comment

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

This seems to be referenced in several places, would it make sense to have an RFC to define the datatypes which would be the canonical location instead of RFCs cross linking each other?

Copy link
Contributor

Choose a reason for hiding this comment

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

I agree. However since this effects several RFCs it should happen in a separate RFC. I'll create an issue for that.

@Wollac Wollac merged commit b0d7214 into iotaledger:master Nov 6, 2021
@lzpap lzpap mentioned this pull request Nov 18, 2021
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@m-renaud m-renaud m-renaud left review comments

@thibault-martinez thibault-martinez thibault-martinez left review comments

@alexsporn alexsporn alexsporn left review comments

@wusyong wusyong wusyong left review comments

@frohal frohal frohal left review comments

@laumair laumair laumair left review comments

@cvarley100 cvarley100 cvarley100 left review comments

@Thoralf-M Thoralf-M Thoralf-M left review comments

@charlesthompson3 charlesthompson3 charlesthompson3 left review comments

@karimodm karimodm karimodm approved these changes

@Wollac Wollac Wollac approved these changes

@lzpap lzpap lzpap approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.