Last Time. In small words. Why 2MB impossible. Why Soft Fork. Why SegWit First..

[franky1]

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

<questioner2> is using up all 20k legacy treated as using up all 80k block sigops.
<sipa> a legacy sigop counts as 4 segwit sigops
<sipa> so 20k legacy sigops would fill a block
<sipa> just as 1MB of non-segwit transactions would fill the whole block, not leaving space for segwit transactions

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)

[The One]

What wrong with do both as hard fork? Wouldn't segwit hard fork be better than soft fork?

I assume if hard fork for both then there is a need to allow legacy txs to be converted at a later date. ie. 10 years.

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:

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.

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

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?

[AngryDwarf]

A soft fork is always better if possible because of the "danger of two competing blockchains"

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.

Wouldn't segwit hard fork be better than 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.

Maybe they can be prohibited and all people owning bitcoins on non-Segwit keys have to transfer them to Segwit addresses.

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.

[lurker10]

Last Time. In small words. Why 2MB impossible. Why Soft Fork. Why SegWit First..

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

[Lauda]

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.

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.

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

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)

Therefore, you were wrong and I was write.

yes lauda, cludgy code can lead to semantics games which core devotee's love.

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

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

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

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

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.

[hobbes]

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.

Wouldn't segwit hard fork be better than soft fork?

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

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.

[AngryDwarf]

Wouldn't segwit hard fork be better than soft fork?

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

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.

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.

[Lauda]

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

Absolute bollocks. If SWSF becomes a contentious soft fork, you would still need replay protection.

Correct.

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.

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.

It cannot be reversed since it would be an 'anyonecanspend' free-for-all.

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.

[Minecache]

Ok.

Jhonny's got 3 threads up about mean nasty Core and how they are destroying Bitcoin.

Here is my LAST attempt at explaining 'what is going on' rationally.

1) There is a 'buglet' in Bitcoin that means that you can construct a TXN that uses a lot of time to process / check. Let's not worry about what it is but agree that it exists. The larger the blocks the easier it is to construct this TXN, and IF we had 2MB blocks, right now, you could bring down the network. This issue is fixed with SeqWit. So Core thought, let's introduce SW first, THEN we can make the blocksize bigger. Safely.

2) Soft fork vs Hard-fork. The 'poison pill' Jhonny and Franky keep ranting about is actually because CORE thought that NOT forcing you to upgrade was a GOOD thing. This is a Soft Fork. It means if you don't upgrade - no problem. No Split. We all carry on as before, and all the clever SegWit shit will happen in a way that doesn't affect the old nodes. Safely.

3) Bigger Blocks would ALREADY be here IF we had just upgraded to segwit 6 fucking months ago. This ridiculous stalemate is what is causing this total cluster fuck of a situation.  Once we get SegWit.. oh mama.. ALL the clever things people have dreamed about can START to happen. AND Bigger Blocks!.. Safely.

..

If you are saying - NO! You Bast***ds! We want to jump ship to BU, which has a new consensus model, and software that crashes every 3 weeks, you are NOT acting SAFELY. Fact.

CORE are NOT your enemy.

.. Wake UP! (My New Chant..  ) .. before it's toooo late..

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

[The One]

Ok.

Jhonny's got 3 threads up about mean nasty Core and how they are destroying Bitcoin.

Here is my LAST attempt at explaining 'what is going on' rationally.

1) There is a 'buglet' in Bitcoin that means that you can construct a TXN that uses a lot of time to process / check. Let's not worry about what it is but agree that it exists. The larger the blocks the easier it is to construct this TXN, and IF we had 2MB blocks, right now, you could bring down the network. This issue is fixed with SeqWit. So Core thought, let's introduce SW first, THEN we can make the blocksize bigger. Safely.

2) Soft fork vs Hard-fork. The 'poison pill' Jhonny and Franky keep ranting about is actually because CORE thought that NOT forcing you to upgrade was a GOOD thing. This is a Soft Fork. It means if you don't upgrade - no problem. No Split. We all carry on as before, and all the clever SegWit shit will happen in a way that doesn't affect the old nodes. Safely.

3) Bigger Blocks would ALREADY be here IF we had just upgraded to segwit 6 fucking months ago. This ridiculous stalemate is what is causing this total cluster fuck of a situation.  Once we get SegWit.. oh mama.. ALL the clever things people have dreamed about can START to happen. AND Bigger Blocks!.. Safely.

..

If you are saying - NO! You Bast***ds! We want to jump ship to BU, which has a new consensus model, and software that crashes every 3 weeks, you are NOT acting SAFELY. Fact.

CORE are NOT your enemy.

.. Wake UP! (My New Chant..  ) .. before it's toooo late..

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

LTC is nothing but a pump.

[franky1]

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.

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

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

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

"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

[jonald_fyookball]

Ok.

Jhonny's got 3 threads up about mean nasty Core and how they are destroying Bitcoin.

Here is my LAST attempt at explaining 'what is going on' rationally.

1) There is a 'buglet' in Bitcoin that means that you can construct a TXN that uses a lot of time to process / check. Let's not worry about what it is but agree that it exists. The larger the blocks the easier it is to construct this TXN, and IF we had 2MB blocks, right now, you could bring down the network. This issue is fixed with SeqWit. So Core thought, let's introduce SW first, THEN we can make the blocksize bigger. Safely.

2) Soft fork vs Hard-fork. The 'poison pill' Jhonny and Franky keep ranting about is actually because CORE thought that NOT forcing you to upgrade was a GOOD thing. This is a Soft Fork. It means if you don't upgrade - no problem. No Split. We all carry on as before, and all the clever SegWit shit will happen in a way that doesn't affect the old nodes. Safely.

3) Bigger Blocks would ALREADY be here IF we had just upgraded to segwit 6 fucking months ago. This ridiculous stalemate is what is causing this total cluster fuck of a situation.  Once we get SegWit.. oh mama.. ALL the clever things people have dreamed about can START to happen. AND Bigger Blocks!.. Safely.

..

If you are saying - NO! You Bast***ds! We want to jump ship to BU, which has a new consensus model, and software that crashes every 3 weeks, you are NOT acting SAFELY. Fact.

CORE are NOT your enemy.

.. Wake UP! (My New Chant..  ) .. before it's toooo late..

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

LTC is nothing but a pump.

started out as sw pump but when coinbase adopted it, could actually get some more use, that is much more real fundamental value than sw.

[Amph]

Which alts have big blocks without segwit?

this is the only one, pretty new still https://bitcointalk.org/index.php?topic=1883902.0, has segwit and it's a clone of bitcoin in everything with 20MB block

but they don't need that of course their transactions per day can't dream to be on par with bitcoin, and there are no ddos or spam attack there

[Lauda]

this is the only one, pretty new still https://bitcointalk.org/index.php?topic=1883902.0, has segwit and it's a clone of bitcoin in everything with 20MB block

This is incorrect. There are 4 that already have activated it or are just about to activate it:
1) Groestlcoin: https://bitcointalk.org/index.php?topic=525926.0
2) Vertcoin (will activate in a few days due to pressure via UASF): https://bitcointalk.org/index.php?topic=404364.0
3) Litecoin: Activates in a few days too.
4) Digibyte: https://segwit.digiexplorer.info/

[spartacusrex]

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.

This is a cool explanation.

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

- snip -

So they look exactly the same during a chain split.

But there is no chain split on a soft fork.. That's the WHOLE point ?

started out as sw pump but when coinbase adopted it, could actually get some more use, that is much more real fundamental value than sw.

LOL.. pls.. Give credit where it's due.. Maybe CoinBase added it BECAUSE of SW..  or at least Coinbase were convinced into adding it, becuase of SW.

It's not as bad as you make out.. Come and Join us! (If you want a $10k BTC.. that is.).. still plenty of room..

[AngryDwarf]

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.

This is a cool explanation.

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

- snip -

So they look exactly the same during a chain split.

But there is no chain split on a soft fork.. That's the WHOLE point ?

There is a chain split if there is a division of hash power between old and new rule sets. The only difference is that a soft fork is backwards compatible with older node software, whereas a hard fork isn't.

In the event of a successful soft fork, older nodes continue to operate as normal.
In the event of a successful hard fork, older nodes become unsynced and have to upgrade.

In the event of a contentious fork, hard of soft, it becomes an economically damaging clusterfuck until the winning fork is determined (the longest chain) or a bilateral split occurs (the minority chain implements replay protection).

A hard fork which is hacked as a soft fork (where backwards compatibility is an illusionary hack), the soft fork functionality has to be sufficiently locked in before activation to prevent the backwards compatibility hacks from being exploited. In this case, an older node appears to operate as normal, but it really isn't because it is being fooled by filtered hacked data.

[jubalix]

people are bored of this::

A plague on both your houses::

do both segwit and 2MB

LTC now provides a credible test bed and alternative.

BTC is shooting itself in the foot, did you notice how it has lost dominance so much, LTC has just done what 30% in 1 or 2 days.

The only thing  I don't quite get is it that miners want larger blocks so they can collect more fee's but the LN + segwit will mean they face much less fees for miners?

[spartacusrex]

people are bored of this::

Totally..

The only thing  I don't quite get is it that miners want larger blocks so they can collect more fee's but the LN + segwit will mean they face much less fees for miners?

As soon as the blocks aren't full.. the fee market will collapse. Any fee will do.

[jubalix]

people are bored of this::

Totally..

The only thing  I don't quite get is it that miners want larger blocks so they can collect more fee's but the LN + segwit will mean they face much less fees for miners?

As soon as the blocks aren't full.. the fee market will collapse. Any fee will do.

no what I mean is as the block insensitive drops and (if) usage goes up the block reward would compensate miners.

so a 10 mb  x  full use at 1/5 fees would give more 2 x more at 1 unit of fee in 1mb block size so it would word for usage and miners.

Now is it the case that LN would allow all of the extra fees of chain, and so make BTC less attractive miners and keep fees high?

[thejaytiesto]

Ok.

Jhonny's got 3 threads up about mean nasty Core and how they are destroying Bitcoin.

Here is my LAST attempt at explaining 'what is going on' rationally.

1) There is a 'buglet' in Bitcoin that means that you can construct a TXN that uses a lot of time to process / check. Let's not worry about what it is but agree that it exists. The larger the blocks the easier it is to construct this TXN, and IF we had 2MB blocks, right now, you could bring down the network. This issue is fixed with SeqWit. So Core thought, let's introduce SW first, THEN we can make the blocksize bigger. Safely.

2) Soft fork vs Hard-fork. The 'poison pill' Jhonny and Franky keep ranting about is actually because CORE thought that NOT forcing you to upgrade was a GOOD thing. This is a Soft Fork. It means if you don't upgrade - no problem. No Split. We all carry on as before, and all the clever SegWit shit will happen in a way that doesn't affect the old nodes. Safely.

3) Bigger Blocks would ALREADY be here IF we had just upgraded to segwit 6 fucking months ago. This ridiculous stalemate is what is causing this total cluster fuck of a situation.  Once we get SegWit.. oh mama.. ALL the clever things people have dreamed about can START to happen. AND Bigger Blocks!.. Safely.

..

If you are saying - NO! You Bast***ds! We want to jump ship to BU, which has a new consensus model, and software that crashes every 3 weeks, you are NOT acting SAFELY. Fact.

CORE are NOT your enemy.

.. Wake UP! (My New Chant..  ) .. before it's toooo late..

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

LTC is nothing but a pump.

started out as sw pump but when coinbase adopted it, could actually get some more use, that is much more real fundamental value than sw.

It all started because of segwit. Without segwit, LTC would be rotting in stagnation, but thanks to segwit, lightning network developers are going to move there, so LTC will get tons of features that are impossible without segwit. Exchanges will show interest and LTC will solidify as a solid altcoin.

Meanwhile BTC remains as it is today due miners not following economic majority. I believe sooner or later the balance will fall into segwit, but until then, LTC remains bullish. There will be ups and downs anyway, but this is no longer an isolated pump and dump, the fundamentals are clear.