Bitcoin Forum

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 think Gavin is right that any usefull contract needs outside input and this is something which requires trust.

so i do like his idea

I've been giving contracts a lot of thought lately and everything interesting and useful that I've come up with to date needs outside information anyways.  And that's always been the problem: right now there is no service that I can pay to sign a transaction if, for example, the London Gold fix drops below $1000 / oz in the next 12 months.  So it seems that having Oracles that compete in a "market for trust" would be very useful.

I really like Gavin's idea. 

This subject has been a frequent one in #bitcoin-wizards.

I didn't allow any script directed I/O in my design at all, instead, I planned on having IO done as a pre-processing stage and provided as inputs to the scripts— they're pure functions.  Turns out it's a lot easier to handle the VM security when it does no IO, it's also easier to handle resource usage when the script won't be blocking to wait on the network.

It's funny that we just published a whitepaper explaining the technical details of such a solution.

http://github.com/orisi/wiki/wiki/Orisi-White-Paper

There's also a basic implementation in the works, to be released today evening, or tomorrow.

Our team has been working on that for the past three weeks :)

It's funny that we just published a whitepaper explaining the technical details of such a solution.

http://github.com/orisi/wiki/wiki/Orisi-White-Paper

There's also a basic implementation in the works, to be released today evening, or tomorrow.

Our team has been working on that for the past three weeks :)

is it peer-to-peer?

-bm

I've been giving contracts a lot of thought lately and everything interesting and useful that I've come up with to date needs outside information anyways.  And that's always been the problem: right now there is no service that I can pay to sign a transaction if, for example, the London Gold fix drops below $1000 / oz in the next 12 months.  So it seems that having Oracles that compete in a "market for trust" would be very useful.

I really like Gavin's idea.  

It's funny that we just published a whitepaper explaining the technical details of such a solution.

http://github.com/orisi/wiki/wiki/Orisi-White-Paper

There's also a basic implementation in the works, to be released today evening, or tomorrow.

Our team has been working on that for the past three weeks :)

one trustless contract could be a just-dice copy (including bankroll investing

Part of my concern with resource control and IO complexity is that ultimately I'd like to have this virtual machine running inside an IBM cryptocard, with remote attestation... not just to protect the users from a cheating operator, but to protect the operator from being threatened by users that might want to try to coerce them.

I think the IBM cards are basically dead, at this point. TC is now all about Intel TXT (sort of crappy) or SGX (not here yet but seems to have a much better design).

Fundamentally, two big problems to solve are rendezvous and communication, both user/agent and agent/agent.  BitMessage attempts to solve these problems, but BitMessage has its own scaling and other code problems.

Users need to be able to find agents (oracles) in a vendor-neutral, open market manner, where one vendor may not DoS other vendors off the market.  (vendor == agent's owner/operator)

And agents need to communicate with other agents in the market.

Once we have a good, decentralized chat room for market players to congregate and communicate, it is trivial to implement M-of-N oracles.

Yes, the WoT is a common solution.  In order to scale well, WoT usually requires one or several centralizing entities that act as large signature hubs.

And even so, you still need a useful rendezvous mechanism.

If OP_ADD is allowed, the bulky 8-of-11 multisig is not necessary and some block space is saved

Can you explain this?  How does OP_ADD simplify the security requirements?

pub-a OP_CHECKSIGVERIFY OP_4 pub1 pub2 pub3 pub4 pub5 pub6 pub7 OP_7 OP_CHECKMULTISIG

OP_4 pub1 pub2 pub3 pub4 pub5 pub6 pub7 OP_7 OP_CHECKMULTISIGVERIFY pub-a OP_CHECKSIG

LOL, a common solution?

in what exactly?

-bm

The goal of ethereum is to replace the Internet (DNS, email, facebook, ...). It's not even remotely comparable to the goals of Bitcoin. I very much doubt that Bitcoin can move in this direction, for many reasons. I mean, for example the accounting system is a mess and is going to be removed. If not even something which is in the core can be fixed, how could one take one such large goals? The last 16 bips of 39 bips are in draft mode. The last feature update of Bitcoin is now 20 months ago.

Anyone taking this seriously? Seems to me that innovation in the protocol is stalled. Anyone asking why? Is it the protocol architecture? Is it the core dev team (size, resources, politics)? I would think some of the venture money coming in would be paying attention (Andreesen, R. Branson). Oh, look, Branson just put money into TransferWise...

I think the IBM cards are basically dead, at this point. TC is now all about Intel TXT (sort of crappy) or SGX (not here yet but seems to have a much better design).

Oh, even OP_ADD is not needed.

Public key of Alice is pub-a; pub1-pub7 are public keys of 7 oracles.

For 4 of 7 oracles, the script could be:


or equivalently,


(actually the paper mentioned this: "Transaction of 1+(m of n) signatures would be non-standard")

OP_IF
 <some perfectly innocuous, already-standard m of n or whatever>
OP_ELSE
 <some other perfectly innocuous, already-standard m of n or whatever>
OP_ENDIF

Nope, still sold and supported— and there was a new version (third generation) released last year. (I also have a second generation card to screw around with…)

Nope, still sold and supported— and there was a new version (third generation) released last year. (I also have a second generation card to screw around with…)

How much for such card? Is there any real service (bitcoin or not bitcoin related) on the web using these cards?

"Those who don't understand Open-Transactions are condemned to reinvent it, poorly."

yeah right. these lines of code is all you need to know about the project.. document strings in source code. one could not make this up.

https://github.com/Open-Transactions/Open-Transactions/blob/master/src/ots/OTServer.cpp#L1611

there were at one time quotes from the Bible in "Open Transactions" source code.

-bm

 if (NULL != m_pUserID)
        delete m_pUserID;
    m_pUserID         = NULL;

well, I've read I don't know how many million lines of code in my life, but I've never seen something quite like it. If you're going to rely on this software for financial transactions, well... good luck? Just because somebody puts together 50kLOC does not mean anything. It could be producing random cooking recipes. the same applies to ethereum. just because someone has an idea and code together software, doesn't mean it actually does what it is claimed. the space of all possible software is pretty large.

OT has been talking about interesting things in connection with Bitcoin since at least mid 2011 (my personal recollection) but in all this time has still not, as far as I know, produced even the simplest tool to do anything useful with it.

I wish them the best of luck, but to the extent that the promotion without delivery is distracting people from actually creating stuff that people can use it's not a good thing.

OT has been talking about interesting things in connection with Bitcoin since at least mid 2011 (my personal recollection) but in all this time has still not, as far as I know, produced even the simplest tool to do anything useful with it and Bitcoin.

I wish them the best of luck, but to the extent that the promotion without delivery is distracting people from actually creating stuff that people can use it's not a good thing.

It does seem to be the case that building things that work in the real world, not jus in laboratory conditions,  takes time.