16

The main factor is the number of signatures included in a transaction. With Bitcoin you only have 1 signature per input, whereas with Monero you have N number of signatures (depending on your choice for that transaction) per input. There should be little else that affects the blockchain size as directly as that.


12

The 2x the median block size cap is directed at the blocks themselves not individual transactions. In my example below I will ignore the small coinbase transaction. Assume during a single block interval there are 5 very large transactions each one being approximately .53 of the median block size. Collectively the would total 2.65 times the median block ...


11

There is no easy answer, since both the block size limit and the transaction sizes are variable. currently, the block size limit sits at its low limit, which is 60 kB. A transaction size can range from a few hundred bytes to more than 60 kB. With those numbers, you could fit 1 to 100 transactions. With a typical transaction size of 2 kB, you can have 30 in ...


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


9

Privacy: Outputs are where amounts of Monero are stored on the blockchain. When you spend one of your outputs in a transaction, it cannot be known which of 7 different source outputs you're really spending. Therefore your anonymity set grows by 40%. Another advantage is that outputs that you receive will now more likely be used as decoys in other people's ...


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


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

According to Monero Blocks statistics the highest pre RingCT ringsize was 850. I was not able to immediately locate that transaction on the blockchain. I was able to find a sample 150 mixin transaction from block 1,067,631 with a size of 70,219 bytes and a transaction fee of 0.69 XMR. The above pre RingCT ring size and transaction size records were prior ...


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

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


6

I have this, which may be wrong as I've not tested it a whole lot. The constants at start are "close enough", I did not try to be 100% precise: 47 + inputs * (39+(mixin+1)*2) + outputs*38 + 64 * inputs * (mixin+1) If you want to know whether a fee is acceptable before it is actually sent, you can use set always-confirm-transfers 1 in simplewallet, and you'...


5

The database file is something like 2.5 or 3 times larger than the actual blockchain data. There are a variety of reasons for it: preallocation of space in the file (if your filesystem supports sparse files, this doesn't actually take physical space, otherwise it does), denormalization for performance reasons, internal tables for the database engine's usage. ...


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

If you were a bank, then I agree with you - clearing all transactions as fast as possible makes the most sense for your customers. After all, you would control all the account information, have plenty of computing power, and would enjoy all the transaction fees that go with them. We don't want centralization, we want as many people as possible to run a full ...


4

There is no particular limit. If you send to many addresses, then you will get split transactions (assuming you use transfer_split in RPC, this is the default with the command line wallet), since this increases the number of outputs. Large pools probably have a number of txes with a lot of destinations (and even more so before the payout threshold was ...


4

What happens if a transaction containing an extremely large numbers of outputs and a very large mixin exceeds the current dynamic blocksize limit? If simplewallet is creating this tranasction (or any other wallet software using proper protocols), the transaction would be broken into multiple transactions that would be more compatible with the current ...


3

I don't have data to analyze this. However, I guess average transaction amount might have relationship to monero market price, because people will spend fewer if xmr is expensive, spend more if xmr is cheap. For example, in Bitcoin beginning stage, you might spend 500 BTC to buy a pizza, but now? While considering transaction size, maybe we can also ...


3

It could be argued that there's no need to re-adjust M_0 again as just reducing typical TX size would give us more margin and would further reduce the effect of TX size / block size ratio. However, do-not-relay fee could be adjusted at any time to keep the price/fiat at some reasonable level and deter irrational network use. The more TX-es can fit in a ...


2

What is the correct maximum transaction size in protocol v12? Quoting the source of get_transaction_weight_limit in tx_pool.cpp: // from v8, limit a tx to 50% of the minimum block weight if (version >= 8) return get_min_block_weight(version) / 2 - CRYPTONOTE_COINBASE_BLOB_RESERVED_SIZE; Which is used when adding a tx to the pool in ...


2

Update for v. 0.12 and newer: It is now better for recipient to use subaddresses instead of paymentIDs - see here why: https://monero.stackexchange.com/a/7907/859 Subaddress allows recipinent to generate one address for each sender, so they don't have to share one address with more people. This increases their privacy and also has added benefit, that on ...


2

But I fail to see how a miner, who just "packs" transactions in a block, can control the size of the blocks he or she mines. Exactly like that. You pack until you get to the target size. Then, you simply don't pack the rest of the queue and leave it for the next block. Or you swap low fee tx-es with ones with higher fee, still keeping the size below the ...


2

Since the penalty function is inherited from CryptoNote, we must look at the whitepaper for the "original thought" on the subject. A miner still has the ability to stuff a block full of his own zero-fee transactions up to its maximum size 2 * M_b. Even though only the majority of miners can shift the median value, there is still a possibility to bloat the ...


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


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