Bitcoin Core bleek jaar lang vatbaar voor double-spending-aanval

De Bitcoin Core-software voor het Bitcoin-netwerk had een jaar lang een ernstige double-spending-kwetsbaarheid, die in theorie zelfs tot een blockchain-fork van getroffen nodes en bugvrije nodes had kunnen leiden. De kwetsbaarheid is niet misbruikt.

De kwetsbaarheid, met aanduiding CVE-2018-17144, is vorige week verholpen met de release van Bitcoin Core 0.16.3 en 0.17.0rc4. Aanvankelijk kregen de ontwikkelaars een melding over een denial-of-service-bug, maar bij nadere inspectie kwam een inflationkwetsbaarheid aan het licht, zo blijkt uit de full disclosure van Bitcoin Core.

Optimalisaties in Bitcoin Core 0.14, die vorig jaar maart verscheen, hadden als onbedoeld bij-effect dat nodes konden crashen bij de verwerking van blokken met transacties die coins meerdere keren probeerden te besteden. Met de komst van Bitcoin Core 0.15.0, iets meer dan een jaar geleden, werden de problemen groter. De aanpassingen zorgden er namelijk voor dat nodes de double-spend-transacties in sommige gevallen accepteerden.

Bitcoin Magazine beschrijft dat een kwaadwillende in het ergste geval de hoeveelheid valuta kon vergroten door zijn eigen coins te kopiëren. Nodes met de kwetsbare Bitcoin Core-versies zouden deze coins accepteren, waarmee theoretisch een fork kon ontstaan. In de praktijk zou dit onwaarschijnlijk zijn, omdat de oudere, niet getroffen nodes waarschijnlijk een te lage hashrate zouden hebben.

Inmiddels zou meer dan helft van de hashrate een upgrade hebben gekregen naar Bitcoin Core 0.16.3, waarmee een aanvaller niet meer met succes de valide blokketen kan verdringen. Bitcoin Core is de naam van de softwareclient voor het Bitcoin-netwerk.

Reacties (98)

[.oisyn]

De specifieke condities voor het triggeren van de bug zijn dat een input* meerdere keren gebruikt wordt in een enkele transactie. Hierop wordt wel gechecked voordat de transacties de mempool in gaan (dus als ze door gebruikers worden aangeboden aan het netwerk), maar van transacties die daadwerkelijk in een blok terecht komen werd ten onrechte aangenomen dat deze altijd juist zijn. Een malafide miner zou dus foutieve transacties op kunnen nemen in de door hem geminede blokken.

In 0.14.x leidde dit tot een crash (er werd wel gecontroleerd, maar met een assert() ipv een juiste foutafhandeling, wat resulteert in een process exit). In 0.15 en verder werd dit verergerd door een herdesign van hoe transacties getracked worden. Er werd niet meer gekeken of een input al gespend was, maar puur of hij als output bestond in een voorgaande transactie. Als die output in een vorig block stond, was de transactie vrij om de input meerdere keren te spenderen in een enkele transactie.

Een kanttekening hierbij is wel dat de miner hierbij een groot risico loopt. Hij moet succesvol een block minen (wat 'm normaal gesproken zo'n $80000 oplevert momenteel) die eigenlijk invalid is door de betreffende transactie, en daarna heel snel handelen door de betreffende "fake" coins om te zetten in andere assets aangezien de miner weet dat de betreffende chain die hij zojuist gecreëerd heeft binnen no time geen waarde meer zal hebben. Want zodra zo'n blok verschijnt gaan er natuurljik allemaal alarmbelletjes rinkelen. Een groter kans op succes is als hij de BTC markt zou shorten, want zodra zoiets gebeurt schiet de waarde natuurlijk naar beneden, maar zelfs dat is niet zonder risico.

* Even ter verduidelijking, Bitcoin (en de meeste andere blokchains) hanteren een UTXO model. Dat staat voor Unspent Transaction Output. Transacties specificeren niet "X bitcoin van adres A naar adres B", maar: "de outputs van voorgaande transacties T1, T2, ..., Tn gaan naar de adressen A1, A2, ..., An met hoeveelheden X1, X2, ..., Xn". Een transactie specifieert dus 1 of meerdere inputs en 1 of meerdere outputs. Die inputs zijn ongespendeerde outputs van voorgaande transacties. Een output van een transactie is gespendeerd als hij gebruikt is als input voor een andere transactie. Een transactie gebruikt altijd álle bitcoin van een output - als een output 10 btc is, dan kan een transactie daar niet slechts maar 4 btc van gebruiken en de rest laten staan. De overige 6 btc zal dan typisch worden gestuurd naar een adres wat in eigen beheer is. Overgebleven bitcoins die niet naar een output worden gestuurd zijn bestemd als miner fee.

[Reactie gewijzigd door .oisyn op 25 juli 2024 17:21]

[Rannasha]

Merk op dat deze zelfde kwetsbaarheid ook aanwezig kan zijn in software van cryptocurrencies die van Bitcoin zijn afgeleid. Zo waren bepaalde implementaties van BCH, LTC en DASH kwetsbaar. Maar er zijn nog veel meer cryptocurrencies die gebaseerd zijn op Bitcoin Core. En sommigen van deze zijn wellicht niet zo snel met het doorvoeren van bugfixes. Nu de details over de kwetsbaarheid openbaar zijn, levert dit een gevaar op voor de kleinere cryptocurrencies die op Bitcoin gebaseerd zijn en nog geen update hebben die voldoende verspreid is.

[.oisyn]

Het is jammer dat sommigen wat onverantwoordelijk zijn omgegaan met het publiceren van details over de bug (hierbij doel ik overigens niet op de ontdekker, een dev van Bitcoin Unlimited, een Bitcoin Cash client, props naar hem/haar!). Aanvankelijk werd alleen de DoS-bug vermeld, maar door de code change te analyseren zijn er mensen onafhankelijke van de bugreport zelf tot de conclusie gekomen dat een double-spend mogelijk was. Nadat deze informatie gepubliceerd werd, is Bitcoin Core dus enigszins geforceerd geweest om met een full disclosure te komen terwijl heel veel coins nog helemaal niet de kans hebben gehad om de boel te fixen. Sommigen zeggen dat de fix misschien beter in wat refactor-changes begraven had moeten worden zodat het niet heel duidelijk was wat de fix precies oplost. Persoonlijk denk ik niet dat dat nou zo'n goed idee was geweest...

