Justus Ranvier [ARCHIVE] on Nostr: š Original date posted:2015-10-22 š Original message:On 22/10/15 16:47, Luke ...
š
Original date posted:2015-10-22
š Original message:On 22/10/15 16:47, Luke Dashjr wrote:
> Well, I strongly disagree with adopting the BIP as it stands.
That's fine. Nobody is required to adopt an informational BIP if they do
not wish to do so.
> No, those are not network-level changes. They are mere software changes that
> can be deployed along with the rest of the proposal.
They are "mere software changes" outside the control of the users and
wallet developers who may wish to use and implement payment codes, so
are indistinguishable from a network-level change.
> "Standard" means defined in a BIP. To date, there are no standard
> transactions using OP_RETURN period. IsStandard is a node policy that should
> have no influence on future BIPs.
Since Bitcoin Core 0.11, 80 byte OP_RETURN transactions are standard, so
that's what payment codes use:
https://github.com/bitcoin/bitcoin/commit/fcf646c
Whether or not it "should" have an influence, it is an absolute fact
that Bitcoin users are affected by it.
A user whose transactions are not relayed or mined doesn't care about
the politics surrounding node policy.
Designing standards without putting the needs of its intended users
first is a great way to see the standard fail.
> Such changes should not be made until there is a standard for them.
Have you ever heard the term "permissionless innovation" by chance?
Particularly in reference to Bitcoin?
If you don't like payment codes, then don't use them.
-------------- 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/31d89835/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/31d89835/attachment-0001.sig>;
š Original message:On 22/10/15 16:47, Luke Dashjr wrote:
> Well, I strongly disagree with adopting the BIP as it stands.
That's fine. Nobody is required to adopt an informational BIP if they do
not wish to do so.
> No, those are not network-level changes. They are mere software changes that
> can be deployed along with the rest of the proposal.
They are "mere software changes" outside the control of the users and
wallet developers who may wish to use and implement payment codes, so
are indistinguishable from a network-level change.
> "Standard" means defined in a BIP. To date, there are no standard
> transactions using OP_RETURN period. IsStandard is a node policy that should
> have no influence on future BIPs.
Since Bitcoin Core 0.11, 80 byte OP_RETURN transactions are standard, so
that's what payment codes use:
https://github.com/bitcoin/bitcoin/commit/fcf646c
Whether or not it "should" have an influence, it is an absolute fact
that Bitcoin users are affected by it.
A user whose transactions are not relayed or mined doesn't care about
the politics surrounding node policy.
Designing standards without putting the needs of its intended users
first is a great way to see the standard fail.
> Such changes should not be made until there is a standard for them.
Have you ever heard the term "permissionless innovation" by chance?
Particularly in reference to Bitcoin?
If you don't like payment codes, then don't use them.
-------------- 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/31d89835/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/31d89835/attachment-0001.sig>;