Ask questionsList of Changes in 4.0.0
These release notes constitute the list of changes from 3.1.2
--v4flag. See the Slatepack section for details.
The major new feature of the v4.0.0 wallet is the introduction of the Slatepack Format and Workflow. Slatepack is the culmination of much thinking about how to reduce, simplify and standardize how transactions are exchanged between parties, and it is hoped that it will provide a solid foundation to improve the overall user experience over time.
In a nutshell:
send, sending wallets will attempt to send a transaction to the TOR hidden service.
A Full description of Slatepack can be found in the Slatepack RFC (URL to be updated after merge)
--v4flag during the
methodflag is removed from all command-line arguments in favor of Slatepack workflows
destis no longer mandatory for all functions that produce a slate. If
destis provided and is a Slatepack address, the slatepack sync-send workflow is invoked, which attempts to send to the TOR address represented by the Slatepack address, followed by Slatepack output to the prompt and a file if that fails. If
destis not provided the Slatepack is automatically output.
destis provided as a Slatepack address, the Slatepack is encrypted for the recipient only.
senderfield in the encrypted portion of the Slatepack is included by default.
destfield is a valid Slatepack address, a payment proof will be requested by default. If this is not desired, the
-nflag can be provided.
pay) attempt to continue the transaction via the Slatepack's sender field if available, otherwise they revert to Slatepack output.
inputargument for all command-line functions that accept a slate is no longer mandatory. If included, the command will attempt to read from the given file. If not, the command will prompt the user to paste Slatepack data into the terminal directly.
--manualflag is added to all commands that can send a Slatepack. If this flag is present, the wallet will not attempt to send the resulting Slatepack via TOR.
unpackcommand is added, which will decode and decrypt (if possible), a Slatepack Message.
addresscommand will now output this wallet's Slatepack address
destfield for now, however the user will need to respond to a nag prompt.
messageflag has been removed from all commands that previously accepted an optional message
messageargument is removed from
process_invoice_txwill optionally invoke the Slatepack sync workflow if the appropriate InitSendTx arguments are provided.
skip_send_attemptis added to the
TorConfigstruct. To prevent these calls from attempting to send via TOR, call the
set_tor_configAPI function with this field set to
post_txfunction now accepts a Slate rather than a raw Transaction
get_stored_txcan now accept either a Transaction Log ID or a Slate UUID
get_public_proof_addressis replaced with
get_slatepack_address, which returns a
get_slatepack_secret_keyis added, which returns the SecretKey of the wallet that can be used for Slatepack decryption
create_slatepack_messageis added, which creates a SlatepackMessage string from the given slate and recipients
slate_from_slatepack_messageis added, which extracts a Slate from a SlatepackMessage
decode_slatepack_messageis added, which decodes a SlatepackMessage
receive_txwill attempt to send the processed transaction back to the sender if a return address is provided. This functionality is provided for convenience for upstream wallet developers. If this functionality is used, the caller should check the slate's
stafield to determine whether the sync send attempt succeeded, and invoke the slatepack workflow otherwise.
messagefield in the
receive_txhas been changed to
r_addr. It is now interpreted as a Slatepack address and if included, the funciton will attempt to send the resulting Slatepack back to the specified address.
recieve_txfrom attempting to send the result via TOR.
finalize_invoice_txis removed, replaced with simply
finalize_txfunction now has a
post_automaticallyflag. The function will post to the node only if this is set to
messagefield removed from the Slate along with all related API and command-line functions.
skip_send_attemptfield is added to the
TorConfigstruct. This can be set to
trueto stop the wallet from ever attempting to send via TOR. This field is not required to be present in the configuraiton file.
Answer questions tromp
our pool (2Miners.com) is fully anonymous not having any sort of a client area or secure page where the miner could potentially grab these Slatepack Messages for a direct manual deposit
You're already maintaining some miner credentials, like an address to send mining proceeds to. By maintaining a grin wallet address for each grin miner, you can let them exchange encrypted slatepacks for payout to their claimed grin wallet in an anonymous client area. Only the true owner of the grin wallet address is able to complete the payout transaction, so no further authentication is required?!