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

Carlton Banks

legendary

Activity: 3430

Merit: 3080

Quote from: cellard on January 19, 2018, 07:25:42 PM

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.

codewench

member

Activity: 93

Merit: 39

Quote from: superbotolo on January 20, 2018, 01:22:47 AM

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.

Matias

full member

Activity: 182

Merit: 101

Quote from: superbotolo on January 20, 2018, 01:22:47 AM

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.

superbotolo

jr. member

Activity: 56

Merit: 5

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!

cellard

legendary

Activity: 1372

Merit: 1252

Quote from: Carlton Banks on January 18, 2018, 04:23:08 PM

Quote from: cellard on January 18, 2018, 01:58:42 PM

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)

Quote from: cellard on January 18, 2018, 01:58:42 PM

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.

Carlton Banks

legendary

Activity: 3430

Merit: 3080

Quote from: cellard on January 18, 2018, 01:58:42 PM

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)

Quote from: cellard on January 18, 2018, 01:58:42 PM

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

legendary

Activity: 1372

Merit: 1252

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.

DooMAD

legendary

Activity: 3948

Merit: 3191

Leave no FUD unchallenged

Quote from: Wind_FURY on January 03, 2018, 01:04:10 AM

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.

Wind_FURY

legendary

Activity: 2898

Merit: 1823

Quote from: DooMAD on January 02, 2018, 06:52:05 PM

Quote from: zoloq33 on January 02, 2018, 05:23:25 PM

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

legendary

Activity: 3948

Merit: 3191

Leave no FUD unchallenged

Quote from: zoloq33 on January 02, 2018, 05:23:25 PM

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.

zoloq33

newbie

Activity: 44

Merit: 0

Quote from: achow101 on January 02, 2018, 02:43:54 PM

Quote from: zoloq33 on January 02, 2018, 09:48:59 AM

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.

achow101

staff

Activity: 3458

Merit: 6793

Just writing some code

Quote from: zoloq33 on January 02, 2018, 09:48:59 AM

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.

zoloq33

newbie

Activity: 44

Merit: 0

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

Carlton Banks

legendary

Activity: 3430

Merit: 3080

Quote from: Wind_FURY on January 02, 2018, 12:22:27 AM

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.

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

DooMAD

legendary

Activity: 3948

Merit: 3191

Leave no FUD unchallenged

Quote from: Wind_FURY on January 02, 2018, 12:22:27 AM

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?

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.

Wind_FURY

legendary

Activity: 2898

Merit: 1823

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.

achow101

staff

Activity: 3458

Merit: 6793

Just writing some code

Quote from: Valle on December 20, 2017, 10:52:34 AM

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.

Valle

full member

Activity: 177

Merit: 101

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

DooMAD

legendary

Activity: 3948

Merit: 3191

Leave no FUD unchallenged

Quote from: Matias on December 20, 2017, 03:29:54 AM

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.

Matias

full member

Activity: 182

Merit: 101

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?

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