Topic: So who the hell is still supporting BU? - page 19. (Read 29824 times)

If you're running the GUI, you can set EB and AD from the Preferences dialog:



I don't know whether or not a restart is required.


Read 'em and weep, Lauda.

yep thats my thought.
him thinking if everyone adopts it then no one will notice the blacklisting.

Eg if 95% of pools go for segwit no one will notice the 5% no longer winning blocks (because they are automatically ignored/rejected)

afterall with a few rejects/orphans each week(natural occurrence) how many people actually check to see why they get rejected/orphaned. usually its a 2 second decision of 'invalid, throw aside and forget'
and who actually notices which pools just stop mining over night and not produce blocks.

i guarantee you gmaxwell has already wrote the scripts to pass out to sheep to explain why segwit auto bans native pools making blocks
im guessing its ' dont worry they are opposers trying to force a split'..

even though its segwit doing the ignoring and splitting.. not the other way round

core have already set up the ring fense around the pools to 'validate and filter' blocks (the Fibre network) so core are starting to not care about native/non-core nodes.. they just think the sheep will follow and no one will notice. or if they do notice, it would be too late as nodes cant do nothing to defend against it.

---

last point maxwell fails to honestly explain is that the benefits of segwit (linear sigops and tx count boost) only occur if malicious people cant make native transaction types. where everyone has to make p2wpkh tx's (which he knows not everyone will)

he cant explain his way out of people who use native tx types (p2pkh NOT p2wpkh) will still spam the network meaning segwit wont fix the things it promises to fix

Don t mind. He might have the illusion once he got you convinced of SW in soft fogg the entire network will adopt it over midnight...

 

What I do not understand from BU people is why they prefer to secede and possibly totally fuck Bitcoin instead of working on Core or just maybe better shut up.

lol gmaxwell we both know that you are the one that wants a network split.
the majority want true consensus (nodes first, pools second) .. its why pools are holding back from signaling for segwit. they wont make blocks unless the majority of nodes can accept and fully validate segwit.

your segwit nodes have already been highlighted as being (YOUR WORDS) 'upstream filters', where they whitelist downstream nodes and ignore blocks made by old nodes

you can try stroking sheep all you want. but people can read passed your half answers and word twisting

you say
you know why, i know why and so do smart people. but it is such a shame your not big enough guy to explain it to your own sheep with honesty.

maxwell.. here is a mindblowing experiment for you
make a segwit transactions and get BTCC to mine the transaction into a segwit block.
prove to the network and everyone how 'backward compatible segwit blocks are'.

go on, dare you
afterall its all utopia and nothing can go wrong..hmmm
(note: sarcasm in last sentence)
if you want node confidence and pool confidence.. do it.

"Jet fuel can't melt steel beams!"

Please.

Old nodes do not relay, display as unconfirmed, or mine segwit transactions. At no point are they cut off from the network in any way.  By contrast, your desperately proposed hardforks would force all non-participating systems into a separate network.

But keep on, I enjoy watching you turn red faced as people simply laugh off your constant misinformation.

It's confidence inspiring to be so opposed by the dishonest and the deranged.

lauda you dont understand.

i checked post history and as far back as last april i told you about the bug.. and still you have not even bothered to learn a damn thing


i told you this last year!!!

and its why blockstream want to not fix the bug, but to split the network after activation(to stop old nodes from messing with anyoncanspend) and why they have propped up their nodes as the gate keepers of pools(FIBRE - upstream filters) and going to cut off any pools that make blocks using 'old nodes'

wake up. read something. learn something. even try extra hard to read the very links you provide yourself

you have had your head in the sand since april last year and still dont accept the truth even when core themselves wrote it in the very link you provided to this topic.

icebreaker still doing a good job refuting all those gavinista hard fork attempts I see. I remember you posting about XT and classic back in the day, now they are back with unlimited.

Very nice Nick Szabo article in his blog. Lays it down nicely. I would add this one by Andreas too:

https://medium.com/segwit-co/segregated-witness-and-aligning-economic-incentives-with-resource-costs-7d987b135c00#.ui14y1ffm

Im sure if there was a better team than Core, we would have no problems admitting it if they showed superior code and a realistic vision, but as of today, im sorry but anyone not supporting Core + LN roadmap is simply delusional, they are the best.

Until somebody can come up with a coin that scales onchain to visa level volume transactions, without node centralization, with near instant and cheap transactions... Core + LN (with segwit) is the best thing we have, so don't get fooled.

Facepalm. "Anyone can spend" doesn't actually mean anyone can spend that TX. This is used to describe a transaction without specific conditions on how its output can be spent. I've heard a lot of nonsense (I'm not sure if you're trying to imply this?) claiming that Segwit is insecure because "anyone-can-spend" transactions, which is utterly false. Segwit TXs would appear as 'anyone-can-spend' to old nodes, but due to protocol rules these transactions can't be spent without valid signatures.

I do hope that my sense of sarcasm isn't letting me down.

DELETED because you guys have lost all sense of humor.  Happy now?

A compromise could also look like BU injects SW. They have at least recognized that....

I don t care exactly how, but I predict first movers take it all!

yep 8mb is safe for "raspberry Pi" based min specs.
where a 32mb was a old benchtest (normal pc) done years ago where dataloss 'could' start to occur. (protocol limit (above consensus limit(above policy limit)))

this is where the debates began in 2015 where random numbers started coming up, like 32mb 16mb 8mb 2mb.
late 2015 2mb was the ultimate compromise, just to try and get the ball rolling.. but the blockstream paid devs even back tracked on that ultimate compromise

i think what is needed is
protocol limit 32mb. hard coded(reviewed every 4 years as technology grows)
consensus limit 8mb. soft coded. can be adjusted by nodes, to show what they can cope with(maybe have a speed test algo to autoset upper limit)
preference limit start 2mb. which reacts DYNAMICALLY to what the nodes can cope with and supply/demand

we should not be thinking of hard coding 2mb, because we are just being spoon fed by devs and needing to debate for years before dev kings decide.

it needs to be the nodes that decide because the nodes are paramount not devs

Here comes what I assume a compromis could look like.


Given the fact there was an agreement about 8 Mb is fine for all and the calcs I ve seen for SW might using up to 4 Mb there is space for an increase by 4  MB for the MAX BLock Size upper limit.

I guess there you d get more votes for and majority for tesing ?

And SW allone is already tested ( by devs).

And yes it is a HF, but I assume all would be fine with this since it is a compromis.

Sigh

You just dont want to get it?

Who needs to do UAT testing?

Me?

Hahhaaaa

Miners need to do and in depth, they have Millions at risk.

Common youre not that slow.

your reading a script
think logically

litecoin has extensive testing and peer review. right!
does that mean we should throw litecoin keypairs into bitcoin and then block nodes that dont understand these new keypairs that enter the bitcoin code.
... no

until you see a segwit keypair being used within the bitcoin main net. you know nothing.
research this
“anyone can spend”

please spend time reading it.

here use the link that YOU provided but failed to read passd the 6th paragraph
https://bitcoincore.org/en/2016/10/28/segwit-costs/

use the browsers 'find' function for “anyone can spend”

and you will see why segwit nodes are setting themselves up as the gate keepers (upstream filters) and only whitelisting native nodes as downstream nodes(if they white list at all)

if native bitcoin nodes made a block.. its treated as an attack on segwit. even if the block is valid.

its not propaganda if its something YOU provided but YOU fail to understand.

research. read. learn. understand.
fail to, just leads to your opinion on things you dont know, being meaningless.

---

also thanks to _hv
https://medium.com/@DCGco/scaling-bitcoin-reflections-from-the-dcg-portfolio-35b9a065b2a4#.k125iopmo

