12

You can put potentially any data into tx_extra and it will be stored on the blockchain with your transaction, only accessible with your keys. This however, will bloat your transaction size and your transaction will be more expensive as you have to pay per kb. For now, beside the elastic blocksize limit (median of last 100 blocks * 2) there is no maximum how ...


8

Since StackExchange prefers content to be on the site rather than through links, I've transcribed and annotated the information from luigi1111 on PasteBin to make it more accessible for readers. Stealth Short Payment IDs This is a proposal for shortening both "user" and "blockchain" payment IDs from 256 bit (32 bytes) to 64 bit (8 bytes), incorporating a ...


5

The basics are already here: encrypted payment IDs are private information encrypted by the sender, which only the recipient can decrypt. If the sender and the recipient are the same party, you can store data that only yourself is able to recover. A similar system could be used to enable "chat like" behavior. Transactions would have to be marked as non-...


5

Monero/Aeon developer smooth, quoted below explains the encrypted messaging system he is currently researching: There are many ways one could implement messaging, but I don't favor storing p2p messages on the blockchain itself. Encrypted is even worse, in a way, since that can't possibly be of any benefit to anyone other than the specific recipient. (At ...


2

It is theoretically possible (that is what the short payment ids are), but I don't think there's any existing command for this at the moment.


2

Credit to @JollyMort the python base64 module can encode/decode the unsigned_tx file into ascii for transmission via QR code: import base64 ... ... with open(args.infile, "rb") as source: with open(bitPath, 'wb') as dest: dest.write(base64.b64encode(source.read())) <transmit sliced up bitpath file via qr codes as is now ASCII> <on ...


2

There is a function in BlockchainDB which iterates through all transactions: for_all_transactions. Call this with a function which extracts the payment id (see find_tx_extra_field_by_type and get_payment_id_from_tx_extra_nonce), and scan its bytes for suitability (isprint).


1

Current software supports embedding arbitrary 256-bits or 64-bits into a TX. The 256-bit "payment ID" will be unencrypted on the blockchain (unless you encrypt before submitting). The 64-bit "payment ID" will be encrypted with the "shared secret" before bein written into the TX. This can easily be decoded by the recipient as it uses a scheme similar to how ...


1

Well, a transaction id is already a 32 byte field that you can put whatever you want in there. Payment id is actually in a part of the transaction field called "tx extra", which I believe supports arbitrary length data (as long as the tx for in a block, I guess). However, the default client does not support putting arbitrary strings on that field, and I ...


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