20

Most non coinbase Monero transactions are currently around 2,000 bytes (but with significant variation) which is somewhere in the neighborhood of 8 times larger than most Bitcoin non coinbase transactions. The reason why RingCT should help eliminate the need for extremely large Monero transactions is that RIngCT no longer will require the use of outputs of ...


15

Non coinbase transactions can start at a couple hundred bytes, and can go up in size a lot if they have a large number of inputs. The main factors driving up size is the number of inputs and mixin. When sending a large amount, if the sending wallet only has small inputs, it will have to include a lot of them in the transaction (and possibly even send ...


14

Key offsets are the set of outputs your ring is using as "fake"outputs, as well as yours. Outputs of a given denomination are ordered in blockchain order, and thus can be represented by their index in that list. This is smaller than using the public key. Moreover, they're stored as offsets from the previous one (the first one from 0), as this will result in ...


13

Suppose the sender wants to create a Pedersen Commitment to the amount of 23 XMR for a new output pubkey in a transaction. Without range proof, the sender simply creates the commitment as: C = a G + 23 H where a is a random scalar. With range proof, there's an assumption in the protocol that any committed amount falls within a certain range; let's say ...


11

I know Monero is dynamically scalable, but everyone knows that simply increasing blocksize does not make a blockchain scale. Saying "everybody knows" doesn't really cut it. Who can say what kind of hardware will be available by the time usage of Monero network gets to the point where Bitcoin is today. It's really not possible to answer this honestly without ...


10

Monero's fees are not dependent on price. They are based on the size of the transaction (minimum 0.002 Monero per kB, rounded up). There is some research going on about making the fees dynamic, based on directly observable quantities such as transaction rate, but this isn't anything firm yet. Monero price is inherently foreign from the blockchain, and as ...


10

You have a public and private spend key, and a public and private view key. The public spend and view keys are used to create an output that only you can see that exists, and that only you can spend. You use your private view key and public spend key to detect the existence of that output. You use your private view key and private spend key to spend the ...


9

Monero (and Cryptonote) addresses include a simple (32 bit) checksum, so a simple typo in the address will be detected. The checksum is embedded inside the base 58 layer, after the public keys. If, however, you ended up making a typo which keeps the CRC identical [1], the monero would be essentially lost, since it'd require a brute force search to find the ...


9

In the interest of pedantry (and since I can't comment -_-): You sign the hash of the transaction prefix. In Monero that is everything but the signatures. (at the above answer) Monero relies on ed25519, not EdDSA. EdDSA is a particular signature system (completely absent in Monero). Monero's ring signatures are presently the Fujisaki-Suzuki variety, ...


9

Like hyc already said, dynamic fees currently do not exist yet and currently the minimum fee is hardcoded at 0.002 XMR per kB. There is a lot of discussion on how to address this subject and core-team member ArticMine is looking into it. However, given that there is nothing concrete yet, it is not possible currently to answer your question.


9

The transaction structure is: Transaction version: 1 VarInt Unlock time: 1 VarInt Per Input: 1 byte (type: either coinbase or regular spend) + 1 VarInt (pre-ringct amount) + 1 VarInt (the ring size) + Ring_Size VarInts (input offsets) + 32 bytes (key image) Per Output: 1 VarInt (pre-ringct amount) + 1 byte (type: only regular spend type currently ...


8

The current Monero median block size (last 1,000 blocks) is 286 bytes. The median transaction size is slightly less because some block include multiple transactions. The current median BTC transaction size is 260 bytes. http://moneroblocks.info/stats https://bitcoinfees.21.co/ Monero median (not mean) block sizes are important since they influence the ...


8

Most of the space in a block is transactions. Most of the space in transactions is signatures (especially with RingCT). The wallet doesn't actually verify signatures, the daemon does it (you're running your own daemon, right ?) Signatures are an obvious candidate for eliding when transmitting new data from the daemon to the wallet. Pretty much all of the ...


8

As in my post to MRL Issue #6, I now figured out what pseudoOuts mean. Assuming the outPk means the output commitments, what I'd like to know (assuming the ring signature is valid), would be to see the following hold: sum_j{pseudoOuts[j]} = sum_i{outPk[i]} + fee*H What I'm missing in Luigi's JS code is a way to get fee*H. Edit: Luigi kindly answered my ...


8

The input comes from a non-RingCT transaction. The outputs are RingCT outputs, and are therefore reflected as 0.


7

There is no scripting language in Monero at the moment (the Cryptonote paper describes a simple one, though, if memory serves).


7

You need to pass every output public key, along with every transaction public key. If we assume RingCT (going forward), this is 3 * 32 bytes per transaction (1 transaction public key + 2 output public keys -- currently much more than that due to denominations). This is the bare minimum with the current implementation. You will leak which transactions you're ...


7

The Monero blockchain can be used to send any information, as long as it's part of a transaction. There is a field (tx_extra) where you can effectively put whatever you want in there. It's really a matter of size as the limiting factor. As with the bitcoin blockchain, tx fees need to be paid (based on the size of the transaction). So, yeah, it would work ...


7

All¹ asymmetric signature protocols calculate a hash of the message and then apply the “mathematical” transformation to this hash. This includes EdDSA which Monero relies on. The reason is that all those mathematical transformations work on fixed-size numbers (of about a few hundred bits). Hashing condenses the information into this fixed size, with the ...


7

Yes, it is possible, and while I can't point at it right now, I know there's at least one in the chain.


6

I captured the stream of RPC requests and answers between monero-wallet-cli and monerod (v0.10) with wireshark to see how much data is transferred during a synchronization. It was a synchronization of 658 blocks (blocks 1159032 to 1159659), and the total amount of data exchanged was: 7662 bytes from the wallet to the daemon (get_version, getblocks.bin, ...


6

An arbitrary amount of arbitrary data can be added in a transaction. The extra field contains data with a high level structure. Several fields are predefined, such as public key, or extra nonce. In order to add custom data there, you would need to define another data type, and store it in that extra field. Minergate recently did just this, adding 32 bytes of ...


6

So the transaction splitting function is not an anonymity thing, it's due to the dynamic block size limiter. Right now testnet is on the block median, and you're trying to create a transaction that is much larger than that block limit. So it tries to split the transaction up into several that fit into the block limit, but if it needs to create thousands of ...


6

Monero has a simple transaction format and doesn't suffer from transaction malleability in the same way as Bitcoin does. See here and here for more details on malleability, and here for flexible transactions / SW.


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 ...


5

This question was cross-posted to Reddit and was answered by dEBRUYNE_1 citing luigi1111's article: You may have noticed that this scheme only gives Alice one output for Bob per r, but with auto-denomination Monero and other Cryptonote coins have many outputs per transaction. To get different stealth addresses for each output, Alice (and Bob) append an "...


5

She can do just one TX, unless she wants to specify a different payment ID for each recipient. The CLI wallet supports this, the format is transfer <address> <amount> [<address 2> <amount 2>] ... [<address n> <amount n>] [<payment ID>]. Note how there's only one payment ID. That's because you can specify only one ...


5

It turns out that for version 2, the hash is computed by combining 3 other hashes and then computing the hash of the aggregate. To be specific, the tx hash turns out to be: H(H(prefix) || H(RingCTBase) || H(RingCTPrunable)) Where H is the Keccak256 hashing function, prefix is the Transaction Prefix serialized, RingCTBase is the RingCTBase serialized and ...


5

There is an outPk for each output in a transaction, and therefore you'll need the outPks from the transactions that created each of the inputs. (Where each outPk is C, i.e. the sum of Ci). OutPks are stored after the pseudoOuts and ecdhInfos in every version 2 transaction.


5

These multiplications are trying to address a similar problem discovered in the key image exploit - small order subgroup issues. The derivation_to_scalar issue is easier to describe; it is listed on Daniel Bernstein's page about twist security. If an attacker provides a small order point (i.e. a point whose group has 8 members) in tx_extra for the ...


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