Topic: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB) - page 17. (Read 14409 times)

You keep talking about miners mining this more quickly validating block... there is no code currently that can try to validate two different blocks concurrently and pick the one that validates faster. The first one that comes in will be under validation while any other blocks come in wait before they can be validated so unless someone has a rewrite that does what you claim, the problem still exists. First block that hits will always win.

No, "there has never been an excessively quadratic blocks in bitcoin". Yes, I am sure.

Of course, 'excessive' requires finesse. There has been, to my knowledge, one block in the history of bitcoin that contained a single transaction of nearly 1MB. That transaction took quite a long time to validate due to the quadratic hash time issue.

But what has been the repercussions of this event? Naddadamnthing. Well, there has been endless FUD yammering and chicken-little-ing. But in terms of the core function of Bitcoin, there has been exactly zero effect. In other words, not excessive.

Of course, if a persistent repeated sequence of such blocks were to be somehow mined back-to-back, that might slow transaction processing to a crawl*.

That is, if no other miner bothered to mine a competing block. Which, of course, is what a rational miner would do in such a situation. For then he would reap the rewards of a more-quickly validating block. (That would be the coinbase reward for solving a block).

The 'excessivity' solves itself. Through natural incentive of rational self-interest.

Sure, we should replace the current algorithm with one that scales linearly. After we address more pressing issues. Such as the cartel-like hard capped transaction production quota.

*Anyone supporting the core approach to 'scaling' has already tacitly accepted transaction processing being slowed to a crawl.

When I read your comment, this is what my mind flashed to.
https://www.youtube.com/watch?v=9fdcIwHKd_s

No compromise.

by limiting blocks ability to make a 1mb tx
by having improvements of libsec
by having hardware improvements (raspberry Pi is now atleast v3) quadratics doesnt become an issue.

if blocks grow to say 8mb we just keep tx sigops BELOW 16,000 (we dont increase tx sigop limits when block limits rise).. thus no problem.

however needing to rely on "probability of time" or "hope of 100% user migration of funds to segwit keypairs" is not a good enough solution to me and not a good enough thing to be selling segwit as the solution for. (because 100% key adoption wont occur, malicious users will stay with native keys on purpose)

so there has never been an excessively quadratic blocks in bitcoin.. due to faith in "time"

are you sure

careful how you reply, careful what you say next. the blockchain history never lies

From memory the closest we've come to that to date was that single transaction 1MB block from f2pool that took nodes up to 25 seconds to validate. It is possible to make it much worse, but newer versions of bitcoind (and probably faster node CPUs) would have brought that down. Rusty at the time estimated it could still take up to 11 seconds with 1MB:

https://rusty.ozlabs.org/?p=522

So yeah it has been used... possibly unwittingly at the time.

Your sarcasm escaped me. Though I must admit your statement elicited some surprise, as you have indeed been otherwise consistent in your advancing the notion that the quadratic hashing time solution within The SegWit Omnibus Changeset could simply be stepped around by an attacker.

Why I am trying to tell you is that it doesn't matter. It's not a problem in any systemic sense. Market forces will conspire to orphan blocks that take an inordinate amount of time to verify. Regardless of which -- or even if any -- scaling solution be adopted.

my "doesnt need" was sarcasm because segwit does actually need it.
the sarcasm was pointed at those that think segwit will fix the issues simply by the belief in 'time'

I don't understand that statement. Are you talking about DooMAD's idea (modified BIP100+BIP106) or the compromise proposed by "ecafyelims", or both?

I ask because I think DooMAD's "10%-blocksize-change-voting proposal" sounds interesting and if there is support by staff/respected community members/devs then it would be worth discussing it in a separate thread to elaborate a "final BIP".


Well, if I understand right (as a [almost] non-programmer) then that problem could be solved by coding the change proposal in a way that explicitly delays the hardfork until a lot of time (several months) has passed after the Segwit activation. That should be possible - it would then signal the "big blockers" that their desired blocksize change will come, but would give the system time to adopt Segwit transactions.

No new rules need be defined.


No weakness. No belief. No faith. Natural incentives of rational self-interest.


Yes - now you're getting it.

but this is where the rules need to be defined. so that if a malicious pool did add it. the LOWER tx sigops would be knowingly rejected by consensus so pools wont bother.

by keeping it at 16,000 malicious pools 'could' accept it and know its a valid block and only have to worry about 'timing' as the disincentive, rather than RULES.

however if you prefer not to have RULES and just rely on belief or faith of pools.. then that is a weakness.
however if belief and faith were strong for such an occurrence not to happen. than quadratics has never been a problem and never be a problem because bitcoin is protected by belief that it will get orphaned due to 'time'.

meaning segwit doesnt need 100% of users to move their funds to segwit keys (weeks after activation) just to possibly get a segwit fix to fix it(never gonna happen anyway), because belief alone in 'time' has protected the network thus far and will continue to

You're sounding like a Segwitter jbreher


How come Franky, the Bitcoin genius who loudly shouts about how loudly shouting makes him right all the time, can't figure this out too

Bitcoin is permissionless. The proper answer to "who the damned F*ck should be allowed to build..." is anyone who wishes to.

But another aspect of permissionless is the fact that no miner is compelled to include that transaction into a block. In fact, there is a natural disincentive to any miner including such a transaction into a block. Blocks that take a long time to validate are likely to be orphaned by other blocks which validate quickly.

apparently, Sigop DDoS attack is possible now, because the Sigops per block limit is too high.


Why isn't anyone using the attack then?

No.

Banning nodes is completely fine.

---

Anyone ready for the altcoin called BTU?




https://twitter.com/zaifdotjp/status/839692674412142592
https://twitter.com/SatoshiLite/status/839676935768715264

cores limit is not low enough

MAX_BLOCK_SIGOPS_COST = 80000;
MAX_STANDARD_TX_SIGOPS_COST = MAX_BLOCK_SIGOPS_COST/5;

who the damned F*ck should be allowed to build a single tx that uses 20% of a block!!
who the damned F*ck should be allowed to build a single tx has 16,000 sigops!!

lower the TX sigop limit to something rational and you wont have the worry of delays due to sigop validation

also. one thing CB is missing out on


meaning native transaction users can still sigop SPAM.
segwit has nothing to do with disarming the whole block.. just segwit transaction users

again because carlton is not quite grasping it

Well, yes. I was just illustrating how hysterical the notion that "the price crashed due to Chinese Antpool mined BU block" was.

It's just a flag added to the block to show whether the pool is voting for segwit or BU, nothing more. The blocks are exactly the same otherwise as far as I know.

Forgive me if i'm a bit skeptical that segwit is a good idea.  It sounds very complicated and
that once we do it, we'll be stuck with it.

I thought it was initially promoted as a way to avoid a hard fork but if we're going to
be forking to 2MB anyway, what is the point?