Why don’t wallets implement a QR code for transactions? I understand there are no addresses in the network, but there are “transaction files” and these files could be encoded into a QR code which can be scanned/copies to a wallet when transacting. Here’s how it could work:
User A wishes to receive grin from User B
User B creates a transaction file and gives the transaction QR code to User A
User A scans code and gives the response QR code to User B
Transaction complete.
Also, in place of QR codes, one could encode the transaction into a hexadecimal string for web applications. Further, NFC could be used between mobile devices to communicate a transaction.
one could encode the transaction into a hexadecimal string for web
Having an address-like method to receive/send is a must in my opinion. Downloading and uploading files is a pain and I don’t want to open my ports. Grinbox is great but afaik not widely supported + exposes IP address (?). Though don’t quote me on that, I may be wrong.
I have a lack of knowledge in this area, but is there a way to optimise the following?
Get the raw JSON tx output.
Strip away json keys, condense empty values like [0, 0, 0, 0, 0, 0 … ] to [0], null → n.
PGP armor the stripped output.
Share armored output.
Decrypt output by receiver.
Re-build json tx from stripped output.
Receive json tx.
Doing this process with a standard json tx outputs ~2000 characters… which is long.
Maybe there’s redundant information in the json tx that can be further stripped away?
Maybe the PGP process can be replaced with some other public key native to wallets already (if it exists?)?
While it works for a typical slate (1 input, 2 outputs) qr code limits are not suitable for bigger slate. There was idea to generate a series of qr codes (like an animation), but it may be pretty awkward to use.
It may not be awkward to use. Rather than use an animation at a fixed frame-rate, a setup where the frames are interactively requested from the receiver of the payload (slate) could be less awkward.
I’d like to propose an idea for all wallet developers. Unfortunately, I’ve not had the time contribute implementation efforts into this idea, so I feel it’s best to just share the idea. (I’ll also try my best to contribute in the effort in anyway I can; through code if needed).
The idea is to use a QR code to encode transaction files between mobile devices. The first transaction file, or slate, is generated by the senders mobile device after entering an amount to send. The receive then scans the slate and generates a QR code for the response transaction file. The sender then must scan the response QR code and then submit the final resulting commitment to the blockchain.
Now, here is the key ingredient for this user experience. The mobile devices use the front facing cameras to do the scanning of all QR code’s. This means that the transaction UX is as follows:
Sender presses a send button which prompts for an amount to be entered send. After input a QR code becomes visible.
Receiver presses a receive button which displays a message telling the receive to hold their mobile device screen facing the senders screen.
The receiver’s device’s front-facing camera will scan the senders QR code and generate the response transaction file QR code nearly immediately.
The senders mobile device will almost instantly detect the receiver’s response QR code and finalized the transaction by committing it to the blockchain and displaying a final “done QR code”.
The receiver’s device detects the “done QR” and vibrates or exterts haptic feedback.
Between two and five seconds after the sender displays the done QR, the sender’s mobile device vibrates or exerts some haptic feedback.
This protocol for transacting has the following benefits in its design:
Transaction communication remains offline and in person. Much like physically exchanging cash in person. It is the first form of in-person digital cash exchange.
It only requires that mobile devices have front facing cameras. No special NFC or Bluetooth chips (even thought these are common; they might not be for some devices common in third world countries).
Transactions are a seamless user experience much like Apple Pay. The user only experiences placing their phone in front of another device until the vibration or haptic feedback is felt.
Did I mention that it would be the first offline digital cash exchange system?
The search lead me to your comment, because I was thinking about animated QR codes too.
I did not consider scanning sender and receiver simultaneously, which makes a lot of sense in a real world payment situation. There is still the waiting time for the confirmations though, so the payment does not happen instantaneous.
I found this project for transferring data with animated QR codes:
The demo looks nice. Pretty much like scanning a normal QR code.
Depending on the scanner, this could also be used to scan a series of printed QR codes. Just so that transactions can also be sent with letters.
Animated QR also could make sense for communicating with a cold storage device.
If in an animated QR code the data for each frame starts with ‘grin://’, a normal QR code scanner would offer to open the app that is registered for that.
I tested that with an animated QR code that I created myself and my phone offered to open ironbelly.
This is a send file in 16 QR codes in one animated gif (11 fps, 56kb, responses are larger) where each frame starts with ‘grin://’, some metadata (frame number, total frames, shortened hash), followed by a slice of the data.
Scanning this file entirely takes at least roughly 1.5 seconds. If a frame is missed, a scanner needs to wait until the frame is shown again, which takes another ~1.5 seconds.
If you have ironbelly installed, your standard scanner might offer to open it. Ironbelly itself of course has no clue what to do with this code, but if it had, it could detect animated QRs and start itself in scanning mode.
These codes are not meant for human viewers at the end, but you could reduce the framerate for sensitive viewers that are not in a hurry.
Combined with the minimal slate files that are mentioned on keybase this could be used at a lower framerate.
Even the minimal slates would require large QR codes if you want to put all the data into one code. Animated codes can be smaller. Think smart watches for example.
Couldn’t I just take: ‘my normal send to ip address’ or ‘hedwig adress’ or ‘one of the many options that are already out there’ ------> QR code generator
then print a static non eye-fucking QR code for someone to send me grin?
edit: damn, that qr code animation like rekt the last minute of my life. Someone flag it ew god, jk, idno op put a hyperlink with a warning up for that monstrosity.
Hey bud, can you please like imbed that gif into a link, with a warning. It’s like you’ve invented the knife-weilding flailing tentcle box and just brought it to the office party with no warning.
Turned that into a non-clickable link for you, so the forum does not auto-embed. It did not occur to me that it could offend someone.
The point is that an animated QR code can contain the actual data of the slate file (that is too big for a normal QR code) and not just some link. Having all the data in the code means that there is no network required for passing slate files.
These have a higher capacity than QR and are more pleasant to look at (or not?), but it still might be too small to cover all cases. Also you’d still probably need to use the largest version of these codes, that would not display well on a smartwatch. Also printability suffers with these. Animations can scale with arbitrary payload size, while static codes are limited.
In theory even micro QR codes could carry the information if animated.
These can be displayed at sizes smaller than 1.5cm x 1.5cm and still work.
Maybe JAB looks nicer if animated, because the contrasts are less harsh, but most probably with any kind of animated code you will end up with something that looks like some kind of static noise. These are made for machines to look at, not for humans.
The jab would look super cool if it were animated with a fade. So instead of instantly switching colors, it does so in a sin wav or whatever wav, for some period of time. Maybe 2 colors/second. Fadining in and out of the colors from box to box, I hope that makes sense… like the new RGB led gaming keyboards do on the ‘breathe’ setting
Edit: Oooo the fading path over the boxes could be done in patterns, like a diagonal wave pattern, or, vertical chevron pattern. That would look neat, payment jab things that looked all shiny pretty and animated sounds like something that something from the future would have…
edit 2: also your animated qr might look cool if it faded from frame to frame too.
That would surely make it look smoother, but most probably also requires to lower the framerate so that the scanner does not get confused. So scanning would take longer. The best case would probably be an interactive mode, where the user can influence the framerate and the fading.
JABs look nice, but they are not very common and there aren’t many implementations, while any phone can scan QRs. So a wallet app could implement it, but the user could not just scan the code to open the app.
What’s this about QR code aesthetics? Form over function? It’s your device that will be observing the code; why is the QR code’s visual appeal so important?
Because I’m picturing a future like that movie ‘idiocracy’. Plus you gotta locate the qr with your eyes first before you scan it with your device, why not make it pretty?
. And thank you for the explanation about QR codes, and how static ones can’t do certain things.
