The bold values are the witness program lengths and address lengths of the
segwit v0 programs (BIP-141), which clearly need to be covered in my
proposed amendment. 32 bytes is also the proposed witness program length
for segwit v1 that would correspond to a taproot (BIP-341) program.
On Wed, Jul
Can you make it clear what the bold vs not-bold numbers mean?
On Wed, Jul 15, 2020 at 4:56 PM Russell O'Connor via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Wed, Nov 13, 2019 at 1:31 AM Pieter Wuille via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>>
>>
On Wed, Nov 13, 2019 at 1:31 AM Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> That brings me to Matt's point: there is no need to do this right now. We
> can simply amend BIP173 to only permit length 20 and length 32 (and only
> length 20 for v0, if you like; bu
On Tue, Nov 12, 2019, 21:33 ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Good morning all,
>
> It seems to me that adding the length for checksumming purposes need not
> require the length to be *actually* added in the address format.
>
Indeed!
This has the followin
Good morning all,
It seems to me that adding the length for checksumming purposes need not
require the length to be *actually* added in the address format.
So, currently, below is my understanding of bech32 validation:
* Run BCH checksum on witness program.
* Compare checksum to checksum in add
I agree on all points. The address space already brings enough confusion to
users out there. As it stands, we can use script version and program length
for address validity. Sneaking an alternate checksum into the mix for
different length programs lets us lean on our parsing libraries and not
incre
Seems good to me, though I'm curious if we have any (even vaguely)
immediate need for non-32/20-byte Segwit outputs? It seems to me this
can be resolved by just limiting the size of bech32 outputs and calling
it a day - adding yet another address format has very significant
ecosystem costs, and if
On Thu, Nov 7, 2019, 18:16 David A. Harding wrote:
> On Thu, Nov 07, 2019 at 02:35:42PM -0800, Pieter Wuille via bitcoin-dev
> wrote:
> > In the current draft, witness v1 outputs of length other
> > than 32 remain unencumbered, which means that for now such an
> > insertion or erasure would resul
> 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
> th
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 f
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-
> On Nov 8, 2019, at 11:16, David A. Harding via bitcoin-dev
> wrote:
>
> On Thu, Nov 07, 2019 at 02:35:42PM -0800, Pieter Wuille via bitcoin-dev
> wrote:
>> In the current draft, witness v1 outputs of length other
>> than 32 remain unencumbered, which means that for now such an
>> insertion
On Thu, Nov 07, 2019 at 02:35:42PM -0800, Pieter Wuille via bitcoin-dev wrote:
> In the current draft, witness v1 outputs of length other
> than 32 remain unencumbered, which means that for now such an
> insertion or erasure would result in an output that can be spent by
> anyone. If that is consid
Given the issue is in the address format, not the consensus/standardness layer,
it does seem somewhat strange to jump to addressing it with a
consensus/standardness fix. Maybe the ship has sailed, but for the sake of
considering all our options, we could also redefine bech32 to not allow such
a
Could the softer touch of just making them non-standard apply as a future
preparation for an accepted softfork? Relaxations could easily be done
later if desired.
On Thu, Nov 7, 2019, 5:37 PM Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hello all,
>
> A while ag
Hello all,
A while ago it was discovered that bech32 has a mutation weakness (see
https://github.com/sipa/bech32/issues/51 for details). Specifically,
when a bech32 string ends with a "p", inserting or erasing "q"s right
before that "p" does not invalidate it. While insertion/erasure
robustness wa
16 matches
Mail list logo
