mahatma

Das Ziel von Radix: Ein Layer-1 Protokoll, welches alle Transaktionen der Welt verarbeiten kann, heute, und noch in 100 Jahren. Welches Sicher ist, einfach zu benutzen, und in dem es einfach und intuitiv ist, Anwendungen zu programmieren und welches auf Grund dieser Punkte geeignet ist, Krypto und Defi wirklich massentauglich zu machen. Dazu braucht es u.a. zwei zentrale Dinge: Der Konsensmechanismus muss linear skalieren Die "user-experience" muss einfach und intuitiv sein. Zu Punkt 1: Der Cerberus Konsensmechanismus skaliert linear, ist eingehend geprüft, von der University of California Davis peer-reviewed und im Journal of Systems Research veröffentlicht. https://escholarship.org/uc/item/6h427354 Des weiteren wird er seit fast 3 Jahren im Rahmen des Cassandra Netzwerkes in einer Testumgebung mit paar Dutzend Nodes getestet und optimiert und "fertiggestellt". Die lineare Skalierbarkeit ist also kein "absurdes Marketingversprechen" sondern läuft und wird getestet. Aber, niemand braucht lineare Skalierbarkeit, solange das Ökosystem nicht ausgelastet ist, weil es nicht benutzt wird. Das bringt und zu Punkt 2: Die user experience muss einfach sein, um wirklich massentauglich zu werden, der Krypto-unerfahrene Neuling muss sich "sicher" fühlen und Vorgänge intuitiv verstehen. Umgesetzt wird die mit der Radix Engine, dem alternativen Konzept zur EVM. Die imho entscheidenden Unterschiede: Objekte wie Token, NFTs, Rechte, Smartaccaounts und deren Interaktionsweisen sind nativ auf Protokollebene definiert. Objekte wie Token, NFTs etc sind dabei immer echtes "Eigentum" eines Accounts, also einer Adresse, es wird nicht über Kontostandslisten innerhalb eines Smartcontracts gearbeitet, so wie bei Ethereumartigen VMs. Transaktionen sind human readable und passieren auf Protokollebene. Das heisst, die VM ruft nicht einfach nur nen SC auf, ohne eigentlich genau zu wissen was der macht und der Benutzer muss sich vom Ergebnis überraschen lassen. Die Transaktion direkt auf Protokollebene weis was ihre Inputs sind, mit welchem Contract sie interagieren soll und was die Outputs sein werden. Dies wird dem Benutzer im Transaktionsmanifest zur Unterschrift vorgelegt, und es wird genau dies und nichts anderes passieren, oder die Transaktion scheitert. Sie kann auch nie "halb" ausgeführt werden, es können keine "Zwischenstates" hängen bleiben, braucht keine Rollbacks etc, und dies immer über den ganzen Datenspace des Ledgers, über alle Shards hinweg, mit egal wievielen beteiligten Substates. Der ganze Metamask Blödsinn den man hier ständig liest, die allermeisten Scams und Exploits, liegen in der Grundarchitektur der EVM begründet, die selber als Asset nur ETH versteht und handeln kann, der ganze Rest, alle Tokens etc, sind Smartcontracts die selbstständig Liste führen über die verschiedenen Kontostände, die EVM versteht an sich nichts vom Konzept "Token" etc, das muss über die verschiedenen ERC Schnittstellen definiert werden und ist eigentlich maximal unintuitiv, komplex und fehleranfällig. Bei Transaktionen ist man bei der Unterschrift darauf angewiesen dem SmartContract zu vertrauen, hat er Schadcode verbaut kann der normale User das erst im nachhinein feststellen. Bei Radix läuft das vereinfacht ausgedrückt so aus: Die Transaktion wird von der Radix Engine probeweise ausgeführt und geschaut was für substates als outputs entstehen würden. Dieses Ergebnis wird dem Benutzer zur Unterschrift vorgelegt. Nach der Unterschrift muss es von allen beteiligten Nodes ausgeführt werden und alle Nodes müssen zum gleichen Ergebnis kommen. Dann wird es zum Ledger geschrieben, zusammen mit dem ganzen Kryptografischen Nachweis der in der Kommunikation zwischen den beteiligten Nodes angefallen ist. Würde ein Smartcontract was anderes machen, als im Transaktionsmanifest stand und unterschrieben wurde, dann würde die Transaktion auf Protokollebene scheitern, ganz unabhängig von der etwaigen Anwendung, dem Smartcontract o.ä. Und dieser ganze Teil von Punkt 2, das ganze Ökosystem, die RadixEngine, das Transaction Manifest, die Radix Wallet und n ganzer Zoo von Dapps wie Exchanges, Lending Protocols, paar Spiele und sehr coole Geschichten wie http://xrd.domains sind bereits live und voll funktionsfähig. Was wir doch eigentlich alle wollen, den Coin, die Layer-1 Lösung, die es echt schafft Crypto massentauglich zu machen, früh zu entdecken und vom Hype von Anfang an profitieren. Schaut euch Radix mal an und entscheidet selbst ob es das Potential für ne Revolution hat, das Potential Ethereum vom Thron zu stossen. Und schaut es euch aus der Perspektive des unerfahrenen Benutzers an, der einfach nur was Anwenden will, so wie ne Banking app, und dabei nicht ständig durch ein Minenfeld voller Exploits und Bedrohungen manövrieren will. Radix Wallet für iOs oder Android runterladen, sich paar XRD besorgen und mal rumspielen. Bischen staken, bischen Liquidity providen, bischen auf ociswap traden, sich paar Adressen bei xrd.domains für die Zukunft sichern und anderen Scheiss. Und das dann vergleichen mit ähnlichen dApps auf Ethereum, Cardano, Solana usw.... Und sich überlegen ob der Coin mal zu Relevanz kommen könnte. Vom CEO von Radix gibts ne neues Interview, sehr schön und sauber die wichtigsten Punkte erklärt und dargestellt, auch im Vergleich zu Solana, MOVE, und anderen. Schaut es euch an und seht selbst in wie weit es sich um absurde Marketingwerbung handelt. Bzw probierts einfach mal aus!

