Any exclusive Bitcoin android wallets other than Mycelium that would work as a cold wallet?
Apparently "Bither" has a cold storage mode... I've never used that mode, and haven't really used Bither itself other than installing it and messing about for a few hours... so I'm not going to recommend it as such, but it might be worth checking out. Supposedly, you can "monitor" the cold account from your "hot" device, generate unsigned transactions and use QR-Codes to transmit the unsigned/signed transactions to/from the "cold" device. Check it out here: https://bither.net/ |
|
|
|
Did you read BIP143? Restrictions on public key type
As a default policy, only compressed public keys are accepted in P2WPKH and P2WSH. Each public key passed to a sigop inside version 0 witness program must be a compressed key: the first byte MUST be either 0x02 or 0x03, and the size MUST be 33 bytes. Transactions that break this rule will not be relayed or mined by default.
Since this policy is preparation for a future softfork proposal, to avoid potential future funds loss, users MUST NOT use uncompressed keys in version 0 witness programs.
Looks like your coins are stuck...  |
|
|
|
|
At this point then... I would suggest that your options are:
- Try a different Linux VM (Ubuntu 16.04 LTS seems to work OK for me, but like I said, I'm on Win10)
- Try running Ledger Live on Windows 7
- Try running Ledger Live on Windows 7 (Safe Mode + Networking)
- Upgrade to Windows 10
- Create a bootable Linux USB
- Try and troubleshoot the Linux VM
|
|
|
|
Would anyone besides the recipient of the original Bitcoin Cash ABC transfer have the information needed to perform (and benefit from) this "replay"? In other words, is this foul play on the part of changelly or could any blockchain observer do this? Anyone with a copy of the BCH ABC blockchain, or access to a BCH ABC block explorer has all the information required to perform the replay. All they need is the raw transaction (or TXID to look it up on block explorer)... and then you broadcast it on the BSV network. Without replay protection, it's a perfectly valid transaction on both networks. Only the initial receiver would benefit, as you can't change the transaction (it'll break the signature after all)... but that doesn't necessarily mean they were the ones who actually did replay it. Given that a LOT of people seem to have had BSV transferred while moving BCH, I'm guessing that there were simply BSV nodes that were automatically rebroadcasting any BCH transaction, on the BSV network... all part of the "hashwar" etc... |
|
|
|
|
Most likely because you're using the software and hardware in a way that it was never designed to be used... and, somewhat unsurprisingly, you're getting unexpected results. Like I mentioned a while back... trying to use USB devices with virtual machines can be problematic due to it essentially being a software emulation of a physical hardware interface.
Having said that, I am able to make it work on Ubuntu 16.04 VM, but running on a Windows 10 host. It could be something as random as a latency issue due to OS version or drivers etc preventing the process from working properly.
Have you tried opening Ledger Live, then connecting the Ledger Device, unlocking with PIN and then selecting Bitcoin app on the device BEFORE you select "add account" in Ledger Live?
|
|
|
|
|
Firstly, Bitcoin SV isn't Bitcoin (in spite of what Craig Wright is attempting to convince the world of), so your request should be in the Altcoin forum.
Secondly, I believe they didn't implement replay protection in Bitcoin SV... creating the so-called "Hashwar". The result being that any BCH transactions that were conducted immediately after the split, could be replayed on the Bitcoin SV network. So, my guess is that Changelly "received" your 40 BSV, due to the transaction being replayed.
I'm not even sure if BitcoinSV ever implemented replay protection...
|
|
|
|
You're missing the point that if a user account was created today, when they get 1000 merit, they are a so-called "self-made" legendary... In any case, all this "self-made" stuff is just nothing more than 'peacocking'.  Actual Legendary members don't (and shouldn't) care. If the majority of users here cared a little less about merits and rank, and a bit more about actually contributing in a meaningful way, simply because it helped the community, we'd be a lot better off. |
|
|
|
Currently, the negative trust description we have is: "You were scammed or you strongly believe that this person is a scammer." These quite specific words seem to be at the root of a lot of the claims of "Trust Abuse"... Specifically, we see a lot of users who receive negative trust ask questions such as "Whom have I scammed?". This arises from the fact that a number of users appear to use negative trust to show that they consider someone untrustworthy, as opposed to considering them a scammer, per se. On the flip-side... the positive trust description is: " You trust this person or had a successful trade." (emphasis added) Would it not make sense for the descriptions of these two options to be properly mirrored as their names would suggest?  To this end, what if the negative trust description were to be modified to something like: "You were scammed or you strongly believe that this person is a scammer or you consider this user untrustworthy."? (emphasis added for clarity) And the matching "Big Red Box" was changed to "Warning: One or more bitcointalk.org users have reported that they consider the creator of this topic untrustworthy or that they strongly believe that the creator of this topic is a scammer. (Login to see the detailed trust ratings.) While the bitcointalk.org administration does not verify such claims, you should proceed with extreme caution." (again, emphasis added for clarity) Hopefully, this can stay on-topic and we can avoid the usual petty name calling, accusations and counter-accusations. If you want that, there are plenty of other threads both here and in "reputation" to beat those dead horses... I am simply looking for discussion on the description for "Negative Trust". So, "Should the Negative Trust description be modified?".... Good idea? Pointless exercise? |
|
|
|
Wallet opened and showed receive address without password input.
Funds show as received......two transactions confirmed.
wallet shows as unlocked.
Seed appears to be encrypted string and is displayed without asking for password.
Can not send funds to any wallet tested.
All of this leads me to believe that you have a "fake" version of Electrum installed. Where did you download this 3.3.6 version of Electrum from? Check the actual URL it was downloaded from in your browser history... Also, did you verify the digital signature of the downloaded file? Instructions on how to verify the downloaded Electrum file are shown here: https://bitzuma.com/posts/how-to-verify-an-electrum-download-on-mac/ |
|
|
|
Exodus doesnt show change addresses (for simplicity) (because it is a poorly designed wallet), while Legder does.
There... fixed that for you. Honestly, this is bread and butter stuff for a wallet. If a user wants to view the transaction details, they should see the actual transaction details... not whatever the developer thinks the user should see.  For instance, hiding change addresses is just confusing for users who then wonder why their coins are not in "their" address if they should happen to put their "main" address into a block explorer and then wonder why the balance doesn't match what their wallet is telling them. |
|
|
|
For the record... the "best" explorer I've seen at displaying "correct" transaction sizes and fee rates is actually btc.com: https://btc.com/8a95f05d72d9283bfd759352d3053c04e16e6674ee4c451bd1a72b09d14a3a0eYou can clearly see the "raw" size, the "virtual" size, the "weight"... and then the fee rate paid in BTC/kVB:  Note: You can work out the sats/vByte by dividing by 1000 => 3000 / 1000 = 3 sats/VByte |
|
|
|
I grabbed a few addresses from my Ledger Live transactions but it said it wasn't a valid Bitcoin P2PKH address.
------------------
Okay update. I made a new wallet on Ledger Nano S with a new seed and I got the xpub key from Ledger Live. I ran seedrecover.py by taking out one word from the seed and it couldn't find it, so perhaps I did miswrite something in the original. Not sure why seedrecover.py isn't working properly.
OK... my bad... I forgot that madacol's "master" branch was actually just default btcrecover!!?!   ... So, you need to switch to the "p2wpkh-p2sh" branch first, THEN download the .ZIP file from github:  Apologies for that! You also need to specify a non-default derivation path... as seedrecovery defaults to m/44'/0'/0'/0 and you need m/49'/0'/0'/0 So, I just ran a quick test using a 24 word seed generated on Ian Coleman's mnemonic code converter. version vanish add search lucky polar buddy wasp image trophy bright educate rubber tell control crystal rude letter erosion thank advance magnet veteran buddy
m/49'/0'/0'/0/0 3QpdYZkyW6a5GGFVVGAQRprvNfkUWfiSc6
m/49'/0'/0'/0/1 3KRsYk5aQVPELD8x6MCDDJLb5EPsZr7bvZ
m/49'/0'/0'/0/2 37g3kfip54i91YSS9KSPhQkaFPxr95unfB
m/49'/0'/0'/0/3 38p4SgCkDNGRjWNzUmZyoaAEejbsfvHgkj
m/49'/0'/0'/0/4 31wz2V9aRvSn4zmQGSxTdEuwoyHSQikPHb
version vanish add search lucky polar buddy wasp image trophy educate rubber tell control crystal rude letter erosion thank advance magnet veteran buddy
python .\seedrecover.py --wallet-type bip39 --addrs 31wz2V9aRvSn4zmQGSxTdEuwoyHSQikPHb --addr-limit 5 --mnemonic-length 24 --mnemonic-prompt --bip32-path "m/49'/0'/0'/0"
Gives this output: PS C:\Crypto\btcrecover-p2wpkh-p2sh> python .\seedrecover.py --wallet-type bip39 --addrs 31wz2V9aRvSn4zmQGSxTdEuwoyHSQikPHb --addr-limit 5 --mnemonic-length 24 --mnemonic-prompt --bip32-path "m/49'/0'/0'/0"
Starting seedrecover 0.7.3, btcrecover 0.17.10 on Python 2.7.15 64-bit, 16-bit unicodes, 32-bit ints
terminal does not support UTF; mnemonics with non-ASCII chars might not work
Please enter your best guess for your mnemonic (seed)
> version vanish add search lucky polar buddy wasp image trophy educate rubber tell control crystal rude letter erosion thank advance magnet veteran buddy
Using the 'en' wordlist.
Seed sentence was too short, inserting 1 word into each guess.
Phase 1/3: up to 2 mistakes, excluding entirely different seed words.
Not enough entirely different seed words permitted; skipping this phase.
Seed not found
Phase 2/3: 1 mistake which can be an entirely different seed word.
Using 4 worker threads
20695 of 49129 [################-----------------------] 0:00:00, ETA: 0:00:00
Seed found: version vanish add search lucky polar buddy wasp image trophy bright educate rubber tell control crystal rude letter erosion thank advance magnet veteran buddy
Addtionally, you *might* actually be able to also use the "xpub" from Ledger Live instead of using addresses... Out of curiosity, I ran a quick test that seems to indicate it will work OK python .\seedrecover.py --wallet-type bip39 --mpk xpub6DBZvWvR1bgKmk6k5JvweNRD1QhKXzGroqZWAETadaz5BWauEGwptwn4o2jeFknZxKhe9dCA9NYk1TfjPiesg5tJG6xF5ymBogS8fHKVsiL --mnemonic-length 24 --mnemonic-prompt --bip32-path "m/49'/0'/0'/0"
yielded: PS C:\Crypto\btcrecover-p2wpkh-p2sh> python .\seedrecover.py --wallet-type bip39 --mpk xpub6DBZvWvR1bgKmk6k5JvweNRD1QhKXzGroqZWAETadaz5BWauEGwptwn4o2jeFknZxKhe9dCA9NYk1TfjPiesg5tJG6xF5ymBogS8fHKVsiL --mnemonic-length 24 --mnemonic-prompt --bip32-path "m/49'/0'/0'/0"
Starting seedrecover 0.7.3, btcrecover 0.17.10 on Python 2.7.15 64-bit, 16-bit unicodes, 32-bit ints
terminal does not support UTF; mnemonics with non-ASCII chars might not work
Please enter your best guess for your mnemonic (seed)
> version vanish add search lucky polar buddy wasp image trophy educate rubber tell control crystal rude letter erosion thank advance magnet veteran buddy
xpub depth: 3
xpub fingerprint: D04C4361
xpub child #: 0'
Using the 'en' wordlist.
Seed sentence was too short, inserting 1 word into each guess.
Phase 1/3: up to 2 mistakes, excluding entirely different seed words.
Not enough entirely different seed words permitted; skipping this phase.
Seed not found
Phase 2/3: 1 mistake which can be an entirely different seed word.
Using 4 worker threads
20695 of 49129 [################-----------------------] 0:00:00, ETA: 0:00:00
Seed found: version vanish add search lucky polar buddy wasp image trophy bright educate rubber tell control crystal rude letter erosion thank advance magnet veteran buddy
NOTE: For this test, I used the " Account Extended Public Key" ypub from the BIP49 tab on Ian Coleman, and ran it through the converter here: https://jlopp.github.io/xpub-converter/ to convert to an the xpub. (The xpub from Ian Coleman BIP44 tab is actually different and didn't work). However, this converter seems to supply the same "xpub" that Ledger Live provides... which would imply that Ledger Live is doing a similar ypub to xpub conversion. Good Luck!  |
|
|
|
|
Because that information (what public keys contain what) is contained in the blockchain... the blockchain is a record of all bitcoin transactions. It records all movements of bitcoin from public key to public key. From this public record, we derive what is known as the "UTXO set"... Unspent Transaction Outputs. This is the current record of what public keys owns what bitcoins.
So, you can certainly try and sign a transaction claiming you own 3 bitcoins instead of 2... but the full nodes that accept and validate transactions will reject this transaction as invalid, as they won't be able to find that extra bitcoin that doesn't exist in the UTXO set.
This is what full nodes do... they validate transactions and blocks. They start at the "genesis block", the very first block in the blockchain and then they validate each and every block from there right up to the blocks/transactions being made today (this is why the blockchain data is over 250gigs and growing)... each block builds on the previous one, creating the immutable chain. Any attempt to modify any of it will render the whole chain after the modification as invalid... and then blocks/transactions will simply be rejected.
|
|
|
|
-----BEGIN BITCOIN SIGNED MESSAGE-----
This is Ene1980 from bitcointalk
Just for the record... that is a really bad message... it doesn't include the date, or the purpose for the message... someone could possibly use that message, address and signature to impersonate you on other platforms... For instance, someone could create a Telegram account called @ene1980_ and then send someone that signed message and say "see, I'm Ene1980 from Bitcointalk, you can trust me". Signed messages should always be dated, and state the purpose of the message. So in this instance, a better message would be: This is Ene1980 from BitcoinTalk. The date today is DD/MM/YYYY and I am staking address bc1xyzabc123
[/quote[ |
|
|
|
But what I cant seem to understand is how the ledger transmits data to the blockchain saying Im sending 2 bitcoins to a public key. Without accessing those private keys. Like it only transmits signed transaction data?? What is that. Ok... so going back to your original post, it seems like what you're actually thinking is "how the Ledger can "sign" a transaction, without accessing the private keys?". The short answer, is that it can't... it absolutely MUST access the private keys. However... the trick to the Ledger is that it has the "secure element". This is basically a mysterious "black box" containing all your private keys... the black box can see/access your keys... but no one else (including you) can. So, the idea is that you put in an unsigned transaction... the black box does "magic black box stuff" and a signed transaction comes back out. You can't see what is in the box, you can't access what is in the box... the box will only accept an unsigned transaction [1] as input... and will only give a signed transaction (or error) as output. It has a bunch of inbuilt code and functions and magic smoke that allow it to achieve this wizardry... but due to Non-Disclosure Agreements and lot's of secrecy... the only people that actually know exactly how the internals of this black box work are the manufacturers. Hopefully that helps... [1] - In case any pedants are here... yes, I know it will also accept "messages" for signing.  |
|
|
|
A mod bot that autolocks any thread that hasn't had an activity (to account for bumps etc) in like 1 month would be great... might stop some of the severe necroposting that happens here where someone responds to a thread from 2017 saying "I can help you recover that 1000 BTC you accidentally deleted, PM me" |
|
|
|
+1 I would also be keen for this sort of feature... I've been fairly active in some of the "wallet" sub-forums helping people recover coins from various wallets due to "broken" seed mnemonics, or wallets being deprecated or issues getting wallets working etc. Because of this, I actually get unsolicited PMs from brand new users who basically signed up just so they could PM me and ask for help. Then I have to give out email/skype etc to be able to communicate with these users as they only get 1 PM per day etc. Whatever you are saying tecshare can be done if users can whitelist other users on personal level. Instead every newbie can send unlimited message (with whom you did corresponded.) you can select them (personally whitelisting.) Once you are done with trade then you can remove them or keep them in whitelist.
I really like the idea of being able to "whitelist" individual users, regardless of rank. |
|
|
|
A lot of people have started making a lot of useless data just for the sake of merit farming.
This ---^ Don't waste merit on those threads anymore. And also This ---^ It is pretty blatant what is happening with these threads/posts... and I see they've started popping up (unsolicited?) in campaign threads as well... |
|
|
|
Question for you... did you write your 24 words on the "official" Ledger recovery sheet? I'm wondering if you wrote them on the card as: 1 2 3 4 5 6 ... 19 20 21 22 23 24 But they should be written on the card as: 1 13 2 14 3 15 ... 10 22 11 23 12 24 But at the time you first set it up and did the second checkpoint you knew which way you had written it down and so re-entered it in correct order... but now that time has passed, you've just entered them in the number order as written on the card? Just another possibility to consider... as I know of one user who did exactly this. And yes as I mentioned in the thread I crosschecked each word and all were on the list.
It's quite possible you also have the "similar word" issue... kit vs. kite... kid vs kind etc... |
|
|
|
Does a given hex seed generate the same addresses in version 2.7.9/3.0.0 and the most recent version 3.3.6? If so, that would likely rule out any behind the scenes code changes and indicate that the seed itself is wrong. For the record... I actually just tested this... I downloaded 2.7.9... created a wallet using BIP39 "seed" of: thiscouldbeanything Then I created a wallet in 3.3.6 using the same BIP39 "seed": thiscouldbeanything Both versions created identical wallets... this leads me to conclude that your issue is that you are either remembering your brainwallet phrase incorrectly... or you're doing the string to hex conversion differently (or it is producing a different result to what you previously used). As I said earlier, my personal guess would be that you have the brainwallet phrase incorrect. |
|
|
|
|
Show Posts
