npub1r3…n6ccq

Last Notes

2023-06-09 14:49:24 CEST

- reply

📅 Original date posted:2018-03-10
📝 Original message:
Hello Corné,
I'm glad to see that someone getting this kind of idea started.
I'm still new to some of these topics, but I have a few comments.
Hopefully I'm not wasting your time if they are too rudimentary!
1. You mention that the payee gives a URL where the payer can then
connect to to request invoices. You mention that this can be a tor
hidden service if the payee needs to remain private. You also
suggest that the payee can remain private by "payee can send an
invoice to payer which has a partial onion route as destination
instead of a node ID". I was reading about tor hidden services
(https://www.torproject.org/docs/onion-services.html.en), and they
require an introduction point, and a rendezvous point. Do we not
need this two step process for the payment route, because we already
have communication initiated over the anonymous communication
channel, and the beginning of the partial onion route is not
publicly available information, and can change with every invoice?
2. What happens if the capacity of the partial onion route is no longer
sufficient when the payer is ready to pay? Is there a way to provide
a few routes just in case? Or, in the case where no amount is
specified, how is the partial onion route possible if we don't even
know how much capacity may be needed?
3. You say the refund should invalidate the proof of payment of the
initial transaction. What about partial refunds? I think there are a
lot of applications where there would be a partial refund.
4. You say "this BOLT specifies a protocol where payee gives a URL to
one or more potential payers". How does the payer identify itself to
the payee so that the payee knows what goods or services that they
want an invoice for? Do they send this after making the connection,
or is it part of the URL?
Andy Schroder
On 03/08/2018 10:19 AM, Corné Plooy via Lightning-dev wrote:
> Hi,
>
> I was thinking of how to use Lightning for various types of payments,
> and I think it's currently fine for customer/(web)shop type
> interactions, but it seems a bit inconvenient for other use cases, e.g.
> salary payments or direct pay-out of cryptocurrency bought on an
> exchange. I came up with an idea that addresses some of these issues and
> more (e.g. payee anonymity) by having a direct line of communication
> between payer and payee instead of BOLT11-style interaction. It's still
> a bit half-baked, with many details not worked out yet, but you can read
> it here, and see if you like where this is going:
>
>
> https://github.com/bitonic-cjp/lightning-rfc/blob/payment-protocol/12-payment-protocol.md
>
>
> In true permissionless fashion, I have been so bolD to register bolT #12
> for my idea.
>
>
> Please let me know what you think.
>
> kind regards,
>
> CJP
>
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180310/b0f5979c/attachment.html>

2023-06-09 14:48:12 CEST

- reply

📅 Original date posted:2017-12-29
📝 Original message:
Hello,
Thanks for all of the discussion on this topic. In general, I don't have
a solid opinion formed yet, but I understand all of the points that
everyone has made. I think the bottom line is that a limit doesn't hurt
right now unless the purchasing power of bitcoin dramatically declines.
This limit is like the block size limit in that it is conservative and
we need to have some experience in order to determine whether the limit
is needed at all. It proved to be very clear over time that a block size
limit was needed as one force against centralization. Maybe a limit is
needed for lightning channels, maybe it isn't, but we need to first see
how the network starts to evolve. My main concern long term is that a
large business couldn't operate using lightning, because the channel
sizes and payment sizes are too small. What if you're buying an oil rig,
a locomotive, a gas turbine, a load of coal, or a herd of cattle. Should
a blockchain transaction be used for everyone in the world for these
types of purchases? But then again, maybe different types of users will
use different kinds of lightning networks.
Another reason against accepting large incoming channels yourself would
be that you may not want to encourage people paying you to route through
one of the super nodes. Super nodes are likely spies or targets of spies
and users won't naturally want to deal with those types of actors.
Also, the Eclair implementation supports push_msat too.
Other than as "training wheels", I'm still not sure why we need a
payment limit if we have a channel limit. It seems as though the channel
limit puts an implicit payment limit in place.
Andy Schroder
On 12/27/2017 03:13 PM, ZmnSCPxj wrote:
> Good morning Daniel,
>
>
>
>> -------- Original Message --------
>> Subject: Re: [Lightning-dev] General questions about channels
>> Local Time: December 27, 2017 10:30 PM
>> UTC Time: December 27, 2017 2:30 PM
>> From: therealsangaman at gmail.com
>> To: ZmnSCPxj <ZmnSCPxj at protonmail.com>
>> Andy Schroder <info at andyschroder.com>,
>> lightning-dev at lists.linuxfoundation.org
>> <lightning-dev at lists.linuxfoundation.org>
>>
>> I've only really been getting my hands into LN the past few weeks but
>> I thought I'd share my thoughts here.
>>
>> ZmnSCPxj via Lightning-dev lightning-dev at lists.linuxfoundation.org
>> <mailto:lightning-dev at lists.linuxfoundation.org> wrote:
>>
>> Perhaps some day, in the LONG TERM, the limits may be increased
>>
>>
>> I was always under the impression that the channel and payment limits
>> were intended to be training wheels, this is the first I've heard of
>> them intended to stick around long term. I find the channel limit to
>> be particularly restrictive, as it hinders some use cases I'd envision
>> where large payment channels between two parties are useful and can
>> also be used for routing LN payments. Large payments afaik can be
>> broken up into smaller ones without incurring too much cost or
>> trouble,
>
> Splitting up large payments would require multiple invoices at least
> for now (whether this is troublesome or not may be a matter of
> opinion, bit I suspect juggling more than a few invoices would be
> painful as a user experience). Routing larger payments over multiple
> routes automatically while using a single invoice, is harder as
> multiple routes need to be set up, and each route must have different
> preimages: further it is likely you want the entire large payment to
> be done atomically, which would be harder to arrange.
>
>> but that's not the case for creating channels. As the channel
>> itself involves only two parties - and in sticking to my general
>> political/philosophical mantra - there is really no justification for
>> limits to be imposed on this. Which brings me to my next point.
>>
>
> Perhaps our definition of "long term" is askew. A year after mainnet
> release, I doubt anyone would feel safe implementing removal of the
> limit; this is my "long term". Five years, I imagine quite a few will
> use the nonlimited version and may form a subnetwork among
> themselves. But possibly by then it would be unlikely that most
> people using Bitcoin at all would evem be capable of putting 150 mBTC
> in spending money on a hot wallet, in which case whether there is a
> 167 mBTC limit per channel or not is largely a moot point. Or perhaps
> I simply imagine hyperbitcoinization by then, with people putting
> entire bitcoins into hot wallets equivalent to people putting
> thousands of USD today in their back pockets as invitation to be attacked.
>
>>
>> There is also again the wisdom, that one should keep most of the
>> funds in
>> cold storage, and only a small amount for spending in hot wallets
>> like
>> Lightning nodes
>>
>>
>> I think this is a top-down way of thinking that runs counter to the
>> spirit of bitcoin. The "wisest" thing to do in fact may be to simply
>> buy inflation-adjusted treasury bonds and not mess with bitcoin at
>> all, much less the experimental lightning network. As advice this is
>> perfectly fine to share with others for them to follow on a voluntary
>> basis, but I don't see why this ought to be enforced as a rule on a
>> protocol level.
>>
>
> Possibly. At the protocol level, a limit encourages the growth of the
> network towards a mesh network rather than more central forms,
> however. I merely put this since it is unlikely that most people
> following this "wisdom" would have an incentive to even run software
> with the limit removed: that is, by the time Lightning becomes fully
> deployed the limit may not even be reached in practice.
>
>>
>> Also, I personally can't see a reason why a node would reject a large
>> channel being made with it, where is the downside or risk? The party
>> committing funds to the channel is the one risking loss or delay of
>> funds.
>>
>
> But the party committing funds to the channel is known via node
> gossip, and it is known also who the other end of the channel is. If
> you were to propose opening for example a 5BTC channel to me with the
> funds coming from you, I would consider the possibility that I might
> get attacked in order to get to your funds (and I might not have the
> resources to protect against such an attack on my end, even if you
> might). Further, putting 5BTC implies that at some point there is the
> future possibility, due to routing and so on, that the channel will
> have around 5BTC belonging to me, and at some point before you can
> spend the entire 5BTC I would want to close the channel and commit the
> funds that I now own into cold storage (so that the ability to channel
> 5BTC from you to me is a moot point).
>
>
> Regards,
> ZmnSCPxj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20171229/b0cc58a4/attachment.html>

2023-06-09 14:48:10 CEST

- reply

📅 Original date posted:2017-12-27
📝 Original message:
Andy Schroder
On 12/27/2017 01:06 AM, ZmnSCPxj wrote:
> Good morning Andy,
>
>> Andy Schroder
>> On 12/27/2017 12:18 AM, Andy Schroder wrote:
>>>> Channel closing
>>>> costs dwarf the gains to be made from cheating, however.
>>>>
>>>>
>>>>> Since millisatoshis is used, is there a maximum channel funding size?
>>>> Yes, the upper 32 bits must be zero, from BOLT #2:
>>>>
>>>> - for channels with `chain_hash` identifying the Bitcoin
>>>> blockchain:
>>>> - MUST set the four most significant bytes of `amount_msat` to 0.
>>>>
>>>> This gives a maximum HTLC value of .04294967295 BTC, which, back when
>>>> we started, was about $10.
>>>>
>>>
>>> What's the point of wasting the upper 32 bits? Seems like this is a
>>> waste of data?
>>>
>>> If you have the lower 32 bits of data to use, and
>>> 2^32=4,294,967,296, then you have 4,294,967,296 milli satoshis. 1
>>> BTC=10^11 milli satoshis, so 4,294,967,296 milli satoshis/((10^11
>>> milli satoshis)/1BTC) = 0.04294967296 BTC. That is off by 1 milli
>>> satoshi from what you say above. Why is this?
>>>
>>> Regardless of the discrepancy of 1 milli satoshi, it still seems
>>> like 0.04294967296 BTC is kind of a low maximum channel size for a
>>> lot of business applications. Why do you want to limit this when you
>>> have those extra 4 bytes set to zero? You think any more is too much
>>> to safely have in a hot wallet? You felt keeping it low will
>>> encourage decentralization? Something else?
>>>
>
> Yes, I believe Rusty did indeed consider 42mBTC as a reasonable amount
> to transfer on Lightning. So that in case of trouble on Lightning,
> not a lot of money gets lost. At the time he decided this 42mBTC
> limit, it was about 10 USD only, so Rusty could always just buy you a
> drink if he somehow causes c-lightning to lose that much.
>
> Of course, 42mBTC today is much larger.
>
> For myself, I think the channel limit of 167mBTC is good as it
> encourages decentralization by encouraging people to make many small
> channels than one large channel. Many small channels helps in keeping
> your funds resilient against temporary outages of your fellow nodes.
I understand what you are saying about decentralization, but is this
really something that will be enforceable? Seems like people will just
make an alt-lightning network layer with different limits to get around
this, since there isn't really a consensus rule set like on the block
chain to motivate them.
>
>>>
>>> Is the max HTLC value the same as the maximum channel size?
>>
>> Okay, so I may have discovered part of this answer to this question
>> in BOLT 2 where it says: "MUST set|funding_satoshis| to less than
>> 2^24 satoshi". However, I still don't understand the rational of why
>> |max ||funding_satoshis doesn't equal max |amount_msat, or where the
>> values of (2^24)*10^3 and 2^32 milli satoshis came from. Also, why
>> don't you use units of millisatoshis everywhere in the spec?
>> Sometimes it's satoshis and sometimes it's milli satoshis.
>>
>
> This is actually very simple. Everything that touches the chain
> (opening and closing) uses satoshis. Everything that does not, uses
> millisatoshis. This is because the chain uses satoshis as the
> smallest amount. Offchain, we can use millisatoshis, and it is used
> everywhere offchain.
Okay, the unit choices now make sense!
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20171227/51e762f0/attachment-0001.html>

2023-06-09 14:48:08 CEST

- reply

📅 Original date posted:2017-12-27
📝 Original message:
Andy Schroder
On 12/27/2017 12:56 AM, ZmnSCPxj wrote:
> Good morning Andy,
>
>>
>> Channel closing
>> costs dwarf the gains to be made from cheating, however.
>>
>> Since millisatoshis is used, is there a maximum channel
>> funding size?
>> Yes, the upper 32 bits must be zero, from BOLT #2:
>>
>> *
>> for channels with |chain_hash| identifying the Bitcoin
>> blockchain:
>> o MUST set the four most significant bytes of |amount_msat|
>> to 0.
>>
>> This gives a maximum HTLC value of .04294967295 BTC, which, back when
>> we started, was about $10.
>>
>>
>> What's the point of wasting the upper 32 bits? Seems like this is a
>> waste of data?
>
> The specs are intended to eventually support other similar
> cryptocurrencies, such as Litecoin. For those currencies, payments of
> hundreds of whole coins may be practical, and thus the 0.042 limit is
> not imposed. For Bitcoin only, the limit is applied. This simplifies
> the design of software by only imposing a limit to a large field under
> certain conditions (i.e. for Bitcoin) while retaining the same format
> for all coins. Other cryptocurrencies may have different imposed
> limits when Lightning gets around to those.
It seems like you are making assumptions about the purchasing power of
certain cryptocurrencies. Why even bother doing this? You have no idea
what the future holds. Why set a limit for any cryptocurrency that might
use lightning?
Even if you are right about the purchasing power of a particular
cryptocurrency, why is a limit needed at all? If I have an high, bi
weekly paid salary, and I have a low budget lifestyle, let's say I save
90% of my income. It seems like your assumed limits could require
multiple payments and multiple open channels for each bi weekly payment.
What if I want to buy a boat, do you expect me to make payments from a
lot of different channels? I was kind of under the assumption that the
long term goal of lightning was only to have a few on chain payments per
human per year.
Or, are you just worried right now because lightning isn't well tested?
>
>>
>> If you have the lower 32 bits of data to use, and 2^32=4,294,967,296,
>> then you have 4,294,967,296 milli satoshis. 1 BTC=10^11 milli satoshis,
>> so 4,294,967,296 milli satoshis/((10^11 milli satoshis)/1BTC) =
>> 0.04294967296 BTC. That is off by 1 milli satoshi from what you say
>> above. Why is this?
>>
>
> You have an off-by-one error. The largest number representable by 32
> bits is 2^32 - 1, not 2^32.
Okay, thanks for the clarification.
>
>>
>> Regardless of the discrepancy of 1 milli satoshi, it still seems like
>> 0.04294967296 BTC is kind of a low maximum channel size for a lot of
>> business applications. Why do you want to limit this when you have those
>> extra 4 bytes set to zero? You think any more is too much to safely have
>> in a hot wallet? You felt keeping it low will encourage
>> decentralization? Something else?
>>
>
> This is not the channel size. This is the payment size limit. The
> channel size limit is 0.16777215 BTC, or 16777215 satoshi (2^24 - 1).
>
> A single payment can be up to 0.04294967295, but a channel is up to
> 0.16777215.
Okay, so why bother making these two amounts different?
>
>>
>> Is the max HTLC value the same as the maximum channel size?
>>
>>
>
> No
>
>>
>> Is the optional initial push of millisatoshis during the channel
>> creation there in order to motivate the other party to be
>> willing to
>> waste their time with the channel creation in the first
>> place? If not,
>> what's it for?
>> It's for the common case where you want to connect to someone and
>> make a payment immediately. I'm not sure how widely it will
>> be used,
>> though. It's also the only mechanism for the payer to have
>> /zero/ funds
>> in channel (ie. below reserve).
>>
>>
>> Why would you ever want to start up a channel and immediately have zero
>> funds in reserve? If you are doing that, why not just make a blockchain
>> transaction?
>>
>
> An exchange might support this. You buy for example 100USD worth of
> BTC and indicate a desire to open a new channel between your node to
> the exchange's. The exchange opens the channel with your node and
> specifies the push_msat equivalent of 100USD minus fees to your node.
> The exchange will want to do this because your new channel goes
> directly to the exchange and it can earn routing fees from your
> spending. Presumably you want to do this so that you can spend your
> 100USD on Lightning for things within a short time frame.
>
> The alternative is to send the money from the exchange onchain to you,
> then for your node to open a new channel (not necessarily to the
> exchange, too, so the exchange loses the routing fees) with the
> onchain funds. This is two onchain transactions (from exchange to
> you, and from your node to a Lightning channel), unlike the case where
> the exchange does a single open and reassigns the funds to you via
> push_msat.
>
> Both you and the exchange would want to do this: the exchange wants
> this so it can capture your routing fees, you want this so that you do
> not even touch the chain at all and start out in Lightning in the
> first place.
Okay, so all this feature is doing is saving the extra step of making an
initial payment? Just saving a little time, and not a monumental or
required feature?
Thanks,
Andy Schroder
>
> Regards,
> ZmnSCPxj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20171227/8e8c3749/attachment.html>

2023-06-09 14:48:08 CEST

- reply

📅 Original date posted:2017-12-27
📝 Original message:
Andy Schroder
On 12/18/2017 01:40 PM, Rusty Russell wrote:
> Andy Schroder <info at AndySchroder.com> writes:
>> What's the rational for using millisatoshis as the units for lightning
>> channels? Aren't you going to loose up to 1/2 of a satoshi when the
>> channel is closed?
> You can lose up to 0.999 satoshi per in-progress payment, yes. BOLT #3:
>
> The amounts for each output MUST be rounded down to whole satoshis.
Okay, round down, not regular rounding!
>
>> Is this because it doesn't hurt and you might as well
>> be open to the opportunity for these sub satoshi transactions, because
>> if you aren't, you are giving up the opportunity to get accumulated
>> revenue from many of those small transactions, that could end up being
>> greater than 1/2 of a satoshi?
> In practice, payments of less than a few thousand satoshi are
> impractical, as they cost more than that to spend.
They are impractical even on the lightning network?
> Channel closing
> costs dwarf the gains to be made from cheating, however.
>
>> Since millisatoshis is used, is there a maximum channel funding size?
> Yes, the upper 32 bits must be zero, from BOLT #2:
>
> - for channels with `chain_hash` identifying the Bitcoin blockchain:
> - MUST set the four most significant bytes of `amount_msat` to 0.
>
> This gives a maximum HTLC value of .04294967295 BTC, which, back when
> we started, was about $10.
What's the point of wasting the upper 32 bits? Seems like this is a
waste of data?
If you have the lower 32 bits of data to use, and 2^32=4,294,967,296,
then you have 4,294,967,296 milli satoshis. 1 BTC=10^11 milli satoshis,
so 4,294,967,296 milli satoshis/((10^11 milli satoshis)/1BTC) =
0.04294967296 BTC. That is off by 1 milli satoshi from what you say
above. Why is this?
Regardless of the discrepancy of 1 milli satoshi, it still seems like
0.04294967296 BTC is kind of a low maximum channel size for a lot of
business applications. Why do you want to limit this when you have those
extra 4 bytes set to zero? You think any more is too much to safely have
in a hot wallet? You felt keeping it low will encourage
decentralization? Something else?
Is the max HTLC value the same as the maximum channel size?
>
>> Is the optional initial push of millisatoshis during the channel
>> creation there in order to motivate the other party to be willing to
>> waste their time with the channel creation in the first place? If not,
>> what's it for?
> It's for the common case where you want to connect to someone and
> make a payment immediately. I'm not sure how widely it will be used,
> though. It's also the only mechanism for the payer to have *zero* funds
> in channel (ie. below reserve).
Why would you ever want to start up a channel and immediately have zero
funds in reserve? If you are doing that, why not just make a blockchain
transaction?
>
>> In all of the clients that I've looked at, I can't seem to find out how
>> to define the timeout closing out a channel when someone does not
>> cooperate. Is there a fixed value for this as part of the protocol? Or
>> do most clients have a default that they enforce over all channels that
>> they create?
> If there's no in-progress payment, there's no reason to close a channel
> to an unreachable peer, unless you want to abandon the channel and get
> the funds back.
>
> If there is, BOLT #2 has you covered:
>
> https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#requirements-8
Okay, so every time you get a new HTLC, your client can change the
timeout that you require for closing the channel, which will control how
long it takes you to abandon the channel and get your funds back when
the peer is unreachable? Or is that set during initial channel creation
only?
>
> Hope that helps,
> Rusty.
>

2023-06-09 14:48:07 CEST

- reply

📅 Original date posted:2017-12-17
📝 Original message:
What's the rational for using millisatoshis as the units for lightning
channels? Aren't you going to loose up to 1/2 of a satoshi when the
channel is closed? Is this because it doesn't hurt and you might as well
be open to the opportunity for these sub satoshi transactions, because
if you aren't, you are giving up the opportunity to get accumulated
revenue from many of those small transactions, that could end up being
greater than 1/2 of a satoshi?
Since millisatoshis is used, is there a maximum channel funding size?
Is the optional initial push of millisatoshis during the channel
creation there in order to motivate the other party to be willing to
waste their time with the channel creation in the first place? If not,
what's it for?
In all of the clients that I've looked at, I can't seem to find out how
to define the timeout closing out a channel when someone does not
cooperate. Is there a fixed value for this as part of the protocol? Or
do most clients have a default that they enforce over all channels that
they create?
Thanks,
--
Andy Schroder

2023-06-07 19:52:21 CEST

- reply

📅 Original date posted:2016-08-08
📝 Original message:On 08/08/2016 11:00 AM, Jonas Schnelli via bitcoin-dev wrote:
> # ___known-peers___ contains known identity-public-keys together with a
> network identifier (IP & port), similar to the "known-host" file
> supported by openssh.
I have mixed feelings about strictly tying the identity-public-keys with
a network identifier. I think the purpose of this is to detect if
someone has physically stolen and compromised my bitcoin node and placed
it on another network under control of an attacker. This seems to be a
bit of a benefit, however, an attacker could always spoof the original
network identifier anyway.
I run my bitcoin node on an internet connection that does not guarantee
a static IP address (although it usually stays the same for several
weeks or months at a time). I'd like to be able to make secure
connections back to my own node, even if I know the IP address may
change from time to time. There are several reasons for wanting to this
with a changing IP. The first is because the bandwidth on my internet
connection with a guaranteed static IP address is considerably more
expensive than my internet connection without a guaranteed static IP
address. The second reason is because the DNS PTR record for my static
IP address is personally identifiable based on other reasons/services.
The internet connection that my bitcoin node is using without a
guaranteed static IP address just has a PTR record that basically
includes my IP address and ISP name. This isn't much use to the general
public (although my ISP obviously knows who I am). The third reason is
that I consider it a good thing from a privacy perspective if my IP
address changes every once and a while.
Maybe a strict check option where the identity-public-keys must
optionally match a specific network identifier would be a compromise?
Maybe this is up to the client implementation to decide, so it should
just be suggested in the BIP rather than required?
> # ___authorized-peers___ contains authorized identity-public-keys
Is there an option for a wildcard here? Couldn't there be a case where
the client wants to authenticate, but the bitcoin node does not care who
it's clients are? This would be similar to many of the http based
bitcoin block explorer API services that are out there. The API
operators have built up some reputation, so people use them, but they
don't necessarily care about who their users are.
> === Local identity key management ===
> Each peer can configure one identity-key (ECC, 32 bytes) per listening
> network interface (IPv4, IPv6, tor).
What if I have bitcoind listening on multiple IPv4 interfaces? Can I
have a different identity-key for each IPv4 interface?
Also, would it be possible to only allow this authentication on specific
interfaces? In my example above where I have two internet connections,
if you don't agree to loosening the tie between the network identifier
and the identity-public-keys, maybe I would just connect my bitcoin node
to both internet connections, but only allow a few authorized-peers on
the static IP (which would be low bandwidth), and then not authenticate
on the internet connection with the changing IP at all
If you don't want to increase complexity by adding these options, one
could always accomplish the same thing by runing two instances of
bitcoind and pairing the two over a local network, it would just be a
waste of resources.
> == Disadvantages ==
>
> The protocol may be slow if a peer has a large authorized-peers database
> due to the requirement of iterating and hashing over all available
> authorized peers identity-public-keys.
Does openssh have this same problem?
I'm assuming this could be parallelized very easily, so it is not a huge
problem?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160808/819a2eb5/attachment-0001.sig>

2023-06-07 19:51:27 CEST

- reply

📅 Original date posted:2016-06-22
📝 Original message:>
> Only large merchants are able to maintain such an infrastructure;
> (even
> Coinbase recently failed at it, they forgot to update their
> certificate). For end users that is completely unpractical.
>
>
> Payment protocol is for when you buy stuff from purse.io
> <http://purse.io>, not really needed for face-to face transfers, end
> users, IMO.
I disagree with your statements. There are many face to face use cases
where the payment protocol is essential. Pretty much anything where the
payee's hardware device that the payer interacts with is automated in
public and/or operated or accessible by untrusted employees. In any of
those cases the software on the payee's hardware device can be modified.
Providing a signed payment request gives the payer additional confidence
that they are paying the correct person.
See some examples here: http://andyschroder.com/BitcoinFluidDispenser/2.3/
There was a secure bluetooth protocol that Andreas Schildbach and Eric
Voskuil and I were working on, but we never pulled it all the way
together. This would also need a two way exchange for a face to face
payment. This could be used without using some sort of key/certificate
verification service if being done between two humans who are the direct
senders and receivers of the payment and are using hardware that they
personally own (not necessarily the case of untrusted employees or
public vulnerable machines).
> The same benefit can be achieved without the complexity of BIP70, by
> extending the Bitcoin URI scheme. The requestor is authenticated using
> DNSSEC, and the payment request is signed using an EC private key. A
> domain name and an EC signature are short enough to fit in a
> Bitcoin URI
> and to be shared by QR code or SMS text.
>
> bitcoin:address?amount=xx&message=yyy&name=john.example.com
> <http://john.example.com>&sig=zzz
>
>
> I agree. A TXT record at that name could contain the pubkey.
Did you not see my previous message about the size of the bitcoin: URI
getting too big for NFC and QR codes? Do you not care about giving the
payer the option of using multiple destination payment addresses? This
is important for many reasons.
> That extension is sufficient to provide authenticated requests,
> without
> requiring a https server. The signed data can be serialized from the
> URI, and DNSSEC verification succeeds without requesting extra
> data from
> the requestor. The only assumption is that the verifier is able to
> make
> DNS requests.
>
>
> The problem is that there's no way for a merchant to /refuse /a
> payment without a direct communication with the merchant's server.
> Verify first / clear later is the rule. Check stock, ensure you can
> deliver, and clear the payment on the way out the door.
So, are you saying first the payer should send an unsigned transaction
for review, and then once the payee has agreed it's good, they can send
an ACK message back and then wait for the signed version? I don't think
this is a bad option to have. Many wallets simultaneously broadcast a
signed transaction to their peers and and also back to the payee via
https or bluetooth. So, you'd have to add another step to do the
unsigned transaction review in order to avoid a transaction being
accidentally broadcast that both parties don't like.
>
> Also, as a merchant processing monthly subscriptions, you don't want
> the first time you hear about a user's payment to be /after /it hits
> the blockchain. You could add a refund address to deal with it after
> the fact... stuff a refund address int OP_RETURN somehow?
>
> bitcoin:address?amount=xx&currency=ccc&message=yyy&name=john.example.com
> <http://john.example.com>&offset=3d&interval=1m&sig=zzz
Again, my comments above about issues with using bitcoin: URI for
everything. Also, why do you want to bloat the blockchain with
unnecessary refund transaction data?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160622/9ae17eed/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160622/9ae17eed/attachment.sig>

2023-06-07 19:51:17 CEST

- reply

📅 Original date posted:2016-06-21
📝 Original message:Bluetooth exchange of payment requests already has a noticeable lag with
protocol buffers, so that would be another reason to argue against JSON,
because JSON is less efficient size wise, correct? I will say that
although protocol buffers have good platform support, I don't know that
the documentation for each platform is very good. This is the main
drawback I see with them. One additional advantage of protocol buffers
is that the .proto file is a specification, whereas with JSON, you'd
just have an example file, right?
Isn't keybase a centralized infrastructure? Are you against a blockchain
based identification? There are a few out there. There is some confusion
because onename's efforts are breaking away from namecoin though.
I like the idea of PGP signatures of payment requests. This allows for
manual verification (in my mind, the highest quality) of key
authenticity (or, with PGP you also have the option to opt into some
centralized service for key verification). This can be useful when
dealing with semi-manually issued invoices for goods and services. The
local bitcoin wallet could just interact with the local PGP keyring.
Although, one can already just send the payment request in a PGP signed
e-mail, so I'm not sure if PGP signing is really needed if you're using
PGP email. The main benefit may just be consolidating/itemizing into
your bitcoin wallet's transaction history whether the payment
destination/request was securely received or not. It may also be useful
for someone to be able to extract a signed payment request from a signed
PGP e-mail and send it to someone else to make a payment for you (maybe
you don't want your accounting person to need your entire e-mail
correspondence with a supplier to be able to just verify the payment
request and make a payment for your company).
I'm concerned about extending the URI scheme too much. Isn't this going
to reach the practical size limit of NFC and QR codes pretty quickly?
Andy Schroder
On 06/21/2016 05:43 AM, Andreas Schildbach via bitcoin-dev wrote:
> Protobuf vs. JSON was a deliberate decision. Afaik Protobuf was chosen
> because of its strong types, less vulnerability to malleability and very
> good platform support. Having coded both, I can say Protobuf is not more
> difficult than JSON. (Actually the entire Bitcoin P2P protocol should be
> based on Protobuf, but that's another story.)
>
> Yes, all extensions to BIP70 should go into new BIPs. Note the plural
> here: if you have orthogonal ideas I strongly suggest one BIP per idea
> so they can be discussed and implemented (or rejected) separately.
>
>
> On 06/20/2016 07:33 PM, Erik Aronesty via bitcoin-dev wrote:
>> BIP 0070 has been a a moderate success, however, IMO:
>>
>> - protocol buffers are inappropriate since ease of use and extensibility
>> is desired over the minor gains of efficiency in this protocol. Not too
>> late to support JSON messages as the standard going forward
>>
>> - problematic reliance on merchant-supplied https (X509) as the sole
>> form of mechant identification. alternate schemes (dnssec/netki), pgp
>> and possibly keybase seem like good ideas. personally, i like keybase,
>> since there is no reliance on the existing domain-name system (you can
>> sell with a github id, for example)
>>
>> - missing an optional client supplied identification
>>
>> - lack of basic subscription support
>>
>> /Proposed for subscriptions:/
>>
>> - BIP0047 payment codes are recommended instead of wallet addresses when
>> establishing subscriptions. Or, merchants can specify replacement
>> addresses in ACK/NACK responses. UI confirms are /required /when there
>> are no replacement addresses or payment codes used.
>>
>> - Wallets must confirm and store subscriptions, and are responsible for
>> initiating them at the specified interval.
>>
>> - Intervals can /only /be from a preset list: weekly, biweekly, or 1,
>> 2,3,4,6 or 12 months. Intervals missed by more than 3 days cause
>> suspension until the user re-verifies.
>>
>> - Wallets /may /optionally ask the user whether they want to be notified
>> and confirm every interval - or not. Wallets that do not ask /must
>> /notify before initiating each payment. Interval confirmations should
>> begin at /least /1 day in advance of the next payment.
>>
>> /Proposed in general:
>> /
>> - JSON should be used instead of protocol buffers going forward. Easier
>> to use, explain extend.
>>
>> - "Extendible" URI-like scheme to support multi-mode identity mechanisms
>> on both payment and subscription requests. Support for keybase://,
>> netki:// and others as alternates to https://.
>>
>> - Support for client as well as merchant multi-mode verification
>>
>> - Ideally, the identity verification URI scheme is somewhat
>> orthogonal/independent of the payment request itself
>>
>> Question:
>>
>> Should this be a new BIP? I know netki's BIP75 is out there - but I
>> think it's too specific and too reliant on the domain name system.
>>
>> Maybe an identity-protocol-agnostic BIP + solid implementation of a
>> couple major protocols without any mention of payment URI's ... just a
>> way of sending and receiving identity verified messages in general?
>>
>> I would be happy to implement plugins for identity protocols, if anyone
>> thinks this is a good idea.
>>
>> Does anyone think https:// or keybase, or PGP or netki all by
>> themselves, is enough - or is it always better to have an extensible
>> protocol?
>>
>> - Erik Aronesty
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160621/6970aa58/attachment.sig>

2023-06-07 17:40:59 CEST

- reply

📅 Original date posted:2015-06-28
📝 Original message:Regarding privacy and the lightening network. Has this been well
addressed? I haven't seen much that leads me to believe there is. Only
options I see are to have many open payment channels, but that is still
limiting and inefficient, or require an extensive number of hops in your
payment route, but this is also limiting.
Andy Schroder
On 06/28/2015 06:07 PM, Adam Back wrote:
> On 28 June 2015 at 23:05, Gavin Andresen <gavinandresen at gmail.com> wrote:
>> On Sun, Jun 28, 2015 at 2:58 PM, Adam Back <adam at cypherspace.org> wrote:
>>> This is probably going to sound impolite, but I think it's pertinent.
>>>
>>> Gavin, on dwelling on the the fact that you appear to not understand
>>> the basics of the lightning network, I am a little alarmed about this
>> If I don't see how switching from using the thousands of fully-validating
>> bitcoin nodes with (tens? hundreds?) of Lightning Network hubs is better in
>> terms of decentralization (or security, in terms of Sybil/DoS attacks),
> Its a source routed network, not a broadcast network. Fees are
> charged on channels so
> DoS is just a way to pay people a multiple of bandwidth cost.
>
> in terms of trustlessness Andrew Lapp explained it pretty well:
>> I don't mind a set of central authorities being part of an option IF the central authority
>> doesn't need to be trusted. On the blockchain, the larger miner is, the more you have
>> to trust them to not collude with anyone to reverse your payments or destroy the trust
>> in the system in some attack. On the Lightning network, a large hub can't steal my
>> money.
>>
>> I think most people share the sentiment that trustlessness is what matters and
>> decentralization is just a synonym for trustlessness when talking about the blockchain
>> and mining, however decentralization isn't necessarily synonymous with trustlessness
>> nor is centralization synonymous with trust-requiring when you're talking about
>> something else.
> Gavin wrote:
>> then I doubt other people do, either. You need to do a better job of explaining it.
> I gave it a go a couple of posts up. I didnt realise people here
> proposing mega-blocks were not paying attention to the whole lightning
> concept and detail.
>
> People said lots of things about how it's better to work on lightning,
> to scale algorithmically, rather than increasing block-size to
> dangerously centralising proportions.
> Did you think we were Gish Galloping you? We were completely serious.
>
> The paper is on http://lightning.network
>
> though it is not so clearly explained there, however Joseph is working
> on improving the paper as I understand it.
>
> Rusty wrote a high-level blog explainer: http://rusty.ozlabs.org/?p=450
>
> though I don't recall that he got into recirculation, negative fees
> etc. A good question
> for the lightning-dev mailing list maybe.
>
> http://lists.linuxfoundation.org/pipermail/lightning-dev/
>
> There are a couple of recorded presentation videos / podcasts from Joseph Poon.
>
> sf bitcoin dev presentation:
>
> https://www.youtube.com/watch?v=2QH5EV_Io0E
>
> epicenter bitcoin:
>
> https://www.youtube.com/watch?v=fBS_ieDwQ9k
>
> There's a related paper from Christian Decker "Duplex Micropayment Channels"
>
> http://www.tik.ee.ethz.ch/file/716b955c130e6c703fac336ea17b1670/duplex-micropayment-channels.pdf
>
>> But even if you could convince me that it WAS better from a
>> security/decentralization point of view:
> We don't need to convince people, we just have to code it and
> demonstrate it, which people are working on.
>
> But Lightning does need a decentralised and secure Bitcoin network for
> anchor and reclaim transactions, so take it easy with the mega-blocks
> in the mean-time.
>
>> a) Lightning Network is nothing but a whitepaper right now. We are a long
>> way from a practical implementation supported by even one wallet.
> maybe you want to check in on
>
> https://github.com/ElementsProject/lightning
>
> and help code it.
>
> I expect we can get something running inside a year. Which kind of
> obviates the burning "need" for a schedule into the far future rising
> to 8GB with unrealistic bandwidth growth assumptions that will surely
> cause centralisation problems.
>
> For block-size I think it would be better to have a 2-4 year or one
> off size bump with policy limits and then re-evaluate after we've seen
> what lightning can do.
>
> I have been saying the same thing ad-nauseam for weeks.
>
>> b) The Lightning Network paper itself says bigger blocks will be needed even
>> if (especially if!) Lightning is wildly successful.
> Not nearly as big as if you tried to put the transactions it would
> enable on the chain, that's for sure! We dont know what that limit is
> but people have been imagining 1,000 or 10,000 transactions per anchor
> transaction. If micro-payments get popular many more.
>
> Basically users would park Bitcoins a on a hub channel instead of the
> blockchain. The channel can stay up indefinitely, and the user has
> assurances analogous to greenaddress time-lock mechanism
>
> Flexcap maybe a better solution because that allows bursting
> block-size when economically rational.
>
> Note that the time-locks with lightning are assumed to be relative
> CTLV eg using the mechanism as Mark Friedenbach described in a post
> here, and as implemented in the elements sidechain, so there is not a
> huge rush to reclaim funds. They can be spread out in time.
>
> If you want to scale Bitcoin - like really scale it - work on
> lightning. Lightning + a decentralised and secure Bitcoin, scales
> further and is more trustless than Bitcoin forced into centralisation
> via premature mega-blocks.
>
> To my mind a shorter, more conservative block-size increase to give a
> few years room is enough for now. We'll be in a better position to
> know what the right next step is after lightning is running.
>
> Something to mention is you can elide transactions before reclaiming.
> So long as the balancing transaction is correct, someone online can
> swap it for you with an equal balance one with less hops of
> intermediate payment flows.
>
>
> It's pretty interesting what you can do already. I'm fairly confident
> we're not finished algorithmically optimising it either. It's
> surprising how much new territory there is just sitting there
> unexplored.
>
> Adam
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 555 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150628/5a17cd68/attachment.sig>

