The merchant can always act maliciously by simply not delivering the
goods. The only recourse the payment protocol provides at that point
is that you have proof the merchant is acting maliciously (or at the
very least his payment system is broken).
Your scheme just adds an ACK of the specific unsi
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 sh
Please note, responding to Pieter and Chuck concurrently.
On Thu, 30 Jan 2014 07:16:54 -0800, Pieter Wuille
wrote:
> Currently, with the specification and implementation in Bitcoin Core,
> if a merchant wants to use the refund or memo feature, they need to
> provide an alternative route for del
On Thu, Jan 30, 2014 at 3:51 PM, Jeff Garzik wrote:
> On Mon, Jan 27, 2014 at 5:17 PM, Pieter Wuille
> wrote:
>> On Mon, Jan 27, 2014 at 11:03 PM, Kevin Greene wrote:
>> > Should the wallet broadcast the transaction to the bitcoin network when it
>> > receives an ACK, or always assume that the
On Thu, Jan 30, 2014 at 4:06 PM, Gavin Andresen wrote:
> On Thu, Jan 30, 2014 at 9:51 AM, Jeff Garzik wrote:
>>
>> Is this truly the intent? That the merchant/processor takes full
>> responsibility for getting the TX confirmed?
>
>
> The intent is to give the customer a great experience. We coul
On Thu, Jan 30, 2014 at 9:51 AM, Jeff Garzik wrote:
> Is this truly the intent? That the merchant/processor takes full
> responsibility for getting the TX confirmed?
>
The intent is to give the customer a great experience. We could talk for
months about whether having the wallet broadcast the t
>
> Is this truly the intent? That the merchant/processor takes full
> responsibility for getting the TX confirmed?
As per Gavin at the top of the thread, the intent is to give the customer
reassurance that their payment will be processed. The merchant trying to
get the tx confirmed is presumabl
On Mon, Jan 27, 2014 at 5:17 PM, Pieter Wuille wrote:
> On Mon, Jan 27, 2014 at 11:03 PM, Kevin Greene wrote:
> > Should the wallet broadcast the transaction to the bitcoin network when it
> > receives an ACK, or always assume that the merchant server will do that?
> In my opinion, that should b
On Tue, Jan 28, 2014 at 06:33:28PM +0100, Mike Hearn wrote:
> In practice this should only be an issue if a payment is submitted and
> fails, which should be rare. Barring internal server errors and screwups on
> the merchants side, the only reasons for a rejection at submit time would
> be the imp
In practice this should only be an issue if a payment is submitted and
fails, which should be rare. Barring internal server errors and screwups on
the merchants side, the only reasons for a rejection at submit time would
be the imperfect fungibility of bitcoins, e.g. you try and pay with a huge
dus
On Tue, Jan 28, 2014 at 07:53:14AM -0500, Gavin Andresen wrote:
> On Tue, Jan 28, 2014 at 6:42 AM, Mike Hearn 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 ag
>
> 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?
>
I guess a lot of wallets just won't broadcast at all and try to submit via
the URL.
On Tue, Jan 28, 2014 at 1:53 PM, Gavin Andresen wrote:
> On Tue, Jan 28, 2014 at 6:42 AM, Mike Hearn 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
On Tue, Jan 28, 2014 at 6:42 AM, Mike Hearn 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
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.
On Mon, Jan 27, 2014 at 11:39 PM, Kevin Greene wrote:
> >> Sh
>> Should the wallet broadcast the transaction to the bitcoin network when
it
>> receives an ACK, or always assume that the merchant server will do that?
>
> In my opinion, that should be the primary meaning of receiving an ACK:
> acknowledgement that the receiver takes responsibility for getting t
On Mon, Jan 27, 2014 at 11:03 PM, Kevin Greene wrote:
> +1 for an error field.
Agree, I think we need a way for client applications to interpret the response.
> Should the wallet broadcast the transaction to the bitcoin network when it
> receives an ACK, or always assume that the merchant server
+1 for an error field.
Should the wallet broadcast the transaction to the bitcoin network when it
receives an ACK, or always assume that the merchant server will do that?
On Mon, Jan 27, 2014 at 7:52 AM, Mike Hearn wrote:
> At the moment there's no way to distinguish between a failed / rejecte
At the moment there's no way to distinguish between a failed / rejected
submission and a successful one beyond the freeform memo field, right? It'd
be good if we had an error code field as well, perhaps for a future version.
--
On 01/27/2014 03:54 PM, Gavin Andresen wrote:
> The purpose of PaymentACK is to give the customer reassurance that their
> payment request has been received and will be processed (or not).
>
> If it is syntactically incorrect or invalid in a way that the payment
> processor can detect right away
On Sun, Jan 26, 2014 at 4:56 PM, Andreas Schildbach
wrote:
> The BIP70 is very brief on what a PaymentACK is supposed to mean. Quote:
>
> "it [PaymentACK] is sent from the merchant's server to the bitcoin
> wallet in response to a Payment message"
>
> Does it simply mean we received a syntacticall
The BIP70 is very brief on what a PaymentACK is supposed to mean. Quote:
"it [PaymentACK] is sent from the merchant's server to the bitcoin
wallet in response to a Payment message"
Does it simply mean we received a syntactically correct Payment message?
Does it mean the Payment is valid?
Does it
22 matches
Mail list logo
