That paper is unrelated to what I'm talking about. |
|
|
|
|
There's a new trend of Tor exit nodes MITMing bitcoin sites, and even using self-signed certs, which fool users who don't know better into thinking that they are now "safe" because they have an https connection.
I propose that web wallets and exchanges officially publish hidden services. Because the service is listed on your site and otherwise verified to be yours, users will know that it's the correct site. Because it's a hidden service, exit nodes can't fuck over users.
It's a win-win. The exchanges can still have full AML/KYC/whatever other privacy invading things they need, because they know who the users are when the users log in. And the users can be confident it's the right site because you the site have widely publicized the correct official hidden service URL.
To their detriment, many Bitcoin users are simply not tech-savvy enough to use Bitcoin safely. To attempt to mitigate their incompetence, they often hold their funds with websites they trust. They also attempt to use privacy software that is uncomplicated enough that they can figure out how to make it work.... Like the Tor Browser Bundle or the TAILS live OS. So when they are on an unsecured wifi or using another computer and they are scared about their bitcoins being hacked, they turn to such things in the hopes and expectations that they will help protect them.
These users may not fully understand the limitations of these tools-- what they can do, what they can NOT do, and where the potential risks and threats may be.
Having common Bitcoin sites have official Tor hidden services protects users. It's a very obvious step that needs to be done in order to increase user security, at no extra cost to anybody.
It's frankly shameful that more sites haven't done it already. (And kudos to those that have.)
|
|
|
|
Can someone kindly advise me what the issue is with Ubuntu 14 LTS installation? I'm a Ubuntu newbie but have followed the instructions and running sudo bash ./install-sx.sh file from / (root) always gives this install error: checking if g++ supports -c -o file.o... (cached) yes
checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes
checking dynamic linker characteristics... (cached) GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether we are using the GNU C++ compiler... (cached) yes
checking whether g++ accepts -g... (cached) yes
checking dependency style of g++... (cached) gcc3
checking whether g++ supports C++11 features by default... no
checking whether g++ supports C++11 features with -std=c++11... yes
checking whether make supports nested variables... (cached) yes
checking --enable-testnet argument... no
checking for boostlib >= 1.20.0... yes
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for SSL... yes
checking for CURL... yes
checking for libsecp256k1... yes
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating include/bitcoin/Makefile
config.status: creating src/Makefile
config.status: creating libbitcoin.pc
config.status: executing depfiles commands
config.status: executing libtool commands
configure: WARNING: unrecognized options: --with-libsecp256k1
Making all in include/bitcoin
make[1]: Entering directory `/usr/local/src/libbitcoin-git/include/bitcoin'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/usr/local/src/libbitcoin-git/include/bitcoin'
Making all in src
make[1]: Entering directory `/usr/local/src/libbitcoin-git/src'
CXX utility/ec_keys.lo
utility/ec_keys.cpp: In function 'libbitcoin::ec_point libbitcoin::secret_to_public_key(const ec_secret&, bool)':
utility/ec_keys.cpp:66:23: error: 'secp256k1_ecdsa_pubkey_create' was not declared in this scope
compressed))
^
utility/ec_keys.cpp: In function 'bool libbitcoin::verify_public_key(const ec_point&)':
utility/ec_keys.cpp:75:78: error: 'secp256k1_ecdsa_pubkey_verify' was not declared in this scope
return secp256k1_ecdsa_pubkey_verify(public_key.data(), public_key.size());
^
utility/ec_keys.cpp: In function 'bool libbitcoin::verify_private_key(const ec_secret&)':
utility/ec_keys.cpp:81:60: error: 'secp256k1_ecdsa_seckey_verify' was not declared in this scope
return secp256k1_ecdsa_seckey_verify(private_key.data());
^
utility/ec_keys.cpp: In function 'bool libbitcoin::ec_tweak_add(libbitcoin::ec_point&, const ec_secret&)':
utility/ec_keys.cpp:115:73: error: 'secp256k1_ecdsa_pubkey_tweak_add' was not declared in this scope
return secp256k1_ecdsa_pubkey_tweak_add(a.data(), a.size(), b.data());
^
utility/ec_keys.cpp: In function 'bool libbitcoin::ec_multiply(libbitcoin::ec_point&, const ec_secret&)':
utility/ec_keys.cpp:121:73: error: 'secp256k1_ecdsa_pubkey_tweak_mul' was not declared in this scope
return secp256k1_ecdsa_pubkey_tweak_mul(a.data(), a.size(), b.data());
^
utility/ec_keys.cpp: In function 'bool libbitcoin::ec_add(libbitcoin::ec_secret&, const ec_secret&)':
utility/ec_keys.cpp:127:64: error: 'secp256k1_ecdsa_privkey_tweak_add' was not declared in this scope
return secp256k1_ecdsa_privkey_tweak_add(a.data(), b.data());
^
utility/ec_keys.cpp: In function 'bool libbitcoin::ec_multiply(libbitcoin::ec_secret&, const ec_secret&)':
utility/ec_keys.cpp:133:64: error: 'secp256k1_ecdsa_privkey_tweak_mul' was not declared in this scope
return secp256k1_ecdsa_privkey_tweak_mul(a.data(), b.data());
^
utility/ec_keys.cpp: In function 'bool libbitcoin::verify_public_key(const ec_point&)':
utility/ec_keys.cpp:76:1: warning: control reaches end of non-void function [-Wreturn-type]
}
^
utility/ec_keys.cpp: In function 'bool libbitcoin::verify_private_key(const ec_secret&)':
utility/ec_keys.cpp:82:1: warning: control reaches end of non-void function [-Wreturn-type]
}
^
utility/ec_keys.cpp: In function 'bool libbitcoin::ec_tweak_add(libbitcoin::ec_point&, const ec_secret&)':
utility/ec_keys.cpp:116:1: warning: control reaches end of non-void function [-Wreturn-type]
}
^
utility/ec_keys.cpp: In function 'bool libbitcoin::ec_multiply(libbitcoin::ec_point&, const ec_secret&)':
utility/ec_keys.cpp:122:1: warning: control reaches end of non-void function [-Wreturn-type]
}
^
utility/ec_keys.cpp: In function 'bool libbitcoin::ec_add(libbitcoin::ec_secret&, const ec_secret&)':
utility/ec_keys.cpp:128:1: warning: control reaches end of non-void function [-Wreturn-type]
}
^
utility/ec_keys.cpp: In function 'bool libbitcoin::ec_multiply(libbitcoin::ec_secret&, const ec_secret&)':
utility/ec_keys.cpp:134:1: warning: control reaches end of non-void function [-Wreturn-type]
}
^
make[1]: *** [utility/ec_keys.lo] Error 1
make[1]: Leaving directory `/usr/local/src/libbitcoin-git/src'
make: *** [all-recursive] Error 1
sim@ubuntu:/$ sx
The program 'sx' is currently not installed. You can install it by typing:
sudo apt-get install lrzsz
Everything is fine up until this point. Any help would be greatly appreciated; have literally spent 2 days trying to work this out with LTS 12 now LTS 14 (ie I'm not here as first resort, I've RTFM!) TL;DR: Ubuntu 14 LTS, how to fix this error? utility/ec_keys.cpp: In function 'bool libbitcoin::ec_multiply(libbitcoin::ec_secret&, const ec_secret&)':
utility/ec_keys.cpp:133:64: error: 'secp256k1_ecdsa_privkey_tweak_mul' was not declared in this scope
return secp256k1_ecdsa_privkey_tweak_mul(a.data(), b.data());
^
utility/ec_keys.cpp: In function 'bool libbitcoin::verify_public_key(const ec_point&)':
utility/ec_keys.cpp:76:1: warning: control reaches end of non-void function [-Wreturn-type]
}
^
utility/ec_keys.cpp: In function 'bool libbitcoin::verify_private_key(const ec_secret&)':
utility/ec_keys.cpp:82:1: warning: control reaches end of non-void function [-Wreturn-type]
}
^
utility/ec_keys.cpp: In function 'bool libbitcoin::ec_tweak_add(libbitcoin::ec_point&, const ec_secret&)':
utility/ec_keys.cpp:116:1: warning: control reaches end of non-void function [-Wreturn-type] I had the same issue and fixed it. Make sure you have: 1- secp256k1 installed 2- libbitcoin installed To install secp256k1: $ git clone https://github.com/bitcoin/secp256k1
$ cd secp256k1
$ ./autogen.sh
$ ./configure
$ make
$ sudo make install
To install libbitcoin: $ git clone https://github.com/libbitcoin/libbitcoin
$ cd libbitcoin
$ autoreconf -i
$ ./configure --enable-leveldb
$ make
$ sudo make install
$ sudo ldconfig
You will likely need to do the following as well: $ sudo apt-get install build-essential autoconf automake libtool libboost-all-dev pkg-config libcurl4-openssl-dev libleveldb-dev libssl-dev
I still get HeadsOrTails's error of "utility/ec_keys.cpp:134:1: warning: control reaches end of non-void function" whenever I try to make libbitcoin after the configure step. Any advice or things to try? |
|
|
|
|
LOL basic economics fail OP. POW mining is exactly what gives bitcoin its value. Miners have to expend real resources and fiat (or other value) to buy mining equipment and to run it, which they won't do unless they and other miners value those costs as lower than the amount of bitcoins they mine with them. POW mining sets a base value for bitcoin. That money you think "leaves the ecosystem" doesn't leave, it *sets the price*.
|
|
|
|
|
Whoops. I scrolled past that, looking at op codes. Thanks for the explanation!
|
|
|
|
|
How is that determined? Is there a data format not listed on the wiki about scripts?
|
|
|
|
|
Can somebody explain how 0x81 translates to -1? I get the 0x01 code to push the 0x81 byte, but I don't understand why it's a -1.
|
|
|
|
New ways might have major flaws in it. I just have to wait until it will be perfect. Bip38 ec multiplied two factor keys have been around for years. You can read about how it works here: https://github.com/bitcoin/bips/blob/master/bip-0038.mediawiki#Encryption_when_EC_multiply_mode_is_usedIn short, it takes advantage of the fact that in elliptic curve math, pubkey1*privkey2 = pubkey3, and privkey1*privkey2 = privkey3. So you are giving them your pubkey1 with the intermediate code, and they create a new private key and multiply it by your public key to generate a public address, and then they give you their privkey2, which enables you to get privkey3 because you also have privkey1. Your bip38 password is run through a key derivation algorithm, and eventually also sha256 hashed, which produces a pseudo-private key, which has a corresponding public key, which is used to encrypt the entire payload. So the guy who makes the key for you can decrypt the encrypted key, but he still can't get the private key, since your privkey1 is part of the key derivation from your password before everything is sha256'd to get the shared secret between you two. So only you, with the correct password, can recreate the correct privkey1, and then also decrypt the payload, and then use privkey1 with the now decrypted privkey2 to get the actual relevant key, privkey3. Additionally, the key derivation function is scrypt, with some additional random bytes that you create. Because it's scrypt, it's really slow to brute force, and because you add in random bytes, rainbow tables won't work. The actual bip38 encrypted payload in a bip38 ec multiplied address is those random bytes, privkey2 from the guy who generated the key, and a checksum hash of pubkey3 to verify that everything was decrypted properly. That gives you all the information you need to be able to, along with the correct password, derive and decrypt everything and generate privkey3, which is the private key for the address that "belongs" to the bip38 encrypted key. (And then you can verify that everything worked with the checksum hash. If the hash doesn't match, the password entered was incorrect.) |
|
|
|
|
Unfortunately OP, this is a common occurance. Malicious Tor exit nodes are redirecting requests to known bitcoin wallets and exchanges to their own malicious version and stealing coins. Even in SSL connections. Always verify the SSL certificate fingerprint and make sure it is correct when you are doing Bitcoin related things on Tor.
|
|
|
|
The players are good, I always do better playing good players. no you just suck at adapting |
|
|
|
|
I would like to formally protest the movement of this question to the alternate currencies sub. The reason I want Scrypt is because I'm building a Bitcoin tools program and want to implement Bip38. It is entirely related to Bitcoin specifically and NOT with any alt coins. Additionally, I think the question is less likely to be answered in a less frequented sub.
Yet another reason why there should be a misc questions board....
|
|
|
|
|
Trying to install python scrypt wrapper module in Windows 7 x64 and running into all kinds of problems. Apparently nobody has been able to do it on x64 Windows, but a few have had success on win32 and just copied the site-package module folder over and that worked. I was hoping some kind soul who has it working on Windows, x86 or x64, could upload their scrypt module folder for me, since the pure Python implementation of Scrypt (module "pyscrypt" if you're interested in testing) is about 300x slower than the C implementation wrapper....
|
|
|
|
|
While you should always use a strong password, no, there is no way of knowing from the address itself how good of a password you used. The password you use, whatever it is, is hashed, and the hash is used as the AES key. So all passwords are the same "length" when the encryption actually happens.
Additionally, the hashing algorithm used is Scrypt, which is currently pretty slow on modern computers, so it takes longer to brute force. It was in fact picked for that exact reason. 4-char passwords have been posted online with bounties and taken days to crack, so a 6-char password is probably safe enough for your purpose, although obviously, just in case, you should still move the coins ASAP if you know a copy of the paper wallet was stolen.
|
|
|
|
|
The vast majority of alt-coins (or "chains" as you're calling them) still use, like Bitcoin, the secp256k1 curve, and still have 32 byte private keys and the same corresponding public keys as derived by point multiplication with the secp256k1 generator point. Therefore, the format for all of them is basically the same-- except for a different version byte prefix used whenever they are represented in base58. All this BIP is doing is using one of the BIP32 index numbers to signal a version byte. For example, the key with the hash160 of
6702F8597CC96876B6A31CD30F2DA6498BE8AAD3
can be a bitcoin address if you put a 00 in front of it, or a litecoin address if you put a 30 in front, or a namecoin address with a 34, etc etc etc.
1APgA8J71MPkCGD1xwHpWcpiU9apbppM8w
LUcdRLbw61doT4uB95H7ndtUgMx6gsdKFk
N5y3Mmo5vjVJioTXEkcPj8ydCNysWSqxwJ
Those are all addresses of different coins for the exact same key. Any coin, no matter its block time or hashing algorithm, can work with this format, as long as it uses the secp256k1 curve for its keys.
|
|
|
|
|
The SHASUMS is not signed by Gavin's Code Signing key.
It is signed by Wladimir's key, which is itself signed by Gavin's key, but still, this freaked me out momentarily when I went to verify it.
|
|
|
|
|
Yeah, got a Laxo ad myself. It was a nice treat-- paid the tx fee for me to consolidate a bunch of small outputs.
|
|
|
|
|
I genuinely like it. I like that it's "totally not an assassination market". Like seriously, it's totally not.
|
|
|
|
|
This is basically what a stealth address is.
EC math has the property that pubkey1 * privkey2 = pubkey3, and privkey1 * pubkey2 = pubkey3.
Note that one of you always has to use a private key in order to get pubkey3.
So you can generate the shared secret pubkey3, use any kind of encryption you want, with pubkey3 as the password, and send that to them along with your own pubkey, and then they will use their private key and your public key to find the shared secret which is the password to the encrypted data.
|
|
|
|
I have a way that is better, but if I told you then everybody would know!
Then it is not secure. Security must work even if everybody knows the full algorithm. That's why strong passwords and good entropy sources are necessary. If the algorithm itself is not known, then it hasn't had a chance to be publicly vetted and may be extremely insecure, and you just wouldn't know it until one day you get hacked and you can't figure out why. All good security is open source. |
|
|
|
|
You could also add a security feature where hot and cold both have stealth keys (or some other public key to generate a shared secret), and the QR data is encrypted with shared secret, so that for example the unsigned QR message from HOT doesn't get compromised en route on its way to COLD.
|
|
|
|
|
Show Posts
