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

[anonymoustroll420]

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

0.12 and 0.14 both have 1MB blocks. Can't make quadratically spammy block that takes 10 minutes to validate with 1MB. Sigops are a fucking bandaid added by Gavin so that he can argue bigger blocks are safe. They don't do ANYTHING. If your an evil miner you can edit the source and change the limit and attack the network, it's not a consensus rule, needs to be forked in to be one, blocks exceeding the limit are still valid, it's the 1MB blocksize limit that protects us from evil miners.


Sigops limit protect us from random assholes quadratically spamming, but not evil miners.
Blocksize limit protects us from random assholes and evil miners crafting blocks that take 10 minutes to validate.
Gavin argued that miners would never be evil, so increasing the blocksize would be safe if we prevented random assholes from quadratically spamming. This is bullshit, miners can be evil.

by filling the 1mb with spam.. then the other 3mb remains empty.

You can always fill a block if you are willing to outbid everyone else on tx fees.

I'm done arguing with you...

[The One]

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.

Eh!! If pool don't prioritise segwit then it is an issue. We have no idea how the pools may react in the future.

[-ck]

Eh!! If pool don't prioritise segwit then it is an issue. We have no idea how the pools may react in the future.

Default rules in bitcoin core with segwit enabled bias towards segwit transactions by counting the amount of block space they use and since their signature verification is no longer in the block they are substantially smaller than traditional transactions (up to 4x) so if they use the default bitcoin core implementation they will bias towards segwit transactions by default. However there is absolutely nothing that says what any pool must include or how they must bias their transaction choices, so long as the transactions are valid by current rules - most pools run custom bitcoin daemons already and they probably have their own custom rules.

[franky1]

by filling the 1mb with spam.. then the other 3mb remains empty.

You can always fill a block if you are willing to outbid everyone else on tx fees.

to which i will reply with your own words

This is bullshit, miners can be evil.

Pools can and will prioritize Segwit transactions over the native ones if an attacker tries to abuse this. It's a non issue.

Eh!! If pool don't prioritise segwit then it is an issue. We have no idea how the pools may react in the future.

yep ill reply with anontroll420's quote

miners can be evil.

solution
consensus.h
txsigops <4k (forever)

[The One]

Eh!! If pool don't prioritise segwit then it is an issue. We have no idea how the pools may react in the future.

Default rules in bitcoin core with segwit enabled bias towards segwit transactions by counting the amount of block space they use and since their signature verification is no longer in the block they are substantially smaller than traditional transactions (up to 4x) so if they use the default bitcoin core implementation they will bias towards segwit transactions by default. However there is absolutely nothing that says what any pool must include or how they must bias their transaction choices, so long as the transactions are valid by current rules - most pools run custom bitcoin daemons already and they probably have their own custom rules.

Is this not something developers should sort out? This is an element of centralisation when pools can dictate their own rules on the rest of the network. A truly decentralise bitcoin should by default be the codes that process the rules and protocols.

[-ck]

Is this not something developers should sort out? This is an element of centralisation when pools can dictate their own rules on the rest of the network. A truly decentralise bitcoin should by default be the codes that process the rules and protocols.

No. You cannot dictate what transactions are included at all, only what rules they must abide by. To do so would require a hard fork and mandating what transactions will be going in would be an extremely unpopular move and suicide for a cryptocurrency that is trying to be open.

[kiklo]

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.

@CK    

Takes one to know one.  


 

[anonymoustroll420]

by filling the 1mb with spam.. then the other 3mb remains empty.

You can always fill a block if you are willing to outbid everyone else on tx fees.

to which i will reply with your own words

This is bullshit, miners can be evil.

Miner can currently mine empty blocks right now if they want....

solution
consensus.h
txsigops <4k (forever)

Good luck doing any useful contracts or any large multi output tx with that limit. Good luck having unspendable txes.

[franky1]

Miner can currently mine empty blocks right now if they want....

yep which also shows that segwit solves nothing. it cannot force pools to only accept segwit keys meaning native keys can still mess with the base block in MANY attack vectors that affect the network.
segwit doesnt 'fix' anything. its just HOPES malicious users decide to disarm themselves

No. You cannot dictate what transactions are included at all, only what rules they must abide by. To do so would require a hard fork and mandating what transactions will be going in would be an extremely unpopular move and suicide for a cryptocurrency that is trying to be open.

[anonymoustroll420]

yep which also shows that segwit solves nothing. it cannot force pools to only accept segwit keys meaning native keys can still mess with the base block in MANY attack vectors that affect the network

Yes, they can fill a block if they outbid everyone on tx fees. They can do that right now too. They can do that with any blocksize. Segwit users can do that too. Nobody quadratically spam.

Miners can also outbid by giving up the tx fees they earn in a block and mine an empty or full block if they want too. They can always do that

[The One]

Is this not something developers should sort out? This is an element of centralisation when pools can dictate their own rules on the rest of the network. A truly decentralise bitcoin should by default be the codes that process the rules and protocols.

No. You cannot dictate what transactions are included at all, only what rules they must abide by. To do so would require a hard fork and mandating what transactions will be going in would be an extremely unpopular move and suicide for a cryptocurrency that is trying to be open.

You ? meaning me or miner?

You said, "However there is absolutely nothing that says what any pool must include or how they must bias their transaction choices,." = miner can choose = dictate?

