Mine does (as outputs, at least). Using P2SH inputs safely requires a message signing algorithm compatible with multi-sig scriptPubKeys. This is a separate problem that does need to be solved as well.

This subnet is owned by a Swiss academic institution:

http://whois.domaintools.com/129.132.230.0

If anyone knows who this group is, can they please make them aware of the difficulties they are causing?

It's a perfectly valid address. You just need to use Bitcoin-Qt or another sane wallet application.

No, nothing at all. Completely orthogonal issues.

No, you have a misunderstanding of how bitcoin works. There is no "from" address. A merchant knows when they've been paid because they receive payment to a one-time-use address they generated specifically for the transaction. The way this would work in CoinJoin is that you pretend that you are mixing X coins, where X is the amount that you are paying the merchant, and then use the key id provided by the merchant for your blinded output.

And yes, this is a PURELY higher-level protocol that makes no changes to how bitcoin currently operates.

The mixing application described in the OP uses same valued outputs for two reasons: (1) to avoid this sort of identification, and (2) to prevent the facilitator from learning identities through blind signatures. This requires that within a single transaction, the mixed outputs must have the same value denominations (or be divided into groups of same-valued denominations). The hypothetical given is a weaker protocol than the OP.

That said, there is no reason that the common denomination used by one transaction has to match or be a multiple of the common denomination of another - that gains you nothing as far as I can tell.

Carlton, you don't reuse addresses. That was your mistake.

I'm not really sure I follow. From my analysis there is zero benefit to mandating common output sizes across multiple transactions. gmaxwell, am I mistaken?

justusranvier, I'm not sure I follow. Mixing is only occurring within a single transaction. Within that transaction, some subset of the outputs must be same-sized. But I do not think there is any reason that all transactions must use the same (set of) output sizes...

Real investment. Contrary to loose terminology prevalent on these forums, holding currency is not investment in the economic sense, it is speculation. Investment is the purchase of goods not for consumption but for future production. For example, building a factory, hiring engineers and designers to build a product, training a workforce to make them more productive, etc. These actions grow the economy.

Currency speculation, on the other hand, impedes the larger economy by tying up resources which would otherwise be spent on consumption or invested in real projects. This unearned rent impedes real economic growth, acting as a parasitic tax on the economy.

The ~5% annual demurrage of Freicoin is chosen specifically to counteract this effect, such that speculators are hit with a penalty exactly equal to the unearned rent they extract from the rest of society, driving them to find more productive uses for their money.

EDIT: Demurrage is kinda like copyleft. Inflation currency is evil because it structures our economy and by extension our society to be debt-based in an arrangement that only benefits the bankers (e.g. mortgage and national debt interest payments being a transfer of wealth from the little guy to Wall St.). Just how Stallman created GPL to protect users, demurrage currency protects the little guy buy gaining the macroeconomic benefits of inflationary currency in such a way that improves society without favoring bankers (or anyone else).

Because... why would you? You're not going to recoup that investment.

Have you tried performing BDB recovery and dumping of (a copy of) the wallet file? If it is at all damaged, Bitcoin-Qt probably won't load it, but the BDB tools might. You can then use pywallet or something similar to reconstruct a wallet with the keys you can find.

No, you are mistaken. There has to be agreement between two parties in an exchange as to what the color they are exchanging is. However coloring is deterministic, and does not affect bitcoin consensus in any way. So as long as you and the people you are interacting with are in agreement on the color definition, that is all that is required. You do not need global consensus on anything except the bitcoin block chain.

8 sounds very much like "money" in chinese.


Hah, right.

Kubuntu is still pretty beefy. Perhaps Xubuntu is a better fit?

You don't need to rewrite the BIOS eeprom. You can stick the payload (or its bootloader) in any of the other NVRAM locations and inject it into the running BIOS during boot when the infected device is brought up.

This embedded hardware is much more common and standardized than you might think. Pretty much all PCs use the same USB host chips. And for a given peripheral there's usually only a handful of chips running similar architectures available on the market. The BIOS/EFI firmware has standard extension interfaces that all vendors support and the malware would hook into to load itself.

Of course there's still a lot of engineering work that needs to be done to create such a virus, enough to put it in the category of almost-certainly-state-sponsored. But once it is isolated in the lab, it's a relatively small operation to dissect and re-purpose its various components to an existing bitcoin wallet seeking malware, for example.

Ente, that's why we invented this thing called a trusted platform module which lets us do crypto operations in a boxed, temper resistant environment.

flipperfish, most USB controllers do some processing at that layer. That's why there is a microcontroller, after all. If there is a security hole at that layer, then a specially constructed USB device (like, say, those given out at conferences or the G8 summit) could do a buffer-overflow like attack against the microcontroller itself, before the frame is passed up to the operating system's USB stack. It then flashes the USB controller with its own custom firmware, sticks the virus payload in NVRAM for insertion into the kernel at next boot, and then passes up fixed, normal USB frames to the host OS. What you need to realize is that none of this occurs on the CPU or in main memory, so it's pretty much undetectable with the current generation of commercially available security software. When you flash the USB firmware, what do you think it does? It send commands to... the USB microcrontoller. If the virus is already in the controller, then it is perfectly capable of flashing itself without outside involvement.

And yes, using a new stick doesn't really gain you anything for the reason you mention.

Yes, the facilitator gains no extra information about the transaction than is observable from the outside, if blind signing is used (see gmaxwell's posts at the beginning of this thread).