De Broncode

[Anonymous]

Zonder veel woorden, maar met wat meer mensen kennis:

Jan Sloot was geen meesteroplichter, misschien wel paranoide en angstig, maar nou niet echt het voorbeeld van een oplichter.

Ik kom overal die 1 kB tegen, die heeft Jan nooit geclaimd zover ik weet, die hebben we weer uitgerekent naar vermoedelijke feiten die nu niet meer staafbaar zijn. Wie heeft het over een processor?

Jan niet, ooggetuig verslag varieert van:

- hij sloot zijn kastje aan op een 22 inch monitor

- hij sloot zijn kastje aan op een 24 inch monito

- hij sloot zijn kastje aan op een laptop

Maakt nogal uit, en op welke ingang sloot Jan aan. is meer de interessante vraag hier.

RanDt

[Boaz]

Zijn broncode moet namelijk de precieze karacteristieken (formules dus) van al die verschillende fractals bevatten

Zo langzamerzeker varieren de verhalen behoorlijk. Wat ik me herinner van 5 jaar geleden is dat hij 3Gb aan code had, maar met die drie Gb kon hij wel alles definieren. Maar goed, ik probeer ook alleen maar een verklaring te vinden voor iets wat onverklaarbaar lijkt...

[Rogier]

Ik kom overal die 1 kB tegen, die heeft Jan nooit geclaimd zover ik weet, die hebben we weer uitgerekent naar vermoedelijke feiten die nu niet meer staafbaar zijn.

In de documentaire, en ook in eerdere verhalen die ik me over dit onderwerp kan herinneren, was sprake van "16 films op een geheugen kaartje van 64 kilobyte. En het kan nog beter, er zouden zelfs 64 films op kunnen."

[Boaz]

Ik heb daar ook mijn hoofd over gebroken. Met de techniek van Jan Sloot leg je oneindige dingen vast binnen een eindig getal. Dat is theoretisch alleen mogelijk als alles is opgebouwd uit fractals.

Hoe bedoel je?

Neem weer die 64 kB. Dan heb je nu eenmaal een beperkt aantal mogelijkheden. Neem in plaats van films nu eens miljoenen (of liever oneindig veel verschillende) bestandjes. Ik kan ze allemaal (misschien niet tegelijk) op diezelfde 64 kB kwijt. Maar ik heb maar een beperkt aantal mogelijkheden. Dus leg je eigenlijk een oneidig aantal vast binnen een eindig aantal. Aangezien dat (volgens mij) onmogelijk is, zul je het moeten doen met een soort 'loop'. Neem voor mijn part een getal, dat getal wordt d.m.v. algoritmes een aantal keer vermeerderd. Uiteindelijk komt daar een mega'getal' uit, of liever een hele reeks kleinere, die je vervolgens weer kan omzetten naar digitale codes. Het getal 64 is letter A is 40 Hex. Het getal 121064123001078 kun je dan lezen als 121-064-123-001-78, dat is weer 79-40-7B-1-4E in hex code.

Het probleem zit hem in het creeeren van je basisgetal. Als je een file omzet naar een lange logische reeks getallen dan komt daar uiteindelijk een mega groot getal uit. Dit getal zal je moeten zien te verkleinen door een algoritme te verzinnen dat omkeerbaar is. De uitkomst van het algaritme moet teruggerekend weer het orginele getal opleveren. Als je een algoritme kunt verzinnen waarbij de uitkomst ALTIJD kleiner is dan het orgineel, en de uitkomst terug te rekenen is naar het orginele getal dan geldt er daarna nog maar een voorwaarde. Het aantal keer dat je het algoritme erop los mag laten mag niet groter zijn dan het orginele getal. Nog sterker, het aantal digits moet minimaal 1 kleiner zijn.

Wat ik hierboven beschrijf is eigenlijk het zoeken naar de basis fractal die door hem maar vaak genoeg aan elkaar te leggen je uiteindelijk je orginele getal teruggeeft.

[Tool]

Ik ga me zelf toch maar eens verdiepen in het inkorten van data op alle mogelijke manieren, gewoon uit nieuwsgierigheid over hoe klein je bepaalde data in theorie op zou kunnen slaan en van welke informatie het daadwerkelijk nodig is om het over te sturen met de huidige grote van harde schijven.

[Anonymous]

zie vorige post, het getal 64 is letter A.

WE weten dat dit letter A is omdat dit zo gedefineerd is in de ASCII tabellen.

Maar hoe herkennen we ZELF de letter A, pasop wat we hier doen we claimen hieral een codering van meer dan 100% !! Kunnen we beter opschrijven van wat we zien (tekst, foto, beeld) en hoeveel externe code daarvoor nodig is. Als ik een nieuw alfabet zou bedenken, denk aan runen, kan ik met vision technologie en 2 runen miljoenen combinaties uitwerken? Denk 3 D !

Rand(t)

[Boaz]

Ik begrijp wat je wilt zeggen Rand. Het punt is dat de data van sloot uiteindelijk wel digitaal was. Dus met een ASCII tabel werkte (of er zelf een creerde). Het voorbeeld wat ik gaf moest duidelijk maken hoe ik de fractals voor ogen had.

