Hi Mike
Not sure if you've seen it, but here is how we do NFC right now
http://www.youtube.com/watch?v=DGOMIG9JUY8 with XBTerminal.
For now this is just an NDEF URI message with Bitcoin URI inside, and then
transaction itself propagated to the network by the phone using it's own
Internet
2014-03-08 8:52 GMT+00:00 Jan Vornberger j...@uos.de:
On Thu, Mar 06, 2014 at 02:39:52PM +, Alex Kotenko wrote:
Not sure if you've seen it, but here is how we do NFC right now
http://www.youtube.com/watch?v=DGOMIG9JUY8 with XBTerminal.
Very interesting, thanks for sharing
It heavily depends on where you use it. Here in UK any card payments are
often limited to minimum of £5 in small shops that have heavy transaction
fees burden and low margins. Big networks with more resources often let you
pay as little as you want by card, and they more often have NFC enabled POS
Ah, I see, so it's only payee who has to enable it, payer side is on by
default. Then fine, situation is better than I thought. We'll look at
implementing BIP70 asap.
Best regards,
Alex Kotenko
2014-03-10 19:28 GMT+00:00 Andreas Schildbach andr...@schildbach.de:
On 03/10/2014 04:09 PM, Alex
QR code format?
How much do we actually win in total bytes capacity at a price of
noncompatibility and increased complexity?
And also maybe we can extend BIP72 to include encoded payment request in
the URL directly in a backwards compatible way?
Best regards,
Alex Kotenko
2014-03-02 11:50 GMT+00
2014-03-20 8:08 GMT+00:00 Andreas Schildbach andr...@schildbach.de:
On 03/20/2014 03:22 AM, Alex Kotenko wrote:
Right now, before BIP70, I'm sending BIP21 URI via NFC or QR code, and I
need to still be able to use it for backwards compatibility. But at the
same time I want to be able
2014-03-20 17:31 GMT+00:00 Jeff Garzik jgar...@bitpay.com:
On Thu, Mar 20, 2014 at 8:12 AM, Adam Back a...@cypherspace.org wrote:
Whats a sensible limit on practical/convenient QR code size?
Extremely limited. Preferably under 100 bytes. You will see
increasingly poor operating in varying
Hmm, is there any other way to do it? Can we provide a signed payment
request and verify the sign on receiving side and this way protect from
bluetooth MitM attack? Quick googling showed that SSL over bluetooth isn't
a very well developed area, and my own skills are not enough to quickly
implement
, this overlaps somewhat with the PKI
signing in BIP70, but not entirely - you might want to serve unsigned
payment requests, but still have confidentiality and authenticity for a
local face to face transaction. The signing and encryption does different
things.
On Thu, Mar 20, 2014 at 7:20 PM, Alex Kotenko
2014-03-21 9:47 GMT+00:00 Andreas Schildbach andr...@schildbach.de:
On 03/20/2014 05:14 PM, Alex Kotenko wrote:
Hmm, if we're inventing an URI for bluetooth, I'd rather follow existing
URI's patterns. BT is strictly point-to-point connection, so BT MAC
should be considered as server
2014-03-21 14:51 GMT+00:00 Andreas Schildbach andr...@schildbach.de:
Quoting from RFC 3986, Section 3.4. Query: The characters slash (/)
and question mark (?) may represent data within the query component.
Ok.
So BIP72 with a BT URI in the 'r' parameter?
Yes.
I know that general approach to interaction design in Bitcoin assumes
minimal to no difference between payer and payee, and generally I agree
with this approach.
However, for the sake of my PoS development this assumption is wrong by
default, as PoS is a specialized hardware, and one who cared to
the nodelist.
So I've set up and will run a well connected testnet node, as we need it
for the XBTerminal.
Please let me know if I can somehow help to fix the DNS discovery issue
also.
Best regards,
Alex Kotenko
2014-05-16 17:46 GMT+01:00 Laszlo Hanyecz las...@heliacal.net:
It looks like
Ok, what do I need to do? How do I host a testnet seed myself?
Best regards,
Alex Kotenko
2014-05-16 23:02 GMT+01:00 Jeff Garzik jgar...@bitpay.com:
There are only two testnet seeds listed in bitcoind, and one of them
returns SERVFAIL (testnet-seed.bitcoin.petertodd.org) and the other
just
, and
also a well connected nodes for mainnet and testnet on the same server.
Is this a good plan? Will this all help?
Best regards,
Alex Kotenko
2014-05-17 12:39 GMT+01:00 Andreas Schildbach andr...@schildbach.de:
I think the best way to contribute to the infrastructure is actually
what we're
if someone else tries to reach your wallet
with his own NFC - how can we distinguish between deliberate redeem by
owner and fraudulent redeem by anybody else with custom built long
range NFC antenna? Any ideas?
Best regards,
Alex Kotenko
2014-05-17 17:40 GMT+01:00 Gregory Maxwell gmaxw
Yes, but it must not sacrifice usability. It's paper money, people are used
to it and they have rather high standard of expectations in this area. Any
usbility sacrifices in this area result into failure of the whole thing.
Best regards,
Alex Kotenko
2014-05-18 13:14 GMT+01:00 Andreas
putting your bitcoin wallet on it.
So really I see only issues of technical security in here, and this is
the problem I'm seeking solutions for.
Best regards,
Alex Kotenko
2014-05-18 14:50 GMT+01:00 Natanael natanae...@gmail.com:
Now you are talking about Trusted Platform Modules. Like
the notes
- he has control over physical object itself, ideally for a period of time.
With some active powered electronics in place it would be easy, but how do
we do it without anything active in place?
Best regards,
Alex Kotenko
2014-05-18 21:10 GMT+01:00 Natanael natanae...@gmail.com
Asking random ignorant stranger to care to protect themselves never works.
We need solution that requires strictly zero effort.
Best regards,
Alex Kotenko
2014-05-19 14:06 GMT+01:00 Brooks Boyd bo...@midnightdesign.ws:
2014-05-18 13:14 GMT+01:00 Andreas Schildbach andr...@schildbach.de
Hmm, this is firmcoin thing looks like what I mean. They don't have a
solution yet, and prices they quote smartcards are unacceptable, but if
they will manage to get down in selfcost - that may work. Ok, I'll follow
them and see what it will come to.
Best regards,
Alex Kotenko
2014-05-19 13:55
IP addresses for it. That's unfortunate as it needs
much more spendings from me to operate, second IP address will cost nearly
as much as the server itself.
Can anybody help with this? I cannot into C++ to fix that myself.
Best regards,
Alex Kotenko
2014-05-17 13:39 GMT+01:00 Andreas
, 2014, at 4:14 PM, Alex Kotenko alexy...@gmail.com wrote:
Hmm, I've mostly setup what's promised, testing DNS seeds now. There is
one problem I see that I can't really solve myself.
This dnsseed daemon cannot serve more than one name at once, which means
that I cannot serve testnet and mainnet
with testnet DNS seeder?
Best regards,
Alex Kotenko
2014-05-20 1:50 GMT+01:00 Robert McKay rob...@mckay.com:
On Tue, 20 May 2014 01:44:29 +0100, Robert McKay wrote:
On Mon, 19 May 2014 19:49:52 -0400, Jeff Garzik wrote:
On Mon, May 19, 2014 at 4:36 PM, Robert McKay rob...@mckay.com
wrote
Misunderstanding. Both seeds are available on port 53 via BIND forwarding.
Just also each DNS seed is available separately on it's own port.
Best regards,
Alex Kotenko
2014-05-21 12:03 GMT+01:00 Andreas Schildbach andr...@schildbach.de:
Great, thanks for this contribution!
Do you plan
seed
to help me debug
mine
?
Best regards,
Alex Kotenko
2014-05-30 10:43 GMT+01:00 Peter Todd p...@petertodd.org:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 27 May 2014 02:19:39 GMT+03:00, Andreas Schildbach
andr...@schildbach.de wrote:
Hey, really sorry I don't have
, but that isn't a good solution even if it might work for some
resolvers.
Rob
On Fri, 30 May 2014 15:13:36 +0100, Alex Kotenko wrote:
Hmm, you might be right, as queries
dig @node.alexykot.me [8] testnet-seed.alexykot.me [9]
and
dig @node.alexykot.me [10] -p 18353 testnet-seed.alexykot.me
[11
if all looks fine with this seed from your
side.
Best regards,
Alex Kotenko
2014-05-22 9:58 GMT+01:00 Andreas Schildbach andr...@schildbach.de:
Hi Alex,
I'm not sure if you saw this message.
Your seeds are not reachable from my ISP unfortunately.
Cheers,
Andreas
this involvement regulateable. Otherwise I
think the Bitcoin experiment will fail.
Best regards,
Alex Kotenko
2014-06-16 18:16 GMT+01:00 Lawrence Nahum lawre...@greenaddress.it:
Mike Hearn mike at plan99.net writes:
As long as miners stick to Satoshi's first seen rule, which is the
default, it's
It took some time but we have finally implemented bluetooth integration
offered by Andreas in our bitcoin payment terminals.
However it's not ideal at the moment. Basically the main problem is that
in the BIP72 there is no way to provide a fallback alternative URI for
payment request fetch if
In my mind it's not like the client's phone is going all directions at the
same time. There should be a priority method and fallback method(s). And I
see p2p radio as priority, and web as fallback, and BIP21 in the end as
always-working-default.
So I'm keeping support for it all while want to
a distinction here. Also
because of backwards compatibility to the status quo.
On 07/01/2014 03:03 PM, Alex Kotenko wrote:
In my mind it's not like the client's phone is going all directions at
the same time. There should be a priority method and fallback
method(s).
And I see p2p radio
Ok, agreed. I will submit a pull request to BIP72 then.
Not sure about escaping though. It is indeed not critical for bitcoin URIs,
but still it is a part of RFC, don't think we should go against it.
Andreas, we will implement this on our side, with bluetooth on r= and web
address on r1=.
33 matches
Mail list logo