[Lauda]

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.

Nonsense. The sigops in Core 0.14.0 are scaled for Segwit and have linear validation time. "40 minutes" is an outright lie.

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

Do you even algorithm complexity?
This was debunked by me long ago, then later also commented on by Maxwell stating the absurdness of your claims.

[-ck]

Is this not something developers should sort out? This is an element of centralisation when pools can dictate their own rules on the rest of the network. A truly decentralise bitcoin should by default be the codes that process the rules and protocols.

No. You cannot dictate what transactions are included at all, only what rules they must abide by. To do so would require a hard fork and mandating what transactions will be going in would be an extremely unpopular move and suicide for a cryptocurrency that is trying to be open.

You ? meaning me or miner?

You said, "However there is absolutely nothing that says what any pool must include or how they must bias their transaction choices,." = miner can choose = dictate?

The developers cannot dictate.

[franky1]

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.

Nonsense. The sigops in Core 0.14.0 are scaled for Segwit and have linear validation time. "40 minutes" is an outright lie.

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

Do you even algorithm complexity?
This was debunked by me long ago, then later also commented on by Maxwell stating the absurdness of your claims.

i was actually symplifying things without going into waffle for the benefit of the "one paragraph concentration spam" people of reddit/twitter
so here goes, as condensed as i can make it:

Code:

MAX_STANDARD_TX_SIGOPS_COST

not

Code:

MAX_STANDARD_P2WSH_TX_SIGOPS_COST

plus gmax didnt dbunk anything. he just done what you usually do.. "wrong because word twist + insult"

[The One]

Is this not something developers should sort out? This is an element of centralisation when pools can dictate their own rules on the rest of the network. A truly decentralise bitcoin should by default be the codes that process the rules and protocols.

No. You cannot dictate what transactions are included at all, only what rules they must abide by. To do so would require a hard fork and mandating what transactions will be going in would be an extremely unpopular move and suicide for a cryptocurrency that is trying to be open.

You ? meaning me or miner?

You said, "However there is absolutely nothing that says what any pool must include or how they must bias their transaction choices,." = miner can choose = dictate?

The developers cannot dictate.

I was talking about pools when I used the word dictate.

[jonald_fyookball]

CORE are NOT your enemy.
 

Yes they are.  Their actions speak for themselves.  They've stalled for years and damaged Bitcoin adoption, use-cases, and marketshare with high fees and slow confirmations.   Segwit as SF just allows them to continue to dole out whatever meager on chain capacity improvements they are willing to grant us.

I reject their economic approach entirely and believe blocksize should always be well beyond market demand.  Let off-chain solutions compete FAIRLY with on-chain, without any constraints.  

If you're concerned about decentralization, SPV Fraud Proofs are better than ever:  https://bitcrust.org/blog-fraud-proofs

[anonymoustroll420]

If you're concerned about decentralization, SPV Fraud Proofs are better than ever:  https://bitcrust.org/blog-fraud-proofs

I had never heard of this fraud proof implementation. Interesting.

I just started reading it and one problem I see is that it requires a fork to Bitcoin that changes the merkle tree. This would break covert ASICBOOST (I'm not joking!) so I don't think Jihan will support it.

It seems like to do what they call 'fraud hints' would require a malleability fix too, so we'd still need segwit or another malleability fix, though I'm not entirely sure about this.

There are also some limitations to it:

The tricky frauds to proof, are not covered this way. An attacker can include a TXID of a non-existent transaction in the block. Such absence cannot be proofed as there is no invalid transaction to broadcast.

This article does not aim to structurally cover the full attack surface, nor does it provide detailed solutions; it should serve as an initial exploration of the possibilities of Fraud Proof SPV nodes using the spend tree.

[Lauda]

i was actually symplifying things without going into waffle for the benefit of the "one paragraph concentration spam" people of reddit/twitter

Regardless, you are wrong about the sigops.

plus gmax didnt dbunk anything. he just done what you usually do.. "wrong because word twist + insult"

He did debunk it by making such a statement as your claim is ludicruous. If I were to get the author of Segwit in here to tell you that you were wrong, you'd still write "he didn't debunk anything" nonsense.

If you're concerned about decentralization, SPV Fraud Proofs are better than ever:  https://bitcrust.org/blog-fraud-proofs

This is nonsense, as you'd expect it from a paid baboon. SPV Fraud Proofs are far from being practical and safe enough to alleviate the dangers of SPV wallets.

I had never heard of this fraud proof implementation. Interesting.

They are not ready yet. Hypocritically, the BTU supporters bash something that has been extensively tested for months but praise something that is new as safe just because it fits their agenda. 

[franky1]

plus gmax didnt dbunk anything. he just done what you usually do.. "wrong because word twist + insult"

He did debunk it by making such a statement as your claim is ludicruous.

wow "im ludicrous"
now thats real proof of concept there.
such merit in code and such merit in display of proving wrong by saying "im ludicrous", such detail in explaining it...

now then..
4k vs 16k sigop count, which do you think is worse

[Lauda]

wow "im ludicrous"

You are.

4k vs 16k sigop count, which do you think is worse

The left one is with the current block size limit & quadratic validation time, the other one is with Segwit and linear validation time. The foremost is worse. Maybe enroll in a CS college?