ethereum / btcrelay Goto Github PK

I think what we need is a receipt verification function.
input: the target BTC address, amount of BTC received at the target BTC address, number of confirmations
output: true if the amount of BTC has been received at the target BTC address with the specified number of confirmations; false otherwise.

a subroutine is also needed:
input: BTC tx hash
output: how deep is the tx embedded in the main branch? of course, the returned value reflects the "current" status. for a current ETH block height, there is a corresponding BTC block height.

any comment? can we have such a function?

and there is an ultimate question: why do we trust the function? is it trustworthy?

self.highScore = 1 should more accurately be self.highScore = chainWork
https://github.com/ethereum/btcrelay/blob/develop/btcrelay.se#L67

But it doesn't affect things because scorePrevBlock (not highScore) is used to compute the next scoreBlock:

scoreBlock = scorePrevBlock + difficulty

and scorePrevBlock
scorePrevBlock = m_getScore(hashPrevBlock)

Note: there are also tests that verified that scores are expected. (Though there must be a missing/wront test that highScore is correct value after setInitialParent)

on Morden, it is a known issue that the chainwork is NOT accurate. Need to make sure it is correct when deploying to Frontier.

also, replace "cumulative difficulty" with chainwork to be more accurate with terminology

review and update functions, such as computeMerkle, that should return uint256

Hey there,

I noticed that btcrelay.org has a link that says "For further details, view this DEVCON1 presentation". But the link has no href value. I believe it should point here.

I went to look for the site so I could send a PR, but I couldn't find it! So the real issue is, the site isn't open-source :)

Seems like a really important project but are people even relaying any more?

Whoever deployed the "live" contract mentioned in README.md, please also do the Etherscan verification: https://etherscan.io/verifyContract?a=0x41f274c0023f83391de4e0733c609df5a124c3d4

It's slightly misleading to call the contract live though when the last storeBlockHeader was 94 days ago... hope it gets better; after all, a lot of projects are out there to solve inter-blockchain communication. This solution is already running, but no one seems to be using it.

https://github.com/ethereum/btcrelay/blob/develop/incentive.se#L32-L35

        if tx.gasprice < (1023*gLastGasPrice/1024) || tx.gasprice > (1025*gLastGasPrice/1024):
            currGP = gLastGasPrice
        else:
            currGP = tx.gasprice

The else clause should be either 1023*gLastGasPrice/1024 or 1025*gLastGasPrice/1024 (So that honest gas prices can affect the trend of the gas price, instead of just using the last gas price which may have been "set" by an "attacker")

A) relayTx passes all gas to callee contract <- current behavior.
There's 2 cases:
A1) gas is enough for relayTx and callee so the log is done.
A2) gas is all consumed by callee contract, so tx is OOG and no log generated.

B) Suggested behavior is for relayTx to reserve some gas for itself and provide/limit a specific amount to callee contract.
2 cases:
B1) gas is enough for relayTx and gas amount to callee is enough so the log is done.
B2) gas is enough for relayTx but provided gas to callee contract is insufficient, so OOG should be handled by relayTx and a log still generated.

So consider updating the relayTx interface to take an additional uint param, which is how much gas to provide to processTransaction

the lookup button won't call MetaMask

BtcChain.se, line 23, m_saveAncestors

Takes hashprevblockarg as argument, but two lines later uses blockHashArg as hashPrevBlock, ignoring the parameter completely (line 25).

http://btcrelay.surge.sh/mainnetStatus.html

Relayer: 0x1a23fd30aabf5ad53bab3093dcd4948e15cec80 should be 0x01a23fd30aabf5ad53bab3093dcd4948e15cec80

missing the first 0

Thank you for the report @christianlundkvist
e3d0619#commitcomment-14883610

I've examined and have a PR to fix.

It appears (based on the Readme) that this tool is only available as a Python script. It would be nice if it was released as a binary so I could run it without having to install Python.

The binaries should be available on all major OSs.

StoreHeader for the header for blockheight say 10010 will lead to ambiguty with ERR_DIFFICULTY https://github.com/ethereum/btcrelay/blob/develop/constants.se#L15

maybe error codes for storeBlockHeader should all be negative numbers.

due to 637c80c

It costs about 0.04$ to add a new header in gas costs. This makes it expensive to get it current (about 10k blocks behind)- any ideas to optimize to make it easier to keep up to date?

Thanks

For those that are interested, a Solidity library that parses a Bitcoin transaction would be a great compliment to BTC Relay. The first version could parse a "standard" Bitcoin transaction that just has 1 input and 1 output, like the following in Serpent:
https://github.com/ethereum/btcrelay/blob/master/example-btc-eth/btcSpecialTx.se

A more general, but outdated (since it accepts input as hex string instead of bytes) example is:
https://github.com/ethereum/btcrelay/blob/master/example-btc-eth/btcTx.se

name: Bug Report
description: File a bug report
title: "[Bug]: "
labels: ["bug", "triage"]
assignees:

• octocat
  body:
• type: markdown
  attributes:
  value: |
  Thanks for taking the time to fill out this bug report!
• type: input
  id: contact
  attributes:
  label: Contact Details
  description: How can we get in touch with you if we need more info?
  placeholder: [email protected]
  validations:
  required: false
• type: textarea
  id: what-happened
  attributes:
  label: What happened?
  description: Also tell us, what did you expect to happen?
  placeholder: Tell us what you see!
  value: "A bug happened!"
  validations:
  required: true
• type: dropdown
  id: version
  attributes:
  label: Version
  description: What version of our software are you running?
  options:
  - 1.0.2 (Default)
  - 1.0.3 (Edge)
  validations:
  required: true
• type: dropdown
  id: browsers
  attributes:
  label: What browsers are you seeing the problem on?
  multiple: true
  options:
  - Firefox
  - Chrome
  - Safari
  - Microsoft Edge
• type: textarea
  id: logs
  attributes:
  label: Relevant log output
  description: Please copy and paste any relevant log output. This will be automatically formatted into code, so no need for backticks.
  render: shell
• type: checkboxes
  id: terms
  attributes:
  label: Code of Conduct
  description: By submitting this issue, you agree to follow our Code of Conduct
  options:
  - label: I agree to follow this project's Code of Conduct
  required: true

With Metropolis, there will be a new opcode, REVERT (ethereum/EIPs#206) and RETURNDATA (ethereum/EIPs#211).

The REVERT opcode will function as a throw, reverting state-changes, but will not burn the remaining gas. Additionally, it can return some data, in order to provide the callee with information about the error.

Unfortunately, this EVM-change undermines the model for synchronous oracles which accept payment; it's possible to

1. Make a call to BTCFreelay
2. Make a call to InternalCall
   3. Perform call to BTCRelay for verification, along with payment
   4. Perform revert along with the response from BTCRelay

This would revert the payment(s), but still grant access to the return value.

Note: Even without RETURNDATA , it would still be possible to perform this attack, albeit with less data being extracted. Example gist showing how to 'freeload' on btcrelay using revert without returndata: https://gist.github.com/holiman/51f9b02b64f864b896129d329757460c .

Note 2, this can also be performed already today, using a regular throw, but the attack is quite 'messy' since it needs to handle several intricate cases of OOG due to remaining gas being discarded at every throw.

I'm filing this as an issue, even if it's not yet implemented, so there can be a discussion about possible future modifications that can be made. Also, posting it as a 'known issue' here makes in not eligible for a reward in the bug bounty.

when there are 2 blocks that can be at the Head of btcrelay's internal "blockchain", should btcrelay always prioritize the head hash that is smallest in value...

https://github.com/ethereum/btcrelay/blob/develop/test/test_btcChain.py#L18

the depths are now powers of 5 (instead of 4 https://github.com/ethereum/btcrelay/blob/develop/btcChain.se#L108-L109)

and switch over from Morden to Ropsten

def relayTx(txBytes:str, txIndex, sibling:arr, txBlockHash, contract):
    txHash = self.verifyTx(txBytes, txIndex, sibling, txBlockHash,
value=msg.value)
    if txHash != 0:
        returnCode = contract.processTransaction(txBytes, txHash)
        log(type=RelayTransaction, txHash, returnCode)
        return(returnCode)

    log(type=RelayTransaction, 0, ERR_RELAY_VERIFY)
    return(ERR_RELAY_VERIFY)

The 'contract' in this case, if he returns ERR_RELAY_VERIFY, won't that
look very much like the bitcoin Tx was not verified, even though it was
successfully verified... Have to consider fixing this