Hi Fireball, There is still something wrong with the documentation of BTCUSD variation margin ( https://icbit.se/BUH3 ). On your web page, W/R is still -0.1 where it should be -10 USD in order to give the correct result. Should the equation read R/W instead (due to the prices being reciprocal)?. By the way, why confuse the issue by introducing the minimal price step and its cost, when it is clearly the contract size that enters into the calculation? Hi Fireball, There seems to be something wrong with the equations giving the variation margin on your web page. The actual calculation is OK, it is just the web page that gives the wrong expression. The variation margin should be the price difference times the size of the futures contract. As the actual contract is a futures contract for -10 USD, traded in BTC, but the price is listed as the price in USD/BTC, a reciprocal comes in, confusing matters a bit, and the equation becomes (on your web page): Vm = (1/p2 - 1/p1) * W/R Here 1/p is the "real" price (in BTC/USD), and W/R should be the contract size, i.e -10 USD, giving a variation margin in BTC. However, on the web pages https://icbit.se/BUZ2 and https://icbit.se/BUH3 you list W = 0.0001 USD and R = -0.001 USD, giving W/R = 0.1 (no unit). So both the magnitude and the unit is wrong. The example at the bottom of the page correctly uses W/R = -10 (but leaves out all units). And the actual variations margins calculated in your trading platform are correct as well, fortunately  I have not looked closer into the Gold and Oil options, but since the prices here are listed in BTC I am a bit surprised to the reciprocal of the price in the equations. |
|
|
|
There's no way users will pick a different passphrase for their private keys and their public keys, and that makes this a pretty significant risk...
Actually, blockchain.info essentially does this, and I did not even consider making the two passwords the same. Anyway, it should be easy to disallow that the two are identical. |
|
|
|
Now I see why your ignore link is starting to change color. I'll help it along.
I hope he is not behaving like this in real life, otherwise he will run into trouble quickly! The key is on a keyserver. It just isn't in his keychain or the keyserver he queried. I don't automatically add etotheipi's key to your keychain because the git verify-tag command does it automatically. I've queried a bunch of keyservers for this key and every one has worked but pgp.keyserver.com. You have to manually upload and verify your key with them.
The key is definitely on keyserver.ubuntu.com
Looks like the keyserver that was the obvious one to use back when I configured my gpg installation (last century, probably!!) is no longer current. Switching to Ububtu's fixed the problem. Everything now works just fine. Thanks again for the homebrew formula, Red Emerald! |
|
|
|
Apparently they could not be bothered with putting the key needed on a key server that is what the error is telling you.
Red Emerald is actually making an unpaid effort to help us install Armory in an easier way. You really are quite hostile to him! Most likely my gpg setup is querying the wrong keyserver. While it would be nice if things worked in the first try, sometimes it takes a few attempts before such a setup script works for everyone. |
|
|
|
I tried the updated tap - sure enough, now it called gpg (but it also first replaced my ancient gpg installation with homebrews ...) Now it gives a new error, perhaps my gpg is not set up optimally, I rarely use it. $ brew upgrade
==> Upgrading armory-qt
==> Cloning https://github.com/etotheipi/BitcoinArmory.git
Updating /Library/Caches/Homebrew/armory-qt--git
==> Checking out tag v0.86.3-beta
==> Patching
patching file ArmoryQt.command
==> git verify-tag v0.86.3-beta
gpg: requesting key 98832223 from ldap server keyserver.pgp.com
gpgkeys: key 4AB16AEA98832223 not found on keyserver
gpg: no valid OpenPGP data found.
gpg: Total number processed: 0
gpg: Can't check signature: public key not found
READ THIS: https://github.com/mxcl/homebrew/wiki/troubleshooting
Now it is compiling with the --skip-verify flag, no problems so far. |
|
|
|
Dear Red Emerald, Thanks a lot for making this tap. It really makes it a lot easier - except that this time I run into a snag: $ brew upgrade
==> Upgrading 3 outdated packages, with result:
armory-qt 0.86.3-beta, netpbm 10.60.05, sqlite 3.7.15
==> Upgrading armory-qt
==> Cloning https://github.com/etotheipi/BitcoinArmory.git
Updating /Library/Caches/Homebrew/armory-qt--git
==> Checking out tag v0.86.3-beta
==> Patching
patching file ArmoryQt.command
==> git verify-tag v0.86.3-beta
error: cannot run gpg: No such file or directory
error: could not run gpg.
READ THIS: https://github.com/mxcl/homebrew/wiki/troubleshooting
Note that I do have gpg installed, and can run it from the command line: $ gpg --version
gpg (GnuPG/MacGPG2) 2.0.17
libgcrypt 1.4.6
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Home: ~/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA
Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128,
CAMELLIA192, CAMELLIA256
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2
|
|
|
|
Starting on January 5th, 2013 all MPEx accounts that have a zero BTC balance and zero holdings of any kind (including any stocks, shares, options, futures, funds, also including any sums deposited as collateral for option or future issuance) will be disabled. This means you will not be able to use MPEx (”Unrecognized signature. Please email your public key first.” error.) Starting on February 5th, 2013 all MPEx accounts that have been disabled as per above and have not been reinstated will be purged. This means all account data will be deleted. Accounts’ signature will be replaced with MPEx’s own in our trade history databases. Signed receipts will be discarded. You will not be able to file any claims for anything whatsoever after this date.In order to reinstate a disabled account you can contact us any time after January 5th, 2013 but before February 5th, 2013. Your account will be re-enabled on request, however, if your balances etc are still zero on February 5th, 2013 your account will still be purged.This will be a recurring yearly event. Please plan your account management accordingly. Original article. MPOE-PR: If anybody else had posted this, you would have been the first to call it shady business practises or something like that. If anybody have shares but are not actively trading, they loose the ability to access their assets  |
|
|
|
Closing positions prior to settlement seemed to be the smart move Looked like a hot potato to me, so I got out of BUZ2 not long after BUH3 opened.
I honestly did not expect trouble, but clearly settlement was a special time, so if anything was going to go wrong, that would be a likely time for it to happen. So I got rid of my small position in BUZ2, and planned to withdraw all the bitcoins. But those overpriced BUH3s were sooo tempting |
|
|
|
OK guys, good news.
After speaking to other important community members, I decided to take all the risk on myself for BUZ2 and
NO PRICE CAPPING will happen. You get what you got at settlement. That's as honest as it could be. This means, I'm paying for the balance of those users who went negative when so actively shorting BUZ2. Being honest means being honest - you played according to the ICBIT rules, and ICBIT plays according to the rules.
BUH3 and other contract's will stick to the terms of the worst case scenario as explained on the website (forceful counterparty position liquidation) to prevent such situation from happening at all.
Good? :-)
You just proved you quality! I will now leave BTC on icbit.se with more ease of mind. Disclaimer: I had no BUZ2 at closing time, having switched to BUH3. |
|
|
|
Wasn't margin calls supposed to prevent this?
It is exactly for this, but for the beginning period we had it was not possible to forcefully buy 14k of BUZ2 contracts. There just were not enough sellers. And for this bad moment I listed two solutions above. According to your page on "Margin Call", that should have resulted in the "worst case scenario", forcibly closing the positions at that time. Clearly, some people would have lost part of their profit at the time, but that was part of the deal, you had stated that clearly on your page. By not closing them at the time, you took the risk that their accounts would go negative - or did you hope that the rate would change, solving the problem in time, and instead the reverse happened? In that case, you chose to risk your own money, in my opinion. |
|
|
|
|
Wasn't margin calls supposed to prevent this?
|
|
|
|
|
Wow, you are amazingly fast!
I can confirm that it works as expects (i.e. great).
The "brew fetch" command is not really necessary, but I guess that it gives the truly paranoid a chance to check what is being installed.
Thank you very much, indeed!
|
|
|
|
Hi Fireball, There seems to be something wrong with the equations giving the variation margin on your web page. The actual calculation is OK, it is just the web page that gives the wrong expression. The variation margin should be the price difference times the size of the futures contract. As the actual contract is a futures contract for -10 USD, traded in BTC, but the price is listed as the price in USD/BTC, a reciprocal comes in, confusing matters a bit, and the equation becomes (on your web page): Vm = (1/p2 - 1/p1) * W/R Here 1/p is the "real" price (in BTC/USD), and W/R should be the contract size, i.e -10 USD, giving a variation margin in BTC. However, on the web pages https://icbit.se/BUZ2 and https://icbit.se/BUH3 you list W = 0.0001 USD and R = -0.001 USD, giving W/R = 0.1 (no unit). So both the magnitude and the unit is wrong. The example at the bottom of the page correctly uses W/R = -10 (but leaves out all units). And the actual variations margins calculated in your trading platform are correct as well, fortunately I have not looked closer into the Gold and Oil options, but since the prices here are listed in BTC I am a bit surprised to the reciprocal of the price in the equations. |
|
|
|
Red Emerald: Are you going to release 0.86 in homebrew, too? Not that it is hard to compile by myself, but your homebrew formula is easier |
|
|
|
Wow! 700 billion bitcoins in circulation. We are taking over the world. |
|
|
|
I do not own a safe, so if someone were to break in my house and get to the paper backup, the funds would probably be gone before I would realized it had been stolen. So my idea is to have hdd backup of the wallet with a strong passphrase, and a single copy of a paper wallet with a weak enough passphrase that I could bruteforce it in a decent amount of time in case I would forget it, but would give me enough time to clear the funds out if someone were to steal it. I hope that makes sense.
That would be a most unusual burglar. 99% of burglars would say "crap, a piece of paper, not money, not drugs ... worthless". The last percent would actually look on the paper before saying "what a nerd" and throw it away. |
|
|
|
|
I got it yesterday on my Mac, but first it printed that it had lost connection to the Satoshi client, so I assumed that was the problem.
|
|
|
|
|
Just tried Red Emerald's brew tap. It works as expected, thanks a lot!
Regarding the trust chain: I think it would be a good idea if etotheipi publishes the SHA hash of Red Emerald's brew script on his web page. Then users can verify that script, and as the script contains the SHA of the downloaded tar file, that is automatically verified as well. The only remaining attack vector is then malicious code put into some of the dependencies, but that would then almost have to be done by somebody outside the bitcoin ecosystem. I am not sufficiently paranoid to worry about that.
Of course etotheipi or Red Emerald could SHA sign all the dependencies as well, but that would honestly be a PITA since they are updated without warning.
|
|
|
|
It does not look like making an app is that hard - I made one by accident the other day While looking for a solution to the printing problem in Mac OS X, I found a small test example showing a similar problem. The test example consists of three small source files, bulding into a .app ! You can find the files print.pro, print.h and main.cpp here: https://bugreports.qt-project.org/browse/QTBUG-17913Then you just type "qmake" at the command line, and qmake writes a Makefile. The Makefile then builds print.app It should be possible to work out how the Makefile does it, at least if you cheat and look in the print.app directory as well. The "Application Bundle" (.app) is a directory that MacOS insists on showing like a file. I don't know if it is the .app suffix or a special file attribute that does the hiding. |
|
|
|
So what's the lesson? 5 letter passwords are crackable within a day by any sysadmin. 7 letters are probably crackable within a day by a botnet. 8 and more are impossible to memorize. Passwords in general, can't be considered secure anymore.
No I don't think so. This thread had been going 2 or 3 days before anyone cracked it, and that was only after casascius gave enough information to cut the possible solutions in half. Furthermore, the password didn't have any numbers or any other special characters. A random 5 letter password which we know nothing about would take more than a day to crack even with multiple computers. Actually, he gave info that cut the search space by a factor of 2^6 = 64 by giving the case of all letters, and that the first was from the second half of the alphabet. A five-letter random password is clearly not sufficient, but surprisingly robust for this application. Looks like I would have found the password in a few days. I permuted the alphabet to search in another order than everybody else (since I started late), and managed to place W last |
|
|
|
|
Show Posts
