Sjors Provoost [ARCHIVE] on Nostr: 📅 Original date posted:2017-09-28 📝 Original message:Op 28 sep. 2017, om 18:06 ...
📅 Original date posted:2017-09-28
📝 Original message:Op 28 sep. 2017, om 18:06 heeft Andreas Schildbach via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> het volgende geschreven:
>
> On 09/28/2017 04:41 PM, Sjors Provoost via bitcoin-dev wrote:
>
>>> The payment request message is just as one-way as an address is. It is
>>> already being emailed and printed on an invoice, in fact it often acts
>>> as the invoice.
>>
>> True and the more complicated fields, like a digital signature, are optional. Are you suggesting BIP-70 payment requests should be rendered with bech32? How long would those be if it's just the address and expiration date?
>
> I've not yet progressed that far in segwit support, but I can't think of
> a reason why not. You can request coins to any script using the payment
> protocol.
>
> Regarding size, I've had no problems putting (unsigned) payment request
> messages into QR codes. I doubt paying to a native segwit address will
> change much in size. Protobuf is very efficient.
Bech32 is just a replacement for Base58. It's not strictly SegWit related. If I understand correctly the only reason it won't be used for legacy addresses is to prevent confusion:
https://www.youtube.com/watch?v=NqiN9VFE4CU
https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki
Regarding size I'm mostly curious how big it is on a screen or a physical paper, as text, not as a QR code. This would involve deserializing the protobuf and rendering the result in bech32.
I does sound like there's overlap between BIP-70 and BIP-173 that should be resolved.
Perhaps any payment request can be rendered as bech32 and any bech32 address can converted to a payment request. Maybe only for a limited set of fields (address, expiration, amount). This would be a matter of agreeing how the protobuf should be serialized and deserialized. In that case the protobuf would not contain the literal bech32 address as a string, but instead it would contain the underlying data (public key / script hash, network, etc).
Sjors
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170928/c1597496/attachment-0001.sig>;
📝 Original message:Op 28 sep. 2017, om 18:06 heeft Andreas Schildbach via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> het volgende geschreven:
>
> On 09/28/2017 04:41 PM, Sjors Provoost via bitcoin-dev wrote:
>
>>> The payment request message is just as one-way as an address is. It is
>>> already being emailed and printed on an invoice, in fact it often acts
>>> as the invoice.
>>
>> True and the more complicated fields, like a digital signature, are optional. Are you suggesting BIP-70 payment requests should be rendered with bech32? How long would those be if it's just the address and expiration date?
>
> I've not yet progressed that far in segwit support, but I can't think of
> a reason why not. You can request coins to any script using the payment
> protocol.
>
> Regarding size, I've had no problems putting (unsigned) payment request
> messages into QR codes. I doubt paying to a native segwit address will
> change much in size. Protobuf is very efficient.
Bech32 is just a replacement for Base58. It's not strictly SegWit related. If I understand correctly the only reason it won't be used for legacy addresses is to prevent confusion:
https://www.youtube.com/watch?v=NqiN9VFE4CU
https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki
Regarding size I'm mostly curious how big it is on a screen or a physical paper, as text, not as a QR code. This would involve deserializing the protobuf and rendering the result in bech32.
I does sound like there's overlap between BIP-70 and BIP-173 that should be resolved.
Perhaps any payment request can be rendered as bech32 and any bech32 address can converted to a payment request. Maybe only for a limited set of fields (address, expiration, amount). This would be a matter of agreeing how the protobuf should be serialized and deserialized. In that case the protobuf would not contain the literal bech32 address as a string, but instead it would contain the underlying data (public key / script hash, network, etc).
Sjors
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170928/c1597496/attachment-0001.sig>;