Yes, it downloads the full blockchain and verifies everything...

The OS doesn't matter in this case... CPU mining is dead... Wether your os is server 2015, XP, windows 95, SLES, debian, ubuntu, solaris, AIX,... Mining with a desktop will give you a maximum profit of a couple cents a year, and since you're asking how to run a miner stealthly, i can only presume you're not going to ask permission to install and run mining software on the PC's you're going to use this "trick" for, thus you'll be risking expulsion/firing/being sued for a couple cents/PC/year...

To add to this: most up-to-date mining software removed cpu mining years ago... If you really wanted to do this, you'd have to find old, buggy sourcecode of cgminer or something, then compile everything yourself... It would be a hell of a task, and your profit would be allmost 0, while your risk would be rather big.

It's a desktop wallet, so you download it, and sync it... This process can take hours to days and takes +100 Gb of diskspace. If you don't want this, you should look at an SPV wallet like electrum.

BTW: i would strongly advice to stay away from online wallets for multiple reasons.

If you want to mine BTC on an ordinary pc without the user noticing, you'll need to make sure your miner doesn't push the cpu load to 100%, and the mining process should have lower priority, so other tasks get more cpu cycles if needed... Mining with such a setup will net you a couple cents/year/PC, do you really want to risk losing your job/getting expelled/getting sued for a couple cents a year?

If you want to mine, the only way to do it profitably is by using an ASIC, but i think it'll be kind of hard to hide a last-gen asic in your computer lab (don't do this, i'm pretty sure it's illegal)

How do you conclude a fee of 120 sat/byte would be sufficient...
The transaction is 2145 bytes, the optimal fee at time of writing is 300 sat/byte (https://bitcoinfees.21.co/)
2145 bytes*300 sat/byte = 643500 satoshi's = 0.006435 BTC, since the poster only payed 0.00258, the fee is insufficient...

The full analysis + possible sollutions can be found here : http://mocacinno.com/feecheck.php?txid=eb4bbc38b826858fdfc1db05d0888b38a5484199620762d1cf7f20513664f7c9

Just a quick vouch for this thread:
- i sent the OP a PM applying for the beta tester position
- the next day, the OP replied to my PM, giving me the beta tester position
- i have tested out the OP's service
- i got the promised bounty plus a rather big tip  

As for the OP's service:
- i can vouch that he has a hidden service that is setup as a mixer
- i have tested his mixer, and everything seems to be set up properly. I have provided the OP with some feedback, and i can only assume the other testers did the same. There might be room for some little improvements to his service, but even at this moment, i think his service would be completely functional if he decided to open his doors for business right away
- i can vouch that i have never seen his mixing idear, and i must say that i think it's an innovative idear.

Due to the fact that he's running a mixer, thus provides privacy, i won't post the withdrawal txid's in public, but in case a member with sufficient trust is interested, i can provide the txid's over PM

There is no way for anybody to be sure wethere or not a certain transaction is sitting in viabtc's mempool... It's possible they rejected a perfectly find transaction while at the same time accepting a transaction whose inputs have been used in a double spending transaction.

That being said, both the first and thirth transaction look ok to me, so there's a big chance viabtc will have them in it's mempool, so there's a big chance you can accellerate them if you submit them at exactly the right moment.
The second transaction uses an unconfirmed parent, chances that this transaction is in viabtc's mempool are a little less than the chances for the first and last transaction.

The only advice i can give you is to keep on trying...

You should try to use viabtc exactly after a new hour starts, so exactly at 15:00 or 16:00 or 17:00 or 18:00.
There are other options to speed up your transaction, but they are either expensive or pretty difficult and technical, viabtc is one of the only free and easy tools, but you can only accellerate transactions that have been broadcasted recently, no double spends, no dependance on unconfired transactions, ... If your transaction does not follow this pattern, there's a big chance viabtc won't be able to accept it.

Also, viabtc only accepts 100 transactions/hour...

well, if you were the seller, and he was the buyer, this means that he was the sender of the BTC and you were the receiver.
In this case, the answers are as follows:

1) he is wrong, only the sender of the transaction is to blame when the transaction remains unconfirmed for a longer period. It's not the receivers fault, unless the sender and receiver negotiated the specific parameters that were used for creating the transaction... In other words: unless you specifically told him to use a sub-standard fee to send you BTC, it's his fault it took so long

2) as soon as a transaction has a couple of confirmations, it's final, so you should send the good as promised... Unless a certain timeframe for confirmation was agreed upon (for example, if you made a deal that specifically said the transaction has to be confirmed within 2 hours, the sender broke his promise if it took longer. If you did not agreed upon a confirmation deadline, he helt his end of the deal, albeit, it took longer as expected)

A couple of questions:

- will you be using an escrow
- i assume it's all legal stuff?
- why did you post your email OR your PGP public key... Do you mean we should either email you unencrypted, or PM you our application encrypted with your public key?

I might be interested. Depending on your answers i'll send you an application PM/email

I have a tendency to write complex things... sorry  
I'll try to explain it a big more new user friendly... I'll have to ommit certain details, so don't take this story as the complete bitcoin theory, becuase it's heavily simplified...

Each transaction is basically a string of text that explains which inputs are used to create one or multiple outputs. As long as a transaction is unconfirmed, it only exists in the volatile memory of the nodes, so it's pretty unsecure.
The only way of securing a transaction is when it's added to a block, thus gets a confirmation. From this point out, your transaction will be written in a physical file on the disks of hundreds of nodes, so it will no longer exist in mempools only (as a matter of fact, it gets removed from the mempool once it's confirmed).

