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

everyone ignore the troll with the initials C B
he does not know the difference between a consensus fork and a intentional split

especially when its only been core that have been begging everyone else to intensionally split(bilateral)
kind of foolish for him to bait a reply with twisting the rhetoric of who wants what, by pretending its the community wanting it when its obviously the segwit fans..

a hard fork is just an empty umbrella term that has several subcategories.. a hard fork buzzword is meaningless if you dont understand which subcategory has been proposed.

softfork: consensus - >94% pools no banning/intent of minority. result: small 5% orphan drama then one chain. minority unsynced and dead
softfork: controversial - >50% pools no banning/intent of minority. result: long big% orphan drama then one chain. minority unsynced and dead
softfork: bilateral - intentionally ignoring/banning opposing rules and not including them. result: 2 chains

hardfork: consensus - >94% nodes, then >94% pools no banning/intent of minority. result: 5% orphan drama then one chain. minority unsynced / dead
hardfork: controversial - >50% nodes, then >50% pools no banning/intent of minority. result: big% orphan drama then one chain. minority unsynced / dead
hardfork: bilateral - intentionally ignoring/banning opposing rules and not including them. result: 2 chains

funny how when they say softfork they use best case scenario.
funny how when they say hardfork they use worse case scenario. as if worse case is the plan, when its not.

the community want in general "consensus", preferable one where nodes have involvement (harder to achieve).

not that surprising.. it was well announced.
"bitmain new xinjiang farm"

i remember in november/december antpool(bitmain) announcing they were adding a new farm. which would be live by december.
they were at about ~330phash then. now at 500peta.

orphan risk can lead to double spend attack as you say. so you are near spot on. especially if while orphaned a mallicious spender then uses RBF to strike off the then (re-)unconfirmed tx before its put into a new block. to substitute it with another tx where the values/destinations differ
(more so the finney attack on the next paragraph after the 'race attack' you linked, but with new features like RBF which wasnt around in hal finneys time, to make it more possible to adjust transactions when an orphan occurs).

but not to try confusing the matter more.. the reason i say 'not quite', 'more so' and 'near spot on'. is that on a usual day is 1% of orphan. the risk of a finney attack is 0.0004%.. (because you only care about 1tx of the whole block. so chances is one 2500th of 1%)
there are other things..  like someone that didnt pay a fee getting into a block.. but if that block orphans it again sits as unconfirmed but may not get into another block due to no fee.. risk of this is could be 0.25% (if pools use old preference of 25% of a block has no fee, divided by orphan risk)
there are many ways that tx's cant be trusted. not just maliciously. but also unintentionally struck off by how the network works.
but now thats getting too detailed of the behind the scenes where things are no longer static but variable and confusing
 

as for CLTV and CSV
firstly while unsettled (inside LN) CLTV and CSV are not penalties. they are just terms of agreement. but when broadcast. the tx is confirmed onchain.. and the CLTV is a maturity period (like the block rewards 100 confirm waiting period 'maturity') where it cannot be spent. and the CSV is a special output that the second party can spend the intended recipients funds before the maturity expires.

so even though its confirmed on chain the intended recipient cant spend it until matured and is at risk of the other party revoking it during maturity.

this is like paypal or a bank having a 3-5 day 'clearing period' and a chargeback able to occur in that time.
so even if you see its confirmed but unspendable, lik the bank saying unavailable balance and separately available balance. dont presume your guaranteed that 'unavailable' money until its available.

im sure all the block explorers will update their graphic user interfaces to alert people if a tx contains CLTV and CSV.. but for now it has to be done manually by knowing what to look for in the raw data

read my post again .. edited to further clarify
"just to clear the terminology up
orphaning off a block not because its invalid but because of which pool sent it. is controversial because its not an invalid block. meaning different nodes are accepting different blocks. this causes orphan drama (which will eventually sort itself out to one chain with the minor chain unable to sync)
[this is a contraversial fork that just creates orphan drama then settle down as one chain,  and minority unsynced from network]

