Justus Ranvier [ARCHIVE] on Nostr: 📅 Original date posted:2015-10-22 📝 Original message:On 22/10/15 15:43, Luke ...

📅 Original date posted:2015-10-22
📝 Original message:On 22/10/15 15:43, Luke Dashjr wrote:
> BIPs should in general not be
> designed around current software

I strongly disagree with this statement.

There is a version byte in the payment code specification for a reason.

Version 1 payment codes are designed to be deployable by wallet
implementers today, without requiring them to wait on any network-level
changes whatsoever, which includes IsStandard() redefinitions, or
yet-to-be-invented-and-deployed filtering schemes.

As far as I know, multi-push OP_RETURN outputs are not standard
transactions and so wallet users can not rely on transactions containing
them to be relayed through the network, therefore any improvement to the
protocol which requires that feature is not appropriate for version 1.

When additional capabilities are deployed in the network such that
Bitcoin users can rely on their existence, that would be a great time to
specify a version 2 payment code that uses those features and encourage
users to upgrade (which should be a fairly smooth process since their
actual keys don't need to change).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 18442 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151022/d079a180/attachment-0001.bin>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151022/d079a180/attachment-0001.sig>;