Tool, ik be er ook al zo'n 5 jaar mee bezig. Maar als het al kan ligt het in ieder geval niet erg voor de hand. Hoe dan ook heb ik er wel wat aan. Ik heb ondertussen verscheidene applicaties geschreven voor encryptie. Geeft meteen een beetje inzicht in de onzin van het Echelon-project...

[fysica]

lachwekkend terwijl het heel simpel is...het alfabet bestaat uit 26 letters waarmee 1,26miljard woorden mee gemaakt kunnen worden.

Digitaal op zn best.. doseer de techniekniet sneller dan de aex kan volgen

[Boaz]

Moet je dus alleen nog een manier vinden om 26 delig op te slaan in plaats van binair (2 delig)....

[Wouter_Masselink]

Ik heb hier niet veel verstand van, maar zou het niet mogelijk zijn dat hij niet meer in eenen en nullen telt maar in q-bits of hoe ze die ook maar noemen.

[WiZ]

Sorry dat ik nog niet uit het boek heb geciteerd Druk druk druk Maar goed, ik heb hier een link naar de registratie van zijn vinding waarin beschreven wordt hoe hij werkt. Dat is nog beter dan citeren. Ik moet zeggen dat het erg interessant is hoewel ik niet alles begrijp.

Is een .pdf bestand by the way.

http://www.debroncode.nl/files/registratie_vinding.pdf

[Anonymous]

Naar mijn mening zijn de claims in de documenten niet mogelijk. Ongeacht de lengte van een film een unieke sleutelcode maken voor een unieke film, zonder dat de sleutelcode groter wordt dan 1 kB. Dat kan niet als die sleutelcode binair is, want het aantal unieke sleutels is dan eindig terwijl het aantal unieke films oneindig is (er is altijd nog een film die 1 frame langer is, en die kan je dus niet uniek meer coderen omdat je alle unieke waardes al gebruikt hebt).

Die sleutelcode kan dan dus niet binair zijn, en er wordt gezegd dat de sleutelcode wordt opgeslagen in een capaciteit van 1 kB dus 8192 bit posities. Wat nu als Jan Sloot er in is geslaagd op een bit positie een waarde te schrijven/lezen in het bereik [0.0-1.0]. Als dit zelfs een continu bereik is ® dan kun je oneindig veel waardes kiezen in dit bereik, je kan namelijk altijd een waarde kiezen die tussen twee punten in het bereik ligt (bijv. tussen 0.45 en 0.46 kies je 0.455). Het probleem zit hem hier in de beperking van de hardware: hoe precies kan je lezen/schrijven. Op zo'n manier kan je veel meer informatie kwijt in hetzelfde aantal bit locaties dan wanneer je binair opslaat.

- In het interview [http://debroncode.nl/files/Interview_va ... Pieper.doc]

"ES: Sloot kon video, audio en data versleutelen?

RP: Maar hij kon het niet versturen op een netwerk, daar zat het probleem.

ES: Maar een sleutelcode zoals Sloot die kon maken, kun je toch gewoon over een netwerk versturen?

RP: Maar daar ging het niet om, je moest de database versturen en dat lukte hem niet.

ES: Maar een database kun je ook als een stuk electronica op de markt brengen, verpakt als een soort settopbox.

RP: Nu gaan we er even te diep op in. Daar kunnen we beter een andere keer verder over praten, maar dan wel op basis van fair play."

database versturen , de sleutelcode zou toch voldoende moeten zijn??? En als de sleutelcode niet binair is opgeslagen, maar zoals beschreven hierboven, dan kan je deze dus niet oversturen via de normale netwerken omdat die namelijk binair werken (ronden af naar 0 of 1). Dan zou je dus die informatie weer om moeten zetten naar binair en dan heb je vervolgens dus weer gigantisch veel bits nodig.

Ik snap niet dat Roel Pieper zo makkelijk overtuigd was van de Vinding. Wat ik gelezen heb dan is er nooit een goede proef/demo gedaan. De demo die gedaan werd was genoeg om interesse te wekken, maar was totaal geen bevestiging van de gemaakte claims. De demo voorgesteld door Natlab (p.170) had wel volstaan, deze zou hebben uitgewezen of inderdaad alle benodigde informatie op de chipcard staat (het zou niet hebben aangetoond of de sleutelcode geschikt is om over traditionele netwerken, binair dus, te versturen). Voor deze demo zouden twee Sloot kastjes nodig zijn. Op kastje A wordt een nieuwe film gecodeerd en op de chipcard wordt de sleutelcode gezet. De chipcard wordt vervolgens in kastje B gestoken en de film wordt hierop gedecodeerd/afgespeeld. (De inhoud van kastje B mag niet worden aangepast nadat er bekend is welke nieuwe film er gecodeerd gaat worden. (Kastje B staat in een anechoische ruimte: ruimte waar geen radiogolven of andere storingen naar binnen kunnen komen, zodat er geen draadloze communicatie met het kastje mogelijk is)

Een groot aantal partijen wilde pas geld investeren nadat zo'n dergelijke proef succesvol was afgerond. Voor Pieper, die toch verstand zou moeten hebben van wiskunde en informatica, was dit niet nodig

[Rogier]

Ik heb hier niet veel verstand van, maar zou het niet mogelijk zijn dat hij niet meer in eenen en nullen telt maar in q-bits of hoe ze die ook maar noemen.  

Misschien, maar dan heeft de vinding geen reet met films of audio/video compressie te maken, maar met een andere data-opslagtechniek. De nadruk werd in dit hele verhaal erg op films gelegd, en dat impliceert dat het qua informatiehoeveelheid, dus ook in termen van normale binaire bits, veel kleiner zou worden.

[WiZ]

- In het interview [http://debroncode.nl/files/Interview_va ... Pieper.doc]

"ES: Sloot kon video, audio en data versleutelen?

RP: Maar hij kon het niet versturen op een netwerk, daar zat het probleem.

ES: Maar een sleutelcode zoals Sloot die kon maken, kun je toch gewoon over een netwerk versturen?

RP: Maar daar ging het niet om, je moest de database versturen en dat lukte hem niet.

Als ik de registratie goed heb gelezen begrijp ik eruit dat hij die "database" op hardware heeft opgeslagen en ik weet het niet zeker maar volgens mij kun je hardware alleen via de post in een pakketje versturen.

ES: Maar een database kun je ook als een stuk electronica op de markt brengen, verpakt als een soort settopbox.

RP: Nu gaan we er even te diep op in. Daar kunnen we beter een andere keer verder over praten, maar dan wel op basis van fair play."

Te diep?? Hier gaat het toch om? Het moge toch duidelijk zijn dat Sloot het niet kon zonder dat kastje. In de artikelen en documantaire's wordt meer malen gezegd dat de vinding in computers geintegreerd moet worden zoals er nu op zo'n beetje elke versterker dolby zit.

[Anonymous]

Als ik de registratie goed heb gelezen begrijp ik eruit dat hij die "database" op hardware heeft opgeslagen en ik weet het niet zeker maar volgens  mij kun je hardware alleen via de post in een pakketje versturen.

Hardware binair opslaan is inderdaad lastig . Maar als die 'database' hardwarematig zou zijn, dan zou die zich dus bevinden in elke Sloot decoder. Die hoef je dus niet te versturen, en volgens de claims hoeft die ook niet aangepast te worden. De database zou generieke data moeten bevatten waarmee alle mogelijke films opgebouwd kunnnen worden. Er werd gesuggereerd dat je enkel met een chipcard met sleutelcodes deze films op elk decoder kastje af zou kunnen spelen (decoderen), en dat de sleutelcodes binair op zo'n chipcard zijn opgeslagen. Binaire informatie kan je dus versturen over een digitaal netwerk.

Te diep?? Hier gaat het toch om? Het moge toch duidelijk zijn dat Sloot het niet kon zonder dat kastje. In de artikelen en documantaire's wordt meer malen gezegd dat de vinding in computers geintegreerd moet worden zoals er nu op zo'n beetje elke versterker dolby zit.

Inderdaad. Hier wil Pieper dus niks over zeggen. Ik vermoed dat hij per ongeluk heeft genoemd dat er naast de sleutelcode ook een database verstuurd moet worden. En dat was nergens anders genoemd! Deze database bevat dus waarschijnlijk informatie voor die specieke film (of een beperkt aantal films). Ik denk dat het mogelijk zou zijn dat in de decoder deze database wordt opgeslagen (mogelijk niet binair) wanneer er films mee gecodeerd worden. En dat de database opgeslagen blijft in de decoder. Met behulp van een sleutelcode kan je dan enkel op ditzelfde kastje de films weer afspelen. Wil je echter met de sleutelcodes op de chipcard de films op een ander decoder kastje afspelen, dan zul je moeten zorgen dat je ook de bijbehorende database hebt. Die zul je dus ook op een of andere manier moeten verkrijgen. Dit was waarschijnlijk het probleem. Op deze manier dienen de sleutelcodes meer als beveiliging dan als opslag van de film. Zonder de sleutelcodes kan je de film niet afspelen. Maar deze sleutelcodes hadden ook net zo goed in de decoder kunnen worden opgeslagen omdat ze toch enkel bruikbaar zijn op een decoder waarvan de bijbehorende database nog in het geheugen staat. (Dit is een mogelijkheid die ik waarschijnlijk acht en waardoor de uitvinding niet zo'n grote impact zou hebben die er voorspeld werd)

Ik weet niet hoeveel exemplaren van het kastje Sloot in zijn bezit had? Mogelijk maar 1 (ik heb over geen demo gelezen waarbij meerdere kastjes aanwezig waren), dus dit is niet uitgesloten.

Ik weet niet of het interview met Ivo Niehe al is opgenomen, en of het anders mogelijk is om hem enkele vragen hierover te laten stellen aan Pieper. Ik betwijfel of Ivo Niehe genoeg kennis heeft om wat zinnige informatie los te peuteren bij Pieper. Ik neem ook aan dat Pieper hier geen aandacht aan wil geven.