I will discuss what I think Zionism is. I think Zionism exists for religious Jews who want a G-d-fearing Homeland to go to. Zionism exists for secular Jews as a place of sanctuary.

Adolf Hitler, as well as modern day Neo-Nazi groups, usually decide to take on a negative view of a person if they are born to a Jewish mother. Hitler did not care whether one was secular or religious. If they were Jewish, then Hitler did not like them. That is why Israel exists. To give both secular and religious Jews a place to go to when they feel like the world, or a particular part of the world, is bearing down on them with threats of antisemitism. That is why many Jews who are secular still support Israel. Because many anti-Semites seem to dislike Jews because they were born Jewish and not whether or not they practice the religion.

It was stated on the download page.  With a direct link to the 12.04.3 download.  It might've gotten lost in the upgrade to 0.92.  I'll make sure it gets back in there.

We didn't get around to upgrading the offline bundles.  I think you still need to use 12.04.3.  

Unfortunately, we permanently broke support for 10.04.  I really tried not to do that, but some of the new stuff we made (including the universal builder that makes things much simpler to deploy on other Linux systems), requires a version of libc that is newer than 10.04.   The benefit here was that now we have a single deb package that works on all Ubuntu newer than 12.04 -- we used to have to have lots of different packages and individually verify which OSes it worked on.

For myself, I just keep an old version 0.91.2 on my online computer, and use that when I need to sign something with my offline computer.  It's certainly inconvenient, but at least the databases don't have to be rebuilt to switch, so it doesn't take that long.  I plan to eventually upgrade/switch my offline computer.  It may be inconvenient, but you can be sure that I myself and inconvenienced too!  Yet I still went through with it because of the simplicity and robustness added by making the associated change.

Yes, moving past 0.91.2 will require both offline and online computers to be upgraded to 0.92.1. This is true whether or not you plan to use multisig.

Do I understand correctly that upgrading from 0.91 would require upgrading the offline wallets too?  If that is the case, please put a warning on the website, upgrading the offline Armory may be significant work depending on the setup.  I for one plan to wait till the dust has settled.  I know that no new changes are expected in the communication protocol, but there will probably be many bug fixes.

140,000 is just the site wallet for silkroad users.  Then there is Ross's 400k and about 400k from that dealer which occured more recently.

I've been thinking about ethereum a bit recently. Parts of it are pretty interesting.

Some of it seems like needless re-engineering (like creating a new proof-of-work or a new currency). And in general, I suspect they're trying to do too much-- "complexity is the enemy of security"-- and will end up either radically reducing the scope of what they're trying to do or will get tired of playing whack-a-mole with security and DoS vulnerabilities.

But I might be wrong; maybe I'm just an old, cynical curmudgeon who has played a lot of whack-a-mole with security and DoS vulnerabilities.

Anyway, one of the ideas in ethereum I do find interesting is a contract that has funds associated with it, arbitrary code and state. Verified by the network instead of a central authority. And with transactions as a pseudo-anonymous way of triggering evaluation of the contract, paying funds held in escrow with the contract, and updating its state.

So... could we take that interesting idea and map it onto Bitcoin? Could somebody create "Bit-thereum" on top of Bitcoin as it exists today?

The answer is "yes," if we're willing to replace "verified by the entire network" with "verified by a set of semi-trusted 'oracles'."

That's cheating, though, isn't it? We're not entirely decentralized if we are trusting eleven contract-verifying-services not to collude (or all get hacked) to violate conditions encoded in some contract(s).

It is cheating a bit... but all of the really interesting complex contracts I can think of require data from outside the blockchain. Like the BTC/USD exchange rate on some future date (for blockchain-enforced futures contracts).

ethereum doesn't have some magic solution to the "data outside the blockchain" issue: as their whitepaper says, "a trusted source is still needed to provide the price ticker."  And there is already at least one startup working on a solution to the "data outside the Bitcoin blockchain" problem (Reality Keys).

Moving from one trusted source to M-of-N semi-trusted sources would be an improvement.

So I'll start there, and imagine that there are semi-trusted 'oracles' that compete to be the most reliable and trustworthy verifiers of contracts. People involved in contracts choose N of them, and then require that contract conditions be validated by one or more of them before the contract pays out. Pick more than one so no single oracle can steal the contract's funds, but less than N in case some of them go out of business or just aren't around to validate contracts when it is time for the contract to pay out.

