Stop right there, educate yourself before doing something unwise...
The article posted by Pmalek is talking about how to import private keys into electrum... But like i said: i don't think it's a good idear to do this (safety wise)... You're actually using a very safe solution, and using the seed phrase to restore your wallet on a desktop wallet is taking a huge step back in the security department for a lousy couple of bucks...

To answer the questions in this post:

• As far as i know, you can't export your master private key, nor the derived keys from a trezor wallet... It isn't a feature of a hardware wallet because it's a bad idear to do so
• You CAN restore your wallet on electrum using the seed phrase by setting the proper derivation path... However, it's not a good idear to do so
• uploading private keys to a web service is never a good idear

AFAIK, you can't export your xprv or derived private keys from a trezor, however, you should be able to use the seed phrase and restore your wallet on a compatible software wallet like electrum. At this point, you should consider your hardware wallet to be compromised!

That being said, i personally feel this is a bad idear! I always advice people to move away their funds from online wallets and exchanges and store their funds using a hardware wallet.

Safety-wise it goes like this:
(airgapped, non HD, recent core wallet) > (airgapped HD wallet) > (hardware wallet) > (paper wallet) > (recent, community supported desktop wallet) > (safe, wellknown online wallet) > (exchange or casino wallet)

Sure, you can start using an exchange wallet and receive peanuts in forked altcoins, but would you compromise your security for a measily couple of bucks? I'm sure i wouldn't...

I have claimed a couple of forks with my trezor, and eventough the process didn't work flawless in the beginning, it did work in the end... Trezor doesn't support all forks, but my personal opinion is that if a fork is actually worth something (and not a mere money-grab by the developers), trezor will sooner or later support them and allow you to use the forked unspent outputs in a safe way...

My gut feeling would say that you're talking about a bitcoin core wallet, since the wallet's name is wallet.dat, it's a file from 2015 AND you're talking about pywallet.

You don't need to unlock your wallet to see the balance, however, there are 3 ways to see the balance:
1) use core to load the wallet.dat and wait untill core syncs... This will probably take several days, maybe even weeks
2) use pywallet to export the private keys and import those in an SPV wallet like electrum
3) use core to load the wallet.dat, use the console to list all addresses, import those addresses into an SPV wallet to create a watch-only wallet

Why don't you want to use pywallet? Is there a reason, or is it just because you don't want to invest time in setting everything up? Pywallet would be by far the fastest way to be able to spend those funds... Option 1 will take ages and option 3 is a watch-only wallet...

EDIT: i just realised you probably don't want to use pywallet because you forgot your password... Maybe this tool will help?
https://github.com/gurnec/btcrecover

If you can find your transaction on an explorer like blockchain.info, it means that it has been succesfully broadcasted. However, it's possible localbitcoins didn't pay an appropriate fee.

Mind telling us how much sats/byte they added?

Lately the appropriate fee increased to ~35 sat/byte... If they didn't add an appropriately high fee, the miners won't have a lot of incentive to add your transaction to the block they're trying to solve. The less miners that are adding your transaction to the block they're trying to solve, the lower the odds of your transaction ending up in a valid block.

There are always options to speed up the confirmation:

• If the tx is opt-in RBF, localbitcoins should be able to increase the fee (usually works)
• localbitcoins can double spend the unspent outputs used as an input for your transaction (only small odds of working)
• you can attempt a CPFP (this will cost you some money) (usually works)
• you can pay a miner to include your transaction in the block he's currently trying to solve (usually works)
• or you can buy a cup of coffee and just wait it out (usually works if the fee localbitcoins added isn't tooo low)

I'm buying a new house, so i'm cutting corners... One of these corners will be to stop leasing a dedicated server... This is why i'm selling 2 domains:

• unblur.ninja
• lightning.photos

Included is the sourcecode of the script that's currently running... I'll only sell one copy and you have all rights to use, edit or sell my work, but i reserve the right to run a copy of the script for myself in the future. No support will be given tough, you buy the script as-is. Upon request, an admin demo account can be delivered!
The script has cost me dozens of hours to write, so i won't sell it for a couple bucks.

prereqs:

• Dedicated server OR large vpn
  
  • At least 0.5 Tb HDD, preferably 2 disks in RAID1 or and SSD (cached) configuration
  • At least 4 (v)Cpu's or threads
  • 4 Gb of ram
• You'll have to run core, compile c-lightning and lightning-charged... So you'll need some basic knowledge on how to do this
• You'll need some basic *nix management basics, since this puppy will only run on linux (preferably an ubuntu LTS)
• You'll need an account @ namesilo, because that's my current registrar and pushing a domain between two users of their service is supposed to be painless (namesilo accounts are free... And you're welcome to push the domains to any other registrar afterwards, but at this point, it's no longer any of my business)

I'll go first for very green trusted, longtime members, sr+ who can sign a message with an address staked a long, long time ago... For anybody else: I'll either go last OR we'll use an escrow (it's up to you to decide... We can split the escrow fee).

