I've had my eye on the blockchain explorer quite frequently for a while now, and I've noticed something weird. No matter what the price of tickets are, every 10 +/- a few blocks (or so), there are 20 tickets sold (fresh stake) and then 10+ sold the very next block. It appears to have started in block # 11256 (about two weeks ago) and has continued ever since. This process repeats as far back as I have looked, and I can't help but wonder - what is causing this? While it's impossible to determine if this is a single wallet creating the transactions, what are the odds that blocks will pass with very few new ticket purchases, then be maxed out with 20 new tickets followed by 10? This pattern has repeated indefinitely since 3/17 and the extreme ticket prices has not affected it yet. Could this be some sort of automatic network "stimulus" to control the rate of change of ticket prices? What do you guys think?
Another interesting thing is those ticket purchases have a fee of 0.003876 DCR which is well below anything that I can get accepted.
After following the some of the transactions back, they appear to be coming from one of the original Decred addresses found in the premine config. Davecgh said in The Project's Commitment thread: I'm looking for the original statement as I'm curious about the details and extent of c0's stake mining.
This isn't the original statement, but I did break down the extent of the staking based upon the information here: https://forum.decred.org/threads/dd-3-v0-0-7-03-09-16.1274/page-2#post-14099
As far as the pattern, it's probably helpful to keep in mind that the ticket price adjustment formula is a weighted average that considers the entire window of blocks in the adjustment interval. That is to say it considers the total number of tickets purchased (Fresh Stake) in all of the blocks in the interval in the calculations, so it doesn't matter how those tickets are dispersed among the blocks. For example, if the first 50 blocks are filled with 20 each and all the rest have 0, that's a total of 1000 new tickets. If 42 of the blocks had 7 tickets each with 3 in the last two, the total would also be 1000 new tickets. The same is true if there were 20 in every other block for the last 100 blocks. The important part is that there were 1000 new tickets during the period. That value is then weighted more heavily (since it is more recent) and combined with weighted values of the previous periods and used in the price retarget algorithm. In other words, splitting ticket purchases up across the blocks like that has no effect at all on the rate of change versus purchasing the same number of tickets in bulk. Splitting them across the entire interval does however have the benefit of putting less outstanding ticket purchases into the mempool which results in less peak memory usage. For example, let's say you're going to purchase hundreds of tickets. Rather than putting them all into the memory pool at once which means they will be sitting there for at least (totalnum / 20) blocks, if you only purchase 20 or 30 every few blocks, the total number of tickets purchased is the same without requiring the transactions to use as much memory.
Interesting finding @David. I think it shouldn't be a surprise that the devs are stake mining, this is only logical. What made me wonder is the extent to which this is happening, and if there are guarantees or safeguards in place that keep stake mining open and profitable for small bag holders.
I'm not 100% sure, but I think I read somewhere that dev's commitment not to sell their premine at least for one year, include also PoS mining.
I in my experience you can get 0.003876 accepted, but only if you are using only one input. If you have 2+ inputs, the fee won't meet the threshold for minimum price / kB. Notice that https://mainnet.decred.org/tx/2ab082cc044575abcad628d3fbf3b108678192f3260926692cc770f39ca0e649 has 0.0131 DCR/kB, which is above the minimum price (0.01 DCR/kB). It only uses 1 input, and it has no change address, making it only 296 (bytes). A transaction like https://mainnet.decred.org/tx/461e155d574f7d67073c0a996119e7a7aba0de361a1cd39eac519c82743cfd0e has 5 inputs, and so is 1519 (bytes) in size. This required a fee of 0.22DCR, or 0.0145 DCR per kB. Now, for normal transactions the miner ordering transactions by fee / kB makes sense, since the block size is limited. For a cap of 20 new stakes, miners should really be weighing up the higher free / stake vs fee / kB to choose the most profitable tickets for themselves. If there aren't enough normal transactions to fill the block, then fee / kB isn't as important and they should really use fee / ticket instead.
The announcement is here. @Kandiru: I would have to check to be 100% certain, but I'm pretty sure that there hasn't been a period yet where every single block had 20 new ticket purchases in the entire period (aka 2880 new tickets in the period). IIRC, there was one that came close (something like 100+ blocks) when the price dipped to ~8.75, but so long as every spot is not filled, all ticket purchases that meet that bare minimum fee requirements will eventually make it in. That said, relying on that does run the risk of all of the remaining ticket spots being bought out with higher fees thereby making those lower fee transactions miss the price window. The expectation is this fact will eventually cause a fee market for tickets.
@davecgh I was thinking more from the point of view of the miner, who might be missing out on subsidy by putting the lower fee, but higher fee per DCR ticket in their block, rather than the higher fee but lower fee per DCR SStx. When mempool is full, miners don't seem to be incorporating the SStx based on strict fee ordering.