feat: enforce maximum serialized size for output notes

[Forostovec]

Introduced NOTE_MAX_SIZE (32 KiB) and enforce it on individual output notes. The limit is applied based on the Serializable::get_size_hint implementation for notes and their components.

• Added NOTE_MAX_SIZE constant for serialized note size
• Implemented get_size_hint for Note, PartialNote, and related note types
• Implemented get_size_hint for OutputNote and OutputNotes
• Reject output notes larger than NOTE_MAX_SIZE in OutputNotes::new using
  TransactionOutputError::OutputNoteSizeLimitExceeded { note_id, note_size }
• Added test to ensure OutputNote::get_size_hint matches serialized length
• Added a regression test that constructs an oversized note and asserts that OutputNotes::new returns OutputNoteSizeLimitExceeded

fixes #2195

[Copilot]

Pull request overview

This PR introduces a maximum serialized size limit of 32 KiB for individual output notes to prevent excessively large notes from being created. The limit is enforced during OutputNotes construction and applies to all output note variants (Full, Partial, and Header).

• Added NOTE_MAX_SIZE constant (32 KiB) and integrated it into validation logic
• Implemented get_size_hint methods throughout the note hierarchy to enable size calculation
• Added validation in OutputNotes::new to reject oversized notes with a descriptive error

Reviewed changes

Copilot reviewed 14 out of 14 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
crates/miden-protocol/src/constants.rs	Defines NOTE_MAX_SIZE constant (32 KiB)
crates/miden-protocol/src/errors/mod.rs	Adds OutputNoteSizeLimitExceeded error variant with note ID and size details
crates/miden-protocol/src/transaction/outputs.rs	Implements size validation in OutputNotes::new, adds get_size_hint for OutputNote and OutputNotes, and includes comprehensive tests
crates/miden-protocol/src/note/mod.rs	Implements get_size_hint for Note based on metadata and details sizes
crates/miden-protocol/src/note/partial.rs	Implements get_size_hint for PartialNote using metadata, recipient digest, and assets sizes
crates/miden-protocol/src/note/header.rs	Implements get_size_hint for NoteHeader summing note ID and metadata sizes
crates/miden-protocol/src/note/metadata.rs	Implements get_size_hint for NoteMetadata returning Word::SERIALIZED_SIZE
crates/miden-protocol/src/note/details.rs	Implements get_size_hint for NoteDetails summing assets and recipient sizes
crates/miden-protocol/src/note/assets.rs	Implements get_size_hint for NoteAssets accounting for count prefix and individual asset sizes
crates/miden-protocol/src/note/inputs.rs	Implements get_size_hint for NoteInputs accounting for length prefix and individual input sizes
crates/miden-protocol/src/note/recipient.rs	Implements get_size_hint for NoteRecipient summing script, inputs, and serial number sizes
crates/miden-protocol/src/note/script.rs	Implements get_size_hint for NoteScript summing MAST and entrypoint sizes
crates/miden-protocol/src/note/note_id.rs	Implements get_size_hint for NoteId returning Word::SERIALIZED_SIZE
crates/miden-protocol/src/note/nullifier.rs	Implements get_size_hint for Nullifier returning Word::SERIALIZED_SIZE

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[bobbinth]

@Forostovec - thank you for working on this! Seems like some tests are not passing. Could you make the CI green?

[Forostovec]

Introduced NOTE_MAX_SIZE (32 KiB) and enforce it on individual output notes

Made changes

[PhilippGackstatter]

Great work! Looks good!

I left a few small comments. Once these are addressed, I think this is good to merge.

[PhilippGackstatter]

I think we should construct a more complex note to make sure everything is correctly covered. The note returned by mock_noop is a bit too simple, I think. E.g. I would add at least two assets and at least two note inputs.

[PhilippGackstatter]

I think we don't technically need this method for the purpose of this issue, right? If so, I'd remove it. Especially since it isn't covered by a test.

[Forostovec]

I think we don't technically need this method for the purpose of this issue, right? If so, I'd remove it. Especially since it isn't covered by a test.

Did it!

[bobbinth]

Looks good! Thank you! I left a couple of comments inline.

One thing that I'm still trying to think through is at what level do we want to enforce this limit. The approach taken in this PR is to enforce this at OutputNotes level - but there are other options:

