From: Damian Mee <btc@meedamian•com>
To: "Russell O'Connor" <roconnor@blockstream•io>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Bech32 weakness and impact on bip-taproot addresses
Date: Fri, 8 Nov 2019 14:42:13 +0100 [thread overview]
Message-ID: <CANeGfAeOK3bC+NkAtYaT-6XVmi8_200rU_=Jv7OszEGdkXN85g@mail.gmail.com> (raw)
In-Reply-To: <CAMZUoK=QFPAzZzxFOA6ZYez_dwCTi_OxYup19w32suDvBdXJoQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3765 bytes --]
> 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@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@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@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 5026 bytes --]
prev parent reply other threads:[~2019-11-08 13:42 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-07 22:35 Pieter Wuille
2019-11-07 22:45 ` Greg Sanders
2019-11-08 0:41 ` Matt Corallo
2019-11-08 2:15 ` David A. Harding
2019-11-08 3:15 ` Eric Voskuil
2019-11-10 21:51 ` Pieter Wuille
2019-11-11 1:02 ` Matt Corallo
2019-11-13 2:56 ` Clark Moody
2019-11-13 5:32 ` ZmnSCPxj
2019-11-13 6:30 ` Pieter Wuille
2020-07-15 20:56 ` Russell O'Connor
2020-07-15 21:05 ` Greg Sanders
2020-07-15 21:11 ` Russell O'Connor
2019-11-08 5:11 ` ZmnSCPxj
2019-11-08 13:03 ` Russell O'Connor
2019-11-08 13:42 ` Damian Mee [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CANeGfAeOK3bC+NkAtYaT-6XVmi8_200rU_=Jv7OszEGdkXN85g@mail.gmail.com' \
--to=btc@meedamian$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=roconnor@blockstream$(echo .)io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox