Topic: Bitcoin 20MB Fork - page 18. (Read 154787 times)

Today I would say you could drop or include as a full txn (depending on fee) a small number of standard txns and get a high IBLT proof success rate.   It would make sense to assume that non-standard txns, very stale txns (txns which have been in the memory pool much longer than normal) and very recent txns are not O(1) and only include those if the fee is higher than the propagation cost.

The larger point is that is only true today while the txn volume is low.  If txn volume remains lower than the bandwidth requirements of most nodes then larger blocks aren't an issue.  You know that thinking in nominal terms for a computing network is silly.  In 1980 someone would have said 1MB blocks every 10 minutes to tens of thousands of nodes all over the world would have been an impossibly high resource requirement to base a decentralized network on but today it is trivial.   So what matters is not the nominal size but the size relative to the median node's resources.   My point is that IBLT only results in O(1) if the IBLT set is smaller than the resource availability of median node.  If it is higher than the IBLT proof will fail for a majority of the nodes and they will request the full block resulting in the full propagation cost.

As a thought exercise, if there was no block limit today and IBLT was already implemented could a miner create a 1GB block have O(1) cost?  The answer is probably not.  The median node would not have a superset of the txns in the IBLT set.  They would either be dropped due to being stale or simply because the node had insufficient bandwidth to relay all txns.  So solving the IBLT would fail and the receiving node would need to request the full block at O(n) costs.  Would it make sense for a miner under that scenario to create that block with txns which pay less than the expected orphan cost?  Once again no, no more than it would without IBLT.

What about all blocks up to the median (i.e. a set which has a high confidence of being a subset of the memory pool of >50% of the nodes)?  Well you're right the marginal cost would be near zero but the miner can't control the resource availability of other nodes so he can't force them to accept more.  Also if the majority of nodes can handle that volume and there is sufficient demand for that volume why would we want to artificially prevent that transaction volume?

Now a jump to 1GB (or unlimited) block size would be bad today.  It doesn't have anything to do with fees or economics though.  It has to do with the original reason for the limit and that is security.  It would not be economical (in fact it would be moderately expensive) for a miner to create 1GB blocks but they would hurt the network by bloating the blockchain.  This is why I am not in favor of an unlimited block size.   The current block limit has had no impact on economics but it does provide an upper bound on the damage caused by an attempt to maliciously bloat the blockchain.  Those arguing unlimited block sizes often forget this fact.   So from a security standpoint the question becomes at what rate can the limit be raised with low risk.  At some point in the future 1GB will have lower storage and bandwidth costs than 1MB does today.   I don't favor Gavin's current proposal only because I think the high rate of change is a risk.  A lower rate of change that is sublinear to Neilson's Law over a longer period of time can get us to the same place with less short term risk.

True I updated the post to indicate that I have no belief that Bitcoin will ever be changed to that degree.  It was more a thought exercise.  The current fee model does trend towards low marginal cost.  In most economic models marginal cost does not follow that pattern.  I thought it was useful to point out that the 'we need artificial scarcity to keep fees high enough to secure the network' is really an outshoot of that deeper problem.  If the marginal cost doesn't trend towards zero then there is no incentive to scoop up any fee greater than zero.

Umm... no.

You confuse a syllogism and a basic linear function of the form f(x) = ax + b
In our case, f(x) is the profitability threshold and x is the marginal cost of inclusion of a transaction, a = 1 and b = 1.

f(0) = 1, f(1) = 2, etc.

I hope this makes it clearer for you.

It's not half a sentence - it's the premise of a syllogism.

Refuting premises to falsify a syllogism isn't a matter of being interesting or not interesting - it's about being logically correct or not.

This is the difference between reasoning and sophism.

It sure is easy to argue against half a sentence, that's not really interesting for anyone but you though.

We're headed to altcoin-ville here

It isn't, and will never be.

