mhm.. yea core are stupidly going for the most foolish 'dynamic' method they can, as a way to turn people away from wanting it.

its like going up to a starving man with food you know he wants.. then rubbing the food between your a*scrack and handing it to him. and when he refuses to eat it, because you have only offered uneatable food .. you can scream to the world that starving people are not starving. because they refused your food.

they are desperate to keep onchain scaling halted, so are suggesting a dynamic method with market cap penalising code just to scare people away from wanting it. (people are smart enough to stick away from such stupid methods like this)

then claim "people dont want it", rather than offering a clean straight forward natural, non penalising dynamic method which people do want.
 

---

/Satoshi:0.13.1/   1512 (26.84%)
/Satoshi:0.13.2/   1165 (20.68%)
/Satoshi:0.13.99/   116 (2%)

~50% are segwit supporting whether they realise it or not.. yep 50% implicitly, but an unknown number below 50% explicitly.
the difference between implicit and explicit terms is that some people upgrade just because they see something new and shiny but dont understand whats 'under the hood'. so its not ~50% full knowledge explicit desire. it's less
the other 35% you are mentioning above ~50% are undecided. yep even if they love core. they have not decided yet or they oppose segwit. by not upgrading
(try understanding the context of stats)

---

kind of funny, i have actually in many topics highlighted the tech, explained it in laymans ELI-5 and shown the finer details that others sweep under the rug or word twisted with buzzwords to hide its importance or meaning. but as soon as i mention a persons name... its treated as attacking their king and thus they must defend bad implementation to protect the king. even if they dont understand the implementation.

gotta love blockstream fans playing the victim card, especially after poking the bear first

your continued rhetoric that china's "their" suggests one entity, but is fail beyond belief

separate pools have separate asic locations, with separate stratums, separate power stations and separate managers in separate locations.

the hashrate is not "combined".

if the chinese government were to cut off the internet to an asic farm warehouse. a pool manager can cellphone text message(or cellphone 4/5G api request) a hash with a difficulty to the asic farm..
when a solution is found the asic farm texts(or cellphone 4/5G api pushes) back a solution to the pool stratum.
yes pools have many stratums around the world.

if the chinese government were to cut electric to an asic farm warehouse. a pool manager simply turn on their generator temporarily while the employee's physically move rigs to a new physical location.. yes that farm isnt productive for hours. but the other 20+pools are happy because their 'luck' has temporarily improved, gaining income because they are solving more blocks due to less competition.
within 48 hours the electric losing farm would be back online

if the chinese government were to outlaw mining. then within 48 hours everything moves to thailand or mongolia, or other neighbouring countries (and yes pools already have property and pool stratums and guys managing pools outside china.. even if the classification you call the pools are 'chinese', they are not actually all chinese)

"no its impossible for camera's to be digital, where a clear picture needs a server the size of a grand piano to store just one digital picture. lets boycott digital photography and devote ourselves to a 100 year contract with kodak and fuji film analog camera companies, to make sure they dont go digital ever"

i remember them days fondly..
back then if i was told a computer shoot-em-up game required 60gb(20x available space at time) and needed a internet speed that was 15x dialup.
i would have said its physically impossible. the shoot-em-up game wont ever work, no one will play it, it would require servers and warehouses of blah blah blah.


but today millions of people are spawn killing people online on Call of duty.. without a tear.

technology moves on and bitcoins requirements are well below todays available tech so we can increase capacity now and still have room to grow when tech grows with time.

dont play the "its 1996, call of duty infinite war is impossible, lets veto activision from ever making games forever"

20 years ago: 1-5gb


today: 128gb


20 years in the future:
"back when i was your age, people were crying that bitcoin needed servers when the reality was fingernail sized stores of data.. those were funny days"

seriously.. wanting to ignore a majority to push through a softfork. .. thats a bilateral split (gmaxwells buzzword) where they move off to their minority 25% chain.

foolish notion to intentionally split the network to force a softfork..
a softfork was only proposed to avoid controversy and avoid intentional splits. real funny anyone is proposing to do an intentional split to get a softfork.

if anyone is serious about intentionally splitting.. how about try using real consensus first. and give the community what they want, which will speed up activations of two community desires at same time without controversy or splits.

.. but going from soft straight to intentional split.. shows double irrational thoughts and illogical process

---

