Sjors Provoost [ARCHIVE] on Nostr: 📅 Original date posted:2017-12-05 📝 Original message:CryptAxe wrote: > Perhaps ...
📅 Original date posted:2017-12-05
📝 Original message:CryptAxe wrote:
> Perhaps instead of a flag that can be used to disable a specific operation, there should be a "-ignoredflags=x,y,z" section of the URI that can be used to ignore whatever BIP this might also be useful for in the future?
I don't think all BIPs lend themselves to this pattern. Can you think of another example? I also suspect each ignored flag requires carefully defined behavior, so it's probably better to spell that out in the BIP.
I also wouldn't be surprised if this BIP will get superseded in its entirety in the not too distant future; I believe there's some earlier discussion on this list about variations on BIP-71. So I don't think there will be many additional params in the future that warrant abstraction.
Luke Dashjr wrote:
>> P.S. I'd similarly suggest adding a bech32 param, but that's for another
>> discussion
>
> Bech32 addresses are just normal addresses. What need is there for a param?
>
> Luke
Most wallets consider bech32 addresses to be invalid. This would allow merchants to display a backwards compatible P2SH address and allow modern wallets to use bech32. In fact, this should be encouraged because it's slightly cheaper for the recipient to spend these funds (but not worth even a tiny increase in shopping cart abandonment).
Once the new format has sufficient adoption, merchants can simply drop support for old wallets and not use this parameter.
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/20171205/6a2b0451/attachment.sig>;
📝 Original message:CryptAxe wrote:
> Perhaps instead of a flag that can be used to disable a specific operation, there should be a "-ignoredflags=x,y,z" section of the URI that can be used to ignore whatever BIP this might also be useful for in the future?
I don't think all BIPs lend themselves to this pattern. Can you think of another example? I also suspect each ignored flag requires carefully defined behavior, so it's probably better to spell that out in the BIP.
I also wouldn't be surprised if this BIP will get superseded in its entirety in the not too distant future; I believe there's some earlier discussion on this list about variations on BIP-71. So I don't think there will be many additional params in the future that warrant abstraction.
Luke Dashjr wrote:
>> P.S. I'd similarly suggest adding a bech32 param, but that's for another
>> discussion
>
> Bech32 addresses are just normal addresses. What need is there for a param?
>
> Luke
Most wallets consider bech32 addresses to be invalid. This would allow merchants to display a backwards compatible P2SH address and allow modern wallets to use bech32. In fact, this should be encouraged because it's slightly cheaper for the recipient to spend these funds (but not worth even a tiny increase in shopping cart abandonment).
Once the new format has sufficient adoption, merchants can simply drop support for old wallets and not use this parameter.
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/20171205/6a2b0451/attachment.sig>;