mega
Rolex
Well, problemet så som jag ser det är att hur du än vrider och vänder på detta så är det du försöker göra; binda en sträng till ett fysiskt objekt. Detta är möjligt ur ett relationsperspektiv, men inte möjligt sett ifrån en säkerhetssynpunkt. Om strängen på något sätt går att manipulera eller byta ut på objektet, så brister hela konceptet.
Så att bygga ett system kring det fysiska klockor, hade kanske vart möjligt med DNA-märkning och kryptografiska chip om klockorna tillverkats med det ifrån start. Men, detta innebär att inga klockor som inte tillverkas med just den processen, skulle gå att säkra. Så alla klockor som redan finns, går inte att säkra på det sättet. Det finns väl redan klocktillverkare som gör detta idag ? Hade inte breitling någon idé här kring tex. ?
"Sen hoppas man på att de fysiska datapunkterna inte ändras över tid? " , och om det gör det, ska man då nullifiera diamanten och räkna den som oäkta helt plötsligt ? Tråkigt för den som köpte den stenen. Om objektet också bara kan ändras på utav den som äger privata nyckeln, hur gör man då om personen förlorar sin nyckel ? Vad gör man vid dödsfall ?
En centraliserad databaslösning med checksummeverifiering. Det hade vart mycket snabbare än en blockkedja också. En blockkedja ser ut som den gör, för att den har settlementperioder där informationen sparas, vilket är nödvändigt då systemet behöver veta att alla noder är överens. Detta gör processerna kring kedjan långsamma.
Både ja, och både nej! Historiken i en blockkedja går att ändra, om 51% eller mer av nätverket är överens om ändringen. Kretsar systemet kring en centraliserad part,kan man oftast räkna med att dom har merparten utav beräkningskapaciteten i nätverket.
Well, problemet så som jag ser det är att hur du än vrider och vänder på detta så är det du försöker göra; binda en sträng till ett fysiskt objekt. Detta är möjligt ur ett relationsperspektiv, men inte möjligt sett ifrån en säkerhetssynpunkt. Om strängen på något sätt går att manipulera eller byta ut på objektet, så brister hela konceptet.
Så att bygga ett system kring det fysiska klockor, hade kanske vart möjligt med DNA-märkning och kryptografiska chip om klockorna tillverkats med det ifrån start. Men, detta innebär att inga klockor som inte tillverkas med just den processen, skulle gå att säkra. Så alla klockor som redan finns, går inte att säkra på det sättet. Det finns väl redan klocktillverkare som gör detta idag ? Hade inte breitling någon idé här kring tex. ?
"Sen hoppas man på att de fysiska datapunkterna inte ändras över tid? " , och om det gör det, ska man då nullifiera diamanten och räkna den som oäkta helt plötsligt ? Tråkigt för den som köpte den stenen. Om objektet också bara kan ändras på utav den som äger privata nyckeln, hur gör man då om personen förlorar sin nyckel ? Vad gör man vid dödsfall ?
En centraliserad databaslösning med checksummeverifiering. Det hade vart mycket snabbare än en blockkedja också. En blockkedja ser ut som den gör, för att den har settlementperioder där informationen sparas, vilket är nödvändigt då systemet behöver veta att alla noder är överens. Detta gör processerna kring kedjan långsamma.
Både ja, och både nej! Historiken i en blockkedja går att ändra, om 51% eller mer av nätverket är överens om ändringen. Kretsar systemet kring en centraliserad part,kan man oftast räkna med att dom har merparten utav beräkningskapaciteten i nätverket.
Det man knyter klockan med är serienumret, som är instansat i boetten samt står på ett cert.
Visst kan man ändra/förfalska det på en stulen klocka, mendet är mycket jobb, sen skall du bevisa för AD att du är nya ägaren också (kvitton?)...
Vid dödsfall måste den nya ägaren förstås presentera papper för AD från dödsbo etc som gör honom till ny ägare.
Historiken i BC går inte att ändra, oavsett 51%. Däremot kan du smyga in felaktigheter i nya transaktioner.
Har man en kopia av BC så ser man direkt att någonting har ändrats.
I min värld kommer tillverkaren, ex. Rolex att ha 100% av nätverket, så det blir i praktiken en non-issue.
Det är inte heller ett speciellt transaktionsintensivt nätverk, så jag tror inte att effektiviteten/snabbheten skulle vara ett problem.