95% lol. No chance. SegWit is now dead.

[RawDog]

What, me worry?

You only have to worry if Core gets their way and tricks morons into accepting SegWit

[1713563044]

1713563044

[1713563044]

1713563044

[1713563044]

1713563044

[1713563044]

1713563044

[MicroGuy]

What, me worry?

You only have to worry if Core gets their way and tricks morons into accepting SegWit

The Blockstream Kool-Aid is a potent punch. 

[RawDog]

What, me worry?

You only have to worry if Core gets their way and tricks morons into accepting SegWit

The Blockstream Kool-Aid is a potent punch. 

True fact.

[Meuh6879]

the reality ... 

[jbreher]

the reality ...  [ width=250]http://imagizer.imageshack.us/a/img921/1817/YaqtIc.jpg[/]

[]http://imagizer.imageshack.us/a/img922/4007/nxc4Zx.png[/]

Nice try. 51% of non-mining nodes don't accomplish jack shit.

Too bad, so sad.

[franky1]

When a miner is working on a block, it is trying to earn the block subsidy + transaction fees for its proposed block. It will abandon its attempt to find the hash for its proposed block if and only if it is provided with proof that another block spending some of the same transactions has been found. So when a potentially solved block is presented, it needs to validate that block. In the case of a block with excessive sig in a single transaction, this validation process will take an excessive amount of time (indeed, this is the supposed 'nightmare scenario' that makes quadratic hashing such a scary issue). So what is a miner to do? Stop everything, and devote all processing to validating the incoming potentially-solved block? Hell no. A rational miner will spawn off a single thread to validate the potentially-solved block, and devote the rest of its resources to trying to find the solution hash to its proposed block. Anything else would be self-defeating.

As all rational miners would engage in this process, it is likely that some miner will find an alternate block solution while is is still trying to validate the incoming possibly-good but large-sig-containing block solved by the first solving miner. It is free to propagate its solved block to the network at large.

Upon receiving such a block, rational miners will devote (e.g.) one thread to validating the new block - even as they are still trying to validate the first possibly-good but large-sig-containing block. Whichever is the first to be validated is the block which they will propagate and the block that they will build atop. This would be the second-arriving block that does not engender the quadratic hashing issue.  The first solution block - containing the large sig transaction - gets orphaned. Problem goes away.

What, me worry?

i get what your thinking. and this has already been solved.. its the empty block concept, people still dont get.

firstly. pool A solves a block hands it out.. lets say pool B receives it.
immediately.
pool B tells the asics. to start working on an empty block. (no tx apart from blockreward claim(coinbase tx))
because poolB does not know what tx's to add into blockB because its yet to validate blockA

what happens is a pool can take upto 2 minutes to validate a block. (as long as its not got a super bloater 1mb tx)

and so before validating a blockA to know what unconfirmed tx's remain in mempool to start adding to pool B's empty block, if blockB 'luckily' gets a solution then Block B looks 'empty'.

obviously if BlockB is not solved after 2 minutes and if all is good with BlockA... poolB starts adding tx's from unconfirmed mempool to blockB and resending a hash to the ASICS to hash away at.

this is why most 'empty' blocks are found within a couple minutes of the previous timestamp. because they are only mpty because they were luckily solved so quick

..

now thats dealt with.
instead of letting 1tx have 20,000sigops, letting it have say 500sigops max. means that we will never ever ever have a risk of it taking 10minutes to solve a block by someone having a 1mb tx.

secondly pools can right now. in their own settings. without needing to get a consensus or an vote or permission. set their pool node to only allow tx's with < xxx sigops. and then those trying to send such clunky tx's will soon realise their tx's are not getting accepted. and will react accordingly (being more leaner with their tx's)

thirdly making leaner tx's also helps more peoples tx get accepted.
EG 2500tx's of 400bytes. instead of 1tx of 1mb

leaving the sigops soo high, even when (lets say segwit activated)  quadratics is not an issue. may save processing time.. but still allows a bloater to send a tx of 1mb. so reducing the sigop count of tx's should still be done anyway.

so knowing it should be done anyway. we might aswell just do it. and solve the problem sooner. rather than waiting for segwit to not do a full job

[Wind_FURY]

Good job Roger Ver, it looks like SegWit has absolutely no chance at all of getting anywhere near 95%.  I doubt they will ever get over 50%.

SegWit is not Bitcoin.  SegWit is an altcoin.  

I feel it is my duty as a concerned citizen and valuable contributor of the Bitcoin community to declare SegWit dead on arrival.

All Bitcoin Judas accomplished was FUDing a perfectly reasonably and innovative soft fork, which is foundational to future scaling, into a controversial object of drama.

Let's all congratulate him on getting kicked off Reddit for brigading, doxing, and monetizing his subreddit.

SegWit is a controversial contentious fork which half of the community don't want to subscribe to. Blaming and crucifying Ver for SegWit not happening is finding a scapegoat.

