Bitcoin Forum
May 21, 2024, 04:05:53 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 [2]  All
  Print  
Author Topic: Researching Bitcoin for a Presentation - coming here to fact check  (Read 238 times)
Volition (OP)
Newbie
*
Offline Offline

Activity: 12
Merit: 0


View Profile
March 17, 2023, 06:14:06 PM
 #21


above is the image representation of the data of blocks involved in activating segwit

(flags= small reference in block data that shows desire/preference for something)

as you can see from november 2016 when segwit was first proposed and allowed flagging. until july 2017 only got under 50% wanting segwit activated naturally(genuine open choice)

however in May there was another proposal. called the NY Agreement by which from june, many economic nodes and some large mining pools agreed that if the rest of the mining pools and the NYA flag a month long 90% acceptance they would start rejecting(subliminal threat) blocks that disagreed with segwit to cause a statistical 100% acceptance even if not a 100% opinion acceptance... to help activate segwit.. but they wanted a 2mb block later in the year(in hindsight they never got the 2mb blockspace)

the NYA proposal then resulted in the segwit flags showing as an unnatural growth to an unnatural 100% acceptance of segwit in the july-august period which resulted in segwits activation

the group that strongly opposed it decided that they wanted to continue as is so they started accepting blocks that were normal blocks. (ones segwit rejected)
segwit was declared by the economic nodes(merchants/services) as bitcoin and the opposition as an altcoin where the altcoin had to change things in its minority chain to ensure the chains dont converge by the end of august. (so that the flag can be taken out/to not need to continue having 100% flagging which was used to prevent differing blocks on the bitcoin side)


this version of events is backed up by actual agreements. actual code and actual blockdata that is immutable and is strongly uneditable by 6 years of confirmations

Thanks, is this image something in the public domain I can use?

Prior to this, what were the historic precedents for how consensus was found to activate updates / choose proposals?

franky1
Legendary
*
Offline Offline

Activity: 4228
Merit: 4490



View Profile
March 17, 2023, 07:11:08 PM
 #22

image is from reddit

its been public domain for years
https://www.reddit.com/r/btc/comments/8golyn/what_caused_the_miners_to_activate_segwit_threat/

also you can look at the blockdata itself manually/using a script/algo and pull the data yourself

I DO NOT TRADE OR ACT AS ESCROW ON THIS FORUM EVER.
Please do your own research & respect what is written here as both opinion & information gleaned from experience. many people replying with insults but no on-topic content substance, automatically are 'facepalmed' and yawned at
Volition (OP)
Newbie
*
Offline Offline

Activity: 12
Merit: 0


View Profile
March 17, 2023, 07:32:40 PM
 #23

image is from reddit

its been public domain for years
https://www.reddit.com/r/btc/comments/8golyn/what_caused_the_miners_to_activate_segwit_threat/

also you can look at the blockdata itself manually/using a script/algo and pull the data yourself



Thanks, I'm not a dev though and sure I could learn, but I need to be doing other things with my time.

So has the consensus on how Bitcoin is updated changed over the years?
franky1
Legendary
*
Offline Offline

Activity: 4228
Merit: 4490



View Profile
March 17, 2023, 08:09:33 PM
Last edit: March 17, 2023, 08:32:20 PM by franky1
 #24

Thanks, I'm not a dev though and sure I could learn, but I need to be doing other things with my time.

So has the consensus on how Bitcoin is updated changed over the years?

yes

early on. new blank opcodes(no rules) were initially disabled, whereby rules were then applied to opcodes and then when there was somewhat majority readiness, they would activate the opcode to use such opcode AND enforce verification of a newly used opcode rule by having nodes ready first to know what is being validated at activation time(in short not allow usage of an opcode until network was ready)

some attempts of doing things "soft" resulted in forks which is where they then raised the majority from 55% to 75% to 90% and disabled opcodes to only activate at majorities.. (2012-13)

then they done the 2017 mandatory miner activation of august 1st with the block rejecting threat to push an activation, but only requesting miners and economic nodes to show readiness.. not user node majority..  
they did however delay the wallet utility(tx creation using opcode) until 2018

the activation also allowed the creation of another layer of set of opcodes beneath the first set. some were disabled some were enabled(op_nop). where user nodes would just pass the active opcodes as acceptable without knowing the rules

and since then (2021) things have gone super soft where new opcode sets are not disabled upfront(op_success) meaning it doesnt require majority node readiness to enforce new rules and instead just pass whatever data is put after such opcodes unchecked. and its then for nodes to then code in a rule adhoc later, if they should choose to

strange thing is. many dont want to code in rules into the active opcodes,  thus this avoidance of setting rules for opcodes means that it then allows any crap data to be put into blockchain data unverified/unruled, due to lack of rules in the active opcodes that should have been disabled by default
 where they should only have become active once rules/formats are set for the opcode utility and only when there were nodes ready with the new ruleset to know what to look for.


I DO NOT TRADE OR ACT AS ESCROW ON THIS FORUM EVER.
Please do your own research & respect what is written here as both opinion & information gleaned from experience. many people replying with insults but no on-topic content substance, automatically are 'facepalmed' and yawned at
Pages: « 1 [2]  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!