<p>QR code has very limited data capacity. (According to Wikipedia) one single QR code can only carry &lt;3KB of binary data.</p>

<p>It's not rare for a PSBT to hit this 3KB limit, especially for ones which spend non-SegWit UTXOs.</p>

<p>SegWit features signing of input values - on the other hand, signing non-SegWit inputs on offline/hardware wallet still requires full data of previous transactions to validate input values. Otherwise, it could be a security issue: a malicious party/malware could tamper the inputs stealthily to trick the user into paying an unexpected high amount.</p>

CC BY-SA 4.0
2019-11-11T03:34:47.007Z
A solution is not using QR codes for an inappropriate purpose. Find something else.
Claris
CC BY-SA 4.0
2019-11-11T03:41:18.860Z
Use multiple QR codes
Ava Chow
CC BY-SA 4.0
2019-11-11T06:50:46.700Z
@AndrewChow Multiple QR codes seems to require something like sequence number/checksum etc, maybe fountain code would be better.
Chris Chen
CC BY-SA 4.0
2019-11-11T07:07:08.323Z
@Anonymous I think at least QR code is better than USB, because I'm concerned about ADB. ADB has been "abused" by various companies, including both Android handset vendors and software vendors for quite a long time, they had turned ADB from a debugging interface into something for everyday use (as something similar to iTunes), thus countless users had already carelessly left ADB enabled.
Chris Chen
CC BY-SA 4.0
2019-12-11T08:00:58.997Z
@AndrewChow I posted this question mainly because Electrum had implemented BIP174 in a deviated way: to make the PSBT fit in one single QR code, they allowed the insecure signing mentioned in this question. Since BIP174 is intended to be used across multiple wallet implementations, I think this is not an issue only limited to Electrum.
Chris Chen
CC BY-SA 4.0
2019-12-11T08:09:55.283Z
Additionally, BIP174 didn't seem to have any checksum, did it? Since a single bit flip could lead to tragic outcome - erroneously sending coins to a black hole address, considering PSBT might go through unreliable communication channel, it seems that checksum would be helpful.
Chris Chen
CC BY-SA 4.0
2019-12-11T17:00:57.343Z
It was out of scope of the BIP to describe how PSBTs should be communicated. You can use other encoding methods to ensure proper transmission of the PSBT. With multiple QR codes, you can use a Forward Error Correction scheme where you just need to see an amount of data that is the size of the PSBT (you send a lot more than just the PSBT) so order doesn't matter.
Ava Chow
CC BY-SA 4.0
2019-12-12T01:39:32.850Z
@AndrewChow Yes, it's obviously out of scope of BIP174 - however, communication channel affects compatibility/interoperability, doesn't it? If so, we need something more than BIP174 to solve this, otherwise, as far as I can see, a wallet using FEC won't interoperate with another one using simple multi-part QR code with sequence number. I'm sorry for just complaining, however, I think this is a problem that deserves more attention.
Chris Chen
CC BY-SA 4.0
2019-12-12T01:41:05.683Z
Besides compatibility/interoperability, there's also a security issue (signing insecure inputs), isn't it?
Chris Chen
CC BY-SA 4.0
2019-12-12T01:47:23.893Z
I don't expect a newly proposed specification/standard could completely eliminate this problem, however, I think it should at least improve the situation a lot, better than doing nothing.
Chris Chen
<security><qrcode><bip174-psbt>
How could PSBT deal with data capacity limit of QR code?
Chris Chen
# How could PSBT deal with data capacity limit of QR code?

(Asked by: username_0 on 2019-11-11)

QR code has very limited data capacity. (According to Wikipedia) one single QR code can only carry <3KB of binary data.

It's not rare for a PSBT to hit this 3KB limit, especially for ones which spend non-SegWit UTXOs.

SegWit features signing of input values - on the other hand, signing non-SegWit inputs on offline/hardware wallet still requires full data of previous transactions to validate input values. Otherwise, it could be a security issue: a malicious party/malware could tamper the inputs stealthily to trick the user into paying an unexpected high amount.

**Tags:** security, qrcode, bip174-psbt

> **Comments:**
> **username_1**: A solution is not using QR codes for an inappropriate purpose. Find something else.  
> **username_2**: Use multiple QR codes  
> **username_0**: @AndrewChow Multiple QR codes seems to require something like sequence number/checksum etc, maybe fountain code would be better.  
> **username_0**: @Anonymous I think at least QR code is better than USB, because I'm concerned about ADB. ADB has been "abused" by various companies, including both Android handset vendors and software vendors for quite a long time, they had turned ADB from a debugging interface into something for everyday use (as something similar to iTunes), thus countless users had already carelessly left ADB enabled.  
> **username_0**: @AndrewChow I posted this question mainly because Electrum had implemented BIP174 in a deviated way: to make the PSBT fit in one single QR code, they allowed the insecure signing mentioned in this question. Since BIP174 is intended to be used across multiple wallet implementations, I think this is not an issue only limited to Electrum.  
> **username_0**: Additionally, BIP174 didn't seem to have any checksum, did it? Since a single bit flip could lead to tragic outcome - erroneously sending coins to a black hole address, considering PSBT might go through unreliable communication channel, it seems that checksum would be helpful.  
> **username_2**: It was out of scope of the BIP to describe how PSBTs should be communicated. You can use other encoding methods to ensure proper transmission of the PSBT. With multiple QR codes, you can use a Forward Error Correction scheme where you just need to see an amount of data that is the size of the PSBT (you send a lot more than just the PSBT) so order doesn't matter.  
> **username_0**: @AndrewChow Yes, it's obviously out of scope of BIP174 - however, communication channel affects compatibility/interoperability, doesn't it? If so, we need something more than BIP174 to solve this, otherwise, as far as I can see, a wallet using FEC won't interoperate with another one using simple multi-part QR code with sequence number. I'm sorry for just complaining, however, I think this is a problem that deserves more attention.  
> **username_0**: Besides compatibility/interoperability, there's also a security issue (signing insecure inputs), isn't it?  
> **username_0**: I don't expect a newly proposed specification/standard could completely eliminate this problem, however, I think it should at least improve the situation a lot, better than doing nothing.  

---

## 0 answers