2023-06-07 17:31:09 CEST

- reply

📅 Original date posted:2015-02-24
📝 Original message:Andy Schroder
On 02/23/2015 10:09 AM, Jan Vornberger wrote:
> 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'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?
What command line tool are you using with libnfc?
>
>> 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.
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? Wouldn't it be better to just manage everything yourself?
>
>> 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.
I'm personally not to annoyed by the enable bluetooth popup. I do know
what you mean about the "bluetooth is insecure, I should disable it"
attitude. I used to have this same concern.
>
> 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.
Well, with the multiple r parameters, they should also be able to do
this on the payment request too.
>
> 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.
I'm personally very weary of more permissions. Have you checked out how
many unnecessary permissions a lot of bitcoin wallets have? Many of them
are ridiculous. Although this one may be somewhat warranted, I wouldn't
encourage it if they can just fall back to cellular if they don't want
to use bluetooth. If they don't have cellular reception, they can go
through the effort of pressing the enable button that pops up.
>
>> 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
>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 555 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150224/10953415/attachment.sig>

2023-06-07 17:31:03 CEST

- reply

📅 Original date posted:2015-02-24
📝 Original message:I was saying provide a public key via NFC (or a public key fingerprint
and then send the full public key over bluetooth). Instead of providing
a new public key on each tap, why can't the payee just stop accepting
connections from new parties on that "resource" after a session key has
been received from the first person? If the person decides to have there
friend or family pay for them instead and cancel the payment, they could
just hit cancel on the POS or something (on my fuel pump I have a switch
that needs to be turned, the purpose of this is to avoid wasting too
many addresses) and/or do another NFC tap (if you're providing QR codes
you'd still need a button of some kind though so it knows to refresh
it), or the POS can just provide a completely new payment request to any
new connections on that same "resource" which use a different session key.
I feel like the authentication of the payer to the payee in any future
connections after they receive the session key from them (which was
encrypted with the payees public key), comes from the fact that they are
sending responses back that are encrypted using the session key they
gave to the payee. The way I am seeing it is that the NFC tap or QR code
scan is acting in addition to the visual name check on the signature
verification in the wallet. If the certificate used isn't signed by a CA
(self signed), it may be fine as long as you heard about it via NFC or
QR code. I don't think it will require PKI and should still work
wallet-to-wallet.
It sounds like you are saying I'm proposing the customer is going to
need a certificate signed by CA? If so, why? I don't need this for any
https website I visit. It's not like the payee is sending anything to
the payer that is private. The payment request only becomes private if
something is actually received to it, otherwise, it is just discarded
and it doesn't matter. Those bitcoin addresses are never used. It's just
like a shopping cart on a website where someone aborts payment and
cancels the order.
At one point I was thinking we could do something similar to Mike
Hearn's suggestion in another recent e-mail where we re-use some
existing part of the bitcoin URI to bootstrap some trust in a public key
that the payee next sends via bluetooth after the NFC connection. Now
that I'm reviewing my notes though, I can't see how this will work with
a watching only wallet or if no backwards compatible (to BIP21) bitcoin
address is presented in the URI (as Mike said).
What I was saying above about how you can stop accepting connections on
that "resource" after a session key has been received by the first
person could be problematic though. An evil person could just start
making connections to every device they can, just to be mean, which
would not allow the POS operator to receive payments from their real
customers. If you do the other option I proposed, which is to just keep
giving out new payment requests, you have other problems (on top of
wasting addresses), which are that you can still have mean people giving
you a denial of service attach on your hardware, or you could have an
unusual situation where two people pay (don't know why they would do
this though), so that is why I'm suggesting a manual tap or button press
or switch turn being required.
I guess as more of a abuse filter, a new "resource" could be given
instead with each tap, and the POS would just ignore all requests to an
inactive resource. You may say, why not send a new public key (as you
suggested) instead of a new "resource" with each tap (or button press if
using QR codes), and then you can skip the sending of a static public
key (or public key fingerprint), and ignore any data that is not
encrypted with that public key. Maybe that is a better idea because it
will shorten the bitcoin URI. However, I don't think its required from a
privacy standpoint, it primarily just aids in combining the public key
fingerprint with the changing "resource" name used to filter abuse. Or,
am I missing something?
So, after thinking through the abuse scenarios I mentioned above, I
think I am agreeing with you, but the reason I'm writing all this is to
hopefully just get some feedback on my logic to learn something from
this discussion. I do think sending a unique public key over NFC has to
be better than a unique session key. It adds one more step, but seems to
help. If we do this, can we then safely get rid of the h= parameter?
That should make Mike Hearn happy, and also may alleviate the base64url
debate?
Andy Schroder
On 02/23/2015 09:55 PM, Eric Voskuil wrote:
> Andy, adding to my previous post below:
>
> On 02/23/2015 01:40 AM, Eric Voskuil wrote:
>> On 02/22/2015 11:36 PM, Andy Schroder wrote:
> ...
>>> It's possible a really sophisticated modification could be done where
>>> the attacker encrypts and decrypts the communication and then relays to
>>> each party (without them knowing or any glitches detected), but I guess
>>> I'm not sure how easy that would be on such a close proximity device?
>> If the NFC tap is sufficiently private, privacy is easy to achieve for
>> the subsequent communication. If it is not, privacy can be completely
>> compromised. The question is only how much more difficult is the attack.
>>
>> With the public cert tap, the level of difficulty is much lower for
>> capturing selected payment requests. The interloper no longer needs to
>> invade the space of the NFC terminal and can instead impersonate the
>> payer from a safe distance. Nobody gets paid, but privacy is compromised.
> This problem in the preceding paragraph can be resolved by sending a
> unique public key on each NFC tap. In that case an attacker would need
> to monitor the NFC communication.
>
> The talk of wrapping the connection in SSL led me to believe you were
> talking about a static public certificate. However that's not a
> necessary assumption here and may not be what you intended.
>
>> The level of difficulty in the case where the interloper wants to taint
>> transactions may appear lower, but it is not:
>>
>> With the session key tap the interloper must compromise the NFC location
>> and then monitor the BT traffic. Monitoring BT traffic without being
>> party to the connection is presumably not rocket surgery, but not
>> standard BT design either.
>>
>> With the public cert tap the interloper must also compromise the NFC
>> location and communicate over BT. Therefore the hardware and physical
>> attack requirements are similar. The only added difficulty is that the
>> attack on the NFC terminal attack is active (modifying the MAC address
>> directing the payer to the BT service).
> I believe your central claim was that the difference in the two
> bootstrapping approaches (public key vs. session key) is that by using a
> unique public key per tap, the attack requires an active vs. passive
> attack on the NFC terminal. I just wanted to make clear here that I
> agree with that assessment.
>
> The symmetric key approach is based on the idea that these attacks are
> comparable in difficulty and otherwise identical in privacy loss.
>
> However, the difference in implementation amounts to about +23
> additional encoded characters for the BT/LE URL, assuming use of the
> secp256k1 curve for DHE. This is really not a material issue in the case
> of the NFC tap. The entire URI+URL could be as small as:
>
> bitcoin:?r=bt:12rAs9mM/79bq48xJaMgqR9YNxnWhqHHM1JB52nxn6VFXBHTP2zrP
>
> In comparison to a symmetric key:
>
> bitcoin:?r=bt:12rAs9mM/12drXXUifSrRnXLGbXg8E
>
> It also does not change the protocol design or complexity at all - it
> would just swap out an AES key for a secp256k1 public key.
>
> bitcoin:[address]?bt:<mac>/<key>
>
> If that gets us aligned I'm all for it.
>
>> However impersonating the payer is just a matter of software - no more
>> difficult than the session key attack. In fact it may be much easier to
>> implement, as the attack can use supported BT features because the
>> attacker has directed the payer to connect to him and is connecting to
>> the receiver as if he was a payer.
>>
>> But it gets worse for the public cert tap, since a more sophisticated
>> attacker can set himself up in the same position without subverting the
>> NFC terminal at all. By broadcasting a more powerful BT service on the
>> same advertised MAC address, the attacker can capture traffic and relay
>> it to the intended service.
> I'm retracting the last paragraph, since the interloper, without
> invading the NFC connection (by substituting the public cert), could not
> read the relayed traffic. It was getting late :/
>
>> So in sum, reliance on a public cert makes the communication less
>> private under the same physical set of constraints. The difference
>> results from the receiver allowing non-proximate payers to impersonate
>> proximate payers from a distance by generating their own session keys
>> and submitting them over BT.
> e
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 555 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150224/79085253/attachment.sig>

