[Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

2015-02-22 Thread Jan Vornberger
Hi everyone, I am working on a Bitcoin point of sale terminal based on a Raspberry Pi, which displays QR codes, but also provides payment requests via NFC. It can optionally receive the sender's transaction via Bluetooth, so if the sender wallet supports it, the sender can be completely offline. O

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

2015-02-23 Thread Jan Vornberger
Hey! On Sun, Feb 22, 2015 at 05:37:16PM -0500, Andy Schroder wrote: > It's maybe not a bad idea for the wallet to try all payment_url > mechanisms in parallel. Should we add this as a recommendation to > wallets in TBIP75? It doesn't need to be a recommendation I think, but maybe it would be good

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

2015-02-23 Thread Jan Vornberger
On Mon, Feb 23, 2015 at 05:59:34PM +0100, Mike Hearn wrote: > > > > At the moment I'm also modifying BitPay's memo field to contain 'ack', as > > Andreas' wallet otherwise reports a failure if I transmit the original via > > Bluetooth. :-) > > > > Huh? For HTTP it checks whether 'nack' is _not_ p

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

2015-02-25 Thread Jan Vornberger
On Tue, Feb 24, 2015 at 01:14:43AM -0500, Andy Schroder wrote: > I've had similar issues where the NFC device has to be disconnected > and reconnected. I've got lots of error checking in my code on the > NFC device, which helps, but still has problems sometimes. I've > found if I limit how quickly

Re: [Bitcoin-development] Instant / contactless payments

2014-03-08 Thread Jan Vornberger
On Thu, Mar 06, 2014 at 02:39:52PM +, Alex Kotenko wrote: > Not sure if you've seen it, but here is how we do NFC right now > http://www.youtube.com/watch?v=DGOMIG9JUY8 with XBTerminal. Very interesting, thanks for sharing! Are the two devices on the same wifi network in the demo? In my experi

[Bitcoin-development] Determine input addresses of a transaction

2011-10-24 Thread Jan Vornberger
Hi there! As part of my green address endeavor, I'm currently trying to extend the 'gettransaction' call to include an extra field "inputaddresses" which should return a list of the Bitcoin addresses associated with the inputs of the transaction. I understand that this is not generally possible,

Re: [Bitcoin-development] Determine input addresses of a transaction

2011-10-25 Thread Jan Vornberger
Am Mo, 24.10.2011, 16:55, schrieb Gavin Andresen: >> So my first shot at this is to go through the inputs of a transaction and >> see if the scriptSig field has only two opcodes. If that is the case, I assume that it is of the structure and calculate the Bitcoin address from . >> But then I start

Re: [Bitcoin-development] Determine input addresses of a transaction

2011-10-27 Thread Jan Vornberger
Am Mo, 24.10.2011, 16:55, schrieb Gavin Andresen: > Green addresses could be implemented as a second signature in the > scriptSig. You'd have to hack your bitcoin client, but you could > generate a transaction that had ... as the > input instead of . > > The will be ignored by old clients.

Re: [Bitcoin-development] Determine input addresses of a transaction

2011-10-27 Thread Jan Vornberger
Am Mo, 24.10.2011, 13:09, schrieb Pieter Wuille: > As far as your green transactions idea is concerned, maybe we could > provide an interface > to mark certain addresses as 'trusted', and have an RPC call to request > all incoming > transaction that originate from trusted sources? That would be fi

Re: [Bitcoin-development] Determine input addresses of a transaction

2011-10-27 Thread Jan Vornberger
Am Mo, 24.10.2011, 16:55, schrieb Gavin Andresen: > If you assume the client has all previous transactions, then you could > get the transaction input's prevout (from the memory pool or disk) and > then ExtractAddress() from it. I now created a patch based on this idea. To avoid slowing down listt