Chuck [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2014-01-30 to 2014-01-31
💬 Posted a total of 5 messages
📚 Participated in the following categories: Bitcoin-development
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 15:12:52

- reply

📅 Original date posted:2014-01-30
📝 Original message:On 1/30/2014 7:02 PM, Pieter Wuille wrote:
> On Thu, Jan 30, 2014 at 12:59 PM, Mike Hearn <mike at plan99.net> wrote:
>> With the way it works in bitcoinj, the tx is only committed to the wallet if
>> the server accepts the Payment message and ACKs it. So the tx would not be
>> retried if there's a failure submitting or some kind of internal server
>> error, and the UI would show that the payment failed. That seems
>> straightforward and how I'd expect things to work as a user.
> That's one right way to do it imho, but not what is suggested or
> required by the specification, and not what bitcoin core master
> currently implements.
>
If you sent the Payment message and the server goes silent after
receiving it, you retry to delivery. However, the merchant can
broadcast the transactions and force them into your wallet anyway. You
could, quite likely, pay and never get an ACK.

2023-06-07 15:12:51

- reply

📅 Original date posted:2014-01-30
📝 Original message:On 1/30/2014 6:31 PM, Mike Hearn wrote:
> The arbitrator would presumably have some rules about what is or isn't
> an acceptable form of payment.
Do you think this puts unnecessary trust into a third party? If the
merchant instead signed and agreed to the unsigned transactions before
they were broadcast (as in my OP), these arbitration concerns disappear.
> HTTP has response codes for submission of the Payment message. We
> could add signing to PaymentACK and other things in future, if that
> turns out to be insufficient in practice.
HTTP isn't the only message delivery mechanism. Merchants can also lie:
reply with 200 OK and an empty body. Or, reply with 404 not found and
broadcast transactions anyway.
Cheers,
Chuck

2023-06-07 15:12:50

- reply

📅 Original date posted:2014-01-30
📝 Original message:Hi Mike. Thanks for replying.
On 1/30/2014 5:49 PM, Mike Hearn wrote:
> Both Bitcoin Core and bitcoinj are about to ship with the protocol
> as-is, so any changes from this point on have to be backwards compatible.
Then I think it's critically important to talk about failure situations
now, rather than trying to patch on solutions later; it's going to be
very hard to wedge/"hack" in fixes for potential problems when they
could be addressed now with minor changes.
> Let's get some practical experience with what we've got so far. We can
> evolve PaymentRequest/Payment/PaymentACK in the right direction with
> backwards compatible upgrades, I am hoping.
I think what I'm trying to discuss or find out here is whether the
current PP description is defunct or incomplete in some manner, thus
making any experience we gain from the current implementation moot.
It seems the largest hole in the implementation is delivery of the
Payment message, but I'm happy to accept that maybe I'm just missing
something. A malicious merchant could claim he never received the
Payment message, or a faulty network connection could cause the message
to never be delivered. In arbitration the merchant could argue the
transactions seen on the network were insufficient.
To me, this could be a problem.
Cheers,
Chuck

2023-06-07 15:12:49

- reply

📅 Original date posted:2014-01-30
📝 Original message:I spoke briefly with Peter (sipa). He recommend I forward this post to
the mailing list for further discussion.
My apologies if this has been discussed before, but I was curious about
some things re BIP70 message delivery. In particular, I don't clearly
see the value of the PaymentACK message. Allow me to explain...
The current BIP70 workflow designates PaymentACK as the final message in
a payment exchange. However, it doesn't appear that any mention is made
of what happens if that delivery fails. I assume that re-delivery is
left as a detail to the implementation, actually.
For sake of argument, let's assume that PaymentACK is never delivered
either because of a network outage or a malicious merchant or
incompatible software between wallets or a bug. I ask myself: what
would be necessary for sufficient proof of payment, say, to an arbiter?
I presume the receipt R=(PaymentRequest,[transactions]) would suffice.
Am I correct there?
But if the PaymentRequest and broadcasted transactions are enough to
prove payment, what's the point of the Payment message? The merchant
never has to verify the Payment message, possibly maliciously ignoring
it. In the well-behaved case, I presume the point is to help the
merchant associate some arbitrary data with the purchase as well as
provide a refunding address for the customer. If that's the case,
couldn't this protocol be slightly improved like so:
Required steps:
1. Customer clicks "pay now"
2. Merchant sends PaymentRequest/PaymentDetails, which should be signed
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 transaction
hash, the whole message signed with the private key of the refund address.
4. Merchant responds with PaymentApproved message, signing the
PaymentApprovalRequest message with the same key from step 2.
Optional steps:
5. The customer can send a Payment message, which is only a set of
signed transactions.
6. The merchant can respond with a PaymentACK message.
In Step 4, the merchant is acknowledging that if the transactions
provided PaymentApprovalRequest are broadcast, then payment is complete
and no other steps are required. Steps 5 and 6 aren't required but are
considered considerate:)
After step 4, all the merchant needs is to do is watch for the
transactions that were listed in PaymentApprovalRequest. The
(PaymentApproved,[signed transactions]) pair is the customer's proof of
payment and this proof of payment includes a refund address that the
merchant has agreed to prior to payment, instead of after. Step 3 & 4
also allow the merchant to verify transactions, providing an extra layer
of redundancy. The merchant will also be able to ack on fees, time lock
(time sensitive purchases?), sequence numbers, etc.
In Step 3, it's critical the customer sign the message with the private
key of the refund address, so that the merchant can be confident the
refund address is correct.
In each step along the way until step 5, if a message delivery fails
nobody is harmed because the purchase is incomplete.
Thoughts?
Chuck

2023-06-07 15:12:40

- reply

📅 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