crosschain transactions

will etherium support bitcoin or any othet crosschain transactions. for example if you want to send a divident for a share in btc?


  • VitalikButerinVitalikButerin Administrator Posts: 84 admin
    You can have an Ethereum contract that incentivizes someone else to make a Bitcoin transaction to a certain address, paying them some amount of ETH if they make the transaction and then submit the Merkle branch for the transcation proving its inclusion into a block.
  • chris613chris613 Member Posts: 93 ✭✭
    @vitalik? 's explanation leaves out how you validate that the block whose merkle branch you receive from the prover is actually on the BTC blockchain, or even that the transaction hash represents the transaction you wanted. My understanding is that you'd need an external application using libethereum to publish all the BTC block hashes as an ethereum data feed contract. The best solution probably involves several of these run by independent parties and the use of an 'n of m' scheme to make it acceptable to trust them. Validating that the transaction hash actually describes an acceptable transaction would require the prover to provide other data that the contract can add to the txout it's looking for in order to re-build the transaction and check the resulting hash. I think this data is pretty extensive, like all the txins, and the txout for the change address. Is there some other way of accomplishing these that I'm missing? After you've taken care of these two issues, an ethereum contract can reliably decide to take action based on a proof that a particular BTC transaction occurred.

    @romanm?, you asked about sending a BTC dividend. Off the top of my head, here is how I would approach such a system. Assume all of the stuff above is settled.

    * Have a contract that calculates dividends owed to each BTC address and puts them in its storage
    * An external application using libethereum would watch for this contract to be activated, read the resulting lists of dividends, and make all the BTC payments via an interface to a bitcoin client
    * The application waits for the transactions to get confirmed, then sends an ethereum transaction back to the contract that says "this dividend payout was settled by this BTC transaction" (including whatever bits of proof we decide are required)

    Anyone with access to the ethereum blockchain (who also trusts the same n of m bitcoin block feeds) can now validate both the logic used to calculate the dividends as well as the settlement of the payment. AFAICT the distributed calculation of the dividend is the only thing ethereum really brings to this scenario. If you were okay with a conventional computing resource calculating the dividend, the results could still be validated since the payout is on the BTC blockchain. What ethereum offers is a way to make the dividend payout calculation as reliable and permanent a service as the ethereum network itself, but the actual payment processor would still need to be a conventional computing resource.

    This idea of incentivising "anyone" to be able to make the payment is theoretically a way of eliminating this final dependence on the single party BTC payment processor. In order to avoid requiring payment processors from having to monitor thousands of contracts in ever growing numbers with different protocols for how to describe payment requests, I think you'd actually need yet another contract that could serve as a BTC payment gateway. This well known contract would allow contracts like your dividend example to request a particular payment be made. Then any number of payment processors (conventional computing resources, not other ethereum contracts) would monitor this contract and submit payment proofs to collect the reward. I think there would need to be a protocol that helps payment processors avoid sending duplicate transactions that aren't going to be accepted, like you "commit" to sending a particular transaction by sending a tx to the contract and waiting for it to confirm so you're sure that your commitment was the one to get accepted, then you send the BTC transaction, wait for it to confirm, and then collect your reward by submitting the proof. The gateway contract, for it's part, would need to somehow blacklist processors that make commitments they don't fulfil. Frankly this seems wrought with problems, but I've typed enough, so I'd be interested to hear what others think of it.
  • JasperJasper Eindhoven, the NetherlandsMember Posts: 514 ✭✭✭
    I wrote this transaction exchange thing, that uses first setting up contracts based on H=H(S), and later the guy with the secret S, is forced to reveals it in order to 'release' one of the contracts. It doesnt work between Bitcoin and ethereum, but it would work between different ethereum blockchains.(and presumably the idea could be used with Bitcoin too)

    Anyway, you could easily offer a reward, and use a little escrow system to increase the robustness.(increase the cost of attack)

    Of course contracts cant use it, they cant see that transactions went through.. However, if it is simple payment-for-a-transaction(on a single blockchain), that would be usable by contracts. Easy to implement too, just the same restrictions on one of the users, until they receive payment.

    There is a point about the ability to restrict yourself here. For instance if you have 'an account' with your public key to simple namecoin or subcurrency contracts, you can't do this, because the public key cant be restricted from sending transactions. So you'd either want features for this in the namecoin/subcurrencies, or you'd want to use 'satelite contracts'. (as you know, 'satelite contracts' are also useful for setting a limited budget for the case you computer is hacked, and multiple keys could be used to unlock it fully, we have a term for it? 'wallet contract', 'account contract'?)
Sign In or Register to comment.