Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
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, device shows target address on the display and user confirms it by pressing the button. We're trying to make bitcoin payments safe even on hacked computer. For this reason we're also implementing SPV so device don't need to trust computer with any kind of information. The biggest existing problem is that user cannot be sure that the address displayed on computer screen is correct and he's confirming valid address. I don't have any solution for this problem yet. I just appreciate an activity in payment protocol area, because it can (with some care) solve this problem and my appeal si to keep all this simple. I'd be very happy with simple payment protocol which can be implemented even on devices like I'm working on, so device with few widely used certificates stored in the memory will be able to display origin of the invoice and confirm its validity. slush On Thu, Nov 29, 2012 at 1:30 AM, Watson Ladd w...@uchicago.edu wrote: After doing more thinking, what about letting a spend sign more information associated with the transaction, such as a transaction ID provided by the merchant? This seems to solve a lot of the problems being put forward, with much less complexity. -- Keep yourself connected to Go Parallel: VERIFY Test and improve your parallel project with help from experts and peers. http://goparallel.sourceforge.net ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Keep yourself connected to Go Parallel: VERIFY Test and improve your parallel project with help from experts and peers. http://goparallel.sourceforge.net___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
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 implementations might try different things, with the best implementation winning. For example, if some future nifty-keen Bitcoin client is re-using an old Invoice to send a monthly subscription payment and they can't contact the paymentURI, then the right thing is probably for it to retry once a day for three or four days and if they all fail then give up and tell the user that the service is no longer in business (or changed their paymentURI without leaving behind a redirect). If it has a single-use Invoice created a minute or two ago, the right logic might be: + If the paymentURI is completely non-responsive, just error and tell the user payment failed + If connected to the paymentURI and payment sent, but disconnected before receiving a response, then try to send-to-self the coins to cancel payment. Again, I'm not at all sure that is the best way to handle it; implementors have the right incentives to give their users the best user experience, so I feel comfortable leaving the spec fuzzy for now. -- -- Gavin Andresen -- Keep yourself connected to Go Parallel: VERIFY Test and improve your parallel project with help from experts and peers. http://goparallel.sourceforge.net ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
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 to the merchant containing the proposed Outputs and a copy of the merchant_data along with the txid. Assuming the proposed payment is accepted as valid by the merchant, the buyer's client simply broadcasts the pre-prepared transaction in the normal way, and it is the merchant's responsibility to watch for this transaction to arrive over the p2p network/blockchain to complete the purchase. (So if the merchant rejects the purchase at the ValidatePurchase stage, they never get to see the transaction that the buyer prepared, and there's therefore no need for a send-to-self to cancel it.) An optional RequestReceipt message (perhaps containing the merchant_data and txid) can be sent by the client after the transaction has been broadcast - but by making this explicitly optional it forces the merchant to rely on seeing the bitcoin transaction to 'commit' the payment and not on the RequestReceipt message. As far as I can see this proposal has no edge cases where the buyer and merchant have differing ideas as to whether the transaction has 'comitted' - or at least, no more edge cases than the standard bitcoin protocol has. roy -- Keep yourself connected to Go Parallel: VERIFY Test and improve your parallel project with help from experts and peers. http://goparallel.sourceforge.net ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
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 transactions to the merchant for broadcast reduces the load on the P2P nodes because lots of thin clients aren't any longer connecting and disconnecting when sending. They only need to talk to the network when the user has received money. 2) Some users may not have network connectivity at all. For example, this happens quite often whilst traveling at Bitcoin conferences ;) The solution, which Andreas and I prototyped in Berlin together, is for the buyer to communicate only with the seller which can be done over Bluetooth or WiFi Direct or some other mobile radio protocol. Again, send only, but for the common case where you load up your wallet before setting out and then buy things, it works OK. 4) A longer term reason - in time, people may choose to not broadcast transactions at all in some cases. I think how network speed will be funded post-inflation is still an open question. Assuming the simplest arrangement where users pay fees, getting transactions into the chain has a cost. In cases where you trust the sender to not double spend on you, you may keep a fee-less transaction around in your pocket. Then when it's your turn to pay, you use some unconfirmed transactions to do so. People pass around longer and longer chains of un-broadcast transactions until a payment crosses a trust boundary, at which point the receiver adds on their own transaction that spends back to himself but with a fee, and broadcasts them all together as a unit. In this way only people who genuinely need to fear double spends pay for security. -- Keep yourself connected to Go Parallel: VERIFY Test and improve your parallel project with help from experts and peers. http://goparallel.sourceforge.net ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
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 ValidatePurchase message that allows a buyer to ask a merchant would you accept this payment? without actually supplying a signed transaction. Make it optional if you care about minimising the number of round trips, e.g. for fast NFC payments. Having such a message reduces the extent to which you need to trust the merchant not to spend a transaction that they've rejected. (And in the non-Internet connected case this is particularly useful since the client won't have the ability to broadcast a pay-to-self transaction.) roy -- Keep yourself connected to Go Parallel: VERIFY Test and improve your parallel project with help from experts and peers. http://goparallel.sourceforge.net ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Has anyone compiled under MacOS 10.8?
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 the switch to clang++?). I will dig in eventually but for now, if anyone has a recipe that fixes things, let me know. -- Keep yourself connected to Go Parallel: VERIFY Test and improve your parallel project with help from experts and peers. http://goparallel.sourceforge.net ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
