This will easily create too much data in the block chain.
I think it's probably better to trust online wallets to handle complex
financial transactions such a debits or credits.
If Bitcoin achieves Visa-levels of popularity, that would mean one megabyte
of transactions per second (even assuming scr
From what I have seen so far, there seems to be an agreement that this is a
nice feature to add. We are pretty new to that community and so we don't know
exactly what the process is, and in particular how we reach consensus via
email. I am certainly open to follow 'the way' if there is one, but
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
9 matches
Mail list logo
