| |
---|
Resources | |
Do we need more replay reinforcement? | 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? Does the nonce provide enough support to prevent replay?
|
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. 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 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
| |
Review of wallet proposal #2 | https://rchain.atlassian.net/wiki/spaces/CORE/pages/652640311/Wallet+proposal+2 This came out of the proposal for relying on a map. 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?
|
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
|