New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Verify transaction without propagating #4162

Closed
sidazhang opened this Issue May 9, 2014 · 9 comments

Comments

Projects
None yet
7 participants
@sidazhang

sidazhang commented May 9, 2014

Current Behaviour

If I use RPC command sendrawtransaction and supply an tx hex that is not acceptable (e.g. 1. if a signature is invalid, 2. contains a double spend) bitcoind will reject it, and if the transaction is verified, bitcoind will then propagate the transaction

Feature Request

It would be great if there could be a RPC call that allows verifyrawtransaction, which means it will only verify the transaction without propagating.

@gmaxwell

This comment has been minimized.

Member

gmaxwell commented May 9, 2014

One thing such a feature should have is the ability to take a list of transactions— since you may need to also provide the parents which you also don't want to broadcast yet.

An interesting question is should it be validating against the blockchain or against the memorypool?

@sidazhang

This comment has been minimized.

sidazhang commented May 9, 2014

+1 on taking a list of transactions

I feel that it should be validated against the memorypool. In other words, if verifyrawtransaction returns true, then it should be also propagatable with sendrawtransaction

@laanwj laanwj added Feature labels May 13, 2014

@dexX7

This comment has been minimized.

Contributor

dexX7 commented Aug 24, 2015

I agree with the general idea, and think this could be pretty useful.

While "decoderawtransaction" can be used to check the structure of transactions, and in a hacky way "signrawtransaction" can be used to verify scripts and signatures, it's feels more like an incomplete workaround.

A few random use cases that come to my mind, more or less related to this topic:

  • User doesn't want to run a node (for whatever reason), and instead uses a third party API provider; Bitcoin Core could be used to double check the results, at least to some degree
  • User wants to know which inputs are signed in a partially signed transaction
  • User signs a raw transaction offline, and wants to verify the signatures on another machine, before moving the signing keys on paper back to a vault
  • User receives a time-locked refund transaction, say for example from greenaddress.it, and wants to ensure the refund transaction is valid
  • Someone fools blockchain.info' pushtx API and "spoofs" a transaction, seemingly spending Satoshi's coins; Bitcoin Core could again be used to double check, whether it really may have happened
  • In the broader context: user wants to verify that a transaction is really included in a block (although this may already be covered by "verifytxoutproof")

Related to the first point is a discussion over at CryptoConsortium/CCSS#15, which indicates that relying on external API providers seems to be pretty common.

It should probably be differentiated between stateless and stateful verification (e.g. consider the mempool, or be able to check transactions to a limited degree with an unsynchronized offline client).

@dexX7 dexX7 referenced this issue Sep 29, 2015

Open

A plan for abstracting out libconsensus #6714

0 of 5 tasks complete

@laanwj laanwj added the RPC/REST/ZMQ label Feb 16, 2016

@laanwj

This comment has been minimized.

Member

laanwj commented Feb 16, 2016

We've discussed this on IRC a while ago, and this still seems useful.

One thing such a feature should have is the ability to take a list of transactions— since you may need to also provide the parents which you also don't want to broadcast yet.

Yes, it should definitely be able to take a list of transactions.

An interesting question is should it be validating against the blockchain or against the memorypool?

Probably either - should be a parameter, like for gettxout.

@laanwj laanwj removed the Priority Low label Feb 16, 2016

@dcousens

This comment has been minimized.

Contributor

dcousens commented Feb 16, 2016

What is intended by:

validating against the mempool

Do we mean simply checking it against policy? (no double spends, RBF, yada yada)

@NicolasDorier

This comment has been minimized.

Member

NicolasDorier commented Feb 17, 2016

For information, such feature would be very useful for LN.
There is several rule (like dust one) which can make a tx commitment unbroadcastable. This would result into theft.

If such function existed, a LN node would just have to check verifyrawtransaction before releasing the revocation hash of the previous commitment.

@laanwj

This comment has been minimized.

Member

laanwj commented Feb 17, 2016

Do we mean simply checking it against policy? (no double spends, RBF, yada yada)

See it as the difference between 'take into account 0conf' (blockchain+mempool) and 'don't take into account 0-conf' (blockchain).

@laanwj

This comment has been minimized.

Member

laanwj commented Feb 18, 2016

See #7552

laanwj added a commit to laanwj/bitcoin that referenced this issue Mar 18, 2016

rpc: Add `verifyrawtransactions` call
Add a RPC call to verify a set of raw transactions without propagating them.

Implements bitcoin#4162.

    verifyrawtransactions ["hexstring",...] ( options )

    Verifies one or more raw transactions (serialized, hex-encoded). If transactions depend on each other, they must be provided in order.

    Arguments:
    1. ["hexstring",...] (array of strings, required) The hex string of the raw transactions)
    2. options   (json object, optional)
         {
           "include_mempool"          (boolean, optional, default=true) Whether to include the mem pool
           "check_final"              (boolean, optional, default=true) Check that the transactions will be final by next block
           "check_standard"           (boolean, optional, default=true) Perform transaction standard checks
         }

    Result:
    null if the verification was successful, otherwise an error object:
    {
      "index":n,                (numeric) Index in transactions array of failed transaction
      "hash":"hex",             (string) Transaction hash of failed transaction
      "code": n,                (numeric) Reject code
      "reason": "text"          (string) Reject reason
      "debug_message": "text"   (string) Reject debug message
    }

@laanwj laanwj removed their assignment Aug 15, 2017

@MarcoFalke

This comment has been minimized.

Member

MarcoFalke commented Jun 24, 2018

See #11742

@MarcoFalke MarcoFalke closed this Jun 24, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment