Repository navigation
Conversation
…dress The sender of a public offline tx doesn't know the receiver. For a legacy (unsigned) public address it makes up the voucher and signs it with a random one-time key stored as PeerEndpoint, so the exported proof named that key as the receiver and still verified. For a signed public address no voucher is stored and the export failed with a generic message, while wallet-api returned an empty payment_proof as success. ExportPaymentProof now refuses public offline txs with a clear message, and wallet-api export_payment_proof returns PaymentProofExportError for them. A real proof for these txs needs a new proof format (BeamMW#1975).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #1826 (the guard suggested in the issue; a real proof for these transactions needs a new proof format, #1975).
Problem
The sender of a transaction to a public offline address doesn't know the receiver:
LoadReceiverParamsmakes up the voucher itself and signs it with a random one-time key that it stores asPeerEndpoint.ExportPaymentProofexported that key as the receiver, andVerifyPaymentProofaccepted the proof, because it only checks the voucher against that same key. So the wallet produced a proof that "verifies" but names a receiver that doesn't exist.export_payment_proofreturned"payment_proof": ""as a success.Change
storage::ExportPaymentProofrefuses public offline transactions (TxParameterID::AddressType == PublicOffline) with a clear message. The CLIpayment_proof_exportshows it.export_payment_proofreturnsPaymentProofExportErrorwith the same message instead of an empty proof.Tests
lelantus_test/TestPublicAddressTxnow also sends through a legacy public address. The parameters go through the realLoadReceiverParams, so the made-up voucher and endpoint are the ones the wallet really uses. The test checks that both transactions complete, that the receiver gets both coins, and that no proof is exported for either.Receiver: 35c541…, a random key.lelantus_test,wallet_api_testandwallet_testpass (macOS arm64, Ninja RelWithDebInfo).