You really cannot blame some of the people in the community in trying to crucify Roger Ver. I know he is a really nice guy in real life and everything I say about him becoming a CEO of Bitcoin is all in jest. But he put himself in that position where he can be an easy target. So there he is, an easy target.

[franky1]

But he put himself in that position where he can be an easy target.

how?

was it him saying he is happy to let blockstream do their LN(paypal2.0) if they let bitcoins mainnet dynamically grow.
which then got lost in translating and fed to the wolves to vomit out as the opposite?

[aarturka]

the reality ... 

Looks like again Core are victorious! Bitcoin will survive.
Surrender peacefully franky1 and you will not be harmed...

[jbreher]

When a miner is working on a block, it is trying to earn the block subsidy + transaction fees for its proposed block. It will abandon its attempt to find the hash for its proposed block if and only if it is provided with proof that another block spending some of the same transactions has been found. So when a potentially solved block is presented, it needs to validate that block. In the case of a block with excessive sig in a single transaction, this validation process will take an excessive amount of time (indeed, this is the supposed 'nightmare scenario' that makes quadratic hashing such a scary issue). So what is a miner to do? Stop everything, and devote all processing to validating the incoming potentially-solved block? Hell no. A rational miner will spawn off a single thread to validate the potentially-solved block, and devote the rest of its resources to trying to find the solution hash to its proposed block. Anything else would be self-defeating.

As all rational miners would engage in this process, it is likely that some miner will find an alternate block solution while is is still trying to validate the incoming possibly-good but large-sig-containing block solved by the first solving miner. It is free to propagate its solved block to the network at large.

Upon receiving such a block, rational miners will devote (e.g.) one thread to validating the new block - even as they are still trying to validate the first possibly-good but large-sig-containing block. Whichever is the first to be validated is the block which they will propagate and the block that they will build atop. This would be the second-arriving block that does not engender the quadratic hashing issue.  The first solution block - containing the large sig transaction - gets orphaned. Problem goes away.

What, me worry?

i get what your thinking. and this has already been solved.. its the empty block concept, people still dont get.

firstly. pool A solves a block hands it out.. lets say pool B receives it.
immediately.
pool B tells the asics. to start working on an empty block. (no tx apart from blockreward claim(coinbase tx))
because poolB does not know what tx's to add into blockB because its yet to validate blockA

I'm not convinced you are understanding what I am saying. Your description above may be the way things work today (is it?), but it is a stupid design.

The problem is that Pool B is trusting that Pool A's block is valid. The empty blocks are not mined because Pool B is yet to validate Pool A's block, it is due to Pool B not yet knowing which transactions to exclude from the candidate block it (Pool B) is building on top Pool A's (possibly solved but possibly invalid) block. In this I agree, but is irrelevant to the quadratic hash time issue - that is a different concern.

The issue I describe is that, until validated, Pool B has no idea whether or not Pool A's block is or is not valid (duh - tautology). Pool A may be an attacker merely claiming to have solved a block. If this block also contains an expensive to validate transaction (e.g., one in which the quadratic hash issue demands excessive time to validate), then much time will elapse before Pool B knows whether or not it can build a valid candidate block atop the Pool A block.

In this instance, suppose Pool C solves another block which has the same parent as Pool A's block. Let us further suppose that this block is cheap to validate (does not take inordinate time). Rational miners will build atop this Pool C block, rather than Pool A's block. This is because validation can be completed more quickly. These miners are incentivized to stop the expensive validation of Pool A's block, once they validate Pool C's block.

The net result is that Pool A's problem block gets orphaned. The system already has the incentives for rational miners to solve the quadratic hash time issue without recourse to any new fixes such as artificially limiting transaction size.

Again, I don't know current mining implementations. They may be ignorant of this fact. But any miner implementing this idea would then have a natural competitive advantage in any case where problem blocks (containing expensive-to-validate transactions) exist.

Net-net: The problem solves itself.

[jbreher]

[]http://imagizer.imageshack.us/a/img922/4007/nxc4Zx.png[/]

Looks like again Core are victorious! Bitcoin will survive.
Surrender peacefully franky1 and you will not be harmed...

I repeat: a majority of non-mining nodes does not activate The SegWit Omnibus Changeset.

You're a special kind of special, aren't you?

[franky1]

I'm not convinced you are understanding what I am saying. Your description above may be the way things work today (is it?), but it is a stupid design.

i understand fully what your saying.. pools and others ..including myself are many steps ahead of your scenario.
pools have mitigated the risk and found the best efficient ways to handle the problem your describing.

i may have skipped ahead a few details which would have made what im saying more understandable.

but in short.

by pool B telling asics (separate location) to start a new 'empty block'. gains a pool a ~20% advantage rather than waiting the full couple minutes to download the full block A, validate block A's solution and then start a block B with transactions.

there was a bit of drama about this in 2014-2015 scenarios thrown around. benefits/risks talked about at length, blah blah blah

ultimately, where the orphan risk was only ~1-2%, so that 20% advantage is worth doing.
now they found other ways to mitigate it too and the orphan rate is even lower than 1% these days. while still gaining the 20% advantage by starting a new block while simultaneously validating a previous block.

