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=.
2014-0
is
> >> currently implemented that way. (We could however fix this in a
> >> maintenance release.)
> >>
> >> However, r= should also allow all other protocols, exactly like any of
> >> the r[]= params. I don't think we should do a distinction her
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 b
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 cli
True, enough philosophy. Once this BIP will be finalized - we will it's
schedule implementation in XBTerminal. This is a solution to the problem we
have, probably best one we have to date, so we will use it.
2014-06-16 19:09 GMT+01:00 Mike Hearn :
> I think many of us feel it'd be better if this
ght chance of making 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 :
> Mike Hearn plan99.net> writes:
>
> > As long as miners stick to Satoshi's first seen rule, which is
ow if all looks fine with this seed from your
side.
Best regards,
Alex Kotenko
2014-05-22 9:58 GMT+01:00 Andreas Schildbach :
> Hi Alex,
>
> I'm not sure if you saw this message.
> Your seeds are not reachable from my ISP unfortunately.
&
orative
> answer, 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
, assuming that NS record for
testnet-seed.alexykot.me is pointing at alexykot.me?
Best regards,
Alex Kotenko
2014-05-30 14:41 GMT+01:00 Robert McKay :
> Hi Alex,
>
> I think the problem is with my suggestion to use bind forwarding..
> basically bind is stripping off the authorative a
DNS
for your seed
to help me debug
mine
?
Best regards,
Alex Kotenko
2014-05-30 10:43 GMT+01:00 Peter Todd :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
>
>
> On 27 May 2014 02:19:39 GMT+03:00, Andreas Schildbach <
> andr...@schildbach.de> 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 :
> Great, thanks for this contribution!
>
> Do you plan to h
with testnet DNS seeder?
Best regards,
Alex Kotenko
2014-05-20 1:50 GMT+01:00 Robert McKay :
> 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
> >> wrote
-
> Michael Wozniak
>
>
> On May 19, 2014, at 4:14 PM, Alex Kotenko 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
need to buy two 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:
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-0
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 :
> >> 2014-05-18 13:14 GMT+01:00 Andreas Schildbach :
> >> One problem we couldn
redeeming 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 :
> The pro
hen you're 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 :
> Now you are talking about Trusted Platform Modules. Like
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 An
redeem. Like 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 :
tnet-seed.alexykot.me, 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 :
> I think the best way to contribute to the infrastructure is actually
>
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 :
> There are only two testnet seeds listed in bitcoind, and one of them
> returns SERVFAIL (testnet-seed.bitcoin.petertodd.org) and the other
> just retu
nually seed 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 :
> It looks like
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 b
2014-03-21 14:51 GMT+00:00 Andreas Schildbach :
>
> 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.
--
2014-03-21 10:28 GMT+00:00 Andreas Schildbach :
> On 03/20/2014 06:31 PM, Jeff Garzik wrote:
>
> >> Afaik, BIP73 needs an external server (the web server).
> >
> > Yes. Internet connectivity is not a rarity these days. Near-field
> > web servers also work fine.
>
> Unfortunately it still is. At
2014-03-21 9:47 GMT+00:00 Andreas Schildbach :
> 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
> > shou
e there could be radio MITM. Yes, 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 differe
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
2014-03-20 17:31 GMT+00:00 Jeff Garzik :
> On Thu, Mar 20, 2014 at 8:12 AM, Adam Back 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 light conditions, such as
> payi
2014-03-20 8:08 GMT+00:00 Andreas Schildbach :
> 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 t
43 to base64 encoded request in a binary 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
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 :
> On 03/10/2014 04:09 PM, Alex
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
2014-03-08 8:52 GMT+00:00 Jan Vornberger :
> On Thu, Mar 06, 2014 at 02:39:52PM +0000, 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, thank
2014-03-06 17:03 GMT+00:00 Mike Hearn :
> About the video - I'm curious how your device is better than just a
> regular tablet. Could you give us the elevator pitch? :)
sure, here:
- tougher than phone/tablet. Phone dropped on the tiled floor is likely to
die instantly. Our device is designed to
2014-03-06 16:46 GMT+00:00 Andreas Schildbach :
> Supporting Bluetooth is optional in the sense that if a wallet should
> not support it, you will still receive the transaction via the P2P
> network. So I'd say definately go for Bluetooth.
>
Yes, it's part of the plan. Just again - I need to mak
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 connecti
38 matches
Mail list logo