• Enforce it at Note level. This would imply that we'd need to make Note::new() fallible - which is annoying. And I'm also not 100% sure this is the right approach.
• Enforce it at OutputNote level. This would probably be ideal because this would also imply that the limit is automatically imposed for OutputNoteBatch as well, but since OutputNote is an enum, I'm not sure how to do this.

Also, I wonder if we should impose a separate limit on NoteScript. And maybe an alternative approach could be to impose limits on individual note components - though, this has its own downsides.

[bobbinth]

Why do we need to iterate over inputs to compute the size? Each input is just one Felt and so we should be able to just multiple the number of inputs by felt size, right?

[PhilippGackstatter]

Good points, thank you!

Also, I wonder if we should impose a separate limit on NoteScript.

Having a limit on the note script may allow omitting any checks at the output note level, since then all note components are size limited, e.g:

• note attachments: 16 KiB
• note assets: ~8 KiB
• note inputs: 8 KiB

If we now impose a note script limit of, say, 16 KiB, then the maximum possible note size is 48 KiB. This is higher than the 32 KiB we want to impose as an overall limit here, but this could be okay because fees will already disincentivize constructing needlessly large notes.

Not for this PR, but one separate question is whether we will be able to impose a note script limit in the tx kernel (and similarly for account code). I believe we can't really get the script size from within the VM, so it seems to me we can't enforce this at that level, short of hashing the entire script of a note in the VM.

So, if we simply add validation to NoteScript::new, then this would solve the issue fairly nicely, I think.

The alternatives are:

• Make OutputNoteBatch a proper struct and enforce the size limit same as in OutputNotes::new.
• Rename OutputNote to OutputNoteKind and introduce struct OutputNote(OutputNoteKind) for the sole purpose of enforcing the size limit.

Out of these, the second one is annoying but probably cleanest to enforce the limit only in one place.

Overall, I would prefer the NoteScript::new approach. We can start with 16 KiB and if that's too low we can always increase it. The main downside is that the max output note size is fairly large, but with fees this should not really occur in practice.

[bobbinth]

Overall, I would prefer the NoteScript::new approach. We can start with 16 KiB and if that's too low we can always increase it. The main downside is that the max output note size is fairly large, but with fees this should not really occur in practice.