[Reactie gewijzigd door .oisyn op 25 juli 2024 17:21]

[Codin the Coder]

> ...de ontdekker, een dev van Bitcoin Unlimited, een Bitcoin Cash client, props naar hem/haar!

Weet je dat zeker?

Volgens de full disclosure is de ontdekker ene 'earlz'.

Hier hebben we hem. Als ik zijn github en website er zo eens op nalees, lijkt het er niet op alsof hij zich bezig houdt met bcash.

[Kain_niaK]

De ontdekker is Awemany (pseudoniem)
reddit account.
Thread op /r/bitcoin.
Thread op /r/btc
Awemany is een coder for Bitcoin BU en Bitcoin ABC, beide zijn software implementaties van Bitcoin die verschillen van Bitcoin Core. Bitcoin BU (Bitcoin Unlimited) is in 2014 gestart en vanaf de grond af gebouwd. Bitcoin ABC is een fork van Bitcoin Core, die in 2017 gelanceerd is en tot Bitcoin Cash heeft geleid.

Bitcoin BU heeft node software voor zowel de BTC chain als de BCH chain. De BTC chain node sofware heet BU en de BCH chain software heet BUcash.

Andrew Stone is een van de lead devs van Bitcoin Unlimited hij had Awemany gevraagd om aan wat code te werken in zowel ABC als BU (CHECKDATASIG/-VERIFY)

Dat heeft er toe geleid dat Awemany de bug heeft gevonden in ABC. En omdat ABC een fork is van Core, zat de bug natuurlijk ook in Core, want daar kwam hij vandaan.

Awemany heeft eerst een timestamp in de BTC blockchain gemaakt om te bewijzen dat hij het was, voordat hij iemand heeft gecontacteerd.

Alleen liep de BTC chain weer op 100% capaciteit, dus het duurde net eventjes te lang voor zijn timestamp opgenomen was. De volgende keer gaat hij gewoon memo.cash gebruiken of een simpele OP_RETURN in de BCH chain.

[Reactie gewijzigd door Kain_niaK op 25 juli 2024 17:21]

[Biersteker]

Hij had ook gewoon een op_return op bitcoin kunnen doen. Hij gebruikt alleen een nogal cheapass timestamping service. Hij had wel de sha hash in de BU slack gezet, die wel een normale timestamp had.

[Biersteker]

Een SHA hash is 32 byte, past prachtig in een OP_return. En kan je in een transactie van ongeveer 230 byte gooien met een 1 sat/vbyte. 0.015 dollar. Dus rijk hoeft hij echt niet te zijn,

[Kain_niaK]

Met 1 sat/byte op BTC heb je geen idee wanneer er genoeg plaats in het volgende blok is voor je transactie. Dat kan als je gelukt hebt het volgende block zijn, dat kan ook 20 blokken later zijn.

Dat is ook precies wat er gebeurd is. Die "cheap ass" timestamping service gebruikt een te lage fee. De 1 sat/byte kwam er dan ook niet meteen door heen waardoor de timestamp pas iets van 12 uur later aangemaakt is geweest.

Op BCH heb je dat probleem niet, want er is in elke block ruimte voor alle tx die gemaakt worden. En dus is er een garantie dat 1sat/byte meteen in het volgende blok komt.

Awemany, die de bug gevonden heeft zegt zelf:

Unfortunately and as I said, it runs on the BTC variant of Bitcoin and the fees are too high to have instant stamping like memo.cash does.

Voor een timestamp service is het handig dat je een beetje een fatsoenlijke resolutie hebt. Als het 2 weken duurt voordat je hash in het volgende blok zit ....

[Reactie gewijzigd door Kain_niaK op 25 juli 2024 17:21]

[.oisyn]

Strict gezien weet ik niets zeker , maar het is algemeen aanvaard in de BTC communities die ik bezoek (Twitter, Reddit) dat "awemany" van BU het was, zoals hij zelf ook claimt (let op, highly opiniated en veel vingergewijs). Het staat ook onderaan het artikel van Aaron van Wirdum.

Ik snap niet zo goed wat de full disclosure tekst daar bedoelt met "independently". Alsof er twee mensen zijn geweest die het hebben gerapporteerd?

[Reactie gewijzigd door .oisyn op 25 juli 2024 17:21]

[Codin the Coder]

Tja, de Bitcoin Core site geeft aan dat het earlz was. Het feit dat Aaron Awemany's bewering aanneemt, wil niet zeggen dat hij het was. Zijn earlz en awemany dan soms dezelfde persoon?

Ik vind het redelijk toevallig dat een paar weken geleden nog een bitcoin dev een ernstige fout vindt in bcash, en nu ineens een bcash dev in bitcoin.

[Edit]
Ik heb earlz van github gemailed. Hij bevestigt dat hij niet de ontdekker was, maar slechts de reporter. Hij claimt eveneens dat een teamgenoot van hem een 'extensie' van deze attach heeft gevonden, die vooralsnog 'bekend maar niet gepubliceerd' is.

Aaron's artikel geeft trouwens aan dat de dev zowel voor zowel core als cash devved.

[Reactie gewijzigd door Codin the Coder op 25 juli 2024 17:21]

[.oisyn]

Op 20 september, toen wisten ze nog helemaal niet wie het was. Het is pas 22 september bekend geworden dat het awemany was. En nogmaals, let op de formulering

17 sept 14:57 anonymous reporter reports crash bug to: Pieter Wuille, Greg Maxwell, Wladimir Van Der Laan of Bitcoin Core, deadalnix of Bitcoin ABC, and sickpig of Bitcoin Unlimited.

20 sept 19:50 A developer by the title earlz independently discovered and reported the vulnerability to the Bitcoin Core security contact email.

Hier wordt helemaal niet gesuggereerd dat earlz de eerdere anonymous reporter was. Er staat dat op 20 sept een dev de vulnerability heeft gerapporteerd, onafhankelijk van de eerste report. Houd er rekening mee dat in eerste instantie helemaal niet naar buiten is gebracht dat er een double-spend mogelijk was, he. Het ging eerst puur over een DoS (ze wisten wel van de double-spend, maar dat is expres achterwege gelaten). Earlz heeft waarschijnlijk aan de hand van de change zelf ontdekt dat een double-spend mogelijk was, en dat gerapporteerd aan Core.

[Codin the Coder]

Satoshi is uit zichzelf vertrokken. Waarschijnlijk om de decentralisatie te bevorderen. Dat heeft goed gewerkt.

Gavin is uit vrije wil vertrokken omdat ie zijn zin niet doorgedreven kon krijgen.

Bitcoin Core heeft honderden devs. Hoeveel had bcash er ook alweer?

[Kain_niaK]

Bitcoin Core heeft er maar 23 devs die er actief bij betrokken zijn.


Je moet minder propaganda vanuit de Core Cult geloven.

[Codin the Coder]

Je moet minder propaganda vanuit de btrash hoek geloven.

Tevens raad ik je aan dat je leert alleen te zijn met je eigen gedachten. Dat is een skill die je hard nodig zult hebben in de komende jaren.

[Kain_niaK]

Ik hoef niks te geloven. Je kunt zelf op de github kijken naar hoeveel devs er meer dan een paar commits hebben gedaan. Er zijn maar iets van een dertigtal devs actief op de Core github repo, kijk zelf.

[Codin the Coder]

Waarom moet ik statistieken copy pasten van de pagina die je zelf linked?

Issues 560
Pull requests 281
18,395 commits
8 branches
207 releases
578 contributors

[Codin the Coder]

Bitcoin Core bulkt van de devs. Jimmy Song leidt om de haverklap een nieuwe club van enkele tientallen op. Er is een video waarin iemand de github contributions analyseert: er zijn honderden mensen die committen.

Je statements zijn feitelijk incorrect. Het gal dat je op je blog richting Bitcoin spauwt komt nog geen eens in de buurt van een poging to rationeel argument.

Mijn ervaring is dat mensen die zuur zijn op Bitcoin, dat meestal zijn omdat ze het gevoel hebben de BTC boot te hebben gemist, veel BTC zijn kwijtgeraakt, oid.

Het is nu een jaar na de bcash fork. De markt heeft gekozen: BTC is de enige ware Bitcoin.

[Codin the Coder]

Ja, Jimmy Song. Lol: goed argument.

Je lijst is net zo nuttig als alle ICOs op Eth.

Waar is de innovatie bij bcash? Met grote blokken saboteer je je eigen opschaling.

Bitcoin heeft LN. En je weet best dat elke serieuze schalings-oplossing in de geschiedenis van de mensheid in lagen geschiedt. Cpu's, tcp/ips, de menselijke hersenen, etc.

Je had me nog wat beloofd. Stuur es bitcoin: [adres verwijderd; hij had idd wat gestuurd, maar aan de hoeveelheid te zien is ie rekt].

[Reactie gewijzigd door Codin the Coder op 25 juli 2024 17:21]

[Kain_niaK]

Done --> https://explorer.bitcoin....474b0efa165df8d202f84a7f0

Hoe kun je nu met grote blokken je opschaling saboteren? Het niet groter maken van je blokken is letterlijk een eigen limiet zetten op de groei van je eigen system. Wat de hele veiligheid van Bitcoin op lange termijn saboteert, want wanneer alle muntjes gemined moeten de transacties het over nemen. Als dat niet gebeurd omdat je niet toe laat dat het systeem zo veel mogelijk transacties kan maken als het zelf wil, dan bloed Bitcoin dood en stoppen alle miners.

edit: Wat ben jij vervelend zeg. met je "adres verwijderd; hij had idd wat gestuurd, maar aan de hoeveelheid te zien is ie rekt]"

Ik stuur je gratis wat BTC en dan is het nog niet goed. Fuck you, de eerste die hier op reageert met een BCH addres krijgt 20 euro van me in BCH.

[Reactie gewijzigd door Kain_niaK op 25 juli 2024 17:21]

[BlackBeltBob]

Op dit punt heb jij een andere mening dan ik en anderen, en dit bericht, noch de discussie die in de reacties van dit nieuwsbericht staan zullen zowel jouw als mijn mening niet veranderen.

That said; de basis van elke blockchain is dat iedereen van alle transacties kan controleren of ze valide zijn op basis van een set van regels die onderling afgesproken zijn. Hierbij geldt dat de regels via Nakamoto consensus worden vastgesteld.

Door een aanzienlijk grotere block size wordt het voor 'de gewone man' moeilijker om een full node te draaien (waarmee de blockchain en de transacties daarin kunnen worden gecontroleerd). Des te groter de block size, des te meer gebruikers afhaken. Door de block size op te schalen naar terrabytes zullen uiteindelijk vrijwel alleen grote bedrijven en miners overblijven om de verificatie van de transacties uit te voeren. De vraag is dan of je niet gewoon het netwerk van de banken had kunnen gebruiken.

Door nu over te stappen op grotere block sizes zorg je ervoor dat je op korte termijn mensen kan laten instappen. Op lange termijn zorg je er echter voor dat de veiligheid van je systeem in het geding kan komen.

> Wat de hele veiligheid van Bitcoin op lange termijn saboteert, want wanneer alle muntjes (zijn) gemined moeten de transacties het over nemen.

Dit voelt als een drogreden; door de blocksize zo groot te maken zorg je ervoor dat er geen fee-markt kan ontstaan. Waarom zou ik meer dan 1sat/byte moeten betalen als de block size toch groot genoeg is om alle transacties op te nemen? Dan is het aantal transacties on-chain direct de verdienste van de miners geworden, maar zelfs met terrabyte blocks kun je niet de hele wereld over krijgen op bitcoin. Daarvoor zul je toch naar een tweede laag moeten gaan.

Wie uiteindelijk het juiste pad heeft gekozen, Bitcoin of Bitcoin Cash, zal moeten blijken.

[Kain_niaK]

That said; de basis van elke blockchain is dat iedereen van alle transacties kan controleren of ze valide zijn op basis van een set van regels die onderling afgesproken zijn. Hierbij geldt dat de regels via Nakamoto consensus worden vastgesteld.

Ja en je kunt prima je eigen transacties controleren met een SPV wallet. Hier is hoe dat werkt.

Vereenvoudigde betalingsverificatie
Het is mogelijk om betaling te verifiëren zonder een volledig netwerkknooppunt te draaien. Een gebruiker dient enkel een kopie van de blok headers van de langste proof of work keten te bewaren, die hij kan bekomen door ze op te vragen bij netwerkknooppunten tot hij ervan overtuigd is dat hij de langste keten heeft, en de Merkle tak kan bekomen die de transactie verbindt aan het blok waarin het een tijdstempel heeft. Hij kan de transactie zelf niet controleren, maar door het te linken aan een plaats in de ketting, kan hij zien dat het knooppunt het aanvaard heeft, en blokken erna bevestigen dat het netwerk de transactie aanvaard heeft. Zodoende, is de verificatie betrouwbaar zo lang de eerlijke knooppunten controle hebben over het netwerk, maar is het meer kwetsbaar als het netwerk overmeesterd is door een aanvaller. Terwijl
netwerkknooppunten op zichzelf transacties kunnen bevestigen, kan de versimpelde methode om de tuin geleid worden door een aanvaller zijn vervalste transacties zo lang de aanvaller het netwerk erin blijft slagen het netwerk te overmeesteren. Een strategie om het netwerk te beschermen zou kunnen zijn om alarmsignalen van knooppunten te aanvaarden wanneer deze een ongeldig blok detecteren, en de gebruiker zijn software er toe aanzetten om het volledige blok te downloaden en de gesignaleerde transacties om de inconsistentie te bevestigen. Bedrijven die regelmatig betalingen ontvangen willen waarschijnlijk hun eigen knooppunten draaien voor
een meer onafhankelijke veiligheid en snellere verificatie

Wat is er volgens jou mis aan dit ontwerp? Het bied een hoog genoege veiligheid aan zijn gebruikers. Als jij gelooft dat jij of wie dan ook mijn Bitcoin transacties kunt censureren die ik met mijn Electrum SPV wallet doe dan moet je mij eens uitleggen hoe je dat voor elkaar wilt krijgen. Of in het geval van Bitcoin Cash, mijn Electron Cash wallet.

De blockheaders sinds 2009 zijn bij elkaar 40 MB groot. Dan zelfs op een feauture phone nog gebruikt worden.

Dit voelt als een drogreden; door de blocksize zo groot te maken zorg je ervoor dat er geen fee-markt kan ontstaan. Waarom zou ik meer dan 1sat/byte moeten betalen als de block size toch groot genoeg is om alle transacties op te nemen? Dan is het aantal transacties on-chain direct de verdienste van de miners geworden, maar zelfs met terrabyte blocks kun je niet de hele wereld over krijgen op bitcoin. Daarvoor zul je toch naar een tweede laag moeten gaan.

Er zijn twee mogelijkheden om de veiligheid van de chain in de toekomst te garanderen door het inkomen van miners op pijl te houden.

Geen beperking op het aantal transacties x een miners bounty die constant kan blijven.

Een beperking op het aantal transactie x een miners bounty die omhoog gaat.

Welke denk je dat het meeste groei kansen heeft? Een vast aantal transacties dat steeds duurder word en steeds minder mensen in de wereld zich kunnen veroorloven. Of dat wanneer er meer en meer mensen Bitcoin als geld beginnen te gebruiken er steeds meer transacties worden gedaan.

Gebruik je trouwens zelf Bitcoin dagelijks als geld?

[Reactie gewijzigd door Kain_niaK op 25 juli 2024 17:21]

[BlackBeltBob]

Ja en je kunt prima je eigen transacties controleren met een SPV wallet. Hier is hoe dat werkt.

...

Wat is er volgens jou mis aan dit ontwerp? Het bied een hoog genoege veiligheid aan zijn gebruikers.

Goed dat je dit aanstipt. SPV clients bieden inderdaad een hoge veiligheid, zolang het netwerk opereert onder dezelfde consensus rules. Jouw SPV client zit verbonden aan een aantal full nodes die het echte werk doen. Mooi om het hierover te hebben in de reacties over een bericht dat er een bug in de consensus rules zaten. Stel dat jij vast zat met je SPV client aan een groepje 0.16.2 full nodes. Een miner merkt het probleem, en besluit er gebruik van te maken. Een chainsplit ontstaat, waarbij jij op de ene tak zit, en ik op de ander. Jij betaalt mij in jouw tak 1 btc voor een koffie. Jij blij, ik blij. Tot blijkt dat de transactie in een split zit waar ik niet achter sta; immers, ik wil nooit meer dan 21m bitcoin.

Welke denk je dat het meeste groei kansen heeft? Een vast aantal transacties dat steeds duurder word en steeds minder mensen in de wereld zich kunnen veroorloven. Of dat wanneer er meer en meer mensen Bitcoin als geld beginnen te gebruiken er steeds meer transacties worden gedaan.

Gebruik je trouwens zelf Bitcoin dagelijks als geld?

Ik heb het niet over groei. Hoe snel bitcoin groeit maakt me niet uit. Van mij mag het er 100 jaar over doen. Ik hecht aan de belangen van de blockchain: decentraal, vertrouwenloos, oncensureerbaar geld. Zodra je de full nodes uit het verhaal haalt doe je consessies.

Door een gelaagde oplossing als het Lightning Network te gebruiken zorg je ervoor dat je een settlement layer hebt, waarin de belangrijke verplaatsingen van geld hebt (aanschaf huis, lening voor bedrijf, etc), en een tweede laag waarin alle openstaande balansen van onderlinge partijen die kleine transacties doen zitten. Door de onderste laag (Bitcoin) uit te breiden met MAST, Schnorr, BLS, etc zorg je voor grotere ruimte binnen de blokken. Door gebruik van channel factories, transacties waarin een kanaal gesloten wordt en een nieuw kanaal direct geopend wordt, kun je flink schalen.

Ik ben ondertussen de discussie een beetje zat, en nee, ik ga niet van gedachten wisselen als je aankomt met de gebruikelijke argumenten over "routing op het LN", etc. Zoals ik in mijn eerdere post al aangaf:

Op dit punt heb jij een andere mening dan ik en anderen, en dit bericht, noch de discussie die in de reacties van dit nieuwsbericht staan zullen zowel jouw als mijn mening niet veranderen.

[Kain_niaK]

Stel dat jij vast zat met je SPV client aan een groepje 0.16.2 full nodes. Een miner merkt het probleem, en besluit er gebruik van te maken. Een chainsplit ontstaat, waarbij jij op de ene tak zit, en ik op de ander. Jij betaalt mij in jouw tak 1 btc voor een koffie. Jij blij, ik blij. Tot blijkt dat de transactie in een split zit waar ik niet achter sta; immers, ik wil nooit meer dan 21m bitcoin.

Mijn SPV client geeft keurig aan wanneer er een chainsplit detected is. Kijk maar.

SPV clients bieden inderdaad een hoge veiligheid, zolang het netwerk opereert onder dezelfde consensus rules

Ja en die consensus rules worden bepaald door miners en hun hashrate. En bij Bitcoin moet je er sowieso op vertrouwen dat minstens 50% eerlijk mee speelt en niet hun eigen netwerk aanvallen.

Ik heb het niet over groei. Hoe snel bitcoin groeit maakt me niet uit. Van mij mag het er 100 jaar over doen

Dat gaat niet werken wat 80% van de coins zijn al gemined. Binnen 10 jaar is de block reward nog maar 1 BTC per block. 12 keer minder dan nu het geval. Denk je echt dat miner voor de lol al die stroom gaat betalen als hun inkomen 12 keer minder is? Nee, als de incentives die gebruikers aan hun transacties knopen het niet overnemen van de coin reward dan bloed Bitcoin dood en verwijdt alle veiligheid. Als er niemand betaald, geen veiligheid meer.

Door een gelaagde oplossing als het Lightning Network te gebruiken zorg je ervoor dat je een settlement layer hebt, waarin de belangrijke verplaatsingen van geld hebt (aanschaf huis, lening voor bedrijf, etc), en een tweede laag waarin alle openstaande balansen van onderlinge partijen die kleine transacties doen zitten. Door de onderste laag (Bitcoin) uit te breiden met MAST, Schnorr, BLS, etc zorg je voor grotere ruimte binnen de blokken. Door gebruik van channel factories, transacties waarin een kanaal gesloten wordt en een nieuw kanaal direct geopend wordt, kun je flink schalen.

Wat lost dat nou op, Bitcoin is het goud, LN het papier geld dat het goud vervangt. Met LN wissel je geen Bitcoin uit, je wisselt papiertjes uit die je het recht op Bitcoin geven.

Dan krijg je weer gewoon een bank systeem. De bank heeft de Bitcoin, jij de papiertjes die je recht geven om er eventuweel Bitcoin voor te krijgen.

[BlackBeltBob]

> Dan krijg je weer gewoon een bank systeem. De bank heeft de Bitcoin, jij de papiertjes die je recht geven om er eventuweel Bitcoin voor te krijgen.

Behalve dat je het recht behoudt om daadwerkelijk in te wisselen...

[Kain_niaK]

Heb je nog al veel aan als je niet genoeg geld hebt voor een Bitcoin transactie.

[.oisyn]

Heb ik allang gedaan, inclusief link naar het artikel: .oisyn in 'nieuws: Bitcoin Core bleek jaar lang vatbaar voor double-spending-...

[Kain_niaK]

top, awemany is een pracht kerel.

Op de Miners Summit, georganiseerd om te praten over de nieuwe upgrade van Bitcoin Cash in novemeber, heeft hij alle andere devs en miners aangeboden om tijd vrij te maken om volledig uit te leggen waarom CTOR de oplossing is die Bitcoin ABC wil activeren op het Bitcoin Cash netwerk.

[Reactie gewijzigd door Kain_niaK op 25 juli 2024 17:21]

[CH4OS]

Bitcoin Core had een jaar lang een ernstige double-spending-kwetsbaarheid, die in theorie zelfs tot een blockchain-fork van getroffen nodes en bugvrije nodes had kunnen leiden.

Een bugvrije node had dan in deze toch min of meer een oplossing geweest of begrijp ik dit stuk van de tekst niet goed?

Al heb ik nog nooit bugvrije software gezien, dus vraag me af hoe ik een 'bugvrije node' dan moet voorstellen.

[.oisyn]

dus vraag me af hoe ik een 'bugvrije node' dan moet voorstellen

Met "bugvrije node" wordt in dit geval bedoeld een node die geen last had van deze specifieke bug. Niet van een node die in z'n geheel geen bugs heeft.

[CH4OS]

Maar die bugvrije node was dan een fork geweest, neem ik aan? Anders lijkt het me dat het een probleem is dat zichzelf oplost en had de fix niet nodig geweest?

[.oisyn]

Een node kan geen fork zijn, een node is gewoon iemand op het netwerk die transacties en blokken ontvangt en deze eventueel propageert naar andere nodes (na validatie). Als je verschillende nodes in je netwerk hebt die verschillende regels accepteren, dan krijg je dus een chain split als er blokken worden geproduceerd aan de hand van die verschillende regels.

In dit geval hebben de bugvrije nodes amper hash rate, dus de kans dat iemand een blok gaat produceren die ze wel accepteren is heel klein, omdat de rest van de miners ofwel crasht ofwel doorrekent op de invalide chain. Ze blijven dus gewoon eindeloos wachten op een blok dat wel goed is.

[Tokkes]

