[{"data":1,"prerenderedAt":90},["ShallowReactive",2],{"docs-\u002Fdocs\u002Fcore-tech\u002Fone-side-payments-(take-2)-deprecated":3,"docs-surround-\u002Fdocs\u002Fcore-tech\u002Fone-side-payments-(take-2)-deprecated":79},{"id":4,"title":5,"body":6,"description":19,"extension":71,"image":72,"meta":73,"navTitle":72,"navigation":74,"path":75,"seo":76,"stem":77,"__hash__":78},"docs\u002Fdocs\u002Fcore-tech\u002FOne-side-payments-(take-2)---DEPRECATED.md","-- DEPRECATED --",{"type":7,"value":8,"toc":67},"minimark",[9,13,16,20,32,39,43,57,60,64],[10,11,5],"h1",{"id":12},"deprecated",[14,15],"hr",{},[17,18,19],"p",{},"In MW transactions are built interactively, means sender and receiver must collaborate to build a transaction. Here we'll describe a scheme where the sender can pay the receiver without the latter being involved during the payment.",[17,21,22,23,27,28,31],{},"Previously we described such a scheme that allowed one-side payments, which demanded our extension to MW which we called ",[24,25,26],"em",{},"kernel fusion",". The idea was that the receiver prepares in advance its UTXO + kernel that compensates for its blinding factor. Then in order to pay the sender creates a transaction with this UTXO appended, and another kernel ",[24,29,30],{},"fused"," with that given by the receiver. The drawback of this scheme is that it was possible to transfer fixed values only (that corresponded to the prepared UTXOs).",[17,33,34,35,38],{},"Here we describe a scheme without this drawback, i.e. where the sender can transfer any amount to the receiver.\nThe idea is to ",[24,36,37],{},"fuse"," UTXOs rather than kernel. The receiver should prepare the UTXO only partially, then the sender would finalize it to accomplish the payment.",[10,40,42],{"id":41},"detailed-description","Detailed description",[17,44,45,46,49,50,52,53,56],{},"The UTXO is redefined, and may optionally contain an ",[24,47,48],{},"extra excess",", which is an arbitrary EC point with the Schnorr's signature that proves there's no value hidden (similar to kernel). So that when the UTXO signature (bulletproof) is created - it signs the visible UTXO Commitment minus the ",[24,51,48],{},", however this ",[24,54,55],{},"excess"," is accounted for in the signature, so that it's not possible to remove it (this is the fusion).",[17,58,59],{},"The receiver picks an arbitrary excess, signs both this excess and the kernel that would compensate for it. In addition it picks the KDF (key deviation function) parameters.",[10,61,63],{"id":62},"comparison-of-both-schemes","Comparison of both schemes",[17,65,66],{},"Kernel fusion\n*",{"title":68,"searchDepth":69,"depth":69,"links":70},"",2,[],"md",null,{},true,"\u002Fdocs\u002Fcore-tech\u002Fone-side-payments-(take-2)-deprecated",{"title":5,"description":19},"docs\u002Fcore-tech\u002FOne-side-payments-(take-2)---DEPRECATED","_A6Iox9cT5zMO5OVvpilNIFFHalUX3o6VYwhgAscVqw",[80,85],{"title":81,"path":82,"stem":83,"description":84,"children":-1},"One Side Payments","\u002Fdocs\u002Fcore-tech\u002Fone-side-payments","docs\u002Fcore-tech\u002FOne-side-payments","In MW in order to create a valid transaction all the parties must collaborate. Here we'll present a one-side payment scheme, which, after initial setup, allows arbitrary senders to pay specified (fixed) values to a particular receiver, without any further collaboration from the receiver side.",{"title":86,"path":87,"stem":88,"description":89,"children":-1},"Out of sync wallets","\u002Fdocs\u002Fcore-tech\u002Fout-of-sync-wallets","docs\u002Fcore-tech\u002FOut-of-sync-wallets","This document describes scenarios of transferring beams between wallets which are not in sync with node or syncing is in progress.",1783006077376]