This line caught my eyes: 2018-10-25 12:22:16 (ERROR) -- ArmoryQt.py:1198 - 8 attempts to load blockchain failed. Remove mempool.bin.
Can you verify the data directory (of core) is set correctly ( G:\\xjFuck_database\\Home\\blocks) ? Also, can you confirm that bitcoin core is completely synced? You might also check the permissions. Armory might not be able to access this directory because of wrong permissions (not sure about that). |
|
|
|
Now, what is the exchange where I can sell these waves tokens called "bitcoin" for real bitcoin?
These tokens called 'bitcoin' are worthless. They are not related to bitcoin at all. Someone just named a senseless token 'bitcoin'. Probably to scam other people. It is the same approach as with all of these shitforks (bitcoin cash, bitcoin gold, bitcoin shit, bitcoin XXX, etc...). All of them have one in common: They are using the name of bitcoin to attract newcomers. That's their way of making money. Keep away from any tokens / forkcoins which have 'bitcoin' in their name. There is only one bitcoin (BTC). Anything else which uses the name of bitcoin is shady and should be avoided. |
|
|
|
[...]
but as i said it is a good idea to keep a backup just in case something went wrong. in your case make a copy of your wallet file and write down your private key(s) on a paper (eg. printing them in which case make sure your printer is not storing them in its memory).
your wallet file is here: %appdata%\Electrum\wallets
and your private key can be found either by right clicking on each address in your "Addresses" tab and selecting private key then entering your password. or you can go to "Wallet > Private keys > export" from the menu and export all your keys.
Thanks. I want to ask one more question, how to make a backup? Did you even read the post you have quoted ? It is pretty hard to explain it even more detailed. I guess you can figure out yourself how to copy a file on windows.. If not, take a look here. Note, that your wallet format is deprecated. It is recommended to use (modern) HD-wallets. This will save you a lot of time in case of something going wrong at any time in the future. |
|
|
|
FYI:
I Said MANY ALTs have cheaper transaction fees, I only list two.
True. And all of them are way less secured than bitcoin. I'd rather pay a few cents to have a transaction being secured, than paying the fraction of a cent to have 0 protection. FYI2:
Bitcoin can never truly be a Global Currency as it is too scarce making even the 8 digit below zero nonsense cost too much for the majority of the world populace,
Zeit & Mint both have a large enough quantity to be global currencies and both already exceed bitcoin's onchain capacity.
1 satoshi is too expensive ? Currently that's 0.00006481 $. Also, making the minimal unit smaller only requires a softfork (e.g. to divide 1 satoshi into 1.000.000 units). This can always be done when necessary. Those shitcoins are both worthless. A coin without any use (security = 0) can never be a 'global currency'. FYI3:
LN is a 3rd party offchain payment system
3rd party ? It's called open source development. Anyone is free to contribute. Additionally, LN is just ONE implementation of HTLC's. Why do you even post in this forum, it's a discussion about Bitcoin and lightning. Nobody cares about your shitcoin.
This. |
|
|
|
What real world problem is bitcoin solving rn?
Trustless, world-wide and cheap money-transfers without any middlemen. Just a transaction between you and the recipient. Also, you are the only one with access to your money. No entity which can freeze your money/transactions or revert anything. and to what extent?
Completely. |
|
|
|
|
The 3 big problem i see with centralized exchanges are:
1) Security: The whole security of your coins on this exchanges relies on the exchange itself being safe. Since you don't have control over the private keys, you can't do anything to protect your coins (since you essentially don't own any coins at this moment).
2) Monopoly: A big exchange (e.g. coinbase, bittrex, binance) have a lot of power in the market. And that's extremely bad for a decentralized eco system. The people behind these exchanges can easily manipulate the price of an asset in both directions (for example: insider trading before a listing on on of these exchanges can make a shit ton of money).
3) Trust: I don't know how to justify that these exchanges have control over such a big portion of the circulating supply. A lot of people are completely trusting them their money. I wouldn't want to trust anyone to hold my money. I'd rather have full control myself (over the money AND the trades happening).
In the end, a proper, user-friendly and decentralized solution is inevitable. At least if the whole eco system wants to move forward.
|
|
|
|
AFAIK, it's closed source, released by microsoft and it clearly states they can actually collect data and send it back to microsoft when you read the TOS...
i don't know what ToS is. maybe it is like bug/crash report?! ToS = Terms of Service. Microsoft is not only collecting data when software is crashing. They are always collecting data to 'enhance user experience'. Everyone has to decide for himself whether he actually want's to be part of microsoft's data-collecting actions. Being open source doesn't reduce the risk in using software developed by microsoft. Microsoft seems to always produce more buggy and less secure software than anyone else (e.g. windows, bitlocker, ... ). I, personally, wouldn't use a wallet which requires me to install .NET. Especially not a wallet which claims to be privacy orientated. |
|
|
|
The most important step probably is to follow mocacinno's advice.. clone your disk !! A recovery software might damage the filesystem / files on your hard drive. It is always better to make an identical copy (to work on it). Never try anything on the original drive. Make an image -> Work on the image. If you broke your image, delete it, clone your drive again, and go on using the new image. The probability of recovering missing files depends on the usage of the disk after you have abandoned mining. Did you use the disk frequently ? If so, the chances are pretty low. Did the disk just lay around somewhere ? Chances would be high in this scenario. I'd start with some keyword searches (e.g. wallet.dat, wallet, core, bitcoin, bitcoind, satoshi, ...). This would be the fastest/easiest approach. If this doesn't work, you might use a fresh image for pywallet ( https://github.com/jackjack-jj/pywallet). Pywallet also has a relatively good chance to find old wallet files on a disk (please only with your image, never with the original drive!). Feel free to keep us updated. We'll gladly help where we can. |
|
|
|
As I understand dynamic fee should be calculated by already formed tx, i.e. how many inputs, outputs, so from here we can find the size of tx that can be used for fee calculating.
You are right with the fee (in satoshis) being set depending on the inputs and outputs. But since the amount of inputs and outputs do have an direct influence on the size and the number you get when calling getfeerate is a feerate (sat / KB; depending on the size), it is perfectly fine to do it this way. So, following Abdussamad's advice is the correct way to get the fee rate. You'll simply have to set this feerate in your transaction. Since the unit is sat/ KB, the actual total fee (satoshi) will be calculated when creating the transaction (based on the transaction size). |
|
|
|
though I'm curious... can a pool member broadcast the solved block as his own to claim full reward for himself?
No, he can't. The block is being built by the pool operator. The share a miner (inside of the pool) is working on has the block reward (to the operators address) already included. So, effectively you can not contribute to the pool while on the same time trying to mine for yourself. |
|
|
|
well apparently it is against some moderators rule to question this apparent attempt to hack private keys - so carry on! seriously hope this never succeeds.
This tool is to bruteforce private keys. Bruteforcing means to try out every possible combination. You can't forbid someone to try out each number (since private keys are basically just big numbers). The keyspace is big enough for a randomly generated private key to be never found by such a bruteforce tool. This is not hacking in any way. It is just 'trying out numbers' (and it will not succeed in finding private keys generated by proper wallets/clients/etc..). |
|
|
|
There are many misunderstandings regarding the "block lattice" model and Nano in particular.
Nano has, in reality, two confirmation times: one "in the case that everything goes well", which is nearly instant (1-2 sec.), and another one, which is "in the case of a conflict", which is about ~1 minute. This is due to the fact that when the DPoS algorithm detects a conflict in the DAG, then the nodes proceed to vote which transaction goes through.
But as you can never be sure that a conflict won't appear some seconds later - maybe a "legit transaction" is only late because of latency issues - then it's highly risky to accept a transaction with an "instant confirmation". It may get rolled back.
The hyped instant confirmation at Nano has, thus, equivalent security to the 0-confirmation-transaction in Bitcoin, which is also (almost) instant!
[...]
This is an interesting analysis but actually incorrect - your post has been linked in the Nano subreddit where the developer has responded indirectly to your claims. You can check it out here - https://reddit.com/r/nanocurrency/comments/9qdpkw/relevance_of_comment_on_nanos_instant/Regarding the statement about two confirmation times: From a technical standpoint, it is wrong. Propagation of votes in this specific block-lattice-based coin does happen within a few seconds. So there can't be a conflict happening within the next minute. The only case where this could be a feasible attack would be when the majority of the network does not vote (or is seperated from the rest of the network) and then after a given time (e.g. 30 seconds) does publish a countering vote. But this could easily be spotted if you look at the vote weight and if you have a full node running. So.. in the first few seconds there is a decision whether it is confirmed (almost 'instantly'; up to 3 seconds) or will take up to 1 minute until there might be a confirmation. But a scenario where a transaction is confirmed after 5 seconds, with opposing votes 20 seconds later can not work. You might as well read the link posted by chrissyg1, which probably leads to the same conclusion. |
|
|
|
You can't achieve all of this functionality in core. Core is a wallet. Not a hot-/cold- wallet seperation and deposit software. You'll need to build your software around utilizing core's RPC's. 1. Create bitcoin address which forwards 30% send to it to hot wallet, other 70% to cold wallet.
Simply check the received amount and either (1) instantly create a new transaction (not recommended) or (2) batch transactions until you have X, then split them as you wish using sendmany. 2. Send bitcoins from wallet(hotwallet) to other users.
A simple RPC call to generate a transaction is enough here. 3. When user paid to address created, send notification to callback_handler.
You need to use walletnotify (if you only care about the first confirmation) and/or blocknotify (if you want to track the amount of confirmations). There isn't too much work needed to achieve that. Most commands are self-explanatory and/or are very well documented. |
|
|
|
armorycpplog.txt
armorylog.txt
ArmorySettings.txt
dbLog.txt
multipliers.txt
which one?
Only 3 of them are logs. Start with armorylog and dblog. Only those two should be necessary. |
|
|
|
Dice rolls are never random.
If you knew all necessary information (exact surface conditions, air resistance, rotating speed, ..) you could predict each roll with your dice. That's far away from being 'truly random'.
That's an extreme statement. You could say the same thing about Brownian motion. In the end, it doesn't really matter if it is truly random or not. The end justifies the means when it comes to an RNG. Precisely. You could also say the same about: If you want to create the private key yourself (without any wallet), i'd suggest to boot up a live linux, let it run a few minutes, open and close random programs, and then use /dev/urandom to generate a private key: openssl ecparam -genkey -name secp256k1 -rand /dev/urandom
Both are deterministic in the end, as long as you dig deep enough (but not so deep as to enter the quantum realm). The latter being obviously more practical than throwing dice. As long as the result looks random to an outside observer, ie. does not show any bias towards certain numbers, you're golden. That is, as long as an adversary is unable to acquire the input required to (re)create the pseudo-random output. Which can be reasonably assumed for both physical dice and /dev/urandom. That's correct. I have never claimed that /dev/urandom is truly random. I just wanted to clear out the 'how to be sure that dice rolls are truly random' question. More precisely my statement was: This is way more random than your brain or any dice rolls can ever be.
And that's still my opinion. Humans tend to throw the dice in a similar motion each time. Especially with hundreds of rolls. The outcome will be less random. And the brain being one of the worst sources of entropy should be commonly known, at least if you really need a random number and are ready to spend a few minutes to read into this subject. |
|
|
|
Actually the wallet I'm running does not have a SEED, I made it using private key only. So, do I need to create a seed first and then upgrade?
Or should I import the private keys again into the version 3.2.3 without creating a seed?
Do yourself a favor and create a new (HD) wallet. This will make backups, further imports/exports, recoveries and handling MUCH easier. However, this means that you need to send a transaction to the new wallet and that your old addresses won't be under control of your new wallet anymore (still keeping a backup). I'd suggest you do the following: - Backup your wallet file and rename it to something like 'backup-2018-10-24'
- Download and install the latest version of electrum
- Open the new version and create a new wallet. Backup the new seed (non-digital, e.g. on a piece of paper, do NOT copy&paste it), and read everything carefully.
- Now copy (not move) your backup into the electrum wallet directory: press WIN-key and R, then enter %appdata%\Electrum\wallets, copy your backup into this directory
- Inside of electrum, press: File -> Open
- Choose your backup wallet. You should have 2 instances of electrum open now. One with your new wallet and one with your old wallet
- Make sure you have a backup of your new seed! Do not proceed further without having a proper (non-digital) backup.
- Now get a new address from your new wallet via the 'receive'-tab, copy it
- Create a new transaction from your old wallet to your new one, using the full amount.
- Double check everything.
You will still be able to receive BTC to your old addresses, you can simply access them by using the old wallet file in electrum's wallet directory. A full transition to your new wallet is still desirable. |
|
|
|
Using 'Accounts' inside of core is deprecated. Check https://bitcoin.org/en/developer-reference#rpc-quick-reference. If you need to handle different type of user, you'll need to create an external database and link them to addresses generated by core. The 'account functionality' inside of core does not work properly and is deprecated. Do not use and/or rely on it. |
|
|
|
You need private keys to access your coins. So, basically you need just a backup of your private keys. The wallet.dat file contains your master private key (which is needed to derive all further private keys). Therefore it is more convenient to simply backup the wallet.dat instead of backing up each private key individually. And in how many days I should take backup.
You only need to backup once (assuming you don't change your password). If you change your wallet password, a new backup is required. You don't need to back it up each X days. Just after each password change. Also make sure to have multiple copies spread. And do NOT keep all backups connected to a power source (one lightning strike could easily roast all of your hardware connected). Ideally, you make an paper-backup of your master private key (starting with xprv..). Just to be on the safe side. And how I can make recovery of my balance in both cases if my node goes down.
If your node simply crashes, your wallet.dat file shouldn't be corrupted at all. Simply start core and let it repair the database itself (it will redownload, resync, whatever is necessary..). But your private keys stay untouched. However, if somehow the wallet.dat gets corrupted, you simply need to install core (assuming its not installed) and place your wallet.dat into the data directory. Then startup core. That's it. |
|
|
|
I keep my core on an external hard disk and I feel sometimes the cable bends so the connection isn't 100%...
That's the reason mostly. Core needs a continuous connection to the hard drive when syncing the chain. Losing connection can lead to a corruption of your data, which does result in rebuilding your chainstate. long story short it's now reindexing blocks on disk... which doesn't mean downloading the whole chain right?
Yes. The files are on your hard drive (except for maybe a few corrupted). Those are being processed by core now, the missing/corrupted will be downloaded again. I can see wallet balace to 0 but there's a list of recent transactions which are right, so it's just a matter of waiting, yeah?  Yes, simply not synced yet. Nothing to worry about. always living on the edge with bitcoin! hehehehe
Not really, you just need a backup of your private keys. Then you are fine. Your private keys are needed accessing your bitcoins, not any software or file. |
|
|
|
|
Show Posts
