Clearing the FUD around segwit

achow101

Member
Dec 26, 2015
32
21

cypherdoc

Well-Known Member
Aug 26, 2015
5,257
12,995
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

Member
Dec 26, 2015
32
21
@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).
 
  • Like
Reactions: cypherdoc

Dusty

Active Member
Mar 14, 2016
362
1,172
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 ;-)
 
Last edited:
  • Like
Reactions: Lee Adams

cypherdoc

Well-Known Member
Aug 26, 2015
5,257
12,995
@achow101

does a Hash160 create a 20 byte hash?
 

Dusty

Active Member
Mar 14, 2016
362
1,172
it's called "hash160" because it results in 160 bits, hence 20 bytes.
 

Lee Adams

Member
Dec 23, 2015
89
74
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].
 
  • Like
Reactions: Dusty

Dusty

Active Member
Mar 14, 2016
362
1,172
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.
 
  • Like
Reactions: Lee Adams

cypherdoc

Well-Known Member
Aug 26, 2015
5,257
12,995

cypherdoc

Well-Known Member
Aug 26, 2015
5,257
12,995
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?
 
Last edited:

achow101

Member
Dec 26, 2015
32
21
@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.
 
  • Like
Reactions: freetrader

Lee Adams

Member
Dec 23, 2015
89
74
@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?
 
  • Like
Reactions: freetrader

achow101

Member
Dec 26, 2015
32
21
@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.
 
  • Like
Reactions: freetrader

cypherdoc

Well-Known Member
Aug 26, 2015
5,257
12,995
@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?
 

cypherdoc

Well-Known Member
Aug 26, 2015
5,257
12,995
@achow101

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

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"?
 
Last edited:
  • Like
Reactions: freetrader

cypherdoc

Well-Known Member
Aug 26, 2015
5,257
12,995
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?