Page MenuHomePhabricator

[bip21] Support multiple outputs
ClosedPublic

Authored by bytesofman on Jan 13 2024, 19:50.

Details

Reviewers
PiRK
Group Reviewers
Restricted Project
Commits
rABC46d766aa3592: [bip21] Support multiple outputs
Summary

T3401

It would be useful if there were a standard for creating multi-output transactions with a URI string.

This is currently supported in an unspec'd way by both Cashtab and ElectrumABC with the use of CSV strings.

With webapps looking to create these transactions programmatically, we need a settled spec for how this info is communicated between a webapp and a wallet, or a QR code and a wallet.

One option is to continue the use of CSV strings. However, this would not allow us to also include the opreturn param without a new spec, and it seems dumb to have two specs.

Test Plan

Review and suggest improvements

Diff Detail

Repository
rABC Bitcoin ABC
Branch
bip21-multi-output
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 26386
Build 52342: Build Diff
Build 52341: arc lint + arc unit

Event Timeline

no limit on number of outputs

PiRK added inline comments.
doc/standards/bip21-ecash-additions.md
80 ↗(On Diff #44151)

Currently the option for not shuffling the outputs in Electrum ABC is only available when op_return data is specified. I'm wondering if I should make this option available for all send-to-many transactions, or if the spec should be adjusted to enforce the order of outputs only when there is an op_return.

There is clearly a use case for ordered outputs with op_return (SLP), but I'm not sure if there is any for non-opreturn transactions. So there is a tradeoff to be made between letting the user control the transaction he wants to make and not providing the user with options that can accidentally hurt his privacy.

doc/standards/bip21-ecash-additions.md
80 ↗(On Diff #44151)

I lean towards accepting this diff and changing Electrum ABC to enable ordered outputs in the case of URIs of if the user checks the option. I'm just wondering if anyone else has an objection.

Fabien added inline comments.
doc/standards/bip21-ecash-additions.md
69 ↗(On Diff #44151)

wording suggestion

86 ↗(On Diff #44151)

Please make sure that your parsers will be able to decode queries with several time the same parameter

doc/standards/bip21-ecash-additions.md
86 ↗(On Diff #44151)

That should work. With python, repeating the same parameter makes the parser put the results into a list.
There is some concatenation to do for the first address (the path of the URI)

>>> import urllib.parse
>>> u = urllib.parse.urlparse("ecash:prfhcnyqnl5cgrnmlfmms675w93ld7mvvqd0y8lz07?amount=100&address=ecash:prfhcnyqnl5cgrnmlfmms675w93ld7mvvqd0y8lz07&amount=200&address=ecash:prfhcnyqnl5cgrnmlfmms675w93ld7mvvqd0y8lz07&amount=300")
>>> u
ParseResult(scheme='ecash', netloc='', path='prfhcnyqnl5cgrnmlfmms675w93ld7mvvqd0y8lz07', params='', query='amount=100&address=ecash:prfhcnyqnl5cgrnmlfmms675w93ld7mvvqd0y8lz07&amount=200&address=ecash:prfhcnyqnl5cgrnmlfmms675w93ld7mvvqd0y8lz07&amount=300', fragment='')
>>> u.path
'prfhcnyqnl5cgrnmlfmms675w93ld7mvvqd0y8lz07'
>>> pq = urllib.parse.parse_qs(u.query, keep_blank_values=True)
>>> pq
{'amount': ['100', '200', '300'], 'address': ['ecash:prfhcnyqnl5cgrnmlfmms675w93ld7mvvqd0y8lz07', 'ecash:prfhcnyqnl5cgrnmlfmms675w93ld7mvvqd0y8lz07']}
bytesofman marked 2 inline comments as done.

Change address to addr so we can fit more outputs in a QR code, specify that ordering only guaranteed with opreturn param

This revision is now accepted and ready to land.Jan 16 2024, 07:27
This revision was automatically updated to reflect the committed changes.