Topic: Why Segwit adoption is so slow? (Read 1937 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.