i even said how segwit fans can actually get some real data to show undecided groups to vote for or against..
get a segwit node to be an upstream module(gmaxwells buzzwording) meaning direct connection to a segwit enabled pool. and send a segwit p2wpkh tx to, for instance btcc.. let btcc add it to a block and see how the network reacts.

worse case btcc block gets rejected. in which case blockstream ($90m company) can easily pay btcc $15k for the wasted time for the test... atleast then the network can see how "backward compatible" it really is and see how it actually runs on the network and/or changes the network and/or causes issues to the network.

but nah.. blockstream know the risks of it and know its not as "backward compatible" as they presume.

if you disagree with my assumption that its not backward compatible then go show how harmless it is and get some proof to give to the undecideds.

instead of screaming to the community that anything non-core should fork off.. prove its backward compatible to not need to fork off..
but nah.. blockstream wont do it.
they know they over promised and under delivered

we all know that only gmaxwell and those in r/bitcoin want the community divided.
they call anything not core an altcoin. they try to get anything not core to split off (bilateral fork)
funny part is that all the other 70 differ versions (dozen different brands) are all running on bitcoins mainnet now, and for a long time and not causing issues.
yep nodes with 8mb block buffer are running right now and are accepting blocks and not orphaning anything and not autobanning or black listing opposing buffer setting nodes.
not rejecting transactions not becoming gate keepers not doing any harm..

yep nodes with dynamic block buffer are running right now and are accepting blocks and not orphaning anything and not autobanning or black listing opposing buffer setting nodes.
not rejecting transactions not becoming gate keepers not doing any harm..

unlike core features

those in r/bitcoin point the finger in the other direction when saying a proposal they want.. to make them look like the victim and gain sympathy.
they are the ones playing the psychology games. they are the ones that want dominance not everyone on the same equal playing field.
they are the ones desiring centralised commercial services.

i feel sorry for those in r/bitcoin being handed scripts to follow and handed the same scripts by dozens of people to make it seem like its real because more then one person is saying it to them.

if only those at r/bitcoin didnt just play follow the leader games and instead actually read the code and looked passed all the buzzword games that are thrown at them by the script writers.

please if there is anything you can ever be advised to do, it would be... research.

research consensus
research the code
research the context
research scenarios of how rational and researched context plays out

dont copy and paste summaries scripted to you
dont throw boring repeated stuff that has been made a moot point years ago
dont just play the victim card that someone mentioned someones name. and instead look for why and what was said about them

seems more people are screaming im fud because i mention gmaxwells name. rather than about why or what im actually saying about his plans and desires.

atleast research bitcoin and understand it. otherwise all your doing is attacking a pseudonym, not the proposals or features of bitcoin

lol wow, your reply including so much proof, so much rational explanation, such much logical and rational reasoning to come to your assumption..

.. oh wait it didnt

expensive?
nope

if nodes cant handle a certain blocksize. they will orphan a block and the pools wont push the limit.

this "gigabyte blocks by midnight" rhetoric im sure you read somewhere is fake scare stories.

the community want consentual natural growth by the network agreeing what the network can handle.

natural prgressive network dynamic consensus growth

no big leaps to terrabytes a day or any other scare stories you have been told.

also right now bitcoins 8 years of transaction data can sit on a fingernail (128gb microsd)

nah, r/bitcoin trolls want to sybil attack a opinion poll by getting the blockstream trolls to all vote in favour of segwit even when the majority of thos voting dont even run a node or do mining.

polls like this are just keeping the civil war alive and avoiding "consensus" by only having 2 options and worded to make it sound like the options can only oppose each other.. rather than a mutual (consensus) agreement.

i stated this poll needed a third option of 'yes if both were included' (not verbatim) near the start of the topic. but the OP refused to be rational

there are many ways to have a dynamic protocol

put short nodes FIRST have to accept a certain size for the network to happily accept without much/any orphan drama
next pools need to be rest assured that if pools made blocks bigger then current consensus it wont cause much/any orphan drama.

it is not as simple /silly as pools make bigger blocks if the mempool is overfilled due to an abuser flooding it..

firstly node need to flag their acceptance they can cope with Xmb.. then pools flag their intent to make anything upto xmb to give a prompt for the laggers to adjust to xmb or be left unsynced when pools deem it safe to move forward.

then when it meets a certain safe majority level pools dip their toe in the water.
EG imagine majority nodes flagged 2mb was ok.. pools then flagged a majority ok to make 2mb base blocks..
at a certain point pools 'test the water' by making a 1.001mb block to see the orphan risk, then the next block maybe 1.002mb and so on safely incrementing up, naturally with demand until whenever blocks get to be 2mb full due to demand.

its not going to be a 2 mb or a 1gigabyt by mindnight thing. nodes and pools will do it safely.

after all.. did pools and nodes jump from 0mb to 1mb overnight in 2009-2015.. nope.
after all.. did pools and nodes jump from 0.5mb to 1mb overnight in 2013-2015(after the sipa caused db fork event).. nope

it was natural and safe and orphan mitigating low risk movements.

are these done using the exchanges that represent the currencies mentioned.
or
by targeting USD and converting to other currencies using a separate forex conversion from USD to the others.? (hoping the former and not the later

if you read what gmaxwell wrote. not with a blind devotion of gmaxwell hat. but an methodical and open minded hat on you will see he avoided the critical context and was wishy washy about the critical stuff and just knit picked the stupidest things he can find.

EG arguing about version numbers.
EG arguing about how segwit nodes dont have to white list segwit nodes..

when my posts on previous page and even segwits own guide, were about whitelisting old nodes (downstream modules as gmaxwell wants to call them)

my post on previous page with the images explained how old (downstream) nodes wont accept segwit transactions. so segwit has to be the gate keeper(upstream) in the middle joining to the pool not randomly on the outside going through an old nodes.

but hey. i bet you just skimmed what he said and just thought "oh well its gmaxwell lets trust him"

gmaxwell has been known to slide around the truth and throw in buzzwords to make what one person says.

he tried to do it before when i said about his confidential payment codes CPC being upto 1kb+.. he said there was no such thing as a confidential payment code in confidential transactions,
but he soon shut up when i started using his buzzwords of his "confidential Pedersen commitments" CPC being 1kb+

so dont let him throw big words at you and make him side step the critical stuff. because he is known to sidestep issues and brush things under the carpet if you dont use his buzzwords

eg he will deny intentional splits but will agree if you call it a bilateral fork..

. in my reply to him you will see what i mean where he side steps the context of the critical stuff

segwit in regards to real scaling, is a temporary gesture.. a one time boost/stopgap
lets say it was a full release last april and it got activated by june last year.. by this month now. all of its advantages would have been seen and we would still be needing dynamic blocks now.

the best solution is for core to just release a dynamic block version along with segwit. and join the level playing field.

late 2015 core devs agreed to a plan of segwit mid 2016 and dynamic blocks by mid 2017
but in spring 2016.. core started back tracking saying nothing was agreed and they were just independent devs and had no ability to put code into bitcoin core in regards to dynamic blocks... (luke jr received alot of backlash because of that).

pools are not going to break the rules and push for something if nodes are not ready for it..
which core knows. so they have prevented having a dynamic block release. and now done their own temporary feature as soft... but shot their self in the foot because again pools wont push forward with a big change unless there is a big node acceptance. even if devs feel that nodes dont deserve a vote. pools are smart to know for validation security nodes have a place in the network.
hense why segwit is holding at 75% pools undecided about segwit

you literally said it in the same reply.. they do not relay them.. meaning its an issue..
if a segwit node connected to a old node and then the old node connects to a pool... the pool wont get the tx.. because the old node drops it.

segwit node-old node- pool

so this is where segwit has to mess with what it connects to, to ensure its tx's get relayed to a pool
old node-segwit node- pool

or to get past your padantic sidestepping.. segwit by default looks to find segwits first and then after activation it will have to white list old nodes
edit: old nodes(downstream) of the segwit node(upstream/gatekeeper)

a malicious pool could include it in a block and then spend it. hence why you fear making transaction now with p2wpkh keys right now.. and have not included the p2wpkh key generation for mainnet use in the versions you have released so far.


fine you are releasing something unrelated in 0.14.0. but 0.14.X or 0.15.X... whatever the version number will be that includes MAINNET utility of p2wpkh and p2wsh key generation wallets, wont be released until after segwit activation.
im kind of thinking your just being knit picky about the version number rather then the fact of the p2wpkh and p2wsh key generation wallets available only AFTER activation, context.
again lets not play your version number knitpicky game (facepalm at ur fail)
the version with the p2wpkh and p2wsh key generation wallets, AFTER activation will ensure there is a path from a segwit node to a pool because as you yourself said old nodes have issues and wont relay segwit unconfirmed tx's (red text at top)

right now segwit is not activated so nothing now needs to change as there is only one varient of data being created right noe..
but in the context of after activation..

the context of it is instead of white listing OLD nodes as special and then send the blocks in a format old nodes understand. they will just connect to other segwit nodes and let the pools send whichever version block needs to go to whichever version node.
i even quoted the guide that says it too.. where messing with old nodes is a hassle(needing to white list old nodes.. so human psychology is that people wont whitelist old nodes but prefer segwit nodes.
you are really chomping hard at the bottom of the barrel of words.. rather then being honest of the context.


yes your segwit nodes are already avoiding connecting to older nodes(even when right now its not nessessary).. i hear many people shouting loudly how they are not white listing old nodes already.
oh im inaccurate because my image was a 50/50 but i bet your claim is that its not a 50/50 because you see 61%... (facepalm).. the context is that old nodes and new nodes are not going to interact as much..
again knick pick the numbers if you want... but atleast try to aim at being honest with the context. because it is a failure of your honesty and a failure of you actually making a point by side stepping the context with silly knitpicks.

you again are petty knitpicking.. i never said a node RECEIVES 2 variants.. i said a pool or a node that has been generous to white list old nodes. has to CREATE 2 varients (your buzzwords, stripped and unstripped). sending one varient to new and one variant to old..
petty knit picker. you have still not said anything that makes a point that differs. you are just swapping common speech for your buzzwords

so because you have enough gatekeepers old nodes are meaningless to you
if segwit activates and lets say nodes stayed at under XX%.. by looking at the context of your reply. seems you will just leave oldnodes reliant on the very few generous segwit nodes and pools that do white list old nodes. but not care much about old nodes being part of the network because segwit are the gate keepers


so your context is that old nodes are not important. and ok to ignore old nodes..
oh and as for bare minimum of segwit nodes.. shall we let you retry you explaining the relaying of unconfirmed transactions needed to ensure segwit transactions reach a pool (instead of your side stepping the concept to argue about the number version).

yes you can run a old node without changing. but ur relying on segwit nodes to do the gate keeper duties. and filtering data to an old node.
if you had integrity, you would actually inform people their old node is not full validating.
if you had integrity, you would actually inform people their old node is reliant on a sgwit node being the gate keeper.
you wouldnt just stroke peoples heads and tell them its ok to be treated as second class like its nothing.


a hard fork using consensus only activates with high majority. and i personally have been honest to say that old nodes not upgrading will be left unsynced.. yes its harsh. but atleast its honest.

side node.. "downstream modules".. is that what your buzzword is for the older nodes your segwit nodes have to whitelist. while segwit use the upstream modules buzzword i called the gatekeepers.. ill remember that.

it wont activate unless there is consensus.. it wont create an altcoin. please research more and stop reading scripted scare stories by those in the blockstream camp that want intentional splits.

put it this way right now nodes can have any blocksize setting they please. 2mb 4mb 8mb 3.5mb randomnumber, etc etc. and everything carries on
yep all the nodes with upto 8mb in their setting can still happily accept 1mb blocks because the rule is anything below 8mb is acceptable. again for emphasis, they can happily accept 1mb and no rule is broken.

but until the majority of nodes accept X... pools wont even risk agreeing to X.. so there is no contention..
worse case is orphan risk.. but ultimately one chain(after orphan drama subsides) if pools pushed at a low consensus..

again for emphasis
pools wont make changes, unless there is majority consensus that their attempt will be accepted and not rejected by the nodes..

this is why 75% of pools are undecided about softforks. because they can see nodes are not ready.
even though in a softfork, user nodes are not given a vote. the pools(their smart independent brains and eyes) still need to see that nodes wont have a problem, to ensure pools get paid rather than work hard for nothing.

yes the transactions are put back into the mempool.
imagine block A and block B got solved at same time..

because 2 different pools done the blocks and indepentdantly decided what their block added.. some of the same tx's would be in each other block. and some transactions may differ.. eg pool B decided to accept some fee free transactions but pool A decided to mainly look at the high price and some tx's middle priced would be in both..

lets say A got orphaned for a reason.
A puts all transactions back into mempool and then looks at B and sees whats confirmed to know which transactions to not handle in A's next attempt because B confirmed them


miners (ASICS) dont handle or see the full 1mb of data.. they just get the hash of that data and then rehash it with a nonce until it creates a new hash which meets the solution requiring a certain amount of 0's at the start of the new hash.


once an asic finds a hash solution.. it is just handed another hash (new block attempt) to start.. asics dont care about tx data. they just re-hash whatever hash they are handed.. in short asics(miners) dont validate and check transactions

if the pool gets told to orphan the full block the pool handed out to the network because of a problem. the pool then makes a new block hash based on new block data and sends the hash to the asics to start again.

what asics only see as negative is the wasted time working on something that ultimately didnt end in the network longterm, thus no pay for the wasted time.

double spends are a concern to the network because the block is sent out to the network and then thrown out if it was a bad block or a better block was preferred.

so while on the network for those couple seconds or more.. some merchants may have ticked a box to say 'yep confirmed' and released goods/services/fiat to the customer.. then 2seconds or more later.. that block is gone. but the goods/services/fiat is already handed to the customer...

usually in 99.996%-99.75% the tx they thought was confirmed sits back as unconfirmed again until included in the next block so no harm done ultimately but just waiting to reconfirm....
but
as said in previous post (on a good no drama day) in 0.004% or 0.25% chance of the tx not being added to the next block for either malicious reason or unintentionally struck off by how the network works.

(note there are other ways to mess with tx's in an orphan event. but lets not complicate things)

this small under 1% risk is lowest odds. and not strict numbers they are variable. for instance when there is a new feature being added (code rule) like the current 95% soft fork. could result in 5% orphans occurring(higher risk) and many malicious people may increase their malicious attempts ontop due to the "perfect storm to go on a riot" mindset. so it could end up being over 5% risk instead of one 2500th of 1% risk of malicious intent..  or due to the higher blocks.. less 'free transactions' get accepted so the risk of a free transaction not getting re-confirmed becomes riskier.

so its still a risk and worth waiting a few blocks
like some say 1confirm for small amounts (coffee value) 6 confirms (car/house value) during normal no drama transacting.

---

the terminology was that if there is a bad block found that has no competing better block yet. its just called a rejected/invalid block.
however if after getting the block(a1) a new block is built ontop(a2).. but later a competing block(b1)+(b2) has something preferable where the network has to orphan (a2) because (b2) was linked to a different previous block(b1), making (a1 <-the parent) get rejected thus (a2) is the orphan because it lost its parent.

though, these days we use the term 'orphan' for any block that initially had a solution but then thrown away and something else that takes its place for multiple reasons. whther the network had to reject any parents or not.

there have been times in the past where a block with SEVERAL parents(previous blocks) gets orphaned/rejected off in preference of a better chain of blocks

hense the 6confirm mindset many people have, because a chain of 5 blocks can ALL get orphaned as it has happened before.

usually during feature activation events (the day segwit or dynamic blocks reaches 95% to activate) the orphan risk is higher so some say maybe wait 10 confirms for house value amounts.

lets say there was a 51% attack or a controversial activation of a rule (very high orphan risk) some people will say wait 72-144 blocks (12-24 hours) before trusting

by going soft they went against node consensus.. thus its only having to convince 20 pool managers into a limited consensus, instead of 5600 node users..

this is another reason pools think soft is wrong because its pushing something nodes are not ready for, and it can change the network dynamics. but because its the pools that decide.

the devs however can take the glory if everything works, saying 'see soft is better'
BUT devs can blame it on the pools if it goes wrong. saying 'well they consented to it, they activated it'

not when the fee is more than an hours labour in those same developing countries



less risk than pickpocketing your debit card or phone. because its on your arm so you would notice someone playing with your arm more so the someone sliding hand in back pocket

i came up with the wristband concept and created the image during my exploration of what the banks are doing to update themselves (barclays UK wristband) and barclays getting involved in hyperledger)

i have thrown a few concepts out into the community to let people grab if they want to develop.

but cant remember seeing "sigsafe", in the past, even though i been around since 2012..

maybe the guy from sigsafe should work with the hardware wallet teams and restart his project as more of a smartwatch or just launching it as the keyfob.

as i feel that noob/non-techy people would find 'touchless' pay beneficial compared to current bitcoin payment methods.
as i feel the requirement of current hardwallets needing usb and browser extentions, are missing the point of airgapped utility.

good find though. cheers seems im not the only one thinking outside of the box