Federico Tenga [ARCHIVE] on Nostr: 📅 Original date posted:2018-07-24 📝 Original message:Hello everyone, With my ...
📅 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>
📝 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>