My apologies, I misunderstood the LXC comments (i.e. I now know what an LXC is  ). I've got a clearer idea of how this can be done with my setup thanks to the guide you linked to, and I think I understand the rationale: as long as you've got a Linux guest running, the hypervisor doesn't matter if you can create a working LXC container for Ubuntu 14.04 using that guest. The terminology gets confusing because I think you and I are use the word "guest" in different contexts.... but yes that all sounds right. The "guest" of the hypervisor can be anything that you can run Gitian on, including Debian, Gentoo, etc. If this guest machine is a Linux machine, the build machine which runs underneath it can be an LXC container (otherwise it needs to be an "inner" KVM or VirtualBox). If using LXC, these two machines share the same kernel. The build machine's OS must be whatever the project says it is. I think this may be answering another question for me: it seems like the 14.04 container gitian uses shouldn't be getting package updates in order to preserve the build determinism, and the setup script for LXC suggests the same.
Perhaps you're right, it shouldn't, but it does. When you first run make-base-vm, it does the equivalent of an 'apt-get dist-upgrade' on the build (innermost) machine. Each time you run gbuild after that, a new clone of the base-vm is created (and not updated again) and used for that build. Builds are reproducible, and multiple people, if they run make-base-vm within a reasonable amount of time of one another, will generally see the same results. However builds are not completely deterministic—if you try to build today a particularly old version of, say, Bitcoin-Qt, you may end up with a different result than is available for download. It's unfortunate, but it's just the way it currently is. This is partly vmbuilder's fault, which creates VM images by downloading and installing (via debbootstrap) .deb files from the package archives (as opposed to say using .deb files from an ISO), and perhaps partly the fault of Canonical who doesn't guarantee that old versions of updated packages will always be available in the archives. On the plus side, builds from newly created base-vms will pick up security fixes pushed out by Ubuntu. |
|
|
|
Hum... Version 4.24, https://github.com/schildbach/bitcoin-wallet. That help? It was an actual peice of paper... I threw it out.. :S.. Pretty sure I am screwed lol, o well. I sent coins to it from my one phone and imporated it with the other.. alas I recorded that address as my "new phone" address.. bad move. Just thought maybe my old phone stored the private key it scanned but I have my doubts. I really had no intention to reuse the wallet. There seems to be a bit of guessing going on in this thread.... regardless OP, you are unfortunately right.  The Schildbach wallet will not import private keys. It can sweep the current UTXOs, after which it discards the private key. Regarding whether or not the Schildbach wallet is solid: I certainly think so. While there may be other wallets that offer some useful features not offered by this one, the Schildbach wallet offers superior privacy compared to any other android wallet (that I'm aware of). Only breadwallet for iOS offers similar privacy features. Edit: I forgot about Bither, sorry.... |
|
|
|
I may need to at least wait until I can get a 14.04 template for my host (apparently very imminent now they have Wheezy working
Perhaps you missed something above? You can use Wheezy as the Gitian host, you just need a workaround as mentioned above by josephbisch. The instructions for building Bitcoin Core contain two very relevant sections: After that, gitian handles downloading and creating the Ubuntu guest LXC, which runs fine on Wheezy. |
|
|
|
I'm using Xen as a host, and according to the gitian documentation I found, only KVM and VirtualBox are known to work. Will this be a massive job to configure?
You could try Xen -> Debian/Ubuntu host -> LXC guest |
|
|
|
When you say your "investors" you mean the victims of the ponzi scam, don't you? You shouldn't do this. Seriously just don't.
If you put your efforts towards some useful project I will help you. But of course I wouldn't help creating this ponzi site, especially when you call it "investment" which means it's not even transparent.
Dude I know you think I may be scam but I am legit not a scam and will not ever steal from anyone!! I just want to do something for others while getting a little bit of it(1%) *sniff* *sniff* .... Nope, completely fails the smell test. Also, it doesn't help that you rudely crossposted (a.k.a. advertised) in at least three different subforums?! |
|
|
|
As it is based on DNS, how do you prevent DNS hijacking?
There are (at least?) two proposals mentioned. This one is more about how a payee can prove that an address they give to a payer in fact belongs to the payee (and hasn't been modified by a malicious third party), and at the same time: - the address can be generated in a "complicated" way, such as from an HD and/or multisig wallet;
- the payee does not need to publicly publish something new for each new address (they only need to publish a single "master verifying key"*)
- the "master verifying key" is not a BIP32 master extended public key; in other words it can't be used to violate the privacy of the payee / generate other addresses
The method of publishing this "master verifying key" isn't detailed in the above proposal, but DNS is mentioned as a possibility, in which case the spec recommends it be signed by a DNSSEC zone signing key. This proposal is is about the DNS side of things. It mentions some of the concepts mentioned in the above proposal, but doesn't really detail them. It does detail the DNSSEC issues though. The two seem like they should be linked to one another, but they're (currently) not (just because they're still drafts? don't know...). For example, the first proposal talks about BTCA DNS resource records (for which google can't find any spec), while the second details PMTA records. * I just made that "master verifying key" term up, the spec uses more precise terms |
|
|
|
So what is the process to re claim your old wallet if say your computer crashes and all your files were deleted?
That sounds like a frequently asked question to me  |
|
|
|
Yeah just copy and paste.
df ~ gets me this:
Filesystem 1K-blocks Used Available Use% Mounted on
/home/nuke/.Private 149545252 7287928 134637740 6% /home/nuke
Oh... you're using ecryptfs-style home directory encryption. That makes things a lot more difficult and also a lot less likely to succeed. I just tried running a test where I overwrote 5 encrypted files and deleted 5 others, and then tried to recover them, and it didn't succeed for any of them. Short of a professional service, I doubt you have much recourse (and even then it seems unlikely).  |
|
|
|
In fact the British producer that worked on the songs you heard (David) is a huge BTC/KNC enthusiast (pretty much the main person to introduce me to KNC's) and he's built himself a special rack for miners to use them for central heating during winter
I'm actually glad to see you post this. You might recall the PM I sent you back in October? What I didn't say is that I had a second identity in mind of who I thought you might be...: David. Of course I hoped I was wrong about that (and think I am ). |
|
|
|
As soon as I enter that in the terminal it asks for my password then nothing just a new command line appears straight away.
You are entering your password when asked, correct? After that, it should take 10s of minutes before it completes and displays another shell prompt (if I got it right). Are you copying and pasting the line (there are a number of different quote characters, it'd be easy to get one wrong if you're not copying and pasting)? What does this give you? It should give you two lines like this, or is it different? Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda1 8640920 6298256 1880688 78% /
|
|
|
|
That code doesen't seem to do anything in the terminal even with another wallet.
Do you mean that you created a new empty Electrum wallet, and the code doesn't find it? Does it take a while to finish running, or does it return right away? Is your wallet file saved in the default location? |
|
|
|
Someone suggested Pywallet for recovery.
Would this help with my situation or any other programs out there that would? And how do I go about installing it on Linux?
All I have is the assumed corruped default.wallet file and a list of two addressess in the wallet with coin.
pywallet will not find Electrum seeds or xprvs. For Linux, run this in a terminal to search your drive: sudo strings -100 `df ~ | tail -1 | cut -d' ' -f1` | egrep '"x/1?": "|"seed": "' | egrep -v '"xpub|strings' If it outputs any lines, save them and let us know how many "seed" or "x/" lines it found. |
|
|
|
Windows 7 ultimate. I am in the Armory folder but I do not see neither of the two .txt files I need to delete. Are they in a folder within the armory folder?
On Win 7, it should look something like this (note the path at the top); does yours look different?  |
|
|
|
How about TimeVault or the Microsoft version of that? Got that running?
It sounds to me that OP only ever set one password for this wallet, and forgot it... if so, that wouldn't help... (Also for the most part the Windows "previous versions" feature only works for documents if you've set up Backups, which isn't all that common....) And now for a somewhat on-topic shameless self-promotion: btcrecover (a password recovery tool) supports Armory, and has some advantages (and disadvantages) compared to the script supplied with Armory (faster, more flexible, harder to use), although it's not any more useful in this case, sorry.... edit:You're not going to believe it, but after days and days i remembered it! It just came to me! I've immediately created a paper back up!  That's great! You can just ignore all the rest above  |
|
|
|
Yes, this may be exactly what I want. Is ver. 4.12 using an HD seed?
Yes, as of version 4.0, but please be aware that if you used to run a 3.x version and then upgraded to a 4.x version, your wallet and its backup will contain both HD keys and "loose" keys, the latter of which are not backed up by the seed. EDIT: just began looking more closely at the program, seems it's a gui clicky thing. I may indeed pull out the actual method here and set it up to run on the command line as it's what I'm more comfortable with.
If you run it as so, it prompt you for info in the terminal and will not do any GUI. ./decrypt_bitcoinj_seed.pyw bitcoinj-wallet-file If you'd rather use it as a library, you can do something like this: import decrypt_bitcoinj_seed
backup_password = '...' # or None if you've already done the OpenSSL-style decryption
spending_pin = '...' # or None if there is no spending PIN
with wallet_file as open('bitcoinj-wallet-file', 'rb'):
wallet = load_wallet(wallet_file, lambda arg_ignored: backup_password)
mnemonic = extract_mnemonic(wallet, lambda arg_ignored: spending_pin)
print mnemonic
|
|
|
|
What you probably will want is access to the HD seed (which is used to derive all the private keys).
This is an open source tool that will extract the HD seed from a wallet backup file: https://github.com/gurnec/decrypt_bitcoinj_seed (please note that this tool is not endorsed by anyone.... but me -- and it's none too wise to download and run stuff like this from strangers). Given the seed, you can use tools such as this one to derive addresses and keys from it: https://dcpos.github.io/bip39/. Use the "Hive Wallet" derivation path for external addresses/keys. Use "BIP32" with a derivation path of "m/0'/1" for your internal/change addresses/keys. You can also use the seed with a compatible wallet (MultiBit HD, Hive web or mobile, or breadwallet). tspacepilot: I realize you know this already, but it's worth repeating for anyone else reading this... messing around with your seed and keys in such a manner is just asking for trouble / bitcoin loss. It's fine for educational purposes, but that's about it. |
|
|
|
OP's particular issue doesn't look like it was fixed, but the fix is just a small change. Modify this line: addrStr = str(self.widgetTable[row]['QLE_ADDR'].text()).strip() to something like this: addrStr = unicode(self.widgetTable[row]['QLE_ADDR'].text()).strip().encode(errors='replace') or this if you'd rather use Qt's whitespace stripper instead of Python's (both seem to work for OP's example): addrStr = unicode(self.widgetTable[row]['QLE_ADDR'].text().trimmed()).encode(errors='replace') If an Armory dev doesn't happen to notice this thread, it'd make sense to open an issue on GitHub. |
|
|
|
That's definitely not a normal Electrum wallet file—a normal one would contain a bunch of readable text. I'd suggest you look over here: https://bitcointalk.org/index.php?topic=998480.msg10842688#msg10842688As an aside: this is the third or fourth time in just three weeks that someone has posted about a corrupted Electrum wallet file... I wouldn't call that a pattern just yet, but it's getting close.... |
|
|
|
|
Show Posts