These oracles need an agreed-upon, machine-readable contract language, but that shouldn't be hard. There are lots of interesting design decisions on what information contract scripts have access to (and lots of not-so-interesting-to-me design decisions on the language itself; is it stack-based, register-based, high-level, low-level bytecode, etc etc etc). Copying most of the ethereum contract language design (and maybe re-using lots of their code) might be a good way to go.

Maybe off-blockchain data would fetched from the web via URI. The tricky bit would be how to handle error conditions like "This contract is about average temperature in Aruba according to the World Bank, but the World Bank is no longer publishing that information."

They also need a way to store some value in escrow, associated with the contract, so that M-of-N of them must agree to any release of funds. Bitcoin multi-signature transactions could be used for that:

1. Whoever is involved in the contract gives the contract code to each of the N oracles and gets back N public keys.
2. The oracles would store the contract code and the private key, and should be willing to give out the public key to anybody who knows the contract code.
3. Anybody can then add funds to the contract by sending bitcoins into the M-of-N multisig made up of the public keys. And maybe associate some data with the escrowed funds by hashing it and include a prune-able OP_RETURN output with the hash.

So far, nothing tricky either on the Bitcoin side or the oracle's side. But what happens when it is time for the oracles to evaluate the contract and disburse some or all of the funds? What triggers the oracles to evaluate the contract (and update any state associated with the contract), and who creates and broadcasts the disburse-funds-from-escrow transaction?

Those are interesting design decisions. I'd probably have whoever is getting paid be responsible for creating the disbursement transaction, contacting M of N oracles to get signatures and then broadcast the transaction. When I say "whoever" I really mean some contract software running either in the cloud or on somebody's machine.

When to update the state associated with a contract is another interesting design decision. My intuition is a contract's state should be tied to Bitcoin transaction confirmations and the state of the transaction outputs being spent. So a contract could be in several states at once if one or more of its inputs are double-spends. Once blockchain confirmations choose one side of the double-spend or another the state of the contract would also be resolved.

I imagine the contract code would have access to all of the unspent transaction outputs (and associated OP_RETURN data, plus metadata like how many confirmations they have, which block they appeared in, maybe their merkle branch...) plus the disbursement transaction outputs. Another interesting design decision is how to handle unconfirmed transaction outputs; I suspect that letting contracts respend zero-confirmation outputs, combined with a promise from the oracles that they will never sign the same output twice might be incredibly powerful and allow all sorts of interesting applications.

Oracles could be vulnerable to denial-of-service attacks-- e.g. an attacker requesting an endless number of public keys for contracts they have no intention of fulfilling. Or an attacker requesting an endless number of contract evaluations (and signatures).

To solve the first problem, oracles could require a small up-front payment to establish a contract. And to solve the second, oracles could require that any escrow disbursement also include a small payment (they would simply refuse to sign any escrow disbursement transaction that did not include a payment to their public key). All that makes economic sense, and gives oracle operators a clear business model.

Leveraging Bitcoin transactions for the escrow/funding parts of the problem protects oracles from a whole other set of possible denial-of-service attacks; for example, "penny-flooding" a contract to make it very CPU-expensive for the oracle to evaluate would cost the attacker a significant amount of Bitcoin transaction fees.

Oracles might also put limits in their terms of service to fend off potential attackers, and collaborate to confiscate escrowed funds if an attacker created a very expensive-to-validate contract.: "Any contract that uses more than one CPU-microsecond to validate may be terminated with the funds disbursed in equal amounts to the N validating oracles."  They would maintain their reputations by publishing all of the information about the rogue contract.

But... but... doesn't it have to be more complicated than that? New Bitcoin Script opcodes? Contract code in the blockchain? A merged-mined chain or new colored coin or something?

I don't think so. Bitcoin already provides a global currency and distributed ledger-- there is no need to re-invent those wheels. Combining real-world information with Bitcoin is where things start to get really interesting.

I'm still convinced we went to war in Afghanistan for precious metals, of course, you'll never get politicians to admit this and the media barely report on it as with anything that's important.

It has everything to do with them. There is no other way to do it risk free without cryptos.

How do I verify that Armory is running via TOR?

Thanks!

TOR use port 9150 not 9050, FYI.