Oh FFS... you just don't get it do you?

OK, I'll make it easy for you... split your seed in half, put it in a separate safety deposit boxes. Encrypt your passphrase using Axcrypt, store it on multiple USBs stored in separate airtight boxes with gel packs.

"HCP said so, so it must be safe" /s


Are you happy now?


EDIT: just in case it wasn't clear to anyone... this post was total sarcasm.

I think some of it is hidden by the fact that if the bot makes 4 trades (it basically sets up 4 buy/sells etc) for a total gain of 5%... that was being counted as 4 separate wins... so, the amount per "win" isn't really 5%... and that would have been 5% of max risk, not your bankroll... so 5% of 30% of your bankroll etc.

When your "stop" got hit... that was counted as only 1 loss.


So, using your formula, it would be:
The EV of a trade is as follows:
98%(SUCCESS_RATE) of (5% of 30%) (SUCCESS_PROFIT) = 1.47%
2% (FAILURE_RATE) of 30% (FAILURE_LOSS) = -0.6%
total EV of trade: 0.87%

So, theoretically, it should still be positive... but then you have to take all the fees and stuff into consideration as well.

A rough look shows 33 stops hit... out of 740 odd "trades", but each of those was generally something like 4 limit + 1 market... so it's really more like ~150 actual "trades". So, to me, it's more like 75% success...

It's kinda complicated tho, because the earlier bot was 4 limits + 4 limits (so, 8 entries, rather than 5)... and there are some where individual stops seemed to hit for each order, rather than one wiping out all open positions etc. so my maths on what constitutes a "win" and a "loss" is probably horribly wrong.

I'm also ignoring all the little "buy/sell" 1 things that the bot had to do to avoid the API from being "timed out" etc.


I can export the trade history if you want to do the indepth maths on it all.

Aaaaaaaaaand we're back to square 1.

Mate... if you want to put your seed in a cloud-based password manager... and you're comfortable with the associated risks of doing so, then go for it... millions of people do exactly the same with their logins to banks/email/websites etc... what could possibly go wrong? 

If you want to encrypt it with Axcrypt, and you're comfortable with the associated risks of doing so, then go for it...

Stop asking the same questions over and over again. They have all been answered multiple times.


We're going to say "store it offline", you say "what about USB?", people say "they fail", you say "what about using multiple ones? or what about using gel packs in an airtight container?"

Honestly, there are risks involved with EVERYTHING... you are not going to find a 100% failsafe solution to any of this.

- Human memory is "bad" and can fail
- Paper can be destroyed by fire/water
- Metal plates can be found/stolen
- Safety deposit boxes can be seized
- Online cloud storage can be hacked

You name ANY way of storing your seed and/or passphrase and I can probably name at least 5 ways that it can fail or be lost or stolen or hacked.

Just pick one that YOU are comfortable with... if that is an online password manager, then great! good for you... be happy, log out from Bitcointalk and go for a walk, touch some grass, get some fresh air... stop worrying about your seed/passphrase so much

I would say that is more likely to be "fat fingers" (aka data entry error) on behalf of the user than it is an issue with the recovery app (or the device firmware). Because of the english wordlist having so many "similar" words, it's very easy to enter/select the wrong one.

Annoying? yes... but not the end of the world.



^^ THIS! any failures of the device are not an issue... as long as you have you recovery seed words!

Maybe get in contact with BurtW who got raided and had assets, bitcoins and other things seized... and ask him how it all went down.

Seems like they pretty much tore his house apart. I would guess nothing would be safe if they decide to come after you... bank accounts, safety deposit boxes, everything in your house... anything attached to you/your id is likely "fair game" when the govt decided you're one of the "bad guys"™

All I did was document my experience with his trading bot and the platform... and apparently that makes me emotional with poor money management.

The thing he seems to forget with his 98% win ratio... is that it often wins less than 5-10% but will likely lose 100% of your "max risk" (was set to something like 30% of bankroll by default). So, it only takes a couple of loses (which is exactly what you can expect to get with a 2% loss rate) and you're all the way down.

You're basically playing dice at 98% chance to win with 30% of your bankroll. Except that dice is (generally) provably fair and not open to "market manipulation" and the whims of the trading market place.

Like this dicebot simulation... starting bankroll 0.1... bet = balance * 0.3 ("30% max risk")... chance 98%...


Looks somewhat familiar... only 23 losses in 1000 rolls... thats a 97.7% win ratio... and I still lost 99.4% of my bankroll.


