kek
November 20, 2017, 11:12am
1
seems interesting.
opened 04:51AM - 18 Jul 17 UTC
A-rpc-interface
With t-addrs, it is possible to run a "split-node" configuration, where the user… runs two nodes:
- a watching node, which downloads the block chain and tracks balances via watch addresses.
- an offline nodes, which stores the private keys and is used to create transactions.
To make a transaction, the user performs the following steps (either via that RPC or their wallet's UI):
- Call `createrawtransaction` on the watching node
- Transfer the unsigned transaction to the offline node
- Call `signrawtransaction` to sign it
- Transfer the signed transaction back to the watching node
- Call `sendrawtransaction` to send it
We can imagine a similar workflow that would enable users to create shielded transactions in a split-node configuration (actual RPC method names TBD):
- Call `z_preparetransaction` on the watching node to obtain a "proto-transaction"
- Contains the unsigned, unproven transaction, as well as all relevant private inputs
- Transfer the "proto-transaction" to the offline node
- Call `z_shieldtransaction` to create the proof and sign the transaction
- Transfer the completed transaction back to the watching node
- Call `sendrawtransaction` to send it
We should design and implement the two additional RPC methods that enable this workflow.
Two notes:
- The exact split between the two new methods has some flexibility, depending on the trade-off we want to reach between usability and privacy. The "proto-transaction" could include:
- everything except the proof and signatures (ie. the watching node chooses the random values for the notes)
- the necessary inputs, anchor, and the recipient addresses and values (with the offline node generating the randomness)
- only the necessary inputs summing to the total needed, and anchor (with the recipients and precise values specified on the offline node)
- The usability of these additional RPC methods will be limited until #2143 is closed, because currently it is not possible to detect incoming notes without access to the spending key. This limitation may be removed by the Sapling upgrade.
what are some advantages to shielded offline TX. think i have a good idea, but would like a pro’s explanation.
str4d
November 20, 2017, 1:06pm
2
It would enable users to store their Sprout shielded funds more securely, by (for example) having their spending key on an airgapped computer.
This isn’t a catch-all of course, because there needs to be some data transfer between the online and offline nodes, and this could be compromised (e.g. bad USB drive). But the bar to doing so is higher than if the spending key is on an online computer. It can also be preferable in some instances to have a much smaller trust boundary around the spending key, e.g. by using a hardware wallet, but that cannot be done for the Sprout circuit (but will be possible for Sapling).
2 Likes