Discussion:
Clarification about SegWit transaction size and bech32
(too old to reply)
Alberto De Luigi via bitcoin-dev
2017-12-18 16:40:08 UTC
Permalink
Raw Message
Hello guys,

I have a few questions about the SegWit tx size, I'd like to have
confirmation about the following statements. Can you correct mistakes or
inaccuracies? Thank you in advance.



In general, SegWit tx costs more than legacy tx (source
https://bitcoincore.org/en/2016/10/28/segwit-costs/):



* Compared to P2PKH, P2WPKH uses 3 fewer bytes (-1%) in the
scriptPubKey, and the same number of witness bytes as P2PKH scriptSig.
* Compared to P2SH, P2WSH uses 11 additional bytes (6%) in the
scriptPubKey, and the same number of witness bytes as P2SH scriptSig.
* Compared to P2PKH, P2WPKH/P2SH uses 21 additional bytes (11%), due
to using 24 bytes in scriptPubKey, 3 fewer bytes in scriptSig than in P2PKH
scriptPubKey, and the same number of witness bytes as P2PKH scriptSig.
* Compared to P2SH, P2WSH/P2SH uses 35 additional bytes (19%), due to
using 24 bytes in scriptPubKey, 11 additional bytes in scriptSig compared to
P2SH scriptPubKey, and the same number of witness bytes as P2SH scriptSig.



But still it is convenient to adopt segwit because you move the bytes to the
blockweight part, paying smaller fee. In general, a tx with 1 input and 1
output is about 190kb. If it's a Segwit tx, 82kb in the non-witness part
(blocksize), 108 in the witness part (blockweight).

See source:

4 bytes version

1 byte input count

Input

36 bytes outpoint

1 byte scriptSigLen (0x00)

0 bytes scriptSig

4 bytes sequence

1 byte output count

8 bytes value

1 byte scriptPubKeyLen

22 bytes scriptPubKey (0x0014{20-byte keyhash})

4 bytes locktime

https://bitcoin.stackexchange.com/questions/59408/with-100-segwit-transactio
ns-what-would-be-the-max-number-of-transaction-confi



Which means, if you fill a block entirely with this kind of tx, you can
approximately double the capacity of the blockchain (blocksize capped to
1mb, blockweight a little bit more than 2mb)



My concern is about segwit adoption by the exchanges.

SegWit transactions cost 10bytes more than legacy transactions for each
output (vout is 256 bits instead of 160). Exchanges aggregate tx adding many
outputs, which is of course something good for bitcoin scalability, since
this way we save space and pay less fees.

But when a tx has at least 10 outputs, using segwit you don't save space,
instead:

- the total blockweight is at least 100bytes higher (10bytes x 10 outputs),
so the blockchain is heavier

- you don't save space inside the blocksize, so you cannot validate more
transactions of this kind (with many outputs), nor get cheaper fee

- without cheaper fees exchanges have no incentives for segwit adoption
before they decide to adopt LN



In general we can say that using SegWit:

- you decrease the fee only for some specific kind of transactions, and just
because you move some bytes to the blockweight

- you don't save space in the blockchain, on the contrary the total weight
of the blockchain increases (so it's clear to me why some time ago Luke
tweeted to not use SegWit unless really necessary... but then it's not clear
why so much haste in promoting BIP148 the 1st august risking a split)



If it's all correct, does something change with bech32? I'm reading bech32
allows to save about 22% of the space. Is this true for whatever kind of tx?
Immediate benefits of segwit for scalability are only with bech32?



Bech32 is non-compatible with the entire ecosystem (you cannot receive coins
from the quasi-totality of wallets in circulation), I would say it is a hard
fork. But the bare segwit is really so different? the soft fork is "soft"
for the reference client Bitcoin Core, but outside you cannot know what
happens, there are plenty of implementations (especially frontend
customization) which don't work with segwit and need to upgrade. To upgrade
takes a lot of time, especially when services are so crowded and so many new
people want to step in. At this point, if bech32 brings only efficiency (but
correct me if it's not so) and it is well planned, it could be a consensual
upgrade, maybe together with a 2x blocksize? Is there a specific plan for
some upgrade in 2018? I personally think it is far easier to reach consensus
on a blocksize increase una tantum rather than a dynamic increase. You
cannot predict the technology growth: will it be linear, exponential, or
suddenly stop for a while, maybe right before a huge innovation? I think a
hard fork bech32 upgrade + 2x could help a lot in scalability while we test
LN, and it might be the only way to effectively promote (or should I say
enforce?) SegWit adoption.



thank you,

Alberto De Luigi

(.com)
Mark Friedenbach via bitcoin-dev
2017-12-18 17:38:01 UTC
Permalink
Raw Message
Addresses are entirely a user-interface issue. They don’t factor into the bitcoin protocol at all.

The bitcoin protocol doesn’t have addresses. It has a generic programmable signature framework called script. Addresses are merely a UI convention for representing common script templates. 1.. addresses and 3
 addresses have script templates that are not as optimal as could be constructed with post-segwit assumptions. The newer bech32 address just uses a different underlying template that achieves better security guarantees (for pay-to-script) or lower fees (for pay-to-pubkey-hash). But this is really a UI/UX issue.

A “fork” in bitcoin-like consensus systems has a very specific meaning. Changing address formats is not a fork, soft or hard.

There are many benefits to segregated witness. You may find this page helpful:

https://bitcoincore.org/en/2016/01/26/segwit-benefits/ <https://bitcoincore.org/en/2016/01/26/segwit-benefits/>
Post by Alberto De Luigi via bitcoin-dev
Hello guys,
I have a few questions about the SegWit tx size, I'd like to have confirmation about the following statements. Can you correct mistakes or inaccuracies? Thank you in advance.
Compared to P2PKH, P2WPKH uses 3 fewer bytes (-1%) in the scriptPubKey, and the same number of witness bytes as P2PKH scriptSig.
Compared to P2SH, P2WSH uses 11 additional bytes (6%) in the scriptPubKey, and the same number of witness bytes as P2SH scriptSig.
Compared to P2PKH, P2WPKH/P2SH uses 21 additional bytes (11%), due to using 24 bytes in scriptPubKey, 3 fewer bytes in scriptSig than in P2PKH scriptPubKey, and the same number of witness bytes as P2PKH scriptSig.
Compared to P2SH, P2WSH/P2SH uses 35 additional bytes (19%), due to using 24 bytes in scriptPubKey, 11 additional bytes in scriptSig compared to P2SH scriptPubKey, and the same number of witness bytes as P2SH scriptSig.
But still it is convenient to adopt segwit because you move the bytes to the blockweight part, paying smaller fee. In general, a tx with 1 input and 1 output is about 190kb. If it's a Segwit tx, 82kb in the non-witness part (blocksize), 108 in the witness part (blockweight).
4 bytes version
1 byte input count
Input
36 bytes outpoint
1 byte scriptSigLen (0x00)
0 bytes scriptSig
4 bytes sequence
1 byte output count
8 bytes value
1 byte scriptPubKeyLen
22 bytes scriptPubKey (0x0014{20-byte keyhash})
4 bytes locktime
https://bitcoin.stackexchange.com/questions/59408/with-100-segwit-transactions-what-would-be-the-max-number-of-transaction-confi <https://bitcoin.stackexchange.com/questions/59408/with-100-segwit-transactions-what-would-be-the-max-number-of-transaction-confi>
Which means, if you fill a block entirely with this kind of tx, you can approximately double the capacity of the blockchain (blocksize capped to 1mb, blockweight a little bit more than 2mb)
My concern is about segwit adoption by the exchanges.
SegWit transactions cost 10bytes more than legacy transactions for each output (vout is 256 bits instead of 160). Exchanges aggregate tx adding many outputs, which is of course something good for bitcoin scalability, since this way we save space and pay less fees.
- the total blockweight is at least 100bytes higher (10bytes x 10 outputs), so the blockchain is heavier
- you don't save space inside the blocksize, so you cannot validate more transactions of this kind (with many outputs), nor get cheaper fee
- without cheaper fees exchanges have no incentives for segwit adoption before they decide to adopt LN
- you decrease the fee only for some specific kind of transactions, and just because you move some bytes to the blockweight
- you don’t save space in the blockchain, on the contrary the total weight of the blockchain increases (so it's clear to me why some time ago Luke tweeted to not use SegWit unless really necessary... but then it's not clear why so much haste in promoting BIP148 the 1st august risking a split)
If it's all correct, does something change with bech32? I'm reading bech32 allows to save about 22% of the space. Is this true for whatever kind of tx? Immediate benefits of segwit for scalability are only with bech32?
Bech32 is non-compatible with the entire ecosystem (you cannot receive coins from the quasi-totality of wallets in circulation), I would say it is a hard fork. But the bare segwit is really so different? the soft fork is "soft" for the reference client Bitcoin Core, but outside you cannot know what happens, there are plenty of implementations (especially frontend customization) which don’t work with segwit and need to upgrade. To upgrade takes a lot of time, especially when services are so crowded and so many new people want to step in. At this point, if bech32 brings only efficiency (but correct me if it’s not so) and it is well planned, it could be a consensual upgrade, maybe together with a 2x blocksize? Is there a specific plan for some upgrade in 2018? I personally think it is far easier to reach consensus on a blocksize increase una tantum rather than a dynamic increase. You cannot predict the technology growth: will it be linear, exponential, or suddenly stop for a while, maybe right before a huge innovation? I think a hard fork bech32 upgrade + 2x could help a lot in scalability while we test LN, and it might be the only way to effectively promote (or should I say enforce?) SegWit adoption.
thank you,
Alberto De Luigi
(.com)
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
Mark Friedenbach via bitcoin-dev
2017-12-18 22:03:44 UTC
Permalink
Raw Message
Why would I send you coins to anything other than the address you provided to me? If you send me a bech32 address I use the native segwit scripts. If you send me an old address, I do what it specifies instead. The recipient has control over what type of script the payment is sent to, without any ambiguity.
Hi Mark,
thank you. I understand your point, but despite what we define as a fork, when a software uses a particular address, it becomes part of the rules of that software. If another software doesn't recognize that address as a bitcoin address, then the rules it enforces aren't compatible with the behaviour of the first software. If you send me your bitcoins, I can't receive it, exactly like if it was in another chain. This happens even if there isn't such a situation where miners verify that transaction on a chain, while other miners reject it.
If we want to change the addresses, we need consensus and the coordinate upgrade of the entire network. In case we haven't consensus, most of the clients cannot send and receive bitcoins, which is a huge problem.
For this reason I think it is something we should discuss in order to make a coordinated upgrade, exactly like what we do when we propose a fork. And it would be better to do it precisely as a part of a fork, like a 2x (or whatever other upgrade gaining enough consensus)
Apart from the proposal of an upgrade to bench32, do you agree with the rest of my points? I know segwit is valuable because it fixes tx malleability and so on... thank you for your link, but that wasn't the point I wanted to highlight!
Thank you,
Alberto
Addresses are entirely a user-interface issue. They don’t factor
into the bitcoin protocol at all.
The bitcoin protocol doesn’t have addresses. It has a generic
programmable signature framework called script. Addresses are merely a
UI convention for representing common script templates. 1.. addresses
and 3… addresses have script templates that are not as optimal as
could be constructed with post-segwit assumptions. The newer bech32
address just uses a different underlying template that achieves better
security guarantees (for pay-to-script) or lower fees (for
pay-to-pubkey-hash). But this is really a UI/UX issue.
A “fork” in bitcoin-like consensus systems has a very specific
meaning. Changing address formats is not a fork, soft or hard.
https://bitcoincore.org/en/2016/01/26/segwit-benefits/ [4]
On Dec 18, 2017, at 8:40 AM, Alberto De Luigi via bitcoin-dev
Hello guys,
I have a few questions about the SegWit tx size, I'd like to have
confirmation about the following statements. Can you correct
mistakes or inaccuracies? Thank you in advance.
In general, SegWit tx costs more than legacy tx (source
* Compared to P2PKH, P2WPKH uses 3 fewer bytes (-1%) in the
scriptPubKey, and the same number of witness bytes as P2PKH
scriptSig.
* Compared to P2SH, P2WSH uses 11 additional bytes (6%) in the
scriptPubKey, and the same number of witness bytes as P2SH
scriptSig.
* Compared to P2PKH, P2WPKH/P2SH uses 21 additional bytes (11%),
due to using 24 bytes in scriptPubKey, 3 fewer bytes in scriptSig
than in P2PKH scriptPubKey, and the same number of witness bytes as
P2PKH scriptSig.
* Compared to P2SH, P2WSH/P2SH uses 35 additional bytes (19%), due
to using 24 bytes in scriptPubKey, 11 additional bytes in scriptSig
compared to P2SH scriptPubKey, and the same number of witness bytes
as P2SH scriptSig.
But still it is convenient to adopt segwit because you move the
bytes to the blockweight part, paying smaller fee. In general, a tx
with 1 input and 1 output is about 190kb. If it's a Segwit tx, 82kb
in the non-witness part (blocksize), 108 in the witness part
(blockweight).
4 bytes version
1 byte input count
Input
36 bytes outpoint
1 byte scriptSigLen (0x00)
0 bytes scriptSig
4 bytes sequence
1 byte output count
8 bytes value
1 byte scriptPubKeyLen
22 bytes scriptPubKey (0x0014{20-byte keyhash})
4 bytes locktime
https://bitcoin.stackexchange.com/questions/59408/with-100-segwit-transactions-what-would-be-the-max-number-of-transaction-confi
[2]
Which means, if you fill a block entirely with this kind of tx, you
can approximately double the capacity of the blockchain (blocksize
capped to 1mb, blockweight a little bit more than 2mb)
My concern is about segwit adoption by the exchanges.
SegWit transactions cost 10bytes more than legacy transactions for
each output (vout is 256 bits instead of 160). Exchanges aggregate
tx adding many outputs, which is of course something good for
bitcoin scalability, since this way we save space and pay less fees.
- the total blockweight is at least 100bytes higher (10bytes x 10
outputs), so the blockchain is heavier
- you don't save space inside the blocksize, so you cannot validate
more transactions of this kind (with many outputs), nor get cheaper
fee
- without cheaper fees exchanges have no incentives for segwit
adoption before they decide to adopt LN
- you decrease the fee only for some specific kind of transactions,
and just because you move some bytes to the blockweight
- you don’t save space in the blockchain, on the contrary the
total weight of the blockchain increases (so it's clear to me why
some time ago Luke tweeted to not use SegWit unless really
necessary... but then it's not clear why so much haste in promoting
BIP148 the 1st august risking a split)
If it's all correct, does something change with bech32? I'm reading
bech32 allows to save about 22% of the space. Is this true for
whatever kind of tx? Immediate benefits of segwit for scalability
are only with bech32?
Bech32 is non-compatible with the entire ecosystem (you cannot
receive coins from the quasi-totality of wallets in circulation), I
would say it is a hard fork. But the bare segwit is really so
different? the soft fork is "soft" for the reference client Bitcoin
Core, but outside you cannot know what happens, there are plenty of
implementations (especially frontend customization) which don’t
work with segwit and need to upgrade. To upgrade takes a lot of
time, especially when services are so crowded and so many new people
want to step in. At this point, if bech32 brings only efficiency
(but correct me if it’s not so) and it is well planned, it could
be a consensual upgrade, maybe together with a 2x blocksize? Is
there a specific plan for some upgrade in 2018? I personally think
it is far easier to reach consensus on a blocksize increase una
tantum rather than a dynamic increase. You cannot predict the
technology growth: will it be linear, exponential, or suddenly stop
for a while, maybe right before a huge innovation? I think a hard
fork bech32 upgrade + 2x could help a lot in scalability while we
test LN, and it might be the only way to effectively promote (or
should I say enforce?) SegWit adoption.
thank you,
Alberto De Luigi
(.com)_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [3]
------
[1] https://bitcoincore.org/en/2016/10/28/segwit-costs/
[2]
https://bitcoin.stackexchange.com/questions/59408/with-100-segwit-transactions-what-would-be-the-max-number-of-transaction-confi
[3] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[4] https://bitcoincore.org/en/2016/01/26/segwit-benefits/
Alberto De Luigi via bitcoin-dev
2017-12-18 22:19:34 UTC
Permalink
Raw Message
Mark,
suppose I am an average user. Give me a bech32 address and ask me to
send a few coins there. I am 100% sure you will never receive my coins.
I will call you back saying: "Mark, sorry, I tried with three different
wallets, but it seems what you gave me is not a bitcoin address!"

My point is: we want SegWit is used and implemented more and more by the
community. But if besides malleability fix, the main effect of sw
adoption is this:

1) The blockahin is heavier (transactions require more space)
2) the fee is smaller only for some kind of tx
3) the transactions of the exchanges, which aggregate outputs, would be
heavier and pay a higher fee using segwit!

then how can we expect people, exchanges and services to adopt segwit?

Thank you,
Alberto De Luigi
Post by Mark Friedenbach via bitcoin-dev
Why would I send you coins to anything other than the address you
provided to me? If you send me a bech32 address I use the native
segwit scripts. If you send me an old address, I do what it specifies
instead. The recipient has control over what type of script the
payment is sent to, without any ambiguity.
Hi Mark,
thank you. I understand your point, but despite what we define as a
fork, when a software uses a particular address, it becomes part of
the rules of that software. If another software doesn't recognize that
address as a bitcoin address, then the rules it enforces aren't
compatible with the behaviour of the first software. If you send me
your bitcoins, I can't receive it, exactly like if it was in another
chain. This happens even if there isn't such a situation where miners
verify that transaction on a chain, while other miners reject it.
If we want to change the addresses, we need consensus and the
coordinate upgrade of the entire network. In case we haven't
consensus, most of the clients cannot send and receive bitcoins, which
is a huge problem.
For this reason I think it is something we should discuss in order to
make a coordinated upgrade, exactly like what we do when we propose a
fork. And it would be better to do it precisely as a part of a fork,
like a 2x (or whatever other upgrade gaining enough consensus)
Apart from the proposal of an upgrade to bench32, do you agree with
the rest of my points? I know segwit is valuable because it fixes tx
malleability and so on... thank you for your link, but that wasn't the
point I wanted to highlight!
Thank you,
Alberto
Addresses are entirely a user-interface issue. They don’t factor
into the bitcoin protocol at all.
The bitcoin protocol doesn’t have addresses. It has a generic
programmable signature framework called script. Addresses are merely a
UI convention for representing common script templates. 1.. addresses
and 3… addresses have script templates that are not as optimal as
could be constructed with post-segwit assumptions. The newer bech32
address just uses a different underlying template that achieves better
security guarantees (for pay-to-script) or lower fees (for
pay-to-pubkey-hash). But this is really a UI/UX issue.
A “fork” in bitcoin-like consensus systems has a very specific
meaning. Changing address formats is not a fork, soft or hard.
https://bitcoincore.org/en/2016/01/26/segwit-benefits/ [4]
On Dec 18, 2017, at 8:40 AM, Alberto De Luigi via bitcoin-dev
Hello guys,
I have a few questions about the SegWit tx size, I'd like to have
confirmation about the following statements. Can you correct
mistakes or inaccuracies? Thank you in advance.
In general, SegWit tx costs more than legacy tx (source
* Compared to P2PKH, P2WPKH uses 3 fewer bytes (-1%) in the
scriptPubKey, and the same number of witness bytes as P2PKH
scriptSig.
* Compared to P2SH, P2WSH uses 11 additional bytes (6%) in the
scriptPubKey, and the same number of witness bytes as P2SH
scriptSig.
* Compared to P2PKH, P2WPKH/P2SH uses 21 additional bytes (11%),
due to using 24 bytes in scriptPubKey, 3 fewer bytes in scriptSig
than in P2PKH scriptPubKey, and the same number of witness bytes as
P2PKH scriptSig.
* Compared to P2SH, P2WSH/P2SH uses 35 additional bytes (19%), due
to using 24 bytes in scriptPubKey, 11 additional bytes in scriptSig
compared to P2SH scriptPubKey, and the same number of witness bytes
as P2SH scriptSig.
But still it is convenient to adopt segwit because you move the
bytes to the blockweight part, paying smaller fee. In general, a tx
with 1 input and 1 output is about 190kb. If it's a Segwit tx, 82kb
in the non-witness part (blocksize), 108 in the witness part
(blockweight).
4 bytes version
1 byte input count
Input
36 bytes outpoint
1 byte scriptSigLen (0x00)
0 bytes scriptSig
4 bytes sequence
1 byte output count
8 bytes value
1 byte scriptPubKeyLen
22 bytes scriptPubKey (0x0014{20-byte keyhash})
4 bytes locktime
https://bitcoin.stackexchange.com/questions/59408/with-100-segwit-transactions-what-would-be-the-max-number-of-transaction-confi
[2]
Which means, if you fill a block entirely with this kind of tx, you
can approximately double the capacity of the blockchain (blocksize
capped to 1mb, blockweight a little bit more than 2mb)
My concern is about segwit adoption by the exchanges.
SegWit transactions cost 10bytes more than legacy transactions for
each output (vout is 256 bits instead of 160). Exchanges aggregate
tx adding many outputs, which is of course something good for
bitcoin scalability, since this way we save space and pay less fees.
- the total blockweight is at least 100bytes higher (10bytes x 10
outputs), so the blockchain is heavier
- you don't save space inside the blocksize, so you cannot validate
more transactions of this kind (with many outputs), nor get cheaper
fee
- without cheaper fees exchanges have no incentives for segwit
adoption before they decide to adopt LN
- you decrease the fee only for some specific kind of transactions,
and just because you move some bytes to the blockweight
- you don’t save space in the blockchain, on the contrary the
total weight of the blockchain increases (so it's clear to me why
some time ago Luke tweeted to not use SegWit unless really
necessary... but then it's not clear why so much haste in promoting
BIP148 the 1st august risking a split)
If it's all correct, does something change with bech32? I'm reading
bech32 allows to save about 22% of the space. Is this true for
whatever kind of tx? Immediate benefits of segwit for scalability
are only with bech32?
Bech32 is non-compatible with the entire ecosystem (you cannot
receive coins from the quasi-totality of wallets in circulation), I
would say it is a hard fork. But the bare segwit is really so
different? the soft fork is "soft" for the reference client Bitcoin
Core, but outside you cannot know what happens, there are plenty of
implementations (especially frontend customization) which don’t
work with segwit and need to upgrade. To upgrade takes a lot of
time, especially when services are so crowded and so many new people
want to step in. At this point, if bech32 brings only efficiency
(but correct me if it’s not so) and it is well planned, it could
be a consensual upgrade, maybe together with a 2x blocksize? Is
there a specific plan for some upgrade in 2018? I personally think
it is far easier to reach consensus on a blocksize increase una
tantum rather than a dynamic increase. You cannot predict the
technology growth: will it be linear, exponential, or suddenly stop
for a while, maybe right before a huge innovation? I think a hard
fork bech32 upgrade + 2x could help a lot in scalability while we
test LN, and it might be the only way to effectively promote (or
should I say enforce?) SegWit adoption.
thank you,
Alberto De Luigi
(.com)_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [3]
------
[1] https://bitcoincore.org/en/2016/10/28/segwit-costs/
[2]
https://bitcoin.stackexchange.com/questions/59408/with-100-segwit-transactions-what-would-be-the-max-number-of-transaction-confi
[3] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[4] https://bitcoincore.org/en/2016/01/26/segwit-benefits/
Alberto De Luigi via bitcoin-dev
2017-12-19 13:45:09 UTC
Permalink
Raw Message
Thank you Gregory,
so SegWit P2PHK have strictly less weight than P2WPKH, 3 fewer bytes (-1%) no matter the n. of outputs.
Instead, Segwit P2WPKH/P2SH cost 11% more than P2PHK, while compared to P2SH, SegWit transaction P2WSH and P2WSH/P2SH cost respectively 6% and 19% more space. And it can be much more if outputs are, as you say, an absurd number, which is the case of tx made by an exchange.

I understand there is a rationale for the overhead size. It's transparent from here: https://bitcoincore.org/en/2016/01/26/segwit-benefits
I don't understand your two points, which are new to me, maybe I lack of some technical details?
1) outputs were previously undercosted
2) a great many TXOUTs are putting a serious long term cost on the network

