Tracing GC would not be good for portability with embedded devices right? It depends on if your embedded application has actual real-time requirements from bitcoin. I don't see bitcoin having any such requirements since most of what it does is networking and/or churning away at validating the blockchain, updating current balances and so on. Very little of it is actual user-interaction, which might be taken care of by a separate gui layer with different memory management. If you actually need real-time performance for any reason, you'd have to use either something which has no pauses, ie refcounting with a freelist/standard C alloc/dealloc, or a concurrent GC. Concurrent GCs perform worse overall than stop-the-world, but they have minimal pauses so that things like real-time video chat or a phone's normal calling routines aren't choppy. I know that they don't use garbage collection in the iOS obj-c framework, but I don't know what other phone developers do. I know that it's possible to compile GC for an embedded system, but there may be other reasons against it's use. Theoretically it shouldn't break things though, since the OS kernel being preemptible and using a realtime scheduler are the main mechanisms for enabling real-time performance. I would ask someone who actually has some experience with programming for phones. They would know better than I do. I really can't see how reference counting is a major performance issue at all since the retain/release calls are in-between a lot of other code which is much more intensive.
Memory management is one of the biggest overheads incurred by any and every program. It also performs no useful work in regards to a program's 'business' code. As a result, every single instruction of MM overhead is significant WRT overall performance. Just to give you the gist, experiments with region-based memory management and compile time GC in mercury showed speedups of 100% or more for some applications, and no less than 33% speedup for any, while using 66% less memory (or less) than with standard GC. Of course, that was a declarative language with strong-static typing, modes, determinism, and scope declarations, but I think it should give you a good idea of what to expect with changes to memory management in general. |
|
|
|
|
Eh, I can understand not wanting to include any extra libraries, but I'm not so sure about GC having any effect on portability (except maybe on card-readers, which is hard to predict).
I see what you're trying to do with removing some unnecessary refcounts, which has been done (probably more effectively) in automatic reference counting systems, but I wouldn't recommend trying to do it manually. Basically, the case you listed (passing control of an object completely to another object with zero effect on count) is rarer than the more common case where an object is passed temporarily to an object which quickly uses and releases it with no effect on refcount (ie the original owner maintains control). If you want to cut out code like that, I'd suggest doing it on an expendable copy of your code later, and just counting everything for now. You're more likely to break stuff otherwise, which defeats the point of manual refcounting.
Btw, refcounting isn't only inefficient for many dead objects because of extra unnecessary counts; tracing is just that much more effective/efficient on dead objects. Age-oriented GC exploits that by having the young generation collected by a tracer and the old generation automatically refcounted. Personally I wouldn't go for all that complexity for a bitcoin library. It's not like you're decoding video for playback or anything, so a stop-the-world, copying tracing collector would be pretty efficient and work just fine, if you decide to go that direction.
|
|
|
|
|
Well, I tried exporting CFLAGS and ARCHFLAGS, but the result was the same o.0. Oh well.
|
|
|
|
I don't see what reference counting has to do with endianness, but generally it's only useful for memory management of long-lived objects. Are you really writing your own memory management code? o.0
In my post I was talking about two separate issues. The endianness is a bit annoying but it's fine and I did decide to use reference counting for strings in the end. The memory management is a simple reference counter. It is nothing complicated and makes the library much more straight-forward when passing objects everywhere, as no-doubt will be the case with a library like this. You can see what I've done by looking at the CBObject files. Look at the testCBAddress.c file for an example of using a CBAddress object with memory management included. Ah gotcha. I feel that though, retain/release is at least 10 times easier than trying to place deallocs correctly (which is sometimes impossible). You mightcould use an already-been-designed C garbage collector instead and save yourself the trouble in that case. Refcounting is very inefficient when many objects die, and overall doesn't perform any better than a GC, which is zero effort and no chance of screwing anything up  . Honestly, weak-typed imperative languages suck for memory management x.x |
|
|
|
If you're going to rewrite C++ in C (by building virtual function tables yourself), why not code it in C++ in the first place? If compatibility is a problem, you can always expose a C interface to the code.
Because C++ has craptastic performance and tramples all over C conventions, both for no reason. - The Linux Kernel Dev TeamAlso why gnome decided to start from scratch with gobject, although I can't vouch for gobject's characteristics either. That said, I approve of this project, and will probably donate to that end soonish. Thanks. It may be useful to refer to parts that I can't get from bitcoinj such as the script interpreter.  It seems I've made a little problem. I'm storing bitcoin addresses backwards at the moment since my base-58 conversion code works with little-endian data. Probably makes sense to reverse the result of the base-58 conversion so they are stored the right way around instead of reversing hashes and whatever. etotheipi was right about the endianness issue! :-) I have to make some interesting decisions. Should I have a reference counted string structure? It might help with the bitcoin address strings. I don't see what reference counting has to do with endianness, but generally it's only useful for memory management of long-lived objects. Are you really writing your own memory management code? o.0 |
|
|
|
Ugh. You just reminded me that I didn't totally understand endianness when I started the python library, and I most definitely did it wrong. If there is a real demand for mixed-endian-arch support, I can do it. But it may take a few days. Up until now, I have not considered it a worthy investment of my time, because it is so fragile, something is sure to break even after I think I've fixed all of it...
Haha that's alright. I think I got at least electrum to work. You'd be better spending your time helping that other guy build his C implementation and do it right . I've had enough experience with endianness myself to know how inside out and backwards it makes everything, and trying to hack a fix on top of a tangled broken base implementation would be a lot of work and a lot of things that could break, and a lot more work to fix. I'm not going to ask anyone to do something so impossibly unmaintainable. After having to compile an entire system from scratch I've gained an appreciation for having to deal with nonsense like this . Honestly I don't know how binary distros manage to do it at all. |
|
|
|
I think there was something in the original OSX build instructions that addressed the -native and extdef stuff. I don't remember exactly, but it's linked from the "Building Armory from Source" page. As for libcryptopp: I got tired of dealing with library version/compatibility issues so I switched to static compiling crypto++ right into Armory. I needed the source code in the project anyway for Windows/MSVS, so I just did it for all versions. Therefore, the version on your system should not matter. But also there should be no problem compiling it, unless the crypto++ library was never compiled or tested on your architecture. I have no idea about the "g++: language ar not recognized".  Yeah I saw the stuff about -arch in the OSX instructions. I think -arch ppc does work, but I'm not sure exactly what it does or how it relates to cflags. I'll try that and see what happens. However, something tells me it won't work properly anyway, after reading up on the endianness disaster in the bitcoind code. Bitcoind compiles fine, but that doesn't mean it will actually work properly, and something tells me it most definitely won't. >_< |
|
|
|
Well, I got bitcoind and all the qt stuff to compile no problem, although I can't yet attest to whether it works or not. However, I'm unable to get armory to compile. Whether I use "make swig" or "make -e swig", first I get lots of g++ -DNDEBUG -O -g0 -native -template=no%extdef -c ***.cpp
g++: unrecognized option '-native'
g++: unrecognized option '-template=no%extdef'
Then I get a wall of g++: language ar not recognized
then /usr/lib/gcc/powerpc-unknown-linux-gnu/4.5.3/../../../../lib/crt1.o:(.rodata+0x4): undefined reference to `main'
trdlocal.o: In function `CryptoPP::ThreadLocalStorage::GetValue() const':
trdlocal.cpp:(.text+0x2f4): undefined reference to `pthread_getspecific'
trdlocal.o: In function `CryptoPP::ThreadLocalStorage::SetValue(void*)':
trdlocal.cpp:(.text+0x324): undefined reference to `pthread_setspecific'
trdlocal.o: In function `CryptoPP::ThreadLocalStorage::~ThreadLocalStorage()':
trdlocal.cpp:(.text+0x430): undefined reference to `pthread_key_delete'
trdlocal.o: In function `CryptoPP::ThreadLocalStorage::ThreadLocalStorage()':
trdlocal.cpp:(.text+0x53c): undefined reference to `pthread_key_create'
collect2: ld returned 1 exit status
make[1]: *** [libcryptopp.a] Error 1
...
mv: cannot stat 'libcryptopp.a': No such file or directory
make: *** [libcryptopp.a] Error 1
However... localhost cppForSwig # locate libcryptopp
/usr/lib/libcryptopp.a
/usr/lib/libcryptopp.so
/usr/lib/libcryptopp.so.0
/usr/lib/libcryptopp.so.0.0.0
At least some of that stuff is probably arch flag inconsistencies (gcc for ppc exclusively uses -mcpu= and not -march=, although I would have expected make -e to fix that since cflags are set globally in gentoo) but the cryptopp thing makes no sense. I have both crypto++ and pycryptopp installed. The other stuff I have no clue about. |
|
|
|
Bitcoind doesn't run on ppc-- and minimum supported osx version is 10.5.
And Armory depends on bitcoind, right?
Bitcoind happens to be on the gentoo portage repository, so I checked out its dependencies to see if there was anything x86 specific. I don't see anything, so unless you guys decided to rice out your code with x86 assembler then I should be able to compile it just fine. Bitcoind doesn't run on ppc-- and minimum supported osx version is 10.5.
And Armory depends on bitcoind, right?
Does that mean that if I were to cannabilize the bitcoind code to integrate networking into Armory, that I'll never get it working on ppc? Or does it not work, for other reasons? Btw, have you tried Armory yet? P.S. -- I still don't have a working OSX VM or actual OSX-running hardware. So I still have not been able to flesh out the Mac build/distribution process. Sorry Mac'ers I'll let you know. I just got my system to the point where everything is working and it does what I need it to . I think your frontend is exclusively QT, so I'll have to emerge PyQt4 and bitcoind before I can test. I'll let you know what happens. Some other stuffs: You can probably get an iBook or older ppc mac for cheap (if you can find one). PPC macs can't run anything greater than leopard (OSX10.5) but any program coded for Tiger or newer should run on any modern mac. New versions of the OS (in my experience) have always supported older code, but they've changed a few important things over the years so that newer code won't run on older versions. Unless you want compiz effects in armory, that shouldn't really be an issue, though . The only downside is that Tiger doesn't support garbage collection, but if you're using python to do most of your work it shouldn't be a problem. The main problem is hooking up python to the cocoa gui, which I'm pretty clueless about as I'm not a big fan of python . You'll probably want leopard since it natively supports cross development, and is the last OS to support both PPC and x86. One more thing, how are you trying to install OSX in a VM? Apple sold their soul to microsoft in exchange for microsoft continuing to make office for mac, so Apple puts DRM controls on their OS to force it not to install on non-apple hardware (including VMs). There are some hacks around it, but I'm not up to date on any of that. |
|
|
|
I see. easy_install is confused is because you are calling it from the electrum directory, where there is already an ecdsa directory The easiest way to deal with this is probably to reinstall Electrum from scratch, with the pip command, as stated on the Electrum webpage. Remove your current Electrum-0.49 directory, and type: sudo pip install http://ecdsa.org/electrum/Electrum-latest.tar.gz It should install everything. Another solution is to install ecdsa and aes using pip, instead of easy_install sudo pip install ecdsa
sudo pip install slowaes
Ok, now that I know what pip is, I got it to work. Apparently the ecdsa part of the current electrum package is broken, but if I install it separately with pip then everything works. |
|
|
|
Try this: easy_install http://pypi.python.org/pypi/ecdsa might need this too: easy_install http://pypi.python.org/pypi/slowaes localhost Electrum-0.49 # easy_install http://pypi.python.org/pypi/ecdsa
Downloading http://pypi.python.org/pypi/ecdsa
error: Can't download http://pypi.python.org/pypi/ecdsa: 404 Not Found () x.x |
|
|
|
Well, now that I'm on gentoo and have a real web browser I can answer that question: Yes there are multiple versions to support. Basically it's split up between x86 and ppc, with ppc being restricted to Tiger/Leopard (which is fscking retarded considering that apple moved to LLVM....) while x86 will typically be running Snow Leopard or Lion. The main differences are in the quartz/cocoa gui implementation, although it depends on what frontend you use. Qt4 will not build on older versions of OSX (ie anything pre-Snow Leopard) as I've found out the hard way, so if you actually intend to support them at all you'll have to use something else. I don't know how well gtk builds on older OSX (never tried), I just gave up and moved to gentoo . I don't know that there are python bindings for cocoa, but if so it's as easy/difficult as any other gui kit, except they break backwards compatibility without having any explicit versions of the API. |
|
|
|
Ok after a few weeks of downtime I just got electrum 0.43c-2 running, and then quickly saw that there was a new version. Updated to 0.49 and now I get this: localhost Electrum-0.49 # electrum
python-ecdsa does not seem to be installed. Try 'sudo easy_install ecdsa' and then localhost Electrum-0.49 # easy_install ecdsa
Processing ecdsa
error: Couldn't find a setup script in ***/Electrum-0.49/ecdsa Running up to date gentoo. easy_install ecdsa gave me the same thing with 0.43c-2, but electrum seemed to run fine anyway, and connected to the server well enough to tell me there was a new version. 0.49, on the other hand, does not. Also, is the gtk frontend still supported? I haven't gotten far enough to tell, but I no longer see any such option mentioned. |
|
|
|
Oh sorry. I misread. I thought you meant you either wanted to use electrum instead of bitcoin for getting the blockchain, and then still use Armory or wanted to run an electrum server which also requires bitcoind. Those didn't make any sense, but you were saying that want to use the Electrum client. That would work (assuming you can get it compiled  ) Yeah, for now I want to keep it light. My machine is about 1/100th too slow to contribute much of anything to the network . HD space is probably my biggest concern. Well that is a link to xubuntu which uses XFCE instead of gnome. I gave you that link to xubuntu rather than ubuntu 10.04 (which uses GNOME2 IIRC) because XFCE has lower system requirements, but still looks nice. #$%@#%$#$%ing debian . Debian supports everything. And they have nifty net-install CD images so I can basically construct my own distro. Well you won't need to build bitcoin-qt, just bitcoind. Try installing the PPA and then 'sudo apt-get install bitcoind' That's what I did in my VirtualBox VM and it seems to work fine (Although DO NOT import that wallet since it will use 0.6's compressed keys which aren't supported by Armory's import yet). Ah, so bitcoin does use qt for its frontend. I had a suspicion . I'll have to install qt anyway for any of the clients so it's not a big deal. Since I can run the absolute latest debian (and whatever else I feel like on it) I shouldn't have to worry about compatibility issues. |
|
|
|
I don't think that electrum works like you think it does. Last I checked electrum feeds off of full nodes with a special server interface, but isn't tied to any one server nor requires owning one. You haven't touched linux in a while have you? All the modern desktop distros come with all of that stuff installed. Ubuntu is a simple install and everything is there for you. Word processing, e-mail, web browsing, cd/dvd burning, games, irc and IM, etc., etc. However, most modern desktop distros abandoned mainline support for PPC a while ago. Ubuntu moved PPC support to "unofficial" back at version 7, but there is a 10.04 build for PPC. http://cdimage.ubuntu.com/xubuntu/ports/releases/10.04/release/Nifty. Is there anything in particular that I might have trouble compiling/updating? For example could I compile and run GNOME3.x on this box, or is that asking too much? Compiling Armory in xubuntu 10.04 should be easy. It's new enough to have all the libraries you will need and there is a PPC build. There's even a PPA to install bitcoind and/or bitcoin-qt. Hopefully those work with the unofficial build. Otherwise, bitcoind isn't too bad too build from source. Not too worried about it, although I'm not sure what dependencies bitcoind has. Except for Qt (which tries to use newer cocoa bindings) I haven't actually had much trouble compiling things on this machine, and on linux I should probably be able to compile Qt easily enough . For ~800MB it really doesn't look bad at all. |
|
|
|
Well, on the one hand I think I probably did have it figured out. Windowing agnostic mode should cause it to ignore carbon and cocoa which should fix the compatibility issues. I hope. You need the satoshi client to get the blockchain. So you will need either bitcoin-qt or bitcoind until the networking code is built into Armory. I was planning on using electrum since my HD space is somewhat limited. If I can get that working I'll work on armory since the extra stuff it needs shouldn't be too hard. Any reason you have to stick with Tiger? I'd recommend installing linux. It actually works with new software (and old hardware) and is much less of a hassle than building new software on an outdated architecture running an outdated OS. Well, I don't like monokernels . Not that OSX is really any better, although honestly I don't know much of shit about linux . I can barely use bash ^_^. That, and I'd hardly know what to look for in terms of even basic functionality. I know Mplayer and I could probably find an IM client, but for email I'd be screwed. And if you are comparing difficulties with Tiger to the latest linux build, that isn't fair at all. I think trying to get Armory working in Ubuntu 5.04 (which was released about the same time Tiger was) would be a fair comparison and is probably just as much a PITA.
It'd probably be much easier and cheaper to upgrade from Ubuntu 5.04 to the latest on any hardware than to upgrade from Tiger to anything on PPC. Leopard is even more bloated than Tiger, and I'm only vaguely certain that I could upgrade that far. Even if I did even then I doubt this would be any easier since Qt doesn't support anything less than Snow Leopard. x.x |
|
|
|
I just rechecked in ./config -h for QT4 again, and it looks like it's not going to work, period. I really did not want to have to install the satoshi client >_<. Maybe if I erase my HD and start over with Linux it'll work . Sad to say, I've been a mac user since before iPods existed, and now I would not ever buy a mac again after the retarded treatment I've gotten. Besides OpenCL, there's not a single thing new intel hardware can do that mine can't, and yet they drop all backward compatibility for OSX 10.5+? The fuck? I bet the latest linux build would compile just fine (on any hardware of my choosing, for that matter), and then I wouldn't have to jump through all these bullshit hoops just to get some random GUI kit to compile. 24 hours I'll never get back =\. |
|
|
|
You should try using precompiled binaries (if they are available for an old system). They're not. I already looked. The only Qt/PyQt binaries available on Tiger are way out of date, and I know at least Electrum requires Qt4.x/PyQt4.x. It's a one-liner to install homebrew... What problem did you have?
The fact that the PPC fork and the Tiger fork are separate. I probably screwed it up somehow, but I couldn't get it to work at all. Although homebrew seems to have installed (or something), if I type, for example brew install cryptopp what I get is /usr/local/Library/Homebrew/formula.rb:554: warning: already initialized constant CHECKSUM_TYPES /usr/local/Library/Homebrew/global.rb:80: uninitialized constant RUBY_PATCHLEVEL (NameError) from /usr/local/bin/brew:10:in `require' from /usr/local/bin/brew:10 |
|
|
|
Ok I just spent the last !%#@#$%@#$@ 24 hours trying to compile (technically electrum, not that there's a huge difference) on my Tiger/PPC laptop. My conclusion is that it's most likely not possible, although technically not directly the fault of Armory or Electrum in particular, just that Qt is a POS that deserves never to be used ever again . In particular, after trying to @#%$@# compile Qt like 3 times now, it has failed Error 1 and Error 2 (after an excruciatingly long config and make process), no matter which way I configure it. At first I got some unrelated problems because it didn't like being dropped in a folder with a space in the name, but even after fixing that, using -universal and -sdk it gave me the same errors I got when it screwed up for other reasons (after it failed the first time I had to completely scrap the source folder because it decided to shuffle the makefiles all kinds of wrong and then make -confclean didn't work at all either due to the pathname issue). I might try one more time, using the "platform agnostic" version and -arch instead of -universal and -sdk, sometime after I'm done being angry. If I can just get Qt to install (fuck you nokia) then I can probably get electrum and armory running no problem. On an unrelated note, I think homebrew is probably responsible for a lot of the inconsistencies people are seeing. I never was fond of MacPorts, and I had nothing but trouble trying to install homebrew (gave up on that). What I did find is that the python site (and others) offer up-to-date versions that install properly (and easily) and you don't have to mess with symlinks (which occur in ~/.bash_profile, at least on my box) or anything like that. Python 2.7.x works great and SIP was no problem to install. I don't expect any problems with Cryptopp, SWIG, or BDB, as everything else compiles fine, but QT is highly dependent on OS version (on mac anyway) and PyQT won't install without it. |
|
|
|
That's why Gavin suggests that DISPUTE is actually a send-100%-to-tx-fee. Then no one gets the money, but it does get recycled. And that's why I recommended deposits, so that both parties have a mutual incentive not to do shady stuff. If it costs them money to be a dick, there will be a lot less dickery. I see, so it's like a mutually-assured-destruction. If Bob's deposit is 100% of Alice's payment, that could work. The part that you're missing is that the Bitcoin network is offering a dramatic improvement over something that happens all the time -- people trust completely random strangers over the internet, endlessly. And for those people, one party has to assume all the risk: Alice sends money first, or Bob sends merchandise first. Usually with the backstop of bank chargebacks or some company such as ebay or amazon resolving disputes. Also, seller ratings? Even if it's anonymous, you can usually still know something which will indicate whether the seller is honest or not, or else decide whether a purchase is too much money to chance or not, or what your chances are getting a chargeback via paypal or whatnot should they defect. Gavin,
I still think a risk deposit is necessary here. Even if DISPUTE goes to the miners, Alice may just be bitter that her new merchandise is crappy quality and issue DISPUTE to spite Bob. She doesn't get any money back either way, so what does it matter to her whether Bob gets it or the miners get it?
By the way, another problem with it: if Alice has a lot of mining power, it's very +EV for her to pull the DISPUTE trigger, since she's would get something back instead of nothing.
Except maybe that. That's the problem with trying to do business by mutually assured destruction . I don't think Alice being a miner is a serious consideration, though. In order to get all of her money back, she would need to own a serious chunk of the total hashpower and be able to find a block herself (with her dispute included without being transmitted) before nLocktime ran out. In order to get most of it back, she'd have to at least own a serious chunk of a pool, and hope that her pool mines the block with her 'Dispute' call in it. She's much more likely to burn the contract just to be a dick. |
|
|
|
|
Show Posts
