From: Chuck <chuck+bitcoindev@borboggle•com>
To: bitcoin-development@lists•sourceforge.net,
Jeremy Spilman <jeremy@taplink•co>,
Pieter Wuille <pieter.wuille@gmail•com>
Cc: Andreas Schildbach <andreas@schildbach•de>
Subject: Re: [Bitcoin-development] BIP70: PaymentACK semantics
Date: Fri, 31 Jan 2014 11:16:36 +0700 [thread overview]
Message-ID: <52EB23A4.9@borboggle.com> (raw)
In-Reply-To: <op.xainxqs2yldrnw@laptop-air>
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@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
next prev parent reply other threads:[~2014-01-31 4:16 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-26 21:56 Andreas Schildbach
2014-01-27 14:54 ` Gavin Andresen
2014-01-27 15:20 ` Andreas Schildbach
2014-01-27 15:52 ` Mike Hearn
2014-01-27 22:03 ` Kevin Greene
2014-01-27 22:17 ` Pieter Wuille
2014-01-27 22:39 ` Kevin Greene
2014-01-28 11:42 ` Mike Hearn
2014-01-28 12:53 ` Gavin Andresen
2014-01-28 13:09 ` Pieter Wuille
2014-01-28 13:24 ` Mike Hearn
2014-01-28 17:23 ` Peter Todd
2014-01-28 17:33 ` Mike Hearn
2014-01-28 21:12 ` Peter Todd
2014-01-30 14:51 ` Jeff Garzik
2014-01-30 14:58 ` Pieter Wuille
2014-01-30 15:01 ` Mike Hearn
2014-01-30 15:06 ` Gavin Andresen
2014-01-30 15:16 ` Pieter Wuille
2014-01-30 20:16 ` Jeremy Spilman
2014-01-31 4:16 ` Chuck [this message]
2014-01-31 16:21 ` Christophe Biocca
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52EB23A4.9@borboggle.com \
--to=chuck+bitcoindev@borboggle$(echo .)com \
--cc=andreas@schildbach$(echo .)de \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=jeremy@taplink$(echo .)co \
--cc=pieter.wuille@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox