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

[Amph]

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/

he asked for an altcoin with more than 1 mb block, nothing is incorrect, bitcore is the only one with more than 1 mb block, it has 20 mb

what you listed are coins with segwit only, not bigger blocks

[Lauda]

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.

Jonald is a paid joke. There is no way that CoinBase would have added LTC without SW. With SW and LN, LTC has a potential future in which you can transact both Bitcoin and Litecoin via the same Lightning Network!

he asked for an altcoin with more than 1 mb block, nothing is incorrect, bitcore is the only one with more than 1 mb block, it has 20 mb

Segwit == block size > 1 MB.

what you listed are coins with segwit only, not bigger blocks

The faulty understanding is that Segwit != bigger blocks. Just because it handles data differently, that doesn't mean that the block aren't bigger.

[franky1]

There is no way that CoinBase would have added LTC without SW.

so charlie Lee working at coinbase has nothing to do with it.

[franky1]

Segwit == block size > 1 MB.

The faulty understanding is that Segwit != bigger blocks. Just because it handles data differently, that doesn't mean that the block aren't bigger.

segwit only = bigger block ONLY IF:
1. users move funds to segwit keys
2. segwit keys get accepted into blocks
3. native spammers dont fill the base block with native spam

[BillyBobZorton]

There is no way that CoinBase would have added LTC without SW.

so charlie Lee working at coinbase has nothing to do with it.

Obviously it helps, but without segwit LTC would have no selling point. Who wants a BTC clone with prospects to get anything new done? that was LTC before segwit. In this post-segwit reality, LTC can shine to unforeseen prices thanks to what segwit being activated means, this creates a big bullish pressure that Coinbase can cater for.
But of course, anti segwit FUDsters will never admit segwit drives the value of a coin up objectively speaking.

[Lauda]

There is no way that CoinBase would have added LTC without SW.

so charlie Lee working at coinbase has nothing to do with it.

Straw man argument, again.

segwit only = bigger block ONLY IF:
1. users move funds to segwit keys

Which is guaranteed to happen

2. segwit keys get accepted into blocks
3. native spammers dont fill the base block with native spam

Those two can be rewritten into one point. The obvious solution, which I've been telling you about is, prioritizing native -> SW and SW -> SW transactions.

[Amph]

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.

Jonald is a paid joke. There is no way that CoinBase would have added LTC without SW. With SW and LN, LTC has a potential future in which you can transact both Bitcoin and Litecoin via the same Lightning Network!

he asked for an altcoin with more than 1 mb block, nothing is incorrect, bitcore is the only one with more than 1 mb block, it has 20 mb

Segwit == block size > 1 MB.

what you listed are coins with segwit only, not bigger blocks

The faulty understanding is that Segwit != bigger blocks. Just because it handles data differently, that doesn't mean that the block aren't bigger.

yeah i know but he asked specifically for a coins without segwit that use a block size more than 1 MB, just to see if other coin are in the line with BU probably....

[franky1]

Those two can be rewritten into one point. The obvious solution, which I've been telling you about is, prioritizing native -> SW and SW -> SW transactions.

segwit only = bigger block ONLY IF:
1. users move funds to segwit keys

Which is guaranteed to happen

LOL guaranteed. LOL

do pools prioritise LEAN transactions to allow more transactions in.. nope
do pools prioritise mature transactions to evade spammers.. nope (spam: those that intentionally respend every block)
do pools prioritise transactions with fee.. nope (empty blocks/btcc zero fee confirm)

you HOPE and have FAITH that pools will.. but 65% of pools are abstaining or saying no to wanting to prioritise segwit as a protocol. so they are not going to prioritise segwit transactions.

in short. no guarantee, no fix. just gesture, half expectations and faith
much like the expectation of
"if pools prioritise lean tx's we can get 7tx/s 2009-2017".. yet in last 8 years never had a block of 7tx/s

yes on testnet it can be seen but thats test net where 1 person is creating the tx's in a certain agenda display of expectation.. when dealing with real world people using it for real world needs. reality does not reach expectation or hope

P.S your "2.1mb" expectation is the exact same 7tx/s expectation that has been promoted since 2009.. but never reached
its all if's maybe's half gestures hopes faith trust.. not actual real rules that enforce it

[hobbes]

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.

Maybe it was not clear but of course I am assuming a significant hashrate majority. Then there is no need for replay protection because the chain will always converge to the new chain. If you still disagree please explain.

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.

Of course a hardfork is cleaner but the amount of tech debt the softfork causes is acceptable and it more than makes up for it in risk mitigation.

[d5000]

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.

Can't do that.

Why not? In a hard fork, in theory consensus rules can be changed without restrictions.

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

I don't really understand your proposal. Do you mean this for the case "legacy transactions are prohibited" there is a backup for non-upgraded nodes? Well, the idea was to "prohibit legacy transactions", not "prohibit legacy keys" - it would be forever be possible to transfer them to Segwit keys - otherwise, many people would lose their Bitcoins. I think that's what AngryDwarf said here and is also what I meant (I perhaps wasn't precise enough):

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.

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.
[...]
The only difference is that a soft fork is backwards compatible because its more restrictive set of rules.

From my understanding, in a hard fork for unupgraded nodes it would not be possible to follow the new chain anymore. Even if 95% of all miners agree on a hard fork, unupgraded non-mining nodes would split away and couldn't use Bitcoin anymore in a safe way. In a soft fork with a 95% or even 85% approval by miners the minority unupgraded chain would always be orphaned and no node would follow it.

That's why a hard fork would need much more preparation time. A soft fork could be deployed in a few months, a hard fork needs a year or so to ensure all relevant nodes are upgraded.
(If that's wrong correct me.)

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

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?

We could spam the testnet for that if nobody does it. Your point is, I suppose, that someone would hold back spam attacks until the maximal block size becomes big enough (e.g. 8 MB)?

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.

Wouldn't then the quadratic hashing time problem be unsolved forever? Because the problem seems to be the danger of spam attacks based on that problem, and if non-Segwit tx are possible then a spammer obviously will use them. I think as long as it is possible to transfer non-segwit outputs to segwit keys (non-segwit to non-segwit would be the possibility that would have to be prohibited) the precedent is not dangerous.

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.

2 MB + SW in my idea would occur in >2019. If Bitcoin's growth continues at the same speed than until now (30-50% transaction volume growth per year) then we could see pretty full mempools then. OK, maybe not if sidechains or extension blocks are functioning.

[Lauda]

do pools prioritise LEAN transactions to allow more transactions in.. nope

Because this is equal to censorship. Additionally, the average TX size is well above the "lean transaction size".

do pools prioritise mature transactions to evade spammers.. nope (spam: those that intentionally respend every block)

Immature transactions does not necessary equal to spam.

do pools prioritise transactions with fee.. nope (empty blocks/btcc zero fee confirm)

Yes they do (not always obviously). You have no argument as usual.

We could spam the testnet for that if nobody does it.

That does not equal to real world testing unless you can mimic the whole network on a smaller scale.

Your point is, I suppose, that someone would hold back spam attacks until the maximal block size becomes big enough (e.g. 8 MB)?

They could hold back or spam right away. Either way, an attack vector must not be left in the air at any cost.

Wouldn't then the quadratic hashing time problem be unsolved forever? Because the problem seems to be the danger of spam attacks based on that problem, and if non-Segwit tx are possible then a spammer obviously will use them. I think as long as it is possible to transfer non-segwit outputs to segwit keys (non-segwit to non-segwit would be the possibility that would have to be prohibited) the precedent is not dangerous.

Yes, the quadratic hashing problem will exist until it gets sorted out via a hard fork (see the Flextrans proposal, which is a HF proposal similar to SW but vastly inferior even though the incompetent devs claim its superiority). As I've told franky, pools can and will prioritize native-to-segwit and segwit-to-segwit transactions in the case of native-to-native spam attacks.

2 MB + SW in my idea would occur in >2019. If Bitcoin's growth continues at the same speed than until now (30-50% transaction volume growth per year) then we could see pretty full mempools then. OK, maybe not if sidechains or extension blocks are functioning.

I don't agree with the instant jumping visions anyways. Why not 1.2 MB now, 1.4 MB next year and so on, until we hit 2 MB? These kind of approaches make more sense to me.

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

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.

Wait and see. Txs per day would need to go up dramatically in order to justify its value and whether segwit is successful. At the moment segwit doesn't help litecoin at all.
If adoption rate goes up then great. So it's wait and see.

[Lauda]

At the moment segwit doesn't help litecoin at all.

This is nonsense. Segwit wasn't designed as a capacity increase. The capacity increase is a side-effect of it. List of benefits:

Malleability Fixes
Linear scaling of sighash operations
Signing of input values
Increased security for multisig via pay-to-script-hash (P2SH)
Script versioning
Reducing UTXO growth
Efficiency gains when not verifying signatures

Source: https://bitcoincore.org/en/2016/01/26/segwit-benefits/

[The One]

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?

The point of the "civil war" is that intelligent people don't want segwit and/or LN.

So just do a 2mb then 4 then 6 then 8... activated when certain block number is reached... or whatever.

[The One]

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.

Can't do that.

Why not? In a hard fork, in theory consensus rules can be changed without restrictions.

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

I don't really understand your proposal. Do you mean this for the case "legacy transactions are prohibited" there is a backup for non-upgraded nodes? Well, the idea was to "prohibit legacy transactions", not "prohibit legacy keys" - it would be forever be possible to transfer them to Segwit keys - otherwise, many people would lose their Bitcoins. I think that's what AngryDwarf said here and is also what I meant (I perhaps wasn't precise enough):

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 was concern about those who hold bitcoin but do not follow the news daily. Maybe those will ignore bitcoin and wait 10 years. What happens then when they find their bitcoin is "prohibited"?

[The One]

At the moment segwit doesn't help litecoin at all.

This is nonsense. Segwit wasn't designed as a capacity increase. The capacity increase is a side-effect of it. List of benefits:

Malleability Fixes
Linear scaling of sighash operations
Signing of input values
Increased security for multisig via pay-to-script-hash (P2SH)
Script versioning
Reducing UTXO growth
Efficiency gains when not verifying signatures

Source: https://bitcoincore.org/en/2016/01/26/segwit-benefits/

When listing benefits, any competent person would always list both pros and cons. That's to avoid being bias. So can you list the cons please? That would include what happens after segwit gets activated... LN for example?

[franky1]

Malleability Fixes
Linear scaling of sighash operations
Signing of input values
Increased security for multisig via pay-to-script-hash (P2SH)
Script versioning
Reducing UTXO growth
Efficiency gains when not verifying signatures

Malleability Fixes - not fixed. just offering a 'opt-in' keypair type thats disarmed from doing malleability (only the innocent will happily disarm)
Linear scaling of sighash operations - not fixed. just offering a 'opt-in' keypair type thats disarmed from doing quadratics (only the innocent will happily disarm)
same for the rest.

but im glad you admit that adding code to force users to only pay using a certain transaction method is " equal to censorship.".. now think about it
in regards to people saying
"Maybe they can be prohibited and all people owning bitcoins on non-Segwit keys have to transfer them to Segwit addresses."
"prioritise native->SW... SW->SW"
"Q: users move funds to segwit keys A: Which is guaranteed to happen"

also glad your now seeing the truth that its just a optimum HOPE not a reasonable expectation much like the 8 year hope of 7tx/s
"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."

[Lauda]

When listing benefits, any competent person would always list both pros and cons. That's to avoid being bias. So can you list the cons please? That would include what happens after segwit gets activated... LN for example?

You can read all about that in the source. The Bitcoin Core team was pretty objective when assessing the downsides of Segwit. This is why I've added the source.

Malleability Fixes - not fixed. just offering a 'opt-in' keypair type thats disarmed from doing malleability (only the innocent will happily disarm)

It is fixed. Nobody has claimed that it was fixed for the legacy keypairs.

Linear scaling of sighash operations - not fixed. just offering a 'opt-in' keypair type thats disarmed from doing quadratics (only the innocent will happily disarm)

Same as above.

same for the rest.

This is a lie. You don't understand Segwit.

-snip-

Forcing users into Segwit keypairs is not something that I'd exactly support, although I wouldn't strongly oppose it as much as I oppose certain things. Prioritizing native -> SW and SW -> SW is fine with me and tackles the native key spam problem very easily.

[franky1]

Malleability Fixes - not fixed. just offering a 'opt-in' keypair type thats disarmed from doing malleability (only the innocent will happily disarm)

It is fixed. Nobody has claimed that it was fixed for the legacy keypairs.

its not fixed.
the problem with quadratics /malleability is that malicious people will use it to do mallicious things.
unless mallicious people CANNOT do it. then its not fixed.

EG its illegal to use drugs in countries..
does not mean the war on drugs is fixed by some rule. because people still use and sell drugs.

unless there was a way to permenantly guarantee that no one can sell/use drugs, the war on drugs is not fixed.

segwit is not a war on quadratics fix
its not even a prohibition (think about the 1920's alcohol prohibition)
its just a gesture rule where people can voluntarily move to a gated community that voluntarily wants never touch quadratics. and it wil turn out that the only people wanting to move are the people that never intended to spam in the first place

[Lauda]

its not fixed.

It is fixed for the claimed keypairs.

the problem with quadratics /malleability is that malicious people will use it to do mallicious things.
unless mallicious people CANNOT do it. then its not fixed.

You can't harm the network with sigops at 1 MB. Malleability is another matter. This is why everyone should strongly support switching over to Segwit keypairs and implement a stronger control for native keys.