--- title: W-OTS Migration Addresses tags: discussion --- # W-OTS Migration Addresses ## Summary Starting with Chrysalis Part 2, the IOTA protocol will remove support for W-OTS signatures and addresses. As such, there needs to be a migration process of moving funds from W-OTS addresses in the old network to Ed25519 in the new network. The proposed solution involves moving funds to a legacy address uniquely generated from the desired target Ed25519 address. This documents describes how this migration addresses are computed. ## Detailed design ### Generating the 81-tryte migration address According to [Draft RFC-8](https://github.com/luca-moser/protocol-rfcs/blob/signed-tx-payload/text/0000-transaction-payload/0000-transaction-payload.md) an Ed25519 address A consists of 32 raw bytes. This needs to be converted to a 81-tryte address: - Compute the [BLAKE2b-256](https://tools.ietf.org/html/rfc7693) hash H of A. - Append the first 4 bytes of H to A, resulting in 36 bytes. - Convert A to trytes using the `b1t6` encoding (as described in [RFC-15](https://github.com/iotaledger/protocol-rfcs/blob/master/text/0015-binary-to-ternary-encoding/0015-binary-to-ternary-encoding.md)). This results in A<sub>tri</sub> consisting of 72 trytes. - Prepend the 8-tryte prefix `TRANSFER` to A<sub>tri</sub>. - Finally, pad A<sub>tri</sub> with the single tryte `9` to get a legacy 81-tryte address. Since A<sub>tri</sub> is an arbitrary address generated without any underlying private key, it will be practically impossible to access funds on the address and, thus, those funds are effectively burned. The 9-tryte address checksum can be [computed and added as usual](https://docs.iota.org/docs/getting-started/1.1/cryptography/checksums). ### Decoding the 81-tryte migration address - Valid migration addresses start with `TRANSFER` and end with `9`. - The 72 trytes after `TRANSFER` represent a valid `b1t6` encoding of 36 bytes. - The first 32 bytes of the result are called A and the last 4 bytes H. - Check that H matches the first 4 bytes of the BLAKE2b-256 hash of A. - The encoded Ed25519 address is A. ### Example - Ed25519 address (32-byte): `6f9e8510b88b0ea4fbc684df90ba310540370a0403067b22cef4971fec3e8bb8` - Migration address including 9-tryte checksum (90-tryte): `TRANSFERCDJWLVPAIXRWNAPXV9WYKVUZWWKXVBE9JBABJ9D9C9F9OEGADYO9CWDAGZHBRWIXLXG9MAJV9RJEOLXSJW` > Example Go implementation in [wollac/iota-crypto-demo](https://github.com/Wollac/iota-crypto-demo): > - Address generation and decoding: [pkg/migration](https://github.com/Wollac/iota-crypto-demo/blob/master/pkg/migration/migration.go) ## Open Questions - Any alternative prefix is fine. However it should make sense logically and there should not be too many addresses currently starting with this prefix.
Last changed by  
 
Protocol Team
Specing Iota Day and Night
628

Read more

Untitled

12/1/2022
VRF

Verifiable random function

11/11/2022
VRF & ASM

VRF verifiable random function for random sortitioning medium on algorand ietf draft VRF algorand impl BLS signature for VRF? VRF RFC draft-15 API

11/7/2022
Publicly verifiable multi-user public key encryption

Introduction Public key encryption (PKE) is a standard tool used in many protocols with two parties -- sender and receiver. Sender uses receiver's public key to encrypt a secret message and receiver uses her private key to decrypt it. In modern (decentralized) protocols there's a third party -- verifier. Verifier acts as an arbiter, she verifies that both parties (sender and receiver) follow the protocol correctly. When there's a need for privacy a PKE scheme does not offer the verifier to do her job -- to get access to the encrypted message privacy property must be sacrificed. To overcome this issue there's publicly verifiable public key encryption (PVPKE). In such a scheme the sender encrypts a message and proves certain useful properties about it such that the verifier can verify the proof (ie. that the properties do actually hold for the encrypted message without decrypting it) and the receiver can decrypt the message as usual. Some useful properties about encrypted text might include the following: proof of decryptability, ie. that the receiver can indeed decrypt the message (and not claim that she can't, without revealing her private decryption key); proof of correct encryption, ie. that the sender has encrypted a valid message (and not some garbage).

6/30/2022
Read more from Protocol Team
Published on HackMD