odedleiba

Thanks!

Thanks.
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?

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.