But independently from that, my point is: does an exchange have economic incentives in adopting SegWit? I think the answer is no.
Does SegWit help making bitcoin more scalable? Not until Lightning Network, since transactions just take up more space.

Instead, if bech32 really makes possible to save up to 22% of space (I still need confirmation), it would help a lot in scaling bitcoin. We just need to coordinate the network to bring it on most of the wallets. Since using bech32 everybody will benefit and pay smaller fees there are economic incentives in implementing it. For this reason I think an agreement about a transition to bech32 as default address for every wallet is a highly realistic scenario, while widespread SegWit adoption without bech32 is not, in my opinion, because poor or negative economic incentives (including also the costs companies sustain for development).

I know an agreement is a political matter, should it be discussed elsewhere?
I think a network upgrade to bech32 addresses requires the same coordination of a hard fork, but.. just a hint: bech32 helps saving space, in the meanwhile we reach widespread segwit adoption. If transition is achieved, we would have blocks of 2mb fulfilled with transactions using bech32, which have a 20% discount. Compared to the current situation of 1.05mb average blocks and 400k tx daily, we could have about 2mb blocks and 960k tx daily...

Thank you,
Alberto De Luigi
(.com)



-----Original Message-----
From: Gregory Maxwell [mailto:***@gmail.com]
Sent: martedì 19 dicembre 2017 09:06
To: ***@albertodeluigi.com; Bitcoin Protocol Discussion
<bitcoin-***@lists.linuxfoundation.org>
Cc: Mark Friedenbach <***@friedenbach.org>
Subject: Re: [bitcoin-dev] Clarification about SegWit transaction size and
bech32

Alberto,

You are confused about the impact. Ordinary P2WPKH have strictly less
weight no matter how many outputs you have. P2WSH in very output heavy
transactions can be more, but this is inherent in the upgrade from
inadequate 80-bit security to 128-bit security, an intentional
change: because outputs were previously _radically_ undercosted in the
system and any party making a great many new TXOUTs are putting a serious
long term cost on the network, and in any case it's except for transactions
that make an absurd number of P2WSH outputs at once the difference is pretty
small.

On Mon, Dec 18, 2017 at 10:19 PM, Alberto De Luigi via bitcoin-dev
Post by Alberto De Luigi via bitcoin-dev
Mark,
suppose I am an average user. Give me a bech32 address and ask me to
send a few coins there. I am 100% sure you will never receive my
coins. I will call you back saying: "Mark, sorry, I tried with three
different wallets, but it seems what you gave me is not a bitcoin
address!"
My point is: we want SegWit is used and implemented more and more by
the community. But if besides malleability fix, the main effect of sw
1) The blockahin is heavier (transactions require more space)
2) the fee is smaller only for some kind of tx
3) the transactions of the exchanges, which aggregate outputs, would
be heavier and pay a higher fee using segwit!
then how can we expect people, exchanges and services to adopt segwit?
Thank you,
Alberto De Luigi
Post by Mark Friedenbach via bitcoin-dev
Why would I send you coins to anything other than the address you
provided to me? If you send me a bech32 address I use the native
segwit scripts. If you send me an old address, I do what it specifies
instead. The recipient has control over what type of script the
payment is sent to, without any ambiguity.
Hi Mark,
thank you. I understand your point, but despite what we define as a
fork, when a software uses a particular address, it becomes part of
the rules of that software. If another software doesn't recognize
that address as a bitcoin address, then the rules it enforces aren't
compatible with the behaviour of the first software. If you send me
your bitcoins, I can't receive it, exactly like if it was in another
chain. This happens even if there isn't such a situation where
miners verify that transaction on a chain, while other miners reject it.
If we want to change the addresses, we need consensus and the
coordinate upgrade of the entire network. In case we haven't
consensus, most of the clients cannot send and receive bitcoins, which
is a huge problem.
For this reason I think it is something we should discuss in order
to make a coordinated upgrade, exactly like what we do when we propose a
fork.
And it would be better to do it precisely as a part of a fork, like
a 2x (or whatever other upgrade gaining enough consensus)
Apart from the proposal of an upgrade to bench32, do you agree with
the rest of my points? I know segwit is valuable because it fixes tx
malleability and so on... thank you for your link, but that wasn't
the point I wanted to highlight!
Thank you,
Alberto
Addresses are entirely a user-interface issue. They don’t factor
into the bitcoin protocol at all.
The bitcoin protocol doesn’t have addresses. It has a generic
programmable signature framework called script. Addresses are
merely a UI convention for representing common script templates.
1.. addresses and 3… addresses have script templates that are not
as optimal as could be constructed with post-segwit assumptions.
The newer bech32 address just uses a different underlying template
that achieves better security guarantees (for pay-to-script) or
lower fees (for pay-to-pubkey-hash). But this is really a UI/UX issue.
A “fork” in bitcoin-like consensus systems has a very specific
meaning. Changing address formats is not a fork, soft or hard.
There are many benefits to segregated witness. You may find this
page
https://bitcoincore.org/en/2016/01/26/segwit-benefits/ [4]
On Dec 18, 2017, at 8:40 AM, Alberto De Luigi via bitcoin-dev
Hello guys,
I have a few questions about the SegWit tx size, I'd like to have
confirmation about the following statements. Can you correct
mistakes or inaccuracies? Thank you in advance.
In general, SegWit tx costs more than legacy tx (source
* Compared to P2PKH, P2WPKH uses 3 fewer bytes (-1%) in the
scriptPubKey, and the same number of witness bytes as P2PKH
scriptSig.
* Compared to P2SH, P2WSH uses 11 additional bytes (6%) in the
scriptPubKey, and the same number of witness bytes as P2SH
scriptSig.
* Compared to P2PKH, P2WPKH/P2SH uses 21 additional bytes (11%),
due to using 24 bytes in scriptPubKey, 3 fewer bytes in scriptSig
than in P2PKH scriptPubKey, and the same number of witness bytes
as P2PKH scriptSig.
* Compared to P2SH, P2WSH/P2SH uses 35 additional bytes (19%), due
to using 24 bytes in scriptPubKey, 11 additional bytes in
scriptSig compared to P2SH scriptPubKey, and the same number of
witness bytes as P2SH scriptSig.
But still it is convenient to adopt segwit because you move the
bytes to the blockweight part, paying smaller fee. In general, a
tx with 1 input and 1 output is about 190kb. If it's a Segwit tx,
82kb in the non-witness part (blocksize), 108 in the witness part
(blockweight).
4 bytes version
1 byte input count
Input
36 bytes outpoint
1 byte scriptSigLen (0x00)
0 bytes scriptSig
4 bytes sequence
1 byte output count
8 bytes value
1 byte scriptPubKeyLen
22 bytes scriptPubKey (0x0014{20-byte keyhash})
4 bytes locktime
https://bitcoin.stackexchange.com/questions/59408/with-100-segwit-t
ransactions-what-would-be-the-max-number-of-transaction-confi
[2]
Which means, if you fill a block entirely with this kind of tx,
you can approximately double the capacity of the blockchain
(blocksize capped to 1mb, blockweight a little bit more than 2mb)
My concern is about segwit adoption by the exchanges.
SegWit transactions cost 10bytes more than legacy transactions for
each output (vout is 256 bits instead of 160). Exchanges aggregate
tx adding many outputs, which is of course something good for
bitcoin scalability, since this way we save space and pay less fees.
But when a tx has at least 10 outputs, using segwit you don't save
- the total blockweight is at least 100bytes higher (10bytes x 10
outputs), so the blockchain is heavier
- you don't save space inside the blocksize, so you cannot
validate more transactions of this kind (with many outputs), nor
get cheaper fee
- without cheaper fees exchanges have no incentives for segwit
adoption before they decide to adopt LN In general we can say that
- you decrease the fee only for some specific kind of
transactions, and just because you move some bytes to the
blockweight
- you don’t save space in the blockchain, on the contrary the
total weight of the blockchain increases (so it's clear to me why
some time ago Luke tweeted to not use SegWit unless really
necessary... but then it's not clear why so much haste in
promoting
BIP148 the 1st august risking a split) If it's all correct, does
something change with bech32? I'm reading
bech32 allows to save about 22% of the space. Is this true for
whatever kind of tx? Immediate benefits of segwit for scalability
are only with bech32?
Bech32 is non-compatible with the entire ecosystem (you cannot
receive coins from the quasi-totality of wallets in circulation),
I would say it is a hard fork. But the bare segwit is really so
different? the soft fork is "soft" for the reference client
Bitcoin Core, but outside you cannot know what happens, there are
plenty of implementations (especially frontend customization)
which don’t work with segwit and need to upgrade. To upgrade takes
a lot of time, especially when services are so crowded and so many
new people want to step in. At this point, if bech32 brings only
efficiency (but correct me if it’s not so) and it is well planned,
it could be a consensual upgrade, maybe together with a 2x
blocksize? Is there a specific plan for some upgrade in 2018? I
personally think it is far easier to reach consensus on a
blocksize increase una tantum rather than a dynamic increase. You
cannot predict the technology growth: will it be linear,
exponential, or suddenly stop for a while, maybe right before a
huge innovation? I think a hard fork bech32 upgrade + 2x could
help a lot in scalability while we test LN, and it might be the
only way to effectively promote (or should I say enforce?) SegWit
adoption.
thank you,
Alberto De Luigi
(.com)_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [3]
------
[1] https://bitcoincore.org/en/2016/10/28/segwit-costs/
[2]
https://bitcoin.stackexchange.com/questions/59408/with-100-segwit-t
ransactions-what-would-be-the-max-number-of-transaction-confi
[3] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[4] https://bitcoincore.org/en/2016/01/26/segwit-benefits/
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Loading...