It's really simple since some darknet site addresses are known, and the site used that information to link together different addresses.

When you search an address, it will give you all of the transactions related to that address and addresses that are linked to it (linked by spend linking). It does this for every address and assigns each group (called a wallet) and id. If the wallet contains addresses known to belong to a certain company or person, then the wallet will be named so. So, by looking down the list of transactions for each of those addresses, we can see what wallets sent them money, and if any of them are known to be darknet markets.

Disclaimer: I am not a lawyer, so take my replies regarding legal stuff with a grain of salt.

The translation is a little hard to understand.

So, If I read this correctly, they think that the first block of addresses are your kraken deposit addresses.

Then the next block of addresses are addresses that have sent Bitcoin to your kraken addresses.

There is no proof that you own those addresses nor that you sent those Bitcoin yourself unless those addresses are somehow spend linked to an address that you own. Because of the pseudonymous nature of Bitcoin addresses, you could say that you did not know that those Bitcoin came from darknet markets.

Since you say that you are a cash trader on localbitcoins, did you keep good records of your trades? Do you have records such as the name of the person, amount, address that they sent to, for each trade? Maybe also transaction ids for each trade? That will probably be helpful for you in same way in court. With those records, you could try to contact the people you traded with and ask them to testify that they did in fact trade Bitcoin with you and that you aren't cashing out from darknet markets.

Chainalysis is a company that is trying to deanonymize Bitcoin. They don't offer any free services and their service requires actually contacting the company, it isn't a software. You can however, use https://www.walletexplorer.com/ which groups addresses together by spend links. The person that made that site now works at chainalysis.

---

I don't quite know how kraken works as I haven't used it before. Do you use the same deposit address or does it change for each deposit?

That is not how multisig works. Your funds will be in a multisig address, which is neither in A, B nor C. If you happen to lose A, then, if you used the normal multisig setup (2 of 3), then you can still spend the multisig funds with B and C.

Manage UTXOs meaning choosing which outputs you want to use as your transaction inputs.

You would want to do this if you want to have some privacy by not allowing two addresses to be spend linked with each other.

If you want to manage the change address, you will need to use a raw transaction. sendtoaddress will create a change address for you.

It's not just getting a digit wrong. If you don't create a change output, the change will become your fee. If you don't add correctly, you may end up having too high a fee or too low.

Accounts are not the same as wallets. They are simply used for organizing your receiving addresses. You should not use the accounting system as it is deprecated and will be removed.

Sendtoaddress should be find, so long as you don't need to manage which UTXOs are spent.

Raw transactions allow you to control everything about a transaction; the UTXOs to spend, addresses, and fees. However they are more advanced, and if done incorrectly, can result in the loss of a lot of Bitcoin.

In order to do this, we would need to know all of your Bitcoin addresses. The police would have also needed to have known this.

Next, you would need to provide an explanation for each transaction, where you got the money from and where you sent to. This can be checked through blockchain analysis. It may be possible to claim that you did not know where the Bitcoin came from when you received it.

Sometimes ArmoryDB does close when ArmoryQt crashes, so it is likely that is what happened.

mocacinno, check your processes to see if ArmoryDB is still running, and if it is, kill it.

There is a group of bitcoiners who want to hard fork the blockchain in order to increase the block size limit. However, their proposed fork does not have the majority of miners or users agreeing to it yet so it is unlikely that the fork will happen.

If Bitcoin does hard fork, it will not be possible to lose your Bitcoin. However, if the fork is unsuccessful, then a situation like Ethereum's fork could happen; there being two surviving and working blockchains post-fork. This can cause some issues, and for people looking to execute replay attacks to double their money, it could potentially result in a loss of money. If you only intend on using one of the two forks, then your Bitcoin will be safe.

tl;dr a proposed fork exists, but it probably won't happen.

Pay a higher transaction fee. Works every time.

Then you are going to have to examine the source code to see what is going on.

What coin are you using, because it isn't Bitcoin.

