Clearing the FUD around segwit

[Dusty]

The last bolded part is the usual P2SH script that defines a 20-byte hash for a certain script.
That script is a segwit address of the form OP_0 <32-byte-hash>. This script is a P2WSH witness program, and in turn that's like a P2SH address, but with 32 bytes hash instead of 20.
So you have two nested hash, and to calc them you need the witness.

The scriptPubKey you find in the transaction is the latest one:
(0xA914{20-byte-hash}87)
the other is an explaination to understand how it's built

 

[achow101]

@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.

I agree, it is fairly complex, although once you get your mind wrapped around the idea, it does seem kinda simple (at least for me).

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?:

Err, is Rusty on the team doing LN? Who are the LN folks? Last I checked, a lot of different people are implementing LN.

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"?

From what I understand of LN, the anchor txs are basically the start of the channel and funds the channel. The commitment txs are the transactions in the channel, and the close closes the channel.

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?

Those are just explanations of what is above. They show what the hex of that will look like.

 

[cypherdoc]

@achow101

now that you've had some time to look at the 75% discount that SWSF requires, what are your thoughts on the fairness of it and how it was determined?

 

[achow101]

@cypherdoc I think the discount does make sense and I see where it is coming from although the explanation that people get for having the discount is kinda convoluted.

It stems from needing to keep the data transferred to less than 4 Mb and that it makes implementation simpler. The idea is that the maxblocksize does not need to change and no other limit constants need to be added. The block size calculation does the discount for the witness data and that will always come out with a maximum data transferred to be 4 Mb. Instead of checking two limits and some more code to keep the data within two limits, the discount only requires one limit with a change in the calculation.

 

[cypherdoc]

of course i get all of that as you've read my post on SW math.

the problem i see is that the 4MB was centrally planned by pwuille & gmax as they realized 4MB is perfectly within the capability of the network to transmit blocks despite what they've said for years now. it only makes sense if you feel SW has to be done as a SF to keep the 1MB cap and that a simple HF to 4MB blocksizes is a more dangerous way to go. therein lies the disagreement. personally, a+b<=4MB would be interesting to me as well as a straight blocksize increase to 4MB.

 

[achow101]

@cypherdoc Your point? The 2 MB hard fork was centrally planned by Gavin, Garzik and Toomin.

Have they actually been saying that the network could not handle 4 Mb for years now? Also, the network may not have been able to handle 4 Mb a couple of years ago. Technology moves fast in a few years.

The thing with a+b<-4Mb is that a may not be less than 1 Mb and thus break compatibility with previous clients.

 

[Dusty]

@achow101
now that you've had some time to look at the 75% discount that SWSF requires, what are your thoughts on the fairness of it and how it was determined?

I now understand while I was having problems following the reasoning: I was thinking about the fee discount on the witness data, while you were talking about another discount I didn't know about: the one about the size of the witness?
Can someone please explain that to me? I have several objections but I would like to be sure to have a correct understanding.
Thanks

 

[cypherdoc]

@cypherdoc Your point? The 2 MB hard fork was centrally planned by Gavin, Garzik and Toomin.

no, they are responding to what they feel the community wants which is a blocksize increase of whatever size. altho i admit, this may be more debatable now given the inaction of the last few months and how you interpret that.

Have they actually been saying that the network could not handle 4 Mb for years now? Also, the network may not have been able to handle 4 Mb a couple of years ago. Technology moves fast in a few years.

The thing with a+b<-4Mb is that a may not be less than 1 Mb and thus break compatibility with previous clients.

i mean a+b<=4MB done as a HF.

 

[achow101]

I now understand while I was having problems following the reasoning: I was thinking about the fee discount on the witness data, while you were talking about another discount I didn't know about: the one about the size of the witness?
Can someone please explain that to me? I have several objections but I would like to be sure to have a correct understanding.
Thanks

The fee discount is related to the size discount of the witness data. Because the size has a 75% discount, then so does the fee because the fee is directly related to the size of the transaction. See https://bitco.in/forum/threads/clearing-the-fud-around-segwit.1068/page-2#post-17103 for the math behind it. The idea behind it is that it is easier to implement than having two hard limits.

i mean a+b<=4MB done as a HF.

In that case, it isn't really different from a straight 4 Mb hard fork. The only difference is that transaction malleability will no longer be an issue, which is a good thing.

 

[cypherdoc]

I now understand while I was having problems following the reasoning: I was thinking about the fee discount on the witness data, while you were talking about another discount I didn't know about: the one about the size of the witness?
Can someone please explain that to me? I have several objections but I would like to be sure to have a correct understanding.
Thanks

SW discounts the size (bytes) of the witness block downwards by 75%. since fees are based on bytes, aka satoshis/byte, this results in a huge discount for any tx's producing SW outputs.
[doublepost=1461016070][/doublepost]

In that case, it isn't really different from a straight 4 Mb hard fork. The only difference is that transaction malleability will no longer be an issue, which is a good thing.

i know. in that sense, it would be a good compromise btwn the 2 camps. you'd get SW and the malleability fix and we'd get our HF blocksize increase. LN would benefit since it needs bigger blocks eventually anyways.

also, regular users don't feel abused by SW discounts.

 

[Dusty]

The fee discount is related to the size discount of the witness data. Because the size has a 75% discount, then so does the fee because the fee is directly related to the size of the transaction. See https://bitco.in/forum/threads/clearing-the-fud-around-segwit.1068/page-2#post-17103 for the math behind it. The idea behind it is that it is easier to implement than having two hard limits.

Ok, thanks for the confirmation.

So, my question is: why, instead of doing this complex calculation, they simply didn't define a maximum of 3mb for the witness block where its size grows with the size of 'b'?
Put in simple terms: let suppose that a segwit tx is composed by t and w: since t goes in the usual block and w goes in the "witness block", simply add them and check block limits.
So, the TX is too big if it overflows either the standard block or the witness block.

Too easy?

 

[cypherdoc]

@Dusty

b/c they've already determined from a variety of sources that 4MB blocks are perfectly fine for the network. plus, they want to take maximum advantage of stuffing as many p2sh multisigs at a 75% discount into the block as possible to jumpstart LN.

 

[Dusty]

That's my point: since it's so simple to count the new block size even with segwit they had to find a convoluted way to justify the fee discount for the kind of transactions that LN will use.

 

[sickpig]

@cypherdoc Your point? The 2 MB hard fork was centrally planned by Gavin, Garzik and Toomin.

For what is worth using the same logic even Satoshi centrally planned Bitcoin. In this context "centralization" doesn't fit at all, IMHO.

Maybe you meant top down "imposition".

Using your logic both SegWit and 2MB HF are centrally planned.

The difference steams from the method chosen by Core to deploy SegWit, i.e. soft-fork.

In case of soft-fork as a full node operator I've no way to express my contrariety to a new feature and at the same time remaining inside the system.

I can chose between being degraded to a not fully validating node or to upgrade to the new version.

Of course I could choose to run a different implementation that would discard block containing SegWit txs, but this does not differ from something we could call bottom-up hard fork.

In BIP 109 case all system actors (miners, node operators, merchants, exchanges) have a say. In SegWit cases miner voice is an 2 order of magnitude more important of any others.

Lastly, I've heard more than once that that bitcoin could not survive an HF.

Well if that's the case bitcoin is a dead thing walking already, and it is kept alive artificially by the mean of soft-fork upgrade mechanism.