Clearing the FUD around segwit

[achow101]

Ah! so BIP142 is not valid anymore?

For all intents and purposes, yes (it is actually deferred which means it won't be considered for anything for a while).

Thanks for the info: can you please point me to the correct BIP?

What is actually going to happen with the addresses is described here: https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#Witness_program_nested_in_BIP16_P2SH

 

[cypherdoc]

where the <32 byte hash> is the SHA256 of the script. This is something you cannot extract from a p2sh address (unless you find a preimage attack on ripemd160),[/code]

can you explain this further?

 

[achow101]

@cypherdoc The redeemscript of a normal p2sh address (and the pubkey of a p2pkh output) is hashed with SHA256 and then RipeMD160. With segwit, they are just going to do a SHA256 of the redeemscript which will always be 32 bytes (because that is how sha256 works).

 

[Lee Adams]

Since outputs are defined by receivers

Can I get an ELI5 on this one. Sorry it's been a long day and I've had a bit of whiskey.

 

[Dusty]

Can I get an ELI5 on this one. Sorry it's been a long day and I've had a bit of whiskey.

If I have to send you a bitcoin I ask you an address of yours, so you, the receiver, are deciding which address to use, not me, the sender

Feel free to ask details if this does not clear the whiskey problem ;-)

 

[cypherdoc]

@achow101

does a Hash160 create a 20 byte hash?

 

[Dusty]

it's called "hash160" because it results in 160 bits, hence 20 bytes.

 

[Lee Adams]

if my wallet uses segwit addresses by default

There is no such thing as a segwit address, this was BIP 142 but it has been deferred.
[doublepost=1459979245][/doublepost]@achow101 Can you answer this?

How does this tally with:

If a non-upgraded user does not recognise the transaction is for them (i.e. their bitcoin), how can they spend them? Surely this makes this myth true in this, albeit not all, circumstance.

[doublepost=1459979513][/doublepost]

Feel free to ask details if this does not clears the whyskey problem ;-)

Sorry that was me, not reading the rest of the thread where this was explained.

The danger with segwit is that this is NOT true (although I stand to be corrected again). If I send you a segwit transaction and you have not upgraded, then you cannot spend it until you upgrade. This is pretty much different (again, please correct me if I'm wrong here) from all previous soft forks. [Insert Mike Hearn soft fork quote here].

 

[Dusty]

The danger with segwit is that this is NOT true (although I stand to be corrected again). If I send you a segwit transaction and you have not upgraded, then you cannot spend it until you upgrade. This is pretty much different (again, please correct me if I'm wrong here) from all previous soft forks. [Insert Mike Hearn soft fork quote here].

Yes, I think you are completely right in this aspect: a segwit client can take your P2PKH 1XX address and create a segwit transaction toward it.
Your old non-segwit wallet will not "see" the transaction as his, and hence unable to spend it.

 

[cypherdoc]

it's called "hash160" because it results in 160 bits, hence 20 bytes.

 

[cypherdoc]

Yes, I think you are completely right in this aspect: a segwit client can take your P2PKH 1XX address and create a segwit transaction toward it.
Your old non-segwit wallet will not "see" the transaction as his, and hence unable to spend it.

Achow101

Can you verify this? How would such a tx be crafted?

 

[achow101]

@cypherdoc yes, that is true. It would have to be done by hand, as in literally writing out the hex code for the transaction as no wallet software should ever do that.

It can only be done with p2pkh addresses because sending to p2sh addresses will result in an unspendable output. It can be done by getting the hash160 of an address, prepending OP_0, and setting that as the output script of a transaction. In theory it can be done, but with decent wallet software, it should not be a problem.

 

[Lee Adams]

@achow101

Can you explain how a segwit client would normally send transactions. Would it only normally send to P2SH address? Can non-upgraded clients have P2SH addresses? If so how does a seg wit client know not to send seg wit transactions to it?

 

[achow101]

@Lee Adams

I will explain this from how Bitcoin Core will do it.

By default, if you want to send to a p2pkh address (1xxxx) it will create the output as a p2pkh output, same as before. Likewise, if you want to send to a p2sh address (3xxxx) it will create the output as a p2sh output, same as before. To take advantage of segwit, the wallet will create p2sh address which have the witness outputs nested in them. The redeemscript of those p2sh address will be the witness output. Because it is a p2sh address, any client will be able to send to it, regardless of upgrade status because it is still sent to using a p2sh output. This allows for upgraded clients to use the benefits of segwit when spending from those outputs while maintaining compatibility with non-upgraded clients.

The segwit outputs will not be used at all. As of now, there is no way to use Bitcoin Core to generate a transaction with any of the segwit output types. However, it of course does support validating them and spending from them if anyone were to create transactions with segwit outputs by hand or with other software. It will still recognize if a segwit output is meant for it.

 

[Lee Adams]

@achow101

Sorry you lost me a bit...


... If I run a non-upgraded node and publish my P2SH address, could I potentially get a segwit output that I cannot spend without upgrading?

 

[achow101]

@Lee Adams no, you cannot get a segwit output at all.

 

[cypherdoc]

@achow101

no, you cannot get a segwit output at all.

and this is b/c the non upgraded receiving wallet only has the capability of supply and constructing a 20 byte redeem script hash as opposed to a 32 byte redeem script hash for a SW output?

 

[achow101]

@cypherdoc yes. You can only get the 20 byte ripemd160 hash from an address and not the 32 byte sha256 hash.

 

[cypherdoc]

@achow101

lol, do you ever get the sense when you ask a question that you barely understand what you're asking?

anyways, glad i got the question right, it seems. you've been an extraordinary help in understanding all this. it IS extraordinarily complex and i continue to have great reservations about how this is all going to work.

btw, why are the LN folks claiming that LN will be up and running by summer when Rusty hasn't even architected his LN simulations yet to SW?:

https://medium.com/@rusty_lightning/rearchitecting-for-segregated-witness-d67a54740e82#.cv9s16uns

also, what is Rusty referring to when he says "commitment tx's"? are those "anchoring tx's"? what is the term for the "refund tx"?

 

[cypherdoc]

from bip141:

Witness program nested in BIP16 P2SH

witness: 0 <signature1> <1 <pubkey1> <pubkey2> 2 CHECKMULTISIG>
scriptSig: <0 <32-byte-hash>>
(0x0020{32-byte-hash})
scriptPubKey: HASH160 <20-byte-hash> EQUAL
(0xA914{20-byte-hash}87)

what are the bolded parts of this example? are they actual parts of the scriptSig & scriptPubKey or are they just an explanation of what's above it?