Pages:
Author

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

legendary
Activity: 4270
Merit: 4534
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
sr. member
Activity: 476
Merit: 501
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)?
legendary
Activity: 4270
Merit: 4534
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
legendary
Activity: 2674
Merit: 2965
Terminated.
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.
sr. member
Activity: 476
Merit: 501
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?
legendary
Activity: 2674
Merit: 2965
Terminated.
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.
sr. member
Activity: 476
Merit: 501
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?
legendary
Activity: 2674
Merit: 2965
Terminated.
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?
legendary
Activity: 4270
Merit: 4534
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.
legendary
Activity: 2674
Merit: 2965
Terminated.
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.
sr. member
Activity: 476
Merit: 501
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?
legendary
Activity: 2674
Merit: 2965
Terminated.
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.
legendary
Activity: 4270
Merit: 4534
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
legendary
Activity: 2674
Merit: 2965
Terminated.
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?
legendary
Activity: 4270
Merit: 4534
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"

as thats speculative predictions of the future.

stick to rational REAL abilities now

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

that gives a while to reassess the 8mb over time.
rather that waiting and halting growth for years due to fears of 20mb blocks.

legendary
Activity: 2674
Merit: 2965
Terminated.
@Lauda: Maybe I'm overly optimistic about technology development in the coming 10 years. (A less than 160 million possible user base for 2027 would mean a pretty low "cap" for Bitcoin's price imho, as I don't believe in the "digital gold" thing and even using LN you need some on-chain transactions. A not small part of the population of this forum thinks that Bitcoin will replace the whole fiat money next year or so Wink ).
You shouldn't be optimistic nor relying on speculative predictions of the future when it comes to Bitcoin's security. You need to be conservative to say the least. 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.

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. Also reindexing maybe won't be a thing low-end-equipment users would do regularly - they would simply redownload a snapshot.
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.

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.

Edit: What upper limit would you consider realistic?
In what time frame? Next 5, 10 years?
sr. member
Activity: 476
Merit: 501
If you name is inherently insulting to you, you should take responsibility for choosing it

I could make a word play on your username, but I assume you would rather divert this into a slanging match, rather than add to the technical discussion.

So like I say, you can choose to explain it for the benefit of other people, or you can choose not to.
legendary
Activity: 3430
Merit: 3079
If you name is inherently insulting to you, you should take responsibility for choosing it
sr. member
Activity: 476
Merit: 501
You can't expect good will from those to whom you demonstrate bad will, Dwarf

Calling me Dwarf instead of AngryDwarf might be perceived as insult if it was to come from an Elf. Maybe its perception of tone. Neither did I directly say you was throwing insults, you implied it from me stating it came from pro-segwit people.

Internet forums are not for the thin skinned.

If you don't want to answer the question for me, you could answer it for the benefit of other people.
legendary
Activity: 3430
Merit: 3079
You can't expect good will from those to whom you demonstrate bad will, Dwarf
Pages:
Jump to: