Kenneth Skovhede

Blockchain 2008-2019, RIP

Fin beskrivelse, men dit afsnit om konsensus er ikke helt korrekt.

Fordi alle transaktioner er digitalt signeret med en privat nøgle, kan der ikke opstå byzantine forvanskninger, hverken tilfældige eller bevidste. Og fordi der holdes en hash chain kan man heller ikke slette/udelade transaktioner uden det er trivielt at opdage. Med andre ord er de byzantiske generalers problem ikke relevant her.

Det som blockchain (i virkeligheden Bitcoins design) har af nyskabelse er at de kan håndtere Sybil angreb. Alle de andre komponenter er gamle travere som du beskriver dem. I blockchain, som i mange andre distribuerede systemer, løses uenigheder ved en simpel flertalsafstemning. Et Sybil angreb går ud på at starte et stort antal klienter, så man på den måde får flere stemmer end man er berettiget til og således kan overtage systemet. Hvis man sidder på en pose penge, så er det bare et spørgsmål om at starte et stort antal virtuelle maskiner og på den måde få de 50,1% af stemmerne. Angrebet er bla. udført på Tor netværket, som nu har nogen beskyttelse mod dette.

Blockchain løser dette via forskellige proof-of-work metoder, og i Bitcoins tilfælde via regnekraft, altså strøm. Med Bitcoins konsensusprotokol "koster" hver stemme ikke bare en virtuel maskine, men også en del regnekraft. Det gør det betydeligt dyrere for en enkelt aktør at overtage netværket, da de ikke bare skal have maskiner til at stemme men også betale for strøm til beregninger. Det betyder at man i princippet helt kan undvære en central autoritet, fordi man antager at nogen andre altid vil have incitament til at skaffe nok regnekraft til at forhindre en anden i at opnå 50,1%. Indtil Satoshis artikel og oprindelige implementation var der ikke nogen der havde vist at det kunne lade sig gøre at forhindre Sybil angreb på så simpel en måde.

I virkelighedens verden ser det dog lidt anderledes ud, da de fleste bruger pools og disse har en ret stor del af markedet, og ville kunne slå sig sammen og styre netværket. Herudover er der stort set kun Bitmain der er en relevant leverandør af mining hardware, og de kan således "bestemme" hvem der får mest regnekraft.

Hvis man har et scenarie hvor ingen stoler på de andre deltagere så kan en blockchain løsning måske være svaret. Vælger man Blockchain skal man så acceptere at man bliver nødt til at stole på software (man kan ikke fortryde en fejltransaktion, refundere tyveri, o.l.) og være klar til at opskalere sin egen proof-of-work hvis nogen andre bliver for store.

I langt de fleste tilfælde vil det være mere effektivt at oprette en kommitte der kan fungere som mæglingsled eller identitetskontrol, og så køre uden proof-of-work, hvilket falder tilbage på de traditionelle metoder du nævner.

19. december 2019 kl. 10:57
KU-professor til Rigsrevisionskritik: »De forstår ikke universiteter som arbejdsplads«

Men det var netop den konkrete metode, jeg er nysgerrig efter.

Til ERDA / SIF anvendes standard TOTP, der virker både med hardware tokens og software generatorer:https://en.wikipedia.org/wiki/Time-based_One-time_Password_algorithm

Der findes vel mere eller mindre sikre 2-faktor-metoder? Et gæt: Kode tilsendt på mobil er mere sikker end nøglekort?</p>
<p>Eller kan de alle betragtes som tilstrækkeligt sikre?

Til ERDA / SIF sendes der ikke koder på SMS eller lignende da telefon nettet ikke indeholder pålidelig routing eller transport sikkerhed. Der findes et utal af sager, specielt i USA, hvor det er lykkedes at overtage et telefonnummer (kaldet SIM swap):https://www.wired.com/story/sim-swap-attack-defend-phone/

Hvis man bruger en service der kun har mulighed for SMS 2FA bør man bede dem om at rette problemet. Men omvendt bør man altid aktivere 2FA, for sløj 2FA er bedre end ingen da det trods alt gør det sværere at tilgå.

21. januar 2019 kl. 20:43
Dansk turbo-startup udfordrer Chromecast og Apple TV

Jeg har muligvis misforstået det, jeg kommenterede på:

