Unless the address was used before or posted somewhere on the internet, it is basically impossible to know who controls it. Only web wallets will use emails to identify accounts with the service, and that is specific to that service only. It is impossible to know what wallet software the thief used or what other addresses are in their wallet. Unfortunately, your Bitcoin is probably not recoverable at all. I highly recommend that you make sure you have no malware on your computer, that you are using a secure wallet (any wallet listed on https://bitcoin.org/en/choose-your-wallet will be good), and that you have a strong password on your wallet. |
|
|
|
When you installed Armory, did you download and install Bitcoin Core? If you did not, then it is not installed, Armory will not install it for you. To install Bitcoin Core, go to https://bitcoin.org/en/download and download it. Then install it. Then run Bitcoin Core like any other program that you use. |
|
|
|
|
Is Armory fully synced? If you look in the bottom right hand corner, does it say "Connected (468585 blocks)" (does not have to be 468585 exactly, but it should be more than that since that is the number of blocks from a couple of minutes ago).
Can you please post the log files?
|
|
|
|
|
Did you install Bitcoin Core? Is Bitcoin Core fully synced? If you did not do both of those things, Armory will not be connected to the network and will not be able to see any of your transactions.
|
|
|
|
Is it also possible to use the public key directly as address instead of the bitcoin address? I ask because this may be useful if you want the sender to attach a private message to the receiver.
Yes. Many old transactions did this since Bitcoin used to be pay to IP (ask an IP address for a public key). However you will need to ask the person you are sending to to give you a public key and many wallets do not have this information readily available. |
|
|
|
|
Yes. If you setup other nodes you can use the -connect option to have those nodes connect to another one running a regtest network. You will have to explicitly tell each node what IP address and port to connect to since nodes in regtest mode will not attempt to initiate any connections unless explicitly told to do so.
|
|
|
|
The Dashboard confirms that Armory is online. I am connected (288k blocks).
You are not connected. The blockchain currently has 468585 blocks. If you don't have all of the blocks, you will not see your transaction. Make sure that Bitcoin Core is fully synced. Stop Armory and run Bitcoin Core and let it sync. Then stop Core and run Armory normally and you should see your transaction. |
|
|
|
And if I understood it correctly, this situation also disincentives people from the "a new receiving address per transaction" privacy practice because the more different addresses you got the bigger the total size of the transaction will be and hence the more fee you will pay.
No, reusing addresses will not help. To the network and the blockchain, addresses are completely meaningless. What matters are transaction outputs. When you receive Bitcoin, a new transaction output is created. This happens regardless of whether you used the address before or not. When you spend, you have to spend from those outputs. That means that spending from 100 outputs (payments) that are associated with 100 different addresses is going to be the same size as spending 100 outputs (payments) associated with the same address. Reusing addresses and using different addresses does not matter with this. |
|
|
|
So lets say in the Bitcoin network (I guess you are more familiar with that than with LTC) there hasn't been any block minted in 30 minutes, the current block is 468359 and everyone is mining block 468360. They have all been mining for 30 minutes but then I broadcast a high fee transaction (900 satoshi/Byte) and my transaction gets included in block 468360. 1. How does that work?
Once one set of potential blocks have been searched through (i.e. one set of transactions and the nonce and extranonce have been exhasuted), the transactions are reselected a new block is built. When they reselect the transactions, yours may be one of those that is selected. 2. After I broadcast my transaction do they all start their mining over?
No, they won't stop to include every single new transactions. Your transaction and others like it are only included when one set of potential blocks has been exhausted and the transactions are reselected. |
|
|
|
|
When you are hashing with the script, you are hashing the bytes. When you use a different tool for hashing, you are hashing the string with the hexadecimal representation of the bytes. The bytes are what need to be hashed, the string is only to make it human readable.
|
|
|
|
|
Any fork will maintain the blockchain prior to the fork, so any coins from before the fork will always exist on the two blockchains created by a fork.
How a fork will affect the value of a coin cannot be known.
|
|
|
|
Certainly. The consensus rules change with any fork, be it hard or soft. All planned forks to date have been soft forks. To see what these are, look at the list of BIPs: https://github.com/bitcoin/bips/blob/master/README.mediawiki. Anything listed as "Consensus (Soft fork)" and has a status of "Final" are all of the BIPs for soft forks that have already been activated. |
|
|
|
|
Post the transaction ids.
|
|
|
|
How does then for example viaBTC's transaction accelerator works? I know they change the order of transactions (include) before the block is found but still, wouldn't that mean that after they add a new transaction they would have to start their work over?
Yes. When a transaction is "accelerated", all that happens is that the transaction's selection priority is changed. So the transaction is only actually included in a block the next time they need to reselect the transactions, which happens once the nonce and extranonce fields have been exhausted. (Not how it works but) Let's say viaBTC finds a block but still want to include one more transaction into that same block, can they do it? 1. Would the block still be valid after that?
No, the block would now be invalid. 2. Would it be a very miniscule thing to do? 3. Or would they have start the whole mining of that block again and it would take them the same time that it takes to mine any other block. (hope I'm not asking the same question)
They would have to do the same mining process again as they have built an entirely new block by including a single different transaction. |
|
|
|
|
No. It is all secured by the block hash that you find. The hash of all of the transactions (called the merkle root) is included in the block header which is what you hash when mining. If you change any transaction (change a transaction, remove a transaction, add one, reorder them, etc.) the merkle root will change and that will change your block hash.
|
|
|
|
Shut down Bitcoin Core. Find the Bitcoin Core datadir. Delete the file named mempool.dat. Open or create a text file named bitcoin.conf (.conf extension, no .txt extension). Add the following line to the file: Now start Core. You should be able to do Abandon Transaction now. Once you create your double spending higher fee transaction, stop Bitcoin Core and remove the line you added to the bitcoin.conf file. |
|
|
|
|
Download and install Bitcoin Core. Run Bitcoin Core and let it sync. Once it has fully synced, then start Armory. It will do its own syncing off of Core and that should be it. Make sure you use the latest version of Armory, 0.96. If you run into issues, I suggest that you upgrade to our 0.96.1 testing version which has some bug fixes on top of 0.96.
|
|
|
|
|
Show Posts