I don't disagree with that, but it's pretty clear IBLT will remove a very big part of the incentive a node has to mine small blocks.
Of course it wouldn't be 100%, but if the confidence heuristics you implicitly refer to, are pretty similar across nodes, I hardly see more than a few percent of the mempool set being dropped for "IBLT-safety" purposes, which doesn't fundamentally change the argument.

And btw, your argumentation wrt pruning made sense.

Specifically IBLT is only O(1) if the receiving nodes have a superset of the block txns in their memory pool.  Unless bandwidth is free and unlimited, this will put an upper bound on the size of the O(1) txn set.  Even if a miner has free and unlimited bandwidth the O(1) set is limited to the available resources of its mining peers.  Transactions in excess of that can't be propagated using IBLT without risk of IBLT proof failure.  The cost of IBLT proof failure is to request the full block at O(n) which carries the full oprhan cost.  A smart (and dumb miners will go bankrupt) miner will err on the side of caution and keep the IBLT set small enough to have a high confidence that its peers have a superset of those txns.  Everything else (non-standard, stale, low fee, or just excessive) would need be pushed as full transactions to avoid the IBLT proof from failing.  As long as we live in a world which has finite and non-zero cost bandwidth there will be a marginal cost for txns beyond the inflection point.

Today that would limit the IBLT set to be all 'standard' txns but that probably will not be true in a high txn volume environment.  Today a txn has a very high chance of rapidly being included in the memory pool of nearly all well connected nodes as long as it is 'standard' (and that includes paying min fee to relay for low priority txns).  That is true because the bandwidth requirements for the propagation of all standard txns is negligible.  Even with overhead to relay 1 tps only requires all full nodes to have at least 10kbps but at some point the bandwidth (and to lesser extent memory) requirements will require nodes to drop some txns which are otherwise standard.  Since miners are most likely to include the highest paying fees it would make sense for all nodes to drop the lowest paying txns as their links (or memory pool) becomes saturated.  The memory pool will no longer be (nearly) uniform across nodes.  However the highest fee standard txns will still remain uniform across nodes.  A smart miner would use IBLT proof to capture that 'high confidence' head as that is both the highest revenue and the lowest risk.  Including more increases the probability that the IBLT proof will fail and that results in the full orphan cost to the miner.   Miners could still include low probability txns from the tail but it would only be economical to do so if they are worth sufficient revenue to cover their propagation cost.

One thing I would add is that IBLT could result in reduced DDOS protection.  These vulnerabilities could be created by any node not just the miner as the IBLT isn't part of the proof of work and as such have no cost.   With very small blocks the computational resources to reconstruct the block from the IBLT proof is small but with larger blocks it could be used to degrade the network.  Before IBLT is deployed we should strongly look at DDOS vulnerability and ways to harden against it.  One way would be to put the IBLT (or at least some of the metadata) into the blockheader itself but that would require a hard fork as well.  If nothing else it would be useful if the blockheader contained the number of transactions.

Sadly Satoshi did a lot right but he didn't give us a very good fee economy and an artificial scarcity model is just something people have clung to as an unintended 'solution' to that larger problem.   There probably will never be a consensus to change the fee model but one example which would have an increased marginal cost would be a reverse dutch auction.  Miner states fee requirement and can include any txns above that requirement but no txns below that requirement.  Direct compensation to miner is only the stated amount even if fee is higher.   Thus it would not be economical for a miner to accept 1 satoshi per kb because he would only get paid 1 satoshi per kb for all txns.  The 'excess' fee could either be burned or rolled forward to be paid out in future blocks.  I don't hold much hope in changing the fee model but it is something to consider for sidechains or alternatives.

Nope. The lower the marginal cost of including a transaction in a block, the lower the minimum acceptable fee .
If the marginal inclusion cost is zero, the minimum fee is one satoshi, if the marginal cost is one satoshi, then then the minimum fee is (wait for it...) two satoshi.

How does this fundamentally change the reasoning?

The only way to make the scenario you described possible is if a business has - not just low costs - but zero costs.

Well, any business that has sufficiently low costs to be able to turn this amount into a positive profit.

Specifically?



Sure, but we may never be aware of these reasons, we can only reason on the economic profitability of including, or not including a transaction, and as far as economics are concerned the reasoning holds.

No, not entirely.  Mining incentives are complex, and so also is the marketplace.  I do not see this as absolute.  It is a bit orthogonal to this discussion (or at least my part in it).
I do agree that it very much lowers the orphan risk bar for miners with respect to transactions that have been broadcast.  The benefit comes from the bandwidth reductions and also from smoothing of the traffic.  I see it as probably a pretty good thing.

Miners may include 0 fee transactions, and may not include fee transactions at their whim.  Miners may have their own reasons for doing things.  These reasons may or may not have anything to do with Bitcoin.  This is why not just decentralized mining but also distributed mining and pools is an important factor for Bitcoin to continue to exist.

This is incorrect.

I would also like to see some better reasoning.  Here are just a few of the reasoning deficits.  There may be some work on these out there in the interstices of the internet somewhere.  If you have a link, I'd like to see it please.

1) Why the jump in size?  Why not 2MB, or 200MB?  It is arbitrary, so why is this picked?  Why not start the exponential growth from where we are now?   Or from when the 1MB was set?  (I think this proposal starts it too high)

2) We are perhaps losing the TOR nodes with the increase.  This is more TOR's problem than Bitcoin's problem to solve though.  (Trading TOR for enabling micropayments is probably going to be OK though Bitcoin may tragically lose some important users and use cases)

3) Why 20 years?  Bitcoin hasn't been around this long, why is there such confidence?  Why not 2 years or 200?  (I think it is too long).  I also think that the wrong "exponential growth" is being looked at here.  This is a "Bitcoin Developer Growth" problem as much as it is a "bandwidth increase" growth problem.  The END of this problem comes from development and innovation, not from picking arbitrary values for these variables forever.  20 years is a long time and I think this problem can be fixed sooner...if we make the effort to do so.

Do you agree with the argument that, with IBLT deployed, there is no rational reason for a miner to limit the size of blocks it is willing to mine ?
(In other words, if blocks do not risk getting orphaned because of their big size, it is economically profitable for a miner to include all the transactions that bear a >0 fee, no matter how small the fee is).

YES

I am not of the opinion that a scarcity market for transactions (at the protocol level) produces greater net mining fee than one which "could" include all transactions that a miner wants to include.  Mining pools can include and exclude transactions and set their own pricing and their own max sizes independent from the max block size in the protocol.  I am happy to let the miners create the market for their own blocks rather than at the protocol.

My "not this fork, please" is not based on the mining incentives from fees at all.  It is about the safety of Bitcoin

At about the time satoshi put the limit down at 1MB from 32MB he wrote:


My problems are:
1) I see both that both the 1MB limit and the exponential growth path of the latest proposal are broken.  The 1MB is acknowledged as broken, at the time of its inception, and ultimately would need to be changed.  I simply see the "20MB Fork" as more broken (and that is a really bad name for it because that isn't the proposal at all).

2) I would rather Bitcoin grow slower and keep is security and robustness than grow faster and lose that, because losing those destroys its reason to be what it is.

I do like what Gavin has done so far, curating the opinions and knowledge of what a good size and growth pattern might be.  However fundamentally iCEBREAKER is right about bigger not just being more, it is also different.  Too big does exist, and exponential growth for 20 years is not a good plan to avoid that.

Like it or not, we are approaching a world of automation.  It isn't going to be "just people" creating transactions for much longer.

To be honest I'm not sure.

There are a few things to keep in mind, for one we still have the block reward, so whatever experience we may or may not gain from observing an actual backlog may or may not apply to conditions where the block reward does not exist anymore.

The fact that there is a backlog is meaningless if that backlog is made of changetips and other frivolous transactions that really don't require the level of security that native Bitcoin has to offer.

You won't find a common denominator among technical people because this issue is hardly just a technical one.