Hi,
not sure if you already noticed, but I and my friends are actively working
on bitcoin hardware wallet. This should be pocket size device with
something like 256kB flash and 80 MHz CPU, talking with the computer over
USB. User will prepare transaction on the machine, send it to the device,
RE: Roy Badami's comments on edge cases around submitting a Payment
message to a merchant and then not receiving a timely response:
I agree, it is messy.
I'm hesitant to try to specify One True Way of handling it in the
spec; I've got a feeling that this might be a place where different
I'd still like to understand the rationale for having the merchant
broadcast the transaction - it seems to add complexity and create edge
cases.
How about this as an alternative proposal:
The buyer's client prepares the transaction and computes its txid. It
then sends a ValidatePurchase message
I'd still like to understand the rationale for having the merchant
broadcast the transaction
There are several reasons for this:
1) P2P network sockets are a limited resource and bringing up
connections to the network, whilst somewhat fast today, is not
guaranteed to be fast in future. Passing
On Thu, Nov 29, 2012 at 06:31:24PM +0100, Mike Hearn wrote:
I'd still like to understand the rationale for having the merchant
broadcast the transaction
There are several reasons for this:
[snip]
All good reasons, thanks for the explanation.
Though I still like my idea of a
I found that the problem is the version of the Qt SDK I used didn't
like the new MacOS version. Re-installing Qt fixed it.
On Mon, Nov 26, 2012 at 4:05 PM, Mike Hearn m...@plan99.net wrote:
It appears that something about Boost doesn't play nicely with the default
build instructions (possibly
6 matches
Mail list logo