Make me an offer i can't refuse (payments accepted in BTC, LTC, ETH, XMR,.... Or using a couple of lightning invoices )

Next to DdmrDdmr's remarks (with whom i agree), i'd like to point out one/two other flaw(s) in the OP:

First:
A hash is a one-way function, you can't store data in the form of a hash... A hash does not store data. You can't decrypt a hash using a public key...

Second:
Altough there is nothing stopping you from encrypting the data you store in a block in a blockchain, most of the current crypto currencies do NOT encrypt the content of a block... In bitcoin's case (for example) anybody can parse all blocks in the blockchain, sure you need the public keys to verify the signatures, but those public keys are included in the transaction spending the unspent outputs... Offcourse, only the person who has access to the private key can create the signature...

@OP: there is a difference between hashing, encrypting and signing...

I clearly stated in my previous post that the person who sent the OP these dust outputs would be able to see if he used these outputs together with other outputs to create new transactions, but that's about it... Since he already said that he wasn't doing anything illegal, it looked more like a statement to me (he doesn't like people trying to decrease his pseudo-anonimity)...

In this particular case, if he's fine with somebody being able to identify several addresses as belonging to the same wallet, i feel my advice is still valid and he should be able to combine all the dust inputs and try to make a profit.
IF you don't want your addresses to be linked together, Carlton Banks is correct: you shouldn't use these dust inputs.... Or at least have a solid plan on how to spend them without losing your pseudo-anonimity.

The only point i'd like to raise is that if you use the dust input, it shouldn't matter if you use it to pay the miner's fee... As soon as you use it, people WILL be able to link the address containing the transferred value and the address that was funded with the dust outputs...

For example

People looking at the above transaction will be able to deduce with a certain amount of certainty that your wallet contains both address 1MyRealAddress and 1MyVeryPrivateAddress.. Even if the dust output funding 1MyVeryPrivateAddress was used to pay the miner's fee. Why? Because the miner's fee isn't sent to the miner directly. The miner adds a coinbase transaction funding his own address. In order to determine the value, he subtracts the sum of values of the outputs from the sum of the values of the inputs of every transaction in the block he is solving and adds 12.5 BTC (untill the next halving). Since the miner fee isn't payed directly to the miner, anybody analysing the transaction WILL be able to link the address with the dust to the other addresses whose funding unspent outputs have been spent

First rule of being a newbie on bitcointalk: read the rules & stickies:
Lauda has invested a lot of time into writing a long post that answers your question in detail, it can be found at the very top of the subforum you posted this question in, it even has a special icon next to the post that makes it obvious it should be read: https://bitcointalk.org/index.php?topic=1629118.0

This being said: if your sole reason for visiting bitcointalk is to make money, please log out and leave... This is a community for crypto-entousiasts, not an earning platform. If you're here to learn about crypto, help other people, create crypto-related services or make friends with other crypto-entousiasts: you are welcome to stay  , if you make a little bit of beermoney on the side, that's a nice extra... But please refrain from spamming the forum with ico bullcr*p without adding anything substantial to the forum.

that's a completely different pow algorithm... In this discussion, it doesn't matter what ETH miners think or do, their gear can't influence BTC network's hashrate one way or another...

That being said: I have only looked at the hashrate graph very briefly, but it seems the hashrate has dropped <20% recently. This drop wouldn't be sufficient for a 51% attack, unless the attacker already had loads of asic's that weren't hashing on the bitcoin network to begin with...


Maybe it's the other way around? Because of the price drop, mining became unprofitable for some of the mining farms, so they switched off their gear (or switched to an altcoin that has a better profit ratio)

Like Pmalek said: don't worry about them...
Even from a privacy standpoint it shouldn't matter... Sure, the person who sent you these dust outputs will be able to see if you use these outputs together with other outputs to create new transactions, but that's about it... Outputs funding addresses in other subwallets won't be used together anyways... Only outputs funding addresses belonging to the same wallet will be combined, it doesn't matter if it's dust or not.

You can always combine these dust unspent outputs in one transaction paying a 1 sat/byte fee and see if you can make some profit from this dust...

As mentioned above, i personally feel this is a non-issue aswell...
If you're really bothered with the current units, fork one of the open source wallets, edit the sourcecode by multiplying the number that's shown when the wallet show BTC by 100000000 and change the name to satoshi...

Most wallets even use mBTC µBTC and satoshi as potential units... Nothing is stopping you from editing the sourcecode and removing mBTC and µBTC (only leaving satoshi as potential units).

For all i care, fork bitcoin core, work with mSatoshi and call 1 mSatosi 1 cfbtcman... This way you'll be able to send 10.000.000 cfbtcman's to somebody else... Ofcourse, this other person will just see an incoming transaction funding his address with 10.000 satoshi ... Who knows, maybe your wallet will become popular...

Last but not least, the floating point values are a non issue as well, every time i develop anything crypto related, i always count in satoshi (an integer, worth 1/100000000 of a BTC). There's nothing stopping you from doing the same.

This ^^ is the point i was trying to make... As soon as you throw away blocks or transactions, you'll have to start using a trust based validation system... In my personal opinion, this isn't a good basis for validation. It doesn't matter if a group of 1.000.000 trusted individuals provide a trustbase for everybody else, it's still not good enough for me... I want to be able to mathematically verify the complete chain right from the genesis block by myself. As soon as the information is removed, there is no way for me to do this verification and in my honest opinion, at this point the system becomes broken.


Interesting point, i didn't even think about this yet, but this observation is also a valid counter-argument.

Well... Actually... In your case, you're trusting the nodes that verified the first 500.000 blocks and created a sha512 checksum...
In my opinion, bitcoin isn't about trust, it's about being able to mathematically verify everything for yourself if you want to... As soon as the data is gone, it's all about trust... It doesn't matter if there are 100000000 nodes that independantly verified the first 500.000 blocks and all of them say the sha512 hash is valid, it's all about being able not to depend on those 100000000 nodes and verify everything myself...

But, i'm not saying EVERYBODY should run a full node either. As long as several independant nodes exist, most people might be fine with running a pruned node or an SPV wallet... I'll be running a full node tough... I'm not the trusting kind.

I can be wrong here, but i think the technical implementation of this point of the whitepaper was implemented by running a pruned node...
However, if ALL nodes would run in pruned mode, it would become impossible for somebody to independantly build a valid utxo set without relying on thirth party nodes that have been running from before everybody started pruning... I think this would be against the decentralisation idear behind bitcoin.

Block x header: version;hash of header of block x-1;merkle root hash;time;nBits;nonce
Block x containing non-coinbase transaction: unspent output A funding address 1 creating unspent output B (transaction 1)

Block x+1 header: version;hash of header of block x;merkle root hash;time;nBits;nonce
Block x+1 containing non-coinbase transaction: unspent output B funding address 2 creating unspent output C (transaction 2)

Block x+2 header: version;hash of header of block x+1;merkle root hash;time;nBits;nonce
Block x+2 containing non-coinbase transaction: unspent output C funding address 3 creating unspent output D (transaction 3)

Now, at this point, you're saying it would be fine if the whole network would be fine if you'd stub off the branch containing transaction 1 and 2 (given that the other potential transaction in the same stub of the merkle tree also has al it's outputs spent in a transaction included in a block at a greater height).
However, if i ever decided to join the network, i'd have to believe the node i'm using to download the blockchain instead of verifying everything myself...

Why?
Because the seed node threw away all information about transaction 1 and 2, so there is no way i can build a merkle tree and see if the merkle hash in block x and x+1 is correct, so i'd have to take the seed's node's word for it... I would just have to believe unspent output C exists without being able to look at the transaction that created unspent output C...

If you're talking about actually throwing away complete blocks, it would become even worse... If you trew away block at height x and x+1, i'd have no way to verify if the hash of block header x+1 was correct, so i'd have to trust the seed node about the header of block x+2 (next to trusting him about the utxo set or the merkle tree's validity).

It's confusing when you're just starting out, but in reality you shouldn't focus on addresses... It doesn't matter if you derive 10.000 addresses from an xpub or just 50.
What's important is the amount of unspent outputs that are funding the addresses generated by your wallet. As soon as you want to spend those unspent output's you'll have to create a new transaction. The fee you'll have to pay to convince a miner to put your transaction in the block he/she is trying to solve depends on the size of the transaction (not the value).

Why? Because the size of the block is limited. A miner doesn't care if the value of the transaction is huge or very small, he just wants to optimize the sum of the fees of all transactions he can fit into the limited blockspace.
If you want your transaction confirmed, you'll have to make sure your fee (in satoshi per byte of transaction data) is within the top 1 Mb of transactions in the mempool... The fee needed for a fast confirmation fluctuates over time, so at times of low feerates, it makes sense to combine unspent outputs, so the fee you'll have to pay at times of high feerates is lower...

Since segwit, the blocks can be up to 4Mb in size, but the last 3Mb can only be filled with witness data, so don't worry about this untill you've mastered the rest of the protocol first (it'll only make things more confusing if you start reading about this first).

The size of your transaction increases with the number of unspent outputs you use an input and the number of new unspent outputs that'll be generated by your transaction.

So, in the end, things like hot wallet, cold wallet, number of addresses,... It doesn't matter... Your fee will depend on the type of wallet, the number of inputs and the number of outputs. It's a good idear not to create unnecessary transactions, and it might also be a good idear not to receive dust payments... If you're going to receive dust, try out the lightning network, switch to an altcoin or try to sell credit to your users in bigger chunks instead of accepting micro-payments.

Here's a neat tool to emulate the fee you'll have to pay when spending your unspent outputs:
https://coinb.in/#fees

The problem with Steganography is that you could have hidden your wallet.dat into any video, audio, image or text... 12Gb can (and probably will) contain hundreds of potential files... Without knowing which technique you used and which password you used, it's a daunting task

I guess you'll be able to improve your odds if you have a clue about:

• The time when you hid the wallet.dat... If you haven't edited the picture/movie/text/audiofile since then, you *might* be able to look at the timestamp when the media files on your disk were last modified and decrease the number of files that have to be examined drastically
• The password used... Without this password, it's a task that virtually impossible

But in my honest opinion, just sending a random on the internet 12 Gb of random data with the promise that in one of the files you're sending them, you've steganographically hidden a wallet.dat won't give you any positive results...

I've discussed this in the past, but my point of view in this matter is very simple: you can't drop any blocks...
As soon as the complete network dropped the first 100 blocks (for example) nobody would ever be able to re-verify the complete blockchain, so you'd have to start trusting other people instead of being able to verify everything yourself...

As for the OP's question: i agree with odolvlobo, it doesn't matter if people don't give their keys to their heirs... At the moment, the smallest unit is one satoshi (0.00000001 BTC), nothing is stopping the community from implementing even smaller units (for example, one  millisatoshi). The more people lose access to their funds (for example by forgetting or dying), the less BTC will be available, the higher the price will be...
It's perfectly possible to run a complete community whith only 1 BTC in circulation... Ofcourse you'll probably be paying in micro-satoshi instead of mBTC.

I suppose most exchanges do use bitcoind (an educated guess based on reviewing leaked sourcecode of some exchanges in the past). I think the amount of calls is relative, and like others have said: a lot depends on your hardware... When you run an exchange, i don't think you'll be making dozens of json-rpc calls a second... You basically need to request new deposit addresses whenever a clients requests a new address manually, and let bitcoin core call an external command on incoming blocks and transactions funding one of it's monitored addresses...

If you're storing everything on SSD's in a proper raid config, setup a good cache, a decent CPU, fast ram,... I guess you should be able to run a decent size exchange on one or two nodes.

I have tried running a bitcore explorer a long time ago, and if i remember correctly, bitcore was actually using a fork of bitcoin core with only minor changes to the sourcecode (most changes were made in order to be able to build more indexes if i'm not mistaking)... So i guess you should also be able to run a decent size block explorer using bitcoin core.

EDIT: https://github.com/bitpay/bitcoin/tree/v1.15.1-nobig

I'm sorry to hear this, but did you really say you opened up the disk's case and look at the physical cases? I don't think that's a very good idear... Things like that should be done in a cleanroom by a technical person that is trained and has experience with dissasembling harddisks... Especially spinning disks are sensitive to a lot of environment factors...

And it's not because the physical plates look good that they're not corruped...

With minor changes it sould be able to capture quite a bit of info, yes....

As for running it: it requires python 2.7, and the requests, json and collections libraries... Python 2.7 should be available for free on most operating systems