| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
After the fork, normal transfer functions called via RPC
use the minimum mixin 2 if 0 or 1 is requested. While the
incoming transaction may be valid (eg, it has an unmixable
and at most a mixable input), it is a simple way to make
sure RPC users can't get a seemingly random accept/reject
behavior if they don't update their requested mixin.
|
| |
|
|
| |
Add support for short/integrated/encrypted IDs to get_payments RPC
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Blockchain hashes and key images are flushed, and blocks are
pulled anew from the daemon.
The console command is shortened to match bc_height.
This should make it a lot easier on users who are currently
told to remove this particular cache file but keep the keys
one, etc, etc.
|
| |
|
|
| |
Reported by saddam
|
| |
|
|
| |
reported by saddam
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
To get the tx keys returned via RPC, set the "get_tx_key" or
"get_tx_keys" request field to true (defaults to false).
|
| |
|
|
|
| |
They are also stored in the cache file, to be retrieved using
a new get_tx_key command.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Pros:
- smaller on the blockchain
- shorter integrated addresses
Cons:
- less sparseness
- less ability to embed actual information
The boolean argument to encrypt payment ids is now gone from the
RPC calls, since the decision is made based on the length of the
payment id passed.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
A payment ID may be encrypted using the tx secret key and the
receiver's public view key. The receiver can decrypt it with
the tx public key and the receiver's secret view key.
Using integrated addresses now cause the payment IDs to be
encrypted. Payment IDs used manually are not encrypted by default,
but can be encrypted using the new 'encrypt_payment_id' field
in the transfer and transfer_split RPC calls. It is not possible
to use an encrypted payment ID by specifying a manual simplewallet
transfer/transfer_new command, though this is just a limitation
due to input parsing.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It should avoid a lot of the issues sending more than half the
wallet's contents due to change.
Actual output selection is still random. Changing this would
improve the matching of transaction amounts to output sizes,
but may have non obvious effects on blockchain analysis.
Mapped to the new transfer_new command in simplewallet, and
transfer uses the existing algorithm.
To use in RPC, add "new_algorithm: true" in the transfer_split
JSON command. It is not used in the transfer command.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Daemon interactive mode is now working again.
RPC mapped calls in daemon and wallet have both had connection_context
removed as an argument as that argument was not being used anywhere.
|
| | |
|
| |\
| |
| |
| | |
24d500c Add a --restricted-rpc flag to simplewallet (moneromooo-monero)
|
| | |
| |
| |
| |
| | |
It restricts RPC to a subset of "view only" commands. Kind of like
a poor man's view key replacement.
|
| |/
|
|
| |
by giving an empty list of payment IDs.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
| |
only support mnemonic as key_type currently
|
| |\
| |
| | |
New readme, license changes
|
| | | |
|
| |/ |
|
| | |
|
| |
|
|
|
|
|
|
| |
wallet RPC now uses wallet2::create_transactions and wallet2::commit_tx instead
of wallet2::transfer. This made it possible to add the RPC call /transfer_split, which
will split transactions automatically if they are too large. The old call to
/transfer will return an error stating to use /transfer_split if multiple
transactions are needed to fulfill the request.
|
| | |
|
| |\ |
|
| | | |
|
| | | |
|
| | | |
|
| |/ |
|
| | |
|
| |
|
