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

[RPC] Add utility getsignaturehash #11653

Closed
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
7 participants
@NicolasDorier
Member

NicolasDorier commented Nov 10, 2017

Add an utility to get the signature hash in a generic way.
signrawtransaction can't create a signature for an arbitrary scriptCode, as it is using ProduceSignature internally. This make it impossible to create complex scripts without a library.

Show outdated Hide outdated src/rpc/misc.cpp
@NicolasDorier

This comment has been minimized.

Show comment
Hide comment
@NicolasDorier

NicolasDorier Nov 10, 2017

Member

Just refactored.

Member

NicolasDorier commented Nov 10, 2017

Just refactored.

@promag

Some comments.

Missing tests for all sighashtype values and missing test for sigversion = WITNESS_V0?

Show outdated Hide outdated src/rpc/server.cpp
Show outdated Hide outdated src/rpc/server.cpp
Show outdated Hide outdated src/rpc/server.cpp
Show outdated Hide outdated test/functional/getsignaturehash.py
Show outdated Hide outdated test/functional/getsignaturehash.py
Show outdated Hide outdated test/functional/getsignaturehash.py
Show outdated Hide outdated src/rpc/server.cpp
Show outdated Hide outdated src/rpc/misc.cpp
Show outdated Hide outdated src/rpc/misc.cpp
Show outdated Hide outdated src/rpc/misc.cpp
Show outdated Hide outdated src/rpc/misc.cpp
Show outdated Hide outdated src/rpc/misc.cpp
@luke-jr

This comment has been minimized.

Show comment
Hide comment
@luke-jr

luke-jr Nov 10, 2017

Member

(Light concept NACK because utilities should be in libraries, not RPC.)

Member

luke-jr commented Nov 10, 2017

(Light concept NACK because utilities should be in libraries, not RPC.)

@promag

This comment has been minimized.

Show comment
Hide comment
@promag

promag Nov 10, 2017

Member

@luke-jr I understand that but there is no harm in having these utilities:

  • they don't block, just spend a thread handling the request;
  • make the source stronger by using core code and having test coverage;
  • always updated response, libraries can have bugs or be outdated.

That said, most *rawtransactions are also utilities, and they are supported.

Member

promag commented Nov 10, 2017

@luke-jr I understand that but there is no harm in having these utilities:

  • they don't block, just spend a thread handling the request;
  • make the source stronger by using core code and having test coverage;
  • always updated response, libraries can have bugs or be outdated.

That said, most *rawtransactions are also utilities, and they are supported.

@NicolasDorier

This comment has been minimized.

Show comment
Hide comment
@NicolasDorier

NicolasDorier Nov 11, 2017

Member

@luke-jr When you start doing services which span multiple blockchain (cross chain swap), then library can't possibly know how to sign each and every of them. While if each expose getsignaturehash it becomes possible. I bumped into the need of that as I was trying to do a cross chain swap between bitcoin and elements.

Member

NicolasDorier commented Nov 11, 2017

@luke-jr When you start doing services which span multiple blockchain (cross chain swap), then library can't possibly know how to sign each and every of them. While if each expose getsignaturehash it becomes possible. I bumped into the need of that as I was trying to do a cross chain swap between bitcoin and elements.

@sipa

This comment has been minimized.

Show comment
Hide comment
@sipa

sipa Nov 11, 2017

Member

@NicolasDorier I don't see how that is related. You need some code specific for each chain anyway, no?

Member

sipa commented Nov 11, 2017

@NicolasDorier I don't see how that is related. You need some code specific for each chain anyway, no?

@NicolasDorier

This comment has been minimized.

Show comment
Hide comment
@NicolasDorier

NicolasDorier Nov 11, 2017

Member

@sipa, not really. By using using decoderawtransaction, decodescript, createrawtransaction and all of those utilities, I can create transaction on two chains even if their binary representation of a transaction is completely different.
Basically, this is one of the piece missing to have a generic code for all crypto forked from Bitcoin, which does not rely on a library knowing the details.

Member

NicolasDorier commented Nov 11, 2017

@sipa, not really. By using using decoderawtransaction, decodescript, createrawtransaction and all of those utilities, I can create transaction on two chains even if their binary representation of a transaction is completely different.
Basically, this is one of the piece missing to have a generic code for all crypto forked from Bitcoin, which does not rely on a library knowing the details.

@sipa

This comment has been minimized.

Show comment
Hide comment
@sipa

sipa Nov 11, 2017

Member

@NicolasDorier I don't understand, you can't just paste signature hashes into any other RPC, so it can't be a 'missing piece'. You still need to know what the chain's signatures look like (ECDSA, sighash flags, scripting system, ...) to use that information for anything. I expect that if not already, between any two interesting chains those things will differ significantly.

A more useful thing would be an RPC which you give an unsigned transaction, a key and/or an output being spent, possibly a scriptCode, and a sighash flag, and it gives you a piece of scriptSig/witness containing a valid signature for it. You'd still be responsible for combining it with other script elements. Even that isn't a missing piece IMHO, but it wouldn't need intricate knowledge of the digital signature system in your application.

Member

sipa commented Nov 11, 2017

@NicolasDorier I don't understand, you can't just paste signature hashes into any other RPC, so it can't be a 'missing piece'. You still need to know what the chain's signatures look like (ECDSA, sighash flags, scripting system, ...) to use that information for anything. I expect that if not already, between any two interesting chains those things will differ significantly.

A more useful thing would be an RPC which you give an unsigned transaction, a key and/or an output being spent, possibly a scriptCode, and a sighash flag, and it gives you a piece of scriptSig/witness containing a valid signature for it. You'd still be responsible for combining it with other script elements. Even that isn't a missing piece IMHO, but it wouldn't need intricate knowledge of the digital signature system in your application.

@NicolasDorier

This comment has been minimized.

Show comment
Hide comment
@NicolasDorier

NicolasDorier Nov 11, 2017

Member

@sipa there is indeed the creation of script that the library need. But the scripts are most likely similar accross all chains.
Good point for the ECDSA. I thought they were not different, but they are: Bitcoin Cash is using another sighash. I agree, having a RPC method gettransactionsignature where you pass the private key be more generic. Will work on another PR for this as well.

Member

NicolasDorier commented Nov 11, 2017

@sipa there is indeed the creation of script that the library need. But the scripts are most likely similar accross all chains.
Good point for the ECDSA. I thought they were not different, but they are: Bitcoin Cash is using another sighash. I agree, having a RPC method gettransactionsignature where you pass the private key be more generic. Will work on another PR for this as well.

@NicolasDorier

This comment has been minimized.

Show comment
Hide comment
@NicolasDorier

NicolasDorier Nov 11, 2017

Member

I addressed the nits, I keep this open while working on an alternative gettransactionsignature which accept a private key as well and returns the signature.

Member

NicolasDorier commented Nov 11, 2017

I addressed the nits, I keep this open while working on an alternative gettransactionsignature which accept a private key as well and returns the signature.

luke-jr added a commit to bitcoinknots/bitcoin that referenced this pull request Nov 11, 2017

@NicolasDorier

This comment has been minimized.

Show comment
Hide comment
@NicolasDorier

NicolasDorier Nov 12, 2017

Member

Alternative signinput: #11666

Member

NicolasDorier commented Nov 12, 2017

Alternative signinput: #11666

@NicolasDorier

This comment has been minimized.

Show comment
Hide comment
@NicolasDorier

NicolasDorier Mar 6, 2018

Member

supersede by #11666

Member

NicolasDorier commented Mar 6, 2018

supersede by #11666

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