I want the test network to work because there is a wallet on which funds are sent.
Testnet coins are worthless... they have no monetary value.  Did you pay someone money for these coins? If so, you might have been scammed.  Can you please answer goatpig's question... what is the first character of the address that you sent coins to? is it 1, 5, n, m or 3? |
|
|
|
2. Try to Install wallet from original official website. Every coin have their official website where you will find their wallet download link.
Actually, most (may be all) trusted wallets can be found in a GitHub repostory; it's the, probably, the safest place where wallet's code are verified and audited by coders community. In the GitHub, you can follow discussions about developement, updates, and fixing errors as well. Just because a wallet is on GitHub, it DOES NOT mean that it is safe or has been audited or is the legit wallet. It is also insanely easy for scammers to fork a GitHub repo... and setup a fake version of the wallet that steals private keys. Very few users will ever bother to fully vet a GitHub repo to check the owner, the history, commits etc and whether the code is legit. The recent Electrum attack involved directing users to a fake GitHub repo to download a fake version of the wallet. So, any one can confirm that that site can give good results and reliable to use, please.
Virustotal results are reliable and you can trust it. Virustotal is in no way 100% reliable... it will include many false positives... and just like any other virus detection software, it can only detect known viruses/malware. Also, just because the software scans "clean", it does not mean it is not "malware" that will steal your private keys/wallet/password. If the source code has been modified so that the wallet will connect to an external server and post the keys, it is highly unlikely that a virus scanner will flag that as suspicious... to the scanner it will simply appear as an app that connects to external servers and transmits data back and forth. |
|
|
|
Exactly how did you do this transaction "offline"? Were you supposed to be receiving funds? If so, where did you get the receiving address from? From within Armory when it was "offline"? Do you have a transaction ID for the transaction? Have you checked this transaction ID using a block explorer to confirm that the transaction was successfully completed and that the correct addresses were used? |
|
|
|
I'm thinking about buying a hardware wallet and I want to know your opinion?... Which one do you recommend me to buy? and why? Thanks  I think you should not buy hard wallets anymore. Currently in ETH's wallet system has updated a new wallet type is MEWconnect. It has a different level of security than Ledger Nano S and it will save you up to $ 150. Visit Myetherwallet and experience it. Yes... That is correct, insofar that it has exactly the same level of security as pretty much every other modern software wallet. It is not even close to the level of security offered by a hardware wallet.  With MEWConnect, your wallet and private key is stored, encrypted by a passphrase, on your device... connected to the internet. |
|
|
|
I need to quote myself since there is no answer to my question. I still no see that is possible to update only Bitcoin App from version 1.3.2 to 1.3.4 with old 1.4.2 firmware.
Most likely the 1.3.4 app is reliant on underlying changes in the 1.5.5 firmware... so the app is likely to only show in the manager if you update. Also in which way and how Ledger Nano S can be compromised so such attack can be successfully executed? Is hacker need physically access the device or it can be done remotely?
It required that the software wallet on your PC/phone/tablet you were using in conjunction with the Nano S/Blue was setup to exploit the flaw... in the video linked above (and associated article), the actual developers of Mycelium (who responsibly reported the flaw) had purposely coded a version of their wallet that could create data packets that fooled the device into only showing address + fee + amount... while hiding all the other "change" outputs. If you don't have a requirement to have multiple coin apps loaded on your device, I'd advise to update to the 1.5.5 firmware... and then you won't have to worry about this issue. You'll just be restricted to a couple of coin apps due to the space issues with the latest ETH app  |
|
|
|
|
The Digital Bitbox has no screen... and the original Ledger Nano (and HW.1) didn't have a screen either...
They rely on using software to display all the info... which is a possible attack vector ie. an attacker can get hacked versions of the software loaded onto your device(s) and display whatever they want... and trick you into confirming a transaction that sends all your funds to some unseen address etc.
This is why the newer wallets all tend to include screens... it makes it harder for this attack to succeed as the attacker would also need to compromise the device itself to display "bad data"... which is generally orders of magnitude more difficult than compromising software on a PC/tablet/phone
|
|
|
|
135th in line for being blamed for all the ills in the bitcointalk world... I can live with that  |
|
|
|
Its funny. When I look at all your signatures of who has replied to my post.
You are probably all connected and no one of you wants to admit that there is an actual cheat going on here because that would mean that all of you would be affected.
"connected"? ChipMixer isn't even in the Casino business... and the others are for non-Primedice casinos that would actually benefit if Primedice went out of business... so your logic is a bit flawed there. Truth is a red streak of this kind has a chance of less then 10000000:1 occurring only once but if it happens twice within 2500 rolls in a seed it SCREAMS "cheat".
See, now you are introducing new claims... you never mentioned previously that this had happened twice within 2500 rolls, nor did you show any evidence to back up this new claim. At best we have a screenshot that shows a sequence of 7 rolls less than 10. Not only can screenshots be doctored, but we have no way to know if the seeds remained the same throughout this sequence. Additionally, one streak calculator I found, calculated the probability of that streak appearing in 2500 events as 0.02%... which is 5000:1, which is quite small, but still a lot higher than 10,000,000:1. I guess it has a lot to do with how you are actually calculating the probability of a certain event occurring. Hell, I had a sequence once, betting at 10% chance of win, where I got a losing streak of like 130+ !!?!  The largest win streak using those odds (which would be equivalent to your losing streak) was somewhere in the mid-10's... like 13 or 14 from memory... so I don't think 7 is a particularly outrageous loss streak at those odds. But then admitting to that would mean for you guys to having to question "provably fair" business, right?
That can't happen, no.
One thing that can't be doctored is a properly implemented "provably fair" system. The maths involved in the hashing etc makes it impossible to cheat this system... However, if you can show some flaw in Primedice's "provably fair" system that would allow them to cheat... then I think the community as a whole would be VERY interested... and the website would lose all credibility. Also... No I'm not going to post all my evidence here. That would mean giving all my aces away and render them useless.
That is your choice, but if you don't show us evidence there is no way for us to back your claims. Do you really expect anyone to take your side (regardless of their affiliations or "connections" or neutrality as the case may be) unless you show some concrete evidence to back up your claims? We are just supposed to believe your claims based on what you say and a screenshot? While I'm sure you honestly consider it a scam, without some hard evidence, there is no way I, or anyone for that matter, can really corroborate or back your claims. |
|
|
|
are you sure about this?
Nope! Hmmmm maybe it is just the SegWit "xprv" (actually a zprv) that I saw doing odd things... From the Electrum SegWit seed: "keystore": {
"pw_hash_version": 1,
"seed": "wine comfort off fat pudding initial wash they tennis fashion never nuclear",
"type": "bip32",
"xprv": "zprvAYvZpviDe8FvV1uHrqohakCtZ3M4Cv6pcZYqcvzHb1Ujh8s1c3J3cMzza2bCcK91iyik8dZJU3LSiMFkBtppQNSdmcpq3sxtBiT7ojnHq45",
"xpub": "zpub6muvESF7UVpDhVykxsLhwt9d75BYcNpfynUSRKPu9M1iZwCA9acJAAKURHHq8bPcLS3X2p39SJHW45WYmWcsXzPdBTf5f8cPSf7tgUSipez"
You can see the stored zprv... it produces this address:  But, when we put the seed into the converter... we get this:  So, to see the same "xprv" (as stored in the wallet) in BIP39 converter... you need to use a derivation path of: m/0'  But... then addresses shown are NOT the ones in the wallet!! To see the correct address you need the extra "0" (path= m/0'/0), which gives the correct addresses, but shows the wrong xprv:  Meanwhile, in Legacyland... "keystore": {
"pw_hash_version": 1,
"seed": "resist flee ginger seminar pretty walnut basic shift you reason trigger battle",
"type": "bip32",
"xprv": "xprv9s21ZrQH143K3jnoRp5JYq2zjuw1d6rAUmkMT2has1wFujr5SPQdDDma3jwjMRV1rT8xS7ZdeQywSdhzc7SHVncCEQH4FjK9DUKM7ip6WBU",
"xpub": "xpub661MyMwAqRbcGDsGXqcJuxyjHwmW2Za1qzfxFR7CRMUEnYBDyvism263tzxQZLdm8Z2q44HbmjRKk3A28nMJMgM57fBdpnmEMmPSo8rSM7S"
},
Which generates this:  The "xprv" stored in the wallet, is the same as you get if you put the seed into the converter... (so path=m):  but again, does not show the correct addresses until you add a 0 (path = m/0):   It all seems a bit confusing and somewhat inconsistent... but seems to be because the old BIP44 stuff only had: m / purpose' / coin_type' / account' / change / address_index whereas the newer stuff apparently uses: m / purpose' / coin_type' / account' / script_type' / change / address_index But the "xprvs" we have stored in the wallets, are actually at m (legacy) and m/0' (SegWit) ??!? This stuff does my head in sometimes! |
|
|
|
|
Are you saying that it isn't possible for there to be that many rolls in a row under 10? I can assure you that the probability of that occurring, whilst "small", is definitely non-zero.
Did you check the client and server seeds and whether the provably fair results line up? Or is this just another "ZOMG the odds are so small, they must be cheating!!!!1!!1!1!!!!" type thread?
|
|
|
|
Personally, I think it looks very "scammy" when an online service is more than happy to take your money "no questions asked"... then does a "180" and starts asking for all sorts of verification as soon as you try to withdraw your money. I understand the commercial downsides to a crypto-related business asking for KYC "upfront"... they'll be shooting themselves in the foot as users will just move on to the next service that doesn't require KYC to deposit (but may or may not play the card at withdrawal time). But at the very least, they should be "upfront" about the fact that it is likely you will need to provide KYC if you need to withdraw "large" sums (over some stated threshold). Surely it can't be that hard to include it in the T's&C's when a user is signing up? I would likely have more respect for a service that was open and honest in this regard... rather than springing requirements on you at the last moment! In any case, it probably won't stop users complaining... look at the large exchanges, they're generally pretty open about the fact that you will need to complete KYC to withdraw over a certain threshold... and users are always bitching about it. |
|
|
|
Using the xprv likely won't work... the xprv that is "stored" in an Electrum wallet is not the "root key" generated from the seed... but an Account Extended Key. That is to say, it is the xprv calculated from the path m/44'/0'/0' Electrum then uses a derivation path of m/0 and m/1 to generate the "receive" and "change" keys/addresses, respectively, from that starting point. However, I would guess that the Coldcard is attempting to use the full m/44'/0'/0'/0 derivation path and therefore is effectively using a "combined" Derivation Path of m/44'/0'/0'/44'/0'/0'/0 and that is why it would be generating different keys/addresses (and unable to sign your transaction) If you start with the Coldcards... and export the three xpubs from those. Then, import those xpubs into three different Electrum (File -> New/Restore -> Standard Wallet -> Use a master key), wallets, do you get the correct addresses generated? If so, are you then able to create a MultiSig in Electrum from those three xpubs? |
|
|
|
Do you have an already modified offline files that can be downloaded? Or just a fork of https://github.com/iancoleman/bip39 with the edited code? Because newbies and some Electrum users will find it useful at times like this; manually editing the code themselves is much of a hassle or out of their expertise ( though HTML can be edited using notepad and pretty much basic, some may find it hard). You're a trusted member and if it is hosted in Github and a fork of the original, most members will trust it. Actually I do have an offline version hosted on Github... it has been there for a while: https://github.com/HardCorePawn/electrumBIP39 But it was VERY old (only included BIP44 and BIP32 tabs! ), So I have just updated it... Unfortunately, I can't simply fork the Ian Coleman repo and modify it, as Ian removed the standalone.html file from source control (to save space as far as I can tell) So, I did a "save as" on the current Ian Coleman page, made the two edits that I listed in the other thread linked above and then uploaded the file to GitHub. As always, USE AT YOUR OWN RISK!NOTE: Instructions have been updated to include the subtle differences for SegWit address derivation. |
|
|
|
It's a relatively simple flowchart: Is Crypto BTC or ETH? --> Yes --> "Good Crypto"™ | | v No | | v Shitcoin™ |
|
|
|
Did you try rebooting and trying from a fresh startup? It might be that ghost processes are causing issues... You shouldn't need Python sources to run the portable .exe as it should be "self-contained"... Unfortunately, I don't currently have an x86 Win7 system to test with |
|
|
|
You can modify the Ian Coleman webpage to work with Electrum fairly easily... it is open source. You just need to right-click on the page and "save as" to download the .html, open it with a text editor and make 2 minor edits. Refer to my post here: https://bitcointalk.org/index.php?topic=2373020.msg24316954#msg24316954NOTES: - search for self.check and self.toSeed to find the two functions that need to be edited - The first edit removes the error checking from the "BIP39 mnemonic" field, so it pays to triple check you've typed the words correctly. - The second edit changes the "passphrase" section so that it uses the default Electrum passphrase as opposed to the default BIP39 passphrase |
|
|
|
Brainwallets are not secure, at least if they have a relatively short seed , like 12 words.
What about Ledger ones that have 24 words?
What a lot of people fail to grasp... is that the wallets that utilise seed mnemonics (aka 12/24 words), do not start by generating words. They start by using a (pseudo) random number generator to create a very large random number... this large random number is then converted into words by following the BIP39 process. (Note that Electrum follows a slightly different method for converting to words, but the underlying theory is the same... large random number -> words). This is completely opposite to a "brainwallet" where the words are chosen first... and the number is generated from the words. As was already stated, creating your own brainwallet words generally leads to very poor entropy because humans are terrible at creating "random" things. So, by starting with a random number, then converting to words... you retain the "entropy" to safeguard your coins. |
|
|
|
And that they should not be vulnerable to any hack risks
Then software wallets are probably not for you... or hardware wallets... you're probably going to want some dice or a coin, a knowledge of decimal/binary to hex conversion... and some paper. Then go read up on generating paper wallets. |
|
|
|
New new feature could be as this as a example we play on 49.5 chance then on every lose to increase the chance by 1% together with the bet.
You can do that already... just not in the "basic" bot UI, but with a script in programmer mode. |
|
|
|
In a licensed and governmental controled gambling websites these settings are defined by law to protect customers.
From what I've read, you think people can't become gambling addicts if they play in regulated casinos, even worst, you think people can't lose everything they have if they play in such casinos. Well that is just one big crazy assumption and it is completely wrong. I used to work in an actual real life, "bricks and mortar" casino... all of the odds and house edge etc were government regulated. Even the required payouts for slot machines as a percentage of money put into them was government regulated. Side note, this percentage was actually lowered in an attempt to try to stop people becoming addicted (ie. lower the payouts, people will not want to play them etc) I saw first hand, every single day I was at work... that none of this regulation made any difference whatsoever. There were still people who couldn't afford the $10 carpark fee... others who were walking around approaching other patrons offering to sell handbags, phones, necklaces, rings so they could have $20 to gamble... others who would wander the casino for hours looking for 2c worth of credit left on a machine so they could either play it or try collecting it so they could make it up to $1 to cash out etc. While I applaud your cry for consumer protection... attempting to use it as a "weapon" in your ongoing battle against certain forum members is just pure folly. |
|
|
|
|
Show Posts
