[{"data":1,"prerenderedAt":448},["ShallowReactive",2],{"docs-\u002Fdocs\u002Fcore-tech\u002Fbeam-signature-schemes":3,"docs-surround-\u002Fdocs\u002Fcore-tech\u002Fbeam-signature-schemes":437},{"id":4,"title":5,"body":6,"description":28,"extension":429,"image":430,"meta":431,"navTitle":430,"navigation":432,"path":433,"seo":434,"stem":435,"__hash__":436},"docs\u002Fdocs\u002Fcore-tech\u002FBeam-signature-schemes.md","Beam Signature Schemes",{"type":7,"value":8,"toc":414},"minimark",[9,14,18,29,33,44,47,67,70,75,83,86,95,98,115,120,123,127,138,152,158,180,184,187,190,193,197,200,202,234,237,271,275,319,323,341,357,363,366],[10,11,13],"h2",{"id":12},"oracles","Oracles",[15,16,17],"p",{},"Oracles are objects used to generate challenges needed to construct\u002Fverify non-interactive proofs. They interpret exposed transcript data in a standard way, and produce the challenges in a deterministic way.",[19,20,25],"pre",{"className":21,"code":23,"language":24},[22],"language-text","oracle \u003C-- exposed_data_1\noracle --> challenge_1\noracle --> challenge_2\noracle \u003C-- exposed_data_2\noracle --> challenge_3\noracle --> challenge_4\n\u002F\u002F ...\n","text",[26,27,23],"code",{"__ignoreMap":28},"",[10,30,32],{"id":31},"schnorrs-signature","Schnorr's signature",[15,34,35,36,39,40,43],{},"We use Schnorr's signatures throughout the code. We prefer the form ",[26,37,38],{},"[N, k]",", whereas ",[26,41,42],{},"N"," is the \"public nonce\", because it's batch-verifications compatible.",[15,45,46],{},"In addition to the standard Schnorr's signature we use the following variations:",[48,49,50,54,57],"ol",{},[51,52,53],"li",{},"Signatures within a specific context (transcript). Instead of signing a specific message the signature operates on the given Oracle, which means it signs a specific transcript.",[51,55,56],{},"Generalized Schnorr's signatures, i.e. argument of knowledge of the commitment opening in terms of several generators.",[51,58,59,60,63,64,66],{},"Schnorr's multi-signatures. For a number of signatures in terms of the same set of generators we use a scheme of the form ",[26,61,62],{},"[N, k1, k2, ..., kn]",". That is, only a single ",[26,65,42],{},". For the verification n challenges are derived. The soundness of such a signature can be shown by the same \"extractor\" technique used for standard Schnorr's signature for each secret key in reverse order.",[15,68,69],{},"Worth to note: we also use the (3) in the context of a more complex transcript, where a complex proof proves, among other things, knowledge of various secret keys (such as Lelantus spend proof).",[71,72,74],"h1",{"id":73},"biased-sigma-protocol","Biased Sigma protocol.",[15,76,77,78,82],{},"prove the knowledge of opening of 1-out-of-N, after a ",[79,80,81],"em",{},"Bias"," is subtracted (methodically) from all the elements.",[15,84,85],{},"Inputs:",[87,88,89,92],"ul",{},[51,90,91],{},"Bias (EC point)",[51,93,94],{},"Set of N elements (EC points).",[15,96,97],{},"The proof is similar to the standard Sigma protocol, as described by Jens Groth. The differences are the following:",[48,99,100,103,112],{},[51,101,102],{},"It operates on Oracle. Means - it's a part of a specific transcript, and it's not possible to separate it or tamper with it.",[51,104,105,106,108,109,111],{},"For performance reasons the ",[79,107,81],{}," is not technically subtracted from the set. Instead its cumulative coefficient (multiplier) is calculated, so that the ",[79,110,81],{}," is added later to the equation.",[51,113,114],{},"Since because of (2) the set is not actually modified - the whole proof is very batch-friendly. So in a similar way the coefficients of the elements in the set are updated after each individual proof, but their multi-exponentiation is deferred.",[116,117,119],"h3",{"id":118},"padding","Padding",[15,121,122],{},"If there are not enough elements in the set we use zeroes (points at infinity). For original Sigma protocol that'd be insecure (opening of point at infinity is trivial), however for all our use-cases it's fine because of the Bias, since all our proofs are about validation\tof the Bias, showing that it's a legit commitment of G (blinding factor) and something else. Using the Bias that consists of blinding factor only makes no sense for the attacker.",[10,124,126],{"id":125},"asset-proof","Asset proof",[15,128,129,130,134,135,137],{},"Proves that a given blinded generator H' satisfies H' = k•G + H",[131,132,133],"sub",{},"i",", whereas H",[131,136,133],{}," is a legit generator defined as:",[87,139,140,146],{},[51,141,142,143,145],{},"i > 0: H",[131,144,133],{}," = CreateGenerator(\"B.Asset.Gen.V1 | i);",[51,147,148,149,151],{},"i = 0: H",[131,150,133],{}," = H (standard H-generator used for Beams)",[15,153,154,155,157],{},"The proof is based on the biased Sigma proof described above. The prover chooses the window containing its generator by specifying the window first element. The window size is fixed in the consensus rules. Padding is not applicable, since H",[131,156,133],{}," is assumed to be infinite series.",[87,159,160,167,170],{},[51,161,162,163,166],{},"The Sigma protocol's proof is in terms of ",[26,164,165],{},"G","-generator only",[51,168,169],{},"Bias := H'",[51,171,172,173,175,176,179],{},"Witness data: ",[26,174,133],{},", ",[26,177,178],{},"k"," (the blinding factor of the generator)",[116,181,183],{"id":182},"question","Question",[15,185,186],{},"the H' currently is NOT exposed to the Oracle used in Biased Sigma protocol. Means - an attacker can theoretically craft a false Sigma proof, and then substitute an appropriate H' that would fit the needed equation and make the proof valid.",[15,188,189],{},"However I can't see how the attacker can use such an H' generator. Since it comes-out as a random EC point, it has no direct relation to any other generator, and can't be used to conceal negative values, serial number or etc.",[15,191,192],{},"Should we expose H' to the oracle? Is it \"nice-to-have\", or essential?",[10,194,196],{"id":195},"lelantus-spend-proof","Lelantus spend proof",[15,198,199],{},"Proves that a legit element is withdrawn from the shielded pool.",[15,201,85],{},[87,203,204,214,225,231],{},[51,205,206,209,210,213],{},[26,207,208],{},"SpendPk"," - spend public key, from which the serial number ",[26,211,212],{},"s"," is derived in a deterministic way.",[51,215,216,217,220,221,224],{},"Optional: blinded Asset generator ",[26,218,219],{},"H'"," and ",[79,222,223],{},"Asset Proof",", which proves its validity.",[51,226,227,230],{},[26,228,229],{},"Commitment"," - commitment to the element being-withdrawn.",[51,232,233],{},"Shielded pool window - the list of commitments (EC points).",[15,235,236],{},"Proves the following:",[87,238,239,245,254,263],{},[51,240,241,242,244],{},"The spend is signed by the secret key, the pre-image of ",[26,243,208],{},".",[51,246,247,249,250,253],{},[26,248,229],{}," is a commitment of the form k•G + H'•v. The validity of ",[26,251,252],{},"v"," (i.e. rangeproof) is not necessary.",[51,255,256,257,259,260,262],{},"Serial number ",[26,258,212],{}," (derived from ",[26,261,208],{},") corresponds to an element in the specified window.",[51,264,265,267,268,270],{},[26,266,229],{}," commits to the same value and asset type (H",[131,269,133],{},", v).",[116,272,274],{"id":273},"methodically","Methodically",[87,276,277,286,292,299],{},[51,278,279,281,282,285],{},[79,280,223],{}," is verified if specified. Otherwise the asset generator is assumed ",[26,283,284],{},"H"," (used for Beams).",[51,287,288,289,291],{},"Generalized Schnorr's signature proves ",[26,290,229],{}," is indeed of the form k•G + H'•v.",[51,293,256,294,296,297],{},[26,295,212],{}," is derived from ",[26,298,208],{},[51,300,301,302],{},"Biased Sigma protocol is used for the rest:\n",[87,303,304,310,316],{},[51,305,306,307],{},"The Bias is: ",[26,308,309],{},"Commitment + s•J",[51,311,312,313,315],{},"The proof is in terms of ",[26,314,165],{},"-generator only.",[51,317,318],{},"Witness data is the blinding factor difference.",[116,320,322],{"id":321},"technically","Technically",[15,324,325,326,328,329,331,332,220,334,336,337,220,339,244],{},"Technically there are 2 Schnorr's proofs here: validity of ",[26,327,229],{},", and knowledge of pre-image of ",[26,330,208],{},". They are compressed into a single generalized multi-signature, i.e. the prover knows the opening of both ",[26,333,229],{},[26,335,208],{}," in terms of ",[26,338,165],{},[26,340,219],{},[15,342,343,347,348,350,351,353,354,356],{},[344,345,346],"u",{},"Note:"," Normally the ",[26,349,208],{}," must be of the form k•G, and in our scheme we weaken this by allowing additional generator ",[26,352,219],{},". But there seems to be no problem here if someone decides to used ",[26,355,208],{}," that contains also the asset generator used for this element.",[15,358,359,360,362],{},"In addition the ",[26,361,229],{}," is used twice in the protocol: in the generalized Schnorr's signature, and as a part of the Bias for the Sigma protocol. So instead of using it twice we aggregate its coefficient, and is it once in the equation.",[15,364,365],{},"Finally the transcript is the following:",[87,367,368,379,382,385,388,393,396,405,408,411],{},[51,369,370,371,374,375,378],{},"oracle \u003C-- Sigma parameters (",[26,372,373],{},"n",",",[26,376,377],{},"M",")",[51,380,381],{},"oracle \u003C-- `Commitment'",[51,383,384],{},"oracle \u003C-- `SpendPk'",[51,386,387],{},"oracle \u003C-- `N' (public nonce of the Schnorr's multi-signature)",[51,389,390,391],{},"oracle --> Challenge for ",[26,392,229],{},[51,394,395],{},"oracle --> Challenge for `SpendPk",[51,397,398,399,175,402],{},"\u003C-- Schnorr's multi-signature: ",[26,400,401],{},"kG",[26,403,404],{},"kH",[51,406,407],{},"oracle \u003C-- Sigma protocol part 1 (A, B, C, D, G-vector)",[51,409,410],{},"oracle --> Challenge for Sigma protocol",[51,412,413],{},"\u003C-- Sigma protocol part 2 (a, c, r, f-vector)",{"title":28,"searchDepth":415,"depth":415,"links":416},2,[417,418,422,425],{"id":12,"depth":415,"text":13},{"id":31,"depth":415,"text":32,"children":419},[420],{"id":118,"depth":421,"text":119},3,{"id":125,"depth":415,"text":126,"children":423},[424],{"id":182,"depth":421,"text":183},{"id":195,"depth":415,"text":196,"children":426},[427,428],{"id":273,"depth":421,"text":274},{"id":321,"depth":421,"text":322},"md",null,{},true,"\u002Fdocs\u002Fcore-tech\u002Fbeam-signature-schemes",{"description":28},"docs\u002Fcore-tech\u002FBeam-signature-schemes","ju7Bu4lPfAGYTlQfrun5z1g0h5VqsIfGY2b8vQ0uclo",[438,443],{"title":439,"path":440,"stem":441,"description":442,"children":-1},"Beam News Channels","\u002Fdocs\u002Fcore-tech\u002Fbeam-news-channels","docs\u002Fcore-tech\u002FBeam-news-channels","Beam able to provide actual news and exchange rates to wallet users.\nThis implemented using signed messages of different types transmitted over the Bulletin Board System (BBS).\nSuch messages make possible for instance to notify wallet user with popup on new wallet application version release.\nEach message is broadcasted over the network to wallet applications.\nBroadcasted messages has to be signed with apropriate key to verify publisher. Wallet applications have publisher key to check if messages are valid.",{"title":444,"path":445,"stem":446,"description":447,"children":-1},"Beam Wallet Protocol API","\u002Fdocs\u002Fcore-tech\u002Fbeam-wallet-protocol-api","docs\u002Fcore-tech\u002FBeam-wallet-protocol-API","Starting with v6.0 BEAM wallet supports API versioning using the --api_version option. Please choose the corresponding API version in the list below to get the description of the available methods.",1783006063474]