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

Sigals

member

Activity: 76

Merit: 10

Quote from: ChronosCrypto on March 16, 2016, 12:36:25 PM

Whoa, whoa, wait...

Quote from: Pieter Wuille on March 16, 2016, 09:27:36 AM

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

Quote from: jl777 on March 16, 2016, 11:29:36 AM

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.

jl777

legendary

Activity: 1176

Merit: 1134

Quote from: watashi-kokoto on March 16, 2016, 12:14:56 PM

Quote from: jl777 on March 16, 2016, 11:39:41 AM

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?

ChronosCrypto

newbie

Activity: 25

Merit: 0

Whoa, whoa, wait...

Quote from: Pieter Wuille on March 16, 2016, 09:27:36 AM

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

Quote from: jl777 on March 16, 2016, 11:29:36 AM

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.

watashi-kokoto

sr. member

Activity: 687

Merit: 269

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

2112

legendary

Activity: 2128

Merit: 1073

Quote from: jl777 on March 16, 2016, 01:15:24 AM

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

sr. member

Activity: 687

Merit: 269

Quote from: jl777 on March 16, 2016, 11:39:41 AM

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

amaclin

legendary

Activity: 1260

Merit: 1019

Quote from: jl777 on March 16, 2016, 11:39:41 AM

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!

jl777

legendary

Activity: 1176

Merit: 1134

Quote from: watashi-kokoto on March 16, 2016, 09:44:40 AM

Quote from: Pieter Wuille on March 16, 2016, 09:27:36 AM

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

jl777

legendary

Activity: 1176

Merit: 1134

Quote from: Pieter Wuille on March 16, 2016, 09:27:36 AM

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

achow101

staff

Activity: 3458

Merit: 6793

Just writing some code

Quote from: Pieter Wuille on March 16, 2016, 09:27:36 AM

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?

watashi-kokoto

sr. member

Activity: 687

Merit: 269

Quote from: Pieter Wuille on March 16, 2016, 09:27:36 AM

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

Pieter Wuille

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

amaclin

legendary

Activity: 1260

Merit: 1019

Quote from: cypherblock on March 16, 2016, 07:42:28 AM

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

achow101

staff

Activity: 3458

Merit: 6793

Just writing some code

Quote from: 600watt on March 16, 2016, 09:09:00 AM

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.

600watt

legendary

Activity: 2338

Merit: 2106

sry for offtopic noob question:

is this relevant?

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

BlindMayorBitcorn

legendary

Activity: 1260

Merit: 1116

Quote from: JorgeStolfi on March 16, 2016, 06:24:08 AM

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!

cypherblock

jr. member

Activity: 43

Merit: 1

Quote from: achow101 on March 15, 2016, 10:39:58 PM

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.

JorgeStolfi

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.

TierNolan

legendary

Activity: 1232

Merit: 1094

Quote from: jl777 on March 15, 2016, 10:42:59 PM

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.

molecular

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?

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