diff options
| author | Pieter Wuille <pieter.wuille@gmail.com> | 2014-01-28 14:09:28 +0100 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2014-01-28 13:09:35 +0000 |
| commit | 6e9bdd69d4626ca6c12eb9aea8d62c4f91e7064b (patch) | |
| tree | da05027d5a557b8985ba875954e0353562f9f5b7 | |
| parent | 7587cebc65e61944b24d2878f4622c9b23e32681 (diff) | |
| download | pi-bitcoindev-6e9bdd69d4626ca6c12eb9aea8d62c4f91e7064b.tar.gz pi-bitcoindev-6e9bdd69d4626ca6c12eb9aea8d62c4f91e7064b.zip | |
Re: [Bitcoin-development] BIP70: PaymentACK semantics
| -rw-r--r-- | 8f/22079891827268a3ba1f9386083cb6955a7fae | 111 |
1 files changed, 111 insertions, 0 deletions
diff --git a/8f/22079891827268a3ba1f9386083cb6955a7fae b/8f/22079891827268a3ba1f9386083cb6955a7fae new file mode 100644 index 000000000..fcec09e74 --- /dev/null +++ b/8f/22079891827268a3ba1f9386083cb6955a7fae @@ -0,0 +1,111 @@ +Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] + helo=mx.sourceforge.net) + by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <pieter.wuille@gmail.com>) id 1W88Q3-0005el-MU + for bitcoin-development@lists.sourceforge.net; + Tue, 28 Jan 2014 13:09:35 +0000 +Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com + designates 209.85.213.170 as permitted sender) + client-ip=209.85.213.170; envelope-from=pieter.wuille@gmail.com; + helo=mail-ig0-f170.google.com; +Received: from mail-ig0-f170.google.com ([209.85.213.170]) + by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) + (Exim 4.76) id 1W88Q1-00040d-QF + for bitcoin-development@lists.sourceforge.net; + Tue, 28 Jan 2014 13:09:35 +0000 +Received: by mail-ig0-f170.google.com with SMTP id m12so14286341iga.1 + for <bitcoin-development@lists.sourceforge.net>; + Tue, 28 Jan 2014 05:09:28 -0800 (PST) +MIME-Version: 1.0 +X-Received: by 10.43.141.4 with SMTP id jc4mr10211icc.87.1390914568440; Tue, + 28 Jan 2014 05:09:28 -0800 (PST) +Received: by 10.50.100.10 with HTTP; Tue, 28 Jan 2014 05:09:28 -0800 (PST) +In-Reply-To: <CABsx9T2ng9vGMmfFK95A1jBK-FotDL-fA1oOt-=zosCPaug-rQ@mail.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> + <CAEY8wq6n_27Y2N7fVw9uJkfiiYqi6JkTwO0q03_J7tUeBhdQYA@mail.gmail.com> + <CANEZrP0HVJ7Uzow1=4-20LnejURqO5uo16H43uhL=TtNfzhAxQ@mail.gmail.com> + <CABsx9T2ng9vGMmfFK95A1jBK-FotDL-fA1oOt-=zosCPaug-rQ@mail.gmail.com> +Date: Tue, 28 Jan 2014 14:09:28 +0100 +Message-ID: <CAPg+sBhUD3H-dMQoZCNXVHBz5vj7gjkJPnUgdR-B_toQZwRdnw@mail.gmail.com> +From: Pieter Wuille <pieter.wuille@gmail.com> +To: Gavin Andresen <gavinandresen@gmail.com> +Content-Type: text/plain; charset=ISO-8859-1 +X-Spam-Score: -1.6 (-) +X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. + See http://spamassassin.org/tag/ for more details. + -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for + sender-domain + 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider + (pieter.wuille[at]gmail.com) + -0.0 SPF_PASS SPF: sender matches SPF record + -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from + author's domain + 0.1 DKIM_SIGNED Message has a DKIM or DK signature, + not necessarily valid + -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature +X-Headers-End: 1W88Q1-00040d-QF +Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>, + 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: Tue, 28 Jan 2014 13:09:35 -0000 + +On Tue, Jan 28, 2014 at 1:53 PM, Gavin Andresen <gavinandresen@gmail.com> wrote: +> On Tue, Jan 28, 2014 at 6:42 AM, Mike Hearn <mike@plan99.net> wrote: +>> +>> Yeah, that's the interpretation I think we should go with for now. There +>> was a reason why this isn't specified and I forgot what it was - some +>> inability to come to agreement on when to broadcast vs when to submit via +>> HTTP, I think. +> +> +> If the wallet software is doing automatic CoinJoin (for example), then +> typically one or several of the other participants will broadcast the +> transaction as soon as it is complete. +> +> If the spec said that wallets must not broadcast until they receive a +> PaymentACK (if a payment_url is specified), then you'd have to violate the +> spec to do CoinJoin. + +You cannot prevent transactions from being broadcasted, but an ACK can +still mean "You're now relieved of the responsibility of getting the +transaction confirmed". That's independent from being allowed to +broadcast it. + +> And even if you don't care about CoinJoin, not broadcasting the transaction +> as soon as the inputs are signed adds implementation complexity (should you +> retry if payment_url is unavailable? how many times? if you eventually +> unlock the probably-not-quite-spent-yet inputs, should you double-spend them +> to yourself just in case the merchant eventually gets around to broadcasting +> the transaction, or should you just unlock them and squirrel away the failed +> Payment so if the merchant does eventually broadcast you have a record of +> why the coins were spent). + +If a payment_url is unavailable, you should imho retry. If you +broadcasted, and the payment_url is unavailable, you should +*certainly* retry. Otherwise the recipient cannot rely on receiving +memo and refund address, which would imho make these fields completely +useless. + +I still like suggesting not broadcasting if a payment_uri to minimize +that risk further, but as you say - there are enough cases where you +cannot enforce that anyway. + +-- +Pieter + + |