2023-06-07 17:31:01 CEST

- reply

📅 Original date posted:2015-02-23
📝 Original message:I agree that NFC is the best we have as far as a trust anchor that you
are paying the right person. The thing I am worried about is the privacy
loss that could happen if there is someone passively monitoring the
connection. So, in response to some of your comments below and also in
response to some of Eric Voskuil's comments in another recent e-mail:
Consider some cases:
If NFC is assumed private, then sending the session key over the NFC
connection gives the payer and the payee assumed confidence that that a
private bluetooth connection can be created.
If the NFC actually isn't private, then by sending the session key over
it means the bluetooth connection is not private. An eavesdropper can
listen to all communication and possibly modify the communication, but
the payer and payee won't necessarily know if eavesdropping occurs
unless communication is also modified (which could be difficult to do
for a really low range communication).
If we send a public key of the payee over the NFC connection (in place
of a session key) and the NFC connection is assumed trusted (and is
unmodified but actually monitored by an eavesdropper) and use that
public key received via NFC to encrypt a session key and send it back
via bluetooth, to then initiate an encrypted bluetooth connection using
that session key for the remaining communication, then the payee still
receives payment as expected and the payer sends the payment they
expected, and the eavesdropper doesn't see anything.
If we send a public key of the payee over the NFC connection (in place
of a session key) and the NFC connection is assumed trusted (and is
actually modified by an eavesdropper) and use that public key received
via NFC to encrypt a session key and send it back via bluetooth, to then
initiate an encrypted bluetooth connection using that session key for
the remaining communication, then the payee receives no payment and the
attack is quickly identified because the customer receives no product
for their payment and they notify the payee, and hopefully the problem
remedied and no further customers are affected. The privacy loss will be
significantly reduced and the motive for such attacks will be reduced.
It's possible a really sophisticated modification could be done where
the attacker encrypts and decrypts the communication and then relays to
each party (without them knowing or any glitches detected), but I guess
I'm not sure how easy that would be on such a close proximity device?
Erick Voskuil mentioned this same problem would even occur if you had a
hardwired connection to the payment terminal and those wires were
compromised. I guess I still think what I am saying would be better in
that case. There is also more obvious physical tampering required to
mess with wires.
I'm not sure if there is any trust anchor required of the payer by the
payee, is there? Eric also mentioned a need for this. Why does the payer
care who they are as long as they get a payment received? Just to avoid
a sophisticated modification" that I mention above? I can see how this
could be the case for a longer range communication (like over the
internet), but I'm not convinced it will be easy on really short ranges?
It's almost like the attacker would be better off to just replace the
entire POS internals than mess with an attack like that, in which case
everything we could do locally (other than the payment request signing
using PKI), is useless.
I'm not a cryptography expert so I apologize if there is something
rudimentary that I am missing here.
Andy Schroder
On 02/22/2015 08:02 PM, Andreas Schildbach wrote:
> On 02/23/2015 12:32 AM, Andy Schroder wrote:
>> I guess we need to decide whether we want to consider NFC communication
>> private or not. I don't know that I think it can be. An eavesdropper can
>> place a tiny snooping device near and read the communication. If it is
>> just passive, then the merchant/operator won't realize it's there. So, I
>> don't know if I like your idea (mentioned in your other reply) of
>> putting the session key in the URL is a good idea?
> I think the "trust by proximity" is the best we've got. If we don't
> trust the NFC link (or the QR code scan), what other options have we
> got? Speaking the session key by voice? Bad UX, and can be eavesdropped
> as well of course.
>
>
>
> ------------------------------------------------------------------------------
> 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=190641631&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 555 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150223/90498cd6/attachment.sig>

2023-06-07 17:30:59 CEST

- reply

📅 Original date posted:2015-02-22
📝 Original message:Andy Schroder
On 02/22/2015 06:06 PM, Eric Voskuil wrote:
> On 02/22/2015 02:37 PM, Andy Schroder wrote:
>> I'd like to see some discussion too about securing the bluetooth
>> connection. Right now it is possible for an eavesdropper to monitor the
>> data transferred.
> Yes, this should be a prerequisite issue to all others.
>
>> I'd personally like to see if wrapping the current
>> connection with SSL works or if we can run https over a bluetooth
>> socket.
> There is no reason to add this significant complexity. The purpose of
> SSL/TLS is to establish privacy over a *public* channel. But to do so
> requires verification by the user of the merchant's public certificate.
> Once we rely on the channel being *private*, the entire SSL process is
> unnecessary.
I guess we need to decide whether we want to consider NFC communication
private or not. I don't know that I think it can be. An eavesdropper can
place a tiny snooping device near and read the communication. If it is
just passive, then the merchant/operator won't realize it's there. So, I
don't know if I like your idea (mentioned in your other reply) of
putting the session key in the URL is a good idea?
>
> Presumably we would not want to require PKI for privacy, since that's a
> bit of a contradiction. But if one wants to do this NFC is not required,
> since the private session can be established over the public (Bluetooth)
> network.
>
>> There was some criticism of this, but I don't think it has been
>> tested to know if it is really a problem or not. If we just run https
>> over bluetooth, then a lot of my concerns about the message header
>> inconsistencies will go away and the connection will also be secure. We
>> don't have to reinvent anything.
>>
>>
>>
>> Andy Schroder
>>
>> On 02/22/2015 02:08 PM, Jan Vornberger wrote:
>>> 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
>>>
>>> ------------------------------------------------------------------------------
>>>
>>> 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=190641631&iu=/4140/ostg.clktrk
>>>
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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=190641631&iu=/4140/ostg.clktrk
>>
>>
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 555 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150222/38815d05/attachment.sig>

