[Bitcoin-development] Determine input addresses of a transaction
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
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
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
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
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
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
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.
