The python 2.7 version works fine on my system even though I have python 2.6, so either you've screwed up the dependencies again...


...yup, you've screwed up again ...or it doesn't depend on a particular version of python at all, in which case you can safely remove it from the dependency list, and I have no idea what was causing psy's problems.

The fee depends on how much data is needed to send your transaction, which in turn depends on where your coins came from (since a transaction is just a list of where the coins came from plus where they're going). If you received your 20 BTC in (let's say) 2000 separate payments of 0.01 BTC each, then sending them requires much more data (and thus a much higher fee) than if you received the 20 BTC in a single payment. This also means that if later on you withdraw all your bitcoins from Mt Gox in a single transaction, you'll be able to send them again with a much lower fee, since all the coins came from the same place and thus the transaction requires less data.

You manually installed libpython2.6 on top of libpython2.7? Or are you saying your binary doesn't really depend on libpython2.6 at all? Because psy's post:
seems to indicate pretty conclusively that it does. Or doesn't it?

What the Hell? That doesn't make any sense. If whatever crazy packager you're using doesn't start making more sense, you may be better off just creating the .deb file by hand.

I think you may have just made a typo.

Looks like it. The different python versions use different filenames for the library, even though the different versions are mostly compatible, causing the interpreter to crash when it can't find the version of the library it expects. Is there no way of using the statically-linked python interpreter? Or does it need to dynamically linked for Qt or something? (I don't know anything about python)

Well of course it worked on your system, you built it after all, so obviously you have all the dependencies already. It also works on my system, because I already downloaded the dependencies when I was building from the source. It's the people who don't have the dependencies already who need the package to contain a correct dependency list, otherwise the package will install without the correct dependencies, and that won't work at all.

I think the following dependencies are correct (for the binary package, compiling from source requires extra stuff):
libpython2.6
python-qt4
python-twisted
(all other dependencies are children of these dependenies, so can be excluded from the list)

Considering the dependencies are incorrect and it creates invalid menu entries, and currently requires a program (bitcoin) which is not in the official Debian repositories, I don't think it's quite at that stage yet.

It seems that when compiling from source, it uses whatever version of libpython you happen to have, but the binary in the Debian package is dynamically linked to libpython2.6. I don't see a solution as long as Armory needs to be dynamically linked to libpython.

I'm pretty sure python programs don't need executable permissions. At least they don't in python 2.6...

That's because you can't have python 2.6 and 2.7 both installed on the same system, so any given distro will only have one or the other. Sucks. (You can downgrade from 2.7 to 2.6 if you change your distro settings, but installing packages from a different distro almost always ends in tears. I do not recommend you attempt this.)

Okay, now that github has started working again, let's have a look here...

Uh, I think there's still some work to be done on that dependency list:
You mean Armory doesn't require Qt4 any more?

Also, your .desktop files are invalid. "Categories=GNOME;Applications;Internet;" should be changed to "Categories=Qt;Network;", since "GNOME" is not a main category (and Armory is based on Qt, not GNOME) and neither "Applications" nor "Internet" are valid categories at all. Since there is no valid main category specified, KDE just dumps the menu entries in "Lost & Found". For reference, a list of valid menu categories can be found here.

Other than those major flaws it's all good.

All the downloads on that page give 405 Method Not Allowed.

Solution: Have the ATM refuse to pay out on unconfirmed no-fee transactions, and instead have it print out a receipt with a QR code that can be redeemed for cash at the same ATM after the transaction gets confirmed (if it ever does).

You can't add in a couple of double-spends, you can only pull of one double-spend before everyone on the network realises there is something very wrong, at which point everybody will stop accepting bitcoins until the attack is over. Once the attack is over, the network will resume functioning as normal. A one-day 51% attack doesn't fuck Bitcoin permanently, it only fucks Bitcoin for one day.

Why do you insist on PayPal? What is your reason for not paying cash?

D'oh! I somehow managed to completely forget about that! This is why I probably shouldn't post at 1:00 AM. Yeah, just stuff the compiled binaries in /usr/bin/ with the others, no need to bother with the source (at least not in the binary package). Oh, and change whatever's needed to get it to work with the new directory structure.

I don't know about Ubuntu, but I'm pretty sure some kind of user-friendly package manager comes up. I don't think the Ubuntu folks would want users messing around with dpkg!

Good luck!

dpkg is an extremely low-level tool, it's not supposed to be run manually. You're supposed to install packages using a package manager like APT or GDebi. It makes things much easier.

It's not supposed to be. It's a python program. What tool are you using that requires a Makefile?

Just dump the python files into /usr/bin/ (yes, even though they're not true binaries) and the images and whatnot in /usr/share/ -- that's the usual way of doing it, right? The hard part is creating the preinst, prerm, postinst, and postrm scripts, I think that's the only thing you need the tools for. But those scripts are completely optional if all you need to do is dump some files on the user's hard drive - the scripts are just to create the appropriate menu entries and desktop shortcuts and such.

Creating a .deb file that installs garbage is easy - it's just a tarball with some metadata glued to it in the form of another tarball, after all. I don't actually have much experience with Debian packaging either, but it's pretty easy to figure out.

Well, I plan to be reincarnated as an indestructible cyborg when the singularity hits, and I need to plan my trading strategy accordingly. Specifically, I need to know whether bitcoins will go up or down in value over the next several centuries.

Probably because the question is about something that's not going to happen for about a hundred years or so? I think that's about as speculative as you can get!

APT will install dependencies for you, and will is supposed to fail if it can't install them for whatever reason. That's why your statement that "you will still have to install the dependencies the first time" left me wondering if you knew how Debian packages are supposed to work. And what do you mean by "a raw .deb package"? .deb packages are about as cooked as they get, and APT doesn't handle any other kind of files, at least as far as I know.

Okay, now I'm convinced you don't understand how Debian packages are supposed work. You're supposed to specify the architecture in the control file, along with the dependency list and all that other stuff. Wait, how did APT install documentation if it's marked for the wrong architecture? What exactly are you doing to the poor thing?

Yes, and the easiest way to convince people to pay higher fees is for a group of miners to only process high-fee transactions.

Hmmm... It would be better if "pay a fee for faster processing" was implemented at the protocol level rather than being left up to miners (though such a protocol change would easily be accepted if enough miners felt they couldn't work out any other solution). Perhaps something like a minimum transaction fee equal to the block number's largest prime factor. That way, transactions with a fee of only 1 satoshi will have to wait for a prime numbered block, while higher-fee transactions are allowed more frequently. Clients can recommend a specific fee by working out the factors of upcoming blocks and asking the user how long they are willing to wait. Just a random idea, I don't know how well it would work in practice.

In short, not much. Although miners would get the block reward more frequently, the block reward halving would happen more frequently as well, causing it to balance out exactly. To put it another way, there are only 21 million BTC to be distributed, the only difference is how fast you distribute them. Furthermore, each individual block would have fewer transactions, and therefore less transaction fees, but you get more blocks, again balancing it out exactly. 10 minutes was chosen because it's not so long that transactions take forever to be confirmed and not so fast that network propagation delays result in stale blocks.

You are assuming that all miners are motivated solely by profit and would not turn down a fee of any amount, not even a single satoshi. Maybe I'm being hopelessly optimistic, but I think there will always be at least some miners willing to sacrifice a portion of their profit "for the good of the network", as it were. I also think that if the difficulty drops dangerously low, a large number of these self-sacrificial miners will emerge to try to save the network. It's even possible (or even probable) that if Bitcoin becomes a major global economy, major governments will get behind it, spending taxpayers' dollars (bitcoins?) on unprofitable mining operations to ensure the security of the network.

No, your services are not identical to competitors' services. You are not just selling spaces in blocks which you might find in the future, you are selling spaces in blocks which you might find in the near future. People don't just want their transaction included a block eventually, they want their transaction included in a block immediately, and they will probably be willing to pay extra to make it happen. As long as there are some miners who refuse to accept small fees, there will be an incentive for people to pay higher fees, since this is the only to guarantee that their transactions will be included in a block as quickly as possible.