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

[Pieter Wuille via bitcoin-dev]

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 following properties:
>
> * The bech32 address format is retained, and no explicit length is added.
> * There are now two checksum formats: one with just the witness program,
> the other which validates with the witness program length.
>   * Readers that do not understand the new checksum format will simply
> reject them without mis-sending to the wrong witness program.
>

That's very close to what I was suggesting: create an improved bech32
algorithm and use that for future addresses, rather than working around the
problem in the address encoding while keeping the existing bech32 checksum.
Sorry if that wasn't clear from my previous email.

In this case, there is no need to even implicitly include the length in the
checksum algorithm. Replacing the "xor 1" at the end of the algorithm to
"xor (2^30 - 1)" would reduce the occurrence of this weakness from 1/32 to
1/2^30, and have no downsides otherwise. I'd like to do some analysis to
ascertain it actually will catch any other kind of insertion/deletion
errors with high probability as well before actually proposing it, though.

There are other solutions which do include the length in some fashion
directly in the checksum calculation, which may be preferable (I need to
analyse things...). It's also possible to do this in such a way that for
33-symbol and 53-symbol data parts (corresponding to P2WPKH and P2WSH
lengths) the new algorithm is defined as identical to the old one. That
would simplify upstream users of a bech32 library (which would then
effectively need no changes at all, apart from updating the
checksum/decoder code).

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; but they're so far apart that permitting
both shouldn't hurt), for now. Introducing the "new" address format (the
one using an improved checksum algorithm) only needs to be there in time
for when a non-32-byte-witness-program would come in sight.

Of course, I should update BIP173 to indicate the issue, and have a
suggested improvement for other users of bech32, if they feel this issue is
significant enough.

Cheers,

-- 
Pieter
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[ZmnSCPxj via bitcoin-dev]

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 address.
  * If the checksum matches:
* If version is 0, validate that the witness program is length 20 or 32.
* Else accept.
  * If the checksum does not match:
* Reject

Let me propose then:

* Run BCH checksum on witness program.
* Compare checksum to checksum in address.
  * If the checksum matches:
* If version is 0, validate that the witness program is length 20 or 32.
* Else validate that the witness program is length 32.
  * If the checksum does not match:
* Get the length of the witness program.
* Prepend the length to the witness program.
* Run BCH checksum on concatenated length | witness program.
* Compare checksum to checksum in address.
  * If the checksum matches:
* Accept.
  * Else reject.

A writer of bech32 addresses would then:

* If the witness program is length 32, or witness version is 0 and witness 
program length is 20, use a non-length-prefixed checksum.
* Otherwise, use a length-prefixed checksum (but not include the length in the 
address, just change the BCH checksum).

This has the following properties:

* The bech32 address format is retained, and no explicit length is added.
* There are now two checksum formats: one with just the witness program, the 
other which validates with the witness program length.
  * Readers that do not understand the new checksum format will simply reject 
them without mis-sending to the wrong witness program.

Is the above acceptable?

Regards,
ZmnSCPxj

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Clark Moody via bitcoin-dev]

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
increase cognitive load for users.


-Clark


On Sun, Nov 10, 2019 at 7:02 PM Matt Corallo via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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 we don't anticipate needing it for 5 years (if
> at all)...lets not jump to pay that cost.
>
> Matt
>
> On 11/10/19 9:51 PM, Pieter Wuille via bitcoin-dev wrote:
> > 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 result in an output that can be spent by
> > > anyone. If that is considered unacceptable, it could be prevented
> by
> > > for example outlawing v1 witness outputs of length 31 and 33.
> >
> > Either a consensus rule or a standardness rule[1] would require
> anyone
> > using a bech32 library supporting v1+ segwit to upgrade their
> library.
> > Otherwise, users of old libraries will still attempt to pay v1
> witness
> > outputs of length 31 or 33, causing their transactions to get
> rejected
> > by newer nodes or get stuck on older nodes.  This is basically the
> > problem #15846[2] was meant to prevent.
> >
> > If we're going to need everyone to upgrade their bech32 libraries
> > anyway, I think it's probably best that the problem is fixed in the
> > bech32 algorithm rather than at the consensus/standardness layer.
> >
> >
> > Admittedly, this affecting development of consensus or standardness
> > rules would feel unnatural. In addition, it also has the potential
> > downside of breaking batched transactions in some settings (ask an
> > exchange for a withdrawal to a invalid/nonstandard version, which they
> > batch with other outputs that then get stuck because the transaction
> > does not go through).
> >
> > So, Ideally this is indeed solved entirely on the bech32/address
> > encoding side of things. I did not initially expect the discussion here
> > to go in that direction, as that could come with all problems that
> > rolling out a new address scheme in the first place has. However, there
> > may be a way to mostly avoid those problems for the time being, while
> > also not having any impact on consensus or standardness rules.
> >
> > I believe that most new witness programs we'd want to introduce anyway
> > will be 32 bytes in the future, if the option exists. It's enough for a
> > 256-bit hash (which has up to 128-bit collision security, and more than
> > 128 bits is hard to achieve in Bitcoin anyway), or for X coordinates
> > directly. Either of those, plus a small version number to indicate the
> > commitment structure should be enough to encode any spendability
> > condition we'd want with any achievable security level.
> >
> > With that observation, I propose the following. We amend BIP173 to be
> > restricted to witness programs of length 20 or 32 (but still support
> > versions other than 0). This seems like it may be sufficient for several
> > years, until version numbers run out. I believe that some wallet
> > implementations already restrict sending to known versions only, which
> > means effectively no change for them in addition to normal deployment.
> >
> > In the mean time we develop a variant of bech32 with better
> > insertion/erasure detecting properties, which will be used for witness
> > programs of length different from 20 or 32. If we make sure that there
> > are never two distinct valid checksum algorithms for the same output, I
> > don't believe there is any need for a new address scheme or a different
> > HRP. The latter is something I'd strongly try to avoid anyway, as it
> > would mean additional cognitive load on users because of another
> > visually distinct address style, plus more logistical overhead
> > (coordination and keeping track of 2 HRPs per chain).
> >
> > I believe improving bech32 itself is preferable over changing the way
> > segwit addresses use bech32, as that can be done without making
> > addresses even longer. Furthermore, the root of the issue is in bech32,
> > and it is simplest to fix things there. The easiest solution is to
> > simply change the constant 1 that is xor'ed into the checksum before
> > encoding it to a 30-bit number. This has the advantag

[bitcoin-dev] Towards a singular payment protocol

[ee via bitcoin-dev]

A proposal for a new blockchain-agnostic payment protocol:

https://cypherpunk.org/2019/11/10/towards-a-singular-payment-protocol/

Includes the following characteristics:

- can be used with crypto or fiat currencies
- multiple currency options for a single transaction
- multiple payments in a single transaction
- allow a payment in one currency, but the value to be referenced from a second 
currency
- fee payment by sender or recipient
- calculation of valuation and fees through common trusted third parties

This is a proposal for a new payment protocol that is not linked to a specific 
blockchain, and could be supported by many of them, as well as fiat currencies. 
With one system, wallet developers working on multiple currencies could still 
look to a single payment system, and thus full support for a single protocol 
would increase.

I understand that some people will oppose something like this simply because it 
supports other coins, but I ask that it be looked at from the perspective of a) 
does it offer better functionality for Bitcoin, and b) would increased support 
by more wallets for a payment protocol be better for Bitcoin? If those are 
true, and I think they are, then this can be developed to the benefit of 
everyone.

This is the first section, focused on the actual payments. Other future 
sections are planned to include a section on smart contracts and tokens, and a 
transport mechanism for private communications between buyer and seller.

The goal would be to transform this into a BIP, but I think it needs some 
discussion first. I would appreciate constructive criticism on the proposal. 
While I’m open to the argument that payment protocols need to be coin-specific, 
I think at this point it would be more useful to discuss the functionality 
first.

Nothing in this section is really blockchain-specific, and the goal would be to 
keep it that way, and offer the same functionality to everyone.

I thank anyone who takes the time to read this proposal, and I hope to see good 
feedback on it.

Thank you,

EE


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev