Since there are practical limits in what can fit into a QR code, allow prefixless addresses.
Details
Details
- Reviewers
Mengerian - Group Reviewers
Restricted Project - Commits
- rABC1ff83d9b7e15: [bip21] Allow unprefixed ecash addresses
Proofread, comment on any issues
Diff Detail
Diff Detail
- Repository
- rABC Bitcoin ABC
- Branch
- bip21-prefixless-support
- Lint
Lint Passed - Unit
No Test Coverage - Build Status
Buildable 26462 Build 52494: Build Diff Build 52493: arc lint + arc unit
Event Timeline
Comment Actions
Needs more clarity around when and where the "ecash:" prefixes need to be
| doc/standards/bip21-ecash-additions.md | ||
|---|---|---|
| 25 ↗ | (On Diff #44325) | This is super confusing... the URI definitely needs to start with "ecash:" |
| 74 ↗ | (On Diff #44325) | This makes sense, can we go even farther and say that the prefix should not be included? |
| 87 ↗ | (On Diff #44325) | Change these examples to remove the "ecash:" prefixes from the additional addresses |
| doc/standards/bip21-ecash-additions.md | ||
|---|---|---|
| 25 ↗ | (On Diff #44325) | |
Comment Actions
require ecash prefix at beginning of URI, omit ecash prefix from multi-output examples, maintain support for prefix/prefixless addresses at addr param
| doc/standards/bip21-ecash-additions.md | ||
|---|---|---|
| 74 ↗ | (On Diff #44325) | prefixless here is certainly better, but it's not like there is a storage space problem with URIs. It's more a concern for users who would like to fit as many outputs into the string as possible. Tradeoff here between compression and complexity. We could store addresses with even less space, but then it's no longer possible for the casual dev to create the strings. Imo we should just support both. The whole prefix vs prefixless situation is confusing to everyone. If later there is a need to minimize byte usage, we should go much further and support some kind of minified standards, e.g. shorter params, addresses stored by hash, this type of thing. |