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

[spartacusrex]

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

[Lauda]

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.

Franky has a misleading understanding of Segwit, and jonald is a hired baboon. Franky1 will argue that this isn't fixed with SegWit, and he's partially right. The thing is (post Segwit):
1) You could use native transactions to abuse this quadratic validation time problem. However, you are not able to attack the network this way as using only native keys results in =< 1 MB block size.
2) This is fixed for Segwit keypairs and Segwit transactions as validation time is linear. Meaning, with Segwit transactions you can safely do >= 1 - 4 MB.
Pools can and will prioritize Segwit transactions over the native ones if an attacker tries to abuse this. It's a non issue.

CORE are NOT your enemy.

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

You won't wake up if you're paid only to sleep.

[franky1]

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.

not fixed
because
core v0.12  buglet (quadratics) 4k tx limit (10 seconds buglet delay per tx) block limit 20k (ability to have 5tx of the the txsigop limit)
core v0.14  buglet (quadratics) 16k tx limit (8minutes seconds buglet delay per tx) block limit 80k (ability to have 5tx of the the txsigop limit)

the segwit 'activation' itself solves nothing.
even if 99.99% of people move funds to segwit keys to DISARM themselves from causing (your buzzword buglet) quadratics. 1 person can make just 5 quadratic transactions to use up all the sigop limits and cause 40minutes of validation delay instead of 50 seconds.

the solution is not segwit. the solution is maxtxsigops to remain at 4k (less than a couple years ago) or bring it down further... definetly not raise the limit to allow it to become more of a problem/ attack vector

[kiklo]

Wow!!!

@Spartacusrex & Lauda

According to you Guys, BTC is really just a piece of shit.  

BTC can't support 2mb blocks, but there are Alts going as high as 10 MB per block, (without segwit).

BTC can't move to a faster block speed, but LTC runs at 4X faster blockspeed with zero problems, and other alts even faster.


So either you guys don't know what you are talking about and BTC is able to match the alts if the code is updated.
or
BTC is just an old clunker that should be left in the junkyard.


I'll let the reader decide which they want to believe.  


 

[franky1]

2) This is fixed for Segwit keypairs and Segwit transactions as validation time is linear. Meaning, with Segwit transactions you can safely do >= 1 - 4

this is where lauda misunderstands.

segwit transactions do not wholely sit in the weighted area separate and safe from native tx's. they sit in partly in the base block. along side native tx's where a segwit tx has its ass (the sig/witness) hanging in the extra weighted area..

now if 5 native quadratic spam tx's are in the base block.. nothing else gets in. not even segwit tx's .. in short its used up all the baseblock limits and makes that block take 40 minutes to validate.

[anonymoustroll420]

the segwit 'activation' itself solves nothing.
even if 99.99% of people move funds to segwit keys to DISARM themselves from causing (your buzzword buglet) quadratics. 1 person can make just 5 transactions and cause 32minutes of validation delay instead of 40 seconds

You keep saying this but it's just NOT TRUE.

This is why there is a 1MB base blocksize limit.

The old keys can spam away at their 1MB block all they want. The new keys which are 'disarmed' from quadratics can spam away at the 4MB total.

You cannot attack this way, no matter the sigop count, we could remove that limit and we probably should. Sigop limit's are only a bandaid.

You simply cannot craft a tx that takes 10 minutes to validate with only a 1MB block. And segwit isn't quadratically spammy, so 4MB is OK.

It's precisely why segwit+2MB HF was the dumbest proposal in the world. That would be quadratically attackable.

It's also one reason why BU sucks big time. They can't fix quadratics without a new address format like segwit. So they are using 'bandaids' like sigops and a 1MB transaction size limit to try solve it. None of it works, it's still quadratically spammy. When you explain this to the devs, they say that the miners would never attack the network. I beg to differ:
https://bitcointalk.org/index.php?topic=327767.0

The only long term plan they have to fix this is to hardfork in segwit at a later date: https://bitco.in/forum/threads/buip037-hardfork-segwit.1591/

[franky1]

You keep saying this but it's just NOT TRUE.

This is why there is a 1MB base blocksize limit.

The old keys can spam away at their 1MB block all they want. The new keys which are 'disarmed' from quadratics can spam away at the 4MB total.

You cannot attack this way, no matter the sigop count, we could remove that limit. Sigop limit's are only a bandaid.

You simply cannot craft a tx that takes 10 minutes to validate with only a 1MB block. And segwit isn't quadratically spammy, so 4MB is OK.

It's precisely why segwit+2MB HF was the dumbest proposal in the world. That would be quadratically attackable.

1mb, 4mb is just data limit..
if there was only the 1mb limit. then quadratics could make a single tx of hundred thousand sigops taking HOURS to validate..

