diff options
author | Chuck <chuck+bitcoindev@borboggle.com> | 2014-01-31 11:16:36 +0700 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2014-01-31 04:16:56 +0000 |
commit | c21283abeacb28ce42a6311446b0a1a2ed27cadc (patch) | |
tree | c401c217190c70d01064a976c003ece3dbd57ae6 | |
parent | 360e9669d33cf373d617bd6e5ab73995b5b065a8 (diff) | |
download | pi-bitcoindev-c21283abeacb28ce42a6311446b0a1a2ed27cadc.tar.gz pi-bitcoindev-c21283abeacb28ce42a6311446b0a1a2ed27cadc.zip |
Re: [Bitcoin-development] BIP70: PaymentACK semantics
-rw-r--r-- | 02/a001d5e3760a9630d3b647b31ce4bd13510072 | 92 |
1 files changed, 92 insertions, 0 deletions
diff --git a/02/a001d5e3760a9630d3b647b31ce4bd13510072 b/02/a001d5e3760a9630d3b647b31ce4bd13510072 new file mode 100644 index 000000000..c175202a0 --- /dev/null +++ b/02/a001d5e3760a9630d3b647b31ce4bd13510072 @@ -0,0 +1,92 @@ +Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] + helo=mx.sourceforge.net) + by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <chuck+bitcoindev@borboggle.com>) id 1W95XE-000635-DD + for bitcoin-development@lists.sourceforge.net; + Fri, 31 Jan 2014 04:16:56 +0000 +X-ACL-Warn: +Received: from borboggle.com ([69.164.197.78] helo=mail.borboggle.com) + by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76) + id 1W95XD-0006s5-Au for bitcoin-development@lists.sourceforge.net; + Fri, 31 Jan 2014 04:16:56 +0000 +Received: from [192.168.1.72] (unknown [180.183.149.52]) + by mail.borboggle.com (Postfix) with ESMTPSA id 6B81DFA97; + Thu, 30 Jan 2014 23:27:57 -0500 (EST) +Message-ID: <52EB23A4.9@borboggle.com> +Date: Fri, 31 Jan 2014 11:16:36 +0700 +From: Chuck <chuck+bitcoindev@borboggle.com> +User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; + rv:24.0) Gecko/20100101 Thunderbird/24.2.0 +MIME-Version: 1.0 +To: bitcoin-development@lists.sourceforge.net, + Jeremy Spilman <jeremy@taplink.co>, Pieter Wuille <pieter.wuille@gmail.com> +References: <lc409d$4mf$1@ger.gmane.org> <CABsx9T1Y3sO6eS54wsj377BL4rGoghx1uDzD+SY3tTgc1PPbHg@mail.gmail.com> <CANEZrP0ENhJJhba8Xwj_cVzNKGDUQriia_Q=JWTXpztb6ic8rg@mail.gmail.com> <CAEY8wq4QEO1rtaNdjHXR6-b3Cgi7pfSWk7M8khVi0MHCiVOBzQ@mail.gmail.com> <CAPg+sBgUNYqYm7d4Rv+f0rBa=nSuqwmZ6_REBS7M-+Wea+za0g@mail.gmail.com> <CAJHLa0MVbDnC0i+uT9Sahxk8ht9R5ztSJ-kOU5ERapeVibH9eg@mail.gmail.com> <CABsx9T1jAobC_p9oa_PX8M7Bo6Db3=oBhPuhp5CXVHqTRb=Hng@mail.gmail.com> <CAPg+sBiz1oXqsRTpQpVghTFupj6jsp5M-zDGKe7bjeUBHNMxUA@mail.gmail.com> + <op.xainxqs2yldrnw@laptop-air> +In-Reply-To: <op.xainxqs2yldrnw@laptop-air> +Content-Type: text/plain; charset=ISO-8859-1; format=flowed +Content-Transfer-Encoding: 7bit +X-Spam-Score: -0.4 (/) +X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. + See http://spamassassin.org/tag/ for more details. + -0.4 RP_MATCHES_RCVD Envelope sender domain matches handover relay + domain +X-Headers-End: 1W95XD-0006s5-Au +Cc: Andreas Schildbach <andreas@schildbach.de> +Subject: Re: [Bitcoin-development] BIP70: PaymentACK semantics +X-BeenThere: bitcoin-development@lists.sourceforge.net +X-Mailman-Version: 2.1.9 +Precedence: list +List-Id: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe> +X-List-Received-Date: Fri, 31 Jan 2014 04:16:56 -0000 + +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 + + |