Die Idee einer Hardware Wallet wie BitBox02 ist, dass man Seed bzw. PrivateKey NIE auslesen kann, nur die "Unterschrift" verlässt die BitBox02, und von der lässt sich nicht auf den private key schliessen. Also egal ob deine Sparrow Wallet kompromittiert ist, den private Key kann sie nicht auslesen. Was sie kann: Den Inhalt der Transaktion ändern, zB die Zieladresse. Deswegen Adressen immer direkt auf dem Display der BitBox02 kontrollieren/abgleichen! Nur was auf dem Display der BitBox steht stimmt auch und wird tatsächlich ausgeführt.

Falls es da ein Missverständniss gibt: EIN Private-Key gehört immer zu genau EINEM Public Key, das passt so. Die Seed-Phrase beinhaltet viele PrivateKeys, und somit auch viele Public Keys und Adressen. Genau so kenn ich das auch, bei ETH muss man beim Starten der Wallet die eine Adresse bzw. den einen Public Key mit dem man arbeiten will auswählen. Man kann nicht wie bei Bitcoin automatisch mit allen Adressen des Seeds gleichzeitig "arbeiten". Man kann aber durchaus mit den verschiedenen Adressen arbeiten, halt muss man pro Session entscheiden mit welcher. Das bei einem Private Key nur der "eine" public Key kommt ist wie gesagt normal und liegt in der Natur der Sache.

ja, das mag sein! Ich weis nicht in wie weit du mit dem Konzept von Sharding bei Radix vertraut bist. Die Radix Engine ist ne Finite State Machine, im Ledger werden also immer "substates" gespeichert, deren Zustand entweder UP oder DOWN sein kann. Der Cerberus Konsensus arbeitet auf einem pre-sharded Shard-Space mit 2^256 Shards, identifiziert durch den Hash des im Shard gespeicherten Zustandes. Also hat jeder substate einen eigenen Shard! Da die Identifizierung und Positionierung jedes Substates im Shardspace durch den Hash geschieht, hat man automatisch ne gleichmässige Verteilung von Zuständen im Space. Die Validatoren bekommen in regelmässigen Abständen zufällig jeweils nen bestimmten Bereich im Shardspace zugeteilt. Je mehr Validatoren sich beteiligen, umso kleiner wird der pro Validator abgedeckte Bereich des Shardspaces. Der Cerberus Konsens sorgt dafür, das sich für jede Transaktion alle Validatoren abstimmen, die für diejenigen Shards zuständig sind, in denen substates gespeichert sind die in der Transaktion vorkommen. Erst wenn alle von einer Transaktion betroffenen Validatorengruppen der Ausführung zustimmen und sich gegenseitig beweisen das die Ausführung der Transaktion bei allen zum gleichen Ergebnis führt, gehts auf den Ledger. Dadurch sind Transaktionen vom Prinzip her "atomicly composabel" und "atomicly commited", können also beliebig komplex sämtliche Inhalte des gesamten Ledgers enthalten, und werden entweder vollständig ausgeführt oder gar nicht. Keine Roll-backs u.s.w., sondern echtes atomic commitment über den ganzen Shardspace hinweg. Der Cerberus Konsens arbeitet voll parallelisierungsfähig, da sich für jede Transaktion nur die Validatoren die betreffende substates enthalten abstimmen müssen. Es gibt keine zentrale Chain o.ä. die sich irgendwann als Bottleneck rausstellen könnte. Zum besseren Verständnis: https://www.radixdlt.com/blog/cerberus-infographic-series-chapter-ii Der Shardspace wird auf Seite 5 erklärt. Ansonsten, wer Twitter hat, checkt mal fuserleer (Dan Hughes) aus. #cassie leistet bereits erstaunliches. Im Testnetz (Cassandra) läuft das bereits alle Erwartungen übertreffend. Mit dem Netzwerk Update Xi'An läuft das volle Sharding im Mainnet.