Anyway... Nice to see he is interested in civilised, open and honest discourse. Instead, he just throws insults, blames market manipulation and then the end users for not understanding how trading works.

For the curious... Gavin Anderson explains some of this here: https://bitcointalk.org/index.php?topic=34028.msg656114#msg656114

And it seems that Joric showed some specific Python based code for dealing with the encryption/decryption here: https://bitcointalk.org/index.php?topic=34028.msg708668#msg708668

I will have to experiment further when I get some time... but it's Mother's Day here today

Well... it was a loooooong slooooooow death... but the inevitable finally happened. Finally got REKT!



My Bitmex balance dipped below the 0.01 BTC min balance required:


It shows on the Bothive platform as 0.00000000 BTC, but on Bitmex it's actually 0.0091 BTC:



Following some "unluck" this past couple of weeks:

---

Final thoughts:

c'est la vie... in fiat terms, the original 0.1BTC investment was worth around $750... and now my 0.0091 is worth around $530ish... however... considering that 0.1 BTC is now worth USD$5900... I would have been much better off just leaving it sitting in a wallet


Anyway, hopefully, this thread has in some way helped others avoid losing money in this service... even if it was just one person, I would consider it a worthwhile little adventure.

Armory is not a full node... Armory is a wallet application that connects to Bitcoin Core.


What wallet were you using? Just because you keep your wallet closed, and the transaction drops from some mempools... it doesn't mean that your transaction has been removed from your local wallet.

If the transaction was still being held locally in your wallet, and it was setup to automatically rebroadcast transactions on startup... as soon as you opened the wallet after 1 month, it's possible your wallet simply rebroadcast the old transaction again.

For instance, older versions of Bitcoin Core required that you abandon (and/or zapwallettxes) to remove local copies of transactions that you didn't want to be broadcast any more... otherwise the wallet would rebroadcast it every time you started the application.


You're referring to mempoolminfee? The only ones I know of are: https://mempool.space/


When it goes up it'll saying something like "Purging < 3.5 sat/vbyte" etc.


And the other one is here: https://statoshi.info/d/000000020/memory-pool?orgId=1

The graph at the bottom shows the mempoolminfee.


It's also visible using getmempoolinfo command on Bitcoin Core:

which can actually be executed on the chainquery website here: https://chainquery.com/bitcoin-cli/getmempoolinfo

NOTE: unfortunately it formats the BTC values in scientific notation... ie. 1.0e-5 instead of 0.00001000

That's because Bitcoin Core is able to keep much more data in RAM instead of constantly read/writing it all out to disk...

You'll probably find the disk I/O is much reduced as well.

You're going to need to be a bit more specific about what wallet/exchange/website/app you attempting to use for this transfer...

Where exactly are you sending from?
Where exactly are you sending to?

You can also use Ian Coleman's tool... you just put the zpub into the "BIP32 root key" box at the top (leave everything else blank):


Then click the BIP141 tab, make sure derivation path is set to: m/0
and then select the "script semantics" for the address type that you want (should be P2WPKH as you have a zpub which is for native segwit, nested segwit would be a ypub, legacy would be xpub)

Then scroll down to see the derived addresses:



m/0/2 appears to be: bc1qgheaqg9xuetndfzpkk3tuphnleephr3g54rs9t

---

NOTE: when pasting long strings into bitcointalk, it will add extra "hidden" spaces... so you need to wrap them in [ code ] [ / code] tags to stop the forum software from doing this... like this:

Fee rates going up and down has nothing to do with "manipuation" by custodial wallets, exchanges or gambling sites.

It is simply a function of the "supply and demand" nature of the Bitcoin network. Space in bitcoin blocks is limited, so if you want to get your transaction in on quickly, you need to "outbid" others trying to get in.

For instance... if there are 1000 transactions in the mempool (that will completely fill a block)... and there are 999 transactions that pay a fee rate of 1000 sats/vbyte and 1 transaction that pays 1 sat/byte... and you want to send a transaction and get it in the next block.

It makes no difference that 999 transactions are sending with 1000 sats/byte... you would only need to outbid the 1000th ranked transaction to likely get in... in which case, you could use 2 sats/byte and you would "outrank" the 1 sat/byte transaction.

What causes problems is that often, we have a situation where there are just a lot more transactions being generated and sent than can be included... and a lot of the people sending these transactions, want them confirmed fast... so they start outbidding each other to try and get it the next block.

