[bitcoin-dev] Bech32 weakness and impact on bip-taproot addresses

[Damian Mee]

> a new human-readable-prefix for length prefixed bitcoin witness
programs.  "btc1" anyone?

Yes, please!

On Fri, Nov 8, 2019 at 2:04 PM Russell O'Connor via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> I do like the idea of length prefixing the witness program.  I will note
> that the 1 byte witness version is really more like a 1 character witness
> version.  There are 17 different segwit versions and there are 32
> characters in the bech32 alphabet.  That leaves 15 unused characters that
> we can use for assigning new meanings too.
>
> That said, it is probably most sensible to define a new
> human-readable-prefix for length prefixed bitcoin witness programs.  "btc1"
> anyone?
>
> On Fri, Nov 8, 2019 at 12:12 AM ZmnSCPxj via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Good morning Pieter, and all,
>>
>> Can we modify Bech32 SegWit address format for version 1 and above as
>> below?
>>
>>       * The data-part values:
>>       ** 1 byte: the witness version
>>     + ** If the witness version is non-zero, 1 byte: the length of the
>> witness program.
>>       ** A conversion of the 2-to-40-byte witness program (as defined by [
>> https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki BIP141])
>> to base32:
>>       *** Start with the bits of the witness program, most significant
>> bit per byte first.
>>       *** Re-arrange those bits into groups of 5, and pad with zeroes at
>> the end if needed.
>>       *** Translate those bits to characters using the table above.
>>
>> This retains the ability of a bech32 address to specify any valid witness
>> length and allows future version 1 addresses with lengths other than 32,
>> while closing this malleation.
>>
>> Older software being given the modified v1 address format would mis-send
>> it to the wrong witness program, however.
>>
>> Alternately we could just keep using version 0 in the address format
>> forever.
>> The requirement would be to ensure that SegWit vN (N >= 1) output witness
>> programs would have a data-part value encoded as below:
>>
>>     * The data-part values:
>>     ** 1 byte: legacy witness version, which must always be 0.
>>     ** 1 byte: actual witness version, which must be non-zero.
>>     ** 1 byte: padding length: 0 or 1.
>>     ** If padding length is 1, 1 byte: padding, which must be 0.
>>     ** 1 byte: witness program length.
>>     ** variable: witness program.
>>
>> A writer for a v1 or later address would initially set an empty padding,
>> then compute:
>>
>>       1 // actual witness version
>>     + 1 // padding length
>>     + 1 // witness length
>>     + witness_length
>>
>> If the above sum is 20 or 32, then the writer selects a non-zero padding
>> and inserts the padding byte so that the above sum is now 21 or 33.
>>
>> To a reader that understands only bech32 v0, such an encoding would look
>> like a SegWit v0 invalid-program-length, and be rejected.
>> A reader which understands the above protocol would, instead of rejecting
>> a SegWit v0 invalid-program-length, instead attempt to parse it as above
>> first, and consider it as SegWit v1 or higher if it was parsed correctly as
>> above.
>>
>> The above proposal is of course ridiculous and I am now currently running
>> diagnostics on my processing units to see if further glitches occur in test
>> reasoning skills.
>>
>> Regards,
>> ZmnSCPxj
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191108/e3ee321a/attachment.html>