Halten wir das mal für die Nachwelt fest und schaun in 2 Jahren wieder auf den Satz. DYOR

Bei Radix sind die accounts (= Adressen) bereits nativ in der Radix Engine als "programmierbare SCs" ausgelegt. Das was bei Ethereum mit Account Abstraction kompliziert nachgeflickt werden muss, ist hier ne native Eigenschaft des Ledgers selbst. So wie ich das verstanden habe sind alle Adressen "im Auslieferungszustand" erstmal im Modus "Berechtigung durch Vorweisen einer gültigen Unterschrift(Secp256k1)", dies kann dann einmalig und nicht weiter veränderbar geändert werden in den Modus "Berechtigung durch Vorweisen einer gültigen "Badge", bzw eines gültigen "Ausweises"". Mithilfe individuell erzeugbarer "Badges" kann damit ne ganze Fülle von Bedingungen für die Berechtigung zum Zugriff auf einen bzw. zur Wiederherstellung von einem Account konstruiert werden. genaueres unter: https://docs.radixdlt.com/v1/docs/account#account-securification und https://docs.radixdlt.com/docs/access-controller

Der Hash von deiner binary zahl lautet: a17f0556a30f8b9b45b521cb5b3d20d936d708aac0c79b5ada13665dde2edab4 A1 von Hex nach Binary: 10100001 Also letztes Wort: 00110100001 = 417 = crouch Wortliste: region melt always snake carpet sauce mail crucial draft romance humor diary seminar evoke fatigue deer pistol cake decline stove reopen dignity veteran crouch Das ist komplizierter und geht nicht "per Hand" hier was zum einlesen: https://learnmeabitcoin.com/technical/keys/hd-wallets/derivation-paths/

google: HEX Editor für iOS, dann runterladen. Keine Ahnung was da empfohlen ist, irgendein hexeditor halt. Siehste schon wie das dann läuft, das ist selbsterklärend. Wenn du ne Datei neu öffnest (binär!!) dann kannste da byteweise Werte eingeben, immer in Hex. Rechts zeigts dir dann an wie das in ASCII aussieht, meist nur wirre Zeichen. Die abgespeicherte Datei ist dann in diesem Falle, oh Wunder, genau 32 Byte gross. Wenn du die HexZahl als Textdatei abspeicherst, ist die Datei 64 Byte gross, da jedes Zeichen ein Byte erfordert. Nach dem abspeichern kannst du die Datei natürlich direkt im Terminal hashen. Ich hab dir ja oben für die Beispiele die Hashes geschrieben, kannst ja jetzt rumprobieren bis du aufs gleiche kommst In Windows gehts mit "Get-FileHash" in der Powershell. Zum Umrechnen von Bit auf Hex: Probier ian coleman aus. Geht viel einfacher, und es zeigt dir gleich noch die Seedwörter und Haufen andere Info an. Ist n cooles Tool, wenn mans mal geschnellt hat, und du hast dich eh schon recht tief eingearbeitet.

hat in dem falle aber nur mit nem falsch berechneten 24ten wort zu tun, nicht mit electrum

Also man der Reihe nach, hab das grad für dich durchgezogen: deine 23 Wörter ergeben die binäre Zahl mit 253 bit: 1011010010010001010101000001111001100110100100100010110101111111001000011000100110100011010000011111011101110001101111000001111010101100001110001001110000010100111100011100101010100101011001000000100011100011111010110101101101100110011111000011110011001 Das 23te Wort ist 11110011001, 1945, veteran. Jetzt wählst du willkürlich 3 bit, zB 001. (in dem Zitat von dir hast du 011 gewählt). Das führt zur 256 bit Zahl: 1011010010010001010101000001111001100110100100100010110101111111001000011000100110100011010000011111011101110001101111000001111010101100001110001001110000010100111100011100101010100101011001000000100011100011111010110101101101100110011111000011110011001001 dies gibt in hex: b491541e66922d7f2189a341f771bc1eac389c14f1caa56408e3eb5b667c3cc9 jetzt dies in ne binäre datei speichern. (hex editor) der hash sha256 gibt: a17f0556a30f8b9b45b521cb5b3d20d936d708aac0c79b5ada13665dde2edab4 A1 = 10100001 Also ist das letzte Wort: 00110100001 = 417 = crouch Wenn du als letzte 3 bit 011 wählst, lautet deine 256 bit Zahl: 1011010010010001010101000001111001100110100100100010110101111111001000011000100110100011010000011111011101110001101111000001111010101100001110001001110000010100111100011100101010100101011001000000100011100011111010110101101101100110011111000011110011001011 hex: 0xb491541e66922d7f2189a341f771bc1eac389c14f1caa56408e3eb5b667c3ccb binär gespeichert und gehasht: 450f6d2f1e11ea7b98730eb550011718c3e3c6732f0b76a50d6d40f514a6507e 0x45 -> 01000101 letztes wort: 01101000101 = 837 = hamster jetzt klarer? spiel einfach mal mit hex editor und hash tool rum, unterstütz das mit ioan coleman, dann kommste dahinter. gerne fragen, dann geh ich weiter drauf ein.

ja, aber du willst keinen text string hashen, sondern die "echten daten". Also am besten im hex editor ne binäre Datei erstellen, da die 32 byte hex zahl eingeben, die datei abspeichern und dann die datei hashen. dann müsste es passen.

völlig korrekt

Du hast den String "101101...." gehasht. Du müsstest den Hash der Binary Daten deiner 256 bit Hashen, in Hex Format wäre das: b491541e66922d7f2189a341f771bc1eac389c14f1caa56408e3eb5b667c3ccb. Also die gleiche "Zahl", aber in Hex Darstellung, als 32 Byte binary. Wenn de das in ne binary datei schreibst und die hashst müsste das richtige rauskommen. naja, kann er ja willkürlich wählen, oder nicht. eine von den 8 Möglichkeiten fürs letzte Wort. die restlichen 8 bit müssen durch den Hash aufgefüllt werden. @andoo Was ich mittlerweile mache um das 24te Wort rauszufinden und auf dem Weg kein elektronisches Gerät zu verwenden: Ich erstell mir die 256 bit Zahl, so wie du auch, und komm dann auf 23 Wörter. Die geb ich in meiner Bitbox02 ein, direkt an der Bitbox, also keine internetverbindung/ auslesbarewr kontakt zu pc etc. Dann zeigt es dir direkt 8 verschiedene wörter zur auswahl fürs 24te wort an. Kannste an der bitbox auswählen und hast dann garantiert nen gültigen seed ohne irgendwelche hilfsmittel (ausser die bitbox02, aber da musstn später eh eingeben) verwendet zu haben... PS: Ansonsten zum rumspielen und hin und her konvertieren: https://iancoleman.io/bip39/ Nur halt nicht für den echten seed verwenden, bzw dann nur offline in echt sicherer umgebung. Besser mit der bitbox. 23 wörter würfeln, bitbox macht den rest.

Und mal wieder was von RADIX: Ein neues Interview von Dan the Man, grad paar Tage alt. Wie immer ne ausführliche Erklärung in die Technologie von Radix, aktuelle Infos zu Roadmap und Entwicklungsstand jetzt und daneben tiefgehende Schulung in Konsensmechanismen, permissionless Netzwerke und das ganze Ökosystem an sich. Ich geniess es dem Typen zuzuhören... https://www.youtube.com/watch?v=E9yr7JN3oC0 Ums wieder und wieder und wieder zu wiederholen und die Geschichte langsam ins Bewusstsein der Masse zu bringen: Dan hat 2013 erkannt, dass es für ne echt globale, dezentrale Lösung für nen public Ledger der potentiell mit allen Daten der Welt umgehen kann, lineare Skalierung erfordert. Und hat sich dann zuerst drangemacht, dieses Problem zu lösen, bis er nach 8 Jahren Arbeit nen Konsensmechanismus hatte, der linear Skaliert, also mehr Durchsatz bekommt je mehr Geräte sich dem Netz anschliessen. Erst danach hat sich so langsam ein Ökosystem gebildet, erstmal ein sehr vereinfachtes Mainnet (Olympia), seit letztem Jahr ein Mainnet mit der vollen Funktionspalette von Skrypto, SC-Fähigkeit und so weiter, mit dem später auch verwendeten Konsensmechanismus, nur bis jetzt nur ein Shard (Babylon). Das heisst alles, von der RadixEngine, zum Transaktionsmanifest, der atomic Composability, usw. ist alles im Hinblick auf das spätere Sharded Netzwerk entwickelt. Jetzt muss man es nur noch einschalten, nachdem es auf Herz und Nieren getestet wurde und wird, im Test läuft es bereits seit Jahren unter dem Namen Cassandra, im Mainnet soll es innerhalb des nächsten Jahres als Xi'An online gehen. Dann hat es Potential zu nem neuen Netzstandard zu werden, so wie tcp/ip zum Beispiel. Radix bereitet sich gerade darauf vor, ein echtes Cassandra Netz mit möglichst vielen Nodes weltweit aufzubauen, quasi ein Testnetz das sich wie ein Mainnet verhält, um dann unter realen Bedingungen Tx-Durchsatz und so Zeugs zu messen und die Limits zu testen. Hier spricht Dan im oben verlinkten Video davon: https://www.youtube.com/watch?v=E9yr7JN3oC0&t=4801 Ziel ist nen neuen Weltrekord aufzustellen, mit 1.000.000+ SC-Transaktionen pro Sekunde. Hat keiner der Tech Jungs von euch Bock sich zu beteiligen? @skunk,hast du noch Ressourcen für ne Cassandra-Node übrig ? Die einmalige Chance beim Weltrekord mitzumachen, Geschichte zu schreiben, und gleichzeitig tiefer in die Tech von Radix einzusteigen? Ich wär ja brennend an euren Erfahrungen und Einblicken interessiert, leider hab ich keine Möglichkeiten das selbst zu machen... PS: Das ist die Telegram Gruppe: https://t.me/cassandraplayground

naja, willst das ich Zahlen einsetze? Also gut: Angenommen wir haben nen Computer der pro Sekunde 1000 Milliarden Seeds überprüfen kann. Das bedeutet, ne 256 bit Zahl wählen, die zugehörigen Adressen errechnen und schaun ob da Saldo drauf ist. (Keine Ahnung wie schnell das mit zB der kompletten Hashpower des BTC Netzwerkes möglich wäre, nur mal ein willkürlicher Wert. So oder so ist das "Bottleneck" das Überprüfen der zugehörigen Adressen, vielleicht hat da jemand ne Zahl, was für ne Rate man da erreichen kann) 1000 Milliarden wären 10^12. Ein Jahr hat 24*3600*365= ungefähr 30.000.000 Sekunden. Also könnten pro Jahr grob 3*10^19 Seeds abgegrast werden. Im obigen Beispiel mit den 3 Teilen würde das bedeuten das man im Jahr in etwa ein zehn-millionstel des Zahlenraums von 3*10^26 abchecken könnte, (was dem Zahlenraum eines 8 Worte Seeds entspricht). Aktuell gibt es so weit ich weiss grössenordnungsmässig ca 100 mio BTC Adressen mit Guthaben drauf. Hab jetzt das mit der Stochastik nicht mehr wirklich parat, aber würde sagen in diesem Konstrukt wäre der "Erwartungswert" ca 10 Treffer pro Jahr. Falls man der Einfachheit halber annimmt, das pro Sekunde 1000 Milliarden Adressen überprüft werden, im Falle von Seeds wären es multiple Adressen pro Seed, käm also noch n Faktor drauf. So, bei genau dem gleichen Konstrukt mit nem 24 Wort Seed, wäre der Zahlenraum 3*10^79, also um nen Faktor 10^53 grösser. Um mit ner Wahrscheinlichkeit von 1 : 1 Billion (1 : 1.000.000.000.000) einen Treffer zu bekommen, müsste die gleiche Rechenleistung über 10^40 Jahre lang aufgewendet werden, das heisst selbst bei eine Billion mal eine Billion mal Alter des Universums würde immer noch n Faktor von ca einer Million fehlen. (wenn ich mich jetzt bei nen Nullen nicht verzählt habe. )