Segregated Witness JSON-RPC API changes

[oleiba]

Hi
what are the total changes should we expect to see in the JSON responses from the bitcoin JSON-RPC server as it will support Segregated Witness?
As I see it we should have:
1. For each transaction input, a new field 'witness' which should contain what originally was the scriptSig or the redeem script in the p2wsh case.
2. Fore each transaction, its wtxid - the outcome of the hash of the serialization which includes the transaction witnesses.
3. For the coinbase transaction, an extra field in its input which is the merkle-root of all the witnesses serialization (will it override current 'coinbase' field, or will it be an extra field and if so how will it be called?)
Questions:
- did I get it right?
- Will all the witnesses be part of the block-data (i.e. returned with getblock JSON-API response)? If so, would their length be as the sum of the number of all inputs, or as the number of the block trasnactions (and then each witness will be a concatenation of the transaction's inputs witnesses)?
I'm asking because I'm building a block explorer which heavily relies on bitcoind JSON-RPC response calls.

[achow101]

Hi
what are the total changes should we expect to see in the JSON responses from the bitcoin JSON-RPC server as it will support Segregated Witness?
As I see it we should have:
1. For each transaction input, a new field 'witness' which should contain what originally was the scriptSig or the redeem script in the p2wsh case.

Only if the input spends from a witness output type. If it spends from the currently used types, then it will not have a witness.

2. Fore each transaction, its wtxid - the outcome of the hash of the serialization which includes the transaction witnesses.

Yes.

3. For the coinbase transaction, an extra field in its input which is the merkle-root of all the witnesses serialization (will it override current 'coinbase' field, or will it be an extra field and if so how will it be called?)

The merkle root of all of the transactions with witness serializations goes into an OP_RETURN output in the coinbase.

Questions:
- did I get it right?
- Will all the witnesses be part of the block-data (i.e. returned with getblock JSON-API response)? If so, would their length be as the sum of the number of all inputs, or as the number of the block trasnactions (and then each witness will be a concatenation of the transaction's inputs witnesses)?
I'm asking because I'm building a block explorer which heavily relies on bitcoind JSON-RPC response calls.

No, the witnesses are not part of the block data. Witnesses are part of a transaction's data. If a transaction has a witness, then calling getrawtransaction will have a txinwitness field for each input which has the witness data. However if you get the raw block (just the hex), then you will get the witness data as it will return the block with the transactions in witness serialization. The same will happen with getrawtransaction.

[oleiba]

Thanks.

No, the witnesses are not part of the block data. Witnesses are part of a transaction's data. If a transaction has a witness, then calling getrawtransaction will have a txinwitness field for each input which has the witness data. However if you get the raw block (just the hex), then you will get the witness data as it will return the block with the transactions in witness serialization. The same will happen with getrawtransaction.

What do you mean by "get the raw block"? At least up to version 0.11.2, JSON-RPC API does not include getrawblock to return block hash, but rather just getblock which returns the block's JSON. So where did you mean that I can get the "raw" block (just hex)?
I assume that when you're referring transaction - you mean with or without the "verbose" parameter, where 0 will just give the raw transaction (hex), and 1 will give the transaction JSON. So according to you verbose=0 will give the hex together with the witness data, and verbose=1 will give the transaction data together with txinwitness for each witness-using input, Correct?

Another question in the subject - will full nodes save witnesses data, and will witnesses be relayed?
As I understand it, full nodes will keep saving the signatures in the blockchain DB, only that now they may be saved as witnesses and not as an integral part of the inputs' scriptSig.
About relay - I understand that some clients (e.g. SPV clients) will be able to get transactions without the witness data (using some flag?) to allow thinner bandwidth clients to validate existence of transaction (as they do not care about actually validating their unlocking scripts, only counting on the fact they're confirmed). Did I get it right?

[achow101]

What do you mean by "get the raw block"? At least up to version 0.11.2, JSON-RPC API does not include getrawblock to return block hash, but rather just getblock which returns the block's JSON. So where did you mean that I can get the "raw" block (just hex)?

If you do

Code:

getblock <hash> false

you should get the raw hex of the block.

I assume that when you're referring transaction - you mean with or without the "verbose" parameter, where 0 will just give the raw transaction (hex), and 1 will give the transaction JSON. So according to you verbose=0 will give the hex together with the witness data, and verbose=1 will give the transaction data together with txinwitness for each witness-using input, Correct?

You should still be getting the hex even with verbose=1. The hex of the transaction will be in the witness serialziation if it has a witness. The JSON will also have a txinwitness field for each input that has a witness.

Another question in the subject - will full nodes save witnesses data

Yes

, and will witnesses be relayed?

Only to nodes that signal that they can handle witnesses. If a node has the NODE_WITNESS service bit set and it requested the transaction in a getdata message that had the MSG_WITNESS_TX or MSG_WITNESS_BLOCK inv types.

As I understand it, full nodes will keep saving the signatures in the blockchain DB, only that now they may be saved as witnesses and not as an integral part of the inputs' scriptSig.
About relay - I understand that some clients (e.g. SPV clients) will be able to get transactions without the witness data (using some flag?) to allow thinner bandwidth clients to validate existence of transaction (as they do not care about actually validating their unlocking scripts, only counting on the fact they're confirmed). Did I get it right?

Yes. An SPV wallet can request a transaction without the witness data so that it ends up downloading less data.