unwriter / faturi Goto Github PK

Thank you for (yet again) providing an utterly well-described suggestion to how to improve the bitcoin world.

When reading the specification section from the description it is not clear what must happen in case the tx parameter is provided together with other parameters:

The protocol works like this: Whenever a wallet encounters a tx parameter in a URI scheme, it can deserialize the tx parameter to display the transaction object detail in a user-friendly manner, as well as give an option to the user to approve or decline the transaction.

If, for example, tx is provided together with an address and an amount i imagine that we will see different wallets doing one of the following:

1. ignore the tx and provide the user with an interface as if only address and amount were present.
2. ignore the other values and provide the user with an interface as if only tx was present.
3. Recognise that this might be an error and provide an error message to the user
4. Treating the tx as one instance to handle and the address/amount as a second one providing the user with one interface followed by another as if tx was sent separately and address/amount sent separately.
5. The client sees the tx as a "baseline" and will seek to adjust the tx by changing address and amount to the values given as parameter in the URI.

As these are vastly different scenarios this could result in bad user experience across wallets. I, therefore, believe the specification should include a description of what must happen in case tx is provided with other parameters.

Personally, I regard option 2. as the most intuitive.

Seems like a good idea.

The original proposal suggests hex encoding because that's the one that's most widely used at the moment.

However hex format is not the most ideal when it comes to passing around because of its large size.

Here's a quick benchmark:

╔══════════╤════════════════════════════════╤══════╗
║ type     │ content                        │ size ║
╟──────────┼────────────────────────────────┼──────╢
║ Original │ Lorem ipsum dolor sit amet, co │ 212  ║
║          │ nsectetur adipiscing elit. Pro │      ║
║          │ in ut tortor blandit, placerat │      ║
║          │ ipsum non, vehicula odio. Nam  │      ║
║          │ cursus, mi sed dictum posuere, │      ║
║          │ orci nulla ultricies elit, sit │      ║
║          │ amet iaculis erat mi ut orci.  │      ║
║          │                                │      ║
╟──────────┼────────────────────────────────┼──────╢
║ Base64   │ TG9yZW0gaXBzdW0gZG9sb3Igc2l0IG │ 284  ║
║          │ FtZXQsIGNvbnNlY3RldHVyIGFkaXBp │      ║
║          │ c2NpbmcgZWxpdC4gUHJvaW4gdXQgdG │      ║
║          │ 9ydG9yIGJsYW5kaXQsIHBsYWNlcmF0 │      ║
║          │ IGlwc3VtIG5vbiwgdmVoaWN1bGEgb2 │      ║
║          │ Rpby4gTmFtIGN1cnN1cywgbWkgc2Vk │      ║
║          │ IGRpY3R1bSBwb3N1ZXJlLCBvcmNpIG │      ║
║          │ 51bGxhIHVsdHJpY2llcyBlbGl0LCBz │      ║
║          │ aXQgYW1ldCBpYWN1bGlzIGVyYXQgbW │      ║
║          │ kgdXQgb3JjaS4=                 │      ║
╟──────────┼────────────────────────────────┼──────╢
║ Hex      │ 4c6f72656d20697073756d20646f6c │ 424  ║
║          │ 6f722073697420616d65742c20636f │      ║
║          │ 6e7365637465747572206164697069 │      ║
║          │ 7363696e6720656c69742e2050726f │      ║
║          │ 696e20757420746f72746f7220626c │      ║
║          │ 616e6469742c20706c616365726174 │      ║
║          │ 20697073756d206e6f6e2c20766568 │      ║
║          │ 6963756c61206f64696f2e204e616d │      ║
║          │ 206375727375732c206d6920736564 │      ║
║          │ 2064696374756d20706f7375657265 │      ║
║          │ 2c206f726369206e756c6c6120756c │      ║
║          │ 7472696369657320656c69742c2073 │      ║
║          │ 697420616d657420696163756c6973 │      ║
║          │ 2065726174206d69207574206f7263 │      ║
║          │ 692e                           │      ║
╚══════════╧════════════════════════════════╧══════╝

The hex format in this case increases the original message's size 2x.

Also shown on the table, the base64 encoding also increases the size but not as much as hex. Plus it's also a widely used format (although not as much as hex format due to its lack of readability), so base64 might be a better choice.

Some people have brought up other types of encoding schemes as well. Will need to consider if they're better than base64.