| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
2d17feb0 factor STL container serialization (moneromooo-monero)
|
|
|
|
|
|
|
|
Thanks to kenshi84 for help getting this work
|
|
|
|
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
|
|
|
|
3dffe71b new wipeable_string class to replace std::string passphrases (moneromooo-monero)
7a2a5741 utils: initialize easylogging++ in on_startup (moneromooo-monero)
54950829 use memwipe in a few relevant places (moneromooo-monero)
000666ff add a memwipe function (moneromooo-monero)
|
|
|
|
|
|
|
|
54a4c1cb cryptonote: do not overwrite const data (moneromooo-monero)
|
|
47c0948a Implement missing miner functions on FreeBSD (Vasil Dimov)
fdb5bd16 Remove unused variables and fix typos in comments (Vasil Dimov)
|
|
|
|
It's nasty, and actually breaks on Solaris, where if.h fails to
build due to:
struct map *if_memmap;
|
|
cryptonote::miner::get_system_times(): Fetch the system's total and
idle time using sysctl kern.cp_time.
cryptonote::miner::get_process_time(): Use the same implementation as
Linux and OSX, the times(3) function conforms to POSIX.1 and is
available on FreeBSD.
cryptonote::miner::on_battery_power(): Try to fetch the battery status
using sysctl hw.acpi.acline. If that fails (if ACPI is not enabled on
the system), then try querying /dev/apm.
|
|
|
|
c4136134 miner: always update block template when starting (moneromooo-monero)
|
|
|
|
This fixes using the previous address when starting mining,
then stopping and restarting with a different address
|
|
|
|
|
|
|
|
|
|
651baaec wallet: add encrypted seed functionality (moneromooo-monero)
|
|
20256b7c Fix AC power supply detection on Linux (Guillaume LE VAILLANT)
|
|
This uses luigi1111's CN_Add method.
See https://xmr.llcoins.net for details.
|
|
The /sys/class/power_supply/*/present file usually does not exist for
AC power supplies.
|
|
|
|
5a283078 cryptonote_protocol: large block sync size before v4 (moneromooo-monero)
7b747607 cryptonote_protocol: kick idle synchronizing peers (moneromooo-monero)
|
|
In case they dropped off downloading for any reason, they'll get
sent to download again.
|
|
Really unique yet consistent spelling mistake
|
|
d1f204d6 miner: set thread name before logging (moneromooo-monero)
|
|
980e476c cryptonote_basic: fix silly CLANG warning about not emitting function (moneromooo-monero)
|
|
c8640a3d difficulty: fix misleading comment (Guillaume LE VAILLANT)
|
|
87b5ede9 miner: fix ignoring battery from command line (moneromooo-monero)
|
|
|
|
|
|
Why this was initialized properly before I have no idea, but
it is not anymore. Fix it, which fixes syncing in release mode.
|
|
|
|
158c3ecf core: thread most of handle_incoming_tx (moneromooo-monero)
f57ee382 cryptonote_protocol: retry stale spans early (moneromooo-monero)
90df52e1 cryptonote_protocol: light cleanup (moneromooo-monero)
84e23156 cryptonote_protocol: avoid spurious SYNCHRONIZED OK messages (moneromooo-monero)
5be43fcd cryptonote_protocol_handler: sync speedup (moneromooo-monero)
|
|
214fd81e some include cleanup (moneromooo-monero)
|
|
cb0b5594 Move OpenAlias console input back from libs (moneromooo-monero)
|
|
94717021 fix on_battery_power for linux (Ryan Mehta)
|
|
A block queue is now placed between block download and
block processing. Blocks are now requested only from one
peer (unless starved).
Includes a new sync_info coommand.
|
|
|
|
|
|
|
|
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.
|
|
They were set as uint8_t, which boost was apparently treating
as a character type, rather than a numeric type
|
|
fix ac/battery linux
|
|
Implements miner::get_system_times, miner::get_process_time and
miner::on_battery_power for OSX so that background mining works on OSX.
|
|
fix a cmakelist
|
|
bff90264 Add expected total reward to RPC "getblocktemplate". Only works from V5 fork onward - returns 0 before that block. (assylias)
|
|
Only works from V5 fork onward - returns 0 before that block.
|
|
|
|
- Performance improvements
- Added `span` for zero-copy pointer+length arguments
- Added `std::ostream` overload for direct writing to output buffers
- Removal of unused `string_tools::buff_to_hex`
|
|
5b632468 core: fix blob size cache, and reenable hash and blob size caches (moneromooo-monero)
|
|
a38343bf miner: add a debug log in pause and resume (moneromooo-monero)
|
|
|
|
|
|
|
|
Looks like it doesn't work on win64
|
|
|
|
An idea from smooth
|
|
|
|
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).
|
|
BlockchainDB functions virtual again to avoid missing symbols error
|
|
Fix two small typos as mentioned by reddit user nthterm.
|
|
2c468dd4 allow user I/O in millinero, micronero, nanonero, piconero (moneromooo-monero)
|
|
7a44f38a Add support for the wallet to refresh pruned blocks (moneromooo-monero)
da18898f ringct: do not require range proof in decodeRct/decodeRctSimple (moneromooo-monero)
b49c6ab4 rpc: add a default category for daemon rpc (moneromooo-monero)
f113b92b core: add functions to serialize base tx info (moneromooo-monero)
6fd4b827 node_rpc_proxy: allow caching daemon RPC version (moneromooo-monero)
b5c74e40 wallet: invalidate node proxy cache when reconnecting (moneromooo-monero)
|
|
|
|
That is, information without signatures (for v1) nor range
proofs and MGs (for v2)
|
|
should fix a cross dependency betewen cryptonote_basic and
blockchain_db
|
|
|
|
a427235e core: add a missing newline on a string to be logged (moneromooo-monero)
b6a2230e unit_tests: fix minor blockchain_db regression (moneromooo-monero)
c488eca5 hardfork: tone down some logs (moneromooo-monero)
|
|
a493c0b1 BACKGROUND_MINING_MINER_MONITOR_INVERVAL_IN_SECONDS was odr-used, so required a definition. (Dion Ahmetaj)
|
|
a5a0a3c8 core: updates can now be downloaded (and SHA256 hash checked) (moneromooo-monero)
216f062e util: add a SHA256 function (moneromooo-monero)
4bf78492 mlog: only silence errors for net by default, not net.* (moneromooo-monero)
d282cfcc core: test key images against validity domain (moneromooo-monero)
efb72e74 http_client: add a couple consts (moneromooo-monero)
f640512c Optionally query moneropulse DNS records to check for updates (moneromooo-monero)
e3cae4ae core: display any fork warning at startup too (moneromooo-monero)
969ad710 dns_utils: fix first checked DNS entry being ignored (moneromooo-monero)
08c3f380 util: add a vercmp function to compare version numbers (moneromooo-monero)
e8a7525c dns_utils: factor TXT record loading code from checkpoint code (moneromooo-monero)
|
|
|
|
Added an extra path to check for linux power supply status.
Added ignore battery option. If set to true, then when we can't figure out
the power status, we'll assume the system is plugged in.
|
|
required a definition.
Instead of adding a declaration to cpp file, I changed it to non odr-used.
|
|
|
|
was resetting bg mining enabled instead of started. Upped the miner threshold. Also moved setting of enabled on start above miner thread creation since starting with true, then stopping, then starting with false resulted in race condition.
|
|
|
|
|
|
|
|
order to be better able to handle failure states.
|
|
plugged in.
|
|
started, and added an explicit sleep in that block to wait for some mining to occur.
|
|
mining::stop then mining::start, idle logic is re-run instead of starting immediately (if it was running before stop).
|
|
source, and CPU has been idle for some time, then begin mining to some
threshold (don't destroy the users' CPU).
This patch only supports windows and linux (I've only tested on Win64 and
Ubuntu).
The variables currently default to pretty conservative values (i.e. 20%
CPU mining threshold).
|
|
|