2023-06-07 17:30:58 CEST

- reply

📅 Original date posted:2015-02-22
📝 Original message:Hello Jan,
Regarding a few of your questions:
Andreas and I had a number of private discussions regarding the
payment_url parameter. I had suggested a "additional_payment_urls"
repeated parameter, but he didn't seem to like that idea and I
personally am indifferent, so that is why we decided to just change
payment_url to a repeated field. The spec is simpler without the
"additional_payment_urls", but the wallets have to be a little bit
smarter finding the right url they want to use in the list. 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?
I had heard from Andreas a few weeks ago that the multiple r parameters
was not yet implemented. Maybe your interest can motivate him to do so!
I actually also happen to be using nfcpy. I am having some reliability
issues as well with it. What exactly are your problems?
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? In your video
it looks like the phone still has cellular and wifi reception (it is not
offline).
You mention workflow options 1,2,3. You forgot to mention that options
1,2 are not backwards compatible with older wallets.
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.
I don't really understand why Mike Hearn has the objections to the h
parameter. It seems like you should already be ready to produce the
BIP70 payment request at the time when the URI is generated. I'd also
like to clarify that the h parameter is for more than just unsigned
payment requests. You can have a signed payment request with the wrong
signer. There is way to much brainpower required to verify that the
signer is actually the merchant you are doing business with. Just think
how many times you shop at a store that you don't even know the name of.
Also, the store may contract their payment processing out to another
party, or they may have multiple store names but use the same payment
processing system for all their stores, and the parent company has a
different name. It's good to have both the h parameter AND the signed
payment request.
I don't really like the Airbitz proposal. Figuring out if your selecting
is the right one is a real nuisance. The idea is neat in a few
applications, but I just don't think it is going to work for people as
the most efficient and trouble free option day to day. I realize they
are probably doing it to work with Apple's limited functionality phones
(and BLE is a new buzz word). However, I don't think we should base
bitcoin around what Apple wants us to do. They've already had their war
on bitcoin. They are going to do whatever they can to protect their NFC
based payment system. We need to make their platform the the less
desirable one if they are going to play the game that way. If that means
an Airbitz like proposal is implemented as a fallback, maybe that is
fine and POS systems need to support both, but I just don't think we
should limit what we can do because of Apple's products capabilities.
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'd like to see some discussion too about securing the bluetooth
connection. Right now it is possible for an eavesdropper to monitor the
data transferred. I'd personally like to see if wrapping the current
connection with SSL works or if we can run https over a bluetooth
socket. There was some criticism of this, but I don't think it has been
tested to know if it is really a problem or not. If we just run https
over bluetooth, then a lot of my concerns about the message header
inconsistencies will go away and the connection will also be secure. We
don't have to reinvent anything.
Andy Schroder
On 02/22/2015 02:08 PM, Jan Vornberger wrote:
> 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
>
> ------------------------------------------------------------------------------
> 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=190641631&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x2D44186B.asc
Type: application/pgp-keys
Size: 1739 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150222/230a5e33/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 555 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150222/230a5e33/attachment.sig>