📅 Original date posted:2015-10-22
📝 Original message:On Thursday, October 22, 2015 8:58:58 PM Justus Ranvier wrote:
> I strongly disagree with this statement.
Well, I strongly disagree with adopting the BIP as it stands.
> 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.
No, those are not network-level changes. They are mere software changes that
can be deployed along with the rest of the proposal.
> 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.
"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.
> 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).
Such changes should not be made until there is a standard for them.
Luke
Luke Dashjr [ARCHIVE] /
npub1tf…rfq0n
2023-06-07 17:43:49
in reply to nevent1q…hltu
Author Public Key
npub1tfk373zg9dnmtvxnpnq7s2dkdgj37rwfj3yrwld7830qltmv8qps8rfq0nPublished at
2023-06-07 17:43:49Event JSON
{
"id": "66536ef3ae7af925297c9c411c25b03dfa170b1e79f2855a233ef24fcf9532d8",
"pubkey": "5a6d1f44482b67b5b0d30cc1e829b66a251f0dc99448377dbe3c5e0faf6c3803",
"created_at": 1686159829,
"kind": 1,
"tags": [
[
"e",
"9bb6828e62e331ddd988f31d853a7e825173c1f158082e0c7c1ae01342918390",
"",
"root"
],
[
"e",
"35658c5dfac32d5581fe172335ef9ba144a74451e342c052d08c5476b21fa593",
"",
"reply"
],
[
"p",
"b2b39b6f2c86908d3da9f500193abd5757b21cac328f838800a48c4d557c10dd"
]
],
"content": "📅 Original date posted:2015-10-22\n📝 Original message:On Thursday, October 22, 2015 8:58:58 PM Justus Ranvier wrote:\n\u003e I strongly disagree with this statement.\n\nWell, I strongly disagree with adopting the BIP as it stands.\n\n\u003e Version 1 payment codes are designed to be deployable by wallet\n\u003e implementers today, without requiring them to wait on any network-level\n\u003e changes whatsoever, which includes IsStandard() redefinitions, or\n\u003e yet-to-be-invented-and-deployed filtering schemes.\n\nNo, those are not network-level changes. They are mere software changes that \ncan be deployed along with the rest of the proposal.\n\n\u003e As far as I know, multi-push OP_RETURN outputs are not standard\n\u003e transactions and so wallet users can not rely on transactions containing\n\u003e them to be relayed through the network, therefore any improvement to the\n\u003e protocol which requires that feature is not appropriate for version 1.\n\n\"Standard\" means defined in a BIP. To date, there are no standard \ntransactions using OP_RETURN period. IsStandard is a node policy that should \nhave no influence on future BIPs.\n\n\u003e When additional capabilities are deployed in the network such that\n\u003e Bitcoin users can rely on their existence, that would be a great time to\n\u003e specify a version 2 payment code that uses those features and encourage\n\u003e users to upgrade (which should be a fairly smooth process since their\n\u003e actual keys don't need to change).\n\nSuch changes should not be made until there is a standard for them.\n\nLuke",
"sig": "04fd97729a23d26cf77e7ff896ac7742e5a90346cdf201df620248faa795e41582aa36b17b91c51dfc10bacc4668a8b0bc416e4eeeeb3e92c6ec253b97c76a54"
}