Topic: Why Segwit adoption is so slow? (Read 1948 times)

It's about getting the software integrated in existing workflows.

I'm confident as more and more people see the benefit and realizes how cheap SegWit transaction are we should see more adoption.

Mainly because people who do not support segwit and strongly opposed it exists.  Another reason is that even if there is a segwit some would not implement it and we can't just go and tell them to do so.  Many people sees segwit very beneficial especially for faster transactions but of course not all people have same way if thinking and accepting.

I think that many hoped for the emergence of Segwit2 and its use. Now, when it was canceled, will begin to integrate with Segwit. It is strange that many wallet providers have not used it, most likely reason not only technically, but also commercial.

I wouldn't say it's because of lack of wallet support. I know electrum has done it's part and we can update our wallet and use segwit if we want, so in part it's our fault. If I'm not mistaken Trezor and Ledger already support segwit, so we actually have the option to use segwit in either hardware wallets or desktop wallets if we want to. Of course that the big action around bitcoin is still in exchanges, so the other big problem is lack of exchanges support, and I actually think this is the major problem in segwit support. Why is it taking so long? I really don't know, some devs say they want to test it further, before they allow users to use it.

If you want to create segwit ouptuts or move funds to electrum 3.0 (the only wallet that I know support native segwit adresses), I just released segwit native P2WPKH on my demo wallet website bitcoinscri.pt
bitcoinscri.pt requires login with you twitter account.
It will allow you to create your own Bech32-encoded address then send funds to it.
Bitcoinscri.pt will have you first send to the corresponding P2PKH address using your mobile wallet then allow you to send the funds to the native P2WPKH.

It's clumsy but I don't know of any blockchain API nor explorer that fully support segwit addresses .

Slightly bigger (approximately 5%)

https://blockchain.info/charts/avg-block-size

Where can i find the average size of the block of the bitcoin network? is the average size now bigger after segwit's activation?

Just due to the contradiction between big exchanges and wallet's service providers, nothing else.


This is accurate i was searching for this reply in the thread,  Segwit is already activated and the block size is 4MB but many of users are still in a doubt of 2MB block size because they didn't know completely about segwit fork although it was discussed many times throughout the forum and on other social platforms.

Thank you for all your answers. But could someone please explain this "like I'm 4?". It almost understood it from the above post. Close close. Go.

Before, only one aspect of a transaction determined how large a block could be: it's size in bytes.

Now that Segwit is activated, there are two components: the size of the inputs + outputs, and the size of the signature. Inputs/outputs are the information that says "I'm paying this money from this address to that or those address/es". The signature is the part that proves you've got the right (i.e. the private keys) to pay.


Inputs & outputs can only use the 1MB of block space that Bitcoin previously had, they are "weighed" differently to signatures. Signatures are weighed at 1/4 of inputs & outputs (sometimes referred to as the "witness discount"), and so they can use a total maximum of 4MB of block space (but they've got to sign some inputs, it's not possible for a block to contain only signatures signing nothing).

