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.
> On Dec 18, 2017, at 1:41 PM, m...@albertodeluigi.com wrote: > > 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 > > > > > Il 2017-12-18 18:38 Mark Friedenbach ha scritto: >> 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/ [4] >>> On Dec 18, 2017, at 8:40 AM, Alberto De Luigi via bitcoin-dev >>> <bitcoin-dev@lists.linuxfoundation.org> wrote: >>> 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/ [1]): >>> * 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-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. >>> 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)_______________________________________________ >>> bitcoin-dev mailing list >>> bitcoin-dev@lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [3] >> Links: >> ------ >> [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/ > > _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