this is why there is the maxtxsigop limit.. to reduce quadratic risks.
in recent years it got added and put down to 4k sigop limit and 20k blocksigop limit. meaning quadratic spammers can no longer make a single tx of hundred thousand sigops. but at most 5x of 4000 sigops.. which calculates to 50seconds of validation time instead of hours

your also forgetting that native keys will still be functional even after segwit activation. so the attack still exists.
all sgwit key users are doing is disarming themselves from performing it. but people sticking with native keys can still perform it.
and as my other post mentions.. which most people dont realise is that segwit keys need to be in the base block too.. even if their ass is hanging out in their weight area.
its not like segwit key users are completely separated from native keys, just their ass (the sig/witness)

[anonymoustroll420]

1mb is just data..
if there was only the 1mb limit. then quadratics could make a single tx of hundred thousand sigops taking HOURS to validate..

Op codes are data. You can only fit so many spammy op codes into a block. You cannot attack a 1MB block even if it was completely full of the spammiest OP codes. Sigop's limits are a new thing, we didn't have them before.

all sgwit key users are doing is disarming themselves from performing it. but people sticking with native keys can still perform it.

*sigh*

On their 1MB BLOCK, which cannot be used to craft a quadratically spammy tx that takes 10 minutes to validate. Sure, native key users can fill a block. They don't need quadratics to do that. Segwit keys can fill a block too. Anyone can fill a block if you got enough money to burn in tx fees and outbid everyone else.

[-ck]

Why on earth did you start a thread trying to dispel the nonsense of the march of the full time anti-core propaganda trolls and not make the thread self-moderated, hence inciting the very same morons back to post here?

[franky1]

Why on earth did you start a thread trying to dispel the nonsense of the march of the full time anti-core propaganda trolls and not make the thread self-moderated, hence inciting the very same morons back to post here?

come on CK. even you know segwit keys sit in the baseblock too. and if the baseblock has native quadratic spam of 5tx's of 16k sigops each.. thats about 40 minute validation delays. ven after sgwit activates.

cores hope/utopia is that everyone including malicious people will morally move funds to segwit keys. and then the utopian dream of everyone being disarmed 'could' be seen..
but

even you know native key use cant and wont get turned off after segwit activation. otherwise people cant spend their native utxo(16m+coins)
even you know those intentionally wanting to spam wont opt-in to move funds to segwit keys.. so its not solved

[anonymoustroll420]

5tx's of 16k sigops thats about 40 minute validation delays.

Can't fit that many sigops in a 1MB block.

It's interesting that 1MB is the biggest size you can have without it being quadratically spammy (over 10 minutes to validate). Satoshi picked a good limit.

[spartacusrex]

Wow!!

@Kiklo & Franky1!

Nonsensical crap just can't stop spewing out of your Mouths!..  I'd get that seen to.. err.. Staples ?

BTC can't support 2mb blocks, but there are Alts going as high as 10 MB per block, (without segwit).

Coins with the Traffic of Bitcoin ?

BTC can't move to a faster block speed, but LTC runs at 4X faster blockspeed with zero problems, and other alts even faster.

{ YAWN }.. I didn't mention block speed..

Franky1 breaks some teck down in a way that makes sense to HIM..

Somebody corrects Franky1, who then proceeds to ignore it..

I'll let the reader decide which they want to believe.  

Yes - I think that would be best..

Why on earth did you start a thread trying to dispel the nonsense of the march of the full time anti-core propaganda trolls and not make the thread self-moderated, hence inciting the very same morons back to post here?

LOL.. no.. jesus if this thread was Self Moderated, they'd just start another thread and accuse me of having a Self Moderated thread!..

[AngryDwarf]

Why on earth did you start a thread trying to dispel the nonsense of the march of the full time anti-core propaganda trolls and not make the thread self-moderated, hence inciting the very same morons back to post here?

Sorry, but there are pro-core propaganda trolls too. I don't see the point in making them self-moderated, we would just have pro-core and anti-core self reinforcing propaganda threads, where no one would be able to challenge each others assertions.

I'd rather see hand grenades being lobbed from the two entrenched positions to see whose lines of defense holds up, than have a load speaker battle where those with the most powerful amplifier wins a bad philosophy.

[-ck]

Why on earth did you start a thread trying to dispel the nonsense of the march of the full time anti-core propaganda trolls and not make the thread self-moderated, hence inciting the very same morons back to post here?

LOL.. no.. jesus if this thread was Self Moderated, they'd just start another thread and accuse me of having a Self Moderated thread!..

I know, right? But it gave me an excuse to call all the people I have on ignore morons.

Then all you've really done is create yet another thread like all the other ones I'm afraid. They all end up looking the same.

[franky1]

5tx's of 16k sigops thats about 40 minute validation delays.

Can't fit that many sigops in a 1MB block.

It's interesting that 1MB is the biggest size you can have without it being quadratically spammy (over 10 minutes to validate). Satoshi picked a good limit.

did you not see the whole post
CORE V 0.12 :  txsigops 4k blocksigops 20k = 5 tx of 4k each  (total block validation time if those 5tx were created = 50 seconds)

CORE V 0.14 :  txsigops 16k blocksigops 80k = 5 tx of 16k each (total block validation time if those 5tx were created = 40 minutes)
core v0.14.. is segwit.
https://github.com/bitcoin/bitcoin/blob/0.14/src/consensus/consensus.h

Code:

/** The maximum allowed number of signature check operations in a block (network rule) */
static const int64_t MAX_BLOCK_SIGOPS_COST = 80000;

https://github.com/bitcoin/bitcoin/blob/0.14/src/policy/policy.h

Code:

/** The maximum number of sigops we're willing to relay/mine in a single tx */
static const unsigned int MAX_STANDARD_TX_SIGOPS_COST = MAX_BLOCK_SIGOPS_COST/5;

yep more txsigop bloat is possible due to NEW limits of 0.14. which is segwit..

[anonymoustroll420]

5tx's of 16k sigops thats about 40 minute validation delays.

Can't fit that many sigops in a 1MB block.

It's interesting that 1MB is the biggest size you can have without it being quadratically spammy (over 10 minutes to validate). Satoshi picked a good limit.

did you not see the whole post
CORE V 0.12 :  txsigops 4k blocksigops 20k = 5 tx of 4k each

CORE V 0.14 :  txsigops 16k blocksigops 80k = 5 tx of 16k each
core v0.14.. is segwit.

yep more txsigop bloat is possible due to NEW limits of 0.14.

You can't fit the data of 80,000 OP codes into a 1MB block. There is not enough space for that data. If there was, then please make a spammable TX and prove us wrong.

Anyway the txsigops limit is enforced by nodes relaying txes, and the blocksigops is enforced by miners. Evil miner can exceed the limit if he wants. It's only a 'bandaid' to the problem.

[olarsson]

Which alts have big blocks without segwit?

[franky1]

Anyway the txsigops limit is enforced by nodes relaying txes, and the blocksigops is enforced by miners. Evil miner can exceed the limit if he wants. It's only a 'bandaid' to the problem.

but mallicious users are not going to move funds to segwit keys and intentionally disarm themselves.. so segwit doesnt 'fix' it
segwit doesnt even force users to move funds to segwit keys either. users can still use native keys.. so segwit doesnt 'fix' it

[anonymoustroll420]

but mallicious users are not going to move funds to segwit keys and intentionally disarm themselves.. so segwit doesnt 'fix' it
segwit doesnt even force users to move funds to segwit keys either. users can still use native keys.. so segwit doesnt 'fix' it

Fucking hell. The native key users are stuck in a 1MB block. You cannot, no matter what the op code limit is, put in enough op codes into a 1MB block to make a block that takes 10 minutes to validate. The size in bytes of the tx(es) required to do that is bigger than 1MB. They cannot quadratically spam.

If they 'disarm' themselves, then they can use the full 4MB space, and still cannot quadratically spam.

This is what the sigops limit actually do:

Node: I am validating this tx but its taking too long to validate, lets not relay it.
Miner: I crafted this block but it takes too long to validate, lets just craft a new block and mine that one.

Even with sigop's limit a miner can do this:

Miner: I crafted this block but it takes too long to validate, but I am evil so I will mine it anyway!
Nodes: No! this valid block takes too long to validate! I won't be able to validate it before the next one is found, but I have to validate it because it follows all the rules! damn it I'm going to be forked!

[franky1]

but mallicious users are not going to move funds to segwit keys and intentionally disarm themselves.. so segwit doesnt 'fix' it
segwit doesnt even force users to move funds to segwit keys either. users can still use native keys.. so segwit doesnt 'fix' it

Fucking hell. The native key users are stuck in a 1MB block. You cannot, no matter what the op code limit is, put in enough op codes into a 1MB block to make a block that takes 10 minutes to validate.

using v0.12 rules your right..
but check out 0.14 rules
80k block 16k tx

segwit makes things worse for the 1mb block

If they 'disarm' themselves, then they can use the full 4MB space, and still cannot quadratically spam.

by filling the 1mb with spam.. then the other 3mb remains empty. because you cant stick your segwit ass in the 3mb area if you cant even get your head in the 1mb area due to the spam that has filled the 1mb area to stop anything else getting in.

its not about filling 4mb of sigop spam..
its just about being malicious with the baseblock so that the other 3mb is never utilised by only having to mess with the base block

the solution is simple

txsigoplimit 2000.

everyone wins (apart from malicious spammers)
trying to assume the solution is 'lets hope everyone including malicious users use segwit keys' is a laugh