[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, because of the different
possible structures enabled through the scripting language. But it would
be fine, if this only worked for 'regular' transactions.

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 sig pubKey and calculate the
Bitcoin address from pubKey. The patch for this is here:

https://github.com/javgh/bitcoin/compare/vps_wheezy...showinputaddresses

But then I started to wonder if this is safe. Can this be tricked somehow?
Would it be possible to create a valid transaction which has an input that
has only two opcodes but with an arbitrary pubKey at the second position?
Could someone who has a better grasp on the scripting capabilities comment
on this?

Or alternatively: should I determine the input addresses of a transaction
in a different way? if so, how?

Regards!
Jan

--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 sig pubKey and calculate the
Bitcoin address from pubKey.
 But then I started to wonder if this is safe. Can this be tricked somehow?

 Sure. There are lots of non-standard scriptPubKey scripts that will
validate if given sig pubKey as input:  a simple OP_NOP would work
(do nothing, then check the top value on the stack and validate if it is
not zero-- and pubKey is not zero).

Aw, I see. So back to the drawing board for me.

How about this: I make sure that sig is a proper signature from a green
address key, by bringing my own scriptPubKey of just OP_CHECKSIG, complete
the script to be sig pubKey OP_CHECKSIG, and run it and afterwards
check the address by looking at pubKey? Would that be safe? (Even if it
is a hackish solution that only works for certain type of transactions):

 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 greensig sig pubKey  ... as the
input instead of sig pubKey.

Interesting suggestion! So if I understand correctly, greensig would be
the signature generated from signing the transaction with the key of a
green address? Which would allow the rest of the transaction to be
completely 'normal' and not require it to use specific inputs as such?
Sounds good - I guess I never thought in this direction, as I always
assumed doing anything 'non-standard' with the scripting language would
create a number of knock-on problems. But you are saying, that this would
still be considered standard? I guess I have to study this part of the
source code more.

Well, I guess I'm torn a little bit between two options:

1) Get something working reasonable fast to detect current green address
style transactions. It's fine if it is a little bit of a hack, as long as
it's safe, since I don't expect it to be merged with mainline anyway at
this point.

2) Rethink how green transactions are created and verified and try to put
something 'proper' together which has a chance of being merged at some
point.

For the moment I was going more with 1) because I got the impression, that
green transactions are too controversial at this point to get them
included in mainline. Criticism ranging from 'unnecessary, as
0-confirmation transactions are fairly safe today' to 'encourages too much
centralization and therefore evil'. So how to people on this list feel
about green transactions? Would people be interested in helping me with
2)?

Regards,
Jan



--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 experience transaction propagation
through the Bitcoin network takes a couple of seconds longer on average,
so I'm surprised it's that fast here.

You probably share this view, but I just wanted to repeat, that from my
experiments, I think that sending the transaction only over the Bitcoin
network should be a rarely-used fallback. It usually takes a little
longer than you would like for a POS solution and every so often you
don't get the transaction at all until the next block. And then what do
you do? Maybe you would need to ask the customer to pay again, to get
things done now, and put the previous transaction in some kind of refund
mode, where - when you finally get it - you send it back somewhere. But
it's really a problematic corner case - but yet it will happen
occasionally with network-only propagation.

In the context of this discussion, I would also like to share a video of
a prototype system:

  https://www.youtube.com/watch?v=mguRpvf3aMc

Here shown is the (currently no longer working) Bridgewalker client, but
it is also fully compatible with Andreas' wallet. The client picks up
the payment details via NFC (as a Bitcoin URI - could and should be
updated to use payment protocol) and transmits a copy of the transaction
via Bluetooth (using the simple convention first implemented by
Andreas). One optimization I did in the Bridgewalker client is, that it
already opens the Bluetooth connection when presenting the user with the
confirmation dialog. This results in a little additional speed-up, as
the connection is already warmed up, when the user confirms. All code
of this prototype is open source, as is the Bridgewalker client.

From my testing, I can say that NFC for getting the payment details +
Bluetooth for transmitting the transaction back works well. I'm a bit
skeptical about using NFC also for the back-channel, but maybe for cases
where there is no additional user confirmation it could work.

One problem with Bluetooth I see is, that it seems to be mostly turned
off by users and many seem to perceive it as insecure, to have it
active, as a result of earlier Bluetooth hacks. So I'm not sure if that
will turn out to be a problem for usability when rolled-out in practice.

--
Subversion Kills Productivity. Get off Subversion  Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works. 
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 to mention that a wallet may do that, if it wants.

 I actually also happen to be using nfcpy. I am having some
 reliability issues as well with it. What exactly are your problems?