DCG
has ownership stake in
coinbase, btcc, bitpay, blockstream, and many dozens of bitcoin entities..
they concluded that they are on the fense because they are waiting..
they state that only the core devs have been playing around with segwit on testnet not independently reviewed by all the different independent nodes/community

---

lastly. it was me. before segwit even got tested on the testnets i stated that there was a bug in segwit.
yep back as far as april last year i have highlighted the issue.
and it was me that caused devs to rethink their strategy and lead to them realising that segwit is not 'backward compatible'

but instead of them fixing this. they decided that after activation. they would bilateral split the network so that native bitcoin nodes cant attack this bug because they are thrown into an altcoin, or downgraded into not being a upstream node or allowed to even make a block in the network.
(facepalm)

That's not exactly a dynamic block size and you should know this.

Bitcoin Core has extensive testing and peer review. You can't make statements about "bitcoin is far from having". You're generalizing Bitcoin as an single entity that can be 'tested'.

No.

You can join the testnet at any time, and nightly builds are constantly being provided with the latest changes.

Changing the block size with current != 1 line of code. As an example, first look at the HF proposal in Bitcoin Classic. With BU this becomes even worse with thousands of lines of code.

Sadly bitcoin is far of having ANY proper testing, integration staging as you know from big style software devs for banking, insurance, industry...

We only have some test net, but this is close to some dev playground.

A really needed UAT net is completely missing, where other than devs are doing proper user acceptance testing and these have to be as close as possible done in productive like conditions to find out about bugs or other things that might go wrong after deployment into production.

Even having this all in place nothing can be as similar as the real world = production and more issues will pop up thats 100% sure (seen in every Windoof release).

Having comprehended this you can get the Problem with SW (tested ?, but complex) and some simple change to the max block limit (could be done by reducing 1 line of code - very nice and very Austrian!)

We might need both this time to get along and compromise, but we HAVE to move, or others move:

https://mobile.twitter.com/ErikVoorhees/status/830197808573587457

You might need to go back to playground and watch what happens when 2 are fighting
A third will come and grep all the nice toys.

lauda do you think that dynamic blocksizes are untested?

ok here is somenews for you

2009-2016

there was the 1mb rule right.
but did you know that pools had a variable which until recently was set at or below 0.75mb

yep even though the consensus rule was 1mb.. the pools had a dynamic variable below that which incremented over the years

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

in older versions it was called MAX_BLOCK_SIZE_GEN
which in version 0.7 (which sipa screwed up when he tweaked 0.8 ) the
(0.5mb)
pools now have this setting set to 0.999mb but this 'policy' was infact dynamic.

even now the devs can happily play with the setting all they like blow the upper limit..

EG in 2013, there was a bug caused by Sipa.
they had a choice either
keep blocks below a 'policy'(MAX_BLOCK_SIZE_GEN = MAX_BLOCK_SIZE/2;) of 0.5mb and fix the issue later meaning todays 'we need more' drama would have happened in 2013 and devs screaming doomsday if blocks went passed a 0.5mb policy limit. (even with the 1mb consensus limit)
or
they looked at the cause of the orphans risks, and then allowed blocks to grow beyond it.

guess what happened.. (hint: we are not at 0.5mb after 2013 event)

yep thats right from 2009-2016 we had a large upper limit and then a dynamic limit below it.

the problem now is the dynamic limit is at the upper limit. so the upper limit needs to be moved.

There is nothing to rebuttle, only nonsense to waste my time.

Nonsense.

Bullshit and pure propaganda. The rest is not even worth quoting.

That's not the wisest decision. "Segwit has its flaws" is less obvious than the untested "emergent consensus has its flaws". Forking to increase the block size is one thing, but what BU wants to do is a completely different one. Plenty of articles / read material, e.g. Link 1, Link 2.

Happy reading:


https://medium.com/@DCGco/scaling-bitcoin-reflections-from-the-dcg-portfolio-35b9a065b2a4#.j0oc5jisx


Get your feets on the ground and open your minds for having both!