📅 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>;
Sjors Provoost [ARCHIVE] /
npub1ux…7wq7p
2023-06-07 18:06:25
in reply to nevent1q…u29r
Author Public Key
npub1uxks6rvrzqljyfp92sffgqypf8fpts0pv2dshvmmnrse76v0avlqy7wq7pPublished at
2023-06-07 18:06:25Event JSON
{
"id": "861e4705197cbbaf336e327e2a0c06649a032c8779e5d2714ab89c8a4a1e4310",
"pubkey": "e1ad0d0d83103f222425541294008149d215c1e1629b0bb37b98e19f698feb3e",
"created_at": 1686161185,
"kind": 1,
"tags": [
[
"e",
"02d8c76b933e43bf4fbef62deb34ae55389c59e653682f6f8847f8910b9dcb32",
"",
"root"
],
[
"e",
"11c76c71cb1061dcb32186930759648f4767fcd61adb9d04dc23106eaab05989",
"",
"reply"
],
[
"p",
"3215b3d77dff1f84eeb5ad46fb1206a8d1657b3ea765a80b5489ece3a702d2bc"
]
],
"content": "📅 Original date posted:2017-09-28\n📝 Original message:Op 28 sep. 2017, om 18:06 heeft Andreas Schildbach via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e het volgende geschreven:\n\u003e \n\u003e On 09/28/2017 04:41 PM, Sjors Provoost via bitcoin-dev wrote:\n\u003e \n\u003e\u003e\u003e The payment request message is just as one-way as an address is. It is\n\u003e\u003e\u003e already being emailed and printed on an invoice, in fact it often acts\n\u003e\u003e\u003e as the invoice.\n\u003e\u003e \n\u003e\u003e 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?\n\u003e \n\u003e I've not yet progressed that far in segwit support, but I can't think of\n\u003e a reason why not. You can request coins to any script using the payment\n\u003e protocol.\n\u003e \n\u003e Regarding size, I've had no problems putting (unsigned) payment request\n\u003e messages into QR codes. I doubt paying to a native segwit address will\n\u003e change much in size. Protobuf is very efficient.\n\nBech32 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:\n\nhttps://www.youtube.com/watch?v=NqiN9VFE4CU\nhttps://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki\n\nRegarding 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.\n\nI does sound like there's overlap between BIP-70 and BIP-173 that should be resolved.\n\nPerhaps 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).\n\nSjors\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 833 bytes\nDesc: Message signed with OpenPGP\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170928/c1597496/attachment-0001.sig\u003e",
"sig": "2c4bad8e70584f84f0dea9fc92dcbe3b20d5243b2e08e98a1308378438b52dec497548d79299451aba55392cdaa3ed2577ccf2e09901e1e7489f36704beeeafb"
}