Aw, interesting. Sometimes transfers seem to start and then not complete
in some way and occasionally the NFC dongle is then totally 'stuck' in some
way afterwards, that even after restarting the Python script or
reloading the driver nothing works anymore. I have to actually unplug
the dongle and plug it in again. Obviously not exactly production ready.
I had the same problems with the command line tools based on libnfc, so
it might be a problem lower down the stack. I'm not sure I have the
expertise to troubleshoot that.

 I have seen your video before. I guess I'm wondering how your
 prototype works with bitpay and bluetooth. Doesn't bitpay sign the
 payment request for you with an https based payment_url? If so, how
 do you add the bluetooth payment_url while keeping their signature
 valid?

Good point, I'm currently simply removing the signature, so that I can
modify the payment request. I haven't spoken with BitPay yet, but I hope
that they will extend their API at some point to set additional
payment_urls or provide a Bluetooth MAC and then I can do it properly
with signed requests.

 In your video it looks like the phone still has cellular and
 wifi reception (it is not offline).

You are right, I forgot to actually disable wifi and cellular data when
recording the video. But as you know it would work the same way offline.

 Regarding the NFC data formats. I would like to clarify that the
 wallets are having those events dispatched by the android OS. The
 URI and mime type events are sent to the application in the same
 way as from other sources such as a web browser, e-mail, stand alone
 QR code scanner app, etc.. So, I don't think the wallet actually
 knows it is receiving the event from NFC. That is one reason why so
 many existing wallets happen to support BIP21 payment request via
 NFC. Andreas can correct me if I am wrong on these statements. I'm a
 little weary sending the mime type based format over NFC because
 of backwards compatibility and because of the long certificate chain
 that needs to be transferred. You want that tap to be as robust and
 fast as possible. A bluetooth connection can have a retry without
 any user interaction.

There is a specific NFC intent that you have to list in your Android
manifest, but you are right that if you already support BIP21 URIs then
it is often fairly easy and quick to also support them via NFC.

Whereas the mime type approach means that you necessarily need to be
able to actually understand BIP70, which a lot of wallet don't yet. But
personally that wouldn't hold me back using the mime type if I feel it's
the better experience. Those wallets simply have to fall back on
scanning the QR code in the meantime and then get up to speed on their
NFC and BIP70 support.

I'm still concerned that the fact, that Bluetooth is often disabled, is a
problem for the UX. And it's not just a one-time thing as with NFC,
which is - in my experience - also often disabled, but then people turn
it on and leave it on. But with Bluetooth the Android system is geared
much more towards turning it off after use and people have this general
idea of 'it uses energy, so I should disable it' and sometimes also
'Bluetooth is insecure and if I leave it on I will get hacked'. So
chances are, Bluetooth will be off most of the time, which means
everytime you pay the dialog 'Turn on Bluetooth?' will pop up, which
isn't exactly streamlined.

So the advantage of transmitting the whole BIP70 payment request via NFC
I see is, that you don't need Bluetooth to get the payment request and
for sending the transaction back the wallet can then make an intelligent
decision and first try via HTTP and only after that fails, say something
like: You are currently offline, turn on and transmit via Bluetooth
instead?. Much less confusing to the user, in my opinion.

Another idea could be to request the permission BLUETOOTH_ADMIN which,
as far as I know, allows you to programmatically turn on Bluetooth
without user interaction. The wallet could then have a setting somewhere
that says 'automatically turn on Bluetooth during payments' which would
enable and then disable (if it was off before) Bluetooth during the
payment process. That should also be a decent compromise, at the cost of
another permission.

 There is also the ack memo that I mentioned in reference [2]. I
 think we can improve upon this really. Can we make a new status
 field or different bluetooth message header? I know Andreas didn't
 want to change it because that is 

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_ presented:

  
https://github.com/schildbach/bitcoin-wallet/blob/master/wallet/src/de/schildbach/wallet/offline/DirectPaymentTask.java#L133

But via Bluetooth it checks for 'ack' directly:

  
https://github.com/schildbach/bitcoin-wallet/blob/master/wallet/src/de/schildbach/wallet/offline/DirectPaymentTask.java#L238

The latter should probably be at least changed to the reverse check as
for HTTP, but in general some non-memo way of doing that would be nice
of course.

Jan

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 a new connection can be made, that
 reduces the problem. Have you tried this?

I have a limit there, yes, but maybe I need to raise it. I'd rather
would like it to simply not jam up instead though. :-)

 What command line tool are you using with libnfc?

I don't remember exactly right now, but the Debian packages 'libnfc-bin'
and 'libnfc-examples' have some binaries and I think I used one of them
to present an NFC URI record and I ran into similar problems with
instability.

 This sounds weird to me. Why are you even using bitpay at all if you
 are already going through the effort to remove a signature and
 change the memo field?

