[POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)

[jbreher]

Bitcoin already has a sigops per block limit to mitigate the risk of this attack (despite the FUD that introducing such a limit is all that's needed to solve the problem, which is pretty dumb considering that's already what happens )

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!!

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.

[1714098398]

1714098398

[1714098398]

1714098398

[1714098398]

1714098398

[1714098398]

1714098398

[Carlton Banks]

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.

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

[franky1]

Bitcoin already has a sigops per block limit to mitigate the risk of this attack (despite the FUD that introducing such a limit is all that's needed to solve the problem, which is pretty dumb considering that's already what happens )

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!!

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.

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

[jbreher]

Bitcoin already has a sigops per block limit to mitigate the risk of this attack (despite the FUD that introducing such a limit is all that's needed to solve the problem, which is pretty dumb considering that's already what happens )

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!!

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.

but this is where the rules need to be defined.

No new rules need be defined.

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'.

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

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

Yes - now you're getting it.

[d5000]

I have read DooMAD's proposal now and I like it a bit. [...]

I do have to add that, while I think that it would be still extremely hard to gather 90-95% consensus on both ideas, I think both would reach far higher and easier support than either Segwit or BU.

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".

Core would not because they're all convinced we must have segwit before increasing the block size to prevent a quadratic scaling sigop DDoS happening... though segwit doesn't change the sigops included in regular transactions, it only makes segwit transactions scale linearly which is why the blocksize increase proposal is still not on the hard roadmap for core as is.

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.

[franky1]

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

Yes - now you're getting it.

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'

[jbreher]

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

Yes - now you're getting it.

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'

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.

[-ck]

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


Why isn't anyone using the attack then?

Always assume that if a malicious vector exists then someone will try and exploit it

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.

[franky1]

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.

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

[franky1]

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.

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)

[Hexadecibel]

No compromise.

[AgentofCoin]

No compromise.

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

[jbreher]

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.

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

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.

[-ck]

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.

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.

[unamis76]

This and other similar mix of BIP's has been suggested... If it scales, I'm down for it or pretty much anything else.

I have read DooMAD's proposal now and I like it a bit. It would give less powers to miners as they only can vote for small block size increases, but would eliminate the need for future hardforks. The only problem I see is that it could encourage spam attacks (to give incentives to miners to vote higher blocksizes) but spam attacks will stay as expensive as they are today will be even more expensive than today because of the "transaction fees being higher than in last period" requirement, so they are not for everyone.

Very interesting post. The other issue I see here is that such code doesn't exist, thus isn't tested, so it can't be deployed anytime soon.

[franky1]

also worth noting

miners dont care about blocksize.

an ASIC holds no hard drive. an asic receives a sha256 hash and a target.
all an asic sends out is a second sha256 hash that meets a certain criteria of X number of 0's at the start

miners dont care if its 0.001mb or 8gb block..
block data still ends up as a sha hash

and a sha hash is all a miner cares about


pools (the managers and propagators of blockdata and hash. do care what goes into a block)

when talking about blockdata aim your 'miner' argument to concern pools ... not the miner(asic)

[jbreher]

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.

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 disrespect intended. But should excessively-long-to-validate blocks ever become significant, mining using an implementation that does not perform parallel validation is a guaranteed route to bankruptcy.

"no code" - you sound pretty sure of yourself there. It may even be the case ... right up until the point in time that it is not.

[-ck]

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.

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 disrespect intended. But should excessively-long-to-validate blocks ever become significant, mining using an implementation that does not perform parallel validation is a guaranteed route to bankruptcy.

"no code" - you sound pretty sure of yourself there. It may even be the case ... right up until the point in time that it is not.

Right, there is no *public* code that I'm aware of, and I do hack on bitcoind for my own purposes, especially the mining components so I'm quite familiar with the code. As for "up until the point in time that it is not", well that's the direction *someone* should take with their code if they wish to not pursue other fixes for sigop scaling issues as a matter of priority then - if they wish to address the main reason core is against an instant block size increase. Also note that header first mining, which most Chinese pools do (AKA SPV/spy mining), and as proposed for BU, will have no idea what is in a block and can never choose the one with less sigops.

[franky1]

im starting to see what game jbreher is playing.

now its public that segwit cant achieve sigop fix. he is now full on downplaying how bad sigops actually is...
simply to down play segwits promises by subtly saying 'yea segwit dont fix it, but it dont mtter because there is never been a sigop problem'

rather than admit segwit fails to meet a promise. its twisted to be 'it dont matter that it doesnt fix it'.

much like luke JR downplaying how much of a bitcoin contributor his is at the consensus agreement. by backtracking and saying he signed as a human not a bitcoin contributor.. much like changing his hat and pretending to be just a janitor to get out of the promise to offer a dynamic blocksize with core.

[jbreher]

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.

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 disrespect intended. But should excessively-long-to-validate blocks ever become significant, mining using an implementation that does not perform parallel validation is a guaranteed route to bankruptcy.

"no code" - you sound pretty sure of yourself there. It may even be the case ... right up until the point in time that it is not.

Right, there is no *public* code that I'm aware of, and I do hack on bitcoind for my own purposes, especially the mining components so I'm quite familiar with the code. As for "up until the point in time that it is not", well that's the direction *someone* should take with their code if they wish to not pursue other fixes for sigop scaling issues as a matter of priority then - if they wish to address the main reason core is against an instant block size increase. Also note that header first mining, which most Chinese pools do (AKA SPV/spy mining), and as proposed for BU, will have no idea what is in a block and can never choose the one with less sigops.

https://bitco.in/forum/threads/buip033-passed-parallel-validation.1545/

For those unwilling to click through:

BUIP033: Parallel Validation
Proposer: Peter Tschipper
Submitted on: 10/22/2016

Summary:

Essentially Parallel Validation is a simple concept. Rather than validating each block within the main processing thread, we instead create a separate thread to do the block validation. If more than one block arrives to be processed then we create yet another thread. There are currently up to 4 parallel block processing threads available making a big block DDOS attack impossible. Furthermore, if any attacker were somehow able to jam all 4 processing threads and another block arrived, then the processing for the largest block would be interrupted allowing the smaller block to proceed, unless the larger block or blocks have most proof of work. So only the most proof of work and smallest blocks will be allowed to finish in such
as case.

If there are multiple blocks processing at the same time, when one of the blocks wins the race to complete, then the other threads of processing are interrupted and the winner will be able to update the UTXO and advance the chain tip. Although the other blocks that were interrupted will still be stored on disk in the event of a re-org.

...