that then [can] lead to needing to ignore the opposing nodes too [if you want the minor chain to start building its own chain without orphaning.. or if the major chain doesnt want to see the minor chain endlessly requesting and rejecting blocks.]
this is not consensus, [nor controversial, this is a intentional split aka bilateral fork]

consensus is agreement to accept the same data and same rules where the majority accept all the valid blocks (without any biased pickyness) leaving the minority simply unable to sync [ignoring blocks and nodes simply due to a 'brand war' leads to an intentional split] "

errr..

"In order to protect your long-term interest when making Bitcoin transactions, it’s important to wait for at least six network confirmations before deciding that the transaction is 100% valid. As a rule of thumb, the security of any individual transaction is closely related to its age, with older transactions being far more resistant to change when compared to new transactions."

still not completely correct.

"In order to protect your long-term interest when making Bitcoin transactions, it’s important to wait for at least enough confirmations before deciding the risk is negligible. As a rule of thumb, the security of any individual transaction is closely related to its age, with older transactions being far more resistant to change when compared to new transactions. the risk is 1%-5% dependant events, features update periods, so 6 confirms would be advised for larger value transactions"
..
the 1-5% explains and covers the reasons for 6% and also what to do at a 95% (5% risk event)
separately..
because CLTV and CSV is an actual feature compared to previous years. its important to mention tx maturity.. especially when its going to be used alot more by the time your guide gets popular.

maybe add,
"if your transaction has been involved in a locked-in contract such as a side service like Lightning, usually the expiration of maturity occurs after more than 6 confirms. but dont trust it as valid/guaranteed until the maturity expires."

p.s
no need to name drop. just ensure if its a master guide it's not glossing over the important bits people need to know

can people stop thinking china is a power house

lets simplify it

eastern exchanges: 1 person  moving 12.5btc day-trading every 30 seconds = 36,000btc "trade volume" but only 12.5btc holding
vs
western exchanges: 100 people each moving 0.01btc daytrading ever 30 seconds = 2,880btc "trade volume" but only 100x 0.01btc holding (btc)

ok.. keep that concept in mind.

now imagine out of the coins created by pools 1800btc.. where the top 6 eastern pools (50%) only put 10% in public markets (6 people 90btc combined)
imagine westerners 10btc make it to public markets and are handled by 1000 people with 0.01each (1000 people 10btc combined)

eastern: 90btc moving every 30 seconds= 259,200btc volume but only 1.5btc per person with only 6 people
vs
western: 10btc moving every 30 seconds= 28,800btc volume but only 0.01btc per person with 1000 people


so i done it twice because people think small numbers of first example is not representative of reality.. so second example is larger numbers..
but the point is volume does NOT = more users/better adoption/ more popularity / whole country involvement.

EG dynamic blocks starting 2mb base 4mb weight as default start. making both core and the community happy and then the community raise the limit when they want and need to without dev intervention/prevention.
nodes flag what they are capable of and it moves when the majority of nodes can handle it.

thus natural progressive growth and not the misinformed large leaps to gigabyte blocks by midnight false rhetoric.

everyone is happy

segwit AND dynamic blocks.

which is also something nodes with 8mb max would accept.

by doing dynamic blocks the community get the consensus to up the blocksize naturally when requires and copable.. rather than having to play another oliver twist "please sir can i have some more" game with devs in a few years if it was just a fixed dev handed limit

yep
4pence UK is an hours labour in Cuba.
84pence UK is 21 hours labour in Cuba.

so while bigname developers in america pretend that while getting $1m a year from blockstream $480 an hour. they have lost sight that $0.75 is alot. they see it as less than 1second of labour.
so while volunteer in america pretend that while getting $7.50 a hour from their day jobs. they have lost sight that $0.75 is alot. they see it as less than 6 minutes of labour. they even down play it that bitcoin is 'normally' 8cents which is about 30seconds of labour.

they cant see the big international picture

because people have talked to him via email, on forums and IRC during 2008-2010. people have also analysed his written messages and all are saying it was one person using that pseudonym.
and yes this also means he was a sane person with no multiple personality disorders.

but like i said other people with other paeudonyms helped him develop and debug bitcoin.