Airtame vil gøre op med proprietære kabelstik og <em>app-låst tv-streaming</em>

Men der menes muligvis den slags TV der går under navnet "Smart TV", som er alt andet end smart.

Jeg antog at de også ville duplikere skærme fra apps (på Android og iOS), men det er der ikke noget der antyder.

27. november 2013 kl. 13:35
Dansk turbo-startup udfordrer Chromecast og Apple TV

Du fortæller her i realiteten selv, at Google netop ikke "vælger" at lukke Chromecast helt ned, men at det er noget de er nødt til at gøre, rent defensivt, for ikke at blive uvenner med indholdsejere.

Nej, det er ikke det jeg fortæller. Der er er mig bekendt ikke nogen indholdsudbydere der kræver at du IKKE sender normal video ud af en ChromeCast/HDMI dongle.

Du kan sagtens køre et lukket OS der sikrer HDCP mm af video streams fra nogle udbydere, og samtidig kører streaming video fra f.eks. VLC. Det er muligt at Google har en aftale med nogle indholdsudbydere der indeholder sådan en klausul, hvilket ville forklare deres fremgangsmåde, men det er ikke noget de har meldt ud.

Min pointe var at nyheden fremlægger AirTame som en streaming box, men med streaming kræver det en overvejelse af hvad man gør med f.eks. DRM indhold, og det nævnes ikke.

27. november 2013 kl. 11:22
Dansk turbo-startup udfordrer Chromecast og Apple TV

Apple TV har helt klart den nemmeste at udvikle

Hvordan det? Apple har mig bekendt ikke et offentligt SDK, du kan kun udvikle til Apple TV hvis du bliver bedt om det af Apple. Selvom Apple TV kører iOS så kan du IKKE køre normale apps på det, kun specielle Apple TV apps. Jeg gætter på at det er på grund af fjernbetjeningen.

Hvor andre platforme satser på, at man skal benytte sin smartphone, tablet eller computer.

Min løsning til dette er at bruge en remote med standard DPAD til det fleste ting og så "Air Mouse" (dvs. Gyro baseret mus du bevæger) til de tinger der kræver touch (f.eks. Angry Birds).

27. november 2013 kl. 08:39
Dansk turbo-startup udfordrer Chromecast og Apple TV

Jeg har selv startet virksomheden Easy Play TV, bla. pga. at Apple TV og Google Chromecast er så utroligt lukkede, og generelt ikke brugbare, og jeg har derfor en del erfaring med streaming af video over Wifi.

Vores løsning er baseret på Android, og kører en fuld Android på en mini-pc du tilslutter til dit TV via HDMI, med adgang til hele Google Play. Med den løsning kan du allerede nu streame DLNA, WIMO, AirPlay mm direkte til dit TV, fra iPad, laptop, og du kan helt undgå at have en klient-maskine da den jo bare kan køre en browser, Netflix, VLC, etc. direkte på stick'en.

Fordelen ved f.eks. AirPlay protokollen er at devicet selv streamer, dvs. at du kun sender remote-control beskeder til device, og selve video stream kan køre på device. Det er utrolig svært at få styr på latency og audio/video sync hvis man streamer video fra et device over Wifi. Det er det ChromeCast "løser" ved at køre et mini-os på donglen, men de vælger så at låse den helt ned så den i mine øjne bliver ubrugelig. For at se hvad jeg mener så se f.eks. latency i denne video når de spiller.

Deres protokol lyder god, som en reel erstatning for f.eks. VNC, men det lyder utroligt hvis de skulle få styr på latency så meget at man kan bruge det til at spille. En tjeneste som OnLive har arbejdet længe med dette, og de bruger ikke simpel streaming af billedet, netop pga. latency problemer. I deres video ser det ud til at der kun er Wifi understøttelse, og der får man problemer med pakke-tab og latency når der samtidig skal encodes og decodes video.

En anden ting der mangler overvejelser over er håndtering af DRM beskyttet indhold. Hvis denne dongle skal være til "streaming" så kan de forvente stor modstand fra DRM holdet som straks vil se det som en omgåelse af kopi-beskyttelsen (man kan jo kopiere streamen) og forsøge alle mulige krumspring.

27. november 2013 kl. 08:36