For their tie-in with the traditional banking system, i.e. cash-out in
fiat. Here in Germany that might currently be the only feasible way of
accepting bitcoins commercially, because of unresolved questions around
VAT - but that's another topic.

Jan

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[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. Only the terminal needs an
internet connection.

Typical scenario envisioned: Customer taps their smartphone (or maybe smartwatch
in the future) on the NFC pad, confirms the transaction on their phone
(or smartwatch) and the transaction completes via Bluetooth and/or the phone's
internet connection.

You can see a prototype in action here:

  https://www.youtube.com/watch?v=P7vKHMoapr8

The above demo uses a release version of Schildbach's Bitcoin Wallet, so it
works as shown today. However, some parts - especially the Bluetooth stuff - are
custom extensions of Schildbach's wallet which are not yet standard.

I'm writing this post to document my experience implementing NFC and offline
payments and hope to move the discussion forward around standardizing some of
this stuff. Andy Schroder's work around his Bitcoin Fluid Dispenser [1,2]
follows along the same lines, so his proposed TBIP74 [3] and TBIP75 [4] are
relevant here as well.


## NFC vs Bluetooth vs NFC+Bluetooth ##

Before I get into the implementation details, a few words for why I decided to
go with the combination of NFC and Bluetooth:

Doing everything via NFC is an interesting option to keep things simple, but the
issue is, that one usually can't maintain the connection while the user confirms
the transaction (as they take the device back to press a button or maybe enter a
PIN). So there are three options:

1. Do a double tap: User taps, takes the device back, confirms, then taps
again to transmit the transaction. (I think Google Wallet does something like
this.)

2. Confirm beforehand: User confirms, then taps and everything can happen in one
go. The disadvantage is, that you confirm the transaction before you have seen
the details. (I believe Google Wallet can also work this way.)

3. Tap the phone, then establish a Bluetooth connection which allows you to do
all necessary communication even if the user takes the device back.

I feel that option 3 is the nicest UX, so that is what I am focusing on right
now, but there are pros and cons to all options. One disadvantage of option 3 in
practice is, that many users - in my experience - have Bluetooth turned off, so
it can result in additional UI dialogs popping up, asking the user to turn on
Bluetooth.

Regarding doing everything via Bluetooth or maybe BLE: I have been following the
work that Airbitz has done around that, but personally I prefer the NFC
interaction of I touch what I want to pay rather than a payment request comes
to me through the air and I figure out whether it is meant for me/is 
legitimate.


## NFC data formats ##

A bit of background for those who are not that familiar with NFC: Most Bitcoin
wallets with NFC support make use of NDEF (NFC Data Exchange Format) as far as I
am aware (with CoinBlesk being an exception, which uses host-based card
emulation, if I understand it correctly). NDEF defines a number of record types,
among them 'URI' and 'Mime Type'.

A common way of using NFC with Bitcoin is to create a URI record that contains a
Bitcoin URI. Beyond that Schildbach's wallet (and maybe others?) also support
the mime type record, which is then set to 'application/bitcoin-paymentrequest'
and the rest of the NFC data is a complete BIP70 payment request.


## Implementation ##

To structure the discussion a little bit, I have listed a number of scenarios to
consider below. Not every possible combination is listed, but it should cover a
bit of everything.

Scenarios:

1) Scan QR code, transmit transaction via Bitcoin network
   Example QR code: bitcoin:1asdf...?amount=42

2) Touch NFC pad, transmit transaction via Bitcoin network
   Example NFC URI: bitcoin:1asdf...?amount=42

3) Scan QR code, fetch BIP70 details via HTTP, post transaction via HTTP
   Example QR code: 
bitcoin:1asdf...?amount=42r=https://example.org/bip70paymentrequest

4) Touch NFC pad, fetch BIP70 details via HTTP, post transaction via HTTP
   Example NFC URI: 
bitcoin:1asdf...?amount=42r=https://example.org/bip70paymentrequest

5) Touch NFC pad, receive BIP70 details directly, post transaction via HTTP
   Example NFC MIME record: application/bitcoin-paymentrequest + BIP70 payment 
request

6) Scan QR code, fetch BIP70 details via Bluetooth, post transaction via 
Bluetooth
   Example QR code: bitcoin:1asdf...?amount=42bt=1234567890AB
   Payment request has 'payment_url' set to 'bt:1234567890AB'

7) Touch NFC pad, fetch BIP70 details via Bluetooth, post transaction via 
Bluetooth
   Example NFC URI: bitcoin:1asdf...?amount=42bt=1234567890AB
   Payment request has 'payment_url' set to 'bt:1234567890AB'

Scenarios 1 and 2 are basically the 'legacy'/pre-BIP70 approach and I am just
listing them here for comparison.