Topic: SegWit + Variable and Adaptive (but highly conservative) Blockweight Proposal (Read 2090 times)

Yes. I think what we need is code - an actual implementation draft - and a real BIP proposal, as soon as we can. The UASF/MAHF polarization doesn't look good. Unfortunately, I am the wrong person for this (I only know a little Python, no C++ at all).

Any news with respect to the "orphaning risk problem"? I have looked at Luke's BIP but there's nothing about it, there. And unfortunately here my knowledge about the issue comes to a limit.

Maybe it would be even OK to start with a BIP and ignore that issue for now, or draft two versions (one with the decrease option, the other without it).

With the Miner-activated fork vs User-activated fork situation looming on the horizon, time is running out if you don't want a fixed blocksize "solution", which will undoubtedly make us revisit this same horrific debacle when we start hitting another purpose-built wall later.  Whoever activates the fork, either blinkered and shortsighted outcome is foolish.

Either we reach an intelligent compromise soon, or we descend into chaos and farce once again in the future.

It's time to decide.

carltons 'infinite growth' .. or as the reddit script Fudster buzzword calls it "gigabytes by midnight"
i facepalm that.

imagine it this way.
we are in 2013.. consensus is 1mb.. but policy is 0.5mb
now imagine if that 0.5mb was not simply a decision pools made alone. but nodes had some control of. to ensure it didnt jack up above 0.5mb too fast.
where nodes had a speed test benchmark mechanism in their node which publicised what they could cope with.
nodes wouldnt necessarily orphan the blocks above 0.5mb. but would atleast highlight to pools where pools should slowdown if there was not a good healthy node capability

EG
2018 new rules
8mb consensus
nodes publicise 4mb capability

pools made blocks below 4mb at healthy increments of 1mb-4mb over time(eg 0.25mb/year (kind of like 2011-2015(roughly))).. where pools knew what they do would not cause risks to nodes.. thus not cause orphan drama. or drops of node count
if pools know what the network can handle then pools know what not to risk

---

separate rant
what i do truly laugh at is while the "gigabytes by midnight" fudsters are screaming 'it will kill full node count'
they are not arguing how many full nodecounts are dropping due to prunned, no witness(stripped/filtered/downstream) features which have been added and told are "all good and safe"

value of a TX is meaningless.. and 'rich' spammers got around the old fee mechanism by having a TX where one output had 10kbtc and the other outputs of the same tx had 1sat each
which allowed him to not pay a fee because the old formulae was based on value.

this ended up hurting everyone else though. especially those from 3rd world countries who were not spammers, were not able to have 10k btc to counter the fee, where they just innocently wanted to send more than a couple hours labour (only a few cents) but ended up paying more in fee's.. while malicious spammers didnt pay a fee because they simply worked around the 'value' test

---

all that matters is how 'fresh' the coins are and how bloated the tx is.

i see no reason at all for ANYONE to have the need for 10%-20% allocation of a block just for 1tx
so things like
4k txsigops of 20k blocksigops
or
16k txsigops of 80k blocksigops
is literally asking for trouble.(5tx fills the block)

i suggest if the block is going to be 4mb (80k blocksigops)
then make txsigops 2k... and make sure even if blocksigops rises.. txsigops does not. that way each increase makes it harder.

also
the 100kb 'larger than' tx data rule.. again who the hell deserves 10% of block space.
bring that down to 10kb or less. and keep it down even if the blocksize increases.

that way it makes it cost more to fill up

Well, I did ask:


which is related to fees making it harder to spam, and then the thread died for almost 3 days.  

But yeah, let's look at the fee priority mechanism as well.  Each level of security we can add makes it that bit more robust.  But I'm reluctant to drop the reduction aspect in the same way I'm reluctant to adopt Carlton's fixed upper cap.  I sincerely doubt you'd accept his idea and there's no way he'd accept yours, heh.  Both views are a bit too far towards one of the polarised extremes.  In order to be a compromise, I'm trying to steer this thing somewhere towards a happy middle-ground.

there is a simple fix.. without all the cludgy code to drop the blocksize and ensure resyncing doesnt cause issues of orphaning when blocksize drops

afterall decreasing the blocksize hurts everyone, should in a fortnights time demand picks up again but hits the decreased wall.. (so thats just silly) as all the complexities of trying to avoid the rescan orphan things i said before

but if the block remained at 4mb but was 'empty' it would cost a spammer a hell of a lot more to fill it. compared to a block that decreased to under 4mb..

---

the solution is simple.. a new fee priority formulae
a better fee priority mechanism ensures the spammers pay more for spamming every block while not causing issues for the normal folk.


in short dcreasing the blocksize consensus can cause more issues for everyone, requires more coding and more cludge
where as a fee priority makes frequent spammers pay more.
the fee priority also makes sure that people, innocent or guilty of spamming DONT pay the same penalty. thus being fair to the innocent that care about the transactions they make and penalise the ones that dont care and just wanna respend as fast as possible but refuse to use LN

There must be a simple fix, since (at least as far as I remember seeing) no one raised the issue when BIP106 was originally proposed, or, more particularly, when lukejr proposed reducing the blocksize.  I'm sure a dev wouldn't have made a proposal with a gaping hole in it.  Someone would have voiced concerns well before this point if it were a showstopper.  Obviously this wouldn't work as a soft fork, so if all nodes are upgraded, it stands to reason we can tell them not to reject blocks that were valid at the time.

As for blocks being newly appended to the chain at the moment of a reduction, miners could voluntarily operate a soft cap of .01 base and .03 witness under the current threshold if they wanted to play it safe.  Effectively they could operate two weeks in lieu of the actual limit.  Plus that's only an issue if the blocks are full to the brim at the time.

Regarding the problem to "decrease" the maximum block size eventually: I have thought a bit about it, I'm not an expert but I think also it would be desirable to decrease the maximum block size in the case blocks are far from being full, to dis-incentive spam attacks. It would however not be a show-stopper because the proposal is really so conservative that a spam attack would be very, very expensive anyway.

Regarding franky1's orphan risk because of rescanning nodes: I think there is no other way than what aklan said, to store the maxblocksize changes in the blockchain, so the nodes are aware of the changes when they rescan. There would be perhaps another possibility  - to make a conditional decision ("if CheckedBlockSize > ActualMaxBlockSize and CheckedBlockHeight < (ActualBlockHeight - 2016) then AcceptBlock") so nodes can accept larger blocks when they rescan and are more than one difficulty period under the actual block height, but I don't know if this introduces new attack vectors like nodes passing a fake ActualBlockHeight value.

That is what i want to know.

In the scenario you've described, both blocks would be the same size.  Empty and unused space indeed doesn't create any additional data requirements.  But I did give at least 3 reasons why there is a point in being able to reduce the maximum blocksize if the space isn't being used.  Unused space has the potential to be abused.  We want to limit the potential for abuse.

By the same token, you could ask if there is any point in having a maximum blocksize at all.  It essentially amounts to the same thing.  Smaller is generally considered safer.

You haven't answered my questions.

a very detailed and clear response. thanks!

There are actually a few reasons for that decision:

Partly it's the simple fact that we don't know what the future holds or what the levels of demand may be as time goes by.  So if we're aiming for the proposal to be adaptable to demand in real time, it makes sense that we don't want to arbitrarily limit the types of situations it can adapt to.  

Then, as previously mentioned, there's the disincentives to spam, or to game the system with artificial volume.  If demand isn't legitimate, a reduction will negate any fraudulent increases as soon as the attack can't be maintained.  We don't want to encourage spam.  That's a huge no-no.  While miners can certainly choose voluntarily to make smaller blocks, it should be noted there is a clear financial benefit to be gained from cramming in more transactions and collecting more fees as a result.  Gaming the system to reach a higher blocksize to squeeze in more tx in this manner is also a no-no.  We want natural and organic growth, not manipulation.

Also, many deem fee pressure to be an important characteristic of Bitcoin.  In an ideal world it should have a fair amount of consistency and not fluctuate too wildly.  While we obviously don't want fees to be too high, at the same time, we don't want them to be too low, either.  If the space available exceeds demand, fees could potentially diminish, which could sway the alignment of incentives for miners.  This particular issue is a big problem with all of the "whole number" blocksize proposals, that generally involve at least doubling the blocksize and completely obliterating any kind of fee pressure.  As such, changes should be smaller and more frequent.

And lastly, the legitimate concerns over the costs of bandwidth for full nodes as the total blocksize increases.  We have to take every reasonable precaution to prevent any large increases that could potentially result in a drop in node count.  Plus, there have been enough instances in this increasingly ugly scaling debate where one side appears to be shouting over the other and not taking into consideration opposing views.  With this proposal, I'd hope those of both sides of the argument at least feel their voice is being heard.  

Hope that clears it up.  

i think it's meant to be like the rising and (rare, but possible) falling of the difficulty. it can adjust up, or down, as needed.

though as i sit here typing this i'm having a hard time thinking of a real reason it would need to get smaller. the difficulty, of course, needs to match the available hash power to provide security and keep the prescribed block times. but since we can already make and confirm smaller blocks if we want to, i don't know that a reduction in max size is needed.

i'm not a coder of any kind, though. don't take my word for it.

Else IF more than 90% of block's size, found in the first 2016 of the last difficulty period, is less than 50% MaxBlockSize
    THEN BaseMaxBlockSize = BaseMaxBlockSize -0.01MB
      WitnessMaxBlockSize = WitnessMaxBlockSize -0.03MB

If 1mb block had 1 * 250k tx and 2mb block had 1 * 250k tx - surely the file size of the block is the same? or not? Empty spaces don't have any bytes??

If there any point in reducing the maxblocksize?

I think that's another one of those things that everyone finds difficult to agree on.  The safest definition for me would be deliberate and repeated transactions with no intention to transfer any value, but it's not always easy to recognise such transactions if the culprit is determined to cover their tracks.  Some attackers are more blatant than others.  But equally it's easy to lose context and assume that all small value transactions or transactions with low fees are spam, but this isn't a safe assumption due to users in less economically wealthy parts of the world getting involved.  All we can really do is minimise the motivation to engage in deliberate spamming by making it expensive or difficult (or both) to do.

Was Litecoin's spam fix ever implemented in Bitcoin?  And if not, could we look at implementing that as part of this proposal?

Define Spam first.

 

I remember vaguely of reading about this proposal on the Development forum (not sure if OP is the same) and I think deploying this would be a very reasonable solution that would be of interest for both "sides" of this question. In addition to this many people have already talked for several times about dynamic blocks... And I think the only reason this hasn't been implemented yet is because we don't have enough developments regarding that.

I'm all for scaling. I wouldn't mind seeing a system like this go live on Bitcoin.

Plus, this thread is a nice read in a forum where there's been a lot of hate lately

could track what the max block size was for a given difficulty, perhaps? either a database of "this difficulty = this blocksize" or some sort of code, while determining orphans, to check if the blocksize was valid at the time.

Exceptional reasoning, I'm totally on board with that.  I was hoping we could find improvements that help raise disincentives to spam and this absolutely qualifies.  OP updated.  Thanks.  



Maybe it's just me, but I honestly don't see what's logical about taking a stab in the dark now with no way to accurately forecast future requirements.  Particularly if that stab in the dark could easily result in another contentious debate later.  If someone can convince me why a potential hard fork later is somehow better than an equally potential soft fork later, I'll reconsider my stance.



Is there some kind of workaround or fix that would still enable us to reduce dynamically while limiting the potential for orphans?  I have doubts a sufficient supermajority could be reached for the proposal if max sizes could only increase.  It needs to be possible to reduce if there's a lack of demand.