Question about SegWit

[JorgeStolfi]

Suppose Alice is running "new" (SegWit-capable) client software, and sends some bitcoin to Bob, who is running an "old" (SegWit-oblivious) client, with a SegWIt transaction T1.

I understand that Bob would still be able to spend that bitcoin with a non-SegWit transaction T2, by providing the proper signature; is that correct?

But would Bob know what signature he must provide, without Alice telling him?  Or will Bob's client believe that the output of T1 is "anyone can spend", and assume that T2 does not require a signature?

[jl777]

Suppose Alice is running "new" (SegWit-capable) client software, and sends some bitcoin to Bob, who is running an "old" (SegWit-oblivious) client, with a SegWIt transaction T1.

I understand that Bob would still be able to spend that bitcoin with a non-SegWit transaction T2, by providing the proper signature; is that correct?

But would Bob know what signature he must provide, without Alice telling him?  Or will Bob's client believe that the output of T1 is "anyone can spend", and assume that T2 does not require a signature?

my understanding is that bob would have to send alice a segwit p2sh address, which he wouldnt have without running a segwit client. At least that is the assumption.

if bob creates a segwit p2sh address using his privkey, using some external mechanism, then his wallet wont be able to see it as it is a p2sh address it doesnt know about. and presumably if he tries to spend it by signing it, then I think if he signs it properly it will get confirmed by segwit miners. but bob wont be able to directly verify it, so would need to rely on third parties

[achow101]

Suppose Alice is running "new" (SegWit-capable) client software, and sends some bitcoin to Bob, who is running an "old" (SegWit-oblivious) client, with a SegWIt transaction T1.

I understand that Bob would still be able to spend that bitcoin with a non-SegWit transaction T2, by providing the proper signature; is that correct?

But would Bob know what signature he must provide, without Alice telling him?  Or will Bob's client believe that the output of T1 is "anyone can spend", and assume that T2 does not require a signature?

It depends on how Alice sent the Bitcoin.

If Alice created a P2PKH or P2SH output (currently used) which Bob could spend from, then he would spend from that output normally as he does now. In this case, it doesn't matter if the inputs required segwit or not, they will be considered valid by Bob but his wallet won't even tell him about the transaction until it has confirmations.

If Alice sent him a P2WPKH output (new segwit output), AFAIK, Bob wouldn't even know about those transactions and that those outputs are even meant for him. If he did know about said outputs, he would probably spend them as anyonecanspend outputs and thus not require a signature. However the segwit nodes would reject such transactions and it would never be confirmed or even propagate very far.

If Alice sent him a P2WSH, P2WPKH-P2sh or P2WSH-P2SH (new outputs. The latter two are nested in p2sh outputs), Bob absolutely would not know that those outputs are meant for him.

[Jimmy Wales]

Suppose Alice is running "new" (SegWit-capable) client software, and sends some bitcoin to Bob, who is running an "old" (SegWit-oblivious) client, with a SegWIt transaction T1.

I understand that Bob would still be able to spend that bitcoin with a non-SegWit transaction T2, by providing the proper signature; is that correct?

But would Bob know what signature he must provide, without Alice telling him?  Or will Bob's client believe that the output of T1 is "anyone can spend", and assume that T2 does not require a signature?

It depends on how Alice sent the Bitcoin.

If Alice created a P2PKH or P2SH output (currently used) which Bob could spend from, then he would spend from that output normally as he does now. In this case, it doesn't matter if the inputs required segwit or not, they will be considered valid by Bob but his wallet won't even tell him about the transaction until it has confirmations.

If Alice sent him a P2WPKH output (new segwit output), AFAIK, Bob wouldn't even know about those transactions and that those outputs are even meant for him. If he did know about said outputs, he would probably spend them as anyonecanspend outputs and thus not require a signature. However the segwit nodes would reject such transactions and it would never be confirmed or even propagate very far.

If Alice sent him a P2WSH, P2WPKH-P2sh or P2WSH-P2SH (new outputs. The latter two are nested in p2sh outputs), Bob absolutely would not know that those outputs are meant for him.

In short, is it possible that Bob receives a Tx created by Alice, which is included in a block (i.e. a confirmed Tx) and gives her a good/service in return, only to find out later that he can not spend the Tx outputs?

[achow101]

In short, is it possible that Bob receives a Tx created by Alice, which is included in a block (i.e. a confirmed Tx) and gives her a good/service in return, only to find out later that he can not spend the Tx outputs?

Probably not. His wallet is most likely unable to recognize that a P2WPKH output is meant for him because it does not have any OP codes to indicate what that data is and how to spend from such an output.

[Jimmy Wales]

In short, is it possible that Bob receives a Tx created by Alice, which is included in a block (i.e. a confirmed Tx) and gives her a good/service in return, only to find out later that he can not spend the Tx outputs?

Probably not. His wallet is most likely unable to recognize that a P2WPKH output is meant for him because it does not have any OP codes to indicate what that data is and how to spend from such an output.

So, is the counter situation possible? Alice sends the Tx, but as Bob's wallet did not recognize it, she did not get the good/service for which she paid. In effect, Alice lost her coins. Is it possible?

