📅 Original date posted:2014-01-31
📝 Original message:The merchant can always act maliciously by simply not delivering the
goods. The only recourse the payment protocol provides at that point
is that you have proof the merchant is acting maliciously (or at the
very least his payment system is broken).
Your scheme just adds an ACK of the specific unsigned transactions
before the payment is effectively irreversible.
I can't come up with a situation where the combination of signed
request and blockchain entry aren't enough evidence, yet where adding
an ACK by the merchant of the unsigned transaction tips the balance
the other way. If you know of such a possibility, I'd love to hear it,
because we'd know what we're trying to fix.
The only way I can see a malicious merchant exploiting wallet
behaviour around PaymentACK is by accepting the Payment message, not
broadcasting it, not returning an ACK, and hoping the wallet/user
retries paying with a new, non-conflicting transaction. Then he can
try milking multiple small payments out of the user before they
realize what happened, and broadcast them all at once, stealing more
funds than the user ever was willing to risk in the transaction. But
this is trivial to guard against at the wallet level (by making every
new payment conflict with all previous non-acked payments).
The non-reliability of getting memo/refund fields is a separate
problem, but it seems BitcoinJ's approach addresses that nicely.
On Thu, Jan 30, 2014 at 11:16 PM, Chuck <chuck+bitcoindev at borboggle.com> wrote:
> 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
>
> ------------------------------------------------------------------------------
> WatchGuard Dimension instantly turns raw network data into actionable
> security intelligence. It gives you real-time visual feedback on key
> security issues and trends. Skip the complicated setup - simply import
> a virtual appliance and go from zero to informed in seconds.
> http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Christophe Biocca [ARCHIVE] /
npub1mt…9g5zm
2023-06-07 15:12:40
in reply to nevent1q…9al9
Author Public Key
npub1mtxs7jztn027d9cylej99hltqq9vq84uxm80zl4naxafd9hpxqwsj9g5zmPublished at
2023-06-07 15:12:40Event JSON
{
"id": "51ee8e8aa0cb8d06cd08333563e6cd2aaf8a2d374a45b69c70b43a7b5e0a2de3",
"pubkey": "dacd0f484b9bd5e69704fe6452dfeb000ac01ebc36cef17eb3e9ba9696e1301d",
"created_at": 1686150760,
"kind": 1,
"tags": [
[
"e",
"cd2b50b4c4e42fbfc1a32e56fc92dceb6f26c7bd94e21234287a2ef4a6ea523e",
"",
"root"
],
[
"e",
"75ad34438a2279432746c82b1ed7d329fbbe00e29132132d72543d0c1b339c90",
"",
"reply"
],
[
"p",
"31fc418002a35b6a48e41e212021606bbb8b80d712f5f72b9df407cacad2761e"
]
],
"content": "📅 Original date posted:2014-01-31\n📝 Original message:The merchant can always act maliciously by simply not delivering the\ngoods. The only recourse the payment protocol provides at that point\nis that you have proof the merchant is acting maliciously (or at the\nvery least his payment system is broken).\n\nYour scheme just adds an ACK of the specific unsigned transactions\nbefore the payment is effectively irreversible.\n\nI can't come up with a situation where the combination of signed\nrequest and blockchain entry aren't enough evidence, yet where adding\nan ACK by the merchant of the unsigned transaction tips the balance\nthe other way. If you know of such a possibility, I'd love to hear it,\nbecause we'd know what we're trying to fix.\n\nThe only way I can see a malicious merchant exploiting wallet\nbehaviour around PaymentACK is by accepting the Payment message, not\nbroadcasting it, not returning an ACK, and hoping the wallet/user\nretries paying with a new, non-conflicting transaction. Then he can\ntry milking multiple small payments out of the user before they\nrealize what happened, and broadcast them all at once, stealing more\nfunds than the user ever was willing to risk in the transaction. But\nthis is trivial to guard against at the wallet level (by making every\nnew payment conflict with all previous non-acked payments).\n\nThe non-reliability of getting memo/refund fields is a separate\nproblem, but it seems BitcoinJ's approach addresses that nicely.\n\nOn Thu, Jan 30, 2014 at 11:16 PM, Chuck \u003cchuck+bitcoindev at borboggle.com\u003e wrote:\n\u003e On 1/31/2014 3:16 AM, Jeremy Spilman wrote:\n\u003e\u003e I think we want to separate the two issues;\n\u003e\u003e\n\u003e\u003e 1) Reliably getting refund/memo fields to the merchant/payee\n\u003e\u003e 2) Who broadcasts a TX, how it's retried, how outputs are 'locked' and\n\u003e\u003e if/when they should be [double]-spent to clear them\n\u003e\u003e\n\u003e\u003e We should be able to solve '1' without having to fully spec out behavior\n\u003e\u003e for 2.\n\u003e My original message was focused on #1. Not only #1, but ensuring the\n\u003e merchant can't act maliciously too.\n\u003e\n\u003e As far as #2 is concerned, I don't think it makes any difference - it's\n\u003e in both the customer and the merchant's best interest to have the\n\u003e transactions confirmed.\n\u003e\n\u003e\u003e c) Send them as a response to the PaymentRequest/PaymentDetails with the\n\u003e\u003e UNsigned transaction, and then follow up with the signed transaction in a\n\u003e\u003e separate message.\n\u003e ...\n\u003e\u003e On Wed, 29 Jan 2014 21:47:51 -0800, Chuck \u003cchuck+bitcoindev at borboggle.com\u003e\n\u003e\u003e wrote:\n\u003e\u003e\u003e 3. Customer builds a set of transactions and sends a new\n\u003e\u003e\u003e PaymentApprovalRequest message which includes a refund address and the\n\u003e\u003e\u003e unsigned transactions and their associated fully-signed transactionhash,\n\u003e\u003e\u003e the whole message signed with the private key of the refund address.\n\u003e\u003e \"Unsigned transactions and their associated fully-signed transaction hash\"\n\u003e\u003e -- isn't that a fully signed transaction? In this case, it doesn't solve\n\u003e\u003e the core problem of the server being able to broadcast that transaction\n\u003e\u003e without ACKing.\n\u003e What I meant was (and maybe this was roundabout?): the customer includes\n\u003e the UNsigned transactions as well as the hashes (and only the hashes) of\n\u003e the fully signed transactions. The customer keeps the fully signed\n\u003e transactions private until the merchant ACKs the unsigned versions. If\n\u003e the merchant has the hash of the fully signed transaction, he can\n\u003e monitor the network for delivery of the signed transaction.\n\u003e\n\u003e It definitely complicates things, but it's nothing that can't be done.\n\u003e\n\u003e Cheers,\n\u003e\n\u003e Chuck\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e WatchGuard Dimension instantly turns raw network data into actionable\n\u003e security intelligence. It gives you real-time visual feedback on key\n\u003e security issues and trends. Skip the complicated setup - simply import\n\u003e a virtual appliance and go from zero to informed in seconds.\n\u003e http://pubads.g.doubleclick.net/gampad/clk?id=123612991\u0026iu=/4140/ostg.clktrk\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development",
"sig": "79aaf49e6d70cf387da9cdef0f07af0f87ea0e87a6b4a8d3d1044d3fa963d2fd6ddcfa508402eccf9302fbdea4d8a4ffb5c11c49ac7944bccf42dd8e88e23fc6"
}