2023-06-07T01:24:15Z https://yabu.me Jonas Schnelli [ARCHIVE] https://yabu.me/npub1nfrrurat393mqymf3s26pujyn5vujlem3pzcukr5p9d4qpklngxq43dtxs https://yabu.me/nevent1qqsthwdvpfs2un40xtd44qvucn6pjaua0e2wywahfrfnrusuz0j4vwqzyzdyv0s04wyk8vqndxxptg8jgjw3njtl8wyytrjcwsy4k5qxm7dqct6gjhr In reply to <a href='/nevent1qqsw225kn39l66kyp7yfz79dtzsg9r53lvm545q2wp3zkyemmyl3wfcyppdka'>nevent1q…pdka</a><br/>_________________________<br/><br/>📅 Original date posted:2018-06-25<br/>📝 Original message:Hi<br/>&gt; As was partially brought up by William, shouldn&#39;t we consider using<br/>&gt; bech32? It doesn&#39;t break on double-click and it is a dependency for<br/>&gt; native Segwit addresses anyway, so wallets might already support it or<br/>&gt; they will at some point. But we should probably run some numbers on this<br/>&gt; first, since bech32 will obviously be larger than base64.<br/>I don’t think bech32 is a fit here.<br/>Bech32 is a BCH where the error detecting properties are optimised for 1023 chars max and in the special case of the Bech32 BCH, error detection of 4 chars are guaranteed with a max length of 90 chars.<br/><br/>/jonas<br/>-------------- next part --------------<br/>An HTML attachment was scrubbed...<br/>URL: &lt;<a href="http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180625/88470c4c/attachment.html&gt">http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180625/88470c4c/attachment.html&gt</a>;<br/>-------------- next part --------------<br/>A non-text attachment was scrubbed...<br/>Name: signature.asc<br/>Type: application/pgp-signature<br/>Size: 833 bytes<br/>Desc: Message signed with OpenPGP<br/>URL: &lt;<a href="http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180625/88470c4c/attachment.sig&gt">http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180625/88470c4c/attachment.sig&gt</a>; 2023-06-07T18:13:11Z https://yabu.me/nevent1qqsrjgysv3ldrp35j3y4zd9pqfaxcq0z6vm2zayvrgsefpht4gy9vegzyzdyv0s04wyk8vqndxxptg8jgjw3njtl8wyytrjcwsy4k5qxm7dqcjz8ytq In reply to <a href='/nevent1qqs29h5p9lmkuxqymta2aq6uk2l697r729lh9vv5v5229sl56zgwcms5u0f98'>nevent1q…0f98</a><br/>_________________________<br/><br/>📅 Original date posted:2018-06-19<br/>📝 Original message:I agree with matejcik’s point 1 to 3 and especially with point 4.<br/>The mandatory flag (or optional-flag) makes much sense to me.<br/><br/>&gt; -----------<br/>&gt; <br/>&gt; In general, the standard is trying to be very space-conservative,<br/>&gt; however is that really necessary? We would argue for clarity and ease of<br/>&gt; use over space constraints. We think more straightforward approach is<br/>&gt; desired, although more space demanding. What are the arguments to make<br/>&gt; this as small as possible? If we understand correctly, this format is<br/>&gt; not intended for blockchain nor for persistent storage, so size doesn’t<br/>&gt; matter nearly as much.<br/><br/>I don’t see any reasons why space would be an issue.<br/><br/>HWWs probably can’t handle PBST natively since it is not optimised for<br/>presenting various informations in a signing-verification.<br/><br/>A single stream-in of a PSBT through USB (or similar channel) will not work in<br/>many cases since HWW come often with very restrictive RAM constraints.<br/><br/>Furthermore, I forget to mention in my last mail, that registering (or defining)<br/>a mime-type for PSBT would probably a great usability feature.<br/>(Send PSBT by email/messanger and with dbl-click to open feature, etc.)<br/><br/><br/>/jonas<br/>-------------- next part --------------<br/>A non-text attachment was scrubbed...<br/>Name: signature.asc<br/>Type: application/pgp-signature<br/>Size: 833 bytes<br/>Desc: Message signed with OpenPGP<br/>URL: &lt;<a href="http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180619/c263f67b/attachment.sig&gt">http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180619/c263f67b/attachment.sig&gt</a>; 2023-06-07T18:13:04Z