[{"data":1,"prerenderedAt":1327},["Reactive",2],{"content-query-U1zbmj8pgl":3},{"_path":4,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"title":8,"description":7,"body":9,"_type":1322,"_id":1323,"_source":1324,"_file":1325,"_extension":1326},"/docs/core-tech/addresses-in-beam","core-tech",false,"","Addresses In Beam",{"type":10,"children":11,"toc":1303},"root",[12,23,29,54,59,115,120,127,132,139,143,148,161,166,171,178,197,202,240,246,251,256,268,273,322,328,340,345,350,355,360,365,377,388,417,433,439,456,467,478,483,488,493,506,512,540,545,556,562,567,572,592,608,620,625,650,655,669,674,680,703,708,713,731,747,753,765,814,825,830,835,840,851,854,860,865,870,875,878,884,887,892,910,940,946,951,956,966,985,991,996,1007,1012,1029,1035,1040,1045,1148,1154,1159,1170,1181,1187,1197,1215,1231,1237,1242,1247],{"type":13,"tag":14,"props":15,"children":16},"element","p",{},[17],{"type":13,"tag":18,"props":19,"children":22},"img",{"alt":20,"src":21},"image","https://github.com/user-attachments/assets/110d645f-944f-43ea-a9e5-d51f7159da09",[],{"type":13,"tag":14,"props":24,"children":25},{},[26],{"type":27,"value":28},"text","There're (too) many different kinds of addresses in Beam:",{"type":13,"tag":30,"props":31,"children":32},"ul",{},[33,39,44,49],{"type":13,"tag":34,"props":35,"children":36},"li",{},[37],{"type":27,"value":38},"Regular (a.k.a. new-style)",{"type":13,"tag":34,"props":40,"children":41},{},[42],{"type":27,"value":43},"Legacy (BBS-only, a.k.a. old-style)",{"type":13,"tag":34,"props":45,"children":46},{},[47],{"type":27,"value":48},"Offline",{"type":13,"tag":34,"props":50,"children":51},{},[52],{"type":27,"value":53},"Max-privacy",{"type":13,"tag":14,"props":55,"children":56},{},[57],{"type":27,"value":58},"In addition to those kinds of addresses, there's more terminology:",{"type":13,"tag":30,"props":60,"children":61},{},[62,75,83,107],{"type":13,"tag":34,"props":63,"children":64},{},[65,67,73],{"type":27,"value":66},"Payment ",{"type":13,"tag":68,"props":69,"children":70},"em",{},[71],{"type":27,"value":72},"Tokens",{"type":27,"value":74},", that consist of an address with the requested payment amount",{"type":13,"tag":34,"props":76,"children":77},{},[78],{"type":13,"tag":68,"props":79,"children":80},{},[81],{"type":27,"value":82},"Vouchers",{"type":13,"tag":34,"props":84,"children":85},{},[86,91,93,98,100,105],{"type":13,"tag":68,"props":87,"children":88},{},[89],{"type":27,"value":90},"Endpoints",{"type":27,"value":92}," (alternatively called as ",{"type":13,"tag":68,"props":94,"children":95},{},[96],{"type":27,"value":97},"Signature",{"type":27,"value":99},", or ",{"type":13,"tag":68,"props":101,"children":102},{},[103],{"type":27,"value":104},"Identity",{"type":27,"value":106},")",{"type":13,"tag":34,"props":108,"children":109},{},[110],{"type":13,"tag":68,"props":111,"children":112},{},[113],{"type":27,"value":114},"Payment proof",{"type":13,"tag":14,"props":116,"children":117},{},[118],{"type":27,"value":119},"Some of the above things are permanent, some expire, and some are intended for single usage.\nIn addition to that, when the wallet is restored, the addresses are not preserved (new wallet instance generates new addresses).\nAll this is very confusing. Here we'll explain in details how things work, why historically so many kinds of addresses were implemented, and what is relevant today.",{"type":13,"tag":121,"props":122,"children":124},"h1",{"id":123},"what-are-beam-addresses",[125],{"type":27,"value":126},"What are Beam addresses?",{"type":13,"tag":14,"props":128,"children":129},{},[130],{"type":27,"value":131},"First and foremost:",{"type":13,"tag":133,"props":134,"children":136},"h3",{"id":135},"there-are-no-addresses-on-the-beam-blockchain-per-se",[137],{"type":27,"value":138},"there are no addresses on the Beam blockchain per se.",{"type":13,"tag":140,"props":141,"children":142},"hr",{},[],{"type":13,"tag":14,"props":144,"children":145},{},[146],{"type":27,"value":147},"Beam is based on UTXO model (set of coins, in simple words). There're 2 types of UTXOs:",{"type":13,"tag":30,"props":149,"children":150},{},[151,156],{"type":13,"tag":34,"props":152,"children":153},{},[154],{"type":27,"value":155},"MW (MimbleWimble) UTXOs.",{"type":13,"tag":34,"props":157,"children":158},{},[159],{"type":27,"value":160},"Shielded TXOs. Those are created and spent using in Lelantus-MW txs.",{"type":13,"tag":14,"props":162,"children":163},{},[164],{"type":27,"value":165},"Both kinds of UTXOs are opaque, and look like random data. No addresses that expose who owns them, and the value is concealed.",{"type":13,"tag":14,"props":167,"children":168},{},[169],{"type":27,"value":170},"Each UTXO has its secret key, which is needed to build a valid tx that spends it. Means whoever knows that secret key - actually owns the coin.",{"type":13,"tag":172,"props":173,"children":175},"h2",{"id":174},"how-the-wallet-manages-its-coins",[176],{"type":27,"value":177},"How the wallet manages its coins",{"type":13,"tag":14,"props":179,"children":180},{},[181,183,188,190,195],{"type":27,"value":182},"Each wallet has the ",{"type":13,"tag":68,"props":184,"children":185},{},[186],{"type":27,"value":187},"Master Key",{"type":27,"value":189}," (initialized from the secret seed phrase). It is used to derive all the coin keys. When the coins are generated by the wallet, they're encoded such that they can re recognized by the corresponding ",{"type":13,"tag":68,"props":191,"children":192},{},[193],{"type":27,"value":194},"Owner Key",{"type":27,"value":196}," (also derived from the Master Key).",{"type":13,"tag":14,"props":198,"children":199},{},[200],{"type":27,"value":201},"This means the following:",{"type":13,"tag":30,"props":203,"children":204},{},[205,222,235],{"type":13,"tag":34,"props":206,"children":207},{},[208,210,214,216,220],{"type":27,"value":209},"All the coins belong to the wallet that generated it. They can be recognized by its ",{"type":13,"tag":68,"props":211,"children":212},{},[213],{"type":27,"value":194},{"type":27,"value":215},", and then spent in the future txs using its ",{"type":13,"tag":68,"props":217,"children":218},{},[219],{"type":27,"value":187},{"type":27,"value":221},".",{"type":13,"tag":34,"props":223,"children":224},{},[225,227,233],{"type":27,"value":226},"Coins do ",{"type":13,"tag":228,"props":229,"children":230},"strong",{},[231],{"type":27,"value":232},"NOT",{"type":27,"value":234}," belong to addresses.",{"type":13,"tag":34,"props":236,"children":237},{},[238],{"type":27,"value":239},"Addresses are only used between the wallets to communicate and build txs (more about this later). After the tx is included in a block - addresses don't matter.",{"type":13,"tag":121,"props":241,"children":243},{"id":242},"mw-txs-and-old-style-addresses",[244],{"type":27,"value":245},"MW txs and old-style addresses",{"type":13,"tag":14,"props":247,"children":248},{},[249],{"type":27,"value":250},"Beam is based on MW, where transactions are built interactively. Means users must communicate to build a transaction.",{"type":13,"tag":14,"props":252,"children":253},{},[254],{"type":27,"value":255},"For this we developed an SBBS system, that allows wallets to exchange encrypted messages anonymously. Wallets can generate public/private key pairs, where the public key is used to encrypt messages, and private key can decrypt them.",{"type":13,"tag":14,"props":257,"children":258},{},[259,261,266],{"type":27,"value":260},"That's how ",{"type":13,"tag":228,"props":262,"children":263},{},[264],{"type":27,"value":265},"addresses",{"type":27,"value":267}," were born on Beam. Address in fact meant SBBS address, a public key to encode messages, that can only be decoded by the appropriate private key.",{"type":13,"tag":14,"props":269,"children":270},{},[271],{"type":27,"value":272},"Here're some notes regarding the SBBS encryption:",{"type":13,"tag":30,"props":274,"children":275},{},[276,281,286,299,304,309],{"type":13,"tag":34,"props":277,"children":278},{},[279],{"type":27,"value":280},"All encrypted messages are opaque (look like random data), the sender/receiver of the message is also opaque, and the message is protected against tampering (using HMAC scheme).",{"type":13,"tag":34,"props":282,"children":283},{},[284],{"type":27,"value":285},"Using the SBBS address one can only encrypt messages, not decrypt.",{"type":13,"tag":34,"props":287,"children":288},{},[289,291],{"type":27,"value":290},"There's no feasible way to realize that a specific SBBS message was encoded by a given SBBS address.\n",{"type":13,"tag":30,"props":292,"children":293},{},[294],{"type":13,"tag":34,"props":295,"children":296},{},[297],{"type":27,"value":298},"Means you can share your SBBS address to different users, they won't be able to see when you communicate with others.",{"type":13,"tag":34,"props":300,"children":301},{},[302],{"type":27,"value":303},"Users can generate as many SBBS addresses as they want.",{"type":13,"tag":34,"props":305,"children":306},{},[307],{"type":27,"value":308},"In order to receive the SBBS message, one tries to decrypt all the incoming SBBS traffic. Only the intended messages would be successfully decrypted and pass HMAC verification.",{"type":13,"tag":34,"props":310,"children":311},{},[312,314],{"type":27,"value":313},"If you listen to several active SBBS addresses - the wallet will try to decrypt each message by each address private key.\n",{"type":13,"tag":30,"props":315,"children":316},{},[317],{"type":13,"tag":34,"props":318,"children":319},{},[320],{"type":27,"value":321},"The more active SBBS addresses - the harder the wallet works to receive the messages.",{"type":13,"tag":172,"props":323,"children":325},{"id":324},"address-generation-and-expiration",[326],{"type":27,"value":327},"Address generation and expiration",{"type":13,"tag":14,"props":329,"children":330},{},[331,333,338],{"type":27,"value":332},"As we said, a wallet may generate multiple SBBS addreses. It may also ",{"type":13,"tag":68,"props":334,"children":335},{},[336],{"type":27,"value":337},"deactivate",{"type":27,"value":339}," a specific address, which means it'd stop trying to decrypt incoming SBBS messages by its private key.",{"type":13,"tag":14,"props":341,"children":342},{},[343],{"type":27,"value":344},"Theoretically there was no good reason to have more than 1 SBBS address. User could just live fine with only a single SBBS address, and share it freely. As we've said, all the messages are completely opaque, and the communication is anonymous.",{"type":13,"tag":14,"props":346,"children":347},{},[348],{"type":27,"value":349},"There's only limited scenarios where a user may need more than 1 address. If the user wishes to provide several addresses that look like of different users (for example, have several accounts at an exchange, with different SBBS addresses for funds withdrawal).",{"type":13,"tag":14,"props":351,"children":352},{},[353],{"type":27,"value":354},"However, due to user habits and some misconceptions, users insisted on changing addresses regularly. That's why we implemented automatic SBBS address generation and expiration",{"type":13,"tag":121,"props":356,"children":358},{"id":357},"payment-proof",[359],{"type":27,"value":114},{"type":13,"tag":14,"props":361,"children":362},{},[363],{"type":27,"value":364},"Unlike other blockchain designs, in Beam there're no addresses on the blockchain per se.\nAs a result, if Alice sends funds to Bob, there's no way to prove it later from the blockchain data (Bob has plausible deniability).",{"type":13,"tag":14,"props":366,"children":367},{},[368,370,375],{"type":27,"value":369},"To address this, we implemented a ",{"type":13,"tag":68,"props":371,"children":372},{},[373],{"type":27,"value":374},"Payment Proof",{"type":27,"value":376},". It's a signature, signed by the recipient of the funds, that it indeed accepts the specific amount from the specific sender. It is signed by the receiver and verified by the sender during the transaction negotiation stage (all this happens off-chain).",{"type":13,"tag":14,"props":378,"children":379},{},[380,382,386],{"type":27,"value":381},"The ",{"type":13,"tag":68,"props":383,"children":384},{},[385],{"type":27,"value":374},{"type":27,"value":387}," signature signed the following:",{"type":13,"tag":30,"props":389,"children":390},{},[391,396,401,406],{"type":13,"tag":34,"props":392,"children":393},{},[394],{"type":27,"value":395},"Identity (pubkey) of the sender",{"type":13,"tag":34,"props":397,"children":398},{},[399],{"type":27,"value":400},"Identity (pubkey) of the receiver (the signature is signed by the corresponding private key).",{"type":13,"tag":34,"props":402,"children":403},{},[404],{"type":27,"value":405},"Amount and asset type being-received",{"type":13,"tag":34,"props":407,"children":408},{},[409,411,415],{"type":27,"value":410},"Transaction Kernel ID. If the tx was negotiated but not broadcasted and accepted in a block - the ",{"type":13,"tag":68,"props":412,"children":413},{},[414],{"type":27,"value":374},{"type":27,"value":416}," is considered invalid (i.e. there was an intention of the tx, but it didn't take place actually).",{"type":13,"tag":14,"props":418,"children":419},{},[420,425,427,432],{"type":13,"tag":68,"props":421,"children":422},{},[423],{"type":27,"value":424},"Identities",{"type":27,"value":426}," of both sender/receiver were in fact their SBBS addresses. That is, ",{"type":13,"tag":228,"props":428,"children":429},{},[430],{"type":27,"value":431},"the same key was used both for SBBS messages encryption, and to identify the owner of the funds",{"type":27,"value":221},{"type":13,"tag":121,"props":434,"children":436},{"id":435},"hardware-wallet-and-new-style-addresses-aka-regular-addresses",[437],{"type":27,"value":438},"Hardware Wallet, and new-style addresses (a.k.a. Regular addresses)",{"type":13,"tag":14,"props":440,"children":441},{},[442,444,448,450,454],{"type":27,"value":443},"With the hardware wallet the things work differently. The ",{"type":13,"tag":68,"props":445,"children":446},{},[447],{"type":27,"value":187},{"type":27,"value":449}," and all the coin keys are managed entirely in the HW wallet. The software wallet gets the ",{"type":13,"tag":68,"props":451,"children":452},{},[453],{"type":27,"value":194},{"type":27,"value":455}," that can recognize coins (but not spend them), and handles all the communication and blockchain state change logic.",{"type":13,"tag":14,"props":457,"children":458},{},[459,461,465],{"type":27,"value":460},"The SBBS address must be managed by the software wallet, it's too complex for the HW wallet to decrypt all the SBBS traffic. On the other hand, when the ",{"type":13,"tag":68,"props":462,"children":463},{},[464],{"type":27,"value":374},{"type":27,"value":466}," is signed/verified - it must be done with the key that is managed by the HW wallet.",{"type":13,"tag":14,"props":468,"children":469},{},[470,472,476],{"type":27,"value":471},"This is where we decided to split the SBBS address and the user identity. The SBBS address is the address you're communicating with, and the ",{"type":13,"tag":68,"props":473,"children":474},{},[475],{"type":27,"value":104},{"type":27,"value":477}," is the public key of the final receiver/sender of the funds. For standard wallets both are managed by the wallet, but with the HW wallet they're managed in different places.",{"type":13,"tag":14,"props":479,"children":480},{},[481],{"type":27,"value":482},"To support this, we defined a new-style address (now called a Regular address).",{"type":13,"tag":14,"props":484,"children":485},{},[486],{"type":27,"value":487},"First, the address format was changed. The older SBBS address was just a hex-encoded pubkey. We decided to change it into an encoded collection of arbitrary number of parameters (to support possible future parameters for various address/token types).",{"type":13,"tag":14,"props":489,"children":490},{},[491],{"type":27,"value":492},"The Regular address consists of the following fields:",{"type":13,"tag":30,"props":494,"children":495},{},[496,501],{"type":13,"tag":34,"props":497,"children":498},{},[499],{"type":27,"value":500},"SBBS address",{"type":13,"tag":34,"props":502,"children":503},{},[504],{"type":27,"value":505},"User Identity",{"type":13,"tag":172,"props":507,"children":509},{"id":508},"endpoint",[510],{"type":27,"value":511},"Endpoint",{"type":13,"tag":14,"props":513,"children":514},{},[515,517,521,523,528,529,533,535,539],{"type":27,"value":516},"Historically we had several names for the above user identity: ",{"type":13,"tag":68,"props":518,"children":519},{},[520],{"type":27,"value":104},{"type":27,"value":522},", ",{"type":13,"tag":68,"props":524,"children":525},{},[526],{"type":27,"value":527},"HW Identity",{"type":27,"value":522},{"type":13,"tag":68,"props":530,"children":531},{},[532],{"type":27,"value":97},{"type":27,"value":534},", and etc. All that lead to confuses, so we decided to give a distinctive name to this: the ",{"type":13,"tag":68,"props":536,"children":537},{},[538],{"type":27,"value":511},{"type":27,"value":221},{"type":13,"tag":14,"props":541,"children":542},{},[543],{"type":27,"value":544},"The rationale behind this name is the following. Suppose Alice sends funds to Bob, both use HW wallet. Conceptually you may treat this situation as this: Alice's HW wallet is the ultimate sender of the funds, Bob's HW wallet is the ultimate receiver. And they negotiate the transaction with each other.\nThe software wallets of Alice and Bob are just intermediate entities, they're not part of the transaction negotiation.",{"type":13,"tag":14,"props":546,"children":547},{},[548,550,554],{"type":27,"value":549},"In other words, the ",{"type":13,"tag":68,"props":551,"children":552},{},[553],{"type":27,"value":511},{"type":27,"value":555}," is the final source/destination of the funds.",{"type":13,"tag":121,"props":557,"children":559},{"id":558},"lelantus-mw",[560],{"type":27,"value":561},"Lelantus-MW",{"type":13,"tag":14,"props":563,"children":564},{},[565],{"type":27,"value":566},"To address the inherent MW linkability problem, we extended Beam with the Lelantus-MW protocol. It's our proprietary modification of the Lelantus protocol, adjusted to fit and complement the MW.",{"type":13,"tag":14,"props":568,"children":569},{},[570],{"type":27,"value":571},"With it we added 2 new transaction elements:",{"type":13,"tag":30,"props":573,"children":574},{},[575,580],{"type":13,"tag":34,"props":576,"children":577},{},[578],{"type":27,"value":579},"Shielded Output - add an opaque coin into the shielded pool",{"type":13,"tag":34,"props":581,"children":582},{},[583,585,590],{"type":27,"value":584},"Shielded Input - spend ",{"type":13,"tag":68,"props":586,"children":587},{},[588],{"type":27,"value":589},"some",{"type":27,"value":591}," coin from the shielded pool.",{"type":13,"tag":14,"props":593,"children":594},{},[595,597,601,603,607],{"type":27,"value":596},"In MW transactions are interactive, when Bob receives funds from Alice, he creates his UTXO to accept the funds in advance (during negotiation stage) . And since Bob himself created his UTXO, he can recognize it using his ",{"type":13,"tag":68,"props":598,"children":599},{},[600],{"type":27,"value":194},{"type":27,"value":602},", and spend using his ",{"type":13,"tag":68,"props":604,"children":605},{},[606],{"type":27,"value":187},{"type":27,"value":221},{"type":13,"tag":14,"props":609,"children":610},{},[611,613,618],{"type":27,"value":612},"In contrast to MW txs, Lelantus-MW txs are non-interactive. Means Alice creates the ",{"type":13,"tag":68,"props":614,"children":615},{},[616],{"type":27,"value":617},"Shielded Output",{"type":27,"value":619}," tx element, without Bob being-involved. Yet she creates it in such a way that Bob will be able to recognize and spend it later.",{"type":13,"tag":14,"props":621,"children":622},{},[623],{"type":27,"value":624},"This means that Bob should give Alice an additional data, to allow her to send funds to Bob using Lelantus-MW.",{"type":13,"tag":14,"props":626,"children":627},{},[628,630,634,636,641,643,648],{"type":27,"value":629},"Technically each ",{"type":13,"tag":68,"props":631,"children":632},{},[633],{"type":27,"value":617},{"type":27,"value":635}," comes with a ",{"type":13,"tag":68,"props":637,"children":638},{},[639],{"type":27,"value":640},"Ticket",{"type":27,"value":642},". It's an opaque data object, but encoded such that it can be recognized by the funds recipient (Bob). Moreover, ",{"type":13,"tag":68,"props":644,"children":645},{},[646],{"type":27,"value":647},"Tickets",{"type":27,"value":649}," must be unique, it's impossible to use the same ticket twice (this is related to double-spend prevention).",{"type":13,"tag":14,"props":651,"children":652},{},[653],{"type":27,"value":654},"So, basically there're 2 options here:",{"type":13,"tag":656,"props":657,"children":658},"ol",{},[659,664],{"type":13,"tag":34,"props":660,"children":661},{},[662],{"type":27,"value":663},"Bob gives Alice a source data, using which Alice may generate arbitrary number of Bob's tickets.",{"type":13,"tag":34,"props":665,"children":666},{},[667],{"type":27,"value":668},"Bob generates arbitrary number of tickets, and gives them to Alice.",{"type":13,"tag":14,"props":670,"children":671},{},[672],{"type":27,"value":673},"Both methods have their pros and cons. And both are supported in terms of different address types.",{"type":13,"tag":172,"props":675,"children":677},{"id":676},"offline-address",[678],{"type":27,"value":679},"Offline address",{"type":13,"tag":14,"props":681,"children":682},{},[683,685,689,691,695,697,701],{"type":27,"value":684},"This corresponds to the 1st method. The ",{"type":13,"tag":68,"props":686,"children":687},{},[688],{"type":27,"value":679},{"type":27,"value":690}," in essence is a ticket generator. It also comes with the Bob's ",{"type":13,"tag":68,"props":692,"children":693},{},[694],{"type":27,"value":511},{"type":27,"value":696},", and is also signed by ",{"type":13,"tag":68,"props":698,"children":699},{},[700],{"type":27,"value":511},{"type":27,"value":702},"'s signature (if Alice needs to prove that she sent funds to Bob - she can show that the corresponding ticket was generated by the generator signed by Bob).",{"type":13,"tag":14,"props":704,"children":705},{},[706],{"type":27,"value":707},"Once Alice has it, she can send arbitrary number of Lelantus-MW txs to Bob, which is a good thing.",{"type":13,"tag":14,"props":709,"children":710},{},[711],{"type":27,"value":712},"There's however a drawback. Alice knows the internal parameters of the ticket (since she actually generated it). One of them later will be used by Bob, when he'll spend this shielded coin.",{"type":13,"tag":14,"props":714,"children":715},{},[716,718,723,725,729],{"type":27,"value":717},"Means that the ",{"type":13,"tag":228,"props":719,"children":720},{},[721],{"type":27,"value":722},"sender will notice when the receiver will spend the shielded coin",{"type":27,"value":724},". For the 3rd-party observers the shielded transactions are anonymous, but this specific kind is not anonymous w.r.t. the sender. Hence we call it ",{"type":13,"tag":68,"props":726,"children":727},{},[728],{"type":27,"value":48},{"type":27,"value":730},", but not truly private.",{"type":13,"tag":14,"props":732,"children":733},{},[734,739,741,745],{"type":13,"tag":228,"props":735,"children":736},{},[737],{"type":27,"value":738},"Note:",{"type":27,"value":740}," despite the above drawback, the above is perfectly fine if you receive shielded funds from a trusted sender. For instance, you may have several wallets (with different seed phrases). You may use ",{"type":13,"tag":68,"props":742,"children":743},{},[744],{"type":27,"value":48},{"type":27,"value":746}," address to transfer funds in a private way. As we've said, 3rd-party observers will see no link between the Shielded Output and the corresponding Shielded Input.",{"type":13,"tag":172,"props":748,"children":750},{"id":749},"max-privacy-address",[751],{"type":27,"value":752},"Max Privacy address",{"type":13,"tag":14,"props":754,"children":755},{},[756,758,763],{"type":27,"value":757},"This corresponds to the 2nd option. The ",{"type":13,"tag":68,"props":759,"children":760},{},[761],{"type":27,"value":762},"Max Privacy",{"type":27,"value":764}," address consists of the following:",{"type":13,"tag":30,"props":766,"children":767},{},[768,777,809],{"type":13,"tag":34,"props":769,"children":770},{},[771,773],{"type":27,"value":772},"Receiver ",{"type":13,"tag":68,"props":774,"children":775},{},[776],{"type":27,"value":511},{"type":13,"tag":34,"props":778,"children":779},{},[780,782,786,788],{"type":27,"value":781},"Arbitrary number of ",{"type":13,"tag":68,"props":783,"children":784},{},[785],{"type":27,"value":82},{"type":27,"value":787},".\n",{"type":13,"tag":30,"props":789,"children":790},{},[791],{"type":13,"tag":34,"props":792,"children":793},{},[794,796,801,803,807],{"type":27,"value":795},"Each ",{"type":13,"tag":68,"props":797,"children":798},{},[799],{"type":27,"value":800},"Voucher",{"type":27,"value":802}," is actually a ticket, signed by Bob ",{"type":13,"tag":68,"props":804,"children":805},{},[806],{"type":27,"value":511},{"type":27,"value":808}," signature (to prove later that Bob is the receiver of the funds).",{"type":13,"tag":34,"props":810,"children":811},{},[812],{"type":27,"value":813},"Optional SBBS address to ask for more vouchers.",{"type":13,"tag":14,"props":815,"children":816},{},[817,819,823],{"type":27,"value":818},"This method doesn't have the drawback of the ",{"type":13,"tag":68,"props":820,"children":821},{},[822],{"type":27,"value":48},{"type":27,"value":824}," address. Alice may send funds to Bob, Bob later may spend those funds anonymously w.r.t. Alice.",{"type":13,"tag":14,"props":826,"children":827},{},[828],{"type":27,"value":829},"The obvious drawback is that there's a limited number of Vouchers/Tickets. Once they're all consumed - there's no way to send more txs.\nThis is where the SBBS address can be used. Once Alice runs out of Bob's vouchers (or getting low on them) - her wallet may request for more Bob's vouchers via SBBS. If/when Bob will be online - his wallet will respond, and provide Alice with more vouchers automatically.",{"type":13,"tag":121,"props":831,"children":833},{"id":832},"tokens",[834],{"type":27,"value":72},{"type":13,"tag":14,"props":836,"children":837},{},[838],{"type":27,"value":839},"As we've said, all the address types, except the \"old-style\", are represented as a collection of parameters. In addition to the address itself (whatever kind it is), it's possible to include more fields.",{"type":13,"tag":14,"props":841,"children":842},{},[843,845,849],{"type":27,"value":844},"Using this we've introduced a so-called payment ",{"type":13,"tag":68,"props":846,"children":847},{},[848],{"type":27,"value":72},{"type":27,"value":850},", which are a way to request a specific payment. They consist of the address (any kind), and the requested Amount and asset type.",{"type":13,"tag":140,"props":852,"children":853},{},[],{"type":13,"tag":121,"props":855,"children":857},{"id":856},"ideas-for-improvements",[858],{"type":27,"value":859},"Ideas for improvements",{"type":13,"tag":14,"props":861,"children":862},{},[863],{"type":27,"value":864},"So we've described what Beam addresses are, why it's not a big deal to loose them (i.e. coins don't belong to addresses, you don't loose coins).\nWe also explained why there're different kinds of addresses, and why they are necessary. The old-style address is actually obsolete, and even incompatible with the HW wallet (i.e. you can't even generate it with the HW wallet). But, unfortunately, we can't get rid of it completely, because some existing exchanges won't accept different addresses (they do a sort of a regular-expression check on the address). So they're still here.",{"type":13,"tag":14,"props":866,"children":867},{},[868],{"type":27,"value":869},"However, many things can and should be improved, mostly regarding user experience and the UX.",{"type":13,"tag":14,"props":871,"children":872},{},[873],{"type":27,"value":874},"The most important change can be expressed as this:",{"type":13,"tag":140,"props":876,"children":877},{},[],{"type":13,"tag":133,"props":879,"children":881},{"id":880},"its-all-about-endpoints",[882],{"type":27,"value":883},"It's all about Endpoints",{"type":13,"tag":140,"props":885,"children":886},{},[],{"type":13,"tag":14,"props":888,"children":889},{},[890],{"type":27,"value":891},"In simple words, each address consists of two things:",{"type":13,"tag":30,"props":893,"children":894},{},[895,905],{"type":13,"tag":34,"props":896,"children":897},{},[898,900,904],{"type":27,"value":899},"Who does it belong to, i.e. who is the supposed receiver of the funds. This is the ",{"type":13,"tag":68,"props":901,"children":902},{},[903],{"type":27,"value":511},{"type":27,"value":221},{"type":13,"tag":34,"props":906,"children":907},{},[908],{"type":27,"value":909},"What kind of tx would that be, and how to negotiate and build it.",{"type":13,"tag":14,"props":911,"children":912},{},[913,917,919,924,926,931,933,938],{"type":13,"tag":68,"props":914,"children":915},{},[916],{"type":27,"value":511},{"type":27,"value":918},", i.e. the identity of the sender/receiver - is the most important thing. It should be visible wherever applicable, and play a crucial role in the address book.\n",{"type":13,"tag":68,"props":920,"children":921},{},[922],{"type":27,"value":923},"Who",{"type":27,"value":925}," am I paying, and ",{"type":13,"tag":68,"props":927,"children":928},{},[929],{"type":27,"value":930},"who",{"type":27,"value":932}," payed me. This is arguably more important than ",{"type":13,"tag":68,"props":934,"children":935},{},[936],{"type":27,"value":937},"how",{"type":27,"value":939}," is the payment done.",{"type":13,"tag":172,"props":941,"children":943},{"id":942},"address-format",[944],{"type":27,"value":945},"Address format",{"type":13,"tag":14,"props":947,"children":948},{},[949],{"type":27,"value":950},"Currently all address types (except legacy) are displayed as a Base58-encoded strings of a \u003Ckey, value> pairs, where key is an 1-byte identifier of the parameter.\nAs a result, the user has no way to see either the embedded arguments, or even the address type. A better option would be encoding the arguments in a human-readable way.",{"type":13,"tag":14,"props":952,"children":953},{},[954],{"type":27,"value":955},"For example, a Regular (online) address could be displayed as:",{"type":13,"tag":14,"props":957,"children":958},{},[959],{"type":13,"tag":960,"props":961,"children":963},"code",{"className":962},[],[964],{"type":27,"value":965},"beam_Bk1azc8VtaYU1f6t7jiRGkxJDiAVui6Y5WvohjoU1yFA_bbs274b78587e1c9643e7472e221be1634b8efe06f747175d3d8c98ce1ef665b056d4a",{"type":13,"tag":14,"props":967,"children":968},{},[969,971,977,979,983],{"type":27,"value":970},"It begins with ",{"type":13,"tag":960,"props":972,"children":974},{"className":973},[],[975],{"type":27,"value":976},"beam",{"type":27,"value":978}," (a common practice in some networks), then followed by a human-readable ",{"type":13,"tag":68,"props":980,"children":981},{},[982],{"type":27,"value":511},{"type":27,"value":984},", and then followed by the bbs address.",{"type":13,"tag":133,"props":986,"children":988},{"id":987},"what-if-users-tampermodify-address-manually",[989],{"type":27,"value":990},"What if users tamper/modify address manually?",{"type":13,"tag":14,"props":992,"children":993},{},[994],{"type":27,"value":995},"The good news is that Beam addresses are generally resistant to tampering. If one modifies the address (either intentionally or not) - there is no risk of loss of funds.",{"type":13,"tag":14,"props":997,"children":998},{},[999,1001,1005],{"type":27,"value":1000},"If one modifies the SBBS address, the communication with the receiver will fail. And if the ",{"type":13,"tag":68,"props":1002,"children":1003},{},[1004],{"type":27,"value":511},{"type":27,"value":1006}," is modified, the negotiation with the receiver will fail.",{"type":13,"tag":14,"props":1008,"children":1009},{},[1010],{"type":27,"value":1011},"Same applies to Max Privacy and Offline addresses. They contain pre-signed receiver signatures (that would be a part of the future payment proof). If one modifies some address fields - the address would become invalid.",{"type":13,"tag":14,"props":1013,"children":1014},{},[1015,1017,1021,1023,1027],{"type":27,"value":1016},"And, again, this all boils down to the ",{"type":13,"tag":68,"props":1018,"children":1019},{},[1020],{"type":27,"value":511},{"type":27,"value":1022}," of the address, i.e. ",{"type":13,"tag":228,"props":1024,"children":1025},{},[1026],{"type":27,"value":930},{"type":27,"value":1028}," is the supposed recipient of the funds. If the sender verifies it and is confident that it's the intended one - there's no risk of funds loss, or the payment going into wrong hands.",{"type":13,"tag":172,"props":1030,"children":1032},{"id":1031},"address-book-refactor",[1033],{"type":27,"value":1034},"Address book refactor",{"type":13,"tag":14,"props":1036,"children":1037},{},[1038],{"type":27,"value":1039},"Address book consists of several tabs. (My active addresses, My expired addresses, Contacts).\nFor the \"Contacts\" tab there is a list of all known addresses of other users.",{"type":13,"tag":14,"props":1041,"children":1042},{},[1043],{"type":27,"value":1044},"A more sane address book should look like this",{"type":13,"tag":30,"props":1046,"children":1047},{},[1048,1059,1096],{"type":13,"tag":34,"props":1049,"children":1050},{},[1051,1053,1057],{"type":27,"value":1052},"There should be a list of known ",{"type":13,"tag":68,"props":1054,"children":1055},{},[1056],{"type":27,"value":90},{"type":27,"value":1058},", not addresses/tokens. Those are actually different contacts. Each can be annotated by a name.",{"type":13,"tag":34,"props":1060,"children":1061},{},[1062,1064,1068,1070],{"type":27,"value":1063},"For each ",{"type":13,"tag":68,"props":1065,"children":1066},{},[1067],{"type":27,"value":511},{"type":27,"value":1069}," we can show the following information:",{"type":13,"tag":30,"props":1071,"children":1072},{},[1073,1078,1083],{"type":13,"tag":34,"props":1074,"children":1075},{},[1076],{"type":27,"value":1077},"Its SBBS address (if known)",{"type":13,"tag":34,"props":1079,"children":1080},{},[1081],{"type":27,"value":1082},"Do we have its Offline address (yes/no)?",{"type":13,"tag":34,"props":1084,"children":1085},{},[1086,1088],{"type":27,"value":1087},"How many vouchers are left for Max Privacy txs?\n",{"type":13,"tag":30,"props":1089,"children":1090},{},[1091],{"type":13,"tag":34,"props":1092,"children":1093},{},[1094],{"type":27,"value":1095},"Optionally - a button to request more vouchers manually",{"type":13,"tag":34,"props":1097,"children":1098},{},[1099,1101,1105,1107],{"type":27,"value":1100},"For owned (my) ",{"type":13,"tag":68,"props":1102,"children":1103},{},[1104],{"type":27,"value":90},{"type":27,"value":1106}," the following information should be presented",{"type":13,"tag":30,"props":1108,"children":1109},{},[1110,1121,1137],{"type":13,"tag":34,"props":1111,"children":1112},{},[1113,1115,1119],{"type":27,"value":1114},"Internal number. That is, all the keys are generated using ",{"type":13,"tag":68,"props":1116,"children":1117},{},[1118],{"type":27,"value":187},{"type":27,"value":1120},", from the provided key number. Normally they're picked at random, and not shown to the user. But we can show them. By such users will be able to re-generate the same addresses after the wallet is restored.",{"type":13,"tag":34,"props":1122,"children":1123},{},[1124,1126,1136],{"type":27,"value":1125},"Option to generate an address/token of any kind ",{"type":13,"tag":1127,"props":1128,"children":1129},"u",{},[1130,1132],{"type":27,"value":1131},"for this specific ",{"type":13,"tag":68,"props":1133,"children":1134},{},[1135],{"type":27,"value":511},{"type":27,"value":221},{"type":13,"tag":34,"props":1138,"children":1139},{},[1140,1142,1146],{"type":27,"value":1141},"HW wallets: option to verify the ",{"type":13,"tag":68,"props":1143,"children":1144},{},[1145],{"type":27,"value":511},{"type":27,"value":1147}," on the HW wallet",{"type":13,"tag":172,"props":1149,"children":1151},{"id":1150},"send-screen-to",[1152],{"type":27,"value":1153},"Send screen - To",{"type":13,"tag":14,"props":1155,"children":1156},{},[1157],{"type":27,"value":1158},"Currently in the \"To\" field the user puts an address. The wallet parses the address, recognizes its type, and acts accordingly. For some addresses the wallet gives an option to modify the transaction type (Online, Offline, Max Privacy) if that token has enough information.",{"type":13,"tag":14,"props":1160,"children":1161},{},[1162,1164,1168],{"type":27,"value":1163},"Instead the wallet should recognize the ",{"type":13,"tag":68,"props":1165,"children":1166},{},[1167],{"type":27,"value":511},{"type":27,"value":1169}," from the given address, check if it's already in the address book, and realize all the possible ways of sending from what it already knows about it. Not only from the parameters of the provided address.",{"type":13,"tag":14,"props":1171,"children":1172},{},[1173,1175,1179],{"type":27,"value":1174},"Moreover, it should be possible to specify \"To\" the ",{"type":13,"tag":68,"props":1176,"children":1177},{},[1178],{"type":27,"value":511},{"type":27,"value":1180}," only. Or just the name that the user annotated to it in the address book.\nThe wallet should automatically find it in the address book, and allow tx types according to what is known about it.",{"type":13,"tag":172,"props":1182,"children":1184},{"id":1183},"send-screen-from",[1185],{"type":27,"value":1186},"Send screen - From",{"type":13,"tag":14,"props":1188,"children":1189},{},[1190,1192,1196],{"type":27,"value":1191},"Currently this doesn't exist at all. When funds are sent - the sending wallet always identifies itself as a random user with an ephemeral ",{"type":13,"tag":68,"props":1193,"children":1194},{},[1195],{"type":27,"value":511},{"type":27,"value":221},{"type":13,"tag":14,"props":1198,"children":1199},{},[1200,1202,1207,1209,1213],{"type":27,"value":1201},"There should be an option to specify an ",{"type":13,"tag":228,"props":1203,"children":1204},{},[1205],{"type":27,"value":1206},"existing",{"type":27,"value":1208}," ",{"type":13,"tag":68,"props":1210,"children":1211},{},[1212],{"type":27,"value":511},{"type":27,"value":1214},". By such the sender may make the receiver know who sent the funds.",{"type":13,"tag":14,"props":1216,"children":1217},{},[1218,1220,1224,1226,1230],{"type":27,"value":1219},"In the \"From\" field there should be a choice of the currently existing ",{"type":13,"tag":68,"props":1221,"children":1222},{},[1223],{"type":27,"value":90},{"type":27,"value":1225}," (i.e. active addresses), as well as previously used (perhaps no more active), or an \"Anonymous\", which means what it is today - a random ",{"type":13,"tag":68,"props":1227,"children":1228},{},[1229],{"type":27,"value":511},{"type":27,"value":221},{"type":13,"tag":172,"props":1232,"children":1234},{"id":1233},"transaction-details",[1235],{"type":27,"value":1236},"Transaction details",{"type":13,"tag":14,"props":1238,"children":1239},{},[1240],{"type":27,"value":1241},"The transaction details are loaded with lots of technical parameters (SBBS address of sender/receiver, signatures, etc.). They are mostly meaningless to the user.",{"type":13,"tag":14,"props":1243,"children":1244},{},[1245],{"type":27,"value":1246},"There should be the following parameters:",{"type":13,"tag":30,"props":1248,"children":1249},{},[1250,1281],{"type":13,"tag":34,"props":1251,"children":1252},{},[1253,1255],{"type":27,"value":1254},"For funds transfer transactions:\n",{"type":13,"tag":30,"props":1256,"children":1257},{},[1258,1267,1272,1277],{"type":13,"tag":34,"props":1259,"children":1260},{},[1261,1265],{"type":13,"tag":68,"props":1262,"children":1263},{},[1264],{"type":27,"value":511},{"type":27,"value":1266}," of the sender/receiver. If they exist in the address book - this should be mentioned.",{"type":13,"tag":34,"props":1268,"children":1269},{},[1270],{"type":27,"value":1271},"Type of tx (Online, Offline, Max Privacy)",{"type":13,"tag":34,"props":1273,"children":1274},{},[1275],{"type":27,"value":1276},"Amount transferred and asset type",{"type":13,"tag":34,"props":1278,"children":1279},{},[1280],{"type":27,"value":114},{"type":13,"tag":34,"props":1282,"children":1283},{},[1284,1286],{"type":27,"value":1285},"For other txs (coinswap, contract calls)\n",{"type":13,"tag":30,"props":1287,"children":1288},{},[1289,1298],{"type":13,"tag":34,"props":1290,"children":1291},{},[1292,1296],{"type":13,"tag":68,"props":1293,"children":1294},{},[1295],{"type":27,"value":90},{"type":27,"value":1297}," and Payment proof are irrelevant. Don't show them.",{"type":13,"tag":34,"props":1299,"children":1300},{},[1301],{"type":27,"value":1302},"List of sent/received asset types and amounts",{"title":7,"searchDepth":1304,"depth":1304,"links":1305},2,[1306,1308,1309,1310,1311,1312,1315,1318,1319,1320,1321],{"id":135,"depth":1307,"text":138},3,{"id":174,"depth":1304,"text":177},{"id":324,"depth":1304,"text":327},{"id":508,"depth":1304,"text":511},{"id":676,"depth":1304,"text":679},{"id":749,"depth":1304,"text":752,"children":1313},[1314],{"id":880,"depth":1307,"text":883},{"id":942,"depth":1304,"text":945,"children":1316},[1317],{"id":987,"depth":1307,"text":990},{"id":1031,"depth":1304,"text":1034},{"id":1150,"depth":1304,"text":1153},{"id":1183,"depth":1304,"text":1186},{"id":1233,"depth":1304,"text":1236},"markdown","docs:docs:core-tech:Addresses-in-Beam.md","docs","docs/core-tech/Addresses-in-Beam.md","md",1777630735841]