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
>
> If you sent the Payment message and the server goes silent after receiving
> it, you retry to delivery. However, the merchant can broadcast the
> transactions and force them into your wallet anyway. You could, quite
> likely, pay and never get an ACK.
>
No retries. If there's a timeout the wa
On Thu, Jan 30, 2014 at 07:03:57PM +0700, Chuck wrote:
> On 1/30/2014 7:02 PM, Pieter Wuille wrote:
> > On Thu, Jan 30, 2014 at 12:59 PM, Mike Hearn wrote:
> >> With the way it works in bitcoinj, the tx is only committed to the wallet
> >> if
> >> the server accepts the Payment message and ACKs i
On 1/30/2014 7:02 PM, Pieter Wuille wrote:
> On Thu, Jan 30, 2014 at 12:59 PM, Mike Hearn wrote:
>> With the way it works in bitcoinj, the tx is only committed to the wallet if
>> the server accepts the Payment message and ACKs it. So the tx would not be
>> retried if there's a failure submitting
On Thu, Jan 30, 2014 at 12:59 PM, Mike Hearn wrote:
> With the way it works in bitcoinj, the tx is only committed to the wallet if
> the server accepts the Payment message and ACKs it. So the tx would not be
> retried if there's a failure submitting or some kind of internal server
> error, and the
With the way it works in bitcoinj, the tx is only committed to the wallet
if the server accepts the Payment message and ACKs it. So the tx would not
be retried if there's a failure submitting or some kind of internal server
error, and the UI would show that the payment failed. That seems
straightfo
On Thu, Jan 30, 2014 at 12:15 PM, Chuck wrote:
> Hi Mike. Thanks for replying.
>
> On 1/30/2014 5:49 PM, Mike Hearn wrote:
>> Both Bitcoin Core and bitcoinj are about to ship with the protocol
>> as-is, so any changes from this point on have to be backwards compatible.
> Then I think it's critica
On 1/30/2014 6:31 PM, Mike Hearn wrote:
> The arbitrator would presumably have some rules about what is or isn't
> an acceptable form of payment.
Do you think this puts unnecessary trust into a third party? If the
merchant instead signed and agreed to the unsigned transactions before
they were
On Thu, Jan 30, 2014 at 12:15 PM, Chuck wrote:
> In arbitration the merchant could argue the transactions seen on the
> network were insufficient.
>
The arbitrator would presumably have some rules about what is or isn't an
acceptable form of payment.
HTTP has response codes for submission of the
Hi Mike. Thanks for replying.
On 1/30/2014 5:49 PM, Mike Hearn wrote:
> Both Bitcoin Core and bitcoinj are about to ship with the protocol
> as-is, so any changes from this point on have to be backwards compatible.
Then I think it's critically important to talk about failure situations
now, rat
Although it should be noted that these binaries don't yet do URI support so
you can't scan a bitcoin URI with r= in it and see the verified merchant
name, etc. I think Andreas plans to do the UI for that in the next update.
On Thu, Jan 30, 2014 at 11:46 AM, Andreas Schildbach
wrote:
> Just a sma
Hi Chuck,
Both Bitcoin Core and bitcoinj are about to ship with the protocol as-is,
so any changes from this point on have to be backwards compatible.
On Thu, Jan 30, 2014 at 6:47 AM, Chuck wrote:
> I presume the receipt R=(PaymentRequest,[transactions]) would suffice.
>
That's all you need to
Just a small update. I merged the code to my bitcoinj-0.11 branch and
put up binary .apk files for experimentation. Just make sure to tick
"BIP70 for tap-to-pay/scan-to-pay" in the labs settings.
Source:
https://github.com/schildbach/bitcoin-wallet/commits/bitcoinj-0.11
Binaries:
https://github.c
19 matches
Mail list logo
