* 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
* Re: [bitcoin-dev] URI scheme with optional bech32 address
2018-07-24 12:05 Federico Tenga
@ 2018-07-24 23:44 ` vv01f
0 siblings, 0 replies; 3+ messages in thread
From: vv01f @ 2018-07-24 23:44 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1.1: Type: text/plain, Size: 3398 bytes --]
When I use the example of HTML forms …
```test.html
<!DOCTYPE html>
<html><head><title>test for URI schema</title>
<body><form method="get" action="./test.html">
<select multiple name="attr">
<option value="val1" selected>1</option>
<option value="val2" selected>2</option>
<option value="val3">3</option>
</select>
<input type="submit" value="send" />
</form></body></head></html>
```
The resulting URI is:
file:///tmp/test.html?attr=val1&attr=val2
That means that a URI attribute is not necessarily singular and can
indeed occur multiple times.
So as we do not have athority in our URI…
for URI = scheme:path[?query][#fragment]
where query=[key1=value1[&key2=value2]]
…under the circumstance that path has a newer standard we can implement
fallback with: query=[path=newerversion[&path=evennewerversion]]
…as our path is the address, resulting in e.g.:
bitcoin:p2pkh?[amount=value][&address=p2sh][&address=p2sh-p2wpkh][&address=bech32]
the effect should be
1. old clients ignore address attribute
2. supporting clients select the address attribute over the address
given in path *if* they support the format
3. future address formats do not need a new attribute
open to me would be:
* the order of the attributes and how this should be recognized/priorized
* is there any precedence for that multiple use of an attribute in URI
schemes?
I think order of attributes should remain irrelevant, thus supporting
clients should check all attributes of the same name and attributes
should be defined for repetitive (like address) or not (amount) in the
BIP. This will still not support sending different amounts to multiple
addresses and be consistent with the older version of the URI scheme.
On 24.07.2018 14:05, Federico Tenga via bitcoin-dev wrote:
> 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
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 898 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