Bitcoin Forum

I finally found a video that explains it in a way a non-technical person like me can understand. https://www.youtube.com/watch?v=QYZv92F2kCw

But that brings me to a question. Where are extended blocks stored and can we call the information from within it on command? What if I want to see the signature of the sender? Are all the data pulled by Segwit still retrievable?

There are no "extended blocks". Blocks are the same as before; they only contain the block header and the transaction. What changed was the transactions. The transactions have two different formats: legacy, and segwit. When a segwit capable nodes receives a block, it will receive the block with transactions in the segwit format. When a non-segwit node receives a block, it will receive the transactions in the legacy format.

When you run a segwit capable node, using the getrawtransaction or gettransaction commands will give you all of the details of the transaction, including the witnesses.

Thanks for the reply. But where are the input signatures "stored" and hashed, and how does that "free" space from the blocks to allow more transactions to fit in?

The more I try to learn the more questions I have. :(

The signatures are stored as part of the transaction. Because legacy nodes will not see the signatures, there is effectively more free space in the block for more data that those legacy nodes can see (e.g. more transactions).

What actually happened is that the block size limit was redefined to something called block weight. There is now a block weight limit, which is 4000000 weight units. Each byte of non-witness data (everything that a legacy node will see) is worth 4 weight units. Each byte of segwit data (everything that a legacy node won't see) is worth 1 weight unit. So if you use segwit, more bytes of your transaction will be in witness data than a comparable non-segwit transaction. So the weight of your transaction is lower and thus there will be more weight for other transactions in the block. That is where the capacity increase comes from.

Ok, sorry for all the dumb questions. I believe it is time for me to go back and read more about it. As you have seen, I am not a technical person so the concept is a little hard for me to grasp.

Hi Achow, did Segwit make the blocks more compact by removing the signatures from the transactions and placing them in an "extended block", and at the same time, maintaining the block size to 1mb?

Is that what it really did?

Another question. Where is the "extended block" stored exactly?

achow101 already answered your questions.  Fully.  Did you read his replies to you?



In other words, there is no “removing” of signatures as you say.  Now to elaborate on this, which you should read carefully:


Stop thinking in terms of “block size”.  The whole concept of a “block size” is obsolete.  With Segwit, there is no longer a block size limit at all!  Instead, as achow101 already explained to you, there is a block weight limit of 4000000 bytes (https://github.com/bitcoin/bitcoin/blob/1e65f0f3396d5d7eaa8e8dd3668dfa180b541c18/src/consensus/consensus.h#L14):


The above-mentioned “weight” calculation is specified by BIP 141 (https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#user-content-Block_size):


Aside:


There is no need for you to grasp it.  If you’re “not a technical person”, don’t even try.  And if you do want to try, then you should start by increasing your basic technical skills—then reading the specs.  Then, you would never find yourself apologizing for “dumb questions”.

There is some sort of absurd postmodern myth that everybody needs to understand everything.  No, you don’t—and you won’t; you never will.  You use technology every day which you have not the slightest hope of ever understanding.  I guarantee that you don’t understand GPS, either; but I’d wager that you trust it to guide you where you want to go.

Segwit is highly technical.  It’s a hack; but it’s a brilliant, elegant hack which makes everything Just Work without sacrificing backwards compatibility (= no hardfork).  The whole Internet is built on such hacks, most of them far less neat and orderly.  Do you want to start brushing up on IPv6 and DNSSEC?  Or for that matter, the long chain of weird kludges applied to SMTP since the protocol was first defined in 1982?

Segwit does not remove signatures; that’s a ridiculous canard peddled by smear campaigners for cheap propaganda purposes.  The engineers did a fine job on this one.  That’s all you really need to know.  If you can’t or won’t read all the specs—if you lack the ability and/or the will to work through the process of gaining significant expertise—then don’t ask questions, especially if you won’t read the answers anyway.  Just sit back, use, and enjoy.

(Note:  I am not affiliated with Core, though I hope to perhaps contribute someday.  I like specs and Unix kernel C code for bedtime reading.)

It can't be that great a video if it explains it in a way that gave you the wrong impression.  I'll take a crack at it in the hope it might make more sense. 

There is only one set of blocks.  It's just that the blocks can be read in one of two ways.  Legacy nodes (any non-SegWit ones) can only ever see a maximum of 1MB of the block, however large it actually happens to be.  SegWit nodes, however, can see the total size of the block in its entirety.  SegWit transactions store witness data in the extra space (up to a maximum of 3MB added on top of the base 1MB) that all the legacy nodes can't read, meaning there's slightly more space for transactions in the 1MB base portion.

As an example, you can see with your own eyes (https://www.xbt.eu/) plenty of blocks now taking up more than 1MB of space, but for all the nodes that don't support SegWit, they won't be able to recognise or understand the witness portions that take those blocks over 1MB.  They simply don't see it, so all of those blocks still appear to be smaller than 1MB to them, meaning they'll simply ignore everything in the witness space (because they don't even know it's there).

Technically it isn't any smaller, but it still means more transactions can fit into the base 1MB portion of the block, because the legacy nodes can ignore all the SegWit signatures.

Sorry. I know I am technically slow to you but the least you can do is to encourage the learning process. I also know I do not have to understand what goes on "under the hood". But what can I do? There interest is there.

The original bitcoin was plain and simple - there are blocks, there are transactions in the blocks, that's it. Now there is SegWit and looks like no one understands what does it mean. If all TX info is still in blocks, what was the point of segwit if transactions are still there. If the TX information is outside of the blocks from now on where is the rest?

"You are dumb and don't understand and it's okay" is not an answer - it means that you have no idea what's actually going on.

I wouldn’t have come down so hard on you, except that you asked again exactly what achow101 had already answered in detail.  Why did you bother asking the first time, if you did not intend to read the answers?

DooMAD’s high-level explanation is well done, if you just want to get the general feel of how Segwit works.

However, speaking only for myself, I’m not interested in “[encouraging] the learning process”.  People who really want to learn, will start by studying everything they can—before they ask questions.  And people who really want to learn, will not be stopped by anything; they don’t need to be encouraged.  I am reminded of an anecdote[1] about a professor who once told a hapless freshman, “You’re not smart enough and you’re not working hard enough.”  I think that is a suitable answer for many questions.  Deserving students will take the hint; and those who don’t have it in them will be saved much trouble.

---

1. From Philip Greenspun?  I can’t find it now.

---

That’s an idiotic non-argument.  Tell me, Valle, if you understand the following technologies which you use every day; I guarantee that you will get zero for seven here:

0. The transistor, in its present-day integrated-circuit implementations measured in nanometers

1. Lasers

2. The Global Positioning System (GPS)

3. The secp256k1 elliptic curve cryptography algorithm used in the “original Bitcoin”, and used now

4. The past two decades of research in TCP congestion control algorithms

5. The metallurgy and materials science used to produce modern steels (hint: much different from steels produced 50 years ago!)

6. The virtual memory management code in your operating system’s kernel

The technologies I named above are much more difficult to understand than Segwit (!).  The technologies above are things which I don’t fully understand—I mean, not really, not according to my own standard of “understanding”.  But it is okay for me to not understand them.  It would not be okay for me to pass an opinion about their technical merits, without understanding them.

The fact that I do not understand them, does not mean that scientists and engineers who work with them daily “have no idea what’s actually going on.”

Bitcoin engineering is hard.  Scaling anything is hard.  “Plain and simple” is not a technical argument.  If you are too dumb to understand the technologies involved, then no, you are not entitled to an opinion.  Ill-informed opinions are worse than worthless, since they are nothing more than hot air which wastes the valuable time of people whose opinions actually mean something.

P.S.:


Valle, since the “original bitcoin was plain and simple”, why don’t you write me an “ELI5” on the mathematics of the SHA-256 hash’s “avalanche effect”, and explain why that’s always been so important to Bitcoin’s network security.  That’s much harder to understand than Segwit.  Or if you can’t understand it, does that mean that Adam Back had “no idea what’s actually going on” when he invented HashCash?  And Satoshi was just stumbling blindly when he repurposed the HashCash concept to create a Byzantine fault-tolerant decentralized database?  Oh, puh-leaze tell me that you know what the Byzantine Generals Problem is!  “The original bitcoin was plain and simple”, right?

Bitcoin was never simple. (http://queue.acm.org/detail.cfm?id=3136559)  The fact that you say it was means that you, personally, never had any idea what was actually going on.

P.P.S., Satoshi was a genius.  The shame is that more oft than not, his great opus is as pearls before swine.

That’s an idiotic non-argument.  Tell me, Valle, if you understand the following technologies which you use every day; I guarantee that you will get zero for seven here:

0. The transistor, in its present-day integrated-circuit implementations measured in nanometers
What exactly you don't understand in transistors? It's a school basics, isn't it? Nanometer size transistors are basically same as larger ones but takes less current.

1. Lasers
Physics, like schools grade 9. Simple quantum physics/chemistry what can be explained easily in terms or resonance and basic electron levels.

2. The Global Positioning System (GPS)
This is bit trickier to understand because of relativistic effectsm however most people supposed to understand it in high school physics.

3. The secp256k1 elliptic curve cryptography algorithm used in the “original Bitcoin”, and used now
I'm author of alternative bitcoin client (android paper wallet). I do understand EC.

4. The past two decades of research in TCP congestion control algorithms
Yes... I have a my own TCP-IP implementation to understand it.

5. The metallurgy and materials science used to produce modern steels (hint: much different from steels produced 50 years ago!)
I've been studying in Bauman state university for few years in metallurgy major (dropped it, too boring)

6. The virtual memory management code in your operating system’s kernel
Approximately.

The technologies I named above are much more difficult to understand than Segwit (!).

Cool. It means it's very easy to understand where extended blocks data is stored, right?

nullius, it is very silly of you to think that you are the smartest and if you cannot understand some things then nobody can.

As per average how many transactions can a 1 MB block hold?

Blocks are not limited to 1MB.  There is no longer any such concept as a block size limit.  Read upthread (https://bitcointalk.org/index.php?topic=2501877.msg26277190#msg26277190).

The average number of transactions a block can hold will depend on the transactions’ average weight—an empirical question, depending on what transactions people are actually making on the network.  You may expect the average weight to drop as more people send Segwit transactions.  You may expect it to plummet after Schnorr signatures become available—especially if/when that gets uptake from senders with very large numbers of inputs/outputs, such as exchanges.  Lower average weight is good:  That means more transactions can fit in a block, according to the simple equation from BIP 141 quoted above.

---

Valle, it was obvious that I meant “understand” on the level of neither high school physics, nor pop-science explanations—nor courses you allegedly dropped out of.  “Understand” in this context means understanding on the level of intelligently discussing implementations.  You’re a fool if based on your ninth-grade physics class, you would try to pass an opinion on engineering questions involved with maintaining and improving the GPS system, or how best to make light lase given a certain particular set of operational requirements.  Oh—and if you can write virtual memory code or a non-toy TCP implementation, I’ll eat my hat.  Serious engineering (http://caia.swin.edu.au/urp/newtcp/papers.html) goes into such things.

But put all that aside.  You have a much more basic problem, one of first-grade reading comprehension:


Upthread (boldface added):


Why do Core people even bother trying to explain in public forums, if this is the response?

---

No discussion of Byzantine generals and their security significance, I see.  In Bitcoin, exactly 0% of that problem is solved by EC.  Nor did you catch the subtle relation between avalanche and HashCash.  (I threw that in because it’s a rather abstruse observation, so you couldn’t crib the answer by checking Wikipedia.)  I could hear a whooshing noise as the whole point of my post went over your head.

Really, all problems for a digital currency except for Byzantine generals could be considered solved as of the 1990s.  Try reading the ACM Queue article I linked above, if you want a good overview of what complexity went into your ostensibly “plain and simple” Bitcoin.

{ethical behavior}
you both do not provide any value to the discussion.
Instead you try to challenge each other with a level of knowledge, which is highly irrelevant to the community, and (if at best) only proves a certain immaturity, developing an arrogance towards "ordinary people", which prevents you to respect others and thus adding value to the discussion.
And insulting language ("being dumb" or "must not interest you") is certainly out of scope of a technical forum like here.
{/ethical behavior}

pebwindkraft, I respect your desire for an environment of technical discussion.  I wish for the same thing.

Perhaps my patience is worn just a bit thin from people who have an axe to grind against Segwit, and do so solely with arguments from ignorance—in essence, “it’s too complicated because I don’t understand it.”  (I have never actually seen a technical argument against Segwit.  Not one!)  I also have zero respect for people who don’t read the technical answers provided—upthread, on the same page, with citations to specs and source code.  And why yes, I am an elitist who gives short shrift to ill-informed opinions.  I don’t apologize for any of that; and I do think it’s a benefit that I have no reason to be diplomatic toward anybody.

But I’ll bow out of this thread if it’s fanning the flames too much here.

pebwindkraft is right, it became too personal, I'm sorry about that.

However, there is still a common confusion about SegWit - since blocks are the same and still store all the info necessary to validate transactions, then why does it help to make blocks smaller/fit more transactions? Obviously it's related to the witness data in TX which seems to give ability to reuse some information somehow but as the thread author mentioned it's hard to see how does it do that.

The principal benefit of that particular aspect of Segwit is that it avoids a hardfork.  Hardforks are anathema to a currency which holds huge amounts of real-world value, although there is Bitcoin hardfork research (https://bitcoinhardforkresearch.github.io/) ongoing to plan how to do one with absolutely no mistakes if/when it becomes necessary in the relatively far future.  Increasing the blocksize limit would have required a hardfork—where all nodes must be upgraded on deadline, and any which didn’t upgrade would suddenly break, badly.  But with Segwit, old nodes will continue to see blocks with a 1000000 byte block size limit, whereas new nodes will see blocks with a 4000000 byte block weight limit.  Old nodes can continue to send transactions, their old way; they simply will not know how to validate transactions sent the new way.  It’s ingenious!

Note that Segwit does not make blocks smaller at all.  It raises the block capacity, up toward a theoretical limit of 4000000 bytes.  In practice, best estimates are that with full Segwit adoption, we will get blocks a bit more than 2MB in actual size.  It was aimed to be an approximate doubling of block capacity, which so many people had been requesting.  Research indicated that such an actual size of blocks would be safe for the network and for nodes, but that much larger sizes would not be.

There are other important fixes (https://bitcoincore.org/en/2016/01/26/segwit-benefits/) built into Segwit—most importantly, a fix for tx malleability; but the foregoing summarizes the reasoning behind the part of Segwit which magically raises block capacity without instantly breaking anybody’s use of Bitcoin.

Now segwit makes sense for me, thank you! One more minor question - do I understand correctly that you can fit only more transactions what use segwit addresses, and in case all clients would keep using addresses starting with 1 then the block size limit stays effectively same as it was before softfork?

I am getting confused here. Are you arguing against yourself? Hahaha.

But thanks for the advice. I will set it upon myself to learn more now and then ask questions later. With that in mind I hope to learn from the both of you, nullius and Valle.

You’re welcome!  To your question:  Yes, you understand correctly on that point.  Segwit’s benefit to block capacity is proportionate to adoption; and if nobody were to use Segwit addresses and tranasctions, then Segwit would have no effect at all on block capacity.  But fortunately, to the flipside, the Segwit design implicitly incentivizes Segwit use.  Anybody who uses an address starting with a “1” is overpaying (approximately[1]) fourfold on fees, because their transactions “weigh” so much more than Segwit transactions.

Looking at it from the opposite perspective, switching to a Segwit address will bring you (approximately[1]) an instant 75% discount on fees.  I have spent a bit of time on the forum (futilely) trying to inform people who complain about fees that they can get themselves an instant 75% discount, in bold letters.  (Perhaps I should try adding emoji—ick! :-( )  I myself have been using Segwit addresses for months, largely for this reason.  Well, I do like showing off in my signature; and I am a Segwit supporter.  Still, I’ll admit that for actually making the change, the fee difference was an awfully nice incentive!

But it’s not there to be “nice”; and it must be emphasized, what I am here calling a “Segwit discount” is not some arbitrary rule made to push Segwit.  Rather, as I said, it is implicit in the design.  If you use an old-style address, then your bytes are consuming about 4× the block weight; that is, you are selfishly consuming about 4× the amount of a globally shared resource.  This pushes the network toward the position you just described, of still being effectually limited to 1MB blocks.  Whereas if you use Segwit, then byte for byte, you consume about 75% less block weight.  That frees up more space for use by others, increasing the network’s capacity and relieving fee pressure.  Thus it is a natural, logical consequence that you will pay about 75% less.  Fair is fair; and as with all else in Bitcoin, the system is carefully designed to align people’s selfish interests with the common good.

(This leaves two practical issues:  Choice of Segwit address type (nested-in-P2SH vs. Bech32), and actually using Segwit addresses with currently available software.  Earlier, I started writing an exceedingly long post about these issues.  It didn’t get done; and for discussing wallets and usage instructions, this is the wrong forum, anyway.  Generally, here or elsewhere, I would be happy to answer questions in so far as I am able.)

---

1. The fourfold increase/75% discount is approximate.  As quoted in my previous post (https://bitcointalk.org/index.php?topic=2501877.msg26277190#msg26277190), the precise equation for block weight from BIP 141 is “Base size * 3 + Total size”, where “Base size is the block size in bytes with the original transaction serialization without any witness-related data, as seen by a non-upgraded node”, and “Total size is the block size in bytes with transactions serialized as described in BIP144, including base data and witness data.”  That is the equation which miners now must use when selecting transactions and, it is to be hoped, trying to fit as many as they can into a block.  The witness data are by far the biggest part of any ordinary transaction; and when the size thereof doesn’t get multiplied, the difference swamps everything else.  Thus in practice, calling Segwit a “75% discount” will suffice for a rule of thumb.

Awesome! I'll try to implement SegWit in my client.

With all that in mind, is there a desktop wallet that can create Segwit addresses by default? Electrum is sadly a no. I also cannot believe that the largest online wallet provider Blockchain.info has not enabled Segwit. Were they not one of the companies that were complaining that their customers are paying high fees?

I see the hypocrisy here because Blockchain is now enabling Bitcoin Cash in their wallets. But why not Segwit?

Plus I believe we should start campaigning for Segwit usage in the forum. But first I need to understand how it works. I hope you will me patient with me.

Awesome right back at you!  Core provides a concise technical overview (https://bitcoincore.org/en/segwit_wallet_dev/) of what is needed for implementing different levels of Segwit support, with links to the pertinent BIPs.

When you’re done, if desired, you may submit a GH pull request to add your software project or company to the list of those which have adopted Segwit (https://bitcoincore.org/en/segwit_adoption/).

That will be good for your users, and good for the network.  It will also prepare you to add important future upgrades such as Schnorr signatures and MAST, which will depend on support for Segwit’s script versioning system.  Segwit was not only a capacity upgrade; it was a bugfix (tx malleability, etc.) and a means to add forward compatibility.


As of version 3.0, released last month, Electrum does support Segwit!  You need to generate a new Electrum wallet for this; and if you select “Segwit wallet”, it will only give you Bech32 addresses.  If you want Bech32 addresses, then your problem is solved.  Bech32 addresses (https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki) are technically superior to old-style addresses; but they are not backward-compatible, so only people with Segwit support will be able to send you money.  I myself hope to switch to Bech32 in perhaps 6–12 months.  Future viewers of this post will see my signature showing an address which starts with “bc”.

To make Electrum give you a wallet of backward-compatible P2WPKH-nested-in-P2SH “3” addresses like the one you see now in my signature, use the following procedure, which I have tested:  (0) Generate a BIP39 seed by some other means.  I wrote a short C program for this, which I should polish up and post online; BIP 39 (https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki) itself contains a list of implementations, including the Python reference implementation (https://github.com/trezor/python-mnemonic).  (1) In the new wallet dialogue, tell Electrum that you already have a seed.  (2) In the seed entry dialogue, click the button for more options and tell Electrum you’re using a BIP39 seed.  (3) In the next screen, change the derivation path to m/49'/0'/0'.  The only part which needs to be changed is the “49”.  You may refer to BIP 49 (https://github.com/bitcoin/bips/blob/master/bip-0049.mediawiki) (as to the 49, the “purpose”) and BIP 44 (https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki) (for the two zeroes, “coin type” and “account”) to confirm that I am not giving you bad instructions which will send your money off into the weeds; I mention that because I’ve seen Internet posts get this part wrong.


Though perhaps some of the major players just don’t yet have their acts together, there is much political motivation behind some of these decisions.  I will take it as conclusive evidence when a company adds forkcoin support without letting their users use Segwit addresses.


Perhaps you can tell, I agree about that campaigning!

I hope that my posts have helped with understanding.

If you check my post history, you may notice that I am ruthless and downright nasty to anybody who seems to have ulterior motives.  Especially anybody who openly promotes a fork coin (https://medium.com/@lukeparker/the-trust-attack-a6241a08a9cd) (n.b. that I just tossed that link because it’s handy; here lies a very deep rabbit hole, one where all the rabbits were killed and eaten by poisonous snakes).  But for decent people who want to use Bitcoin and desire to better understand it, I am happy to help.

I tried generating a wallet in Electrum 3.0.3 but it does not have an option to choose a "Segwit wallet". All the choices it has is the same as the previous builds.

Plus, you are right. The Bech32 addresses which start with "bc1" are not supported and, I believe, will not be in the near future.

I will also refrain from doing anything to technical to find a Segwit enabled wallet for now. I will exhaust all the easier options first. Thanks for your help, nullius.

Then you're doing it wrong. When you create the wallet, choose "create a new seed". Then in the next window, you will choose between "Standard" and "Segwit".

Electrum supports them, but few other clients do currently.

How do the old nodes see Segwit transactions? If I've understood correctly, they see Segwit transactions as something called "anyone can spend transactions"? What about the witness data? How the old nodes interpreted it? It is written somewhere, that the old nodes don't see the witness data at all, but how is that possible, when the data still is broadcasted in the network?

As per my previous post, any nodes not supporting SegWit will only see the "base" weight of the block.  That means they see the transaction details and signatures for non-SegWit transactions, just as they always have.  But they won't see the signatures from all the SegWit transactions, as that's stored in the new "witness" portion of the blocks which they ignore completely.  They don't try to "interpret" what they don't understand.  SegWit nodes see and validate all of it.  And there are enough SegWit supporting nodes for that to work and for the network to function correctly.

As far as I understand older clients see SegWit transactions as zero input/one output transactions due TX format.

No, that is completely incorrect. Older clients will simply not see the witness data (which includes the 0x00 and 0x01 marker and flag bytes) as that data will not be transmitted to them. They will still see that inputs are being spend and outputs are created so that they can update their UTXO sets accordingly.

Is it possible for the community to do another version of the USAF by declaring that their nodes will stop accepting legacy blocks at a certain date?

Maybe this should happen and put Bitcoin's "oligarchy" on high alert to start using Segwit.

It's always possible, I just wouldn't say it's advisable.  Whether it's miners trying to split off without support from nodes and devs, or nodes trying to split off without support from miners and devs (which is exactly what UASF was), it's still going to be a contentious fork.  The previous attempt at UASF was flagrantly duplicitous when most of its support came from people who claimed they want to avoid contentious forks and then suddenly propose a contentious fork.  Plus, while they might call it a "user activated softfork", it invariably results in a hardfork anyway, because there are two incompatible codebases.

If a proposed fork naturally ends up becoming contentious because people simply can't agree, then that can't be avoided.  But we shouldn't be aiming to cause division and controversy from the offset by trying to achieve consensus at the point of a gun, which is UASF's biggest drawback.  It's an act of force and coercion.  We need a healthy mix of support from nodes, miners and devs.  Ideally, all three groups will voluntarily come together and use the codebase that provides the strongest incentives to secure a chain and build upon it.  

People should follow a fork because they want to, not because someone is trying to make them.

No, it's impossible to soft fork by changing pre-existing consensus rules. Refusing to accept blocks with non-witness transaction could only be a hard fork, and would need very high (90-95%) user support.


Hard forks so far (Bcash and S2X) have shown that hashrate follows userbase, not the other way around. But it's not impossible to have a cryptocurrency with little discernible userbase (and hence no real economy), Bcash and Ripple being the most significant examples.


For the above reason though, it's possible to use flag-day activation for forks that are soft-forks. This is how many soft-forks were activated in the past, and also how Segwit was activated using BIP91 (non-supporting blocks were orphaned, and so miners had to upgrade to continue getting their blocks accepted).

Does the work needed for the POW scale with the new block size or it has nothing to do with it?

The PoW and block size are completely independent and have nothing to do with each other.

So, if I haven't got it all wrong, there is a great incentive for miners to mine Segwit blocks instead of old BTC blocks. There will be many more transactions inside each block, hence the total amount of transaction fees from each block will be much higher. If that's the case, the network would move to Segwit quickly, as people will have to follow the large pools to get their transactions confirmed in a reasonable time or pay substantially high fees.

The vast majority of miners have already moved (https://www.xbt.eu/) to SegWit.  That's how it got activated in the first place.  Nearly all the blocks are over the old 1MB limit now.  The issue is getting more users to utilise SegWit, but support for the new address format has been weaker than anticipated.  One would have thought the potential for lower fees would be enough of an incentive, but adoption is still slow. 

It is not only the users' fault but also the fault of Bitcoin services like Blockchain.info, Coinbase and Bitpay. Those are the same services that signed the New York Agreement. The have the power to lure the users to start using Segwit but why do they prefer to accept Bitcoin Cash than enabling Segwit?

True.  All those third party services lost time which they could have been spending developing their support for SegWit, but instead spent supporting the coin that forked away.  But I would have thought they'd at least have some of the groundwork done had the original SegWit2x gone ahead, since many of them claimed they were going to support that.  Evidently it was tricky to gauge at the time which proposals they were genuinely ready to get behind and which ones they were merely paying lip-service to.  But now it's all pretty apparent which horse they were backing and now have to play catchup as a result.

I have a question about segwit and fees.

In order to benefit from the reduced fee from segwit, all the addresses in which you are sending the money must be using bech32 addresses to receive the bitcoins, or it only depends on your end? (using bech32 to send the bitcoin, then even if you are sending it to a legacy address, you still get the same reduction of fees)

I assume that both ends must be bech32 to reduce the size of the transaction?

What happens if it's a mixed transaction with some legacy, some 3 and some bc1? example:

https://btc.com/4063544c31e9258a2a7eb37090bbc81f090259abaabb3f4e3fe79b25e317db59

Was this a reduced fee? would it have been cheaper if every output was bc1? how do you calculate this? it seems it was a 220kb/sat fee, currently according to this website, fee must be 460 for a smooth transaction:

https://bitcoinfees.earn.com/

I just don't know how to estimate how much is a segwit transaction saving compared to if it was a legacy transaction.

No. Only the address sent from needs to be Segwit (and bech32 is only 1 option, you can used nested Segwit if you need to pay someone not using a Segwit address)


There is no reduction in size, more space is allowed in blocks for segwit txs. For the nested (i.e. backwards compatible) address type, the transactions are slightly bigger than regular compressed key txs.

I see, but isn't bech32 to legacy possible? this is backwards compatibility, so what was the point of nested address?

Im asking because in that 22 output transaction there are coin sent to 1 legacy address so it seems to be working.

Very very interesting discussion. Few more questions:

• What if at one point in time we have zero nodes supporting SegWit? What happens to all the SegWit transactions completed before that point? If old-style nodes do not read beyond 1 MB, does this mean that all those SegWit transactions will be like they never existed?
• If I understand right, Electrum currently supports only bech32 addresses and these are not backward compatible with old addresses. Is there any desktop wallet that allows you to create nested SegWit addresses?

Thanks a lot!

I think that this is a highly theoretical question. There’s very close to zero probability that nodes would for some reason abandon SegWit.

Electrum gives you a choice of legacy or bech32. Also, when used with a hardware wallet, it generates nested SegWit addresses. I believe nested addresses can also be achieved by specifying a custom derivation path.

bech32 -> legacy = possible (but wallet software that isn't Segwit compatible may have problems decoding the address, and possibly spending the BTC too, don't try it)

legacy -> bech32 = not possible with wallets that don't support Segwit (Segwit wallets can do this though).


That's why nested Segwit is needed, people from non-Segwit wallet software can safely send and receive to & from Segwit addresses.