Author

Topic: Dynamic Blocksize (Read 947 times)

full member
Activity: 135
Merit: 107
July 10, 2015, 04:55:20 PM
#6
Quote
If the block space is infinite...

These arguments are non-sequiters in the face of my proposal.  Are there any tests proving nodes cannot increase orphan rates by refusing to relay larger transactions?  I don't agree with the suggested miner collaboration model either.  Miners compete with each other so, upon seeing a likely-to-be-orphaned block mined by a competitor, there would be a point where it is worth their while to not relay the transaction and attempt to orphan it with a more acceptable size.  With these limits there is never "zero incentive for miners to not fill blocks entirely" and there would never be incentive to reduce the number of nodes to 1.  In fact, empowering nodes like this incentivizes more nodes, not less.  For example, if enough users don't like the current acceptable block size, more nodes requiring their preferred size will go online.

Quote
The only _fundamental_ cost is communicating the discrepancy between the transactions included and the assumed included transactions.  This can be arbitrarily low, e.g. if miners delay a little to include only somewhat older well propagated transactions-- the cost then is not a question of "size" but in breaking rank with what other miners are doing (and, in fact, producing a smaller block would be more costly).

This is exactly what my proposal should negate.  Transactions that get too large could never become "well propagated transactions".  Therefore, there would be a point where producing a smaller block is more profitable.
sr. member
Activity: 433
Merit: 267
July 10, 2015, 04:03:24 PM
#5
Why not remove the block size entirely was discussed somewhat recently here;
https://bitcointalksearch.org/topic/m.11439896

This is a succinct way to put it;
If the block space is infinite then transaction costs, through competition, would fall to roughly the rate needed to operate [a] single node (when inflation stops), because this is the most competitive configuration in a free market.

This is a refined way to put it  Tongue;
There is zero incentive for miners to not fill the blocks entirely; almost any non-zero fee would be sufficient.
There are physical limits and costs that would prevent this.  Each additional transaction increases the size of the block.  There are costs associated with increasing the size of a block.  At a minimum, there is a (very small) increase in the chance that the block will be orphaned.
The only _fundamental_ cost is communicating the discrepancy between the transactions included and the assumed included transactions.  This can be arbitrarily low, e.g. if miners delay a little to include only somewhat older well propagated transactions-- the cost then is not a question of "size" but in breaking rank with what other miners are doing (and, in fact, producing a smaller block would be more costly).

Even without optimal differential transmission, and only looking at techniques which are nearly _universally_ deployed by large miners today; with the relay network protocol the marginal cost of including an already relayed transaction is two bytes per transaction. I can no longer measure a correlation with block size and orphaning rate; though there was a substantial one a few years ago before newer technology mostly eliminated size related impact on orphaning.

Importantly, to whatever extent residual marginal cost exists these costs can be completely eliminated by consolidating the control of mining into larger pools. We saw people intentionally centralizing pooling as a response to orphaning already (two years ago) which prompted the creation of the block-relay-network/protocol to try to remove some of that centralization pressure by reducing the cost of block relay so there was less gain to lowering the cost by centralizing. Moreover, any funds being spent coping with these costs (e.g. paying for faster connectivity to the majority of the hash-power) cannot be funds spent on POW security.  So I would refine DumbFruit's argument to point out that it isn't that "fees would naturally be priced at zero" but that the equilibrium is one where there is only a single full node in the network (whos bandwidth costs the fees pay for) and no POW security, because the that is the most efficient configuration and there is no in system control or pressure against it, and no ability to empower the users to choose another outcome except via the definition of the system.  I believe this is essentially the point that he's making with "the most competitive configuration in a free market"-- even to the extent those costs exist at all they are minimized through maximal centralization.  This is why it is my believe that its essential that the cost of running a node be absolutely low and relatively insignificant compared to POW security, or otherwise centralizing is a dominant strategy for miners.
full member
Activity: 135
Merit: 107
July 10, 2015, 03:10:36 PM
#4
In true free-market, decentralized fashion, push that decision to the edges.  Remove the hard limit and let the nodes and miners decide.  Miners create the blocks so they obviously have a direct connection to the size they want.  Nodes can collectively influence the miners by refusing to relay any blocks over whatever limit they decide.  A miner would have to weigh its increasing chances of orphaning a block vs. the return of including more transactions, and a market-based size will result.  This method would be the most adaptable to changes in the network (like the recent "spam" attack) and dynamically responsive to market desires.  What's interesting is that individual nodes could also refuse to relay blocks below a minimum size (or a certain % of the mempool, however it's preferred) in order to discourage empty blocks.  I'd love to see something like this simulated to test how much influence nodes can have on orphan rates.  Perhaps an interested hacker can modify Gavin's or Pieter's code.
sr. member
Activity: 433
Merit: 267
July 08, 2015, 11:02:58 AM
#3
Of course, there's pretty close to an infinite number of schemes that can produce a dynamic blocksize. The issues are that they all so far have relied on future predictions, and altering the utility of Bitcoin, all in favor of some particular ideology.
That's if the scheme manages to avoid the minefield of attacks and sustainability issues.

I don't think there's any way for a single blockchain  to objectively get this perfectly right.

An idea I've been thinking about is tiered blockchains, resembling a merge mining architecture. The top tier would be very small, maybe able to handle a megabyte per year. This chain would also verify a subchain via arbitrary hashes submitted to it (Separate from it's own currency transactions.). The second tier would verify itself by pulling those hashes off of the top tier and following the hashes with the highest work. This could be tiered arbitrarily for larger and larger chains.
In that way, you could have as big of block space as you'd like without segregating hashpower and people could decide which tier they want to transact in depending on how decentralized they want their transaction to be. Nodes would also have the ability to choose how much resources they want to contribute. They could mine for only tier 1, or tier 1 and 2, or tier 1, 2, and 3, etc.
Each "tier" would essentially be a different currency on the open market and exchanges would find the market clearing price for each tier. Each tier would provide it's own currency as fees to miners, which is obviously dependent on it's value in the market.

Intuitively, it seems like there is a solution in that direction, but I haven't been able to rigorously show it.
legendary
Activity: 3472
Merit: 4801
July 07, 2015, 01:16:42 PM
#2
Possibly.

If you (or someone else) can come up with a safe way to dynamically determine what the blocksize should be, and you can get nearly everyone to agree with you on your solution.
sr. member
Activity: 330
Merit: 250
July 07, 2015, 01:05:20 PM
#1
Would it be possible to make something like a dynamic blocksize?
Ending the blocksize discussion and move forward would be really nice.

Jump to: