|
Those transactions are real, but the service is most definitely a scam. You are pretty much guaranteed to be scammed as an "bitcoin multiplier" service is completely unsustainable and only exist to get people to send scammers money. The transactions that they list are legitimate transactions, but are likely to be random transactions, or transactions which the scammers made themselves just to make the service look legitimate.
|
|
|
|
My armory shows "Connected (458598)" in the bottom right corner, but as of right now we are already at Block 458617. It seems that it does not sync for some reason what might be the reason for my problem above.
Any ideas?
Restart Armory. Watch the ArmoryDB window (a command prompt window that will have some output) that appears and your current block count in the bottom right hand corner of Armory. When you want to send, make sure that the block count is up to date and that there is no error in the ArmoryDB window that says anything like "Disconnected from Bitcoin node". If you do see that error, or the ArmoryDB window has disappeared, restart Armory, check those again, then send. Repeat until you are able to send.
The bug that is causing this issue has been fixed for 0.96. The 0.96 testing builds will be out soon, after goatpig finishes implementing RBF for 0.96.
|
|
|
|
I have this same problem when i have MultiBit wallet. I make backup of wallet.dat file and later i have question what i have to do to bring my wallet back.
With MultiBit it is easy - you have to install Multibit Classic, then just copy -> paste your old wallet.dat to %appdata% folder with Multibit, and wait for actualization.
Multibit does not use wallet.dat files. Attempting to use a wallet.dat file with Multibit will not work. |
|
|
|
|
You will have to use Bitcoin Core because no other wallet uses the wallet.dat format. Furthermore, the wallet format has changed over time, and only the latest version of Bitcoin Core will work with all of them. Just download and install Bitcoin Core, start it and let it create the datadir. Then stop Bitcoin Core, put the wallet.dat file in the Bitcoin Core data folder, replacing whatever wallet.dat file is automatically created, and start it again. You may need to start Bitcoin Core with -upgradewallet for the wallet to work properly.
|
|
|
|
|
Instead of loading the website, you should download the website's source code from github and load that locally offline. It will still work without any webserver.
|
|
|
|
I'm running "C:\Program Files (x86)\Armory\ArmoryQt.exe" -disablewallet
-dsiablewallet is an argument for bitcoin-qt (Bitcoin Core) not for Armory. Anyways, you don't need to use that option. Restart Armory. Watch the ArmoryDB window (a command prompt window that will have some output) that appears and your current block count in the bottom right hand corner of Armory. When you want to send, make sure that the block count is up to date and that there is no error in the ArmoryDB window that says anything like "Disconnected from Bitcoin node". If you do see that error, or the ArmoryDB window has disappeared, restart Armory, check those again, then send. Repeat until you are able to send. The bug that is causing this issue has been fixed for 0.96. The 0.96 testing builds will be out soon, after goatpig finishes implementing RBF for 0.96. |
|
|
|
Not necessarily. Presumably you, as the app developer, are operating your own servers with players' account information so that you can unlock their purchases after they pay. Your server should be running its own wallet, and it can check its own wallet to see if a payment has confirmed. Still few questions:
1. Where my app can get Transaction ID to check its status? (I suppose only manual enter by user).
You should be checking it on your own servers and informing the app that the payment has confirmed. Your own servers should be handing out a new address for every single purchase so that it is easier to track people's payments to you. All you need to do is watch for transactions for each address, and then notify the app when those transactions confirm. 2. I am not sure that there is programming interface in this wallet to interact with another apps. My goal is to get payment confirmation programatically.
Again, your servers check this, and then relay the information to the app. The app should not be looking for this information itself. |
|
|
|
|
You should check whether the transaction has been confirmed, i.e. it has been included in a block.
Most wallets that you would use for this will tell you whether the transaction has been confirmed and how many confirmations it has.
|
|
|
|
Thanks, as always, for taking the time to say it simply. It really is interesting to realise that a lot of what bitcoin is is done voluntarily - though of course one has to think it is paying dividends to the maintainers at least, as it sounds almost like a full-time job.
AFAIK there are only two organizations that pay people full time to work on Bitcoin Core, MIT DCI and Chain Code Labs. MIT DCI funds Wladimir van Der Laan and Cory Fields to work on Core full time, and Chain Code Labs funds Alex Morcos, Suhas Daftuar, Matt Corallo, John Newberry, and Russell Yanofsky to work on Bitcoin Core. Everyone else works on it on their free time. So I've more or less established the de facto "who are in charge", but do they have a succession plan? What happens if these three very important maintainers suddenly disappear or stop their work (let's not say death but disappearance, maybe like Nakamoto). Is there enough information and resource for someone else to pick things up? And must the devs achieve group consensus on succession?
AFAIK, there is no succession plan. If the 3 maintainers somehow just dropped off of the face of the Earth, Pieter Wuille could still merge things and add people to have commit access (I think). Really though, there are still many people experienced with Bitcoin Core and contributing to it that they can continue working on it and improving it pretty much at the same pace as before. |
|
|
|
I did sent BTC from kraken.com, that transaction is shown as confirmed in the blockchain.
Ah, whoops. I read that part backwards. The block count does not change, it just stays at 453226.
Restarting Armory should fix the issue, briefly. Armory 0.95.1 currently has an issue where it will disconnect from Bitcoin Core every so often but you won't notice it unless you see that the block count is way off. To get it to reconnect, you need to restart Armory. Here is the dbLog.txt:
Is that all? There should be more. Unfortunately I have no clue about how to build a new version on windows :-(
Is there some kind of ETA for the binaries of 0.96? Or is there any other chance to get my BTC out of that wallet?
BR
I don't know when the testing binaries will be available. If you really want to, you can export your private keys to another wallet. Otherwise, just keep an eye on the ArmoryDB window and if it ever says something like "Disconnecting from node", restart Armory so that it will connect to Bitcoin Core properly so that you can send and receive Bitcoin. |
|
|
|
The problem is: Currently we do have 458560 and Armory does not load new transactions. Unfortunately I sent some BTC to my Armory BTC Address yesterday and those BTC do not show up :-(
What can I do?
When you sent the Bitcoin, did you receive a message about the transaction broadcast failing or timing out? After you leave Armory running for a while, do you notice that the block count it reports falls behind the real block count? Can you please post your dbLog.txt file? I believe the issue you are experiencing is a known issue and has already been fixed for 0.96. Goatpig will be putting out the 0.96 testing builds once he finishes implementing RBF, which should be in the next couple of days. If you know how to build software, you can pull the latest development version from the dev branch of the github repo and build 0.96 yourself to use. I also tried to "Let Armory run Bitcoin-code/bitcoind in the background", but in that case the armorydb.exe windows does not show up and it is scanning transactions for days (always saying 1 second left)
Yeah, don't do that. It's almost guaranteed to not work if you have auto-managed bitcoind on. |
|
|
|
|
All transactions to and from that address have already confirmed. Please stop spamming the same question everywhere. Continue to do so and you will be banned from posting in this forum.
If you do not see that this transaction is confirmed in your wallet or service, contact the wallet provider's or the service's support. Users here cannot really help you with that; the transaction is already confirmed so it is not an issue with the network or with the blockchain.
|
|
|
|
|
It is a size indicator opcode. It means that the next n bytes are to be pushed to the stack as one element. Otherwise a script interpreter wouldn't know that the next 65 or 33 bytes represented a public key and had to be pushed to the stack as such.
|
|
|
|
|
Now while that sounds expensive, how much money are you forwarding every single day? What percentage of the amount of money that moves through your service becomes fees?
Also, why the hell do people keep pricing Bitcoin related things in non-Bitcoin units? It is both extremely confusing and extremely deceptive with the constantly fluctuating exchange rate.
|
|
|
|
|
Can you post your armorylog.txt and dbLog.txt files which contain the times when the the "tx broadcast time out" errors occurred? I am investigating the issue and need the log files to confirm my hypothesis.
|
|
|
|
|
Those who have are experiencing this issue, can you please post your armorylog.txt and dbLog.txt files found in the Armory data folder? I am investigating what is causing this problem, and I will need to see both log files to confirm my current hypothesis.
|
|
|
|
|
Show Posts
