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

RFC: Transaction Payload #18

Merged
merged 36 commits into from Nov 6, 2021
Merged

Conversation

luca-moser
Copy link
Member

@luca-moser luca-moser commented Jul 28, 2020

@Wollac Wollac mentioned this pull request Jul 28, 2020
@frohal
Copy link

frohal commented Sep 3, 2020

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 ?

Wollac
Wollac approved these changes Jan 12, 2021
@luca-moser luca-moser requested a review from karimodm Jan 12, 2021
@oopsmonk
Copy link
Member

oopsmonk commented Feb 23, 2021

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

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

@m-renaud m-renaud Apr 1, 2021

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
Collaborator

@Wollac Wollac Nov 3, 2021

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 approved these changes Nov 4, 2021
lzpap
lzpap approved these changes Nov 5, 2021
@Wollac Wollac merged commit b0d7214 into iotaledger:master Nov 6, 2021
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