Struct Extra 

pub struct Extra(pub(crate) Vec<ExtraField>);

The result of decoding a transaction’s extra field.

Note that the Monero protocol defines a transaction’s extra field as a byte vector. This is a parsed view of such a byte vector, yet the Monero protocol does not require the extra field be parseable. The parsing is also lossy in that Extra::read(&mut buf.as_slice()).serialize() == buf is not guaranteed to hold true.

Tuple Fields

0: Vec<ExtraField>

Implementations

impl Extra

pub fn keys(&self) -> Option<(Vec<Point>, Option<Vec<Point>>)>

The keys within this extra.

This returns all keys specified with PublicKey and the first set of keys specified with PublicKeys. If any are improperly encoded, identity will be yielded in place, intending to cause an ECDH of the identity point, as Monero uses upon improperly-encoded points.

pub fn payment_id(&self) -> Option<PaymentId>

The payment ID embedded within this extra.

pub fn arbitrary_data(&self) -> Vec<Vec<u8>>

The arbitrary data within this extra.

This looks for all instances of ExtraField::Nonce with a marker byte of 0b0111_1111. This is the largest possible value not interpretable as a VarInt, ensuring it’s able to be interpreted as a VarInt without issue, and that it’s the most unlikely value to be used by the Monero wallet protocol itself (which itself has assigned marker bytes incrementally). As Monero itself does not support including arbitrary data with its wallet however, this was first introduced by monero-wallet (under the monero-oxide project) and may be bespoke to the ecosystem of monero-oxide and dependents of it.

The data is stored without any padding or encryption applied. Applications MUST consider this themselves. As Monero does not reserve any space for arbitrary data, the inclusion of any arbitrary data will always be a fingerprint even before considering what the data is. Applications SHOULD include arbitrary data indistinguishable from random, of a popular length (such as padded to the next power of two or the maximum length per chunk) IF arbitrary data is included at all.

For applications where indistinguishability from ‘regular’ Monero transactions is required, steganography should be considered. Steganography is somewhat-frowned upon however due to it bloating the Monero blockchain however and efficient methods are likely specific to individual hard forks. They may also have their own privacy implications, which is why no methods of stegnography are supported outright by monero-wallet.

pub(crate) fn new( key: CompressedPoint, additional: Vec<CompressedPoint>, ) -> Extra

pub(crate) fn push_nonce(&mut self, nonce: Vec<u8>)

pub fn write<W: Write>(&self, w: &mut W) -> Result<()>

Write the Extra.

This will write the value in a sorted fashion.

This is not of deterministic length nor length-prefixed. It should only be written to a buffer which will be delimited.

pub fn serialize(&self) -> Vec<u8>

Serialize the Extra to a Vec<u8>.

This will write the value in a sorted fashion.

pub fn read<R: BufRead>(r: &mut R) -> Result<Extra>

Read an Extra.

This is not of deterministic length nor length-prefixed. It should only be read from a buffer already delimited.

Trait Implementations

impl Clone for Extra

fn clone(&self) -> Extra

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for Extra

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl Eq for Extra

#[doc(hidden)] fn assert_receiver_is_total_eq(&self)

impl PartialEq for Extra

fn eq(&self, other: &Extra) -> bool

Tests for self and other values to be equal, and is used by ==.

fn ne(&self, other: &Rhs) -> bool

Tests for !=. The default implementation is almost always sufficient, and should not be overridden without very good reason.

impl Zeroize for Extra

fn zeroize(&mut self)

Zero out this object from memory using Rust intrinsics which ensure the zeroization operation is not “optimized away” by the compiler.

impl StructuralPartialEq for Extra