I agree with this. Though, I wonder if we should start with 32KB - mostly because the way we serialize MAST code now is not super efficient (and I'm actually not sure if we strip out all the decorator info). There are a few additional considerations here:

1. I'm curious how big P2ID note script is for hand-written vs. compiler-generated code. Just want to sanity-check the 32 KB limit.
2. We've had discussions about putting not just the note script, but also note constructor code into the note package. When we build a note script from note package, we'll probably need to prune all constructor-related code to make sure we don't serialize some irrelevant code. Doing this if the programs are static is not difficult - but if there are any dynamic calls, this task would be non-trivial.

Also cc @greenhat and @huitseeker as some of this is relevant to the topics you are working on.

[greenhat]

Overall, I would prefer the NoteScript::new approach. We can start with 16 KiB and if that's too low we can always increase it. The main downside is that the max output note size is fairly large, but with fees this should not really occur in practice.

I agree with this. Though, I wonder if we should start with 32KB - mostly because the way we serialize MAST code now is not super efficient (and I'm actually not sure if we strip out all the decorator info). There are a few additional considerations here:

1. I'm curious how big P2ID note script is for hand-written vs. compiler-generated code. Just want to sanity-check the 32 KB limit.

If I serialize the MastForest of the P2ID note it's 72480 bytes. I think we discussed before, how we want to strip the debug decorators, but I don't know if it was implemented. The ~70KB is the size without stripping.

2. We've had discussions about putting not just the note script, but also note constructor code into the note package. When we build a note script from note package, we'll probably need to prune all constructor-related code to make sure we don't serialize some irrelevant code. Doing this if the programs are static is not difficult - but if there are any dynamic calls, this task would be non-trivial.

FWIW, we don't use dynexec. But I don't think I fully understand how the static code removal would work. Pinging @bitwalker

[bobbinth]

If I serialize the MastForest of the P2ID note it's 72480 bytes. I think we discussed before, how we want to strip the debug decorators, but I don't know if it was implemented. The ~70KB is the size without stripping.

Oh wow - that's pretty large. For comparison:

• Hand-written P2ID note is about 5 KB with decorators.
• Without decorators it is 1.4 KB.
• I think with better serialization we should be able to get it to be under 500 bytes.

Not directly related to this issue, but would be good to understand where the 70KB size is coming from:

• Assuming the same decorator/code ratio as for hand-written note, the version w/o decorators should be under 20KB.
• It may also be possible that compiler-generated code inserts more decorators - would be good to double check this.
• Beyond decorators, I wonder if there are some low-hanging fruit for optimizing the code that could get the size down.

@greenhat - could you create an issue in the compiler repo to investigate these?

For this issue, I think we should definitely set the NoteScript size limit at 32KB or above. But this does bring us back what's the right place to set this limit at. Specifically, we frequently serialize NoteScript with decorators to disc for debug purposes - which should be fine. We want to strip decorators and compact the code at the time when we send it over the wire (i.e., to the node). Maybe the best place for doing this is at the time when we create an OutputNote? But there could be other options too.

[bitwalker]

FWIW, we don't use dynexec. But I don't think I fully understand how the static code removal would work. Pinging @bitwalker

Essentially we'd be doing link-time dead code elimination, but starting by explicitly marking certain procedures as dead (e.g. the note script constructor).

I'm not sure dynexec/dyncall cause any particular problems here though - we can know statically whether there are any references to a procedure (dynamic or static) within the same package. So if we were going to try and strip out the note script constructor (for example), then any reference to that procedure would need to raise an error (or simply not remove that procedure and its callees, it sort of depends on how strict we want to be about it).

It may also be possible that compiler-generated code inserts more decorators - would be good to double check this.

It definitely does, such as the traces for call frame tracking. It also has to include procedures for anything from libcore/liballoc that are referenced and used.

We may also need to play with optimization levels and such to see if that makes any meaningful difference.

Now that we have some practical example programs, we should do some statistical analysis of the MASM to determine where the bulk of the instruction count comes from. My suspicion is that it is primarily stack management operations, but if we see a lot of common sequences, we could look into factoring those out into intrinsic procedures to collapse those sequences.

I'm sure there is fat to be trimmed, but we are also inherently fighting a bit of an uphill battle here, because we are effectively emulating Wasm on Miden, so there will always be some impedance mismatch that results in more code than would otherwise be necessary. Luckily, there aren't too many places where that mismatch is particularly noticeable, but its still something we have to take into account.

[greenhat]

Not directly related to this issue, but would be good to understand where the 70KB size is coming from:

• Assuming the same decorator/code ratio as for hand-written note, the version w/o decorators should be under 20KB.
• It may also be possible that compiler-generated code inserts more decorators - would be good to double check this.
• Beyond decorators, I wonder if there are some low-hanging fruit for optimizing the code that could get the size down.

@greenhat - could you create an issue in the compiler repo to investigate these?

0xMiden/compiler#852

[PhilippGackstatter]

But this does bring us back what's the right place to set this limit at. Specifically, we frequently serialize NoteScript with decorators to disc for debug purposes - which should be fine.

I think there could be two points in time where enforcing the size limit could make sense:

• At the time we build an ExecutedTransaction. This could be done at the OutputNote or OutputNotes level as you suggested.
• At the time we build a ProvenTransaction. This would be done in ProvenTransactionBuilder::build, which would be the same time at which we currently enforce AccountUpdateDetails size restrictions.

As @bobbinth mentioned before, we also want to make sure that these limits continue to be enforced at the batch and block level:

• Since the limit of AccountUpdateDetails is enforced in TxAccountUpdate and not as part of the type itself, we don't have that limit enforced in batch or block currently. The simplest solution is probably to enforce this at the BatchAccountUpdate and BlockAccountUpdate level. It would be possible to do it at the AccountUpdateDetails level, but since is is an enum, this is a bit harder to do. Also, this allows us to have different account update limits for transactions and batches/blocks. (This would be a separate PR, but wanted to mention it here for completeness).
• For notes, I think the same logic applies.
  • If we enforce size limits in OutputNote, then this also applies to batch and block. Enforcing it in OutputNotes only applies at the transaction level and changing batches or blocks to use it isn't really easily possible, because we have to retain the batch note index.
    • This looks pretty clean, but could be problematic for testing. For instance, say we want to test a flow where two transactions A and B build on top of each other. A creates a compiler-generated (and therefore large) OutputNote and B consumes that note. When the note is created as part of A, this fails the transaction because it exceeds the limit, which would be annoying. At least that's how I understand this would work, but if that's correct, I think we should avoid that situation.
  • If we enforce the size limit in ProvenTransaction, then we'd also have to separately enforce it in batch and block.
    • This seems less desirable because of code duplication, and also unnecessary, because we want the same note size limit across tx, batch and block, from what I can tell.
    • This avoids the testing problems of the other approach, at least for executing transactions, but not for proving transactions. My assumption is that this could be fine as proving a transaction means preparing it for submission to the network. Perhaps it ends up making sense to strip decorators (from both note scripts and account code) when building a ProvenTransaction if some option on the prover is set (which could address Note should not include debug decorators info #1812).

So, maybe we should enforce the output note size limits separately to not make testing harder at the cost of enforcing the limit in a few places. This would be somewhere in:

• ProvenTransactionBuilder::build
• ProvenBatch::new
• In ProvenBlock or BlockBody or OutputNoteBatch.

I'm hoping there's a better solution still, but I don't see it.

[bobbinth]

The more I think about this, the more it seems like this and #1812 are related and should be tackled together. Specifically:

• We don't really care about Note size. We may want to execute notes locally in debug mode, and so note scripts there should have decorators which would blow up the size significantly.
• What we do want to prevent is ProvenTransaction, ProvenBatch, and BlockBody having notes that are too large and notes there should be stripped of decorators (and other debug info). Thankfully, these all represent notes as OutputNote structs.

This makes me think that: we want to enforce note size limits for OutputNote and also, whenever we construct OutputNote::Full variant, we need to make sure that we strip all decorators from the NoteScript of the underlying note. Basically, we don't just want to compute note size, we want to compute note size for a note with all debug info removed.

The only annoying thing here is that OutputNote is an enum - here, we could probably use a newtype (e.g., FullOutputNote) to wrap the Note when it is added to the OutputNote::Full variant. Then, in the constructor of FullOutputNote we could strip the decorators off the note script and enforce the size on the resulting note.

Another way to do this is to rethink the OutputNote enum. The main thing I don't like about it is that it is not really "type-safe":

1. It has Partial variant that is never supposed to end up in ProvenTransaction, ProvenBatch, or BlockBody.
2. The Full variant could contain private notes.

Both of these are adjusted via the OutputNote::shrink() method, but this kind of suggest that were are maybe trying to do too much with the OutputNote and maybe we should have two separate structs for it. For example, maybe OutputNote::shrink() should return some other type and this would be the type that gets stored in ProvenTransaction, ProvenBatch, or BlockBody.

[Forostovec]

Looks good! Thank you! I left a couple of comments inline.

One thing that I'm still trying to think through is at what level do we want to enforce this limit. The approach taken in this PR is to enforce this at OutputNotes level - but there are other options:

• Enforce it at Note level. This would imply that we'd need to make Note::new() fallible - which is annoying. And I'm also not 100% sure this is the right approach.
• Enforce it at OutputNote level. This would probably be ideal because this would also imply that the limit is automatically imposed for OutputNoteBatch as well, but since OutputNote is an enum, I'm not sure how to do this.

Also, I wonder if we should impose a separate limit on NoteScript. And maybe an alternative approach could be to impose limits on individual note components - though, this has its own downsides.

Hi , sorry for the delay. Todo, simplification of noteinputs size hint was done, and fixed failling ci because of duplicate fungible asset

[PhilippGackstatter]

For example, maybe OutputNote::shrink() should return some other type and this would be the type that gets stored in ProvenTransaction, ProvenBatch, or BlockBody.

I like this approach as it is more type safe, achieves the note size enforcement and the removal of decorators.

One small challenge is that we'll want to enforce the constraints from OutputNotes in both ExecutedTransaction and ProvenTransaction, but if we introduce separate types, we'll need to let OutputNotes abstract over them. This could overall look like this:

// Previously OutputNote
pub enum UnprovenOutputNote {
    Full(Note),
    Partial(PartialNote),
    Header(NoteHeader),
}

// New type that is created during proving from `UnprovenOutputNote::shrink` (which may be worth
// renaming at this point)
pub enum ProvenOutputNote {
    Public(PublicOutputNote),
    Header(NoteHeader),
}

// Thin wrapper around `Note` that enforces that the contained Note is public, does not contain
// decorators and has a maximum size.
pub struct PublicOutputNote(Note);

// Used in ExecutedTransaction
pub type UnprovenOutputNotes = OutputNotes<UnprovenOutputNote>;
// Used in ProvenTransaction
pub type ProvenOutputNotes = OutputNotes<ProvenOutputNote>;

// Structurally unchanged; generic N parameter added.
pub struct OutputNotes<N> {
    notes: Vec<N>,
    commitment: Word,
}

// Unless we introduce an OutputNote trait, which seems unnecessary, we'll need to abstract
// over Unproven and Proven output notes like this:
impl<N> OutputNotes<N>
where
    for<'a> NoteHeader: From<&'a N>,
    for<'a> NoteId: From<&'a N>,
{ ... }

I'm not sure about the Unproven/Proven naming. An alternative may be RawOutputNote and OutputNote.

Structurally this should work pretty nicely. During output note "shrinking", any public note needs to be converted into a PublicOutputNote which strips decorators and enforces the max size limit.

This gives us the chance to either:

• enforce an overall note size limit in PublicOutputNote
• or a note script limit, which, together with the other limits, will imply a max note size.

Since we have the ability to enforce a max note size explicitly, this seems slightly better, but not a strong opinion.

[bobbinth]

I really like how this is shaping up. @Forostovec would you be able to take a stab at this new approach?

A few comments:

I'm not sure about the Unproven/Proven naming. An alternative may be RawOutputNote and OutputNote.

Yeah, I don't love any of these (maybe the "raw" approach is a bit better than "proven"/"unproven" approach) - but also don't have a better suggestion yet.

This gives us the chance to either:

• enforce an overall note size limit in PublicOutputNote
• or a note script limit, which, together with the other limits, will imply a max note size.

I'd go with the first option - i.e., enforce the limit at PublicOutputNote creation.

// Unless we introduce an OutputNote trait, which seems unnecessary, we'll need to abstract
// over Unproven and Proven output notes like this:
impl<N> OutputNotes<N>
where
    for<'a> NoteHeader: From<&'a N>,
    for<'a> NoteId: From<&'a N>,
{ ... }

I wonder if we could use the same approach for InputNotes as well (currently, we have to use ToInputNoteCommitments trait because of a similar reason).

[Forostovec]

I really like how this is shaping up. @Forostovec would you be able to take a stab at this new approach?

A few comments:

I'm not sure about the Unproven/Proven naming. An alternative may be RawOutputNote and OutputNote.

Yeah, I don't love any of these (maybe the "raw" approach is a bit better than "proven"/"unproven" approach) - but also don't have a better suggestion yet.

This gives us the chance to either:

• enforce an overall note size limit in PublicOutputNote
• or a note script limit, which, together with the other limits, will imply a max note size.

I'd go with the first option - i.e., enforce the limit at PublicOutputNote creation.

// Unless we introduce an OutputNote trait, which seems unnecessary, we'll need to abstract
// over Unproven and Proven output notes like this:
impl<N> OutputNotes<N>
where
    for<'a> NoteHeader: From<&'a N>,
    for<'a> NoteId: From<&'a N>,
{ ... }

I wonder if we could use the same approach for InputNotes as well (currently, we have to use ToInputNoteCommitments trait because of a similar reason).

Yeah, I'm gonna get into this tomorrow morning as soon as possible (now it's 01:26 on my time sorry)

[Forostovec]

I really like how this is shaping up. @Forostovec would you be able to take a stab at this new approach?

A few comments:

I'm not sure about the Unproven/Proven naming. An alternative may be RawOutputNote and OutputNote.

Yeah, I don't love any of these (maybe the "raw" approach is a bit better than "proven"/"unproven" approach) - but also don't have a better suggestion yet.

This gives us the chance to either:

• enforce an overall note size limit in PublicOutputNote
• or a note script limit, which, together with the other limits, will imply a max note size.

I'd go with the first option - i.e., enforce the limit at PublicOutputNote creation.

// Unless we introduce an OutputNote trait, which seems unnecessary, we'll need to abstract
// over Unproven and Proven output notes like this:
impl<N> OutputNotes<N>
where
    for<'a> NoteHeader: From<&'a N>,
    for<'a> NoteId: From<&'a N>,
{ ... }

I wonder if we could use the same approach for InputNotes as well (currently, we have to use ToInputNoteCommitments trait because of a similar reason).

I hope I didn't miss anything - refactored OutputNote into RawOutputNote / ProvenOutputNote with PublicOutputNote enforcing NOTE_MAX_SIZE at shrink-time, updated tx/batch/block types, and in miden-testing MockChain keep full genesis notes so tests can still create InputNotes.

[Forostovec]

Hi @Forostovec, are you still interested in continuing this PR? I think it only needs a little more work to get it over the finish line.

Hi, sorry for delay, all is done

[PhilippGackstatter]

Looks good to me!

Left a few minor nits, but otherwise I think this is ready. Let's wait for one more review before merging.

The handling of private notes in the mock chain is a bit of a mess, but that's not the fault of this PR. On the contrary, this PR basically revealed it since we now have proper enforcement that private notes cannot be public beyond the proven tx stage. Let's discuss that in #2307.

[PhilippGackstatter]

After this PR, we can do a follow-up PR that changes this to self so we don't need to clone here. In build_proven_transaction, we should be able to destructure let TransactionOutputs { output_notes, .. } to avoid a clone.

[PhilippGackstatter]

Can we combine the test shrink_enforces_size_limit_on_public_notes into this one? The setup looks very similar and I think we can just check that OutputNote::Full(oversized_note).to_proven_output_note() returns an error here.

[Forostovec]

Can we combine the test shrink_enforces_size_limit_on_public_notes into this one? The setup looks very similar and I think we can just check that OutputNote::Full(oversized_note).to_proven_output_note() returns an error here.

Sure, did it

[PhilippGackstatter]

Since starting this PR we've released version 0.13. Could you move this entry to 0.14 now? Thanks!

[Forostovec]

Since starting this PR we've released version 0.13. Could you move this entry to 0.14 now? Thanks!

Ready

[PhilippGackstatter]

For a separate PR, I think the Header variant can be renamed to Private, since this should only ever be constructed from private notes. To disallow construction of a ProvenOutputNote::Header with a NoteHeader whose metadata is public, maybe this should be a PrivateNoteHeader newtype that enforces this, so:

pub enum ProvenOutputNote {
    /// A public note with full details, size-validated.
    Public(PublicOutputNote),
    /// A note header (for private notes or notes without full details).
    Private(PrivateNoteHeader),
}

Next to this, I think OutputNote::Partial and OutputNote::Header should also only ever be constructed with metadata that is private, so I think we should consider enforcing private metadata in PartialNote and also use PrivateNoteHeader in OutputNote::Header. Or in other words, only OutputNote::Full can contain both public and private notes. cc @bobbinth in case I'm saying something wrong.

[bobbinth]

Agreed - this structure would enforce all relevant invariants for both public and private output notes.

[bobbinth]

Generally, this PR looks great - the only thing I'm not sure about is the naming. Specifically, ProvenOutputNote sounds a bit off since the note itself is not proven. What it is is a more "final form" of the output note. I don't have great suggestions here, FinalizedOutputNote is an option, but I'm not sure it is any better.

Another option is to rename the current OutputNote into something like RawOutputNote and then ProvenOutputNote could be renamed into just OutputNote.

[PhilippGackstatter]

Another option is to rename the current OutputNote into something like RawOutputNote and then ProvenOutputNote could be renamed into just OutputNote.

I think that's probably the best option I can think of.

I would suggest merging this PR and do the rename in a small follow-up PR to make reviewing that easier. We could also rename ProvenOutputNote::Header to Private in that PR, and I can open an issue for the remaining things mentioned above.

[bobbinth]

Looks good! Thank you! As mentioned in the comments, I think we should rename some types/variants - but I agree with @PhilippGackstatter that we can do this in a follow up PR. So, I'll merge this PR as is.

@PhilippGackstatter - could you create an issue with the remaining follow-up items?

[bobbinth]

In a follow-up PR, this would switch as:

• OutputNotes -> RawOutputNotes.
• ProvenOutputNotes -> OutputNotes.

This means that we'll need to come up with a new name for the current RawOutputNotes type, though I don't have great suggestions for this yet.

[PhilippGackstatter]

@Forostovec Would you be interested in doing a small follow-up PR that renames OutputNote to RawOutputNote and ProvenOutputNote to OutputNote? We can also rename what is currently ProvenOutputNote::Header to ProvenOutputNote::Private.