Nostr notes by

📅 Original date posted:2015-02-24 📝 Original message:On ...

2023-06-07T15:31:09Z

In reply to nevent1q…pay9
_________________________

📅 Original date posted:2015-02-24
📝 Original message: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

📅 Original date posted:2015-02-23 📝 Original message:On ...

2023-06-07T15:31:08Z

In reply to nevent1q…9c4x
_________________________

📅 Original date posted:2015-02-23
📝 Original message: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

📅 Original date posted:2015-02-23 📝 Original message:Hey! ...

2023-06-07T15:31:08Z

In reply to nevent1q…gktz
_________________________

📅 Original date posted:2015-02-23
📝 Original message: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 how his app already works, but I
> don't think the way it is is ideal.

I'm fine with doing changes here - I don't think there is all that much
stuff out there yet which would break from it. 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. :-)
But I was assuming that was temporary anyway (?).

Jan

📅 Original date posted:2015-02-22 📝 Original message:Hi ...

2023-06-07T15:30:57Z

In reply to nevent1q…vdee
_________________________

📅 Original date posted:2015-02-22
📝 Original message: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=42&r=https://example.org/bip70paymentrequest

4) Touch NFC pad, fetch BIP70 details via HTTP, post transaction via HTTP
Example NFC URI: bitcoin:1asdf...?amount=42&r=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=42&bt=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=42&bt=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. Scenario 3 is what is often in use now, for
example when using a checkout screen by BitPay or Coinbase.

I played around with both scenarios 4 and 5, trying to decide whether I should
use an NFC URI record or already provide the complete BIP70 payment request via
NFC.

My experience here has been, that the latter was fairly fragile in my setup
(Raspberry Pi, NFC dongle from a company called Sensor ID, using nfcpy). I tried
with signed payment requests that were around 4k to 5k and the transfer would
often not complete if I didn't hold the phone perfectly in place. So I quickly
switched to using the NFC URI record instead and have the phone fetch the BIP70
payment request via Bluetooth afterwards. Using this approach the amount of data
is small enough that it's usually 'all or nothing' and that seems more robust to
me.

That said, I continue to have problems with the NFC stack that I'm using, so it
might just be my NFC setup that is causing these problems. I will probably give
the NXP NFC library a try next (which I believe is also the stack that is used
by Android). Maybe I have more luck with that approach and could then switch to
scenario 5.

Scenarios 6 and 7 is what the terminal is doing right now. The 'bt' parameter is
the non-standard extension of Andreas' wallet that I was mentioning. TBIP75
proposes to change 'bt' into 'r1' as part of a more generic approach of
numbering different sources for the BIP70 payment request. I think that is a
good idea and would express my vote for this proposal. So the QR code or NFC URI
would then look something like this:

bitcoin:1asdf...?amount=42&r=https://example.org/bip70&r1=bt:1234567890AB/resource

In addition the payment request would need to list additional 'payment_url's. My
proposal would be to do something like this:

message PaymentDetails {
...
optional string payment_url = 6;
optional bytes merchant_data = 7;
repeated string additional_payment_urls = 8;
// ^-- new; to hold things like 'bt:1234567890AB'
}

TBIP75 proposes to just change 'optional string payment_url' into 'repeated
string payment_url'. If this isn't causing any problems (and hopefully not too
much confusion?) I guess that would be fine too.

In my opinion a wallet should then actually attempt all or multiple of the
provided mechanisms in parallel (e.g. try to fetch the BIP70 payment request via
both HTTP and Bluetooth) and go with whatever completes first. But that is of
course up to each wallet to decide how to handle.

TBIP75 furthermore proposes to include an additional 'h' parameter which would
be a hash of the BIP70 payment request, preventing a MITM attack on the
Bluetooth channel even if the BIP70 payment request isn't signed. This would
have also been my suggestion, although I know that Mike Hearn has raised
concerns about this approach. One being, that one needs to finalize the BIP70
payment request at the time the QR code and NFC URI is generated.

## Questions ##