[

[...]
Een bugvrije node had dan in deze toch min of meer een oplossing geweest of begrijp ik dit stuk van de tekst niet goed?

Ik denk, uit je opmerking op te maken dat je niet bekend bent met de blockchain en de technische implementatie ervan.

De Blockchain zou geforked worden in een fork met getroffen nodes en een fork met bugvrije nodes.

[blorf]

Ik snap er weinig van, maar hoe kan het wiskundig gezien mogelijk zijn dat de door te rekenen chain getallen die afgeleid is van natuurlijke constanten zich in twee delen splitst die niet gelijk zijn maar wel allebei blijven voortbestaan, terwijl bij elke transactie de hele blockchain wordt geverifieerd? Het principe van een blockchain is volgens mij juist dat dat niet kan...

[sjongenelen]

De hele blockchain wordt niet gevalideerd. In een notendop:

Het laatste block bevat een hash van alle voorgaande blocks (merkle tree).
Het nieuwe block bevat ook de hash het laatste block.
Het nieuwe block kan alleen aansluiten op de laatste (hash check).
Als de hash niet overeenkomt, is het block dus niet valide en wordt het niet 'chained'

[.oisyn]

Het laatste block bevat een hash van alle voorgaande blocks (merkle tree).

Niet helemaal. Even kort door de bocht:
blockhash(n) = hash(merkletree(transacties) + blockhash(n-1) + nonce)

De blokken zelf zijn dus geen merkle tree, de transacties in een blok zijn dat wel. En de hash van het huidige blok is dus puur gebaseerd op de inhoud van het huidige blok en de hash van de vorige. Goed, aangezien het vorige blok dat ook weer is kun je effectief zeggen dat ze een hash "bevatten" van alle voorgaande blokken, maar dat komt niet terug in de berekening zelf.

[.oisyn]

die afgeleid is van natuurlijke constanten

Wat bedoel je hier precies mee? Als je het echt hebt over constanten uit de natuurkunde, dan zitten die op geen enkele wijze in bitcoin . Als je bedoelt dat bitcoin is gebaseerd op wiskundige principes, dan klopt dat natuurlijk.

zich in twee delen splitst die niet gelijk zijn maar wel allebei blijven voortbestaan, terwijl bij elke transactie de hele blockchain wordt geverifieerd? Het principe van een blockchain is volgens mij juist dat dat niet kan...

Dat is niet juist. Er kunnen prima meerdere chains bestaan. Sterker nog, "orphaned blocks" zie je wel vaker. Een blok is gewoon een lijst met transacties en een stukje "proof of work". Nadat een miner een nieuw blok heeft geproduceerd, moet het hele netwerk van miners gaan werken aan een blok die erop volgt. Je kunt je wellicht wel voorstellen dat hier een race condition in zit: twee miners kunnen onafhankelijk van elkaar een juist blok produceren. De chain is nu feitelijk geforked. De bloks propageren door het netwerk, en zodra een miner een nieuw blok heeft ontvangen van het netwerk zal hij zo snel mogelijk overschakelen op het produceren van een vervolg op dat blok. Als er dan korte tijd later een ander valide blok met dezelfde "hoogte" binnenkomt, dan zal hij die negeren. Er is op zo'n kort termijn niet echt een manier om te bepalen welke de juiste is, maar op lange termijn is de (valide) chain met de meeste proof-of-work de enige juiste.

In het specifieke geval van de betreffende bug heb je nodes die een malafide blok niet accepteren en dus wachten op het eerstvolgende valide blok. Maar dat blok komt nooit, omdat miners doodleuk doorgaan op die malafide chain (omdat ze het niet doorhebbben dat hij niet meer klopt).

[Reactie gewijzigd door .oisyn op 25 juli 2024 17:21]

[OverSoft]

De ene chain accepteert een block wel met de foutieve transactie er in, en de andere chain niet.
Simpel.

De "goede" chain verwerpt de transactie en neemt deze niet op in een block.

[blorf]

Met als gevolg dat bij de eerstvolgende transactie de foute chain op zijn bek gaat en de goede blijft voortbestaan? Die kapotte schakel lost niet ineens op.

[OverSoft]

Nee, er zijn dan dus 2 chains. De nieuwe nodes verbinden niet naar de deze oude chain en de oude nodes verbinden niet naar de nieuwe chain.

Afhankelijk waarmee je dus een nieuwe transactie maakt komt deze op 1 van de 2 chains terecht.

[Tokkes]

inderdaad. Die lost zichzelf niet op: de blockchain word geforked in een 'juiste' en een 'foute' blockchain en blijven beiden gewoon verder gaan, tot een van de 2 een meerderheid heeft. Die meerderheid heeft gelijk en diens blokken komen in de blockchain terecht.

[Reactie gewijzigd door Tokkes op 25 juli 2024 17:21]

[blorf]

Het verleden van de chain wordt bij een transactie niet gecontroleerd op integriteit? Dat is toch juist de basis voor validatie van een transactie?

[OverSoft]

Jawel, maar alleen door de ge-update nodes. De oude nodes vinden niet dat de transactie fout is.
Dus zolang mensen oude software blijven draaien blijft de foute chain doorbestaan.

[Tokkes]

Er staat in het artikel

Optimalisaties in Bitcoin Core 0.14, die vorig jaar maart verscheen, hadden als onbedoeld bij-effect dat nodes konden crashen bij de verwerking van blokken met transacties die coins meerdere keren probeerden te besteden. Met de komst van Bitcoin Core 0.15.0, iets meer dan een jaar geleden, werden de problemen groter. De aanpassingen zorgden er namelijk voor dat nodes de double-spend-transacties in sommige gevallen accepteerden.

In theorie kon een gebugde node dus andere gebugde nodes 'besmetten'(met de foute blockchain), en zo dus een fork maken en als je dus genoeg nodes hebt die die transacties accepteren (zeg, 51% van de network hashrate dan zal die foute fork het overnemen van de 'juiste' fork.

In het artikel wordt ook aangegeven dat, omdat het oudere clients betreft, dat die kans niet heel groot was.

Er wordt wel gecontroleerd op integrity - maar als je bugs in de software hebt die de controle moet doen is dat natuurlijk ook niet heel veel waard.

[Reactie gewijzigd door Tokkes op 25 juli 2024 17:21]

[Kain_niaK]

Maar dit is in de praktijk geen probleem want alleen mensen die hun brood met Bitcoin verdienen hebben er een reden bij om te upgraden. Alle nodes die niet upgraden, daar zit minder dan 0.00001% hashpower achter. De meeste nodes minen helemaal niet, zijn hobby nodes, en zouden ook gewoon niet op het netwerk moeten zitten. Dat er iets van 80% van de nodes nog hieft geupgrade laat dat wel zien.

[.oisyn]

Dit is vooral BCH rhetoriek. Full nodes zijn belangrijk, voor iedereen, niet alleen voor miners. Don't trust, verify.

[.oisyn]

Lol, ik volg Matt dus die tweet had ik allang gelezen. Je mist totaal de nuance van zijn post. Wat hij zegt staat namelijk helemaal niet haaks op wat ik zeg. Hij zegt niet dat het onzin is om een full node te draaien als gewone gebruiker, hij zegt dat het netwerk het niets kan schelen. Dat doet hij als reactie op de tweet van LukeJr dat er nog zo weinig hebben geüpdatet. En dat is idd niet zo gek, de gewone gebruiker zal idd niet zo snel updaten, en dat hoeft ook niet per se, want het netwerk is effectief al veilig.

[Reactie gewijzigd door .oisyn op 25 juli 2024 17:21]

[Kain_niaK]

Deze kerel is anders wel een core dev --> https://twitter.com/LukeDashjr/status/1044224230114627586

Dus daar ben je dan niet meet eens?

[.oisyn]

No shit sherlock. Denk je echt dat ik niemand ken? Ik vind idd dat LukeJr wat overdrijft ja. Maar ik staar niet zo blind op meningen van anderen, ik heb mijn eigen. Ik ben dus ook niet zo gevoelig voor het argument "ja maar X zei Y".

[Reactie gewijzigd door .oisyn op 25 juli 2024 17:21]

[Kain_niaK]

Ok, bedankt voor je antwoorden.

[.oisyn]

Die mensen zijn niet afhankelijk van Bitcoin voor hun brood winning en voor hun maakt het allemaat niet zo veel uit.

Dat doet er niet toe, het gaat om de aard van het beestje. Als je niets geeft om censuur dan kun je net zo goed Paypal gebruiken. Een full node is de enige manier om écht zeker te zijn dat de boel klopt, en dat anderen je transacties niet zomaar zien.

Hoe kunnen nodes zonder hashrate nu helpen het netwerk veilig te houden als Proof of Work nu juist het mechanisme is om Bitcoin veilig te houden?

Het gaat daar om chain splits. Oudere nodes accepteren de malafide blokken niet, maar juiste blokken wel. Als een miner dus een oudere node gebruikt, dan is er hash rate voor de oudere node en zullen er blokken geproduceerd worden. En dan heb je effectief een chain split.

[Reactie gewijzigd door .oisyn op 25 juli 2024 17:21]

[.oisyn]

Jij draaft door in je extremisme van "het moet 100% veilig zijn"

Ho ho, ik zeg dat het 100% veilig moet kunnen zijn. Ik draai ook een SPV client, maar ik vind het belangrijk dat iedereen die keuze moet kunnen maken.

En wederom laat je weer zien dat je gewoon niet in staat bent een normale on-topic discussie te voeren, want op een of andere manier haal je er altijd weer andere dingen bij . Wat je aanhaalt is ook helemaal niet "bitcoin core" cult, het is "bitcoin maximalism en sound money" cult. Het zou je sieren als je die twee dingen los van elkaar kunt zien.

[Reactie gewijzigd door .oisyn op 25 juli 2024 17:21]

[.oisyn]

Waarom zit jij dan nog steeds bij BTC, dat vraag ik mij toch af?

Wat vind je van al deze mensen op de sprekers lijst, ben je het met hun filosofie eens of niet?

Offtopic. Leer maar eens gewoon een keertje bij het onderwerp te blijven. Ik heb een tijdje terug een hele uitgebreide reactie gepost in het CC topic, maar daar heb je nooit op gereageerd. Prima, maar dan is het ook klaar.

[Reactie gewijzigd door .oisyn op 25 juli 2024 17:21]

[MSalters]

Foute aanname. De blockchain is gebaserd op onvoorspelbare eigenschappen van random getallen. Een fork heeft andere random getallen.

De specifieke BitCoin eigenshap is het aantal nullen aan het begin van een cryptografische hash van het random getal, maar dat is in dit verband een detail.

[netfast]

Maar als ik het dus goed begrijp... Kan een miningpool met voldoende hashrate weer terug schakelen naar een lagere versie met de problemen? En daar dan proberen misbruik van te maken?

In de praktijk zou dit onwaarschijnlijk zijn, omdat de oudere, niet getroffen nodes waarschijnlijk een te lage hashrate zouden hebben.

Als er maar genoeg hashrate is om een bepaalde actie op de blockchain goed te keuren...

[Reactie gewijzigd door netfast op 25 juli 2024 17:21]

[.oisyn]

Maar als ik het dus goed begrijp... Kan een miningpool met voldoende hashrate weer terug schakelen naar een lagere versie met de problemen? En daar dan proberen misbruik van te maken?

Nee, want iedereen die een geüpdatete full node draait zal die blokken niet accepteren. Uiteraard zullen merchants en exchanges allemaal rap updaten, dus die accepteren geen enkele van de malafide blokken. En als die ze niet accepteren, dan is de chain effectief waardeloos geworden

[anboni]

Maar als ik het dus goed begrijp... Kan een miningpool met voldoende hashrate weer terug schakelen naar een lagere versie met de problemen? En daar dan proberen misbruik van te maken?

Ja, maar dat is altijd al een onderkende zwakte van de Proof of Work blockchains: als je 51% van de hashrate in handen hebt, kun je in principe doen wat je wilt.

[korenpc]

Kleine edit: Maar wat is Bitcoin core? De enige wie btc Bitcoin core noemt is de oprichter van Bitcoin cash. Met andere woorden een marketing zet. Dus graag Bitcoin gewoon Bitcoin noemen

[.oisyn]

Bitcoin Core is de standaard client software van Bitcoin. De titel is technisch correct, al had er ook gewoon "Bitcoin bleek ..." kunnen staan.

[Reactie gewijzigd door .oisyn op 25 juli 2024 17:21]

[Biersteker]

Iets correcter had Referentie Client van Bitcoin geweest. (Bitcoin Core is ook weer een coin om het makkelijk te houden )

[korenpc]

Waar in the whitepaper wordt btc btc core genoemd?

[.oisyn]

Het gaat niet over de cryptocurrency, het gaat over de software. Die heet gewoon Bitcoin Core. https://bitcoincore.org/, https://en.wikipedia.org/wiki/Bitcoin_Core. Het is de client waar Satoshi zelf aan gewerkt heeft, in 2014 (versie 0.9) is het hernoemd naar Bitcoin Core om een distinctie te maken tussen het netwerk en de software. Zie https://bitcoin.org/en/re...ebranding-to-bitcoin-core

Hoewel die term veelal door Bcashers wordt gebruikt om de BTC chain aan te duiden, is het geen term die ze zelf hebben verzonnen. Ze noemen het Bitcoin Core omdat dat de enige noemenswaardige client is voor BTC, de rest is gediverged naar BCH.

[Reactie gewijzigd door .oisyn op 25 juli 2024 17:21]

[korenpc]

Het lastige is dat Bitcoin.com van Roger Ver. Is en dus de info niet helemaal betrouwbaar. Wiki geld het zelfde probleem. Thanks voor de uitleg rondom de cliënt. (+3)

[.oisyn]

Ik refereer niet naar bitcoin.com

[korenpc]

.org is toch ook van hem? Maar weet niet zeker. (PS had over de .org heen gelezen)

[.oisyn]

Nee .

[Kain_niaK]

Bitcoin.org is van Cobra-Bitcoin.

Bitcoin.com van Roger Ver.

[Kain_niaK]

Wie is de oprichter van Bitcoin dan?

[NielsTn]

Hier mijn Raspberry Pi 3bPlus node ook al sinds het beschikbaar komen geupdate naar 0.16.3.
Easy

[Verwijderd]

Dit is niet voorgekomen ?

[Petje72]

op deze pagina kan je zien wat er draait aan bitcoin nodes, versie en of ze vatbaar zijn voor de bug.

https://coin.dance/nodes#nodeVersions

[Technomania]

Submitter heeft hierover ook een blog geschreven.

[Codin the Coder]

Let op: submitter is een bcasher die een misleide kruistocht tegen Bitcoin onderneemt.

[Kain_niaK]

Submitter is een Bitcoiner die als sinds 2011 in de community actief is. En die als iets van 20 BTC (en later BCH) sinds 2011 heeft uitgedeeld aan tweakers hiero.
Dus als je wat BCH wilt, stuur me een DM. Krijg je meteen. En nou vooruit, ik kan je ook wel wat BTC sturen.

Submitter is al jaren bezig met het aandrijven van Bitcoin adoptie en heeft daar zelfs een website voor, waar de community adoptie kan aandrijven door beloningen te geven aan pizza shops in 100 steden die BCH als betaal middel willen gaan accepteren.

En of een pizza shop nu Ripple, of Dash, Of Zcash, Of VeChain, of BCH, of Ethereum, of BTC of dogecoin of wat voor een coin dan ook accepteert interesseert mij geen reet. De drempel van fiat naar crypto is veel hoger dan de drempel van een crypto naar een andere crypto.

Dus als je ooit bij een pizza shops een pizza gaat halen en je kunt met BTC betalen, kan het zo maar eens zijn dat mijn website daar aan toe bijgedragen heeft.

En ja, ik ben tijdens de split naar de BCH kant gegaan, want de BTC chain loopt de hele tijd op 80% plus capaciteit en het is belachelijk dat ze dat toe laten en hun capaciteit niet vergroten zodat die terug onder de 10% komt. De BCH chain loopt op minder dan 1% capaciteit en heeft alle problemen die BTC heeft dus niet. (lange wachtijden met kosten hoger dan gewoon geld) En de mensen die nog op de BTC chain zitten, zijn mensen die beweren dat het promoten van het gebruiken van cryptocurrency als geld een scam is. Dat vind ik helemaal knettergek! Dat ze het woord "valuta" niet begrijpen. crypto CURRENCY!

[Reactie gewijzigd door Kain_niaK op 25 juli 2024 17:21]

[Codin the Coder]

Allicht loopt bch op minder dan 1% capaciteit. Is niet zo moeilijk bij een coin die terabyte blokken nastreeft en geen enkele organische support heeft.

Ik kan niet geloven dat je zoiets aan durft te dragen als argument. Het komt je geloofwaardigheid niet ten goede. Alsmede alle egogedreven observaties.

Wat betreft je crypto aanbod... challenge accepted.

BTC: [adres verwijderd, want hij stuurde niks]
BCH: [graag converteren naar BTC en opsturen naar BTC adres]

[Reactie gewijzigd door Codin the Coder op 25 juli 2024 17:21]

[Kain_niaK]

Wat kerel? Ik heb je wel iets gestuurd.

https://explorer.bitcoin....474b0efa165df8d202f84a7f0

En dan jij klagen dat het niet genoeg is????

[Kain_niaK]

Ja vriend, ik woon in Canada. Andere tijdzone vriend. Stuur je die 0.00015113 BTC eventjes terug? Dan kan ik hem aan iemand geven die er wel dankbaar voor is.

Wat dit heb ik nog nooit meegemaakt.

Rekt, lol. Jij kent echt niks van Bitcoin. Grapjas. Weet niet eens hoe een blockexplorer werkt.

[Reactie gewijzigd door Kain_niaK op 25 juli 2024 17:21]

[Codin the Coder]

Elke halleve harrie kan een zwik btc naar zichzelf rondsturen en zichzelf dan rijk wanen omdat de block explorer dan aangeeft dat er honderden bitcoins op zijn ontvangen.

Als je dat zou hebben, dan zou ik verwachten dat je gelukkig was en vrede had met jezelf.

[Kain_niaK]

Heb ik ook, maar Bitcoin is meer dan alleen heel rijk worden. (ik heb het meest weggeven)
Het is een instrument dat verandering in de wereld kan brengen. Daar zet ik mij (en samen met mij vele anderen) voor in.

[Kain_niaK]

Helemaal niet hoor. Ik heb nu allemaal goede contacten, krijg de helft van mijn loon al in crypto. Ben de hele dag bezig met mijn twee grote passies, Bitcoin en muziek. Is allemaal goed gekomen.

[Codin the Coder]

Wat fijn dat het zo goed met je gaat. Je straalt het ook helemaal uit.

[Petje72]

niet getroffen nodes waarschijnlijk een te lage hashrate zouden hebben ... Nodes zelf hebben geen hashrate. Alleen miners doen berekeningen en hebben een x hashrate. Nodes verifiereren alleen transactie en berekening niks voor een block en hebben dus geen hashrate.

https://en.bitcoin.it/wiki/Hash_per_second

[Reactie gewijzigd door Petje72 op 25 juli 2024 17:21]