My Segwit questions - a Q&A for Achow and the rest

[Wind_FURY]

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

[DooMAD]

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.

[cellard]

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.

[Carlton Banks]

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)

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)

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

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.

[cellard]

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)

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)

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

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.

[superbotolo]

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!

[Matias]

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?

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

[codewench]

• 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?

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.

[Carlton Banks]

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.

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.