My questions to the list:

1) Do you prefer changing 'optional string payment_url' into 'repeated string
payment_url' or would you rather introduce a new field 'additional_payment_urls'?

2) @Andreas: Is the r, r1, r2 mechanism already implemented in Bitcoin Wallet?

3) Are there other comments regarding 'h' parameter as per TBIP75?

4) General comments, advice, feedback?

I appreciate your input! :-)

Cheers,
Jan

[1] http://andyschroder.com/BitcoinFluidDispenser/
[2] https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg06354.html
[3] https://github.com/AndySchroder/bips/blob/master/tbip-0074.mediawiki
[4] https://github.com/AndySchroder/bips/blob/master/tbip-0075.mediawiki

📅 Original date posted:2011-10-25 🗒️ Summary of this ...

2023-06-07T02:35:11Z

In reply to nevent1q…4jkc
_________________________

📅 Original date posted:2011-10-25
🗒️ Summary of this message: Jan is discussing the implementation of green addresses in Bitcoin transactions and considering two options: a hackish solution or a proper implementation.
📝 Original message: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

📅 Original date posted:2011-10-27 🗒️ Summary of this ...

2023-06-07T02:35:07Z

In reply to nevent1q…eecr
_________________________

📅 Original date posted:2011-10-27
🗒️ Summary of this message: Gavin Andresen suggests using the prevout to extract the address for a transaction input. Jan creates a patch for a new RPC call 'getorigins'.
📝 Original message: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
listtransactions or gettransaction, I put it in a separate RPC
call 'getorigins'. This is the patch:

https://github.com/javgh/bitcoin/compare/bfa4600a93...getorigins

Any obvious mistakes I made there?

Regards!
Jan

📅 Original date posted:2011-10-24 🗒️ Summary of this ...

2023-06-07T02:34:42Z

In reply to nevent1q…rtm8
_________________________

📅 Original date posted:2011-10-24
🗒️ Summary of this message: Jan is trying to add an "inputaddresses" field to the "gettransaction" call in Bitcoin, but is unsure if his method is safe and seeks advice.
📝 Original message: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

📅 Original date posted:2011-07-03 🗒️ Summary of this ...

2023-06-07T02:02:18Z

In reply to nevent1q…0k7t
_________________________

📅 Original date posted:2011-07-03
🗒️ Summary of this message: Jan implemented a balance cache to speed up the Instawallet server, using a list of all account balances stored in a map.
📝 Original message:Hey!

John Smith wrote:
> I think the easiest way to speed this up would be to scan the wallet every
> time a block comes in or something else changes in the block chain (or, if
> you prefer, some pre-set interval of N minutes). Then go over the entire
> wallet and the accumulate balances for all accounts. This could be done in
> amortized linear time using a hash_map.

That was a good suggestion - thanks! I implemented it along these lines
and now the Instawallet server can breath again. Well, more or less at
least, as now "sendfrom" starts acting up and I have to look into that
next.

Here is a branch with the code for the cache:
https://github.com/javgh/bitcoin/tree/balancecache . It's currently based
on a somewhat old version of the codebase as I'm running with a number of
other modifications. So it won't easily apply to something newer. I hope
to be able to switch to a recent version at some point (mostly hoping for
some improvements in the fee handling area before I do that) and then I
can hopefully provide a cleaner version of this patch. For now, I just
document it here for anyone who might need this as well and can piece it
together themselves (I attached a patch file).

Basically I create a list of all account balances every time a new a new
block comes in or a transaction that affects my wallet appears. The list
is stored in a "map" right now. This seems fast enough for me. I didn't
use a hash map for now, because I'm fairly new to C++ and was a little
confused on what to use (is there a "standard" hash map to use in the STL?
or do people use boost or what?). But my VPS is low on memory anyway, so I
guess that's kind of a justification as well to go for a tree-based
implementation of map.

Cheers!
Jan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: balancecache.patch
Type: text/x-patch
Size: 8184 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110703/16ead949/attachment.bin>;