Typically, this will mean each block will be about 1MB of transactions and 1MB of signatures (because the average transaction is roughly one half input/output data and the other half signature data). That's means typically we'll have 2MB blocks (apparently it's more like 2.1MB). But increasing use of transactions with multi-sig (needed for Lightning and other future innovations) that increase average signature size will change the balance between in/outs and signatures, and blocks would get closer to using the 4MB total that is allowed.

Thanks. But the Jimmy Song's blog lost me in the part when he starts explaining "Block Weight". Is there another way for someone to explain this "like I am 5"? I am not a very technical person but I really want to learn everything about Bitcoin.

I've just upgraded to 0.15.1, and I held off whilst I waited for the dust to settle. I wish I had upgraded sooner. I run a full node to maintain my wallet, and it is only online a couple of times a day at most. The new core is faster and more efficient, and that is important for me, as I tend to have connections of variable quality.

You could. But I referred to both forks in terms of their maximum block weight:


I only used the expression blocksize so as to keep it simple; my intention was to highlight a confused set of posts, and present a very short & basic correction.

SegWit has a maximum block weight of 4MB.  This is not comparable to having a maximum block size of 4MB.  SegWit also cannot, in practice, reach four times the capacity that the legacy network had, even if all users were sending SegWit transactions.  

You could refer to the SegWit2x fork's alteration as increasing the base block size to 2MB.
To understand SegWit's effective capacity, try reading through this article.

It depends on the transaction size. For a typical, transaction with 1 input and 2 outputs (you have a coin, pay someone and get a change), the legacy virtual size is 225/226 bytes, so 10^6/226=4424 transactions. The same P2SH-P2WPKH segwit transaction is 166 virtual bytes, so 10^6/166=6024 transactions and for pure P2WPKH, the size is 141 vbytes, so 7092 transactions.

The blockchain is filled also with larger transaction (many inputs or multisignatures), so the number of transaction in the typical block is less but the saving are even better with multi inputs. Segwit saves most for multi input transactions, savings are minimal for multi output transactions.


Segwit transaction go to the same pool. But since they are effectively smaller (actually they are not but witness data goes to a different space that is larger than 1MB but one can operate on virtual size for which they are smaller), their fee per byte is larger if they pay the same fee. So they are ahead of the same legacy transactions paying the same fee. Or you can lower the fee and have the same probability of inclusion in the block as the legacy but with a smaller fee. Or choose any intermediate fee.

Not a SegWit expert here, so I figured I would just ask. Does SegWit tx go to a separate MemPool or does all txs go to the same MemPool? The SegWit transactions are a lot cheaper than the old legacy during the same time when the MemPool are congested or are they going to the same MemPool, but just handled differently?

Hope that makes sense. I have to brush up on my SegWit research, but time is always an issue. ^lol^

Really? Tell that to Mr. Mempool and Mrs. Unconfirmed transactions, https://blockchain.info/charts/mempool-size, https://blockchain.info/charts/mempool-count.

We need Segwit for transactions to be confirmed faster and remain cheap at the same time, plus it also might maintain the no. of unconfirmed transaction below 10,000.

Does anyone know how many transactions would fit in a full block under Segwit?

The big picture. Bitcoin adoption in general is way slower than Segwit adoption.

Demand is not that big.

This is a very confused sounding exchange of posts, neither of you are getting the details correct.


There are (were) 2 entirely different proposals:

• Segwit (4MB blocks)
• Segwit2x (8MB blocks)

Segwit was a soft fork, and is now activated on the Bitcoin network. Segwit2x was hard fork, and was abandoned by it's developers and the miners who agreed to implement it.


This makes talk of 2MB blocks (finally) irrelevant; the max blocksize is now twice that at 4MB.

I believe the majority is holding their BTC because their value is growing over time.
When the prise will be more stabilised in the future, the people is going to use it more and more as a currency and will adopt the segwit.

There are no segwit blocks. And no, we don't have 2MB blocks.
You are talking about the SegWit2x fork which should have happened a week ago. (The 2x stands for 2 times blocksize (2MB))
Bitcoin already adopted to SegWit address formats, to make transactions smaller (Which leads to lower fees per TX, since fees are calculated in sat/B).
But there hasn't been an adoption to 2MB blocks. And thats good. On-chain scaling is no solution.

@OP: There isn't a good reason to delay the SegWit adoption. But as its with everything.. people don't like changing habits.
Look at IPv6 vs. IPv4 for example.. IPv6 is available for years now.. But 80%+ in Europe/USA are still using IPv4.. Just because they are used to it.

To my very limited unterstanding, mining difficulty is not affected by segwit.. only block size. Because you can fit in more Segwit transaction to a block, there is incentive for miners to include as many Segwit transfers in a block as possible, and this causes Segwit transactions to go trough faster. . If I've understood correctly

Main difference is that Sigwit block size is 2MB as  a result difficulty level for mining it is easy and hence transactions are fast. But people are lame at seeing there own benefit. People who just want to  use crypto-currency for transaction then sigwit is best option for them but people who only want to deal in crypto-currency for investment purpose then it will take a while before they will go for sigwit.

It is interesting, that at first Segwit adoption took of really well, then it stalled and now it has plateaued to approximately 10% level

http://segwit.party/charts/#

Indeed, fuckwits will remain fuckwits and people with other agendas will continue to push them however they can.

I think that's a reasonable stance. However, I've been noticing that Tony Gallippi (Bitpay) continues to heavily troll about Bitcoin transaction fees. Here's one from four days ago:


It's not even accurate either. I made multiple transactions right around that time and paid < $10 per transaction, and that was from a non-Segwit wallet.

To knowledgeable users, it looks like a combination of Copay having terrible fee estimation, not implementing Segwit, and misrepresenting the situation. But to new users, his concerns might look legitimate and even ring true. I really think that Bitpay is going to continue this war. I think they are more interested in implementing Bitcoin Cash and pushing users to use it than they are in implementing Segwit.

It's because a lot users still don't use wallets that have Segwit integrated, including me.
If you want to support Segwit, then change to a wallet that has Segwit support for example core.
I am going to switch my funds to a Segwit wallet when the tx fees begin to drop.

I suspect a lot of services were holding off directing resources towards segwit adoption because they were preparing for the 2x fork. Now that that has been cancelled, there is really no reason for them to delay any more and it will probably come more rapidly.

Thank you for your answer. It is strange, that big service providers are so slow to implement this, all thought it would help their customers.

Yes, and services which cover fees for their customers and want customers to be happy would want to have transactions that have lower transaction fees.

^Segwit transfers are faster and cheaper? So wallets’ users would benefit?

It's likely because large services like Coinbase, Bitpay, and Blockchain.info have not yet implemented segwit.

Yes.

For services, yes. It will cost them and their users less in fees. For other wallet software developers, the incentive is to avoid technical debt and have the latest and greatest.

Why Segwit adoption is so slow? Is it because of lack of wallet support? Are there incentives for wallet developers to implement Segwit?