📅 Original date posted:2014-01-31
📝 Original message:On 1/31/2014 3:16 AM, Jeremy Spilman wrote:
> I think we want to separate the two issues;
>
> 1) Reliably getting refund/memo fields to the merchant/payee
> 2) Who broadcasts a TX, how it's retried, how outputs are 'locked' and
> if/when they should be [double]-spent to clear them
>
> We should be able to solve '1' without having to fully spec out behavior
> for 2.
My original message was focused on #1. Not only #1, but ensuring the
merchant can't act maliciously too.
As far as #2 is concerned, I don't think it makes any difference - it's
in both the customer and the merchant's best interest to have the
transactions confirmed.
> c) Send them as a response to the PaymentRequest/PaymentDetails with the
> UNsigned transaction, and then follow up with the signed transaction in a
> separate message.
...
> On Wed, 29 Jan 2014 21:47:51 -0800, Chuck <chuck+bitcoindev at borboggle.com>
> wrote:
>> 3. Customer builds a set of transactions and sends a new
>> PaymentApprovalRequest message which includes a refund address and the
>> unsigned transactions and their associated fully-signed transactionhash,
>> the whole message signed with the private key of the refund address.
> "Unsigned transactions and their associated fully-signed transaction hash"
> -- isn't that a fully signed transaction? In this case, it doesn't solve
> the core problem of the server being able to broadcast that transaction
> without ACKing.
What I meant was (and maybe this was roundabout?): the customer includes
the UNsigned transactions as well as the hashes (and only the hashes) of
the fully signed transactions. The customer keeps the fully signed
transactions private until the merchant ACKs the unsigned versions. If
the merchant has the hash of the fully signed transaction, he can
monitor the network for delivery of the signed transaction.
It definitely complicates things, but it's nothing that can't be done.
Cheers,
Chuck
Chuck [ARCHIVE] /
npub1x8…hr552
2023-06-07 15:12:40
in reply to nevent1q…q5qj
Author Public Key
npub1x87yrqqz5ddk5j8yrcsjqgtqdwachqxhzt6lw2ua7sru4jkjwc0qchr552Published at
2023-06-07 15:12:40Event JSON
{
"id": "75ad34438a2279432746c82b1ed7d329fbbe00e29132132d72543d0c1b339c90",
"pubkey": "31fc418002a35b6a48e41e212021606bbb8b80d712f5f72b9df407cacad2761e",
"created_at": 1686150760,
"kind": 1,
"tags": [
[
"e",
"cd2b50b4c4e42fbfc1a32e56fc92dceb6f26c7bd94e21234287a2ef4a6ea523e",
"",
"root"
],
[
"e",
"3c7bcf18f78238194977d6f2df8138f43bb2a23f306ed007d491b5714aa2e92e",
"",
"reply"
],
[
"p",
"7e57666cff7c86f9410d33d4d34ef3e5105395b3c74af472541dbeeb743f9de3"
]
],
"content": "📅 Original date posted:2014-01-31\n📝 Original message:On 1/31/2014 3:16 AM, Jeremy Spilman wrote:\n\u003e I think we want to separate the two issues;\n\u003e\n\u003e 1) Reliably getting refund/memo fields to the merchant/payee\n\u003e 2) Who broadcasts a TX, how it's retried, how outputs are 'locked' and\n\u003e if/when they should be [double]-spent to clear them\n\u003e\n\u003e We should be able to solve '1' without having to fully spec out behavior\n\u003e for 2.\nMy original message was focused on #1. Not only #1, but ensuring the \nmerchant can't act maliciously too.\n\nAs far as #2 is concerned, I don't think it makes any difference - it's \nin both the customer and the merchant's best interest to have the \ntransactions confirmed.\n\n\u003e c) Send them as a response to the PaymentRequest/PaymentDetails with the\n\u003e UNsigned transaction, and then follow up with the signed transaction in a\n\u003e separate message.\n...\n\u003e On Wed, 29 Jan 2014 21:47:51 -0800, Chuck \u003cchuck+bitcoindev at borboggle.com\u003e\n\u003e wrote:\n\u003e\u003e 3. Customer builds a set of transactions and sends a new\n\u003e\u003e PaymentApprovalRequest message which includes a refund address and the\n\u003e\u003e unsigned transactions and their associated fully-signed transactionhash,\n\u003e\u003e the whole message signed with the private key of the refund address.\n\u003e \"Unsigned transactions and their associated fully-signed transaction hash\"\n\u003e -- isn't that a fully signed transaction? In this case, it doesn't solve\n\u003e the core problem of the server being able to broadcast that transaction\n\u003e without ACKing.\nWhat I meant was (and maybe this was roundabout?): the customer includes \nthe UNsigned transactions as well as the hashes (and only the hashes) of \nthe fully signed transactions. The customer keeps the fully signed \ntransactions private until the merchant ACKs the unsigned versions. If \nthe merchant has the hash of the fully signed transaction, he can \nmonitor the network for delivery of the signed transaction.\n\nIt definitely complicates things, but it's nothing that can't be done.\n\nCheers,\n\nChuck",
"sig": "e323d7ba6200cab5a7b798e4ad92723ca6d4aee7e23a3545060abf1b56d7f6188fbb0c4be7930f1c8998d62baa05134c6f5dfcb6f839b276b4b76edbfae27dd1"
}