In related news:
Specific comments about that CHIP please within its own thread…
2 Likes
Not a dev, but what if instead of using quartiles, we use standard deviations? The minimum relay fee will be 2 or 3 standard deviations below the mean. This default could be adjusted, and we can have this adjusted in a “rolling” fashion, meaning that it is calculated per block, using the data of the last 36/72/144/etc blocks.
Quartiles, standard deviations - it doesn’t really change much.
The end effect will be the same.
Somebody with more mathematical background should chime in and tell us which one is better.
Yes, of course this logically can/should be done only in a rolling fashion, this is what I meant.
1 Like
I agree, but standard deviations make more sense intuitively. I think it’s better at pointing out outliers than using quartiles, but that’s just my opinion. I definitely will look into fee rate distributions though, and gather what I can find. I think johoe’s website is best for this. Heck, I might use blockchair.
With the talks about decreasing the minimal relay fee, I think it’s important that one particular “usage” of blockchains must be raised.
Data storage.
If we go lower than 1000 sats/kB, a very important spam/attack vector opens up, that being an increased usage of data storage on Bitcoin Cash. Currently, on Bitcoin SV there’s a culture of casually storing everything on it, such as pictures you put in a twetch, or just general files using bitcoinfiles.org
Currently, most services/users on BSV pay 500 sats/kB.
If min relay fee gets lowered down to 100 sats/kB, it will be cheaper to store on BCH than on BSV. With the unbounded tx chains now live, the Bitcoin Files protocol (that is part of SLP spec.) could be updated to support them, meaning that the limit will be only how much a person is willing to pay. As the min relay fee gets lowered, that limit increases OR those who were outpriced before, will be able to store files now.
I think it’s important this gets recognised as a point against a such rapid and steep decrease, as it can greatly hurt the Bitcoin Cash network.
6 Likes
I agree that this could be a risk, and is definitely a reason to be very careful about decreasing fees without proper consideration or, in fact without a corresponding price increase of BCH.
4 Likes
If we go lower than 1000 sats/kB, a very important spam/attack vector opens up, that being an increased usage of data storage on Bitcoin Cash. Currently, on Bitcoin SV there’s a culture of casually storing everything on it, such as pictures you put in a twetch, or just general files using bitcoinfiles.org
Currently, most services/users on BSV pay 500 sats/kB.
What if we were to make the user experience better by allowing minimum relay fees based on the number of coindays destroyed? For example, if a user’s transaction destroys 1 coinday, then the minimum fee can be 100 sats/KB, and if they have 10 coindays destroyed, their transaction can be completely free? Obviously, these aren’t actual figures, but it both combats spam, while also making BCH much cheaper.
It isn’t about “spam” per se, it’s rather more about the data transfered. High rate of tx/s =/= high amount of data.
You can technically do 1.5 kB per tx in terms of meaningful data storage using P2SH.
You don’t need a lot of fresh utxos to do store high amounts of data using that.
Coindays Destroyed only protects against constant re-use of UTXOs that have a small value.
I follow your line of thought and wrote a bit more about that here;
1 Like
That creates external dependencies. What if we could learn some useful information directly from our blockchain? Turns out - we can, each block is a price point for hashes/sats, derived from difficulty/coinbase. Our DAA really works like an automated-market-maker (AMM): network bids for hashes, miners sell the hashes, each block is a trade and gives us a price point for this exchange. If we plug in an ASIC-efficiency curve, then we get a price feed that loosely tracks something like MWh/BCH. More on that here: Research: Block difficulty as a price oracle
So, what if we set the fee to, say, 10Wh/TX (for a 200-byte TX)? You get this:
Notice how it would stay in 0.001-0.005 USD/TX range. Free float could be bad UX for wallets and contracts with hard-coded assumptions. What if we made it monotonic, so it can only go down sat-wise? I applied some EWMA smoothing and then “stick” to historical min. sat-wise:
This happens to near-perfectly settle on our current 1sat/byte. It would further reduce if price hits new highs, and it means we get even cheaper fees (<0.001 USD-wise) during bear markets.
3 Likes
On revival of this old topic I want to update it with some thoughts;
first, the default relay fee is indeed a long term real problem. Should the price of BCH go up a lot, we can see 1 dollar fees or more. And the fees can’t be lowered by miners because the nodes in the middle simply block all reasonably paying transactions.
So I’m in full agreement that they should be very significantly lowered at one point.
The main reason it was introduced was always explained as a spam protection, and that was a sane protection since we’ve seen a lot of bad stuff being thrown at our coin over the years. But mostly this attack has not happened. It would not be too expensive to mine a bunch of 32MB blocks full with your own transactions, but no miner ever did. No group ever did such an attack of lots of big blocks. Thank $DEITY.
That does not mean we should drop the relay fee directly and completely, just making the case that our behavior should be based on long term goals and not just simply continuing the road of min-fee we started out of (realistic!) fear.
So to me the goal of mining and minimum fee is that we avoid the debate and we avoid the always problematic design by committee that comes with any sort of central pricing design. The goal instead is to make the prices be set by miners by them simply not mining when they don’t get paid enough. Which may mean they only include high fee paying transactions, or if there are not enough fee paying transactions they may simply decide to not mine Bitcoin Cash. This last part is a reality today. Miners are known to only mine if the electricity in their area is low price. Rainy season for water-power generated electricity as a good example. Winter in areas where the cold allows them to not pay so much for cooling systems, as a second example.
It is a well understood idea because it aligns with the free market. Miners choose to mine when they get paid enough to make the work worth it. And this will shift towards fees over the next decade(s) while the block reward diminishes. Miners will set the price. An idea that works in all industries in free economic systems. They will simply demand a certain income before they do the work. Too low pay, no blocks being mined. Or if we get the tools to do something more fine grained; your low fee paying transaction is ignored in the blocks that are being mined. So pay a reasonable fee and help that miner earn a living.
The free market solves the price setting without any need for an algorithm. Open any economics book, especially from Austrian economics authors, and this is explained repeatedly.
In short, I think we do need action on the minimum relay fee. It needs to be actions with the goal that moves the long term setting of the fee by the market. Supply and demand. Where the ones doing the mining actively eat the supply of transactions that need double spend protection. A free market does not work when some central property distorts it by setting a minimum fee that needs to be charged by miners. So the goal of having a free market of fees means that BCHN needs to severely lower or even remove the relay fee over the next 10 years.
Users, or the “buyers” of block space, have a number of things of value that can’t be spoofed.
Users have cash. This is the default method of payment. We’re solidly in a simple cash phase where everyone just pays 1 sat/byte because coins are cheap.
Users also have coin days. I’m not exactly sure how it was implemented, but the legend of the old days is that users burning sufficient coindays were exempt from paying fees.
Users also, generally, have access to some kind of low grade horribly inefficient hashing mechanism. Users could grind for a low transaction hash to prove they weren’t simply spamming the network at no cost, but the efficiency disparity between an ASIC and a CPU would make it easily abused by miners, and useless to broke users on budget hardware. The user experience would be horrific.
However, miners, or specialist MEV harvesting outfits could write software to grind for a low hash to save a few sats. Offering a network discount for hashrate wouldn’t really work in practice however, because the miner with the winning block nonce can choose to replace an MEV transaction with a low fee for their benefit.
So, ignoring hashing, we want a minimum cost equation like:
(cash + coin_days_destroyed * k) * difficulty_price >= C
To solve for k, the constant normalizing coindays to sats, it’s worth noting that offering a network discount to holders is essentially offering a yield.
Given what I’ve seen on our various yield protocols, it might be interesting to look at a k of 1 sats per coin block or 144 sats per coinday. That works out to a yield of 0.05% APY. It would allow a person with 1 coin to make a simple transaction 125 times a year for free 99.
EDITED to cut k in half.
Boiled down, you list 3 unforgeable proofs the users may offer:
- Cash (sats): proof of fee payment, the default, what we use now
- Coindays: proof of holding
- Hashing (grinding low TX hashes): proof of work at the user level
and claim all of these have value and could therefore be used as “payment” for fees. I disagree. Cash is king, and only cash contributes to common security, because only the fee adds to blockchain’s chainwork state, which underwrites the immutability property. Now let me dismantle both coindays and hashing 
What do users “have” in coindays? Why should coindays be worth something to anyone?
I never understood the obsession with coindays as if they imbue coins with some magical extra value. A coin having high coindays means the owner held on to it for a long time, that’s it. Doing nothing is all it takes to accrue them. How much is doing nothing worth? Why should “we” (the network as a whole) give someone credit for that?
If anything, maybe we should charge them. They were away from the network while “we” kept their coin safe, at a non-zero cost to “us.” Gold vaults don’t pay interest on long-held deposits. They charge fees, because maintaining a vault has costs. The presence of a long-held UTXO in the state imposes a small ongoing cost on every other user’s transaction processing. The least someone can do when finally moving their coin is pay the fee like everyone else, rather than expect a discount.
To this you may retort that gold coins have greater numismatic value as time goes on. But it is not comparable, because our UTXOs are indistinguishable (no TXID:vout has special value), and whatever coindays a coin accrued will be lost on transfer. It can’t be a payment when nobody receives it, it is destruction, all the metrics pages correctly call it coindays-destroyed. Compare to gold coins, where the coin’s history gets transferred together with the coin.
Users, or the “buyers” of block space
Are users really “buyers of block space,” or are they buyers of hashes?
Fees pay for hashes, nothing more, nothing less. When you go to a bazaar, you bring cash and leave with goods. Did you have to buy your slot for the trade first? No. The bazaar is maintained by volunteers who also happen to have stands where they sell goods, so helping maintain it serves their interest.
Users pay a fee, but it’s not for space, it’s for enforcing the common security policy of the bazaar: no returns. Only the security enforcers (hashers) get paid. The minimum relay fee isn’t the bazaar demanding payment for space: it’s congestion control. We don’t let you browse around only to buy nothing. Without block subsidy, our security will depend on this one-for-all-and-all-for-one pact. Each user’s transaction fee will contribute to security of not just his own TX, but everyone else’s TXs. Of course “we” want to allow as much contributions to this commons as we can handle, and in case of congestion favor higher contributions over lower.
There are 2 aspects of fee here:
- Contributing to common security
- Congestion control
Coindays and user-PoW may be useful only for #2, as they contribute 0 to common security but are still fundamentally unforgeable by spammers. But if we already have the fee for #1, why introduce a second mechanism for #2? The fee already handles congestion, a spammer must burn real resources either way. Adding coinday discounts just complicates the equation without buying us anything.
You already discarded this idea yourself by saying spammers could abuse the network due to access to better hardware, but that’s not the only issue. The fundamental issue is that this user PoW doesn’t contribute to common security, no amount of user-PoW in a block would increase difficulty of a reorg. It’s just proof-of-sacrifice, the user did something at a cost to himself and 0 value to us, and would make such offering to “us” to make an exception and let him do his business on the bazaar without paying for common security. But why would anyone need to make this sacrifice when they already have coins they can use for fees? Without coins, how would they do any business on the bazaar?
Miner’s PoW actually buys “us” something: the immutability property. It’s not just a sacrifice (or “waste”), each hash purchased adds to the network’s chainwork. User’s PoW buys us nothing. But users can also buy us immutability: by buying their PoW directly from miners. That’s the brilliance of Bitcoin’s design. Each satoshi paid as fee is actually a user-bought-PoW (at the current exchange rate given by difficulty/coinbase). Cash is king.
1 Like
We agree that letting users hash to meet the relay minimum is silly. We don’t have to waste further time on that. It would destroy the low-end experience and add no security or cost savings.
But on a coindays discount…
Time is a finite resource, a valuable resource, and something easily measured by our timestamp service. It’s not really an emotional obsession, it’s just a matter of finance that money and time are closely related. Contracts and instruments are almost always concerned with rates in time rather than totals.
The question is whether miners should offer holders a slight discount on the purchase of hashes, I think it would actually be in the best interest of miners on a total cash basis to have the discount.
Consider two credit unions. One offers NO interest on savings accounts, the other offers a 0.05% APY―nothing really, but not nothing. It would be 50 cents on every thousand dollars held.
A credit union is made of it’s members, it’s shareholders. The policy and purpose is determined by the folks who keep their money there.
The more valuable credit union would be the one paying 50 cents a year for every grand on deposit, because that credit union would have smarter members. And people generally like if they can get X number of transactions a year for “free”.
If any non-zero return is going to break the bank, the bank is already done. It will be crushed by competitors that have levers.
From a monetary policy perspective, of whether or not we should allow these free loading savers to get cash discounts for their coindays, the policy is already settled squarely in the affirmative.
We DO allow any user to convert coindays accumulated into tokens, and those tokens into cash, and to do all that instantly at the same time Alice is paying Bob.
And anyone who thinks our stablecoin with yield will be more valuable than a stablecoin without can choose to accept or deal in the coinday commodity tokens to help the value of the base asset.
The question now is just about how clean or efficient that process is on chain.
Does Alice have to claim rewards and sell tokens on a dex to pay Bob without paying a fee, OR can the miners (and the maintainers of the network) see the value in baking in a 50 cent annual allowance to pay Alice’s initial fees?
2 Likes
Credit unions pay yield from lending revenue. Where does the coinday “yield” come from? It’s a discount, meaning other users or miners subsidize it. Who pays for Alice’s free transactions security? Everyone else paying full fees. You correctly call it “discount”, just thought to highlight this.
On second thought I’m not really against carving out a discount for coindays-destroyed. It can’t really hurt us because coindays-destroyed are a scarce “resource”. Even if everyone wakes up one day and uses the option at the same time, I wonder how many TXs that could be. Spending all the high-coindays UTXOs in the same day, what happens? Maybe some mempool backlog, but fee-paying TXs would have priority so no problem, miners would slot in these only if there’s room after the last min. fee TX.
This sounds good, actually. Some thought should be given to min. dust limit, and IMO we should NOT discount min. dust limit for new outputs but we should allow spending old outputs below dust. This way, smaller dust could be cleaned up for 0-fee once it ages enough, and contribute to creating fresh UTXOs with enough sats in them that they can carry their own weight.
Now, on the role of miners.
It’s not the miners who are offering any discounts, they don’t hash each transaction individually; they hash whole block headers which commit to whole bundle of transactions. The DAA fixes the amount of hashes they get to “sell” at the current height, and without subsidy it will be just the state of mempool that determines how much they can get for it, take it or leave it. Every TX that pays a non-0 fee will increase the price of hashes. They can take what is offered (current state of mempool, fill the block with whatever is available) or leave it. Leaving it will drive the price down by reducing difficulty, until price becomes acceptable to them. But we have to stop thinking of “them” as a homogeneous collective. Some have ASICs with 80% margin, some have ASICs with 20% margin. If fee offering is too low, the 20% ones may refuse to mine, but 80% will continue and still be profitable - and it will drive the price down until some equilibrium. This ties in well with what @tom was talking about:
With current DAA, this would be problematic in some edge cases (ALL miners starting/stopping) - because someone has to mine the next block to feed in the fresh information into DAA. You need those high-margin miners to still mine when it becomes less attractive to mine, because our DAA won’t reduce difficulty in real-time. Network could indefinitely hang if mempool is starved of fees, and difficulty for the next block would remain the same until someone finally mines a block to update the DAA.
I like the idea of real-time difficulty targeting. The target for the block yet-to-be-mined could be reduced in real-time as time since last block elapses. But to make it work I think we’d have to tick the other things off this list with it: https://github.com/zawy12/difficulty-algorithms/issues/30
On third thought, maybe discount should be for days-destroyed rather than coindays-destroyed. Why?
If you use the formula (cash + coin_days_destroyed * k) * difficulty_price >= C then which k would you pick? No k is good. Set too high it becomes useless for congestion control. Set low enough for congestion control then it becomes useless to anyone holding a “normal” amount. See below table (time it takes to fully discount a 200-byte TX, highlighted in green means free transaction when aged just for 1 block’s worth of time).
With k=0.001 you’d have to age sub-dust amounts for a long time, but someone holding 1.34 BCH could send the balance to himself for free every block. Reduce it further, then people holding a “normal” balance would have to wait years for a meaningful discount but big holders could conduct all of their business for free.
If instead we remove the value from the equation:
(cash + days_destroyed * k) * difficulty_price >= C
then it becomes useful as congestion control and to help consolidate any sub-dust UTXOs. This shifts the discount from “reward for holding large amounts” to “reward for not churning UTXOs”, which aligns better with the network’s interests.
How do we pick a good k? Should the discount apply “outside” the input, or should it be capped to discount just that input’s bytes? I’m leaning towards capping the discount to input’s bytes. It prevents a single aged input from subsidizing a large transaction with many fresh outputs. The aged input “earned” a discount on its own removal from the UTXO set, not on creating new state.
The term “Discount rate” already has multiple important and conflicting definitions.
In the context of bitcoin, I think our “discount rate” might actually work out to be negative because of deflation. But regardless, I believe it’s a made up number.
Maybe “coin age discount” might be more specific.
Agreed that using coindays for the fee discount is a regressive, because it strongly favors wealth. It would not be useful for most normal folks in the long term.
With a progressive discount schedule using only days, we’d have to assure there is no incentive to create dust.
What about 1 sat per hundred blocks, capped at the bytes to add the input to the transaction?
Old inputs become “free” to add to a transaction after a few months, but the transaction outputs won’t be discounted.
On a specific number, the great thing about 1 sat per byte was that it’s easy to remember and easy to understand.
1 Like
That’s 0.7/ideal-day (ideal-day=144 blocks). I prefer it mapped to ideal-day, easier to conceptualize. At 0.7/day, a typical 150-byte input will become free-to-relay in 214 days. We could target half-a-year-to-be-free. That means 0.82/ideal-day, hold for full quarter for a 50% discount, month for 16% discount, and week for a 4% discount.
Miners can of course refuse to add such discounted TXs to their blocks. Important to highlight this: we don’t force anything, we just give the free market more range to work with, but we preserve DoS-resistance because it still costs some fee to grow the UTXO state count, and we still require minimum dust deposit in new UTXO. Discount is only for eliminating the UTXO from the state, not for adding a new one.
I think you hit the general solution here.
The magnitude and units for the terms can be moved around. But I think that equation is as simple as it gets.
I think blocks are the base time unit of bitcoin and satoshis are the base value unit, but I understand that virtually everyone prefers their Earth-day time scales and other units of value.
ALSO
Is it worth considering moving the min fee to consensus? Is that even possible?
I have been thinking about a gigabyte block attack lead by a single miner allowing spam.
I realize our hashing situation is a bit more diversified than some other projects, but it might be worth considering, at the same time, about moving the relay rule to a hard consensus rule to prevent one bad miner trying to make bad blocks drive out good.
I realize the blocksize debate is well addressed by ALBA, and since your the expert there:
Did ALBA completely mitigate a miner backed sub-relay fee spam attack? Do we still want to have both relay and consensus rules for fees?
2 Likes
Yup, and in case of local mempool reaching its limit (bursts of TXs can cause short-lived backlogs), discounted TXs would be the first to get evicted as the fee floor temporarily rises.
Block count would be base time only if target time is forever fixed. When we say height we really mean count. If individual block’s “height” (in the time dimension) varied, then count != height, and you need some other measuring unit to measure the height of block stack when individual blocks are not each of the same “height”. In the CHIP for 1-minute block time I propose ticks to disambiguate from the height = count we’re used to. It’s defined as 1 tick == 1 idealized millisecond, or, original 10-min height divided by 600k. Now when you stack a block of 600k (10min) and a few blocks of 60k (1-min), you can precisely measure the correct height: 3 blocks, but total height 720k ticks. If we’d ever change the target time again we could just keep using the same uniform measure. There’s an illustration in the CHIP: ac-0353f40e / Faster Blocks for Bitcoin Cash · GitLab
We can still use the original 10-min block’s “height” as the “etalon”, and for backwards-compatibility timelocks would continue to use height expressed in count of 10-min blocks. Explorers etc. could switch to ticks or they could use decimal e.g. 900,000.2 as the height expressed in 10-min blocks.
PS without knowledge of target time, the height doesn’t tell you the time, it becomes an unitless measure which you can’t anchor to real time based on only blockchain’s information. If someone gave our blockchain to an alien, but forgot to mention that 1 block targeted 10 min, the alien couldn’t tell if we had produced the blockchain in 10 years or 1 year. Target time (or target time schedule, in case we make it changeable) is the scaling factor that maps this “measure” to real time.
I understand it could be tempting, but I’m starting to think it’s not a good idea. It’s not really necessary, and if we’d add it as consensus rule we’d lock ourselves in for no gain. Relay rules protect nodes from verifying and passing spam transactions that will never get mined. But if a transaction is mined, even if it has 0 explicit fee, it comes with miner’s own PoW as anti-spam measure. Mined 0-fee and mempool 0-fee transactions don’t have the same DoS risk to nodes.
ABLA won’t let a single miner bring the limit overnight to 1 GB. A minority hashrate can only “stretch” the limit proportional to its hashrate. Even a 33% miner making 32 MB blocks full of spam while everyone else mines 10 MB would only allow the limit to “stretch” to ~57MB and it would take ~4 years to reach the asymptote (it’d reach ~43MB after 1st year of this). If others mined 1MB then the asymptote would be even lower. If others started mining 20MB then the asymptote would move up. But if everyone mined at 100% then we could reach 1GB in ~4 years.
I don’t know the exact number, but if the limit has a state of 1 GB then it must mean that the network is legitimately producing ~500MB average blocksize because that’s what it would take to maintain the 1 GB limit state, and spammer could only add about (500MB * his_relative_hash)*144 worth of spam per day, which would be a small % compared to legitimate transactions making 500MB*144 per day.
More on this here: README.md · main · ac-0353f40e / Adaptive Blocksize Limit Algorithm for Bitcoin Cash · GitLab
1 Like