Topic: My Segwit questions - a Q&A for Achow and the rest - page 2. (Read 1212 times)

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.

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.

Awesome right back at you!  Core provides a concise technical overview 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.

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 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 itself contains a list of implementations, including the Python reference implementation.  (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 (as to the 49, the “purpose”) and BIP 44 (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 (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.

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! I'll try to implement SegWit in my client.

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

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.

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?

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

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.

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.

{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}

Blocks are not limited to 1MB.  There is no longer any such concept as a block size limit.  Read upthread.

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

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

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

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?

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

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.

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.