Thank you for the feedback TheZerg.
I have some responses below:
> until the URL syntax is legal ([] is reserved) since it is not implementable as currently defined.
I have added the following note:
· To maintain compatibility with URI standards, all reserved characters must be transmitted as percent encoded values. E.g. %5B = [ and %5D = ].
· For further information on reserved characters, see the following link: https://tools.ietf.org/html/rfc3986#section-2.2
· For the purposes of readability, this specification uses the reserved symbols, however all examples have been represented using RFC3986 compliant notation.
> "mandatory" is impossible
Yes definitely the wrong language.
Have updated to this:
Where amount[N] is defined, the wallet will assume that the value is agreed upon between payer and payee, and will prepare the transaction with an output directing the corresponding amount to address[N]. The wallet may offer the payer the ability to modify this amount prior to the transaction taking place however this is a consideration for the wallet software provider and is not part of this specification.
> Address should be updated to accept either base58 or cashaddr formats
Done.
> what if they specify both bitcoinaddress= and bitcoinaddress[0]= fields?
A URI that defines more than one element in any bitcoinparam[N] field would be rejected as invalid. E.g. if a URI defines an amount in the amount field and then defines a conflicting amount in the amount[0] array position, the URI would be rejected as invalid.
> If its not too painful to specify the array field in your new URL-compliant format (for example, by just removing the brackets), I'd recommend removing the bitcoinaddress= style and using arrays of 1 element for the same functionality. Clients can use the version 1.0 url format if they don't want the arrays.
Not quite sure what you mean by 1 element array. If the URI specifies information using version 1.0 compliant labels, each item is already in a 1 element array. It's only if the URI has further outputs specified that the array notations would be needed.
> xxxparam: We know that these are parameters. I'd recommend removing the "param" from all the field names since it makes the URL longer which is both more difficult to read, and requires a denser QR code.
The 'param' suffix is only in the specification to ensure clarity that the value is being discussed and not the label. The labels used in the URL are all shortened to address, amount, etc.
> for something like a restaurant tip, they would REALLY like to offer you a suggested amount. But your optional output cannot suggest an amount.
They are free to suggest an amount by using the amount[?] field in the URL. The specification is simply saying that if there is no value specified, the wallet should prompt the user to enter a value. If a value is defined in the URL It would be up to the wallet software being used to then allow the payer to go back and modify the suggested amount.
> Are there other uses for a suggested amount?
If you build it they will come.
> multibuy
Please clarify what happens if outputs are not in common.
Multibuy would look at the outputs from each URL scanned and aggregate any amounts directed to the same receiving address into one larger output. Any outputs that are to unique address would be separate outputs in the final transaction. I will try to clarify the language around this.
> Please clarify what happens if there are multiple OP_RETURN outputs, with identical or different information.
There are no OP_RETURN outputs specified in the URL. If receiptparam is set to true, the wallet software concatenates the 'messageparam[]' from each output in plaintext allowing merchants to provide on-chain receipts or other functionality. The wallet that scans the URL creates the OP_RETURN output. If the seller has set receiptparam to true the wallet software should create the OP_RETURN output automatically. If the user then excludes it from the transaction this may cause issues.
If there is too much data in the message array then it will be up to the wallet software to work out how to proceed. This may be to drop any messages that don't fit or to offer the user the ability to remove certain messages. If the current limitation of 1 OP_RETURN output per transaction is lifted this becomes easier as the wallet can simply create an additional OP_RETURN output and append more data.
> Clarify whether a wallet is allowed to produce multiple transactions or whether one transaction MUST be created. Perhaps a field in OP_RETURN that can bind multiple bitcoin tx into a single "merchant" transaction? Or is "merchant code" field not necessary because the merchant just looks for filled outputs.
If the user want multiple transactions, they can just hit 'no' when asked and send each scanned URI as a unique transaction. If the merchant wants unique transactions, they can just set 'multibuyparam' to false. It is assumed that a merchant using this feature would have multiple items for sale at different prices, but that payments would be directed to a single address or set of addresses. In this case the merchant would most likely also set receiptparam to true to enable their POS system to see the list of items purchased on-chain. This is intended to operate in a more passive environment without an active POS to manage each transaction.
[doublepost=1518588899][/doublepost]I am having trouble posting the latest edition due to its length. Is there a better way to do this?
