Understanding - Today on RChain you have to submit a deploy request with owner and timestamp of the deploy. And RChain enforces that this deploy can never be deployed again.
QUESTION - Why do we need additional support in the wallet to prevent replay?
Challenge is imagining all scenarios that include withdrawal authorization.
IDEA require a signature for every transaction mitigates risk.
CON
Requires multiple, signed deploys to achieve multiple transactions
PRO
Mitigates the risk of replay
Does the nonce provide enough support to prevent replay?
Dom and Artur say yes
Ovidiu to think about
Chris to add question to #cryptography
Periodic payments
Concern about supporting periodic sending of REV (ex I want to pay every 30 days)
BLOCKER There is no concept of calendar time on the blockchain, so this is not a possibility
RISK running the contract multiple times is an attack vector because its replayed.
IDEA review code carefully to assure the replay is what you want.
CONCERN how do we store this type of contract to support periodic, desired replay
Example - There is a rental contract that is not connected to the wallet. There is a separate send to this contract (“rent contract”) from the wallet to authorize payment.
RISK - delegating authority to your wallet
Mitigation idea - Don’t give away the wallet. Give away control to the wrapper of the wallet that authorizes the interaction (amount, cadence, etc) with the 3rd party
QUESTION - How do you set up a process where you delegate authority to your wallet and control what the other party does?
RISK - you could empty the wallet before withdrawal is made by 3rd party
Signature authority
Any code you deploy is signed with your key. You can only execute code that’s been signed. Keys must match: wallet and code.
You need authorization to withdraw. You do not need authentication to send.
This came out of the proposal for relying on a map.
Greg argued for using the OCap approach over the map
Proposal #2 incorporates the OCap model
Chris walked through definitions.
IDEA - consider revisit of nomenclature if/when there are challenges with user adoption
Discussion of order of operations
QUESTION - What is the “lockbox”
Greg calls it witness to a value
Requires a primitive
Implementation of the REVWallet
Why do we need it if there is signature approval?
Lockbox supports multisig scenarios
Rholang needs a way to see the signature. Lockbox provides this capability.
This is the way you communicate who signed the transaction on the code requesting a transaction against the wallet.
QUESTION is the witness called to approve transactions?
This is an API or protocol detail related to authorization for the transactions
Bootstrap scenario
Described on wallet proposal #2 page
Chris walked through
REQUIREMENT need to define the format of the REVWallet address
QUESTION - Where do we store the record of the transaction for auditing?
REVWallet support the doing, but how do we store information to support audit?
IDEA we don’t store it in the contract or the tuplespace. Use a block explorer to audit (Kent)
Only look for this information in finalized blocks
Related to Mercury timeline, it may be more efficient to deliver a log to support audit rather than a block explorer
RISK we don’t have confirmation of agreement on this strategy with Greg
QUESTION of how Alice gets her wallet; as a validator herself or via an intermediary validator
Observation that most ETH users rely on Etherscan rather than run their own nodes
Action items
Chris Boscolo Ask the nonce question on #cryptography to get feedback from Kyle or Mike
Ovidiu Deac consider over the weekend the conversation about periodic payments and replay prevention and the need for a block explorer related to auditing