THAT is what causes fees to go up... not anything untoward by exchanges, gambling sites or custodial wallets... if anything, they usually end up sending with low fees to try and minimise their expenses (and increasing their profits).

Just send the 0.05 BTC already and put us all out of our misery... when you do so, please use a fee of 1098234832098 sats/vbyte... then you won't have any BTC and you'll stop bugging us with the same questions... over and over and over and over and over

Honestly mate... how many times do you need to hear the same answer before you'll believe us? 10? 100? 100080328493274932749832?

I'm honestly curious, because this thread is now 15 posts long... and it seems that you're no closer to understanding (or believing the explanations of) the very core basics of how a Ledger Nano S and Ledger Live work.

So, let's try and summarise shall we:

1. For an account to be added into Ledger Live, the master public key has to be read from the Nano S device
2. For the master public key to be read from the Nano S device, the device has to have the appropriate seed
3. For the appropriate seed to be in the device, the device must have had the correct 12/24 words entered into it (and/or BIP39 passphrase used)
4. Once an account is added into Ledger Live, the device DOES NOT need to be connected to view the account (LL has the master public key stored)
5. If you delete an account, the master public key for that account is deleted, and CAN NOT be re-added with the device
6. Ledger Live will allow you to create (unsigned) transactions WITHOUT the device connected
7. You cannot sign a transaction without the device being connected and without the device having the appropriate seed (refer #3)

If you feel you need to transfer 0.05BTC to some other wallet to satisfy yourself it's all working... then just do it... don't ask about fees or when or how... just fucking do it already!

Yes, that is very true... while both software and hardware wallets generally provide a final "transaction preview" seeking confirmation... the hardware wallet has the added protection of requiring the physical confirmation, but also it provides an "independent" verification screen that is not able to be tampered with...

That is to say, while a fake version of a software wallet can modify what you see displayed on you computer screen (ie. the receive address and/or amount, while it is actually going to send to a different address), a hardware wallet will generally give an independent view of this information as read directly from the raw transaction... so it's an extra safeguard where you can see exactly where the coins are being sent (and how much!)

If you're using Windows 10, it could quite possibly be a "permission" error... I was attempting something the other night and some Python scripts were kicking out errors because some of the new Windows 10 defender and security settings attempt to block reading/writing from some C:\ folders

Try starting the command prompt as administrator:

1. Click the "Start" button (press Windows key)
2. Type: command prompt - you should see something like this: 

3. Click the "Run as administrator" option on the right hand side

You should see the command prompt open with admin privileges:


Note how it says "Administrator: command prompt" in the title bar... give that a go and see if the Python script works ok then.

If the scripts like PyWallet or core-decrypt aren't able to read the file... and the db_dump utility doesn't work... then you're probably going to have to try and extract the hex bytes manually using a hexeditor and searching through the wallet.dat for the various markers (ie. mkey and ckey etc).

Honestly, that's going to be a giant P.I.T.A. It's not impossible... it'll just be a ton of work... and depending on how corrupt the file is and/or how exactly it was corrupted, it might actually be impossible to decrypt the individual keys ie. if the mkey is corrupt, you're basically stuffed

Unfortunately, as I haven't yet figured out how to get from encrypted mkey -> unencrypted mkey -> unencrypted ckeys etc... I am not going to be able to assist much further at this point in time.

Hopefully someone else with more knowledge of the technical details of decrypting the mkey will be able to assist.

I already upgraded both Ledger Live and my device to firmware 2.0.0... no issues to report... and I haven't seen any (new) issues reported either.

I was pleasantly surprised at how easy the firmware upgrade was... it basically does everything for you now (removes old apps, reinstalls apps etc). Very simple.

It didn't wipe the device or require the seed to be restore or anything.

If it's been removed from a node's mempool... how would it magically appear again? The node has no record of it any more. So, most likely it won't "appear" again unless it gets rebroadcast.

So, either a node that still had it, would have to rebroadcast it... not sure how many nodes actually do this? or your wallet would need to rebroadcast it... or someone else who happened to have the raw transaction would have to broadcast it.

When you create a recovered wallet... you have to specify a passphrase that the "recovered wallet.dat" is going to use... you then specify the "possible" passphrases it should try when recovering keys/data etc...

The script attempts to decrypt any encrypted keys found using the "possible" passphrases... and then puts them into the recovered wallet.dat, encrypted with a master key derived from the "recovered wallet.dat" passphrase (NOT the passphrase of the original wallet)