In your case, the sender received an output from transaction bbf69880c3464b7c6f316738b0f496580186ff051ebf25396fc6efc7f128f83e, but instead of waiting untill this transaction was included into a block (so the transaction no longer only existed in the memory of a bunch of nodes), he used the output of this "pending" transaction as an input for both your transaction AND the double spending one.

So, if transaction bbf69880c3464b7c6f316738b0f496580186ff051ebf25396fc6efc7f128f83e gets dropped from the mempool of most nodes, or if the creator of bbf69880c3464b7c6f316738b0f496580186ff051ebf25396fc6efc7f128f83e decides to double spend the inputs used for bbf69880c3464b7c6f316738b0f496580186ff051ebf25396fc6efc7f128f83e, both your transaction as your competing transaction are now using inputs that no longer exist on the network... In this case both your and your competing transaction will be dropped...

So, your first order of business should be to make sure that the input for your transaction is actually confirmed... After this is done, your transaction has a much higher chance of getting into a block as the competing transaction

This was actually my first idear to... But then the OP told that he's using multibit HD, and AFAIK, that wallet doesn't rebroadcast transactions automatically (or am i missing something?)
To be perfectly honest: i did try to search if multibit HD automatically rebroadcasts, but since i didn't find anything related to this topic, i just assumed it didn't... But i can be wrong on this 

If I was you, i'd do the following things:
I'd try to get bbf69880c3464b7c6f316738b0f496580186ff051ebf25396fc6efc7f128f83e into a block, you can use my tool to look at your options:
https://www.mocacinno.com/feecheck.php?txid=bbf69880c3464b7c6f316738b0f496580186ff051ebf25396fc6efc7f128f83e . I think viabtc is the best option for you now.. I'd defenately wouldn't pay anybody to get this transaction into a block, since this is only the transaction whose output was used as an input for your transaction

Then, i'd hope your transaction got into a block before the double spending one did...

IF bbf69880c3464b7c6f316738b0f496580186ff051ebf25396fc6efc7f128f83e makes it into a block, and the sender doesn't decide to tripple spend the input for your unconfirmed transaction with a much higher fee, the odds are pretty good that your transaction will be confirmed, and not the double spending one... Why? Because it was broadcasted first, so most nodes will have accepted it, while the other one was broadcasted hours later, so some nodes might have rejected it AND the fee is much higher, so it gives the miners much more incentive to put your tx into the block their working on compared to putting the double spend transaction into a block...

It would also be a good idear to contact the sender once your transaction gets confirmed, and notify him of the problem... If the double spending transaction was also generated to pay somebody, this other person's transaction will be cancelled as soon as yours makes it into a block...

If this is your transaction, the odds are pretty big that it will indeed have a bigger chance of getting into a transaction as the competing transaction... However, both transactions use the same UNCONFIRMED input

https://blockchain.info/tx/bbf69880c3464b7c6f316738b0f496580186ff051ebf25396fc6efc7f128f83e

This means that neither you, nor the double spent can get into a block before bbf69880c3464b7c6f316738b0f496580186ff051ebf25396fc6efc7f128f83e gets into a block, and the sender seems to know a way to double spend the same inputs and broadcast them to the network, this means there is no way of telling if he will double spend the inputs for bbf69880c3464b7c6f316738b0f496580186ff051ebf25396fc6efc7f128f83e using a higher fee, thus lowering the chance bbf69880c3464b7c6f316738b0f496580186ff051ebf25396fc6efc7f128f83e will ever make it into a block...

However, since the sender decided to double spend the unconfirmed input in a transaction using a way lower fee, i'd say there is a pretty good chance it was a human error. If he really wanted to cheat you, he would have double spent the input of bbf69880c3464b7c6f316738b0f496580186ff051ebf25396fc6efc7f128f83e or used a higher fee when double spending the input used in your transaction...

Could you post the transaction id?
If your transaction has a higher fee, and it has the same inputs and roughly the same size, the odds are good that your transaction will end up in a block, but certainly not 100%

Could you post the transaction id? Usually these problems are caused by insufficient fees, but we can only be sure if we can examine the transaction.

I didn't know the txid, the person asking the question hijacked the OP's thread


Time for my new beta tool  
https://www.mocacinno.com/showchain.php?txid=7e295d281ed76d6d4db58a8c160c747bcfdaaee1f7f65dc546266a918e52ce3c

Your transaction is using outputs from an unconfirmed transaction... As a matter of fact, if you look at the link i posted ^^ you'll see the list of all transactions that have to be confirmed before yours can be confirmed (they can all be added to the same block though, the only thing is that your transaction cannot be added to a block before the others have).

The problem with such a chain of unconfirmed transactions is that if a node rejects one of the transactions your transaction depends on, or if a node just doesn't receive one of the transactions in the list, or if he receives the transactions in the wrong order, this node will also reject your transaction since it's using the output of the depending transaction...

1) transaction does not exist => the viabtc node either didn't receive your transaction, or it was rejected by their node
2) Submissions are beyond limit. => if you read viaBTC's TOS, you'll see that they only accept 100 submissions each hour. The current hour's submission limit was reached... Try again in 14 minutes.

Did anybody receive a reply from the OP?

You are the receiver, you shouldn't have payed anything... It should have been the sender that added a sufficiently high fee.
In your case: the transaction is 1109 bytes, my node tells me the optimal fee for a 95% chance of getting a confirmation in ~30 minutes is 353 sat/byte

So => 1109 byte * 353 sat/byte = 391477 satoshi's = 0.00391477. So, the sender *SHOULD* have payed a fee of 0.004 BTC instead of 0.0007 BTC. He cheaped out on the fee, and the end result is that you're in trouble.

Technically, there is no way to pay the fee after the transaction is confirmed. Your only options were listed in my first post.