[achow101]

In short, is it possible that Bob receives a Tx created by Alice, which is included in a block (i.e. a confirmed Tx) and gives her a good/service in return, only to find out later that he can not spend the Tx outputs?

Probably not. His wallet is most likely unable to recognize that a P2WPKH output is meant for him because it does not have any OP codes to indicate what that data is and how to spend from such an output.

So, is the counter situation possible? Alice sends the Tx, but as Bob's wallet did not recognize it, she did not get the good/service for which she paid. In effect, Alice lost her coins. Is it possible?

Yes but unlikely. This depends on the implementation. The current implementation is that entering an address will result in creating a normal P2PKH output which Bob could spend from. If there is an implementation that a P2WPKH output is created when an address is entered, then it is possible that Alice would, in effect, lose her coins if she used such an implementation.

[Jimmy Wales]

In short, is it possible that Bob receives a Tx created by Alice, which is included in a block (i.e. a confirmed Tx) and gives her a good/service in return, only to find out later that he can not spend the Tx outputs?

Probably not. His wallet is most likely unable to recognize that a P2WPKH output is meant for him because it does not have any OP codes to indicate what that data is and how to spend from such an output.

So, is the counter situation possible? Alice sends the Tx, but as Bob's wallet did not recognize it, she did not get the good/service for which she paid. In effect, Alice lost her coins. Is it possible?

Yes but unlikely. This depends on the implementation. The current implementation is that entering an address will result in creating a normal P2PKH output which Bob could spend from. If there is an implementation that a P2WPKH output is created when an address is entered, then it is possible that Alice would, in effect, lose her coins if she used such an implementation.

But, how Alice's wallet would know whether Bob's wallet is SegWit compatible or not. Because, as I understand, depending on this Alice's wallet should create P2WPKH output or P2PKH output respectively.

[achow101]

But, how Alice's wallet would know whether Bob's wallet is SegWit compatible or not. Because, as I understand, depending on this Alice's wallet should create P2WPKH output or P2PKH output respectively.

Well if Alice somehow had a direct connection to Bob's wallet, her wallet would know because of the service bit indicating segwit. Otherwise, she would only know if Bob told her. However, the reference implementation creates by default a P2PKH output when an address is entered. This is to keep the backwards compatibility. I am assuming that there will be checkbox to allow the user to indicate if he wants to send it as a segwit output but that is not the current default.

[fbueller]

I'm not sure this would ever be a problem. Look at the payment protocol; it basically tells a client what output scripts to pay to. (Addresses work in the same way, except the script-type is inferred from the version byte)

From Bobs perspective, there's only one output script he can accept, and he won't be convinced to accept anything else. Just like the amount isn't made up out of the air, neither is the script used to pay somebody. Bob won't hand over the goods until he gets paid.

Suppose the soft-fork activates on the rest of the network, and Bob is still using an old version of bitcoin core. He never created a seg-wit address before, so he certainly won't be looking for payment on one!

Also - as far as Alices ability to _guess_ output scripts (take the hash160 from his P2KH address, and craft a P2WPKH script) Bob would still regard this as non payment. This is because 'output scripts' are strictly the recipients business. How Bob chooses to protect his coins is his business - whether it's by multisig, or some other advanced script type - but it's something Alice cannot really question.

[gmaxwell]

Yes but unlikely. This depends on the implementation. The current implementation is that entering an address will result in creating a normal P2PKH output which Bob could spend from. If there is an implementation that a P2WPKH output is created when an address is entered, then it is possible that Alice would, in effect, lose her coins if she used such an implementation.

What you're saying is equivalent to "in theory there could exist some totally busted software that just make up random crap when alice punched in an address, thereby burning the coins"-- this is true, but it's unrelated to segwit.

The recipients address specifies the scriptPubkey that they must be paid-to in order to be paid.  If you don't pay to what they've specified, you haven't paid a party.  In the OP's example, Bob would have provided an ordinary address-- the same as he provides today, perhaps-- and the payment would work like normal.

How the txin scripts work and txout scripts work are completely orthogonal.  Someone can spend segwit coins and the receiver doesn't care, it doesn't change their operation; beyond the fact that their older client will see the payment as a non-standard transaction so their non-upgraded wallet will not display it until it confirms.

[JorgeStolfi]

But, how Alice's wallet would know whether Bob's wallet is SegWit compatible or not. Because, as I understand, depending on this Alice's wallet should create P2WPKH output or P2PKH output respectively.

Well if Alice somehow had a direct connection to Bob's wallet, her wallet would know because of the service bit indicating segwit. Otherwise, she would only know if Bob told her. However, the reference implementation creates by default a P2PKH output when an address is entered. This is to keep the backwards compatibility. I am assuming that there will be checkbox to allow the user to indicate if he wants to send it as a segwit output but that is not the current default.

OK, so now consider the reverse situation: Bob is running a new client, and Alice is running an old one.  If Bob wants Alice to send him coins, what should he tell her: "pay to this address" or "pay to this segwit script", or "pay to either"?

Or: suppose Alice wants to make a payment that can be collected by either Bob or Carol.  Bob is running an old client, and Carol a new one.  Bob tells Alice "pay me to this address",  Carol says "pay me to this segwit script".  What should Alice do?

[achow101]

OK, so now consider the reverse situation: Bob is running a new client, and Alice is running an old one.  If Bob wants Alice to send him coins, what should he tell her: "pay to this address" or "pay to this segwit script", or "pay to either"?

He could give her a P2PKH address and he would receive the coins as he does now. Or he can give her a segwit script embedded in a P2SH address and he would receive the coins as he does now. He could tell her to make the output a specific script. It doesn't matter as an upgraded node is backwards compatible and can process the old and new output types.

Or: suppose Alice wants to make a payment that can be collected by either Bob or Carol.  Bob is running an old client, and Carol a new one.  Bob tells Alice "pay me to this address",  Carol says "pay me to this segwit script".  What should Alice do?

Er, is that possible now? Both parties receiving the payment would need to agree to the output type since they can both spend from the outputs. The obvious one is to simply pay to the address because that is one that is compatible with both clients.

[Jet Cash]

As I understand it, Alice creates a "pay anybody record", and attaches a signature that says pay Bob. All miners will need to be on SegWit, so they will only allow Bob to claim the coins. The "Pay anyone" record will be part of Bob's blockchain, and will validate any future payments. Because he is running old software, he won't recognise the signature record,but that doesn't matter, as his payment has a valid source of funds. If he wants to track the payment in the future, he will have to use an archive node ( a node that keeps the signatures, and validates segwit traansactions. Miners will not include the signature record in the mined block, so the block can stay below 1Mb, this helps smaller miners who may not be able to compete with the high price installations of the large miners. The biggest threat to Bitcoin is centralisation, and a 2MB blocksize may force out smaller miners, and leave the network vulnerable to fee exploitation by a small group of miners. imho.

[JorgeStolfi]

Miners will not include the signature record in the mined block, so the block can stay below 1Mb, this helps smaller miners who may not be able to compete with the high price installations of the large miners.

This is not correct, right?  Miners (and relay nodes running new software) will have to include the signatures in the extension part of the block and send the whole block out to other miners (and to relay nodes running new software).  The extension record can be omitted only when a miner or relay node sends a block to a simple client.  Right?

The biggest threat to Bitcoin is centralisation, and a 2MB blocksize may force out smaller miners, and leave the network vulnerable to fee exploitation by a small group of miners. imho.

Centralization has happened because of several factors that favor larger miners over smaller ones -- including economies of scale, access to locations with cheaper power and natural cooling, better prices for bulk purchases, in-house hardware and software development, and better support from local governments.  If it is true that larger blocks give an advantage to bigger miners, they could get those same advantages by artificially delaying the transmission of blocks to rivals.

[achow101]

This is not correct, right?  Miners (and relay nodes running new software) will have to include the signatures in the extension part of the block and send the whole block out to other miners (and to relay nodes running new software).  The extension record can be omitted only when a miner or relay node sends a block to a simple client.  Right?

Yes, you are mostly correct. The witness data is sent to nodes that have the proper service bit set. When segwit activates, nearly all of the miners will have this bit set so they will be receiving all of the witness data. The data will be omitted if the node doesn't have that service bit.

[Jet Cash]

This is not correct, right?  Miners (and relay nodes running new software) will have to include the signatures in the extension part of the block and send the whole block out to other miners (and to relay nodes running new software).  The extension record can be omitted only when a miner or relay node sends a block to a simple client.  Right?

Yes, you are mostly correct. The witness data is sent to nodes that have the proper service bit set. When segwit activates, nearly all of the miners will have this bit set so they will be receiving all of the witness data. The data will be omitted if the node doesn't have that service bit.

I understood that the miners would have to validate the signature "extension" to guard against attempts to hijack the payment. Because of this, all miners would have to support segwit. However, they don't include the signature data in the mined block ( if they did it would be even larger than current sizes). They don't need to re-transmit the signature data, and probably won't as the extra processing time could lead to their block being orphaned. The signature data is validated by archive nodes, and other miners of course, and if it is invalid, then the block will not be accepted. I think it is optional if a wallet holder wants to run a pruned node, a full node, or a full node with archiving.

[David Rabahy]

I run a full node (it is my pleasure to provide this service to the community; besides which it is apparently to my advantage to participate in order to help keep Bitcoin viable to help keep my Bitcoins valuable).

Which variant will be best for me to run?  Pruned seems less helpful.  Full seems good but full with archive seems best.

Should I ever hope to be paid for being a full node with archive?

[amaclin]

Should I ever hope to be paid for being a full node with archive?

no.
there is no person in this universe who has reasons pay you just for holding a node

[Jet Cash]

I hope to run an archiving node ( I hope that is the correct term). mainly because I believe that segwit will provide some interesting support for escrow services.

btw. don't forget that I am a recent Bitcoin recruit, so I hope my comments are correct. I think the concept is brilliant as it allows people to run previous versions of core without compromising their wallets. I think I read that there is a 50% fee refund if you are running a segwit node.