Topic: Last Time. In small words. Why 2MB impossible. Why Soft Fork. Why SegWit First.. - page 6. (Read 6499 times)

core are the only ones wanting to create a bilateral or contentious split. core have been the ones screaming for anything not core to split away..
so if cores code causes a bilateral/contentious split (BIP9 and UASF has that ability) then core should be the one that adds "replay protection" if core was to decide to pull the split pin. in short core should take the heat. (and yes it is possible)

all other implementations want to stay together as a diverse per network. so why the hell should they be told to add in code and then be the ones that move away to allow core to have a dominant tier network.

ok lets word it this way..
anyone abstaining from segwit by just sticking with 0.12 rules being told to program a new version with replay protection..
yet core who have changed the code refuse to add in code to avoid risks of replay protection. (facepalm)

---

lastly if you dont think core code is cludgy.
ask yourself why the cludgy maths of native sigops is in line 4xx of a .cpp file and not in a header files(.h) such as policy/consensus.
and why the cludgy maths requires reading four different files instead of just having it all in a single header file as a set variable (easy to do)

and when it comes to changing from a 2merkle block to a 1 merkle block (which core pretends to promise later)... its not a simple edit of one file to change the metrics. but requires yet another big rewrite to undo the cludge of creating their 2merkle block

if you done a cs college course it wont teach you how to read the cludge any better. it would teach you how to read c++ and then recognise cludge when you see it.. because devs are not doing the basics of arranging variables in a logical way.

in short if the current devs of core/blockstream jumped over to litecoin or hyper ledger and retired their desire to work on bitcoin (devs are not immortal, their interests do change) the cludge they leave behind makes it doubly as hard to sort out for anyone new coming in.

---

your devotion to devs without knowing c++ reveals more about your lack of understanding bitcoin, but your adoration of a temporary team and trust that their word twisting should be good enough.

P.S im laughing at how you took the glory of 'explaining it'.. yet you were not 'questioner2' in IRC. and if you read the entire conversation then you would see that segwit does not 'fix' things. it just twists things

you try admitting it but prefer to word twist it

"Segwit wouldn't change that." = "segwit doesnt fix that"

so much cludge while keeping spam attack vectors open.

oh and i did admit i was wrong about the quadratic risk not being worse while at a 2merkle implementation(using math cludge). its no better either.
its just a maths game. of faking how many sigops it really does. by multiplying the rule.
i laugh at a 'sigopcount' variable that gets told not to count real sigops but hold a number thats not related to real sigops count, but a math cludge

and when segwit becomes a 1 merkle block. (removing the witness factor would be part of that) it will become a problem. which you have shown a bit of worry over.. but would not outright admit

---

why waste 2 years on the cludge of a 2 merkle with a promise of a 1 merkle within the year after..(3 year wasted)
when they could have done a 1 merkle initially with all the other features users want and have the 1 year grace period.(1 year and united community)

why even threaten the bilateral/controversial split for a 2 merkle and then promise a 1 merkle a year after doing a split. theres just no logic to it relating to keeping a diverse peer network.. but alot of logic when seeing the desire of a dominant blockstream owned tier network

LTC is nothing but a pump.

Well said. Just look at LTC and imagine what would happen to BTC price.

You are welcome. You shouldn't believe the Segwit == doomsday propaganda from randoms when the super majority of developers/experts are in full support of it anyhow.

Correct.

BU refused to add that to their implementation, which led us to where we are today. If one is so confident about their position, a bilateral split rather than a hostile split with no replay protection is the right way to go. As it currently stands, without replay protection a split would cause a lot of daamage.

A lot of soft forks are "anyonecanspend" for nodes that haven't updated. Segwit is no different to this. Try reversing P2SH as a comparison (the difference being that SW has another UTXO set); it is not impossible, just *very hard*. This is just related to the propaganda that is exaggerating the downsides of SW, which have been clearly written out on the Bitcoin Core website.

Absolute bollocks. If SWSF becomes a contentious soft fork, you would still need replay protection. When there is a contentious fork, it makes no difference if that fork is hard or soft. You only need to implement replay protection if you want to cause a bilateral split, otherwise people will eventually unite behind a single chain, the one which has the most proof of work. The uniting behind one chain will happen sooner rather than later otherwise it is a complete clusterfuck.
Segwit has its merits. However as a soft fork it is a dangerous software engineering hack which will burden the protocol forever. It cannot be reversed since it would be an 'anyonecanspend' free-for-all. And the potential for future developers to fuck this up is quite high. That's right, the high lords who developed segwit as a soft fork won't live forever.

Thanks everybody for the entertaining discussion in this thread, I learned something new about SegWit (WITNESS_SCALE_FACTOR). Thanks Lauda (and Sipa on IRC) for explaining.

You are wrong here. Exchanges pointed out the need for replay protection for even slightly contentious hardforks a while ago. Replay protection is quite difficult and would cause more technical debt than SWSF. This makes SWSF the currently superior solution.

What if nobody attempts to create such block in order to evaluate it? Are "we" going to spam the main network ourselves for testing purposes? In regards to forcing people into Segwit addresses: While everyone using SW keys would be an optimal future, forcing them into doing this may set a dangerous precedent.

I don't see why we'd need a potential 4 MB block (2 MB + SW) for standard transactions. The mempool would be empty for quite a while.

Therefore, you were wrong and I was write.

It is neither "cludgy" code nor "cludgy" mathetmatics, you just don't understand it. That's all.

Nobody ever claimed that it did, which makes this part of your post useless.

No. 5 legacy TX with 4k each fill up the block which is "normal" behavior today, and Segwit wouldn't change that.

---

Learn to admit being wrong, otherwise it's pointless for you to even attempt any kind of discussion.

Everything you said is noise.
True reason is: because CORE wants it this way.

There is no difference between the dangers of a soft fork and a hard fork.

In the event of a soft fork we have:
1.) The old chain exists with a more permissive set of rules.
2.) The new chain exists with a more restrictive set of rules.

In a hard fork we have:
1.) The old chain exists with a more restrictive set of rules.
2.) The new chain exists with a more permissive set of rules.

So they look exactly the same during a chain split.

The only difference is that a soft fork is backwards compatible because its more restrictive set of rules.

However, segwit expands the protocol (the definition of a hard fork), by using software kludges to make old nodes think they are compatible, and so is packaged as a soft fork.


Yes.
1.) We don't know how big a full block might be. It might be anywhere between 1MB and 4MB depending on usage. It is non deterministic. As a hard fork with 1:1 weighting this can be eliminated.
2.) There will be less technical debt by implementing segwit as a hard fork. The software kludges implementing it as a soft fork also creates huge maintenance risks in the future (segwit keys are 'anyonecanspend').
3.) All nodes will be able to perform their job properly. Segwit is not really backwards compatible, it's just an illusion created by the soft fork kludges feeding the old nodes filtered data and creates a two-tier node network.


I would consider it might be possible to make them eventually "send only" addresses after a grace period which allows users to change any known public receiving addresses.

---

I am against segwit as a soft fork. It should be a hard fork by its very nature and sets a dangerous precedent by using software kludges to package it as a soft fork in an illusionary manner. As a hard fork, it is possible that more could be achieved in this extensive protocol upgrade since it would not have design restrictions based on the imposed soft fork illusion.

Can't do that.

However maybe...
On an isolated network with full blockchain - do a soft fork. If it works then make multi copies of the blockchain. Required a huge degree of trusted parties.

Do a hard fork as normal and everyone goes seggy.

Those who aren't aware would still be protected based on the multi copies of the blockchain.

Say 10 years time someone pops up and wonder where their bitcoins are. Trusted parties can use one of the multi copies of the blockchain. to allow the person to transfer his legacy coins to seggy hard fork blockchain.

Would that work?

interestingly.

a native(legacy) tx of 4k txsigops is treated as 16k txsigops in core v0.14 due to the WITNESS_SCALE_FACTOR (which is 4x)

