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

[Lauda]

You shouldn't be optimistic nor relying on speculative predictions of the future when it comes to Bitcoin's security.

then stop throwing speculations of things like 20mb blocks... or ur gangs other fake doomsdays of "gigabytes by midnight" "visa by tomorrow"

You are engaging in a discussion between another user and myself; we are free to discuss whatever we want and however we want. If you can't comprehend our discussion properly, then don't comment on it.

8mb upper limit and 2mb lower (dynamic) limit.

Where is the academic research backing up that 8 MB is safe as upper limit? For which time frame? How does the 2 MB grow to 8 MB? At what periods?

[1713507089]

1713507089

[1713507089]

1713507089

[1713507089]

1713507089

[1713507089]

1713507089

[franky1]

You shouldn't be optimistic nor relying on speculative predictions of the future when it comes to Bitcoin's security.

then stop throwing speculations of things like 20mb blocks... or ur gangs other fake doomsdays of "gigabytes by midnight" "visa by tomorrow"

You are engaging in a discussion between another user and myself; we are free to discuss whatever we want and however we want. If you can't comprehend our discussion properly, then don't comment on it.

if you want a private conversation between 2 people then go to Private message with them

8mb upper limit and 2mb lower (dynamic) limit.

Where is the academic research backing up that 8 MB is safe as upper limit? For which time frame? How does the 2 MB grow to 8 MB? At what periods?

even core deemed 8mb network safe but decided 4mb super safe.. go ask your buddies.
as for how...

are you forgetting the example of dynamics . i even drew you a picture to keep your concentration span open.

what you need to understand by having the limits is that the NODES flag what they are happy with and POOLS work below that.
meaning it wont get out of control of what general nodes can cope with. because the nodes are flagging it.

oh and i remember rusty russel (blockstream) had some stats of 8mb being fine. so try not to proclaim that 8mb is evil as its your gangs own agreement that 8mb is fine as a upper limit, but a preference for less as a lower limit

[Lauda]

if you want a private conversation between 2 people then go to Private message with them

You need to visit some courses in order to improve your faulty comprehension skills. We can discuss whenever we want and wherever we want.

even core deemed 8mb network safe but decided 4mb super safe.. go ask your buddies.

Core deemed "8 MB network safe"? Where?
Segwit 8 MB weight safe != 8 MB block size limit safe.

are you forgetting the example of dynamics . i even drew you a picture to keep your concentration span open

No. I'm asking you for the specifics of your proposal, but there are none apparently.

[AngryDwarf]

even core deemed 8mb network safe but decided 4mb super safe.. go ask your buddies.

Core deemed "8 MB network safe"? Where?
Segwit 8 MB weight safe != 8 MB block size limit safe.

So what is the technical reason for this to be the case?

[Lauda]

even core deemed 8mb network safe but decided 4mb super safe.. go ask your buddies.

Core deemed "8 MB network safe"? Where?
Segwit 8 MB weight safe != 8 MB block size limit safe.

So what is the technical reason for this to be the case?

For one (ignoring everything else): Linear sigops validation vs. quadratic validation.

[franky1]

For one (ignoring everything else): Linear sigops validation vs. quadratic validation.

lol segwit doesnt solve it!!

even after segwit activates native key users are not disarmed.
segwit only offers to disable people who voluntarily use segwit keys to perform quadratics by not having the quadratics problem in a segwit key tx signing.

it does not take the quadratics opportunity away from native key users.

reducing or keeping tx sigops limit at or below 16,000 sigops per block no matter what the blocksize is. ensures quadratic spammers cannot spam large sigop quadratic tx's
core 0.14: MAX_STANDARD_TX_SIGOPS_COST = MAX_BLOCK_SIGOPS_COST/5;
core 0.14: MAX_BLOCK_SIGOPS_COST = 80000;
meaning
core 0.14: MAX_STANDARD_TX_SIGOPS_COST = 16000

core 0.12: MAX_BLOCK_SIZE = 1000000;
core 0.12: MAX_BLOCK_SIGOPS = MAX_BLOCK_SIZE/50;
meaning
core 0.12: MAX_BLOCK_SIGOPS = 20000
core 0.12: MAX_STANDARD_TX_SIGOPS = MAX_BLOCK_SIGOPS/5;
meaning
core 0.12: MAX_STANDARD_TX_SIGOPS = 4000;

segwit actually allowed increasing tx sigops limit since v0.12 from 4000 to 16000 . while thinking that people will all be using segwit keys will be enough defense.. they have not thought about native users taking advantage.

oh and please dont instantly reply, untill you read the code.
read the code dont just reply "wrong because blockstream are kings"


edit: after reading lauda's instant reply below.. i actually pasted in and done the maths for him from cores own code...
lauda: read the code.

[Lauda]

lol segwit doesnt solve it!!

even after segwit activates native key users are not disarmed.
segwit only offers to disable people who voluntarily use segwit keys to perform quadratics by not having the quadratics problem in a segwit key tx signing.

You still don't understand how Segwit works?
1 MB quadratic hashing = no DoS risk AFAIK.
2 MB quadratic hashing -> DoS risk.
Segwit activated 2 MB block (Segwit TXs) = no DoS risk (linear hashing)
Segwit activated 1 MB block (old TXs) = no DoS risk at 1 MB (quadratic hashing).

reducing or keeping tx sigops limit at or below 16,000 sigops per block no matter what the blocksize is. ensures quadratic spammers cannot spam large sigop quadratic tx's

That.. doesn't actually solve it IIRC. Have you actually proposed this somewhere/done calculations or did you pull 16k out of thin air?

[AngryDwarf]

What is the reason for old tx's using quadratic hashing instead of linear hashing, and why is it considered safe with segwit if not for normal transactions?

[Lauda]

What is the reason for old tx's using quadratic hashing instead of linear hashing, and why is it considered safe with segwit if not for normal transactions?

That's the way that it is currently implemented; a known inefficiency (O(n^2) time). This is one of the reasons for which Segwit is quite beneficial. They packed up a lot of improvements at once.

[AngryDwarf]

What is the reason for old tx's using quadratic hashing instead of linear hashing, and why is it considered safe with segwit if not for normal transactions?

That's the way that it is currently implemented; a known inefficiency (O(n^2) time). This is one of the reasons for which Segwit is quite beneficial. They packed up a lot of improvements at once.

But is there any reason that this could not be implemented on the old tx's?

[Lauda]

But is there any reason that this could not be implemented on the old tx's?

Segwit introduces a new transaction type which can't be malleated as old TX's and which have linear scaling. I don't know what exactly is needed in order to make old TXs scale linearly as well. I'm going to assume that it may require a hard fork of some type.

[franky1]

But is there any reason that this could not be implemented on the old tx's?

Segwit introduces a new transaction type which can't be malleated as old TX's and which have linear scaling. I don't know what exactly is needed in order to make old TXs scale linearly as well. I'm going to assume that it may require a hard fork of some type.

sigop attack
v0.12 had a 4000 sigop per tx limit (read the code)
v0.14 had a 16000 sigop per tx limit (read the code)

so now check the code.
https://github.com/bitcoin/bitcoin/tree/0.14/src
core 0.14: MAX_BLOCK_SIGOPS_COST = 80000;
core 0.14: MAX_STANDARD_TX_SIGOPS_COST = MAX_BLOCK_SIGOPS_COST/5;
meaning
core 0.14: MAX_STANDARD_TX_SIGOPS_COST = 16000

https://github.com/bitcoin/bitcoin/tree/0.12/src
core 0.12: MAX_BLOCK_SIZE = 1000000;
core 0.12: MAX_BLOCK_SIGOPS = MAX_BLOCK_SIZE/50;
meaning
core 0.12: MAX_BLOCK_SIGOPS = 20000
core 0.12: MAX_STANDARD_TX_SIGOPS = MAX_BLOCK_SIGOPS/5;
meaning
core 0.12: MAX_STANDARD_TX_SIGOPS = 4000;
nothing stops a native tx from sigops spamming, you can only control how much spam is allowed