Try not setting staking=0, because, if you couldn't tell, it sets staking to "off" (0 is off, 1 is on)

The biggest reason against raising the block size limit is the risk of Denial of Service attacks. The idea of "just change one constant" comes from ignorant and naive people who do not understand how Bitcoin works on a technical level.

The issue is that of signature hashing for signature operations (sigops). Right now, sigops-to-verification-time is a quadratic relationship, meaning that as you increase the number of sigops in a transaction, the time to verify that transaction squares. For example, doubling the number of sigops in a transaction (as with a 2 Mb increase) will require quadruple the amount of time to verify the transaction. Bump up block size limit to 4 Mb (thus bumping the sigops limit to 4 times of what it is now) means that a transaction with the max sigops will require 16 times as long to verify as a transaction with max sigops now.

This sigops issue is one of the biggest problems when it comes to scaling as it becomes possible to cause nodes and miners to have to verify huge transactions and waste time, time in which another miner could find another block. Furthermore, to solve the issue becomes a major pain. There could be a maximum transaction size, but that isn't really ideal (although AFAIK that is what Classic decided to do). Alternatively the signature algorithm could be changed, but in a hard fork scenario, that is just a nightmare to deploy as any unconfirmed transactions at the time of deployment suddenly become invalid.

---

Edit: The 1 Mb limit was added because Satoshi was worried about spam attacks.

While blockstream is developing sidechains as an alternative scaling solution, the idea that they are going to somehow force everyone to use their sidechains is false. The sidechains are completely open source licensed under the MIT License which means that literally anyone can take the code, use it, and start their own business with it. They are literally allowing anyone to make money off of something that they created. Secondly there is also the lightning project, which is not developed by blockstream and is also open source with a few implementations of it already existing.

Additionally, while there are several members of blockstream who are Core devs, they are also the ones who founded the company. Only one of those members even has commit access so it cannot be said that blockstream controls Bitcoin Core. Granted many of those members are senior Core developers who have been actively working on the project for several years, long before blockstream was even founded, and their opinions do carry significant weight.

Lastly, those developers are not actively trying to undermine Bitcoin as some would lead you to believe. They are all doing what they think is good for Bitcoin, as are the developers of XT, Classic, and Unlimited.

---

Also, increasing the block size limit ad infinitum is not a viable solution either and, at some point, we will need to use off chain scaling solutions.

The behavior is kind of inconsistent. Sometimes it works, sometimes it doesn't. Usually it doesn't.

You should also fix that "pars" "pargs" thing. I think it prevents the db from being launched by qt.

Just delete the Databases folder inside of it.

This is the output of that command:

---

Edit, actually for some reason ArmoryDB was already running beforehand for some reason, I don't know why. I just ran that command again and it is fine.

Edit2: ArmoryQt.py works when the DB run separately.

Edit3: So it looks like the problem I was having might be that the DB wasn't starting in testnet mode, even though I ran the normal command in testnet mode. I just did the DB in testnet and Qt not, and I got the same error.

Actually segwit will break compatibility once it is deployed (so 0.13.1 and 0.12.2 and everything later). This is due to a change in transaction serialization which will cause all current versions of Armory to break with segwit. This is being fixed with my segwit compatibility PR (https://github.com/goatpig/BitcoinArmory/pull/47) that goatpig is reviewing and will probably go into 0.95.

Be patient. Theymos can take days, probably weeks, even months to respond, if he even responds at all. Be patient, stop spamming, and if you are banned, you are not allowed to post anywhere else in the forum except this ban appeal thread.

They are contained in the wallet.dat file. Backup the entire file. You can also, in Bitcoin Core, go to File > Backup Wallet and save the file in a safe location.

Yes the wallet is encrypted. You will only have to use the passphrase when you need to access the private keys. This only happens when you want to send Bitcoin or sign a message.

Only the private keys are encrypted, not the addresses nor the public keys.

Yes. Take a look at https://shapeshift.io/. AFAIK, the source code is not available though.