Podcast #128: We chat with Kent C Dodds about why he loves React and discuss what life was like in the dark days before Git. Listen now.
26

The first question one needs to ask before even considering adaptive blocksize limits is: Can a fee market actually work in the absence of a base emission? We first consider a blocksize large enough (or effectively infinite). In this scenario competition among miners will drive fees towards zero since there is no scarcity. This will in turn ...


17

You can select a higher fee if you want. This choice is intentionally limited to a 1x, 2x, and 3x multiplier to avoid leaking too much information via the fee (ie, if you're the only one using a 2.7x fee, your transactions will stick out). NOTE: from two weeks after the v3 fork, the fees multipliers will change from 1/2/3 to 1/20/166. The simplewallet ...


16

According to the pull request from moneromooo-monero on behalf of ArticMine: The dynamic fee is based on the block size in a past window, and the current block reward. It is expressed by kB. This function calculates an estimate for a dynamic fee which will be valid for the next grace_blocks According to dEBRUYNE_1 this change will take effect with v4 in ...


15

@Jollymort will probably answer this better but the current dynamic size algorithm didn't work well with RingCT transactions. It worked well with non RingCT transactions, which were smaller. Once a miner has put enough transactions in a block to reach the median size of the last 100 blocks she faces this decision: add one more transaction, which, in case ...


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

When a block is built a block larger than the median size of the last 100, then a quadratic penalty is imposed on the miner such that: penalty = base subsidy * ((block size / median size of last 100 blocks) - 1)² subsidy = base subsidy - penalty Miners can avoid this fee altogether by refusing to include transactions in blocks that would lead to ...


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


9

TL;DR Actually, with the current minimum fee, there's an incentive for 0.6% growth as long as there's enough transactions coming in. Problem is not in the formulas themselves, but in the typical transaction size / min. block size ratio. The penalty formula has an optimum block size increase for a set of transactions offering any given fee, see figure below. ...


9

There is a block size limitation. The maximum block size is variable, and a function of the size of the previous blocks. More precisely, the maximum block size at a given height is the maximum of (1) 60000 bytes and (2) twice the median size of the last 100 blocks. The intent is that, as transaction traffic increases, blocks fill up. When enough do, the ...


8

Right now, it's basically a 1:1 relationship in the long term for a very basic reason. According to moneroblocks.info, there have been roughly 8100 transactions in the past week. Since there are 10080 minutes in a week, that means there have been approximately 8 transactions every 10 minutes. I'm going to go out on a limb and say this have been a higher-...


8

Fees are rounded to 0.01 XMR per KB. Because of the way outputs are selected, calculating the size of a transaction in advance (and choosing your own fee) would be very difficult and time consuming. The transaction fee priority issue is not really important to Monero because its dynamic blocksizes will grow to meet demand. The need to pay a higher fee than ...


8

This limit is based on the median of the last 100 blocks' size, after removing outliers, with a 60 kB lower limit (so blocks can't get TOO small, or you could have a hard time "restarting"). This allows the block size to grow and contract based on transaction volume. The size at which the block reward penalty kicks in is between 100% and 200% of the block ...


8

In addition to the excellent summary by ArticMine already given, here below is shortened & updated version of my research on the topic. Dynamic Blocksize Penalty This is the penalty which will be subtracted from the block reward. In practice it means that whenever a penalty is triggered, the start of tail emission will be slightly postponed (it will ...


7

By definition pruning branches cannot be considered full nodes because they are missing the data that has been pruned. Pruning branches are not full nodes according to the definition of CONOP. This explanation explains why full nodes (in addition to pruning branches) are necessary. Pruning data makes a node unable to supply the pruned data to other ...


6

What if there was no gold to mine? The fact that it might be more efficient or beneficial to mine rather than buy from a collector adds needed complexity to market decisions. Beanie Babies were limited, and nobody gives a shit about them and I doubt even if they were infinitely divisible it would make a difference. Why not limit bitcoin to 10? why not 10 ...


6

The 60 kB limit is the minimum median block size limit. Thus, miners are able to construct blocks up to 60 kB without incurring a penalty. This limit was increased from 20 kB in the March 23, 2016 hardfork and was first proposed by smooth. From the proposal: The minimum median block size is current 20 KB, meaning without the dynamic block size kicking in, ...


6

Maybe it would. In theory, to smoothly function as "originally intended" would mean the median block size would somehow have to grow to the point where one TX is 1.2% of the median, which translates to a block size of roughly 1250kB (15kB being a safe size to fit a "typical" transactions). The magnitude would then be around 2500TX/hour or 0.7TX/s. It's a ...


6

Unlike Monero which has many developers, Vcash arguably has a bus factor of 1. After recently being doxxed, its developer is alleged to have made harmful changes to the code before abandoning the project: Zero day flaw that allows miners to opt-out of paying incentive rewards to nodes The operator of the suprnova mining pool had this to say: I've ...


6

I am pretty sure that the network could not handle a million daily transactions (how many does it handle now?) In the last day, Monero processed an average of 2.22 transactions per block excluding coinbase transactions. This comes to about 2.22(30)(24)= 1598.4 transactions per day. As demonstrated by the August 2014 spam attack, Monero blocksize limits ...


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


5

Based on current transaction volume (and a small reorg) there does not appear to be a need for a 7 day period for such transaction (because they can be confirmed much faster. However if transaction volumes suddenly much higher (before the dynamic block size limit can fully adjust) and if the reorg was substantial (very large pools of transactions being ...


5

Consensus rules don't disallow it, so a lower fee than priority 1 would be a valid TX in a block. If you're a miner, you're free to mine 0-fee TX-es. On the other hand, as a non-miner, getting into a block is another story because anything lower than minimum fee won't get relayed through the network so no miner will ever see your TX for it to have a chance ...


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


4

The largest size of the next block is limited to 2x the median size of last 100 blocks. Creating a block this large imposes a penalty equal to the block subsidy, so the miners entire revenue would have to come from transactions, thus the transaction fees would have to be at least as large as the block reward to entice the miner. Realistically, a miner ...


4

With sufficient demand, one would end up with a boundless block size, and a minuscule block reward, a tragedy of the commons. What am I missing? I would argue you are missing physics. At some point, the physical limits of the network bound the blocksize. I.e., if a miner decides to keep pushing the blocksize higher, eventually a blocksize will be reached ...


4

Because it's not economic for the pool or miner. There's also a "hard" cap (which goes up with median) at 2x the median. If a miner mines a too big of a block, he loses some base block reward (emission) and for it to be economic to him, the fees must be high enough to compensate and earn a little more. Each wallet fee level corresponds to a % increase ...


3

Does any sufficiently detailed specification of ChainBendover even exist? (this is an answer, not a question) ChainBlender was afaik never sufficiently documented to even determine whether it could possibly work and so as to be able to determine what the code is supposed to be doing.


3

The blocksize can automatically adjust over the course of time by the miners including more or less transactions than what has recently been the norm however they have to pay a penalty fee if they increase it by more than a certain distance from the median of recent blocks. I guess the idea is to let the market decide what the blocksize should be rather than ...


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