remember a pool validates and relays blocks.. but asics (separate location and processors) do the hashing.

hashing blocks is not what the pool does..
validating competing blocks is not what asics do..
just like cooking a steak(asic hashing) is not a restaurant manager(pool) does
just like driving a taxi(asic hashing) is not a taxi company call centre(pool) does

so its not like hashing a new block and validating old block is overpowering a pools CPU.. they are done by separate processors

[jbreher]

I'm not convinced you are understanding what I am saying. Your description above may be the way things work today (is it?), but it is a stupid design.

i understand fully what your saying.. pools and others ..including myself are many steps ahead of your scenario.
pools have mitigated the risk and found the best efficient ways to handle the problem your describing.

Now I'm pretty convinced you have no idea what I am trying to convey. I am not speaking to why it is that empty blocks get mined. I am speaking to the point that no changes to the protocol are necessary to solve the 'quadratic hash time issue', as incentives already solve it.

[franky1]

ok i was replying mainly to the point you made here

When a miner is working on a block, it is trying to earn the block subsidy + transaction fees for its proposed block. It will abandon its attempt to find the hash for its proposed block if and only if it is provided with proof that another block spending some of the same transactions has been found.

empty blocks contain no transactions.. so no risk of orphan due to "blocks spending some of the same transactions"

this has mitigated the quadratic risk of requiring to wait till full validation. because block B contains no transactions that could cause confusion. to cause block B to get orphaned due to building ontop of A straight away. because it contains non of A's tx's..
thus waiting just to validating before even starting a new block becomes less important.


however the bottom part of your scenario post yesterday. and retold now. about pool C making a block to compete against A which gets propagated before A is validated. thus causing B to orphan because A no longer is acceptable... is under 1% risk of occurring.

so B wont waste a 20% efficiency gain due to a 1% chance of C pushing A aside.

all these scenarios have been played out a couple years ago.

[jbreher]

ok i was replying mainly to the point you made here

When a miner is working on a block, it is trying to earn the block subsidy + transaction fees for its proposed block. It will abandon its attempt to find the hash for its proposed block if and only if it is provided with proof that another block spending some of the same transactions has been found.

empty blocks contain no transactions.. so no risk of orphan due to "blocks spending some of the same transactions"

this has mitigated the quadratic risk of requiring to wait till full validation. because block B contains no transactions that could cause confusion. to cause block B to get orphaned due to building ontop of A straight away. because it contains non of A's tx's..
thus waiting just to validating before even starting a new block becomes less important.


however the bottom part of your scenario post yesterday. and retold now. about pool C making a block to compete against A which gets propagated before A is validated. thus causing B to orphan because A no longer is acceptable... is under 1% risk of occurring.

The issue is not that B's block has a chance of being orphaned due to A's not being valid. Whether or not A's is valid is irrelevant, because C's block is proven valid before A's. Accordingly, it is irrational for B to mine atop A's block. B should mine atop C's block, as C's block will propagate and validate across the entire network before A's block does. And if C's block causes A's block to be orphaned, any block built atop A will also be orphaned.

so B wont waste a 20% efficiency gain due to a 1% chance of C pushing A aside.

all these scenarios have been played out a couple years ago.

So then why do you advocate for an artificial limit upon the size of a single transaction?

[Wind_FURY]

But he put himself in that position where he can be an easy target.

how?

was it him saying he is happy to let blockstream do their LN(paypal2.0) if they let bitcoins mainnet dynamically grow.
which then got lost in translating and fed to the wolves to vomit out as the opposite?

He did the moment he started promoting Bitcoin Unlimited. I personally do not see anything wrong with it. It is politics and man by nature is political. We lie, coerce and do whatever it takes behind the scenes to reach a goal that we think is worth fighting for. That is ok. What I do not like about the whole thing is the tasteless name calling from both sides of which I am guilty of sometimes. Chalk that up to human nature again I guess.

[MicroGuy]

What I do not like the whole thing is the tasteless name calling from both sides of which I am guilty of sometimes. Chalk that up to human nature again I guess.

Yeah. Maybe as we get older we learn how to better deal with this damn human-ess!  


... now that I'm turning into dust, I seem to be softening up a bit.

[franky1]

So then why do you advocate for an artificial limit upon the size of a single transaction?

the most simplest answer
because 1tx of 1mb.. holds up ~2499tx on average for getting into a block

[jbreher]

So then why do you advocate for an artificial limit upon the size of a single transaction?

the most simplest answer
because 1tx of 1mb.. holds up ~2499tx on average for getting into a block

And what about that is problematic?

[jonald_fyookball]

it looks like SegWit has absolutely no chance at all of getting anywhere near 95%.  I doubt they will ever get over 50%.

SegWit is not Bitcoin.  SegWit is an altcoin.  
 

I agree.  and I'm glad.  The blockstream/core stonewalling of a blocksize increase
has been ridiculous.  Wondering how long the great scaling debate can go on
before something gives.