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

The One

legendary

Activity: 924

Merit: 1000

Quote from: -ck on May 02, 2017, 06:49:32 AM

Quote from: The One on May 02, 2017, 06:45:57 AM

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?

anonymoustroll420

full member

Activity: 196

Merit: 101

Quote from: franky1 on May 02, 2017, 07:11:17 AM

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

franky1

legendary

Activity: 4424

Merit: 4794

Quote from: anonymoustroll420 on May 02, 2017, 07:08:34 AM

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

Quote from: -ck on May 02, 2017, 06:49:32 AM

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

full member

Activity: 196

Merit: 101

Quote from: franky1 on May 02, 2017, 06:45:36 AM

Quote from: franky1 on May 02, 2017, 06:16:01 AM

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

Quote from: anonymoustroll420 on May 02, 2017, 06:18:56 AM

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

Quote from: anonymoustroll420 on May 02, 2017, 06:18:56 AM

This is bullshit, miners can be evil.

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

Quote from: franky1 on May 02, 2017, 06:45:36 AM

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.

kiklo

legendary

Activity: 1092

Merit: 1000

Quote from: -ck on May 02, 2017, 05:54:32 AM

Quote from: spartacusrex on May 02, 2017, 05:52:01 AM

Quote from: -ck on May 02, 2017, 05:43:49 AM

Quote from: spartacusrex on May 02, 2017, 04:39:19 AM

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

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: The One on May 02, 2017, 06:45:57 AM

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.

The One

legendary

Activity: 924

Merit: 1000

Quote from: -ck on May 02, 2017, 06:27:28 AM

Quote from: The One on May 02, 2017, 06:21:56 AM

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.

franky1

legendary

Activity: 4424

Merit: 4794

Quote from: franky1 on May 02, 2017, 06:16:01 AM

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

Quote from: anonymoustroll420 on May 02, 2017, 06:18:56 AM

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

Quote from: anonymoustroll420 on May 02, 2017, 06:18:56 AM

This is bullshit, miners can be evil.

Quote from: The One on May 02, 2017, 06:21:56 AM

Quote from: Lauda on May 02, 2017, 04:45:33 AM

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

Quote from: anonymoustroll420 on May 02, 2017, 06:18:56 AM

miners can be evil.

solution
consensus.h
txsigops <4k (forever)

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: The One on May 02, 2017, 06:21:56 AM

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.

The One

legendary

Activity: 924

Merit: 1000

Quote from: Lauda on May 02, 2017, 04:45:33 AM

Quote from: spartacusrex on May 02, 2017, 04:39:19 AM

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.

anonymoustroll420

full member

Activity: 196

Merit: 101

Quote from: franky1 on May 02, 2017, 06:16:01 AM

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.

Quote from: franky1 on May 02, 2017, 06:16:01 AM

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

franky1

legendary

Activity: 4424

Merit: 4794

Quote from: anonymoustroll420 on May 02, 2017, 06:10:26 AM

Quote from: franky1 on May 02, 2017, 06:08:04 AM

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

Quote from: anonymoustroll420 on May 02, 2017, 06:10:26 AM

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

anonymoustroll420

full member

Activity: 196

Merit: 101

Quote from: franky1 on May 02, 2017, 06:08:04 AM

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

legendary

Activity: 4424

Merit: 4794

Quote from: anonymoustroll420 on May 02, 2017, 06:01:35 AM

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

olarsson

full member

Activity: 208

Merit: 100

Which alts have big blocks without segwit?

anonymoustroll420

full member

Activity: 196

Merit: 101

Quote from: franky1 on May 02, 2017, 05:59:40 AM

Quote from: anonymoustroll420 on May 02, 2017, 05:50:38 AM

Quote from: franky1 on May 02, 2017, 05:50:01 AM

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.

franky1

legendary

Activity: 4424

Merit: 4794

Quote from: anonymoustroll420 on May 02, 2017, 05:50:38 AM

Quote from: franky1 on May 02, 2017, 05:50:01 AM

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

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: spartacusrex on May 02, 2017, 05:52:01 AM

Quote from: -ck on May 02, 2017, 05:43:49 AM

Quote from: spartacusrex on May 02, 2017, 04:39:19 AM

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.

AngryDwarf

sr. member

Activity: 476

Merit: 501

Quote from: -ck on May 02, 2017, 05:43:49 AM

Quote from: spartacusrex on May 02, 2017, 04:39:19 AM

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.

spartacusrex

hero member

Activity: 718

Merit: 545

Wow!!

@Kiklo & Franky1!

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

Quote from: kiklo on May 02, 2017, 05:29:08 AM

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 ?

Quote from: kiklo on May 02, 2017, 05:29:08 AM

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

Quote from: anonymoustroll420 on May 02, 2017, 05:31:07 AM

Quote from: franky1 on May 02, 2017, 05:25:29 AM

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

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

Quote from: kiklo on May 02, 2017, 05:29:08 AM

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

Yes - I think that would be best.. Wink

Quote from: -ck on May 02, 2017, 05:43:49 AM

Quote from: spartacusrex on May 02, 2017, 04:39:19 AM

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

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