.... your 100 contracts cost $0.02 per day (100 contracts X 0.0001 BTC X 2 clearings per day).
Didn't you mean 0.02 BTC per day. That is 200 times more expensive. With some of the other futures the fee is really heavy. If you deposit X BTC and buy BUZ3 or BUH4, you have already used 10% of the deposited BTC on fees, and will use another 10% when selling. On top of that comes the large spread. Normally with such a large spread it would pay to make a market-making bot that places orders inside both sides of the spread (and tries to keep the total balance close to zero). Such bots would reduce the spread, but the fees makes it impossible to do that. |
|
|
|
The makefile was updated by goatpig to do a more-intelligent search for the python dependencies. It's very possible that you may need to just branch that whole section if compiling on OSX/Darwin.
Yes. It looks very complicated considering that Python normally knows where its stuff is (e.g. os.path.join(sys.prefix, "include/python2.7") for the include files). On the other hand, Python can actually get confused and report the wrong place perhaps goatpig's script is more reliable. When it comes to building an OSX app, it looks like I can quite easily use goatpig's makefile stuff to point to the Python installation inside the app, so that is one less complication.  |
|
|
|
Yeah, so far everything has broken on 10.9. Picobit gave me a script for building a more-standalone version of Armory on OSX, which should hopefully resolve this problem on most versions of OSX, and hopefully Mavericks, too. And hopefully we'll get a new guy soon that will be better experienced with OSX in order to battle these OSX problems.
I just caught the "Marking Orphan Chain" bug in the debugger, which I've been hoping to do for days! If I fix that bug, then I'll be under a lot less stress and can maybe take a shot at this. Stay tuned and thanks for being patient!
And I have been very passive recently due to being busy with other things. I have an issue or two with my build script and the latest changes to Armory, but they are Makefile related and I will have a look at it in the weekend. I will still be using Mountain Lion for a few weeks, but should then soon be able to test with Maverick too. There is a vexing issue with OS X: If the database is messed up (and that happens too often), it is hard to call Armory with --rescan. Passing command line arguments to OS X apps is possible (but not elegant), but the actual app is a script that calls Python, and that script does not pass through command line arguments. If it did, Armory would refuse to start, since OS X per default sets some strange command line arguments (windows position, perhaps), and Armory cannot parse them. |
|
|
|
In my opinion, these advanced measures are only needed, if there is demand for a high throughput of random numbers, which is not the case for the wallet creation.
Agreed, there should be more than enough entropy available on a normal desktop/laptop computer for wallet generation. I guess part of the reason for generating the seed yourself is that some people worry that the NSA or others have subverted the random number generation process to generate less-than-ideally random numbers. Such worries are in my opinion reasonably paranoid, but perhaps not totally without foundation. NIST (the National Institute of Standards and Technology) recently withdrew one of their recommended random number generation algorithms due to worries about NSA subversion of it (incidentally, an algorithm partly based on the same math as bitcoin, elliptic curves. Not that the NSA subversion would be relevant for bitcoin, it was just relating to using elliptic curves to generate random numbers). |
|
|
|
I would like to test the address before I trust it so I know it's really a valid key. But then I expose the public key and then I doesn't feel 100% secure because of that. This test shouldn't be needed if it was included in Armory because I trust that Amory doesn't fuck things up like I might do. If you have the correct number of bits, there is no such thing as an "invalid key". But calculating the corresponding bitcoin address by hand might be error prone, and it would be really nasty transferring funds to a wrongly calculated address. But then, just import the private key in an armory wallet, check that it gives a bitcoin address, and then use it. |
|
|
|
Is this still active brokerage?
I didn't find so much info about 1Broker.
I have been using it for USD/BTC betting recently. have not tried the other markets. |
|
|
|
|
ETH Zürich has some guys researching Bitcoin.
|
|
|
|
There are absolutely no problems having the same Armory wallet on two computers. The same bitcoin-qt wallet would be a disaster, since they would create different addresses. But Armory is completely deterministic, so the only minor inconvenience is that notes added to transactions will not syncronize. As other mentioned, it doubles the risk of theft. But hopefully you are well protected against malware and such. If the risk on one computer is acceptable, then hopefully double that risk is acceptable too
|
|
|
|
As an Armory user who'd absolutely love to see a new release out with lower resource consumption, I think you should leave your laptop at home and enjoy your honeymoon. +1 And congratulations! |
|
|
|
I just installed 0.89.99.5-beta, and was a little disappointed to see that the Message Signing functionality is only compatible with other versions of Armory. Will there ever be an Armory/Bitcoin-Qt cross-compatible signing mechanism?
What do you mean? As far as I know there's only one way to sign something. No, he is right. The mathematics may be (almost) the same, but armory signing and bitcoin-qt signing are not compatible. He is working on it, but unsurprisingly getting the RAM problems solved has much higher priority. |
|
|
|
I have finally produced a script that creates a stand-alone OS X app of Armory. Not a single line of higuys' script has been used (but I use his Info.plist), and I do many things in a different way. Nevertheless, this is based on his work and it would have taken me at least ten times longer to do it without his work to build on! Some comments: * I have only tested it slightly, and almost exclusively on Testnet. * The building script is written in Python. Perhaps that will make it easier for etotheipi to maintain it; it certainly made it easier for me to write it.  * The app is 64-bit only. I doubt that Armory can fit into a 32-bit memory model. * Higuys' script delegated most of the compiling to Homebrew, and copied the result into the App. This script compiles things directly (although mostly the same way as Homebrew would have done it). It looks like this solves the problem with the App crashing on Macs that are older than the one used to build the App. Homebrew assumes that compiled code will be executed on the local machine, and tries to get a bit of extra performance by enabling the full instruction set of the actual CPU. The usual building scripts are more conservative, and build for all 64-bit CPUs. * The app claims to work on OS X 10.6 or later, but in reality I have no idea if it works on 10.6 and 10.7. I suspect that if it declared 10.8 or later that alone would prevent it from working on older versions. * The app is huge, 136 M. This is because it contains the majority of a Python installation (mostly .pyc files, but still 65M) and a large part of Qt (51M). I suspect I can shave off another 25-50 M. * Command line arguments are ignored (so even if you know how to pass command line arguments to OS X apps, you cannot ask Armory to use e.g. testnet). This is because I cannot just pass on command line arguments to the Python script as OS X adds its own extra arguments. I will send this script by PM to etotheipi. I hereby donate the script to the Armory project and transfer copyright etc. |
|
|
|
Just pushed 0.89.99.5-testing.
Looks like this fixed the crashing on exit bug on OS X! |
|
|
|
OK, so tracing the bug is difficult if one cannot single-step through the function unless it is done in less than 10 sec It seems that it sometimes cause corruption of the database, so that a rescan is necessary on the next restart. Othewise transactions may be missing. |
|
|
|
I did a bit more debugging, putting a breakpoint in the crashing function and stepping line by line. It looks like the call to KEY_NOT_IN_MAP triggers an exception in some python code. It is a testnet wallet, so I could in principle send it to you. Breakpoint 1, BlockDataManager_LevelDB::shutdownSaveScrAddrHistories (this=0x104ba23e0) at BlockUtils.cpp:3988
3988 LOGINFO << "Saving wallet history for next load";
(gdb) n
Current language: auto; currently c++
-INFO - 1380282523: (BlockUtils.cpp:3988) Saving wallet history for next load
3990 iface_->startBatch(BLKDATA);
(gdb) n
3992 uint32_t i=0;
(gdb) n
3993 set<BtcWallet*>::iterator wltIter;
(gdb)
3994 for(wltIter = registeredWallets_.begin();
(gdb)
3995 wltIter != registeredWallets_.end();
(gdb)
3998 for(uint32_t a=0; a<(*wltIter)->getNumScrAddr(); a++)
(gdb)
4000 ScrAddrObj & scrAddr = (*wltIter)->getScrAddrObjByIndex(a);
(gdb)
4001 BinaryData uniqKey = scrAddr.getScrAddr();
(gdb)
4003 if(KEY_NOT_IN_MAP(uniqKey, registeredScrAddrMap_))
(gdb)
(ERROR) armoryengine.py:12189 - Waiting for BDM output that didn't come after 20s.
(ERROR) armoryengine.py:12190 - BDM state is currently: Uninitialized
(ERROR) armoryengine.py:12191 - Called from: armoryengine.py:12314 (83837112)
(ERROR) armoryengine.py:12192 - BDM currently doing: Shutdown (83837112)
(ERROR) armoryengine.py:12193 - Direct traceback
File "ArmoryQt.py", line 4981, in <module>
os._exit(QAPP.exec_())
File "ArmoryQt.py", line 4835, in closeForReal
TheBDM.execCleanShutdown(wait=True)
File "/Users/schiotz/src/BitcoinArmory/armoryengine.py", line 12314, in execCleanShutdown
return self.waitForOutputIfNecessary(expectOutput, rndID)
File "/Users/schiotz/src/BitcoinArmory/armoryengine.py", line 12194, in waitForOutputIfNecessary
traceback.print_stack()
(ERROR) armoryengine.py:12195 - Traceback:
Traceback (most recent call last):
File "/Users/schiotz/src/BitcoinArmory/armoryengine.py", line 12185, in waitForOutputIfNecessary
return self.outputQueue.get(True, self.mtWaitSec)
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/Queue.py", line 176, in get
raise Empty
Empty
4009 RegisteredScrAddr & rsa = registeredScrAddrMap_[uniqKey]; |
|
|
|
Please forgive me not reading all previous pages, in case this is a well known issue discussed before.
Yesterday's evening I send BTC with Armory, nevertheless it currently shows today 12:21GMT+2 as send date.
Armory several times restarted since yesterday.
Armory is connected to the bitcoin network and synchronized.
Current block is 260392, 12:50 GMT+2.
Transaction still has 0 confirmations and status 'Not in the blockchain yet'
Transaction fee is 0.0005BTC.
Any advice would be appreciated!
Can you see the transaction on blochchain.info? If so, the transaction has been transmitted correctly but may depend on unconfirmed inputs, have a huge size and too low fee, or something. If it is not on blockchain.info, then armory has not sent it (or bitcoind has not relayed it), and it will never confirm. |
|
|
|
Hi etotheipi, I have a strange crash when Armory quits on Mac OS. LevelDB gives a segfault, the stack trace from gdb is below. I am by the way almost done making a Mac OS X App. But since this is not a race for a bounty, I prefer to sit on it for a few days to fix the worst issues (No real testing yet, will it run on another machine? It probably crashes on old hardware if built on new hardware. The icon and other stuff is missing. The app is beyond huge, 250M !!). I think I know how to address all of them. Anyway, here is the crash data. It occurs when I quit the app, and it does not depend on whether I build a real app, or just compile Armory and run it from the command line. -INFO - 1380265090: (BlockUtils.cpp:3988) Saving wallet history for next load
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000
[Switching to process 899 thread 0x1903]
0x0000000103e083c0 in InterfaceToLDB::commitBatch ()
(gdb) where
#0 0x0000000103e083c0 in InterfaceToLDB::commitBatch ()
#1 0x0000000103e5d064 in BlockDataManager_LevelDB::shutdownSaveScrAddrHistories ()
#2 0x00000001040250fe in _wrap_BlockDataManager_LevelDB_shutdownSaveScrAddrHistories ()
#3 0x000000010001d5a9 in PyEval_EvalFrameEx ()
#4 0x0000000100021869 in _PyEval_SliceIndex ()
#5 0x000000010001d63a in PyEval_EvalFrameEx ()
#6 0x0000000100021869 in _PyEval_SliceIndex ()
#7 0x000000010001d63a in PyEval_EvalFrameEx ()
#8 0x0000000100021869 in _PyEval_SliceIndex ()
#9 0x000000010001d63a in PyEval_EvalFrameEx ()
#10 0x0000000100021869 in _PyEval_SliceIndex ()
#11 0x000000010001d63a in PyEval_EvalFrameEx ()
#12 0x000000010001b147 in PyEval_EvalCodeEx ()
#13 0x0000000100054d7a in PyFunction_SetClosure ()
#14 0x00000001000136c6 in PyObject_Call ()
#15 0x00000001000309bf in PyMethod_New ()
#16 0x00000001000136c6 in PyObject_Call ()
#17 0x0000000100021018 in PyEval_CallObjectWithKeywords ()
#18 0x000000010007d7f6 in initthread ()
#19 0x00007fff96982772 in _pthread_start ()
#20 0x00007fff9696f1a1 in thread_start ()
(gdb) list
1 // algparam.cpp - written and placed in the public domain by Wei Dai
2
3 #include "pch.h"
4
5 #ifndef CRYPTOPP_IMPORTS
6
7 #include "algparam.h"
8
9 NAMESPACE_BEGIN(CryptoPP)
10
(gdb) up
#1 0x0000000103e5d064 in BlockDataManager_LevelDB::shutdownSaveScrAddrHistories () at basic_string.h:279
279 _M_data() const
Current language: auto; currently c++
(gdb) list
274 private:
275 // Data Members (private):
276 mutable _Alloc_hider _M_dataplus;
277
278 _CharT*
279 _M_data() const
280 { return _M_dataplus._M_p; }
281
282 _CharT*
283 _M_data(_CharT* __p)
(gdb) up
#2 0x00000001040250fe in _wrap_BlockDataManager_LevelDB_shutdownSaveScrAddrHistories ()
(gdb) list
284 { return (_M_dataplus._M_p = __p); }
285
286 _Rep*
287 _M_rep() const
288 { return &((reinterpret_cast<_Rep*> (_M_data()))[-1]); }
289
290 // For the internal use we have functions similar to `begin'/`end'
291 // but they do not call _M_leak.
292 iterator
293 _M_ibegin() const
(gdb) up
#3 0x000000010001d5a9 in PyEval_EvalFrameEx ()
(gdb) list
294 { return iterator(_M_data()); }
295
296 iterator
297 _M_iend() const
298 { return iterator(_M_data() + this->size()); }
299
300 void
301 _M_leak() // for use in begin() & non-const op[]
302 {
303 if (!_M_rep()->_M_is_leaked())
|
|
|
|
So far, I've seen a pattern that 32-bit Windows versions don't seem to work. But 64-bit OSes do work.
I would not be too optimistic on a 32-bit version. The real reason for 64-bit architectures is that you can easily handle more than 2GB of data in one block. On a 32-bit architecture, that is going to be tough (but of course not impossible). |
|
|
|
OK, first two strange behaviors: I transferred some testnet coins from a testnet faucet. When the first block arrived, Armory popped up a window saying that Bitcoin-QT was not up to date. It also printed this around 10 times in the terminal. At the same time this happened, I was transferring testnet coins from another faucet. The amount appeared in the total, but this time the transaction did not appear in the list of transactions. Restarting Armory made it appear (at 0 confirmations). Restart was blazingly fast! EDIT:-INFO - 1379965779: (BlockUtils.cpp:3748) Finished blockchain scan in 8e-06 seconds I somehow doubt this timing |
|
|
|
|
I can report that the new version compiled just fine on OS X. I had previously used HomeBrew to install all dependencies of the old Armory client, and did not have to install anything new to compile the new version. The first tests on testnet look good. I will test offline wallets (on testnet) soon.
As for packaging this as an .app, that is going to be harder, but I will have a look at that too. But not this week, and probably not next week.
|
|
|
|
If I want to try it out on OS X I have to compile it myself. I assume it is in a branch in git ?
It's the "testing" branch. There is Level DB source code in the project, though, no clue if it compiles on OSX... If it doesn't, then I will look at it in a few weeks. If it does, I will report back here soon. :-) A quick google for "os x leveldb" looks like it should work, but that it in reality causes some amount of trouble ... |
|
|
|
|
Show Posts
