Bitcoin Forum
June 25, 2024, 01:28:16 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 2 3 4 5 6 7 8 9 [10] 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 »
181  Other / Off-topic / Re: Please Help - Ransomware has stolen my files and I need to pay in BitCoins on: April 26, 2015, 02:00:21 PM
Any suggestions for a specific site that seems to have quick turnaround?

I signed up at localbitcoins.com because that is what was suggested by the hackers.  But nobody there will sell me 2.5 bitcoins and they want a crazy amount more than market value for them.

Regarding localbitcoins.com, were you looking in the "Buy bitcoins online in United States" section here, which typically works anywhere in the U.S. via Western Union, Moneygram, or branch cash deposits (ignore OKPay, Perfect Money, WebMoney, etc., they'll probably just make things more complicated)?

Also, DannyHamilton suggested he may be able to help you out directly: https://bitcointalk.org/index.php?topic=1037805.msg11193629#msg11193629. He's a widely trusted user on Bitcointalk.org, see here (and also a trusted escrow agent, see here), you should consider his offer.

P.S. I'm very sorry this is your first experience with Bitcoin Sad, but I do hope you'll stick around once this mess is settled.
182  Bitcoin / Electrum / Re: Generating key for long-term storage question on: April 26, 2015, 12:01:20 PM
<clipped>

Sounds like you have a pretty good handle on things Smiley.

I am also aware that Electrum servers can omit information from me, but that seems more like an inconvenience instead of an attack.  Is there any incentive to cause someone to actually do this?

It depends on your use case, but yes there can be an incentive. If someone you're sending a tx to also controls your exit node, they may be able to convince you that a tx never went through, and that you need to send another. If Electrum chooses different UTXOs for the second tx, then you've been successfully scammed. It's probably more a theoretical attack than a practical one for most people....

Instead of using ssss you should create a multisig electrum wallet.

That's a good idea, assuming that 2 of 2 or 2 of 3 is flexible enough for OP.
183  Bitcoin / Armory / Re: Armory's Entropy on an Offline Computer on: April 25, 2015, 10:10:32 PM
Thanks! Wow yeah that is a lot.  My concern is that on an offline computer, won't all that other data it grabs be very similar to other offline computers (who have nothing installed but Armory)? Or is that not a valid concern.

Thanks!

Your welcome Smiley

It is a valid concern. I don't know about Windows, but on Linux and BSDs the good news is that it's very much understood as a valid concern, and as much as possible is done to prevent deterministic RNG results: https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/drivers/char/random.c?id=refs/tags/v3.15.6#n52

Is it enough? I honestly don't know, it's a difficult problem....
184  Bitcoin / Electrum / Re: Generating key for long-term storage question on: April 25, 2015, 09:58:39 PM
I plan on doing everything inside TAILS so hopefully that erases my tracks.

I'm not clear if TAILS + Electrum is a good thing. Electrum servers do not require TLS. A malicious Tor exit node could spy on your transactions (but of course not trace them back to you easily), and I believe it could also prevent you from seeing transactions (whichever one(s) it chose). It can't easily fake the existence of transactions, nor lie about transaction contents/values though.
185  Bitcoin / Electrum / Re: Generating key for long-term storage question on: April 25, 2015, 09:52:34 PM
How much of a difference in seed generation security is there between an electrum 2.x seed over a 256-bit 1.x seed?

Assuming your 128 bits of entropy are from a good source, there's no significant known difference in security between the two today.

However, Electrum 2.x's master private key -> individual private key derivation process (a.k.a. BIP-32) is more conservative/paranoid then Electrum 1.x's derivation process. I don't think anyone knows if this more conservative approach might one day be an actual security advantage or not. I certainly don't know the answer to that one....

BTW, all this talk of seed security pales in comparison to the use of cold storage. IOW, if you're not already planning on cold storage, 128 vs 256 or 1.x vs 2.x just doesn't matter. It's like worrying over how lock-pick-proof your door is even though you leave your window open.... Wink are you planning on cold storage?
186  Bitcoin / Electrum / Re: Generating key for long-term storage question on: April 25, 2015, 04:04:48 PM
I was hoping to extract just 128-bits in a compact form such as 32 hexadecimal characters so that the output from ssss is shorter.

Electrum 1.x binary seeds are 128 bits long. They are (AFAIK) the only format that Electrum (1.x or 2.x) can easily restore from which is that short.

You could download Electrum 1.9.8 and have it create a wallet for you (after creating it, you can upgrade to Electrum 2.x), and then run the get_seed code above, or if you wanted to generate your own by hashing with SHA-256 a well-shuffled deck, I think either would be fine. Keep in mind that it's a bit dangerous since any malware that manages to get access to your binary seed as you manipulate it can steal your BTC, e.g. you don't want it accidentally stored in your .bash_history, or anywhere else for that matter.
187  Bitcoin / Electrum / Re: Generating key for long-term storage question on: April 25, 2015, 01:21:33 PM
The first is that I would prefer to split the seed in its hex form instead of its word mnemonic form.  When I run "electrum getseed" though it only outputs the words.  Is there an option or way to access the hex seed without manually creating one myself and restoring from it?

For old-style (Electrum 1.x) wallets, type this in the console:
Code:
wallet.get_seed(gui.password_dialog())

For new-style (Electrum 2.x) wallets, it's:
Code:
wallet.get_master_private_key('x/', gui.password_dialog())

Please note that for new-style wallets, if you keep only the master private key (and later restore from it), there's no way to get the mnemonic (seed words) back. This isn't a problem from a bitcoin funds point of view, but it might be an inconvenience in the future if you ever want to use your mnemonic as a backup later.


Second is that now Electrum can generate a 256-bit seed.  Is there a practical benefit to this since a Bitcoin private key can only have at most 160 bits of security?

A Bitcoin private key has at most 128 bits of security. There's no advantage of using more than 128 bits of good entropy, however it's very hard to know if your entropy is good or not.

If you're not certain of your entropy source, it might be beneficial to use more entropy. IOW, if you have 256 bits of entropy from some source, and if that source actually (unbeknownst to you) has only one bit of entropy for every two bits of output, then you end up with a 256 bit number with only 128 bits of entropy. In short: longer can't hurt, especially if the entropy source is questionable, though it may be inconvenient.


Third, I want to roll some dice and put in that as some extra entropy.  If I use the --entropy option to do this would there be a problem if the dice turned out to be biased or would this option at worst only provide no benefit?

-or-

would it be better to hash a bunch of dice or a deck of cards and use the restore function?
thanks.

Using the --entropy option with poor entropy does hurt: entropy entered via this method replaces some of the entropy (or all of it for the restore method) normally gathered from the OS. If your provided entropy is worse than what the OS can provide, this could be a problem.

Note that you can use the --entropy option with, say, a deck of cards (which is easier than dice IMO), see here: https://bitcointalk.org/index.php?topic=973997.msg10644190#msg10644190. If you're truly paranoid, you could ask for a 256 bit seed, and use the method in that last URL to provide 128 bits of entropy from a shuffled deck. That way, you'd get 128 bits from the deck, and 128 bits from the OS.
188  Bitcoin / Armory / Re: Armory's Entropy on an Offline Computer on: April 25, 2015, 12:08:13 PM
In addition to the OS's CSPRNG (either /dev/urandom or CryptGenRandom), it also mixes in:
Quote
timestamps, down to the microsecond, of every keypress and mouseclick made during the wallet creation wizard. Also logs mouse positions on every press, though it will be constant while typing. ... Then we throw in the [name,time,size] triplets of some volatile system directories, and the hash of a file in that directory that is expected to have timestamps and system-dependent parameters. Finally, take a desktop screenshot...

Please note that it only uses the sources above if you're creating a wallet via the GUI. If you're using a simple script (e.g. the one I posted a couple of days ago for creating a wallet from a deck of cards), it only uses the OS's CSPRNG for additional entropy.

FYI Bither is the only other wallet I know of which goes to similar lengths for collecting additional entropy like this.
189  Bitcoin / Armory / Re: Clarifying armoryd software license on: April 24, 2015, 07:57:14 PM
First off: pretend that "IANAL" is added to every single opinion you see below. With that said....

Is the AGPL enforceable? I've absolutely no idea. It's probably the most copylefty license out there, though.

Is ATI's application of the AGPL to armoryd's JSON-RPC interface enforceable? Again, no real idea, although it seems like a stretch to me.

Is ATI's desire clear? Yes, unless a principal at ATI steps forward with a different statement, I'd say it's pretty clear. They don't want anyone using armoryd with an Internet-facing service unless you open-source that service, or seek an alternate license from ATI.

Will I ever use armoryd for such a project? Almost certainly not; I find the terms of such use far too burdensome. (not that this is a threatening a statement... I have no particular uses in mind as I write this)

Is it not the whole point of Bitcoin to begin with that trying to control abstract concepts is rather pointless?

Perhaps, but there are plenty of options released under a multitude of licenses out there. Some are completely closed-source (I don't touch those), some are source-code-available but not open source (I avoid them too), some are copyleft and some are permissive. ATI is free to make it's own choice. I think the marketplace is fully capable of choosing winners and losers from the bunch.

The statement above from ATI general counsel implies there exists a legal threat to those that do not respect this so-called "license".

Although I didn't read his post that way, the fact is that every piece of copyrighted content (rightfully) carries this inherent threat if misused. Of course I'm happy to argue that copyright law needs a major overhaul in my country (U.S.), but that doesn't change the current state of things.

If you release a piece of information publicly, you cannot reasonably expect to maintain "control" over that information by definition.

Just in the interest of not starting a flame war Wink, is it OK to limit this thread to ATI's particular choice of license, and leave out the more general copyright/left/permissive debate?

Ok then, I hereby state that anyone who replies to this thread or any other on bitcointalk.org about IP is agreeing to a contract that agrees with whatever I say about it. You're saying you don't agree? Well, you are, of course, free to choose to not enter into my contract by not expressing views on IP that constitute reneging this incredibly valid contract. Happy now?

Still not a lawyer here, but I'm nonetheless quite confident that your licensing terms are unenforceable, and so I'm daring to ignore them.

We do share a similar opinion, though: the thought that everything which touches armoryd's JSON-RPC interface is tainted by AGPL is too copyleft for my taste.
190  Bitcoin / Armory / Re: Clarifying armoryd software license on: April 24, 2015, 04:40:59 PM
I was personally less interested in a legal interpretation, and more interested in ATI's intent when choosing the license they've chosen (so that I and others can respect that intent). You've made the intent perfectly clear.

Thank you for taking the time to respond, it's much appreciated.
191  Bitcoin / Mycelium / Re: Mycelium for iOS not working on: April 24, 2015, 03:07:38 PM
Would be good if someone from Mycelium team put some effort too and inform as about what they are doing. We have our btc stuck there Sad.

They've been doing a good job keeping people up to date over on Reddit: http://www.reddit.com/r/Bitcoin/comments/31o5zn/mycelium_ios_wallet_status_update/cqkglk1
192  Bitcoin / Mycelium / Re: Mycelium for iOS not working on: April 24, 2015, 02:54:02 PM
However I only got the main wallet and not the savings wallet that I had.

Do you mean that you had two accounts set up in Mycelium, both from the same seed?

If so, and if you're desperate, there is a way to import your second account into an Electrum 2.x wallet. I'll write up some instructions if you like, however:
  • it's not very safe, since you'll be dealing with your seed and an extended private key,
  • therefore after doing this sort of import, you should probably transfer all your btc to a new wallet and stop using the old one.

Let me know....
193  Bitcoin / Armory / Clarifying armoryd software license on: April 24, 2015, 12:50:34 PM
Armory is released under the Affero GPL v3 software license.

According to the GPL FAQ:

Quote
Where's the line between two separate programs, and one program with two parts? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged).

If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.

By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.

(emphasis mine)

IOW, it seems likely that software which uses armoryd's RPC interface is probably a separate program which can have a different license or even be closed source, but short of some new court decision, it's not entirely clear. If such software isn't considered a separate program, then it must also be licensed under Affero GPL v3. Furthermore, if such software is accessed over the Internet (e.g. an armoryd-based block explorer, storefront, etc.), then the entire source code must be made available for download (as per the Affero GPL).

So, I'd like to make a small request: could this be clarified one way or the other, perhaps right in the armoryd.py file itself?
194  Bitcoin / Bitcoin Wallet for Android / Re: Is there a guide for importing my Android Wallet to a desktop app? on: April 23, 2015, 11:09:57 PM
Hello,

The subject pretty much says it.  I am looking for a guide to export the private keys so they can be imported into Multibit, Armory, etc.

Thanks.

It is possible to extract your mnemonic (seed) from an Android Wallet backup file, and then use it to create a MultiBit HD wallet (via its restore option) which has the same addresses/private keys. However....
  • messing around with your mnemonic can be dangerous (from a loss-of-funds/malware point of view)
  • MultiBit HD is still in Beta and not yet recommended for everyday use
  • it requires the latest version of MultiBit HD (Beta 8, it won't work with earlier versions)

If you still want to proceed, see here for more info on extracting your mnemonic: https://github.com/gurnec/decrypt_bitcoinj_seed
195  Bitcoin / Armory / Re: Inputting Your Own Entropy on: April 22, 2015, 04:56:34 PM
Along the lines of what picobit was thinking, here's a Python script to do this.

It will ask you for a new wallet password, your entropy (e.g. "3s ad 9h tc 4d"....), and whether or not you'd like it to add additional OS-supplied entropy, and then it will ask Armory to create a wallet file (in its usual location).

It needs to run on a machine which already has Armory installed. If you choose not to add additional OS-supplied entropy, be certain you only run this on an offline/cold storage machine. Please close Armory before running it, and when you start Armory after running it the new wallet will be listed in the GUI.

Code:
import sys, os

# Try to add the Armory libraries to the path for various platforms
if sys.platform == "win32":
    progfiles_path = os.environ.get("ProgramFiles", r"C:\Program Files")  # default is for XP
    armory_path    = progfiles_path + r"\Armory"
    sys.path.extend((armory_path, armory_path + r"\library.zip"))
    # 64-bit Armory might install into the 32-bit directory; if this is 64-bit Python look in both
    import struct
    if struct.calcsize('P') * 8 == 64:  # calcsize('P') is a pointer's size in bytes
        assert not progfiles_path.endswith("(x86)"), "ProgramFiles doesn't end with '(x86)' on x64 Python"
        progfiles_path += " (x86)"
        armory_path     = progfiles_path + r"\Armory"
        sys.path.extend((armory_path, armory_path + r"\library.zip"))
elif sys.platform.startswith("linux"):
    sys.path.append("/usr/lib/armory")
elif sys.platform == "darwin":  # untested
    sys.path.append("/Applications/Armory.app/Contents/MacOS/py/usr/lib/armory")

from armoryengine import PyBtcWallet
from CppBlockUtils import SecureBinaryData
from hashlib import sha256
from getpass import getpass

# Hack to prevent Armory from overwriting an existing wallet file
def open_noclobber(name, mode='r'):
    if 'w' in mode:
        if os.path.exists(name):
            raise IOError("won't overwrite existing file '{}'".format(name))
    return open(name, mode)
PyBtcWallet.open = open_noclobber

password = getpass('Password>')
if not password:
    sys.exit('A password is required')
if getpass('Verify password>') != password:
    sys.exit("Passwords don't match")

cards = raw_input('Cards> ')
if len(cards.replace(' ', '')) < 50:  # 2 letters per card
    sys.exit('Requires a bare minimum of 25 cards')
entropy = sha256(cards).digest()

if raw_input('Also add additional OS-supplied entropy (Y/n)? ').lower().strip() == 'n':
    wallet = PyBtcWallet.PyBtcWallet().createNewWallet(plainRootKey=entropy, securePassphrase=password, doRegisterWithBDM=False)
else:
    wallet = PyBtcWallet.PyBtcWallet().createNewWallet(extraEntropy=SecureBinaryData(entropy), securePassphrase=password, doRegisterWithBDM=False)

print 'New wallet created with ID', wallet.uniqueIDB58

(consider it released under The MIT License)
196  Bitcoin / Electrum / Re: Electrum Major Problem on: April 22, 2015, 11:35:44 AM
It sounds like you're wondering why your transactions and bitcoin address history was showing up even though you encrypted your old Electrum wallet.

I didn't interpret OP's post way... I thought OP was saying that Electrum somehow found their wallet even though OP didn't copy it from the old HD to the new and didn't do a restore.
197  Bitcoin / Armory / Re: Inputting Your Own Entropy on: April 21, 2015, 11:40:25 PM
I've read in quite a few places how to sort of be your own RNG, using dice or cards, to create a private key.  I have read a few different ways to do this with Armory and would like some clarification please on how to best do this.  I feel that cards would be the best way, because you don't have to worry about the weight of the dice being perfect.

I also think cards are the easiest way, but they do have some pitfalls. See here for a good discussion on how to shuffle well enough to provide sufficient entropy: https://bitcointalk.org/index.php?topic=682842.0
198  Other / Beginners & Help / Re: How long, strong should a bitcoin wallet pass-phrase be? on: April 21, 2015, 07:27:43 PM
This might be of better use: https://howsecureismypassword.net/
this is a cool link, i bookmarked it for later references. and according to it the kind of passwords i use will require 8 quintillion years to be cracked by a desktop pc Cheesy

...and...


The kind of passwords I use:

Quote
It would take a desktop PC about
285 nonillion years
to crack your password

Don't put your faith in password estimators (read the rest of this thread), but if you insist on doing so, at least use one of the others mentioned here. howsecureismypassword.net isn't very good.

edit: actually, it's terrible. For the password "passwords99", it has an estimate of 1 year! zxcvbn estimates that same password at 16 seconds, much better.
199  Other / Beginners & Help / Re: How long, strong should a bitcoin wallet pass-phrase be? on: April 21, 2015, 05:59:07 PM
The conclusion of one of the papers:
Quote
The password as an authentication mechanism is headed for obsolence, as the password lengths required to thwart rainbow table attacks are rapidly approaching unmanageable (or unrememberable) proportions.

I admit I didn't read the referenced papers, however that conclusion is ridiculous. A simple 8+ byte random salt as already used by most* Bitcoin wallet software today easily defeats rainbow table attacks.

* Electrum (1.x and 2.x) and MultiBit HD are two notable exceptions of wallets which don't use salt.
200  Other / Beginners & Help / Re: How long, strong should a bitcoin wallet pass-phrase be? on: April 21, 2015, 03:49:31 PM
As long as we're talking about favorite strength checkers, here's mine: https://dl.dropboxusercontent.com/u/209/zxcvbn/test/index.html

It's the open source javascript-only checker used by Dropbox. There's a description of its strengths and weaknesses here: https://blogs.dropbox.com/tech/2012/04/zxcvbn-realistic-password-strength-estimation/

i don't know who is right, but with "my name is" the first that i posted say 3 hours, instead your say 1 year approximately

also it say crack time 35M seconds which is about 1 year and then crack time display 3 years? are those two not the same thing?

I don't understand.... when I try "my name is" in the one I linked above (zxcvbn), I get back 5 hours. More on point, it turns out the first one (my1login.com) is using the same underlying zxcvbn javascript library (but maybe a different version of it).

Regardless, the answer to "who is right" is: nobody. As the article I linked above discusses, estimating crack times of a password is very hard, and often attackers have access to resources (e.g. gigantic n-gram tables) which are just too impractical for javascript checkers like these to include.
Pages: « 1 2 3 4 5 6 7 8 9 [10] 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!