📅 Original date posted:2018-07-24
📝 Original message:Hello everyone,
With my team we are working on a walleting application which ideally will
generate a bech32 address when receiving from a bech32 compatible wallet,
and a P2WPKH-nested-in-P2SH address when receiving for a legacy wallet.
However, it is of course impossible for the payee to know in advance the
technological capabilities of the payer, so a solution could be to encode
in a Bitcoin URI both bech32 and P2SH addresses in a way that legacy
wallets only see the P2SH address, while new wallets can also see the
bech32 address and use it to perform the transaction.
In particular, to keep compatibility with BIP21, the <address> field of the
URI can be used for the P2WPKH-nested-in-P2SH address and a new field (e.g.
<segwitaddress> or <bech32address>), which will be ignored by legacy
wallets, can be used to encode the bech32 address. The assumption here is
that the wallets using such scheme will monitor incoming transaction both
on the P2SH address and on the bech32 address.
I did some research around and I did not find any proposal addressing the
same issue, so my questions are (i) does anybody already proposed something
going in the same direction and (ii) do you see any major drawback in the
BIP21 compatible scheme proposed in this message?
Thanks in advance,
Federico
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180724/28e07878/attachment.html>;
Federico Tenga [ARCHIVE] /
npub1lk…8a3qm
2023-06-07 18:13:51
in reply to nevent1q…k4q8
Author Public Key
npub1lkx8kx8luacwklf38arumxrmf3syyas26x54dtdwewtczvw5dm0qp8a3qmPublished at
2023-06-07 18:13:51Event JSON
{
"id": "505bf523886b84d37a6743feaa0326b9cdee318e81aca54413df57fd4bb7b6ed",
"pubkey": "fd8c7b18ffe770eb7d313f47cd987b4c6042760ad1a956adaecb978131d46ede",
"created_at": 1686161631,
"kind": 1,
"tags": [
[
"e",
"7b72698d99716380f26ad6eea4d3234ee893131a7cc27a95e4bf1f32b809b686",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2018-07-24\n📝 Original message:Hello everyone,\n\nWith my team we are working on a walleting application which ideally will\ngenerate a bech32 address when receiving from a bech32 compatible wallet,\nand a P2WPKH-nested-in-P2SH address when receiving for a legacy wallet.\nHowever, it is of course impossible for the payee to know in advance the\ntechnological capabilities of the payer, so a solution could be to encode\nin a Bitcoin URI both bech32 and P2SH addresses in a way that legacy\nwallets only see the P2SH address, while new wallets can also see the\nbech32 address and use it to perform the transaction.\n\nIn particular, to keep compatibility with BIP21, the \u003caddress\u003e field of the\nURI can be used for the P2WPKH-nested-in-P2SH address and a new field (e.g.\n\u003csegwitaddress\u003e or \u003cbech32address\u003e), which will be ignored by legacy\nwallets, can be used to encode the bech32 address. The assumption here is\nthat the wallets using such scheme will monitor incoming transaction both\non the P2SH address and on the bech32 address.\n\nI did some research around and I did not find any proposal addressing the\nsame issue, so my questions are (i) does anybody already proposed something\ngoing in the same direction and (ii) do you see any major drawback in the\nBIP21 compatible scheme proposed in this message?\n\nThanks in advance,\n\nFederico\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180724/28e07878/attachment.html\u003e",
"sig": "53f557e1c0eee7f430a36e1efdca2a4188fe699a16b8bbc18e1ae1ade1c660b3e1e98b875e35e97e3b5b33baca478ddea7af1ab5dbab008ef56ea692c846cbb7"
}