You have some ideas about what the passphrase could be? Or you used something like 2i9Dz$£*"$Aç")=zàé°0"$µZ€¤^? In the first case, put that in a py file and run it: http://pastebin.com/raw.php?i=KyTQWPqs (tweaked Joric's pywallet) It will ask forever for your passphrase and will tell you instantly if it's correct |
|
|
|
|
Great, I thought your deadline would have been shorter. I'm ok to look at it if you're ok.
I just want to be sure I understand: you want to sign a message with a private key? I thought Armory already signed messages
|
|
|
|
Proposition- Hardcode current receiver files
- Hardcode an Unthinkingbit's signing address
- Create a new message type 'getrecfile', which only contains the height of the receiver file
- Create a new message type 'recfile'
- Height of receiver file -> var_int
- Pubkey that signs the receiver file -> var_str (because of compressed/uncompressed keys)
- Signature of the recever file by pubkey (signed message is Height+Receiver_file) -> var_str
- Receiver file -> var_str
I like this idea, but agree with Mark that having a single signing key is a bad idea. It seems like modifying this system so the majority determines which are the correct files to use (eg. someone sends a "getrecfile", all the nodes respond with a hash of the requested file, the client chooses to download from one of the nodes with a hash that matches the majority of hashes). I can see a few issues with this though: 1) What if you're only connected to one node and it's a malicious node? 2) What happens when a new receiver file is created - if there's only one copy how can we determine if it's from a legitimate source? This is why I suggested storing this data in the blockchain. Even just storing the hashes of the receiver files would work. That way no one would be able to forge receiver files, at least the old receiver files. And I guess you could store the signing key of the person who is intended to be the next creator of a file, so if they suddenly disappear there just isn't a receiver for that round (or also store a fallback signing key). Then have some sort of democratic system to decide which signing key gets to create a receiver file in 4000 blocks. 1) If you're connected to only one node, you know you are vulnerable anyway so ignore the recfiles 2) That's the point of signatures But we can't do just 'the majority'. It would be too easy to create tons of addresses that sign the same thing We can do this though: each person has a set of signing pubkeys (possibly weighted) he will trust. His client will then ignore all recfiles from other people. Drawback: possible fork(s!) I totally agree to store the hashes in the blockchain(*). Problem: someone needs to write in the blockchain, so: - Who? Surely Unthinkingbit, then community chosen
- Can he mine himself special blocks? How can we know these blocks are really from him? His pubkey?
- If not, does he have to convince all miners to put the hash? How can he send that hash? Email?
- How can we make the client trust HIS blocks but not others without risking forks?
- What if there's no receiver file in the block chain until we need it?
(*) but we still need to download the files. So maybe a mixed solution can be used: getrecfile+recfile which we can make non secure and just provide the file (then maybe getdata can be tweaked instead), AND hashes are in the blockchain |
|
|
|
|
Majority can still work with that system: everybody signs and broadcasts his signature
|
|
|
|
|
Also if hard-forking is the only concern we can put an extra field in 'recfile' to allow a pubkey change (newpubkey+signature by current pubkey)
|
|
|
|
Lol, I don't know anything about Linux except for that's where they usually make the viruses and that usually Linux cant get viruses.
No don't believe the lies!! lunix may look confusing at first, but it truely is superior to windows in soooo many ways.... and for the record it is the anti-virus software manufacturers who mostly write the viruses so u have to buy their product... or have i just donned my tin-foil hat?? Also, compiling windows apps/virus/etc is much much much much easier on windows, so there's no chance viruses are coded on Linux |
|
|
|
|
Devcoin itself is totally centralised
|
|
|
|
Proposition- Hardcode current receiver files
- Hardcode an Unthinkingbit's signing address
- Create a new message type 'getrecfile', which only contains the height of the receiver file
- Create a new message type 'recfile'
- Height of receiver file -> var_int
- Pubkey that signs the receiver file -> var_str (because of compressed/uncompressed keys)
- Signature of the recever file by pubkey (signed message is Height+Receiver_file) -> var_str
- Receiver file -> var_str
How it worksEverybody: - The client needs receiver_N.csv
- It sends a 'getrecfile' message with height=N to its peers
- If one of them has it, it sends back a 'recfile' message with the data
- The client checks that the signing pubkey is ok
- The client checks the signature is ok
- The client can process the received receiver file
Unthinkingbit signs a new receiver file: - Put height in a var_int
- Put receiver file in a var_str
- Concatenate those two -> msg
- Sign msg with hardcoded pubkey
- Stores the 'recfile' message
- Broadcast it to peers or wait until someone asks for it (I have a preference for the latter, it avoids spamming the network)
In case of Unthinkingbit leaves/disappears/is kidnapped- Devcoin community choses a new signing guy, whose pubkey is Pubkey2
- Fork the client and puts: Pubkey1 if Height<50, else Pubkey2
And if the new signing guy dies: - Fork the client and puts: Pubkey1 if Height<50, else if Height<123 then Pubkey2, else Pubkey3
|
|
|
|
Then either : - Bitcoin client is locking your wallet (check that it's closed)
- Your wallet is corrupted
- You need to be administrator to open a file in C: . Not likely but I'm no specialist of Windows so maybe
|
|
|
|
|
I'm interested. In how much time this needs to be done?
|
|
|
|
|
Yes you always need to be root to install something with aptitude
Yes, just sudo and it's OK
Note that installing with sudo won't make python and other things you install have root rights
|
|
|
|
|
Dump is to show the content of your wallet, that's a good thing to start with that
Looks like you told pywallet that your wallet.dat is in c:\, are you sure of that? Normally it's somewhere in some windows directories and moreover, pywallet should fill the form with this place by default
Once you can dump your wallet, I'll make you a custom pywallet to test out passphrases
|
|
|
|
If you have parts of your passphrase and/or it was short, there is some hope, and yes, pywallet can help (well, a tweaked version)
If not I don't think you'll recover them
You can still try to scan your hdd at a low level (pywallet can do this) to find private keys. It may remain some parts of your not-yet-encrypted wallet before you encrypted it
Thanks for your answer. Do you know if I can find a tutorial ? I tried to install Python + Pywallet, but I can't launch pywallet.py, I have a window appearing for 1ms and desappearing (sorry for my bad english) Run it through the command line: - Hit Windows+R, enter 'cmd'
- Then type 'c:\python27\python.exe path\to\pywallet.py --web' (you won't need the web ui but it's to show what dependencies are missing)
- Report results here
PS: In case you want to use the web ui later: - Download and install PWI (pywallet windows installer), link at the bottom of http://pywallet.tk
- That will put 4 files in the folder you provided (pywallet.bat, pywallet.py, update, and install)
- Run install.bat again (because a link to a dependency changed) and install the program
- Run pywallet.bat
|
|
|
|
|
If you have parts of your passphrase and/or it was short, there is some hope, and yes, pywallet can help (well, a tweaked version)
If not I don't think you'll recover them
You can still try to scan your hdd at a low level (pywallet can do this) to find private keys. It may remain some parts of your not-yet-encrypted wallet before you encrypted it
|
|
|
|
|
Afaik there were trades @1000BQC/BTC
|
|
|
|
I can't seem to import the private key. I made a private key awhile back and sent a good amount of namecoin to a private key now I can't seem to import the key. I googled quit a bit you guys are the only ones even talking about importing namecoin private keys.
It's exactly like importing Bitcoin private keys I don't know if NMC has an importprivatekey option, but pywallet can do it It's not exactly the topic here though, so consider opening a new thread and/or PMing me if you want |
|
|
|
|
Yeah that's pretty misleading but I made these changes when I first started to modify pywallet, that was not intended to become a real, public fork
I think it's mentionned in the readme though
When you do this you get: address, privkey, hexadecimal privkey, hash160 and pubkey
|
|
|
|
|
pywallet.py -info -importprivkey PRIVKEY ('-importhex' if privkey is hexadecimal)
|
|
|
|
But this raises the question: why didn't satoshi use sept160k1 which would have pubkeys of only 40+ digit hex (corresponding to the strength of ripemd160), instead of 64+ digit hex for sepc256?
What you're missing is that paying to 160-bit script hash is an addition that wasn't part of the original client. Originally you paid directly to the full public keys. Are you saying that you had to put a public key in the client when you wanted to pay someone? |
|
|
|
|
Show Posts
