Chuck [ARCHIVE] on Nostr: š Original date posted:2014-01-31 š Original message:On 1/31/2014 3:16 AM, ...
š
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
š 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