| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Signed-off-by: Maxithi <34792056+Maxithi@users.noreply.github.com>
|
|
They are hex rather than words, because they are a lot longer
than "normal" seeds, as they have to embed a lot more information
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
It exports raw transactions, so they may be used by other tools,
for instance to be relayed to the network externally.
|
|
|
|
|
|
|
|
|
|
|
|
Scheme by luigi1111:
Multisig for RingCT on Monero
2 of 2
User A (coordinator):
Spendkey b,B
Viewkey a,A (shared)
User B:
Spendkey c,C
Viewkey a,A (shared)
Public Address: C+B, A
Both have their own watch only wallet via C+B, a
A will coordinate spending process (though B could easily as well, coordinator is more needed for more participants)
A and B watch for incoming outputs
B creates "half" key images for discovered output D:
I2_D = (Hs(aR)+c) * Hp(D)
B also creates 1.5 random keypairs (one scalar and 2 pubkeys; one on base G and one on base Hp(D)) for each output, storing the scalar(k) (linked to D),
and sending the pubkeys with I2_D.
A also creates "half" key images:
I1_D = (Hs(aR)+b) * Hp(D)
Then I_D = I1_D + I2_D
Having I_D allows A to check spent status of course, but more importantly allows A to actually build a transaction prefix (and thus transaction).
A builds the transaction until most of the way through MLSAG_Gen, adding the 2 pubkeys (per input) provided with I2_D
to his own generated ones where they are needed (secret row L, R).
At this point, A has a mostly completed transaction (but with an invalid/incomplete signature). A sends over the tx and includes r,
which allows B (with the recipient's address) to verify the destination and amount (by reconstructing the stealth address and decoding ecdhInfo).
B then finishes the signature by computing ss[secret_index][0] = ss[secret_index][0] + k - cc[secret_index]*c (secret indices need to be passed as well).
B can then broadcast the tx, or send it back to A for broadcasting. Once B has completed the signing (and verified the tx to be valid), he can add the full I_D
to his cache, allowing him to verify spent status as well.
NOTE:
A and B *must* present key A and B to each other with a valid signature proving they know a and b respectively.
Otherwise, trickery like the following becomes possible:
A creates viewkey a,A, spendkey b,B, and sends a,A,B to B.
B creates a fake key C = zG - B. B sends C back to A.
The combined spendkey C+B then equals zG, allowing B to spend funds at any time!
The signature fixes this, because B does not know a c corresponding to C (and thus can't produce a signature).
2 of 3
User A (coordinator)
Shared viewkey a,A
"spendkey" j,J
User B
"spendkey" k,K
User C
"spendkey" m,M
A collects K and M from B and C
B collects J and M from A and C
C collects J and K from A and B
A computes N = nG, n = Hs(jK)
A computes O = oG, o = Hs(jM)
B anc C compute P = pG, p = Hs(kM) || Hs(mK)
B and C can also compute N and O respectively if they wish to be able to coordinate
Address: N+O+P, A
The rest follows as above. The coordinator possesses 2 of 3 needed keys; he can get the other
needed part of the signature/key images from either of the other two.
Alternatively, if secure communication exists between parties:
A gives j to B
B gives k to C
C gives m to A
Address: J+K+M, A
3 of 3
Identical to 2 of 2, except the coordinator must collect the key images from both of the others.
The transaction must also be passed an additional hop: A -> B -> C (or A -> C -> B), who can then broadcast it
or send it back to A.
N-1 of N
Generally the same as 2 of 3, except participants need to be arranged in a ring to pass their keys around
(using either the secure or insecure method).
For example (ignoring viewkey so letters line up):
[4 of 5]
User: spendkey
A: a
B: b
C: c
D: d
E: e
a -> B, b -> C, c -> D, d -> E, e -> A
Order of signing does not matter, it just must reach n-1 users. A "remaining keys" list must be passed around with
the transaction so the signers know if they should use 1 or both keys.
Collecting key image parts becomes a little messy, but basically every wallet sends over both of their parts with a tag for each.
Thia way the coordinating wallet can keep track of which images have been added and which wallet they come from. Reasoning:
1. The key images must be added only once (coordinator will get key images for key a from both A and B, he must add only one to get the proper key actual key image)
2. The coordinator must keep track of which helper pubkeys came from which wallet (discussed in 2 of 2 section). The coordinator
must choose only one set to use, then include his choice in the "remaining keys" list so the other wallets know which of their keys to use.
You can generalize it further to N-2 of N or even M of N, but I'm not sure there's legitimate demand to justify the complexity. It might
also be straightforward enough to support with minimal changes from N-1 format.
You basically just give each user additional keys for each additional "-1" you desire. N-2 would be 3 keys per user, N-3 4 keys, etc.
The process is somewhat cumbersome:
To create a N/N multisig wallet:
- each participant creates a normal wallet
- each participant runs "prepare_multisig", and sends the resulting string to every other participant
- each participant runs "make_multisig N A B C D...", with N being the threshold and A B C D... being the strings received from other participants (the threshold must currently equal N)
As txes are received, participants' wallets will need to synchronize so that those new outputs may be spent:
- each participant runs "export_multisig FILENAME", and sends the FILENAME file to every other participant
- each participant runs "import_multisig A B C D...", with A B C D... being the filenames received from other participants
Then, a transaction may be initiated:
- one of the participants runs "transfer ADDRESS AMOUNT"
- this partly signed transaction will be written to the "multisig_monero_tx" file
- the initiator sends this file to another participant
- that other participant runs "sign_multisig multisig_monero_tx"
- the resulting transaction is written to the "multisig_monero_tx" file again
- if the threshold was not reached, the file must be sent to another participant, until enough have signed
- the last participant to sign runs "submit_multisig multisig_monero_tx" to relay the transaction to the Monero network
|
|
Scheme by luigi1111
|
|
If no subaddress index is given, consider all of them
|
|
|
|
Monero.ts: Fewer pleases in seed NOTE
Monero_it.ts: Fewer pleases in seed NOTE
Monero_fr.ts: Fewer pleases in seed NOTE
|
|
|
|
|
|
|
|
|
|
|
|
- refactoring: proof generation/checking code was moved from simplewallet.cpp to wallet2.cpp
- allow an arbitrary message to be signed together with txid
- introduce two types (outbound & inbound) of tx proofs; with the same syntax, inbound is selected when <address> belongs to this wallet, outbound otherwise. see GitHub thread for more discussion
- wallet RPC: added get_tx_key, check_tx_key, get_tx_proof, check_tx_proof
- wallet API: moved WalletManagerImpl::checkPayment to Wallet::checkTxKey, added Wallet::getTxProof/checkTxProof
- get_tx_key/check_tx_key: handle additional tx keys by concatenating them into a single string
|
|
|
|
|
|
Avoids turning it to a huge number
|
|
|
|
|
|
Missed a crypto::null_pkey in PR#2629
|
|
Missed an input_line() change
|
|
|
|
wallet2 is a library, and should not prompt for stdin. Instead,
pass a function so simplewallet can prompt on stdin, and a GUI
might display a window, etc.
|
|
It was only used there, and this removes one part of the common
dependency on libreadline
|
|
This ensures they don't go out of sync when adding/changing them,
and makes the code easier to deal with.
|
|
It's nasty, and actually breaks on Solaris, where if.h fails to
build due to:
struct map *if_memmap;
|
|
wallet2::get_payments etc
|
|
It'd be interpreted as a huge one (~0 fake outs)
|
|
This yields a clear error message rather then some possibly
confusing more technical errors down the line
|
|
|
|
|
|
|
|
Transactions in the txpool are marked when another transaction
is seen double spending one or more of its inputs.
This is then exposed wherever appropriate.
Note that being marked with this "double spend seen" flag does
NOT mean this transaction IS a double spend and will never be
mined: it just means that the network has seen at least another
transaction spending at least one of the same inputs, so care
should be taken to wait for a few confirmations before acting
upon that transaction (ie, mostly of use for merchants wanting
to accept unconfirmed transactions).
|
|
|
|
Executing 'sweep_all' with no arguments segfaulted before.
|
|
|
|
|
|
They are actually wrong if the wallet is setup in a different
denomination, and it's incursion of extrinsic lingo where monero
fits perfectly in the first place.
|
|
|
|
Fix #1530
|
|
|
|
|
|
|
|
|
|
It'd be set to the current wallet default instead
|
|
|
|
Also mention those options in the start_mining help line
|
|
|
|
|
|
CID 175308
|
|
|
|
Also, set_log without parameters now prints the log categories
|
|
|
|
This uses luigi1111's CN_Add method.
See https://xmr.llcoins.net for details.
|
|
|
|
|
|
|
|
including expected transaction backlog at different priorities
|
|
|
|
Suspend readline when refreshing
|
|
|
|
Add `--mnemonic-language` command-line arg so it's possible to generate a wallet
without interacting with the CLI.
|
|
|
|
|
|
|
|
It's annoying and pointless (especially as it's the only thing
where the user is asked twice)
|
|
Previously, the wallet just asked for "Spend key" and "View key" but
now it specifies that these should be the secret versions of these
keys.
|
|
Integrated addresses are shown when an encrypted payment id is used
|
|
Should help people who don't realize why they haven't seen their
monero yet.
|
|
also show it in simplewallet's show_transfer
|
|
|
|
Asks user for all the data required to merge secret keys from multisig wallets into one master wallet, which then gets full control of the multisig wallet. The resulting wallet will be the same as any other regular wallet.
|
|
Library code should definitely not ask for console input unless
it's clearly an input function. Delegating the user interaction
part to the caller means it can now be used by a GUI, or have a
decision algorithm better adapted to a particular caller.
|
|
"Payment successfully sent" can be misleading if the TX isn't confirmed and drops from TX-pool.
|
|
- Add missing unbind key
- Fix colored messages
- Add command completion
- Preserve last command input
- Fix cursor position issues
- Fix trailing whitespace in commands
- Synchronize set_prompt
|
|
This ensures the chain and related structures can't change
while we're using them
|
|
The previous patch was based on a wrong premise (that the
daemon height was 0 because the daemon calling code wasn't
yet initialized). In fact, current height approximation
was not setup for testnet. Fix this.
|
|
monero-wallet-cli commands which have multine output sometimes causes
issues with the readline support. This patch fixes show_transfers,
payments and incoming_transfers.
|
|
|
|
|
|
|
|
not the actual tx secret key
|
|
This is trivial, but often requested, and possibly hard to do
in Windows. That makes it more user friendly.
|
|
Add fail-fast paths that reduce frustration around the misuse of
--wallet-file combined with --restore-deterministic-wallet. Flow now
gives more descriptive errors and avoids having users type in their
whole seed before the failure condition is noticed.
|
|
With the recent change to wallet creation code, the code was
calling to the daemon before the wallet's daemon address was
initialized, and thus failing. This was causing all new wallets
to refresh from 0 instead of just fetching early block hashes.
|
|
|
|
It sweeps all outputs below the given threshold
This is available via the existing sweep_all RPC, by setting
amount_threshold the desired amount (in atomic units)
|
|
People are likely to enter it in three lines as it is how it
is displayed at creation time
|
|
|
|
They'd be rejected as suspicious as the change goes to more
than one destination. However, split transactions will most
likely include fake zero amount change to random addresses,
so we only consider change with non zero amount for this.
|
|
These can create transactions, even though they cannot sign them.
|
|
Allows priority argument default/unimportant/normal/elevated/priority to
be used per transaction in CLI wallet's transfer command. Resolves #1913.
|
|
|
|
|
|
With the change from the original transfer method to the new
algorithm, payments to the same destination were merged. It
seemed like a good idea, optimizing space. However, it is a
useful tool for people who want to split large outputs into
several smaller ones (ie, service providers making frequent
payments, and who do not like a large chunk of their balance
being locked for 10 blocks after each payment).
Default to off, which is a change from the previous behavior.
|
|
|
|
When a single input is enough to satisfy a transfer, the code would
previously try to add a second input, to match the "canonical" makeup
of a transaction with two inputs and two outputs. This would cause
wallets to slowly merge outputs till all the monero ends up in a
single output, which causes trouble when making two transactions
one after the other, since change is locked for 10 blocks, and an
increasing portion of the remaining balance would end up locked on
each transaction.
There are two new settings (min-output-count and min-output-value)
which can control when to stop adding such unneeded second outputs.
The idea is that small "dust" outputs will still get added, but
larger ones will not.
Enable with, eg:
set min-output-count 10
set min-output-value 30
to avoid using an unneeded second output of 30 monero or more, if
there would be less than 10 such outputs left.
This does not invalidate any other reason why such outputs would
be used (ie, when they're really needed to satisfy a transfer, or
when randomly picked in the normal course of selection). This may
be improved in the future.
|
|
New pull request because I couldn't figure out how to change the previous one.
1. For clarity, I want to focus the help text for the 'transfer' command on the most typical use case (a single payment).
2. New users will prefer to use 'transfer', so the older method 'transfer_original' should refer to 'transfer' rather than the other way around.
|
|
|
|
Those can create unsigned transactions
|
|
|
|
This would otherwise be a silent noop, which is confusing.
This can happen if the daemon is started, but not yet ready
to service all requests, and this is a safe catch all.
|
|
Minimum mixin 4 and enforced ringct is moved from v5 to v6.
v5 is now used for an increased minimum block size (from 60000
to 300000) to cater for larger typical/minimum transaction size.
The fee algorithm is also changed to decrease the base per kB
fee, and add a cheap tier for those transactions which we do
not care if they get delayed (or even included in a block).
|
|
Also tweak wallet2 password code to verify password without
saying it's a new wallet, because it's assuming things.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Remove empty static function which was refactored, as well as
leftover exception testing code.
|
|
|
|
|
|
|
|
- http_simple_client now uses std::chrono for timeouts
- http_simple_client accepts timeouts per connect / invoke call
- shortened names of epee http invoke functions
- invoke command functions only take relative path, connection
is not automatically performed
|
|
|
|
|
|
|
|
|
|
This replaces the epee and data_loggers logging systems with
a single one, and also adds filename:line and explicit severity
levels. Categories may be defined, and logging severity set
by category (or set of categories). epee style 0-4 log level
maps to a sensible severity configuration. Log files now also
rotate when reaching 100 MB.
To select which logs to output, use the MONERO_LOGS environment
variable, with a comma separated list of categories (globs are
supported), with their requested severity level after a colon.
If a log matches more than one such setting, the last one in
the configuration string applies. A few examples:
This one is (mostly) silent, only outputting fatal errors:
MONERO_LOGS=*:FATAL
This one is very verbose:
MONERO_LOGS=*:TRACE
This one is totally silent (logwise):
MONERO_LOGS=""
This one outputs all errors and warnings, except for the
"verify" category, which prints just fatal errors (the verify
category is used for logs about incoming transactions and
blocks, and it is expected that some/many will fail to verify,
hence we don't want the spam):
MONERO_LOGS=*:WARNING,verify:FATAL
Log levels are, in decreasing order of priority:
FATAL, ERROR, WARNING, INFO, DEBUG, TRACE
Subcategories may be added using prefixes and globs. This
example will output net.p2p logs at the TRACE level, but all
other net* logs only at INFO:
MONERO_LOGS=*:ERROR,net*:INFO,net.p2p:TRACE
Logs which are intended for the user (which Monero was using
a lot through epee, but really isn't a nice way to go things)
should use the "global" category. There are a few helper macros
for using this category, eg: MGINFO("this shows up by default")
or MGINFO_RED("this is red"), to try to keep a similar look
and feel for now.
Existing epee log macros still exist, and map to the new log
levels, but since they're used as a "user facing" UI element
as much as a logging system, they often don't map well to log
severities (ie, a log level 0 log may be an error, or may be
something we want the user to see, such as an important info).
In those cases, I tried to use the new macros. In other cases,
I left the existing macros in. When modifying logs, it is
probably best to switch to the new macros with explicit levels.
The --log-level options and set_log commands now also accept
category settings, in addition to the epee style log levels.
|
|
|
|
|
|
|
|
#1498
|
|
Not 100$ sure this is the right fix, nor whether address book entries from URL should be stored as addresses or URLs (or both with a check for change on payment).
|
|
|
|
|
|
|
|
tools::dns_utils; support integrated address with dns lookup
|
|
|
|
The serialization format changed, and while there is code
to load the older serialization format, an older monerod
will not be able to load a file saved by a new monerod,
even though both share the same version. This is not good,
and we prefer a version bump.
|
|
|
|
|
|
reported by nioc
|
|
Resolves -Wreturn-type
References #1447 #1451
|
|
Closes #1447
References #1451
|
|
|
|
|
|
Possibly other pedantry. Pedants are people too.
|
|
|
|
Daemon RPC version is now composed of a major and minor number,
so that incompatible changes bump the major version, while
compatible changes can still bump the minor version without
causing clients to unnecessarily complain.
|
|
|
|
|
|
When passing around unsigned and signed transactions, outputs
and key images are passed along (outputs are passed along unsigned
transactions from the hot wallet to the cold wallet, key images
are passed along with signed transations from the cold wallet
to the hot wallet), to allow more user friendly syncing between
hot and cold wallets.
|
|
Prints pubkey and key image as well
|
|
Also catch change to multiple addresses, this is unexpected
|
|
|
|
|
|
|
|
|
|
This key is available to both cold and hot wallet.
Authenticated encryption will guard against interception and/or
modification of the file.
|
|
m_amount_out was sometimes getting initialized with the sum of
an transaction's outputs, and sometimes with the sum of outputs
that were not change. This caused confusion and bugs. We now
always set it to the sum of outputs. This reverts an earlier
fix for bad amounts as this used the other semantics. The wallet
data should be converted automatically in a percentage of cases
that I'm hesitant to estimate. In any case, restoring from seed
or keys or rebuilding the cache will get it right.
|
|
The intended use is to export outputs from a hot wallet, which
can scan incoming transfers from the network, and import them
in the cold wallet, which can't. The cold wallet can then compute
key images for those outputs, which can then be exported with
export_key_images, etc.
|
|
This is on the potentially compromised wallet, but still guards
against stupid mistakes.
|
|
This will happen when sending to another address, after removing
the fee.
|
|
Not as trustworthy as this is in the view wallet, the one
that's considered compromised.
|
|
Re-creating the transaction on the cold wallet was not splitting
the change, causing the transaction to be rejected by the network.
This worked on testnet since amounts do not have to be split.
Also add selected_transfers, which can now be saved since they're
size_t rather than iterators. This allows the view wallet to
properly set the sent outputs as spent and update balance.
Bump transfer file version numbers to match.
|
|
Factor locked_transfer into transfer_main, which brings various
improvements for free (multiple addresses, proper detection of
multiple payment ids, obeying the prompt settings).
Also fix a few things, such as using uint64_t instead of int
for block heights, actually checking whether getting blockchain
height succeeded, etc.
|
|
|
|
RingCT outputs will be 0 in the vin, so we need to get the actual
amount from elsewhere.
|
|
|
|
|
|
|
|
|
|
|
|
Changed the wording from "from 0 to maximum available" to "from 2 to maximum available".
May I also suggest putting in a number rather than "maximum available" and also clarifying that mixin = 0 is still allowed if the user has unmixable outputs (dust), which he wants to "undust" using sweep_unmixable (comment from dEBRUYNE-1 ).
|
|
set confirm-missing-payment-id 0|1
Defaults to true.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This change adds the ability to create a new unsigned transaction
from a watch only wallet, and save it to a file. This file can
then be moved to another computer/VM where a cold wallet may load
it, sign it, and save it. That cold wallet does not need to have
a blockchain nor daemon. The signed transaction file can then be
moved back to the watch only wallet, which can load it and send
it to the daemon.
Two new simplewallet commands to use it:
sign_transfer (on the cold wallet)
submit_transfer (on the watch only wallet)
The transfer command used on a watch only wallet now writes an
unsigned transaction set in a file called 'unsigned_monero_tx'
instead of submitting the tx to the daemon as a normal wallet does.
The signed tx file is called 'signed_monero_tx'.
|
|
|
|
|
|
They're confusing, as people think it reports their balance.
|
|
Change was not taken into consideration
|
|
We keep 1, 2, 3 multipliers till the fee decrase from 0.01/kB
to 0.002/kB, where we start using 1, 20, 166 multipliers.
This ensures the higher multiplier will compensate for the
block reward penalty when pushing past 100% of the past median.
The fee-multiplier wallet setting is now rename to priority,
since it keeps its [0..3] range, but maps to different multiplier
values.
|
|
|
|
This ensures it's hard to mix files up
|
|
Saves on space, and on some pointless hex conversions
|
