summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorChuck <chuck+bitcoindev@borboggle.com>2014-01-31 11:16:36 +0700
committerbitcoindev <bitcoindev@gnusha.org>2014-01-31 04:16:56 +0000
commitc21283abeacb28ce42a6311446b0a1a2ed27cadc (patch)
treec401c217190c70d01064a976c003ece3dbd57ae6
parent360e9669d33cf373d617bd6e5ab73995b5b065a8 (diff)
downloadpi-bitcoindev-c21283abeacb28ce42a6311446b0a1a2ed27cadc.tar.gz
pi-bitcoindev-c21283abeacb28ce42a6311446b0a1a2ed27cadc.zip
Re: [Bitcoin-development] BIP70: PaymentACK semantics
-rw-r--r--02/a001d5e3760a9630d3b647b31ce4bd1351007292
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
+
+