14

I've spoken to Robby Dermody from Counterparty about this exact thing. Shoving the data into tx_extra is the trivial part, and in my opinion the best way to handle it would be to encrypt the data with the viewkey. You could reveal the tx key or the viewkey to reveal your asset movement, but it would otherwise stay private. Since transfers of an asset to ...


6

Yes you can do it, but. There are 2 options which you can use at the moment: plain-text 256-bit PID and encrypted 64-bit PID as part of the integrated address scheme. In principle, you could put anything in the tx-extra field but you'd need to customize the wallet software to do this. Plain-text 256-bit PID - You could encode a string of 32 ASCII ...


6

If we could predict all the things tx_extra could be used for then sure, we can do that. But as a thought: what if Monero can no longer hard fork in future due to complexity / politics / etc., and so we decide to stuff a new transaction format into tx_extra? Had we limited tx_extra we'd have a hard time doing that. Ultimately, too, there's no difference ...


6

I wouldn't do that. The tx_extra field opens some possibilities for unforseen inventions build on Monero. Monero doesn't have such rich scripting language as Bitcoin, but the tx_extra field offers some other possibilities how to make use of the anonymous blockchain in other ways than simple monetary transactions. It may for example interlink monero ...


5

I understand the only thing limiting people from inserting, for example, a 180MB FLAC encoded recording of The Sign into the tx-extra field in a Monero transaction is the high fees they pay per kb. That's the 2nd limiting thing, really. First, we'd have to somehow get to a block size median of min. 90MB. The dynamic block size and reward penalty make it ...


4

Two main reasons why this can't happen: The block size can't grow from 60KB to 180MB abruptly, it has to be progressive (a new block can't be larger than twice the median size of the last 100 blocks) The fee for that transaction needs to be more than the block size penalty incurred by miners, which wouldn't be the case for such a large block: miners would ...


4

Padding is for adding freeform data of arbitrary length. It can be used to embed any data, for example a human readable mesage. Pubkey is for the transaction public key (R in the Cryptonote whitepaper). Nonce is for extra data, currently only used for the payment ID. Classic style payment IDs are 256 bits and unencrypted, while integrated address payment ...


3

According to moneromooo-monero, it may be that someone is adding invalid TX extra by using a custom software, on purpose or by error. Therefore when the usual daemon receive the transaction, it is not possible to decode the value. I'm guessing someone hacked the tx_extra code, or is using an entirely new tx_extra generator. These have a pubkey field, but ...


3

Yes, tx-extra can be of any length, as long as the transaction as a whole is not too large to be accepted into a block. Only the parts of tx-extra that need to be encrypted are encrypted. For example, the transaction public key does not need to be encrypted, so that's just directly in tx-extra. But (the newer style) payment ids do need to be encrypted, so ...


3

Things to keep in mind: The field's location within transaction data is defined by the transaction's structure. Currently (protocol v12) the transaction version is v2, and 'extra' lives between 'vout' (outputs) and 'rct_signatures' (ringct data). The field is interpreted as an array of bytes with little endian order (indexed 0, 1, 2). Its content is ...


3

0x01: transaction public key... Incorrect. 0x01 is a public key. Not specifically a transaction public key. The wallets may stuff other public keys in extra, as an example, for multi-sig needs. Open question(s): If e.g. there are two transaction public keys with tag 0x01, how will the core implementation interpret this? Tag 0x01 is not defined as "...


3

A block is not a transaction. Obviously, if you print different things, you will get different results. This should not come as a surprise. A block may contain more than one transaction (in addition to the coinbase transaction). It appears you are comparing the block's coinbase transaction to the transactiou you had the txid for. These things are also ...


2

When using the getblocktemplate RPC, you can pass a reserve_size argument. You will get a block template and a reserve_offset, and then starting at reserve_offset in the block template, you can put reserve_size bytes of whatever you want.


2

From my understanding, the payment ID is not associated with a specific output. It is included in a different portion of the transaction, near the transaction hash and public key. There is no practical reason to use more than one payment ID. Its only purpose is for merchants and exchanges to verify which person sent the funds to them. There is a direct harm ...


2

tx_extra can contain any number of items. The field is documented here: https://cryptonote.org/cns/cns005.txt Therefore it can contain 0..N public keys. Usually there is just one public key in it (the tx public key), but there could be more. So do not rely on there just being one, you have to parse the field and respond accordingly. One such example of a ...


2

This option is available for the in-built miner. Reviewing how it's used: Its expected format is one base64 string per line. When the miner requests a block template to mine, it adds the current index line from the file as the extra_nonce field in the block template - this gets placed in the tx extra field. When the miner finds a block, it increments the ...


2

This is such an example transaction on stagenet where I sent 1 XMR to a subaddress and 2 XMR to a standard address (and the change goes back to myself): https://community.xmr.to/explorer/stagenet/tx/bd82785dc41a608b9796eeca31ba6b4b8d7a9c194691c136e2baf916c66fa98a The tx_extra contains the following information: 01 ...


2

Because miners are free to put whatever they want in there. For example, if you parse the 2nd as ASCII codes, it can be decoded to: 4,QAy^0P<ºÈ±ùGÛg¥g=ÆúòVø9QÇ?MinerGate001!>պ⨪Ëq©ä9{ê¤^KPÀÙ^ñÈýdÇG)ù


1

The extra payload appears to be for merged mining, as per the definitions in src/cryptonote_basic/tx_extra.h: field 0: extra pub key: <c4230d59c83b3042fd82999cfda5be6b77c1673d9442d1f21c7ab9215bdc6c18> field 1: extra nonce: 9841490000000000000000000000000000 field 2: extra merge mining tag: depth 0, merkle root <...


1

Only the old, long-form, unencrypted payment IDs are obsolete. You can still use the short (8 byte) encrypted payment IDs. You create/attach encrypted payment IDs by using the command integrated_address: help integrated_address Command usage: integrated_address [device] [<payment_id> | <address>] Command description: Encode a payment ...


1

Using the example from this question's answer, and following jtgrassie's recommendation to use https://xmrchain.com with "More Details" -> "Show JSON representation of tx", the tx extra field can be found in here. EDIT: better instructions Go to https://xmrchain.com Enter the transaction hash you want to look up, e.g. the example here Go to bottom of page ...


1

Is there an example of a transaction that makes use of tx_extra field? Is this public unencrypted data? Every transaction makes use of tx extra as it places the tx public key in there. The data is public but can be encrypted (e.g. payment IDs are encrypted in extra). ...that is viewable in the monero block explorer? Select a transaction in https://...


1

The wallets only add specific data to tx extra (e.g. tx public key, payment ID etc) and do not offer options to embed arbitrary data. If you need to add your own arbitrary data, such as your example of embedding a Bitcoin address, you will need to manually construct and broadcast the tx. Of course, embedding something like this will make your tx stick out, ...


1

Some good answers so far, but I think the keys here are: Yes, we could cap the size of tx extra, however this would require a fork (pretty common for Monero so not a big deal) Putting a cap is essentially saying "this is spam", but I don't think that's super valid, as other have alluded to. Fees in Monero pay for block space, and so ultimately miners can ...


1

How can I use tx-extra to store something in it? You can store whatever you like in it. For example with simplewallet. You can use simplewallet by setting the data as the payment ID parameter. It's down to the wallet implementation how much data you can set in this field however. Ultimately, any data can be set, of any format and size, in the tx_extra ...


1

No, but there's nothing preventing it - either. We have the TX-extra data field which could be used to embed a return address. For example, you could store an encrypred return address. However, how does the recipient know that those apparently random numbers represent an address? So, there needs to be some convention amongst supporting wallets on the method ...


1

Why would having multiple payment ID's per TX be any better? The simplest answer is because it's intuitive and it works.


Only top voted, non community-wiki answers of a minimum length are eligible