@cypherdoc I think it is basically just semantics. The block size limit is still there, it is 1 Mb. Then they have another thing called block cost which is 4 Mb. That is the maximum amount of data that a block could contain with the witnesses included.
Clearing the FUD around segwit
- Thread starter achow101
- Start date
Can you also explain this comment from Lukey?:
Old wallets cannot receive segwit UTXOs, but they can receive from new wallets that have them.
That post means that old wallets cannot receive a segwit output. Since they are not segwit enabled, they do not know what that output type really means and they do not recognize that such an output could be meant for them. However, a new wallet which spends from segwit outputs can still create a nonsegwit output which an old wallet can receive and spend from.
An old wallet can also create segwit outputs, specifically the output where the segwit part is nested in a p2sh output. Because it is p2sh, it is indistinguishable from a normal multisig p2sh output and a segwit output until that output is spent.
An old wallet can also create segwit outputs, specifically the output where the segwit part is nested in a p2sh output. Because it is p2sh, it is indistinguishable from a normal multisig p2sh output and a segwit output until that output is spent.
@cypherdoc It does actually receive it but recognizes it as an anyonecanspend. However, it does not recognize that the output belongs to it, so it would not show up as an output that it could spend.
@achow101
Your explanations are highly confusing because they are not being as exact or complete as necessary. For example, in this situation we are talking about, this ANYONECANSPEND TX to the old wallet has been received, won't be initially seen by the gui client, but will be seen and received approximately10 min later after being mined into a block, right ?
Your explanations are highly confusing because they are not being as exact or complete as necessary. For example, in this situation we are talking about, this ANYONECANSPEND TX to the old wallet has been received, won't be initially seen by the gui client, but will be seen and received approximately10 min later after being mined into a block, right ?
Probably for the same reason he thinks the Pope is the anti-christ or that the Sun revolves around the Earth. This is the convoluted answer he gave me!
How I thought it worked was that the bitcoin address of the non-upgraded wallet was included in the anyonecanspend transaction, but because it is 'anyone can spend' then it is ignored, as suspicious, by the old client and will not show in the balance. However once the transaction is confirmed in a block, it will show up as a balance and can be spent. So ANYONECANSPEND really means AnyoneCanSpendUntilItIsConfirmedInaBlockAndThenOnlyPKHcanSpend.
However this is not what Segwit-FUD-Clearup now says. Now I am confused again.
@achow101
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.
@Lee Adams
yeah, the optics on this thing keep getting mucked up everytime i think i got it down. if anything, sipa's response to testicool confused things as he made it seem that outputs could seamlessly move back and forth btwn SW outputs and regular addresses.
yeah, the optics on this thing keep getting mucked up everytime i think i got it down. if anything, sipa's response to testicool confused things as he made it seem that outputs could seamlessly move back and forth btwn SW outputs and regular addresses.
@cypherdoc Sorry about the confusion, I was tired and not really in a good place for a coherent response.
Whether the transaction shows up in the GUI is up to the implementation, however I will answer this in the context of Bitcoin Core.
When a non-segwit wallet receives a transaction with a segwit output, it does not recognize that the segwit output belongs to it. To old nodes, the segwit output is a nonstandard output because it is of the form
This will not be recognized as belonging to the wallet even if the <20 byte hash> is a hash160 that belongs to the wallet.
Non-segwit wallets will only recognize p2pkh, p2sh, p2pk, and raw multisig as outputs that belong to it.
To send Bitcoin to non-segwit wallets is really part of the implementation of segwit. Since p2pkh outputs are universally recognized as a normal address and p2sh outputs as a multisig address, segwit will not be trying to change that. If you are sending to an address, then it should always be sent as a p2pkh and p2sh output regardless. When you enter a normal Bitcoin address, the wallet should (and will in the case of Bitcoin Core) always create a p2pkh output and never a segwit output. With p2sh addresses, it will always create a p2sh output because it isn't possible to know the 32 byte hash required for a segwit script hash output.
There isn't any incentive for the sender to be creating segwit outputs anyways. There is actually a negative incentive for doing so because the receiver may not have a segwit enabled wallet. It can cause disputes and it's a total dick move. No wallet developer should write their wallet to create segwit outputs by default, only be able to handle them if people do decide to create those outputs by hand.
The part that makes sending between segwit wallets and non-segwit wallets is the use of segwit outputs nested inside of a p2sh address. Because it is p2sh, the sender sends it using the standard p2sh format but the receiver can still take advantage of segwit's benefits. And spending from a segwit output to a non-segwit output is fine too because inputs and outputs in a transaction are not linked together.
Whether the transaction shows up in the GUI is up to the implementation, however I will answer this in the context of Bitcoin Core.
When a non-segwit wallet receives a transaction with a segwit output, it does not recognize that the segwit output belongs to it. To old nodes, the segwit output is a nonstandard output because it is of the form
Code:
OP_0 <20 byte hash>Non-segwit wallets will only recognize p2pkh, p2sh, p2pk, and raw multisig as outputs that belong to it.
To send Bitcoin to non-segwit wallets is really part of the implementation of segwit. Since p2pkh outputs are universally recognized as a normal address and p2sh outputs as a multisig address, segwit will not be trying to change that. If you are sending to an address, then it should always be sent as a p2pkh and p2sh output regardless. When you enter a normal Bitcoin address, the wallet should (and will in the case of Bitcoin Core) always create a p2pkh output and never a segwit output. With p2sh addresses, it will always create a p2sh output because it isn't possible to know the 32 byte hash required for a segwit script hash output.
There isn't any incentive for the sender to be creating segwit outputs anyways. There is actually a negative incentive for doing so because the receiver may not have a segwit enabled wallet. It can cause disputes and it's a total dick move. No wallet developer should write their wallet to create segwit outputs by default, only be able to handle them if people do decide to create those outputs by hand.
The part that makes sending between segwit wallets and non-segwit wallets is the use of segwit outputs nested inside of a p2sh address. Because it is p2sh, the sender sends it using the standard p2sh format but the receiver can still take advantage of segwit's benefits. And spending from a segwit output to a non-segwit output is fine too because inputs and outputs in a transaction are not linked together.
is there value to this?:
The script language is a Forth-like stack-based language deliberately designed to be stateless and not Turing complete. Statelessness ensures that once a transaction is added to the block chain, there is no condition which renders it permanently unspendable. Turing-incompleteness (specifically, a lack of loops or gotos) makes the script language less flexible and more predictable, greatly simplifying the security model.
The script language is a Forth-like stack-based language deliberately designed to be stateless and not Turing complete. Statelessness ensures that once a transaction is added to the block chain, there is no condition which renders it permanently unspendable. Turing-incompleteness (specifically, a lack of loops or gotos) makes the script language less flexible and more predictable, greatly simplifying the security model.
ah, so it is possible for a new SW wallet to create standard p2pkh outputs to a 1* address? so it creates a standard scriptpubkey?
[doublepost=1459958244][/doublepost]
i'm very surprised to hear you advocate this. seems that would be very detrimental to overall SW adoption and will cause huge delays in the supposed blockchain scaling of SW.
just so we don't forget. Mike Hearn:
P2SH works because the Bitcoin protocol was changed to include a new rule: when you see an output script of the above form, don’t actually treat it as a script at all, instead apply special processing to it: the password is in fact the “real” script so run that. So P2SH is not insecure, don’t worry. But why use this roundabout and strange approach?
You guessed it — soft forking is to blame. This construct is designed to always be considered valid by old nodes that don’t understand the P2SH rule. If presented with a transaction that spends this coin under the classical Bitcoin rules but which doesn’t satisfy the new P2SH rule, they will fail to audit it correctly and calculate an incorrect ledger.
But preventing that from happening is the whole reason you’re running a full node in the first place! Oops!
https://medium.com/@octskyward/on-consensus-and-forks-c6a050c792e7#.szqn97ku1
P2SH works because the Bitcoin protocol was changed to include a new rule: when you see an output script of the above form, don’t actually treat it as a script at all, instead apply special processing to it: the password is in fact the “real” script so run that. So P2SH is not insecure, don’t worry. But why use this roundabout and strange approach?
You guessed it — soft forking is to blame. This construct is designed to always be considered valid by old nodes that don’t understand the P2SH rule. If presented with a transaction that spends this coin under the classical Bitcoin rules but which doesn’t satisfy the new P2SH rule, they will fail to audit it correctly and calculate an incorrect ledger.
But preventing that from happening is the whole reason you’re running a full node in the first place! Oops!
https://medium.com/@octskyward/on-consensus-and-forks-c6a050c792e7#.szqn97ku1
Dusty
Active Member
- Mar 14, 2016
- 362
- 1,172
Since outputs are defined by receivers, it's them that decide the format of the outputs, so this should not be a problem.
I suppose it should be possible to transform a P2PKH into a P2WPKH, but you should not be able to convert a P2SH to a P2WSH (please correct me if I'm wrong), but a wallet would be very, very stupid to convert addresses.
The problem could be in reverse though: if my wallet uses segwit addresses by default and I give one of them to a non-segwit enabled wallet he would not be able to send me funds (he would reject the address as invalid).
Yes, the value is when a fork happens: a miner can grab all the (valid) transactions of the orphaned blocks and put them in the new chain.
@Dusty
you sure about that? it's the senders that define the ScriptPubKey, unless of course, you mean the receiver defines the type of address to which the sender sends.
this should be possible given what we've been told so far if you're using an upgraded client.
that segwit address would be a 3*. your old wallet should be able to construct a p2sh output to that segwit address i think, but with p2sh scripting, not segwit scripting.
not sure what you mean.
Dusty
Active Member
- Mar 14, 2016
- 362
- 1,172
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.
Segwit addresses start with P or 7, 3 is the prefix for the usual P2SH address.
Take this scenario:
- a party A broadcasts tx1 and that transaction goes into Block B1: since that tx went in a block, it gets dropped from the mempool.
- a new block B2 arrives and it orphans B1. Let's suppose B2 does not contain tx1: since tx1 was dropped from all the mempools of the network, if the original party A does not rebroadcast it, it would never put on the new chain and hence his transaction lost forever
- but for the property we are discussing, a knowledgeable miner can extract all the valid (not double spent) transactions from orphaned block B1 and put them in a new block that follows the new chain after B2 without requiring action from the original submitters (and hence even A, the one that created tx1)
No. Segwit is no longer going to have a separate address format for the segwit outputs (at least not for now). Instead, segwit addresses are going to actually be p2sh addresses with the segwit output script as the redeemscript of the p2sh address. This means that a non-segwit enabled wallet can send to that address as it normally would but the receiver would be able to take advantage of segwit's features.
BIP 142 which specified a new address format was deferred.
No, @Dusty is right. A p2wsh output iscypherdoc said:
Code:
OP_0 <32 byte hash>Dusty
Active Member
- Mar 14, 2016
- 362
- 1,172
Ah! so BIP142 is not valid anymore?
Thanks for the info: can you please point me to the correct BIP?
@cypherdoc : my reply to you about P and 7 prefix is hence not valid anymore.
