I personally belief this question doesn't have a one-size-fits-all sollution.

I'd rather have all my funds on a single bip38 encrypted (strong password) paper wallet, from which i have 2 copies, both stored in 2 different banks than having all my funds dispersed over 10 online wallets...

It's a question about privacy, the broadcasting of your public key and risk management, IMHO.

privacy => using a couple wallets, using mixers, always using newly generated address and change addresses drasticly increases your privacy, while using a single address in a single wallet decreases your privacy

broadcasting of your public key => As soon as you spent unspent outputs, you need to include your public key in the transaction... As long as you generate an address, and use this address as output for transactions, but never use these outputs, you can avoid getting your public key known to the public.
There is a discussion about this, basically if ECDSA encryption ever gets broken, it would be technically less chalenging to recalculate the private key when you have the public key. Since the address is only a hash of the public key, it's safer if only your address is known on the network, since an attacker would have to work back from address to public key to private key... This is very futuristic stuff tough, for the time being, i don't think there's a lot of risk in exposing your public key.

risk management => It's all about which wallets you store where, how much funds, how many backups, which types of encryption... Like i said: it would be better to have a single paper wallet, BIP38 encrypted with a 30 letter password, 2 copies stored in the safe of 2 banks than it would be to have 10 online wallets... From a safety point of view, i think this setup would outbeat allmost all types of storage.

Are you sure your wallet is completely synced?
If it it, you could try to rescan your wallet by starting it with the correct parameter (./bitcoin-qt -rescan)

I don't own one, but it seems archive.org still have the drivers-page directly from butterflylabs, and they seem to have cached at least part of the zipfiles to...

https://web.archive.org/web/20161101210812/http://www.butterflylabs.com/drivers

I'm not sure about this... Ledger nano S is a HD wallet, it means it's deterministic, so it derives private keys from an xprv.
By defenition, a "thirth party" private key can not be derived from the same xprv.
I think, theoretically, it should be possible to generate a wallet that uses a seed to generate an xprv and derives new private keys from this xprv AND allows you to import "random" private keys... However, i don't think such a wallet exists at the moment (AFAIK). Such a wallet would combine two completely different methods, and just share the functions to scan for new unspent outputs and generate transactions...


In electrum, you have 2 kinds of wallets: a HD wallet can not import private keys, it can sweep wallets tough. When sweeping a private key into a HD wallet, what happens is: a new private key => public key => address is generated deterministically using the xprv. Then, electrum generates a new transaction using all unspent outputs controlled by the swept private key and generates a new transaction using all these unspent outputs as input, and it generates one new output, one that can be spent by the newly generated address.

A non-HD electrum wallet does not use an prv to derive new private keys/public keys/addresses, it just imports "random" private keys and keeps track of their unspent outputs.

AFAIK, when coupling a ledger nano S to electrum, it's always a HD wallet, so you cannot import new private keys, merely sweep them.

[ANN] = announcement

Een aankondiging dus... Als je een nieuw product of service will aanbieden aan het forum, kan je hier best een announcement thread voor maken. door het [ANN] keyword te gebruiken weet iederen dat dit de officiele announcement is, dus dat ze best hun vragen in deze thread posten.

Andere keywords zijn, bijvoorbeeld
[WTB] = want to buy, gebruik deze als je een goed of dienst wilt aankopen
[WTS] = want to sell, gebruik deze als je iets te verkopen hebt

I think some vendors on localbitcoins.com don't have a minimum.
Other than that, you can get your hands on some non-reversible currency, or some non reversible voucher codes and sell them on this forum for BTC... Only trade with trusted members and allways use an escrow tough!

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...