blockstream just thinks that people using segwit keys is enough defense they have not realised native users will stick to native keys

[AngryDwarf]

But is there any reason that this could not be implemented on the old tx's?

Segwit introduces a new transaction type which can't be malleated as old TX's and which have linear scaling. I don't know what exactly is needed in order to make old TXs scale linearly as well. I'm going to assume that it may require a hard fork of some type.

That is what I am wondering. If segwit was implemented as a hard fork, could the transaction malleation and quadratic sigops spam attack be solved for good. Could a native address automatically be a segwit address, negating the need for users to move UTXO's from native keys to segwit keys (which is going to cost a transaction fee and put unnecessary pressure on network capacity)?

[franky1]

That is what I am wondering. If segwit was implemented as a hard fork, could the transaction malleation and quadratic sigops spam attack be solved for good. Could a native address automatically be a segwit address, negating the need for users to move UTXO's from native keys to segwit keys (which is going to cost a transaction fee).

nope.

only real defense is keep limit per tx down........................ or blindly think malicious people will move to segwit keys to disarm themselves so everyone is using segwit keys

[Lauda]

-snip-
nothing stops a native tx from sigops spamming

You still don't understand it. Spamming with native keys after Segwit has been activated is useless. You can't DoS the network with them.

If segwit was implemented as a hard fork, could the transaction malleation and quadratic sigops spam attack be solved for good.

No. The difference between SFSF and SFHF is negligible (aside from hard forks being dangerous without consensus). In order for something like that happen, it would probably require a whole different BIP and approach.

Could a native address automatically be a segwit address, negating the need for users to move UTXO's from native keys to segwit keys (which is going to cost a transaction fee and put unnecessary pressure on network capacity)?

I doubt it. Even the other attempt at fixing malleability with a hard fork called Flextrans (from the Classic dev, i.e. a BTU supporter) doesn't do that.

[franky1]

-snip-
nothing stops a native tx from sigops spamming

You still don't understand it. Spamming with native keys after Segwit has been activated is useless. You can't DoS the network with them.

you can by filling the baseblock.

EG
a block based on v:0.12 fills the 1mb block with sigop tx's totallying 4000 sigops per tx
a block based on v:0.14 fills the 1mb block with sigop tx's totallying 16000 sigops per tx

edit: here is the clincher justdoing 5 tx's uses up the blocks max tx count.. no one else can be added

READ THE CODE. not the sales pitch by blockstreamers on reddit

[AngryDwarf]

-snip-
nothing stops a native tx from sigops spamming

You still don't understand it. Spamming with native keys after Segwit has been activated is useless. You can't DoS the network with them.

Is this because it will eventually only be possible to send to a segwit key, or is there some function in the two tier network that the SWSF creates?

If segwit was implemented as a hard fork, could the transaction malleation and quadratic sigops spam attack be solved for good.

No. The difference between SFSF and SFHF is negligible (aside from hard forks being dangerous without consensus). In order for something like that happen, it would probably require a whole different BIP and approach.

So does this mean a soft fork bypasses consensus?

Could a native address automatically be a segwit address, negating the need for users to move UTXO's from native keys to segwit keys (which is going to cost a transaction fee and put unnecessary pressure on network capacity)?

I doubt it. Even the other attempt at fixing malleability with a hard fork called Flextrans (from the Classic dev, i.e. a BTU supporter) doesn't do that.

Does flextrans require a new address key type as well?

[d5000]

If you don't believe that Bitcoin is digital gold, or you don't understand where the current value stems from, then you have to re-examine everything.

Maybe we've different opinions here. I believe Bitcoin's value comes mainly from its usability as a value transfer (and later, also value storage) platform for many use cases among many users ("network effect") and its advantage ahead of similar cryptocurrencies ("altcoins"). But that could lead to a long discussion, so here in this thread, let's focus on the block size issue.

In the case of IBD I think that in that in that "drastic future" most users will end downloading blockchain snapshots. That has some centralization risks but I think they are manageable. [...]

You shouldn't throw in centralizing aspects like they are trivial changes. The impact of something like that, and potential security concerns are probably not properly researched.

Then I would encourage research on that topic - I think it's inevitable at some point to provide "lighter" IBD procedures. Maybe Electrum and other light wallets could serve as objects in such a study.

We're obviously talking about end users with consumer-level equipment. Professional users that use servers in well-connected datacenters should have no problems with 20 MB blocks, I think.

I don't understand why you want me, as a user, to spend a lot of money to run my node in datacenters? I use Bitcoin Core for everything, node, wallet, cold storage.

No! Obviously the goal must be to allow end users running their node on PCs or notebooks. That was only a comment about professional equipment today - because the power of pro-equipment should be reached by consumer-level hardware at most a decade later. (Connectivity/bandwidth is another point, here you're right that mainly the upload bandwidth growth is a major bottleneck).

Edit: What upper limit would you consider realistic?

In what time frame? Next 5, 10 years?

Let's say 5 years, 10 years maybe is too far away.

(The 20 MB blocks were only an example to show the approximate relation between block size and possible user base, for now, I won't insist on this number)

[Lauda]

you can by filling the baseblock.

EG
a block based on v:0.12 fills the 1mb block with sigop tx's totallying 4000 sigops per tx
a block based on v:0.14 fills the 1mb block with sigop tx's totallying 16000 sigops per tx

Are you trying to say that Bitcoin can be DOS'ed at 1 MB now?

Is this because it will eventually only be possible to send to a segwit key, or is there some function in the two tier network that the SWSF creates?

No. You can refuse to use Segwit if you do not want to.

So does this mean a soft fork bypasses consensus?

No. Soft forks are backwards compatible, therefore mitigating the risk of a network split.

Does flextrans require a new address key type as well?

Yes.

I believe Bitcoin's value comes mainly from its usability ....
 But that could lead to a long discussion, so here in this thread, let's focus on the block size issue.

It sounded like I was talking to Roger Ver for a second, but okay.

Then I would encourage research on that topic - I think it's inevitable at some point to provide "lighter" IBD procedures. Maybe Electrum and other light wallets could serve as objects in such a study.

Then encourage it, but don't spread it around like it is trivial until we know for 'sure'.

No! Obviously the goal must be to allow end users running their node on PCs or notebooks. That was only a comment about professional equipment today - because the power of pro-equipment should be reached by consumer-level hardware at most a decade later. (Connectivity/bandwidth is another point, here you're right that mainly the upload bandwidth growth is a major bottleneck).

Noted. My bad.

Let's say 5 years, 10 years maybe is too far away.

(The 20 MB blocks were only an example to show the approximate relation between block size and possible user base, for now, I won't insist on this number)

We also need to determine whether we are talking about a block size in the traditional sense or a post-Segwit 'base + weight' size (as the "new" block size). Which is it?

[jbreher]

What is the reason for old tx's using quadratic hashing instead of linear hashing, and why is it considered safe with segwit if not for normal transactions?

That's the way that it is currently implemented; a known inefficiency (O(n^2) time). This is one of the reasons for which Segwit is quite beneficial. They packed up a lot of improvements at once.

But is there any reason that this could not be implemented on the old tx's?

The 'DoS' doesn't even require a protocol change to nullify. Indeed, there is a natural incentive already in the protocol that ensures it will never become a systemic problem. If large-time-to-verify-blocks ever became A Thing, miners will employ parallel validation. This will ensure that such large-time-to-verify-blocks will be orphaned by faster-to-verify-blocks.

Miners who gravitate to parallel validation will earn more income, and miners who do not employ parallel validation will become bankrupted over time. As will miners who create such DoS blocks.

This is already part of the protocol. No change is needed.