eCash has used BIP21 URI parameters with some obvious-ish but unspec'ed modifications (for example, using ecash address format, using units of XEC instead of BTC).
Codify these modifications. Add a new opreturn param.
Details
Details
- Reviewers
PiRK - Group Reviewers
Restricted Project - Commits
- rABCeba145f39087: [standards] Collect eCash-specific variations to BIP21 in a spec
Read and suggest improvements. Sanity check for opreturn spec, to be implemented in Cashtab.
Diff Detail
Diff Detail
- Repository
- rABC Bitcoin ABC
- Branch
- param-for-opreturn-adds
- Lint
Lint Passed - Unit
No Test Coverage - Build Status
Buildable 25817 Build 51214: Build Diff Build 51213: arc lint + arc unit
Event Timeline
| doc/standards/bip21-ecash-additions.md | ||
|---|---|---|
| 25 | Actually, for the case of a URI it should always have the "ecash:" in front, so that the other applications know what it is. This is intended to be something that can be included in web pages, or other places where it's not obvious that an eCash address might be expected. The cashaddress format was actually designed with this in mind, that's why it uses the colon separator. | |
| doc/standards/bip21-ecash-additions.md | ||
|---|---|---|
| 25 | I confirm that ElectrumABC requires a prefix for a payment URI, but there is some confusion around the fact that it is the BIP21 prefix or the cashaddr prefix.. And I have heard of issues with some software producing double prefixed addresses (bitcoincash:bitcoincash:....) because of an incorrect interpretation of the spec. Maybe we should clarify that a single prefix is mandatory. | |
| doc/standards/bip21-ecash-additions.md | ||
|---|---|---|
| 25 | At the spec level, I think best to just specify ecash: prefixed cash address. Some apps may choose to support weird variations like ecash:<legacy> -- but I don't think it's good practice for this to be generalized and expected everywhere. Updated. | |