📅 Original date posted:2016-01-26
📝 Original message:> As I explained, none of those reasons apply to PaymentRequests.
As they exist today PaymentRequests allow for essentially the same types of
transactions as non-PaymentRequest based transactions with the limitation
that OP_RETURN values must be greater. In that sense they're basically a
pre-OP_RETURN environment. OP_RETURN serves a purpose and it can't be used
with PaymentRequest transactions.
> I have no idea what you are trying to say here.
I think if you think through how you would create an OP_RETURN transaction
today without this BIP you'll see you need a key at some point if you want
a zero value.
On Mon, Jan 25, 2016 at 6:56 PM, Luke Dashjr <luke at dashjr.org> wrote:
> On Tuesday, January 26, 2016 2:54:16 AM Toby Padilla wrote:
> > Luke - As stated in the Github thread, I totally understand where you're
> > coming from but the fact is people *will* encode data on the blockchain
> > using worse methods. For all of the reasons that OP_RETURN was a good
> idea
> > in the first place, it's a good idea to support it in PaymentRequests.
>
> As I explained, none of those reasons apply to PaymentRequests.
>
> > As for keyless - there's no way (that I know of) to construct a
> transaction
> > with a zero value OP_RETURN in an environment without keys since the
> > Payment Protocol is what defines the method for getting a transaction
> from
> > a server to a wallet. You can make a custom transaction and execute it in
> > the same application but without Payments there's no way to move
> > transactions between two applications. You need to build the transaction
> > where you execute it and thus need a key.
>
> I have no idea what you are trying to say here.
>
> Luke
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160125/cd6c0b93/attachment.html>;
Toby Padilla [ARCHIVE] /
npub1m9…huekt
2023-06-07 17:48:08
in reply to nevent1q…9zgq
Author Public Key
npub1m99yqj0pat7mwzsdczyn28z84ce47adngzqp9kzft4gc3xke52fqqhuektPublished at
2023-06-07 17:48:08Event JSON
{
"id": "fce069bc88ab6a2b0e5dee865d55fa9acaa3486c15873d4ec101dcccb3d80395",
"pubkey": "d94a4049e1eafdb70a0dc089351c47ae335f75b3408012d8495d51889ad9a292",
"created_at": 1686160088,
"kind": 1,
"tags": [
[
"e",
"368032d333e01794ac3e7b97c278de084cce6e6228857d943836fb1a934a5739",
"",
"root"
],
[
"e",
"dc0502945e08f71f08be6a95c6709777affbce6829339aac3fb0d4cec60e3f22",
"",
"reply"
],
[
"p",
"5a6d1f44482b67b5b0d30cc1e829b66a251f0dc99448377dbe3c5e0faf6c3803"
]
],
"content": "📅 Original date posted:2016-01-26\n📝 Original message:\u003e As I explained, none of those reasons apply to PaymentRequests.\n\nAs they exist today PaymentRequests allow for essentially the same types of\ntransactions as non-PaymentRequest based transactions with the limitation\nthat OP_RETURN values must be greater. In that sense they're basically a\npre-OP_RETURN environment. OP_RETURN serves a purpose and it can't be used\nwith PaymentRequest transactions.\n\n\u003e I have no idea what you are trying to say here.\n\nI think if you think through how you would create an OP_RETURN transaction\ntoday without this BIP you'll see you need a key at some point if you want\na zero value.\n\nOn Mon, Jan 25, 2016 at 6:56 PM, Luke Dashjr \u003cluke at dashjr.org\u003e wrote:\n\n\u003e On Tuesday, January 26, 2016 2:54:16 AM Toby Padilla wrote:\n\u003e \u003e Luke - As stated in the Github thread, I totally understand where you're\n\u003e \u003e coming from but the fact is people *will* encode data on the blockchain\n\u003e \u003e using worse methods. For all of the reasons that OP_RETURN was a good\n\u003e idea\n\u003e \u003e in the first place, it's a good idea to support it in PaymentRequests.\n\u003e\n\u003e As I explained, none of those reasons apply to PaymentRequests.\n\u003e\n\u003e \u003e As for keyless - there's no way (that I know of) to construct a\n\u003e transaction\n\u003e \u003e with a zero value OP_RETURN in an environment without keys since the\n\u003e \u003e Payment Protocol is what defines the method for getting a transaction\n\u003e from\n\u003e \u003e a server to a wallet. You can make a custom transaction and execute it in\n\u003e \u003e the same application but without Payments there's no way to move\n\u003e \u003e transactions between two applications. You need to build the transaction\n\u003e \u003e where you execute it and thus need a key.\n\u003e\n\u003e I have no idea what you are trying to say here.\n\u003e\n\u003e Luke\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160125/cd6c0b93/attachment.html\u003e",
"sig": "aff77c9a53d37e1611872bba7eee98a78d8fa83d5fd429a407ab90b98fd41cfecee1ac3b9fc067de9ba1a94e83791b4c7ca1469fbe3e8337bb3e2475f6b6456a"
}