so to correct myself about worry of propagation delay, native(legacy) tx does not/cannot perform 16k actual CPU intensive sigops. its still only 4000 real CPU intensive operations(just treated as 16k after the fact purely for cludgy mathematics of filling the limit)
yes lauda, cludgy code can lead to semantics games which core devotee's love.

but segwit still doesnt make the native keys disarmed from the 4k CPU intensive time that existed in 0.12 either
so segwit for CPU intensive purposes is no better or worse

---

however there is still the 5tx's to fill the 80k issue
where it doesnt need to be 16k/tx of actual sigops.. only 4k/tx..
that means 5tx's can hold up and prevent even segwit transactions utilising the 3mb weight area because those 5tx's have used up all of the block sigops due to all the cludgy maths of 80/5/4

---

tl:dr;
ok so segwit doesnt make native tx's able to be more quadratically CPU intensive. to cause more propagation delay
but it doesnt make native tx's any less quadratically CPU intensive than v0.12 (still 4k)

it doesnt stop native tx's making just 5tx's to fill a block (cludgy maths sigop count limit)

so to amend it - 3 attack vectors
1. just fill a block of native data to 1mb (data/byte bloat fill attack)
2. use up the block sigops limit with say 1000tx of just 20sigops each for example (cludgy maths sigopcount fill attack)
3. use up the block sigops limit with say 5tx of just 4,000sigops each for example (cludgy maths sigopcount fill attack)

A soft fork is always better if possible because of the "danger of two competing blockchains", and I don't see how a hard fork can solve the quadratic hashing problem here. (edited, see below) But legacy transactions cannot be permitted in an unrestricted way after the 2MB activation like today, as Lauda correctly points out:


So the "grace period" between the Segwit activation and the 2MB activation must be as long as possible (~1 year) to correctly evaluate the danger of "full block spam" (in this case "4 MB block spam"). Edit: And the 2 MB hard fork should contain also a restriction for legacy transactions. Maybe they can be prohibited and all people owning bitcoins on non-Segwit keys have to transfer them to Segwit addresses. But we don't have to do that already when the Segwit soft fork is activated (so we don't need a hard fork then), the 2 MB hard fork 1 year later would be early enough.

Regarding the possible 8 MB block spam, as I have already discussed in another thread, I would support going forward slower (first go to 1,5 MB/6 MB max. after a year and then to 2 MB after 1-2 years more if everything works right).

I agree they SHOULD but as I said there is no way to reliably make it so they MUST.

Of course miners are choosing what goes into a block - that's precisely what mining is; mining transactions into the blockchain. You can't mine only "verified" transactions because the process of mining IS the verification.

Which is not something that I've ever said. Learn to read.

---

I'd be very surprised if either one of you would admit to being wrong considering my previous post. Let's see whether we are really talking about "open-minded" individuals or "closed-minded" shills as suspected earlier.

So it appears that this limit is used in validation.cpp.  Why is Lauda saying its only for segwit?  What a troll.

Because of your nonsense, someone actually asked on IRC about this (it wasn't me):

---

Tl;dr; + ELI5: You can't use more than 20k sigops per block using native keys after Segwit.
Bonus: I was right, and franky was wrong as usual.

yep. 4mb single block would be better for everyone..
but the other thing is that the hype about a compromise of 2mb+segwit.. was released on the 1st of april...
so although 4mb block where native and segwit can co-mingle in one merkle block(no block within block) would be better
im taking a pinch of salt as to if 'core' would actually really agree to code such a version of even 2mb+segwit for people to download.

Surely 4mb would be better?

I didn't say 'which' but any validated txs. As long there are txs in the mempool, then the block should fill up until there is no txs in the mempool or block is over 95% full, for example. Empty blocks when there are no txs is fine but when there are thousands of txs waiting to be confirmed is madness.

Isn't that what the miners are already doing ?

It does not mean what you think it means. Ask any developer that is actually working on the code.

I don't see how 2 MB + Segwit would avoid the quadratic problem on it's own. It needs to have some constraints on native transactions in order to work. Additionally, this creates a possibility of almost 8 MB blocks (if someone wanted to spam the network with this).