-
Notifications
You must be signed in to change notification settings - Fork 36.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bitcoin-Qt Export function non-intuitive #1169
Comments
This "issue" is incredibly aspecific. The export button exports the contents of the current tab as csv. I'm not sure what could be more intuitive than that. It was frequently requested, and useful if you need an exports of your addresses, or transactions, for example for tax reporting. What do you propose to make it more intuitive? Please be reminded that github issues are meant for specific problems. |
Apparently it exported public keys in this case? I didn't really look into what exactly was non-intuitive about it, but thought it should get reported for tracking rather than simply ignored/forgotten. |
It simply exports bitcoin addresses, not public keys. |
Tested it and it simply exports the listed addresses from the client ... what else should it do, seems rather obvious!? |
Closing issue (nothing to fix) |
* locks in PS * lock in governance * locks in IS * lock in ProcessGetData * locks in CMasternodeSync * centralize mnodeman.Check call * locks order in mnpayments * use current block chainTip when possible (less locks) * add missing lock in CountInputsWithAmount * fix deadlock RequestLowDataPaymentBlocks/IsTransactionValid * LOCK2 in CheckMnbAndUpdateMasternodeList, CheckAndUpdate, SendVerifyRequest * LOCK(cs) is not needed here * Decouple governance init actions from serialization Should fix this: ``` Assertion failed: lock governance.cs not held in governance-classes.cpp:117; locks held: cs_Shutdown init.cpp:200 (TRY) cs ./governance.h:195 cs governance.cpp:835 Abort trap: 6 ```
…e-of-failure travis: Dump available debug.logs and bitcoin.confs in case of test f…
40f9c8e Avoid overflow trap on reindex with debug enabled (Peter Bushnell) Pull request description: When reindexing mainnet with --debug-enabled which sets -ftrapv, exceptions are generated from an overflow in FormatDivisibleMP, this happens when Omni TXs that are in error and have the value -9223372036854775808 hit the following line in FormatDivisibleMP. https://github.com/OmniLayer/omnicore/blob/master/src/omnicore/omnicore.cpp#L196 -9223372036854775808 when negated as 9223372036854775808 is in overflow and crashes with trapv set. This was avoided in the past for a normal sync with the following commit. OmniLayer@eb8a986 This commit reverts the commit above and if the value passed to FormatDivisibleMP or FormatDivisibleShortMP is the minimum possible value then the string "ErrorAmount" is returned and the code generating the exception is skipped. Tree-SHA512: b4e5f62905145b6bb59e24071f56b2088ba659b2f751e3ee9b9da82b1eed9cd8b994257fbb7a0d36621b4c66e656b0a2e42030a9f6dbabbd039520bf165c86c4
https://bitcointalk.org/index.php?topic=78301.msg874450#msg874450
The text was updated successfully, but these errors were encountered: