Question about SegWit | Bitcointalksearch.org

UngratefulTony

member

Activity: 115

Merit: 10

Quote from: exstasie on April 01, 2016, 01:49:35 PM

Quote from: BitUsher on April 01, 2016, 11:01:36 AM

Quote from: amaclin on March 30, 2016, 11:03:41 AM

Quote from: David Rabahy on March 30, 2016, 10:23:57 AM

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

From what I understand , one of the benefits of the LN payment channel is that it can act as a means to incentivize and cover the costs(potentially even profit)off of running a full node.

Indeed, if payments do not need to be committed to the blockchain, this opens up possibility for non-miners to collect fees.

Now, if we can get the Palestinians to act like the industrial miners... world peace soon to follow.

exstasie

legendary

Activity: 1806

Merit: 1521

Quote from: BitUsher on April 01, 2016, 11:01:36 AM

Quote from: amaclin on March 30, 2016, 11:03:41 AM

Quote from: David Rabahy on March 30, 2016, 10:23:57 AM

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

From what I understand , one of the benefits of the LN payment channel is that it can act as a means to incentivize and cover the costs(potentially even profit)off of running a full node.

Indeed, if payments do not need to be committed to the blockchain, this opens up possibility for non-miners to collect fees.

BitUsher

legendary

Activity: 994

Merit: 1035

Quote from: amaclin on March 30, 2016, 11:03:41 AM

Quote from: David Rabahy on March 30, 2016, 10:23:57 AM

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

From what I understand , one of the benefits of the LN payment channel is that it can act as a means to incentivize and cover the costs(potentially even profit)off of running a full node.

Jet Cash

legendary

Activity: 2870

Merit: 2474

https://JetCash.com

Quote from: achow101 on March 30, 2016, 02:25:56 PM

Quote from: Jet Cash on March 30, 2016, 12:40:20 PM

But not all nodes will update to recognise segwit. If a non segwit node receives the two records that signify a segwith transaction, then won't it accept the payment record, but reject the signature record as an invalid type. It will accept the payment record as valid because the signature will be blank ie. anybody can receive.

Yes, but for a full node that is segwit capable, it WILL receive the witness data. Once segwit updates, running a full node without segwit should not be optional and is less secure since that node cannot verify the signatures of segwit transactions.

I agree, and I believe it is effectively mandatory for miners to run segwit nodes. The beauty of segwit is that is is not a requirement to update a node to be able to use a core wallet. You can't verify the signature of course, but you can still receive a segwit transaction and accept the payment as an "anyone can spend" transaction. The signature has to be completely blank, so it can't be hijacked through the base transaction, and a segwit node will verify the signature record for you. I assume that if one wants to update from an old version of core to a segwit version, one will have to update the latter part of the blockchain to include the signature blocks.

I've only seen the 50% discount on transaction fees mentioned in one place. Is this definately going to be an incentive to update to a core segwit capable node?

achow101

staff

Activity: 3458

Merit: 6793

Just writing some code

Quote from: Jet Cash on March 30, 2016, 12:40:20 PM

But not all nodes will update to recognise segwit. If a non segwit node receives the two records that signify a segwith transaction, then won't it accept the payment record, but reject the signature record as an invalid type. It will accept the payment record as valid because the signature will be blank ie. anybody can receive.

Yes, but for a full node that is segwit capable, it WILL receive the witness data. Once segwit updates, running a full node without segwit should not be optional and is less secure since that node cannot verify the signatures of segwit transactions.

Jet Cash

legendary

Activity: 2870

Merit: 2474

https://JetCash.com

But not all nodes will update to recognise segwit. If a non segwit node receives the two records that signify a segwith transaction, then won't it accept the payment record, but reject the signature record as an invalid type. It will accept the payment record as valid because the signature will be blank ie. anybody can receive.

achow101

staff

Activity: 3458

Merit: 6793

Just writing some code

Quote from: Jet Cash on March 30, 2016, 09:57:45 AM

Quote from: achow101 on March 30, 2016, 06:44:43 AM

Quote from: JorgeStolfi on March 30, 2016, 03:52:06 AM

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.

No. You are incorrect. The signatures are required to validate a block. Full nodes need that data in order to verify the block. If the node announces that it supports segwit, then it will receive the witnesses to validate them. It is not optional for any full node. For reference, a full node is any node which fully verifies all transactions and blocks it receives. This includes pruned nodes and "archiving" nodes.

Jet Cash

legendary

Activity: 2870

Merit: 2474

https://JetCash.com

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.

amaclin

legendary

Activity: 1260

Merit: 1019

Quote from: David Rabahy on March 30, 2016, 10:23:57 AM

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

David Rabahy

hero member

Activity: 709

Merit: 503

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?

Jet Cash

legendary

Activity: 2870

Merit: 2474

https://JetCash.com

Quote from: achow101 on March 30, 2016, 06:44:43 AM

Quote from: JorgeStolfi on March 30, 2016, 03:52:06 AM

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.

achow101

staff

Activity: 3458

Merit: 6793

Just writing some code

Quote from: JorgeStolfi on March 30, 2016, 03:52:06 AM

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.

JorgeStolfi

hero member

Activity: 910

Merit: 1003

Quote from: Jet Cash on March 29, 2016, 12:06:24 AM

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?

Quote

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.

Jet Cash

legendary

Activity: 2870

Merit: 2474

https://JetCash.com

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.

achow101

staff

Activity: 3458

Merit: 6793

Just writing some code

Quote from: JorgeStolfi on March 24, 2016, 03:43:50 PM

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.

Quote from: JorgeStolfi on March 24, 2016, 03:43:50 PM

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.

JorgeStolfi

hero member

Activity: 910

Merit: 1003

Quote from: achow101 on March 24, 2016, 11:07:03 AM

Quote from: Jimmy Wales on March 24, 2016, 11:01:53 AM

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?

gmaxwell

staff

Activity: 4326

Merit: 8951

Quote from: achow101 on March 24, 2016, 10:53:14 AM

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.

fbueller

sr. member

Activity: 412

Merit: 287

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.

achow101

staff

Activity: 3458

Merit: 6793

Just writing some code

Quote from: Jimmy Wales on March 24, 2016, 11:01:53 AM

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.

Jimmy Wales

member

Activity: 144

Merit: 17

Quote from: achow101 on March 24, 2016, 10:53:14 AM

Quote from: Jimmy Wales on March 24, 2016, 10:45:41 AM

Quote from: achow101 on March 24, 2016, 10:23:46 AM

Quote from: Jimmy Wales on March 24, 2016, 10:16:20 AM

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

staff

Activity: 3458

Merit: 6793

Just writing some code

Quote from: Jimmy Wales on March 24, 2016, 10:45:41 AM

Quote from: achow101 on March 24, 2016, 10:23:46 AM

Quote from: Jimmy Wales on March 24, 2016, 10:16:20 AM

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

member

Activity: 144

Merit: 17

Quote from: achow101 on March 24, 2016, 10:23:46 AM

Quote from: Jimmy Wales on March 24, 2016, 10:16:20 AM

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

staff

Activity: 3458

Merit: 6793

Just writing some code

Quote from: Jimmy Wales on March 24, 2016, 10:16:20 AM

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

member

Activity: 144

Merit: 17

Quote from: achow101 on March 24, 2016, 09:32:44 AM

Quote from: JorgeStolfi on March 24, 2016, 09:19:45 AM

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

staff

Activity: 3458

Merit: 6793

Just writing some code

Quote from: JorgeStolfi on March 24, 2016, 09:19:45 AM

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.

jl777

legendary

Activity: 1176

Merit: 1134

Quote from: JorgeStolfi on March 24, 2016, 09:19:45 AM

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

JorgeStolfi

hero member

Activity: 910

Merit: 1003

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?

Topic: Question about SegWit (Read 3166 times)