Rannasha schreef op maandag 23 april 2018 @ 11:12:
[...]
Je mist het punt dat ik maakte volledig (zoals gebruikelijk).
Bedrijfskritische software (wat een cryptocurrency-node meestal zal zijn voor bedrijven die dit draaien) iedere 6 maanden updaten met een update die wijzigingen in de functionaliteit aanbrengt? Vergeet het maar. Iedere IT afdeling van een bedrijf van redelijke omvang zal hier naar kijken, een beetje giechelen, en overgaan naar een andere cryptocurrency.
Dan is Bitcoin-BTC gedoemt om voor eeuwig een blocksize limiet van 1 MB te hebben wamt die patch is van 2010, en als 8 jaar niet lang genoeg is ... zal Iedere IT afdeling van een bedrijf van redelijke omvang zal hier naar kijken, een beetje giechelen, en overgaan naar een andere cryptocurrency.
Als je dan alles op LN wilt doen met zo weinig mogelijk on chain tx om ver onder de 400 000 tx per dag te blijven heb je grote centralse hubs op LN nodig zodat alles daar gedaan kan worden zonder te veel op de chain te settelen.
Rollout processen zijn traag. En met goede redenen. Je moet de update testen, alle code, processen en documentatie die van de software gebruik maken moet worden aangepast.
Hangt een beetje van de code af, de code die ik gepost heb veranderd gewoon een soft limit die ooit als bescherming door Satoshi is toegevoegd. Heel iets anders als de 32 MB limiet die in het P2P transfer protocol zit. Als je daar documentatie voor moet schrijven gaat er iets grondig mis. Ik heb het niet over het toevoegen van features of dergelijke. Ook niet over een bugfix.
En dat moet worden getest. Vervolgens moet de daadwerkelijke rollout worden gepland, inclusief een fallback, wat op zichzelf al een uitdaging is, want je kunt niet zomaar terugvallen op de vorige versie van de software bij een hard fork.
Zoals ik al zei het hangt allemaal af van wat er nu precies wijzigt. Bitcoin-qt software verandert elke release. Alleen die veranderingen zijn niet op protocol level. Het wijzigen van de 1 mb soft limit is wel op protocol level. Maar dat veroorzaakt helemaal geen enkel probleem, bitcoin heeft van 2008 tot 2010 prima gewerkt zonder deze soft limit. Je zult toch echt eens een keer moeten uitleggen waarom het weg halen van deze softlimit nou zulke grote problemen gaat veroorzaken terwijl iedereen die in Bitcoin zit met eigen ogen heeft kunnen zien en zelfs persoonlijk meemaken wat de gevolgen zijn geweest van het niet weg halen van deze soft limit.
En dat allemaal met deadlines die extern bedacht zijn. Dus als het even niet handig uitkomt met drukke periodes binnen het bedrijf, pech. Updaten of niet meer mee doen.
Voor grootschalige adoptie (dus niet alleen hobbyisten en startups) is een beleid van verplichte updates iedere 6 maanden met een keiharde deadline voor implementatie funest.
Voor grootschalige adoptie gaan gebruikers gewoon SPV clients gebruiken en die hoeven niet mee te updaten, alleen de nodes waar deze mee verbinden.
Zie het meer als Google die zijn eigen software binnen zijn servers elke 6 maanden aanpast. Miners en grote bedrijven die genoeg betalingen doen dat ze een non mining node draaien zullen moeten updaten. Maar het is sowieso in hun beste intrest dat er genoeg onderlinge coördinatie is zodat de gebruikers nergens last van hebben.
Als een groot genoeg gedeelte van het netwerk laat zien dat ze niet elke 6 maanden willen updaten kan gebeurd het ook niet. Het zijn miners die een update initialiseren, maar die willen natuurlijk niet het risico lopen om hun gebruikers weg te jagen. Bitcoin-BTC heeft dat risico wel genomen ... door het totaal in het extreme het maar altijd te hebben over het risico van wijzigingen, precies zoals jij nu doet. Zelfs als de wijzigen gewoon het verwijderen van een bescherming is die in 2010 wel zin maakte maar sinds ongeveer 2013 al lang niet meer.
De reden dat Bitcoin Cash wel elke 6 maanden gaat proberen dit te doen is nu juist om het andere extreme te voorkomen, waar een group devs het succes van Bitcoin kan verhinderen door iedereen wijs te maken dat verandering te gevaarlijk is, onafhankelijk van de context. Door te doen alsof elke wijziging op protocol level gelijk is aan elke andere wijziging en dat de risico's bij elke aanpassing van de code hetzelfde zijn. Dat is gewoon niet zo.
De toekomst zal uitwijzen wie er de beste kijk op heeft.
[
Voor 4% gewijzigd door
Kain_niaK op 23-04-2018 11:37
]