Pages:
Author

Topic: Segwit details? N + 2*numtxids + numvins > N, segwit uses more space than 2MB HF - page 12. (Read 21405 times)

member
Activity: 76
Merit: 10
Whoa, whoa, wait...

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

So, 47 bytes per block. That's not too unreasonable. But...

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?

50 bytes per transaction for fully-validating nodes? This needs to be answered.

I would like to see an answer to this too, it seems everyone is avoiding this question. Fully validating nodes are very important for those of us that want to verify the blockchain ourselves and are required for bootstrapping new nodes.
legendary
Activity: 1176
Merit: 1134
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
how many bytes total does a segwit tx permanently occupy
just pick any standard normal tx.

is that number bigger or smaller than the size of the normal tx.

if the number is bigger, is this the case where "more" means "less"?
am I a troll because I am confused why something that is 10x more complicated, has potential attack vectors and requires adding trust to the bitcoin is marketed as helping with scaling by using MORE bytes.

I am just a simple C programmer and I dont understand complicated things like using more bytes to help scaling when that seems to be you end up with less tx that fit in the same amount of space.

please help me understand. Is there a new quantum zero knowledge phased space bit multiplexer now? do I need to find my flux capacitor from the attic?
newbie
Activity: 25
Merit: 0
Whoa, whoa, wait...

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

So, 47 bytes per block. That's not too unreasonable. But...

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?

50 bytes per transaction for fully-validating nodes? This needs to be answered.
sr. member
Activity: 687
Merit: 269
Someone's stressed that  ˵Bitcoin is out of their control˶
legendary
Activity: 2128
Merit: 1073
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.
sr. member
Activity: 687
Merit: 269
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
legendary
Activity: 1260
Merit: 1019
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!  Grin Both sides call me troll when I asking questions!
legendary
Activity: 1176
Merit: 1134
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
legendary
Activity: 1176
Merit: 1134
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
staff
Activity: 3458
Merit: 6793
Just writing some code
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?
sr. member
Activity: 687
Merit: 269
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
legendary
Activity: 1072
Merit: 1181
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).
legendary
Activity: 1260
Merit: 1019
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 No fork, but an increased number (~5%) of orphaned blocks.
Non-updated nodes will accept blocks version 5, because this is soft-fork
staff
Activity: 3458
Merit: 6793
Just writing some code
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.
legendary
Activity: 2338
Merit: 2106
legendary
Activity: 1260
Merit: 1116
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!
jr. member
Activity: 43
Merit: 1
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:
Quote
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
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.
hero member
Activity: 910
Merit: 1003
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.
legendary
Activity: 1232
Merit: 1094
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?

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

Quote
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.
donator
Activity: 2772
Merit: 1019
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?
Pages:
Jump to: