Segwit details? N + 2*numtxids + numvins > N, segwit uses more space than 2MB HF

[jl777]

I'm not sure about the space reducing part. Was that actually mentioned anywhere? I don't think I said that it would reduce the space used. It is essentially a 2Mb block size limit increase but with the added benefit of making transaction malleability impossible.

maybe you didnt say it, but the official claims are here: https://bitcoincore.org/en/2016/01/26/segwit-benefits/#block-capacitysize-increase

maybe its just me misinterpreting the english as my second language and the above isnt claiming that it will increase the block capacity. I avoid political stuff so maybe I am just not understanding the nuances of the english. recently I found out that "sick" meant "cool", but cool wasnt about the temperature, but something else. So I guess it just matters what the meaning of the words "size increase" means.

[1715115294]

1715115294

[1715115294]

1715115294

[1715115294]

1715115294

[1715115294]

1715115294

[1715115294]

1715115294

[funkenstein]

it is a hardfork pretending to be a softfork that increases tx capacity without doing a hardfork, but it actually wastes space permanently.

Of course it only wastes space on nodes running the segwit "softfork"

but if you received any wtxid and want to spend it, you need to run an updated wallet, which I am sure will be available within 3 days from when you get such a wtxid. After all the changes required are quite simple: https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki

Anybody that has written a bitcoin core from scratch (like me) should be able to implement the dozen or so changes in a month or two, and we can ignore any issues about the customer support as they can just do manual rawtx manipulations with all the great tools available for that if they really want to and dont want to update to the only wallet that supports segwit

So it breaks the installed base
Creates customer support and field update issues
And permanently wastes 30%+ of the new space as opposed to a simple 2MB hardfork (or 4MB)
But it will single source wallets for the months it takes for everybody to "fix" their software

Dont get me wrong, I think the segwit tech is pretty cool, but instead of pushing it into BTC mainnet under the innocent sounding "softfork" and exposing the entire installed base to pain and suffering, it seems this magnitude change should start in a side chain, get field tested and then if it makes sense to do a HARDFORK for it. DO NOT BREAK THE INSTALLED BASE

James

Funny

Is this thing just a hack to fool miners into storing more data?  As you point out it's not just more TX but also more bytes per TX.  I don't see it happening.  Who is going to send that first transaction that might be spendable by anyone?  Probably I am naive here and missing some political or alchemical posturing nuance.  If so that's fine, in the end nobody is going to break the installed base as you put it.  It's not worth the risk.     

There is also the claimed advantage that it removes malleability.  But again, is malleability really a problem?  If you are concerned about a TXID changing, for some scheme that relies on using unpublished TXs, then submit your transactions directly to a mining pool.  This is the way we need to go eventually anyway, as TX relaying by random nodes is purely altruistic and in a long term perspective looks like a temporary condition.   

Anyway thanks for your analysis. 





 

[l8orre]

I still say that it is a soft fork, albeit not entirely a soft fork but not a hard fork either. Let's agree to disagree.
 

So according to you it is not a soft fork, but it is not a hard fork either... so how many other forks are there? I think you need to explain this. Pitch forks maybe?

[molecular]

I really don't understand why we need to force our beloved wallet devs through this complicated mess. New address format? How to explain to users? All infrastructure needs to be upgraded... What a gargantuan task...

Why do we need segwit again?

[TierNolan]

it is a hardfork pretending to be a softfork that increases tx capacity without doing a hardfork, but it actually wastes space permanently.

What does "wastes space permanently" mean?

but if you received any wtxid and want to spend it, you need to run an updated wallet, which I am sure will be available within 3 days from when you get such a wtxid. After all the changes required are quite simple: https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki

You don't receive transactions, you receive transaction outputs.  If the address you provide is a standard address, then it can be processed by legacy clients. 

Old clients would have problems with zero confirms though.  SW outputs look like they can be spent by anyone.  You could send someone a transaction that spends a SW output and they will think the transaction is valid.

Even with P2SH protection, there is a window where you could "double spend" the output.  Once you get the pre-image of the P2SH output, you can create an unlimited number of double spends for that transaction that will be accepted by old clients.

So it breaks the installed base

The space improvements do assume that people actually use SW.  If nobody uses it, then there is no benefit.

[JorgeStolfi]

I asked some of these questions 3 months ago.  Never got a decent answer.

Blockstream wants soft-forked SegWit to fix the malleability problems (that would be needed for the LN, if they ever get it to work), and to force ordinary p2p bitcoin users subsidize the costs of complicated multisig transactions (ditto).  But these reasons do not seem explain the urgency and energy that they are putting on the SegWit soft fork.  Maybe they have other undeclared reasons?  Perhaps they intend to stuff more data into the extension records, which they would not have to justify or explain since, being in the extension part, "ordinary users can ignore it anyway"?

As for SegWit being a soft fork, that is technically true; but a soft fork can do some quite radical changes, like imposing a negative interest (demurrage) tax, or raising the 21 million limit.  One could also raise the block size limit that way.  These tricks would all let old clients work for a while, but eventually everybody will be forced to upgrade to use coins sent by the new verson.

[cypherblock]

No. It will not fork the blockchain. All of the blocks produced after the fork are still valid under the old rules. This is part of what makes it a soft fork. It doesn't fork the blockchain like a hard fork does.

Technically this is incorrect. Blocks produced by non updated Miners will be forked if they come after 95% blocks are updated to new version. New nodes will not accept these blocks, old nodes will.

From the BIP:

Furthermore, when 950 out of the 1000 blocks preceding a block do have nVersion >= 5, nVersion < 5 blocks become invalid, and all further blocks enforce the new rules.

So if 5% of the miners don't upgrade, and produce a block (which will have nVersion<5), non-updated nodes will accept that block, but updated nodes will not. Once this happens, non-updated nodes will only accept new blocks from the 5% since the 95% will not be building off that <version 5 block. Thus the chain is forked into a 5% hash power chain and a 95% hash power chain.

EDIT:
amaclin corrected me below, no hardfork because, duh, old nodes will still see blocks from the 95% as valid, so even if they receive a 5% block first, the 95% will quickly build a longer valid chain, thus 'orphaning' this 5% block. So no fork really just orphaned/stale blocks. 5% miners will lose money though in wasted electricity and no block rewards.

[BlindMayorBitcorn]

I asked some of these questions 3 months ago.  Never got a decent answer.

Blockstream wants soft-forked SegWit to fix the malleability problems (that would be needed for the LN, if they ever get it to work), and to force ordinary p2p bitcoin users subsidize the costs of complicated multisig transactions (ditto).  But these reasons do not seem explain the urgency and energy that they are putting on the SegWit soft fork.  Maybe they have other undeclared reasons?  Perhaps they intend to stuff more data into the extension records, which they would not have to justify or explain since, being in the extension part, "ordinary users can ignore it anyway"?

As for SegWit being a soft fork, that is technically true; but a soft fork can do some quite radical changes, like imposing a negative interest (demurrage) tax, or raising the 21 million limit.  One could also raise the block size limit that way.  These tricks would all let old clients work for a while, but eventually everybody will be forced to upgrade to use coins sent by the new verson.

You've come to the right place for answers, professor. Openness is our middle name!

[600watt]

sry for offtopic noob question:

is this relevant?

http://seclists.org/oss-sec/2016/q1/645

[achow101]

sry for offtopic noob question:

is this relevant?

http://seclists.org/oss-sec/2016/q1/645

No. That is with the git, a VCS not specific to bitcoin. We are taking about segwit here which is a bitcoin consensus specific thing.

[amaclin]

So if 5% of the miners don't upgrade, and produce a block (which will have nVersion<5), non-updated nodes will accept that block, but updated nodes will not. Once this happens, non-updated nodes will only accept new blocks from the 5% since the 95% will not be building off that <version 5 block. Thus the chain is forked into a 5% hash power chain and a 95% hash power chain.

No fork, but an increased number (~5%) of orphaned blocks.
Non-updated nodes will accept blocks version 5, because this is soft-fork

[Pieter Wuille]

From the point of view of old clients, segwit adds one coinbase output that contains the root hash of the Merkle tree that commits to the witness transaction ids. It uses 47 extra bytes per block, so technically, yes, it "wastes precious blockchain space". The blockchain on-disk can be pruned though (implemented as an experimental feature in Bitcoin Core 0.11, and with nearly full functionality in 0.12), so calling it "permanently" is not very accurate.

If you're talking about storage space used by segwit-compatible full nodes, well, obviously it will use more space, because it increases block capacity - that capacity has to go somewhere. However:

• The extra space used by witnesses is more prunable than normal block space, as it's not needed by non-validating clients.
• Has less effect on bandwidth, as light clients don't need the witness data.
• Has no effect on the UTXO set, so does not contribute to database growth and/or churn.
• Enables script versions, which will make the introduction of Schnorr signatures much easier later on, which are more space efficient than what we have now (even for simple single-key outputs/inputs).

[watashi-kokoto]

From the point of view of old clients, segwit adds one coinbase output that contains the root hash of the Merkle tree that commits to the witness transaction ids. It uses 47 extra bytes per block, so technically, yes, it "wastes precious blockchain space". The blockchain on-disk can be pruned though (implemented as an experimental feature in Bitcoin Core 0.11, and with nearly full functionality in 0.12), so calling it "permanently" is not very accurate.

pieter keep up the great work! we're on your side.

don't worry about the lies, manipulation and misinformation, we're on it. we got it covered.

jl777 joined the dark side, and for all intents and purposes should be considered a troll with agenda.

don't feed the trolls

[achow101]

From the point of view of old clients, segwit adds one coinbase output that contains the root hash of the Merkle tree that commits to the witness transaction ids. It uses 47 extra bytes per block, so technically, yes, it "wastes precious blockchain space". The blockchain on-disk can be pruned though (implemented as an experimental feature in Bitcoin Core 0.11, and with nearly full functionality in 0.12), so calling it "permanently" is not very accurate.

If you're talking about storage space used by segwit-compatible full nodes, well, obviously it will use more space, because it increases block capacity - that capacity has to go somewhere. However:

• The extra space used by witnesses is more prunable than normal block space, as it's not needed by non-validating clients.
• Has less effect on bandwidth, as light clients don't need the witness data.
• Has no effect on the UTXO set, so does not contribute to database growth and/or churn.
• Enables script versions, which will make the introduction of Schnorr signatures much easier later on, which are more space efficient than what we have now (even for simple single-key outputs/inputs).

How are the witnesses serialized and sent with blocks?

Also, is there (or will there be) a full technical write up of the changes of segwit so that wallet developers can change write changes accordingly? Preferably before the ogival release of segwit?

[jl777]

From the point of view of old clients, segwit adds one coinbase output that contains the root hash of the Merkle tree that commits to the witness transaction ids. It uses 47 extra bytes per block, so technically, yes, it "wastes precious blockchain space". The blockchain on-disk can be pruned though (implemented as an experimental feature in Bitcoin Core 0.11, and with nearly full functionality in 0.12), so calling it "permanently" is not very accurate.

If you're talking about storage space used by segwit-compatible full nodes, well, obviously it will use more space, because it increases block capacity - that capacity has to go somewhere. However:

• The extra space used by witnesses is more prunable than normal block space, as it's not needed by non-validating clients.
• Has less effect on bandwidth, as light clients don't need the witness data.
• Has no effect on the UTXO set, so does not contribute to database growth and/or churn.
• Enables script versions, which will make the introduction of Schnorr signatures much easier later on, which are more space efficient than what we have now (even for simple single-key outputs/inputs).

Let us ignore pruning nodes or anything about SPV nodes. My concern is about full relaying nodes. My assumption is that for a segwit compatible full relaying node to be able to relay the full blockchain it would need to have ALL the data, original blockchain and witness data.

How can ANY of that data be pruned and still be able to be a full  relaying node?

If all such data is needed, I want to call the combined size the size of the blockchain. Regardless of whether it is one or 2 different datasets.

So unless there is magic involved that allows relaying data that has been pruned, pruning is IRRELEVANT.

This then gets us to my question that is not being answered. On average, how many bytes in the blockchain will be needed for a standard payment sent via segwit?

Is this ever less than it would be now?
Is this ever the same as it is now?
Is this usually about 50 bytes more per tx?

Unless there is actual savings of blockchain space, then it would be a failure as far as reducing blockchain usage. What am I missing?

James

[jl777]

From the point of view of old clients, segwit adds one coinbase output that contains the root hash of the Merkle tree that commits to the witness transaction ids. It uses 47 extra bytes per block, so technically, yes, it "wastes precious blockchain space". The blockchain on-disk can be pruned though (implemented as an experimental feature in Bitcoin Core 0.11, and with nearly full functionality in 0.12), so calling it "permanently" is not very accurate.

pieter keep up the great work! we're on your side.

don't worry about the lies, manipulation and misinformation, we're on it. we got it covered.

jl777 joined the dark side, and for all intents and purposes should be considered a troll with agenda.

don't feed the trolls

dark side? I am asking questions I need answered to be able to implement things. The more I find out about segwit, the more it appears to be a LOT of work needed that can be avoided just with a 2MB hardfork. And compared to a 2MB hardfork segwit wastes space as far as I know at this moment and I await to be corrected.

FYI I am on no side other than the side of truth. The other side has politicized the RBF and claims it is the devil's spawn. I keep saying the reason RBF breaks zeroconf is that zeroconf is totally broken when the blocks are full. So adding RBF still leaves zeroconf broken when the blocks are full.

Now, one difference is that the other side doesnt start calling me a troll when I point out that their technical analysis is incorrect.

my agenda is to implement a scalable onchain bitcoin. If I see something that doesnt make sense, I will ask about it. If I get nonsense answers, I will point that out.

If using logic and asking pointed questions makes me a troll, then I guess I am a troll. Convince me with the math, then I will be segwit's strongest advocate. It the math doesnt add up, I will call it what it is

[amaclin]

Now, one difference is that the other side doesnt start calling me a troll when I point out that their technical analysis is incorrect.

You are fucking lucky!  Both sides call me troll when I asking questions!

[watashi-kokoto]

If using logic and asking pointed questions makes me a troll, then I guess I am a troll. Convince me with the math, then I will be segwit's strongest advocate. It the math doesnt add up, I will call it what it is

the paper's out there
read it and then come back
FYI 1.375 to 1.75 MB per block

[2112]

maybe its just me misinterpreting the english as my second language and the above isnt claiming that it will increase the block capacity. I avoid political stuff so maybe I am just not understanding the nuances of the english. recently I found out that "sick" meant "cool", but cool wasnt about the temperature, but something else. So I guess it just matters what the meaning of the words "size increase" means.

Your English is very fine, in fact it is already better than the written word of many native English speakers.

The mistake you are making is your avoidance of the "political stuff". There's no way to avoid learning about https://en.wikipedia.org/wiki/Political_economy .

"segregated witness" is a neat tool that cleaves not only "big blockists" but also "small blockists" associated around Mircea Popescu's  http://thebitcoin.foundation/ which considers 0.5.3 as the "original codebase".

The key contribution of Adam Back is his update of https://en.wikipedia.org/wiki/Democratic_centralism vocabulary to the situation in 21st century.

If you really try to understand what's going on reread the https://en.wikipedia.org/wiki/Twenty-one_Conditions , but replace "communist" with "bitcoinist" and "proletariat" with "bitcoinariat", "counter-revolutionary element" with "troll", etc.

[watashi-kokoto]

Someone's stressed that  ˵Bitcoin is out of their control˶