addwitnessaddress was primarily a shim to facilitate testing of segwit. It was not really meant to be widely used by users for segwit.
Segwit addresses beginning with a '3' are actually P2SH addresses. This means that the address itself is mapped to a script (after all, it is Pay-to-script-hash), not to a private key. From there the parts of the script itself are mapped to a private key. However dumpprivkey does not go that deep, it only takes things that are mapped directly to a private key, which are P2PKH addresses and public keys. Segwit addresses are not mapped to a private key because they are really just P2SH addresses. So using dumpprivkey with segwit addresses will return an error (as will using any other P2SH address).
To get the private key of the address, you need to take the address that you used addwitnessaddress on originally and call dumpprivkey on that address.
Hello, thank you for your reply. Do you know if there is a plan to start using , as a regular user, the SegWit addresses?
I think that if we need to show to the users that SegWit is the right path to take at least the Bitcoin Core should start implementing it.
I will take a look at GreenBit wallet to see how they implemented the SegWit solution.
What I do not understand is why P2SH address does not come from a private key, arent multi-signatures addresses generated from private keys? The more I know about BTC the more I get to think that I know nothing.
So what information is encoded in a P2SH address? A specific unspent Bitcoin can actually have a whole range of different spending conditions attached to it, the most common being a typical P2PKH which just requires the recipient to provide a signature matching the public key hash. The Bitcoin core developers realized that people were looking at the capabilities of Bitcoin's Script language and seeing a whole array of possibilities about what spending conditions you could attach to a Bitcoin output, to create much more elaborate transactions than just P2PKH transactions. The core developers decided that instead of letting senders put in long scripts into their scriptPubKey (where spending conditions usually go), they would let each sender put in a hash of their spending conditions instead. These spending conditions are known as the redeem script, and a P2SH funding transaction simply contains a hash of this redeem script in the scriptPubKey of the funding transaction.The redeem script itself is only revealed, checked against the redeem script hash, and evaluated during the spending transaction.
Source (the whole piece if very useful / I'd recommend reading):
http://www.soroushjp.com/2014/12/20/bitcoin-multisig-the-hard-way-understanding-raw-multisignature-bitcoin-transactions/. Segwit in it's current form is encapsulated in P2SH.
Again disclaimer: I have not used any SW stuff with Bitcoin Core yet, thus I'm just basing this on my knowledge of P2SH and SW, which should be correct (or mostly correct).
Thank for the URL Lauda. I will read it, hope it is not so crypto-technical
