public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* Re: [bitcoin-dev] URI scheme with optional bech32 address
@ 2018-09-25  6:59 shiva sitamraju
  0 siblings, 0 replies; 3+ messages in thread
From: shiva sitamraju @ 2018-09-25  6:59 UTC (permalink / raw)
  To: Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 1312 bytes --]

Hi,

I am not sure why this wasn't discussed more but it seemed like a very good
idea to me
https://www.reddit.com/r/Bitcoin/comments/9iivej/its_been_like_a_year_and_bech32_adoption_remains/

QR code is very important for network wide adoption. The problem is bech32
qr code isn't backward compatible and noone is going to show two QR codes.
Everyone is going safe with P2SH address qr code.

Example of proposed URI. I want not sure of technically best encoding, but
this is just for ideas

bitcoin:3BnsWZiTdYVrqiPh2RP3q9Y3ZqvhbCN2it?bech32=bc1q5u92yq20hss4rc99mfu23h4dxkxn4uuyqd5dzy
bitcoin:3BnsWZiTdYVrqiPh2RP3q9Y3ZqvhbCN2it?keyhash=a70aa2014fbc2151e0a5da78a8dead358d3af384
bitcoin:3BnsWZiTdYVrqiPh2RP3q9Y3ZqvhbCN2it?amount=0.123&bech32=bc1q5u92yq20hss4rc99mfu23h4dxkxn4uuyqd5dzy

As merchants/exchanges adopt this QR code, wallets that support bech32 can
chose to autopay to bech32 address  (for lower tx fee). This can create a
network effect as more people start using bech32 and when we reach enough
wallet adoption, people can shift to just showing bech32 QR codes


-- 
Shiva S
CEO @ Blockonomics <https://www.blockonomics.co>
Decentralized and Permissionless Payments
Join us on Telegram <https://t.me/BlockonomicsCo>
View our Welcome Guide
<https://www.blockonomics.co/docs/blockonomics-brochure.pdf>

[-- Attachment #2: Type: text/html, Size: 1994 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread
* [bitcoin-dev] URI scheme with optional bech32 address
@ 2018-07-24 12:05 Federico Tenga
  2018-07-24 23:44 ` vv01f
  0 siblings, 1 reply; 3+ messages in thread
From: Federico Tenga @ 2018-07-24 12:05 UTC (permalink / raw)
  To: Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 1299 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 1424 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2018-09-25  7:00 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-09-25  6:59 [bitcoin-dev] URI scheme with optional bech32 address shiva sitamraju
  -- strict thread matches above, loose matches on Subject: below --
2018-07-24 12:05 Federico Tenga
2018-07-24 23:44 ` vv01f

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox