Alex Kotenko [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2014-03-06 to 2014-07-02
💬 Posted a total of 38 messages
📚 Participated in the following categories: Bitcoin-development
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub14jv7tj33yt72yk8mljmvkck3p4xm5s3mxfpj289up38qqsn9dhkqeh00t4

Profile Code

nprofile1qqs2ex09egcj9l9ztraledktvtgs6nd6gganyse9rj7qcnsqgfjkmmqqhc7yw

Author Public Key

npub14jv7tj33yt72yk8mljmvkck3p4xm5s3mxfpj289up38qqsn9dhkqeh00t4

Show more details

Last Notes

2023-06-07 15:23:26

- reply

📅 Original date posted:2014-07-01
📝 Original message:Hmm, r1, r2 etc is actually interesting. It takes less chars then array
(yes, array brackets have to be escaped) and provides unlimited number of
options, uniformed approach and priority definition. I'd say that is the
way to go. Any objections?
On 1 Jul 2014 16:39, "Andreas Schildbach" <andreas at schildbach.de> wrote:
> Ok, one more idea:
> r= is used for the first URL, and we *think* of it as r0=
> additional URLs are appended as
> r1=
> r2=
> and so on. This would also define an ordering in case we need it.
>
>
> On 07/01/2014 05:07 PM, Michael Wozniak wrote:
> > Multiple parameters is currently undefined as far as I can tell. Should
> the client take the first, last, or ignore it completely if there are
> multiple of any parameter? I think that’s the point of the parameter
> pollution discussion, which will define it one way or the other.
> >
> > I’m only familiar with the Electrum implementation, which is currently
> checking for any duplicate parameters and treating the entire URI as
> invalid if duplicate parameters exist (following the parameter pollution
> suggestions).
> >
> > -
> > Michael Wozniak
> >
> > On Jul 1, 2014, at 10:59 AM, Andreas Schildbach <andreas at schildbach.de>
> wrote:
> >
> >> Does r[]= really need to be encoded as r%5B1%5D= ? In this case, I'd
> >> advocate for a simple array parameter name, like rs= ("plural" of r).
> >> Length really does matter for QR codes.
> >>
> >> I'm fine with either multiple r= params or exactly one r= plus zero to
> >> many r[]= params. Although I think it is a violation of the (current)
> >> spec to choke on more than one r= parameters, I admit that bitcoinj 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 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 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 be able to provide
> best
> >>> user experience.
> >>> Mike, a while ago in this thread you've described contactless cards
> >>> user experience. I'm also using contactless cards often, and what I'm
> >>> aiming at is creating same level of user experience for Bitcoin users.
> >>>
> >>> Encryption over bluetooth is a matter to worry about, and we will
> >>> introduce that, but we need to sort out more low level problems first
> >>> before coming into that stage.
> >>>
> >>>
> >>> So, the backwards compatibility is a good issue Michael pointed out.
> >>> While processing of multiple "r" parameters is indeed uncertain (since
> >>> there is no RFC for that various implementations may behave
> >>> differently), the array solution is somewhat better. The array
> parameter
> >>> name is "r%5B1%5D=", i.e. it's not "r=", and we can add plain "r="
> >>> alongside. And if particular implementation understands the array
> >>> construct - it will use it, otherwise it will ignore the "r%5B1%5D="
> and
> >>> use only usual "r=".
> >>>
> >>> This doens't work though for cases where particular implementation
> >>> understands array construct but doesn't work well with repeating
> >>> parameters, since it will see two repeating "r" - an array and a
> string.
> >>> I don't have a solution for that atm.
> >>>
> >>>
> >>> If add completely new parameter to solve this we will need to make it
> an
> >>> array straight away to address upcoming issues with accommodating other
> >>> protocols.
> >>> And then I would also modify existing BIP72 to strictly define "r=" as
> >>> "http(s)" only parameter, while all other protocols (bluetooth, WiFi
> >>> Direct, ultrasound, chirp etc) should go to the new array parameter.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> ------------------------------------------------------------------------------
> >>> Open source business process management suite built on Java and Eclipse
> >>> Turn processes into business applications with Bonita BPM Community
> Edition
> >>> Quickly connect people, data, and systems into organized workflows
> >>> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> >>> http://p.sf.net/sfu/Bonitasoft
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> Bitcoin-development mailing list
> >>> Bitcoin-development at lists.sourceforge.net
> >>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >>>
> >>
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> Open source business process management suite built on Java and Eclipse
> >> Turn processes into business applications with Bonita BPM Community
> Edition
> >> Quickly connect people, data, and systems into organized workflows
> >> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> >> http://p.sf.net/sfu/Bonitasoft
> >> _______________________________________________
> >> Bitcoin-development mailing list
> >> Bitcoin-development at lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
> >
> >
> ------------------------------------------------------------------------------
> > Open source business process management suite built on Java and Eclipse
> > Turn processes into business applications with Bonita BPM Community
> Edition
> > Quickly connect people, data, and systems into organized workflows
> > Winner of BOSSIE, CODIE, OW2 and Gartner awards
> > http://p.sf.net/sfu/Bonitasoft
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
>
>
>
>
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140701/f3b7f78d/attachment.html>

2023-06-07 15:23:26

- reply

📅 Original date posted:2014-07-02
📝 Original message: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-07-01 18:59 GMT+01:00 Mike Hearn <mike at plan99.net>:
> Nope, r1/r2 sounds good to me. BTW we should update the spec to reflect
> that escaping is largely unnecessary in many cases.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140702/8da22f48/attachment.html>

2023-06-07 15:23:24

- reply

📅 Original date posted:2014-07-01
📝 Original message: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 be able to provide best
user experience.
Mike, a while ago in this thread you've described contactless cards user
experience. I'm also using contactless cards often, and what I'm aiming at
is creating same level of user experience for Bitcoin users.
Encryption over bluetooth is a matter to worry about, and we will introduce
that, but we need to sort out more low level problems first before coming
into that stage.
So, the backwards compatibility is a good issue Michael pointed out.
While processing of multiple "r" parameters is indeed uncertain (since
there is no RFC for that various implementations may behave differently),
the array solution is somewhat better. The array parameter name is "
r%5B1%5D=", i.e. it's not "r=", and we can add plain "r=" alongside. And if
particular implementation understands the array construct - it will use it,
otherwise it will ignore the "r%5B1%5D=" and use only usual "r=".
This doens't work though for cases where particular implementation
understands array construct but doesn't work well with repeating
parameters, since it will see two repeating "r" - an array and a string. I
don't have a solution for that atm.
If add completely new parameter to solve this we will need to make it an
array straight away to address upcoming issues with accommodating other
protocols.
And then I would also modify existing BIP72 to strictly define "r=" as
"http(s)" only parameter, while all other protocols (bluetooth, WiFi
Direct, ultrasound, chirp etc) should go to the new array parameter.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140701/3d587442/attachment.html>

2023-06-07 15:23:23

- reply

📅 Original date posted:2014-06-30
📝 Original message: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 client wallet supports BIP70 but doesn't not
support fetching over bluetooth or bluetooth connection fails for any
reason.
There is a way to define alternative URIs inside payment request itself,
but that doesn't really work as client first needs to get payment request
message itself somehow and this is exactly the problem.
As far as I see there is three ways to solve that:
1. add new URI parameter for bluetooth address
(e.g. r=http://<web_address>&rbt=bt:<BT_MAC_addres>).
2. allow multiple "r" parameters
(e.g. r=http://<web_address>&r=bt:<BT_MAC_addres>).
3. allow "r" to be an array
(e.g. r%5B0%5D=http://<web_address>&r%5B1%5D=bt:<BT_MAC_addres>).
Option #1 isn't great at all, as it solves existing problem, but not
provides any way to solve same problem appearing again for another possible
protocol.
Options #2 & #3 may be working and seem to be nearly equal, and both are
not great in the way that URI parser behavior in these cases is not clearly
defined. I've checked through relevant RFCs and found nothing specific
about this. According to my limited web experience the array scheme is
working better than multiple repeating parameters.
So I'm looking for some advice on which route of three proposed may be
better here, or if there are any other ways I'm missing.
2014-03-27 13:31 GMT+00:00 vv01f <vv01f at riseup.net>:
> Companies can have a Cert with their name via CAcert. It requires some
> work though to get assured as an organisation.
> Did you already think about what CA is to be trusted or do users need to
> do that. The least good decision in my POV would be to accept OS/browser
> built in CAs only.
>
> Am 27.03.2014 um 11:08 schrieb Mike Hearn <mike at plan99.net>:
>
> But these cases are the norm, rather than the exception.
>>
>
> Well, you're lucky, you live in Berlin. Most of the payments I make with
> Bitcoin are online, to websites. So this will differ between people.
>
> I wonder how critical it is. Let's say you are paying for a meal. In your
> head the place you're at is just "the little Indian restaurant on the
> corner". In the companies register and therefore certificate it's something
> like "Singh Food GmbH". That's probably good enough to prevent shenanigans.
> Even if there's a virus on your phone, it can't really replace the cert
> with a random stolen one, otherwise your meal could show up like "IronCore
> Steel Inc" or something that's obviously bogus. It'd have to be an
> incredibly smart virus that knew how to substitute one name for a different
> one, from a large library of stolen identities, such that the swap seemed
> plausible. That sounds very hard, certainly too hard to bother with for
> stealing restaurant fees.
>
> And if a waiter at the restaurant is corrupt and they replace the cert
> with one that's for their own 1-man business "BP-Gupta" or something, OK,
> you might pay the wrong person by mistake. But eventually the corrupt
> waiter will be discovered and then someone will have proof of what they
> did. It's FAR more likely they'd just strip the signature entirely and try
> to convince you the restaurant doesn't use BIP70 at all.
>
> Still, if we want to fix this, one approach I was thinking about is to
> have a super-cheesy CA just for us that issues certs with addresses in
> them, for any name you ask for. That is, if you say you want a cert for
> "Shamrock Irish Pub, Wollishofen, Zurich, CH" then it either sends a
> postcard to that address with a code to check ownership of the address, or
> it checks ownership of the place on Google Maps (which does the same
> postcard trick but for free!).
>
> That doesn't work for vending machines, but perhaps we just don't care
> about those. If a MITM steals your lunch money, boo hoo.
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140630/c57b4bfb/attachment.html>

2023-06-07 15:22:49

- reply

📅 Original date posted:2014-06-16
📝 Original message: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 <mike at plan99.net>:
> I think many of us feel it'd be better if this kind of thing were not
> needed at all, however, the best way to ensure it doesn't end up being used
> is to write code, not to try and block alternative approaches. If Bitcoin
> is robust the market should sort it out. If it's robust for some
> transactions and not others, that makes for a fun project for a future
> generation of hackers to sort out.
>
> OK, enough philosophy - let's try and keep this thread just for discussion
> of the BIP itself from now on. If you'd like to continue debating the
> Future of Bitcoin please change the subject line and break it out into a
> new thread.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140616/d67b537a/attachment.html>

2023-06-07 15:22:46

- reply

📅 Original date posted:2014-06-16
📝 Original message:Hi Lawrence/All
I'm afraid with this BIP for TTP of instant transactions we will end up in
VISA world again. As I see it - it's not about if the TTPs will centralize,
it's only when. Simply because if economy of scales makes growth profitable
and coming into this market is at least a little expensive - this
(centralization, VISA world) will happen, sooner rather than later.
And while some may argue that coming to market in Bitcoin world is cheap so
the crowd will always have a chance to come in and beat the monopolists -
think of one thing. Right now Bitcoin is not seen as money and not
regulated accordingly anywhere in the world, thanks God, but how many years
away we are from the point when it will start to be regulated that way? And
once it is - the monopolies will make sure that rules are restrictive
enough to prevent competition, especially in conjunction with economy of
scales playing against the small newcomers.
The "instant providers list" is susceptible to regulatory influence, and
once in place and widespread - it will be a timebomb under Bitcoin. We need
to solve the doublespend issue without TTP involvement, or at least without
even a slight 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 <lawrence at 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 useful:
> >
> >
> > https://bitcointalk.org/index.php?topic=423.msg3819#msg3819
> >
> >
> >
> >
> > (this is the famous "snack machine" thread from 2010)
> >
> > If they decide to change to something like highest-fee-always-wins, then
> they (again) centralise things by forcing all instant transactions to pay
> GreenAddress and its competitors money - much though I like your product
> Lawrence, let's hope they don't collectively lemming us all off a cliff by
> doing that ;)
>
>
> I assume we can't enforce to miners rules about which tx will go in and
> which won't and therefore whether this will cause more or less double
> spends.
>
>
> I mean, you can try but I would rather have to option to pick an third
> party
> instant provider explicitly than enforce bigger rules on mining which
> would
> IMHO lead to implicit centralization.
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://p.sf.net/sfu/hpccsystems
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140616/b38e4996/attachment.html>

2023-06-07 15:22:36

- reply

📅 Original date posted:2014-06-11
📝 Original message:Hi all
It took some time, but now my testnet seed is fully operational. In fact
I've dropped an earlier idea of DNS forwarding and now serving only testnet
seed, as it is more important atm than a mainnet one.
Testnet seed is available at testnet-seed.alexykot.me.
Please check and let me know if all looks fine with this seed from your
side.
Best regards,
Alex Kotenko
2014-05-22 9:58 GMT+01:00 Andreas Schildbach <andreas at schildbach.de>:
> Hi Alex,
>
> I'm not sure if you saw this message.
> Your seeds are not reachable from my ISP unfortunately.
>
> Cheers,
>
> Andreas
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140611/3c605cd3/attachment.html>

2023-06-07 15:22:09

- reply

📅 Original date posted:2014-06-01
📝 Original message:So generally it seems impossible to have both DNS seeds running on same IP
address. Too bad.
Ok, I'll switch to serving only testnet DNS on this server for now, as this
seems to be a much bigger problem than mainnet. Later I might buy second IP
to setup mainnet DNS also.
Best regards,
Alex Kotenko
2014-05-30 15:51 GMT+01:00 Robert McKay <robert at mckay.com>:
> No, I don't think so. The problem is the 'aa' flag is missing (see the
> 'flags' section in dig). Perhaps if you could suppress the authority
> records the recursor would give up and just accept the non-authorative
> 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 [9]
>>
>> and
>> dig @node.alexykot.me [10] -p 18353 testnet-seed.alexykot.me
>> [11]
>>
>> are giving different authority sections.
>>
>> Hmm, but if I setup custom SOA record for it - it should work,
>> right?
>> What SOA name should it be actually, assuming that NS record for
>> testnet-seed.alexykot.me [12] is pointing at alexykot.me [13]?
>>
>> 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 answer bit in the
>>> reply.. this causes the recursor to go into a loop chasing the
>>> authority server which again returns a non-authoritve answer with
>>> itself as the authority again. Im not sure if this can be fixed
>>> without hacking the bind src, so maybe it wasnt such a great
>>>
>>> suggestion in the first place. Basically I think if bind was
>>> returning authorative answers it would work, but I cant see any way
>>>
>>> to make that happen in the bind configuration.
>>>
>>> Rob
>>>
>>> On Fri, 30 May 2014 14:19:05 +0100, Alex Kotenko wrote:
>>>
>>> Hi Peter
>>>>
>>>> Ive setup DNS seeds myself a week ago, at
>>>> testnet-seed.alexykot.me [1] [6]
>>>> and bitcoin-seed.alexykot.me [2] [7], but there is a problem with
>>>>
>>>> DNS
>>>> settings that we with Andreas couldnt sort out quickly.
>>>>
>>>> The problem itself is that I can reach my nameserver and get
>>>> dnsseed
>>>> response if I query it directly with
>>>> dig @node.alexykot.me [3] [8] testnet-seed.alexykot.me [4] [9]
>>>>
>>>> dig @node.alexykot.me [5] [10] bitcoin-seed.alexykot.me [6]
>>>> [11]
>>>>
>>>> But when I try nslookup testnet-seed.alexykot.me [7] [12] -
>>>>
>>>> it
>>>> fails.
>>>> I guess the problem is in my DNS settings but I cant figure out
>>>> what
>>>> is it.
>>>>
>>>> S o could you share
>>>> how you configured DNS
>>>> for your seed
>>>> to help me debug
>>>> mine
>>>> ?
>>>>
>>>> Best regards,
>>>>
>>>> Alex Kotenko
>>>>
>>>>
>>>>
>>>
>>
>> Links:
>> ------
>> [1] http://testnet-seed.alexykot.me
>> [2] http://bitcoin-seed.alexykot.me
>> [3] http://node.alexykot.me
>> [4] http://testnet-seed.alexykot.me
>> [5] http://node.alexykot.me
>> [6] http://bitcoin-seed.alexykot.me
>> [7] http://testnet-seed.alexykot.me
>> [8] http://node.alexykot.me/
>> [9] http://testnet-seed.alexykot.me/
>> [10] http://node.alexykot.me/
>> [11] http://testnet-seed.alexykot.me/
>> [12] http://testnet-seed.alexykot.me
>> [13] http://alexykot.me
>> [14] mailto:robert at mckay.com
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140601/9e40b92b/attachment.html>

2023-06-07 15:22:00

- reply

📅 Original date posted:2014-05-30
📝 Original message:Hmm, you might be right, as queries
dig @node.alexykot.me testnet-seed.alexykot.me
and
dig @node.alexykot.me -p 18353 testnet-seed.alexykot.me
are giving different authority sections.
Hmm, but if I setup custom SOA record for it - it should work, right?
What SOA name should it be actually, 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 <robert at mckay.com>:
> Hi Alex,
>
> I think the problem is with my suggestion to use bind forwarding..
> basically bind is stripping off the authorative answer bit in the reply..
> this causes the recursor to go into a loop chasing the authority server
> which again returns a non-authoritve answer with itself as the authority
> again. I'm not sure if this can be fixed without hacking the bind src, so
> maybe it wasn't such a great suggestion in the first place. Basically I
> think if bind was returning authorative answers it would work, but I can't
> see any way to make that happen in the bind configuration.
>
> Rob
>
>
> On Fri, 30 May 2014 14:19:05 +0100, Alex Kotenko wrote:
>
>> Hi Peter
>>
>> Ive setup DNS seeds myself a week ago, at testnet-seed.alexykot.me [6]
>> and bitcoin-seed.alexykot.me [7], but there is a problem with DNS
>> settings that we with Andreas couldnt sort out quickly.
>>
>> The problem itself is that I can reach my nameserver and get dnsseed
>> response if I query it directly with
>> dig @node.alexykot.me [8] testnet-seed.alexykot.me [9]
>>
>> dig @node.alexykot.me [10] bitcoin-seed.alexykot.me [11]
>>
>> But when I try nslookup testnet-seed.alexykot.me [12] - it
>> fails.
>> I guess the problem is in my DNS settings but I cant figure out what
>> is it.
>>
>> S o could you share
>> how you configured DNS
>> for your seed
>> to help me debug
>> mine
>> ?
>>
>> Best regards,
>>
>> Alex Kotenko
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140530/a4fe95aa/attachment.html>

2023-06-07 15:21:59

- reply

📅 Original date posted:2014-05-30
📝 Original message:Hi Peter
I've setup DNS seeds myself a week ago, at testnet-seed.alexykot.me and
bitcoin-seed.alexykot.me, but there is a problem with DNS settings that we
with Andreas couldn't sort out quickly.
The problem itself is that I can reach my nameserver and get dnsseed
response if I query it directly with
dig @node.alexykot.me testnet-seed.alexykot.me
dig @node.alexykot.me bitcoin-seed.alexykot.me
But when I try nslookup testnet-seed.alexykot.me - it fails.
I guess the problem is in my DNS settings but I can't figure out what is it.
S
o could you share
how you configured
DNS
for your seed

to help me debug
mine
?
Best regards,
Alex Kotenko
2014-05-30 10:43 GMT+01:00 Peter Todd <pete at petertodd.org>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
>
>
> On 27 May 2014 02:19:39 GMT+03:00, Andreas Schildbach <
> andreas at schildbach.de> wrote:
> >> Hey, really sorry I don't have the time to fix this issue, been
> >> travelling for a few weeks for my consulting job. If you want to
> >> step up and volunteer please feel free.
> >
> >I'm already volunteering. At least I don't get paid for my efforts in
> >debugging the seed infrastructure.
>
> I meant running a seed yourself. Note that I've only received funds to
> cover expenses and a trivial amount on top to cover some time - about one
> and a half hours at my usual rates.
>
> Gavin: Speaking of, given it looks like my work will be frequently keeping
> me out of country and unable to provide any more than a "best effort"
> attempt at running a seed, I'd like to give back the grant funds for doing
> so. Email me privately with an address to send them too. I have no plans to
> take it down, however the expectations users have for it aren't something I
> can provide.
>
> >Can you verify if your copy of the seeder contains the commit
> >8dcc006e6256cb746c2b025daf3df41baa26353e ?
> >
> >It fixed a bug that has exactly the symptoms we currently see.
> >
> >I wonder if the restart of your server actually changed/fixed
> >anything. If you got a SERVFAIL this may be because you were traveling
> >through parts of the world that can't reach your server. Did you
> >actually try at home, before the restart?
>
> I checked via the same proxy both times; I believe the endpoint is located
> in Europe.
> -----BEGIN PGP SIGNATURE-----
> Version: APG v1.1.1
>
> iQFQBAEBCAA6BQJTiFKwMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
> cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhQFCB/4jypD+xzKVp6fqRUxu
> v22Rc6PeCbeaPYKmdNu0LbY1G5spB8C8ooaZX6z0Ib/CYobzDPJ+rJNB+c1Fna4N
> 1IdH7ZsrX0GFaEn7Grnp7D2rtOXGZV+1XGFAateIA/caQ9+rJfqkHLuvOI0Fh+Ua
> /m857rxUNtA1kObLFS7gfhi2gwXGO6KQ3muS3462hXVVc9j7DhOWQQwJba5PL+Je
> Eob4WtnF2gVFlCEWevxvflF7j4lW9I/S81yZQDnNW9ATF2mfZVqo26sB0yL6Tm4l
> KgdKx7+w3khv6QfW9Ilx0Ov3Ml2ZMRhBimpbnENbW4jfklsuRQcM0yx6vXS/lIMz
> LO5s
> =Up3N
> -----END PGP SIGNATURE-----
>
>
>
> ------------------------------------------------------------------------------
> Time is money. Stop wasting it! Get your web API in 5 minutes.
> www.restlet.com/download
> http://p.sf.net/sfu/restlet
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140530/9fe8be01/attachment.html>

2023-06-07 15:21:37

- reply

📅 Original date posted:2014-05-19
📝 Original message: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 GMT+01:00 Sergio Lerner <sergiolerner at certimix.com>:
> Alex,
>
> I think that what you are talking about more or less something like
> the Firmcoin
>
> Check: http://firmcoin.com/?p=92
>
>
>
> On 18/05/2014 08:47 a.m., Alex Kotenko wrote:
>
>
>
> One problem we couldn't figure out here though - how to protect the
> notes from unauthorized 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?
>
>
> The firmcoin has two capacitive buttons that you have to press in
> sequence to redeem to coins. No long range antenna can do that.
>
> Best regards,
> Sergio.
>
> PS: the device has patents pending
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140519/cd61a2fa/attachment.html>

2023-06-07 15:21:36

- reply

📅 Original date posted:2014-05-19
📝 Original message:Practically I would approach it from a different angle. We need to make
sure that notes we're accepting are still loaded, but assuming it's NFC
enabled this is still quite easy for the user and is an acceptable
usability drawback.
Then what we need to make sure is that when someone is 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 <natanael.l at gmail.com>:
> The problem with not involving any electronics is that somebody needs to
> generate a recoverable private key that we have to trust haven't recovered
> the private key.
>
> The only plausible solution is multisignature P2SH addresses where you
> trust several independent entities to not collude instead, where you
> combine their paper notes into one piece. And then you still don't know if
> all the private keys are recoverable to you (failed print?).
>
> - Sent from my phone
> Den 18 maj 2014 20:48 skrev "Alex Kotenko" <alexykot at gmail.com>:
>
> Erm, few things here.
>> - I can't see really how to embed electronics capable to run an SPV
>> client into printed paper. I know that passive NFC tags can be printed on
>> paper, but not actual chips and/or power modules. So we are talking about a
>> completely different things here.
>> - even with paper notes printed proprietarily by some business the notes
>> itself still can have routes for independent blockchain-based verification,
>> and you won't need to trust anybody to test it. You will have to trust
>> security of the notes itself, but this is same as when you trust the phone
>> manufacturer when 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 <natanael.l at gmail.com>:
>>
>>> Now you are talking about Trusted Platform Modules. Like smartcards,
>>> actually. Devices that won't leak their keys but let the holder spend the
>>> coins. It could even have it's own simple SPV wallet client to make it
>>> easier to handle. And they'd use the attestation features provided by the
>>> TPM to prove the software it's unmodified top the current holder.
>>>
>>> But then you still have to trust the manufacturer of the device, and you
>>> have to trust it has no exploitable side channels.
>>>
>>> - Sent from my phone
>>> Den 18 maj 2014 13:52 skrev "Alex Kotenko" <alexykot at gmail.com>:
>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140519/d1363baf/attachment.html>

2023-06-07 15:21:35

- reply

📅 Original date posted:2014-05-19
📝 Original message: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 <boydb at midnightdesign.ws>:
> >> 2014-05-18 13:14 GMT+01:00 Andreas Schildbach <andreas at schildbach.de>:
> >> One problem we couldn't figure out here though - how to protect the
> >> notes from unauthorized 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?
> >>
> >> I think you'd need multiple factors to protect against that attack. Like
> >> encrypting with a key that is printed on the note as an QR code.
> >
> >On Sun, May 18, 2014 at 7:51 AM, Alex Kotenko <alexykot at gmail.com> wrote:
> >
> > 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
>
> One thought I had reading through this exchange: I think the general
> public is becoming more aware of the "hacker with a long range
> antenna" sort of attack, since credit cards are getting microchips
> that can be scanned. There's a few videos I've seen of white hat
> hackers demonstrating how a suitcase-sized apparatus carried by
> someone walking down the street can scan and make charges on cards in
> people's pockets as the attacker brushes past. Hence RFID-blocking
> sleeves/wallets are on the market, such that your smart credit card
> can't make a purchase while its in your wallet. Is a RFID-blocking
> wallet also NFC-blocking? Irregardless of whatever "future cash" you
> choose to carry (be it credit card or bitcoin card/coin/cash), perhaps
> its the wallet/purse that needs an upgrade, to ensure your money
> doesn't spend itself while its in your pocket, but you can easily
> remove it and spend it conveniently?
>
> Brooks
>
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform
> available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140519/66c3777d/attachment.html>

2023-06-07 15:21:35

- reply

📅 Original date posted:2014-05-18
📝 Original message:Erm, few things here.
- I can't see really how to embed electronics capable to run an SPV
client into printed paper. I know that passive NFC tags can be printed on
paper, but not actual chips and/or power modules. So we are talking about a
completely different things here.
- even with paper notes printed proprietarily by some business the notes
itself still can have routes for independent blockchain-based verification,
and you won't need to trust anybody to test it. You will have to trust
security of the notes itself, but this is same as when you trust the phone
manufacturer when 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 <natanael.l at gmail.com>:
> Now you are talking about Trusted Platform Modules. Like smartcards,
> actually. Devices that won't leak their keys but let the holder spend the
> coins. It could even have it's own simple SPV wallet client to make it
> easier to handle. And they'd use the attestation features provided by the
> TPM to prove the software it's unmodified top the current holder.
>
> But then you still have to trust the manufacturer of the device, and you
> have to trust it has no exploitable side channels.
>
> - Sent from my phone
> Den 18 maj 2014 13:52 skrev "Alex Kotenko" <alexykot at gmail.com>:
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140518/5a1cb108/attachment.html>

2023-06-07 15:21:34

- reply

📅 Original date posted:2014-05-18
📝 Original message:I had a long discussion recently with somebody who wants and has resources
to do exactly this - paper currency representing bitcoins. Yet we've been
thinking mostly about a centralized solution, where one party is producing
and maintaining paper currency, with bitcoins tied to each note verifiable
via blockchain.
The points we've ended up is that it needs to be:
- reloadable
- NFC based
So anybody can verify any notes instantly by just touching it with his
phone, and so merchants could redeem the notes at the moment of accepting
it, convert it into fully online bitcoins and avoid costs of maintaining
paper money turnover. Probably merchant would sell back redeemed
empty notes to the issuer for a price of the note issue, and issuer will
recharge it and put back into circulation.
One problem we couldn't figure out here though - how to protect the notes
from unauthorized 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 <gmaxwell at gmail.com>:
> On Sat, May 17, 2014 at 9:07 AM, Chris Pacia <ctpacia at gmail.com> wrote:
> > I can't really just hand someone the note and walk away
> > because they have to scan it to see if it is actually valid.
>
> Not just scan it, but they actually must successfully sweep it—
> otherwise they can be trivially double spent. This is especially bad
> since any prior bearer can perform such an attack. E.g. record the
> private key of everyone that passes through your hands and then
> doublespend race any redemption that happens >24 hours after you spend
> them. The wrong person would likely be blamed and even if you were
> blamed you could plausibly deny it ("Must have been the guy that gave
> it to me!").
>
> Othercoin seems to have much better properties in the space of offline
> transactions: https://bitcointalk.org/index.php?topic=319146.0
>
> Separately, Cassius also ran into some regulatory issues selling
> physical bitcoin artifacts. Especially printing things that seem to be
> redeemable for a named USD value sounds especially problematic.
>
> Some random comments— The base58 encoding is fairly human unfriendly.
> It's fine for something being copy and pasted, but I've found typing
> or reading it works poorly due to mixed case. I expect the A/B side
> to be difficult to educate users about. "This side is private" is more
> easily understood, you could just pick one of your sides and call it
> private. I find it kind of odd that this design seems to have no
> facility for checking its txouts without recovering the private key,
> though considering no one should rely on such a measurement without
> sweeping perhaps thats for the best.
>
> (As far as the numbering goes, I think you should be calling these
> draft-felix-paper-currency etc. As a matter of hygienic practice I
> will not assign a matching bip number for something that went public
> with a number outside of the assignment.)
>
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform
> available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140518/ec456939/attachment.html>

2023-06-07 15:21:34

- reply

📅 Original date posted:2014-05-18
📝 Original message: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 Schildbach <andreas at schildbach.de>:
> > One problem we couldn't figure out here though - how to protect the
> > notes from unauthorized 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?
>
> I think you'd need multiple factors to protect against that attack. Like
> encrypting with a key that is printed on the note as an QR code.
>
>
>
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform
> available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140518/a79df162/attachment.html>

2023-06-07 15:21:31

- reply

📅 Original date posted:2014-05-19
📝 Original message:Well, it's possible theoretically, but will need another piece of custom
software that will understand DNS protocol and proxy it correctly based on
actual incoming DNS queries.
On 19 May 2014 21:22, "Michael Wozniak" <mw at osfda.org> wrote:
> I’m not familiar with how the daemon works, however could you set up two
> daemons listening local on different ports and with a separate daemon or
> normal dns server that proxies incoming queries to either domain? I don’t
> know if standard DNS servers would support that, or if you would need a
> custom proxy application.
>
> -
> Michael Wozniak
>
>
> On May 19, 2014, at 4:14 PM, Alex Kotenko <alexykot at 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 seeds off one daemon instance which
> means I 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:39 GMT+01:00 Andreas Schildbach <andreas at schildbach.de>:
> > On 05/17/2014 02:02 PM, Alex Kotenko wrote:
> >
> > > So, my understanding is that atm we have no working DNS seeds at the
> > > testnet3, right? There are two DNS seeds known, of which one is
> > > unreachable atm, and another one is giving just one IP address, which
> is
> > > also a dead node.
> >
> > Yes, that's my understanding too.
> >
> > > If I'll start a DNS seed of my own and make sure it works well, will
> > > this help?
> >
> > Yes, definately.
> >
> > > I've found this DNS seeder daemon
> > > <https://github.com/sipa/bitcoin-seeder>, and it seems to be exactly
> > > what I need to run a DNS seeder myself.
> >
> > Afaik this is what most of the other seeds are using, yes.
> >
> > > So if my understanding is correct, I'll setup a DNS seeds for mainnet
> > > and for testnet at bitcoin-seed.alexykot.me
> > > <http://bitcoin-seed.alexykot.me> and testnet-seed.alexykot.me
> > > <http://testnet-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?
> >
> > Sound great! Let me know if you've got something to test.
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> > Instantly run your Selenium tests across 300+ browser/OS combos.
> > Get unparalleled scalability from the best Selenium testing platform
> available
> > Simple to use. Nothing to install. Get started now for free."
> > http://p.sf.net/sfu/SauceLabs
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
> >
> ------------------------------------------------------------------------------
> > "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> > Instantly run your Selenium tests across 300+ browser/OS combos.
> > Get unparalleled scalability from the best Selenium testing platform
> available
> > Simple to use. Nothing to install. Get started now for free."
> >
> http://p.sf.net/sfu/SauceLabs_______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140519/cc158b63/attachment.html>

2023-06-07 15:21:28

- reply

📅 Original date posted:2014-05-21
📝 Original message: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 <andreas at schildbach.de>:
> Great, thanks for this contribution!
>
> Do you plan to have your seeds reachable on port 53 eventually?
> Currently bitcoinj cannot deal with nonstandard ports I think.
>
>
> On 05/21/2014 11:23 AM, Alex Kotenko wrote:
> > okay, I've set it up with bind forwarding requests to two dnsseeds
> > running on separate ports. Though I see a problem with testnet DNS seed
> > itself. It runs, but somehow it only returns one IP address. Exactly
> > same DNS seeder looking for mainnet nodes is working fine.
> >
> > You can reach seeds through
> > mainnet seed:
> > dig @node.alexykot.me <http://node.alexykot.me> bitcoin-seed.alexykot.me
> > <http://bitcoin-seed.alexykot.me> A
> > or directly
> > dig -p 8353 @node.alexykot.me <http://node.alexykot.me>
> > bitcoin-seed.alexykot.me <http://bitcoin-seed.alexykot.me> A
> >
> > testnet seed
> > dig @node.alexykot.me <http://node.alexykot.me> testnet-seed.alexykot.me
> > <http://testnet-seed.alexykot.me> A
> > or directly
> > dig -p 18353 @node.alexykot.me <http://node.alexykot.me>
> > testnet-seed.alexykot.me <http://testnet-seed.alexykot.me> A
> >
> > So what can be the problem with testnet DNS seeder?
> >
> >
> > Best regards,
> > Alex Kotenko
> >
> >
> > 2014-05-20 1:50 GMT+01:00 Robert McKay <robert at mckay.com
> > <mailto:robert at 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 <robert at mckay.com
> > <mailto:robert at mckay.com>>
> > >> wrote:
> > >>> It should be possible to configure bind as a DNS forwarder.. this
> > >>> can
> > >>> be done in a zone context.. then you can forward the different
> > >>> zones
> > >>> to
> > >>> different dnsseed daemons running on different non-public IPs or
> > >>> two
> > >>> different ports on the same IP (or on one single non-public IP
> > >>> since
> > >>> there's really no reason to expose the dnsseed directly daemon at
> > >>> all).
> > >>
> > >> Quite the opposite. dnsseed data rotates through a lot of
> addresses
> > >> if available. Using the bind/zone-xfer system would result in
> fewer
> > >> total addresses going through to the clients, thanks to the
> addition
> > >> of caching levels that the bind/zone-xfer system brings.
> > >>
> > >> That said, if the choice is between no-service and bind, bind it
> is
> > >> ;p
> > >
> > > Setting it up as a zone forwarder causes each request to go through
> > > to
> > > the dnsseed backend for each request.
> >
> > This stackoverflow describes a similar situation;
> >
> > http://stackoverflow.com/questions/15338232/how-to-forward-a-subzone
> >
> > you can additionally specify the port to forward too;
> >
> > http://www.zytrax.com/books/dns/ch7/queries.html#forwarders
> >
> > it should be possible to forward to different ports on 127.0.0.1 for
> > each dnsseed instance.
> >
> > Rob
> >
> >
> ------------------------------------------------------------------------------
> > "Accelerate Dev Cycles with Automated Cross-Browser Testing - For
> FREE
> > Instantly run your Selenium tests across 300+ browser/OS combos.
> > Get unparalleled scalability from the best Selenium testing platform
> > available
> > Simple to use. Nothing to install. Get started now for free."
> > http://p.sf.net/sfu/SauceLabs
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > <mailto:Bitcoin-development at lists.sourceforge.net>
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> > Instantly run your Selenium tests across 300+ browser/OS combos.
> > Get unparalleled scalability from the best Selenium testing platform
> available
> > Simple to use. Nothing to install. Get started now for free."
> > http://p.sf.net/sfu/SauceLabs
> >
> >
> >
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
>
>
>
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform
> available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140521/aae8a29d/attachment.html>

2023-06-07 15:21:27

- reply

📅 Original date posted:2014-05-21
📝 Original message:okay, I've set it up with bind forwarding requests to two dnsseeds running
on separate ports. Though I see a problem with testnet DNS seed itself. It
runs, but somehow it only returns one IP address. Exactly same DNS seeder
looking for mainnet nodes is working fine.
You can reach seeds through
mainnet seed:
dig @node.alexykot.me bitcoin-seed.alexykot.me A
or directly
dig -p 8353 @node.alexykot.me bitcoin-seed.alexykot.me A
testnet seed
dig @node.alexykot.me testnet-seed.alexykot.me A
or directly
dig -p 18353 @node.alexykot.me testnet-seed.alexykot.me A
So what can be the problem with testnet DNS seeder?
Best regards,
Alex Kotenko
2014-05-20 1:50 GMT+01:00 Robert McKay <robert at 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 <robert at mckay.com>
> >> wrote:
> >>> It should be possible to configure bind as a DNS forwarder.. this
> >>> can
> >>> be done in a zone context.. then you can forward the different
> >>> zones
> >>> to
> >>> different dnsseed daemons running on different non-public IPs or
> >>> two
> >>> different ports on the same IP (or on one single non-public IP
> >>> since
> >>> there's really no reason to expose the dnsseed directly daemon at
> >>> all).
> >>
> >> Quite the opposite. dnsseed data rotates through a lot of addresses
> >> if available. Using the bind/zone-xfer system would result in fewer
> >> total addresses going through to the clients, thanks to the addition
> >> of caching levels that the bind/zone-xfer system brings.
> >>
> >> That said, if the choice is between no-service and bind, bind it is
> >> ;p
> >
> > Setting it up as a zone forwarder causes each request to go through
> > to
> > the dnsseed backend for each request.
>
> This stackoverflow describes a similar situation;
>
> http://stackoverflow.com/questions/15338232/how-to-forward-a-subzone
>
> you can additionally specify the port to forward too;
>
> http://www.zytrax.com/books/dns/ch7/queries.html#forwarders
>
> it should be possible to forward to different ports on 127.0.0.1 for
> each dnsseed instance.
>
> Rob
>
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform
> available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140521/e7433ef3/attachment.html>

2023-06-07 15:21:25

- reply

📅 Original date posted:2014-05-19
📝 Original message: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 seeds off one daemon instance which
means I 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:39 GMT+01:00 Andreas Schildbach <andreas at schildbach.de>:
> On 05/17/2014 02:02 PM, Alex Kotenko wrote:
>
> > So, my understanding is that atm we have no working DNS seeds at the
> > testnet3, right? There are two DNS seeds known, of which one is
> > unreachable atm, and another one is giving just one IP address, which is
> > also a dead node.
>
> Yes, that's my understanding too.
>
> > If I'll start a DNS seed of my own and make sure it works well, will
> > this help?
>
> Yes, definately.
>
> > I've found this DNS seeder daemon
> > <https://github.com/sipa/bitcoin-seeder>, and it seems to be exactly
> > what I need to run a DNS seeder myself.
>
> Afaik this is what most of the other seeds are using, yes.
>
> > So if my understanding is correct, I'll setup a DNS seeds for mainnet
> > and for testnet at bitcoin-seed.alexykot.me
> > <http://bitcoin-seed.alexykot.me> and testnet-seed.alexykot.me
> > <http://testnet-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?
>
> Sound great! Let me know if you've got something to test.
>
>
>
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform
> available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140519/5e7b4deb/attachment.html>

2023-06-07 15:21:25

- reply

📅 Original date posted:2014-05-17
📝 Original message:Agree.
So, my understanding is that atm we have no working DNS seeds at the
testnet3, right? There are two DNS seeds known, of which one is unreachable
atm, and another one is giving just one IP address, which is also a dead
node.
If I'll start a DNS seed of my own and make sure it works well, will this
help?
I've found this DNS seeder daemon <https://github.com/sipa/bitcoin-seeder>,
and it seems to be exactly what I need to run a DNS seeder myself.
So if my understanding is correct, I'll setup a DNS seeds for mainnet and
for testnet at bitcoin-seed.alexykot.me and testnet-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 <andreas at schildbach.de>:
> I think the best way to contribute to the infrastructure is actually
> what we're doing: Test the current infrastructure and point out where it
> is not working. Trying to find solutions for problems.
>
> There is nothing gained by throwing additional hardware at a problem if
> the problem itself isn't understood well.
>
>
> On 05/17/2014 02:58 AM, Alex Kotenko wrote:
> > 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 <jgarzik at bitpay.com
> > <mailto:jgarzik at bitpay.com>>:
> >
> > There are only two testnet seeds listed in bitcoind, and one of them
> > returns SERVFAIL (testnet-seed.bitcoin.petertodd.org
> > <http://testnet-seed.bitcoin.petertodd.org>) and the other
> > just returns one A record (testnet-seed.bluematt.me
> > <http://testnet-seed.bluematt.me>). No idea what
> > seeds bitcoinj uses.
> >
> > If you are going to depend on testnet, especially for an important
> > demo... contribute to the infrastructure! This stuff doesn't just
> fix
> > itself for free.
>
>
>
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform
> available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140517/381d1eda/attachment.html>

2023-06-07 15:21:24

- reply

📅 Original date posted:2014-05-16
📝 Original message: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 <jgarzik at 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 returns one A record (testnet-seed.bluematt.me). No idea what
> seeds bitcoinj uses.
>
> If you are going to depend on testnet, especially for an important
> demo... contribute to the infrastructure! This stuff doesn't just fix
> itself for free.
>
>
>
>
> On Fri, May 16, 2014 at 7:07 PM, Alex Kotenko <alexykot at gmail.com> wrote:
> > Hi guys
> >
> >
> > Just wanted to let you know that Andreas' testnet Bitcoin Wallet doesn't
> > work because of fail in the peer discovery, and this caused us problems
> as
> > we cannot properly demonstrate my XBTerminal POS on the Bitcoin
> Conference.
> >
> > Right now I'm booting up an own full node that I will set as trusted
> peer in
> > the Wallet settings, hopefully this will work. However this DNS discovery
> > problem is really a problem, even for testnet. Btw, I had problems
> firing up
> > the full bitcoind node also, of the same reason - discovery failed. I
> had to
> > ask Andreas to paste me his node list to manually 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 <laszlo at heliacal.net>:
> >
> >> It looks like it might be firewalled, probably just need to fix the ACL
> in
> >> EC2.
> >>
> >> -Laszlo
> >>
> >> On May 16, 2014, at 4:34 PM, Andreas Schildbach <andreas at schildbach.de>
> >> wrote:
> >>
> >> > Apparently British Telecom also cannot speak to Peter Todd's server.
> >> >
> >> > That another very large ISP in Europe.
> >> >
> >> >
> >> > On 05/15/2014 01:50 PM, Andreas Schildbach wrote:
> >> >> I'm bringing this issue up again. The current Bitcoin DNS seed
> >> >> infrastructure is unstable. I assume this is because of we're using a
> >> >> custom DNS implementation which is not 100% compatible. There have
> been
> >> >> bugs in the past, like a case sensitive match for the domain name.
> >> >>
> >> >> Current state (seeds taken from bitcoinj):
> >> >>
> >> >> mainnet:
> >> >>
> >> >> seed.bitcoin.sipa.be OK
> >> >> dnsseed.bluematt.me OK
> >> >> dnsseed.bitcoin.dashjr.org SERVFAIL, tried multiple ISPs
> >> >> seed.bitcoinstats.com OK
> >> >>
> >> >> testnet:
> >> >>
> >> >> testnet-seed.bitcoin.petertodd.org SERVFAIL, just from Telefonica
> >> >> testnet-seed.bluematt.me OK (but only returns one node)
> >> >>
> >> >> Note: Telefonica is one of Europe's largest ISPs.
> >> >>
> >> >> I would try to improve DNS myself, but I'm not capable of writing C.
> My
> >> >> "fix" would be to reimplement everything in Java -- I doubt you guys
> >> >> would be happy with that.
> >> >>
> >> >>
> >> >>
> >> >>
> ------------------------------------------------------------------------------
> >> >> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For
> FREE
> >> >> Instantly run your Selenium tests across 300+ browser/OS combos.
> >> >> Get unparalleled scalability from the best Selenium testing platform
> >> >> available
> >> >> Simple to use. Nothing to install. Get started now for free."
> >> >> http://p.sf.net/sfu/SauceLabs
> >> >>
> >> >
> >> >
> >> >
> >> >
> >> >
> ------------------------------------------------------------------------------
> >> > "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> >> > Instantly run your Selenium tests across 300+ browser/OS combos.
> >> > Get unparalleled scalability from the best Selenium testing platform
> >> > available
> >> > Simple to use. Nothing to install. Get started now for free."
> >> > http://p.sf.net/sfu/SauceLabs
> >> > _______________________________________________
> >> > Bitcoin-development mailing list
> >> > Bitcoin-development at lists.sourceforge.net
> >> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >>
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> >> Instantly run your Selenium tests across 300+ browser/OS combos.
> >> Get unparalleled scalability from the best Selenium testing platform
> >> available
> >> Simple to use. Nothing to install. Get started now for free."
> >> http://p.sf.net/sfu/SauceLabs
> >> _______________________________________________
> >> Bitcoin-development mailing list
> >> Bitcoin-development at lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> > Instantly run your Selenium tests across 300+ browser/OS combos.
> > Get unparalleled scalability from the best Selenium testing platform
> > available
> > Simple to use. Nothing to install. Get started now for free."
> > http://p.sf.net/sfu/SauceLabs
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
>
>
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc. https://bitpay.com/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140517/4b719244/attachment.html>

2023-06-07 15:21:23

- reply

📅 Original date posted:2014-05-16
📝 Original message:Hi guys
Just wanted to let you know that Andreas' testnet Bitcoin Wallet doesn't
work because of fail in the peer discovery, and this caused us problems as
we cannot properly demonstrate my XBTerminal POS on the Bitcoin Conference.
Right now I'm booting up an own full node that I will set as trusted peer
in the Wallet settings, hopefully this will work. However this DNS
discovery problem is really a problem, even for testnet. Btw, I had
problems firing up the full bitcoind node also, of the same reason -
discovery failed. I had to ask Andreas to paste me his node list to
manually 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 <laszlo at heliacal.net>:
> It looks like it might be firewalled, probably just need to fix the ACL in
> EC2.
>
> -Laszlo
>
> On May 16, 2014, at 4:34 PM, Andreas Schildbach <andreas at schildbach.de>
> wrote:
>
> > Apparently British Telecom also cannot speak to Peter Todd's server.
> >
> > That another very large ISP in Europe.
> >
> >
> > On 05/15/2014 01:50 PM, Andreas Schildbach wrote:
> >> I'm bringing this issue up again. The current Bitcoin DNS seed
> >> infrastructure is unstable. I assume this is because of we're using a
> >> custom DNS implementation which is not 100% compatible. There have been
> >> bugs in the past, like a case sensitive match for the domain name.
> >>
> >> Current state (seeds taken from bitcoinj):
> >>
> >> mainnet:
> >>
> >> seed.bitcoin.sipa.be OK
> >> dnsseed.bluematt.me OK
> >> dnsseed.bitcoin.dashjr.org SERVFAIL, tried multiple ISPs
> >> seed.bitcoinstats.com OK
> >>
> >> testnet:
> >>
> >> testnet-seed.bitcoin.petertodd.org SERVFAIL, just from Telefonica
> >> testnet-seed.bluematt.me OK (but only returns one node)
> >>
> >> Note: Telefonica is one of Europe's largest ISPs.
> >>
> >> I would try to improve DNS myself, but I'm not capable of writing C. My
> >> "fix" would be to reimplement everything in Java -- I doubt you guys
> >> would be happy with that.
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> >> Instantly run your Selenium tests across 300+ browser/OS combos.
> >> Get unparalleled scalability from the best Selenium testing platform
> available
> >> Simple to use. Nothing to install. Get started now for free."
> >> http://p.sf.net/sfu/SauceLabs
> >>
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> > Instantly run your Selenium tests across 300+ browser/OS combos.
> > Get unparalleled scalability from the best Selenium testing platform
> available
> > Simple to use. Nothing to install. Get started now for free."
> > http://p.sf.net/sfu/SauceLabs
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform
> available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140516/2f902475/attachment.html>

2023-06-07 15:14:57

- reply

📅 Original date posted:2014-03-10
📝 Original message: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
devices.
So it's not an NFC or POS limit, but a business decision for these small
merchants. Bitcoin can address this issue for sure, but this doesn't
concern NFC.

2014-03-10 16:14 GMT+00:00 Jean-Paul Kogelman <jeanpaulkogelman at me.com>:
>
> Just to add some more numbers, in Canada, the maximum is $50 and I've used
> it for transactions of $5, even less.
>
> I use it every day to pay for breakfast and it works through my wallet,
> even with multiple NFC enabled cards in there (though not overlapping). The
> experience is quite smooth; simply tap my wallet on the POS and a few
> seconds later it's approved.
>
> jp
>
> On Mar 10, 2014, at 9:04 AM, Mike Hearn <mike at plan99.net> wrote:
>
> I just did my first contactless nfc payment with a MasterCard. It worked
>> very well and was quite delightful - definitely want to be doing more of
>> these in future.
>>
>
> A bit more competitive intelligence - turns out that the experience isn't
> quite so good after all. After trying a few more times to use contactless
> payments, I found it has a ~75% failure rate based on my usage.
>
> By far the biggest problem is also the most predictable - it's very common
> here for merchants to require minimum payment sizes before they'll accept
> credit cards, often quite high, like 20 CHF or more. But the PIN-less mode
> only works for payments below a certain threshold, I haven't quite figured
> out what it is yet, but in the UK it's 20 GBP so maybe it's about 30 CHF.
> So there turns out to be an incredibly thin price range in which the simple
> touch-to-pay system actually works. Most of the time, either they:
>
> a) Reject cards entirely because the payment is too small
> b) Don't have the right hardware, or the hardware just mysteriously fails
> to work.
> c) Require a PIN because the payment is too large
>
> I'm sure Bitcoin can do better than this.
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140310/049dfc3a/attachment.html>

2023-06-07 15:14:56

- reply

📅 Original date posted:2014-03-10
📝 Original message: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 <andreas at schildbach.de>:
> On 03/10/2014 04:09 PM, Alex Kotenko wrote:
>
> > Yes, I'm certain about that we need to switch to BIP70 asap. As I said
> > earlier - support among the wallets is the biggest problem here really.
> > Only Andreas' Wallet supports it right now AFAIK, and even in there it's
> > only as "LABS feature", so will be turned off for most of users.
>
> Just a small clarification here. Bitcoin Wallet supports the customer
> side of the protocol since 2011, without any "Labs enabling"! This means
> you've got an install base of half a million devices that you can
> interoperate with. Sure, a lot of users will have Bluetooth switched
> off. The UI flow to enable it while paying is pretty smooth though.
>
> The merchant side used to have the Labs enabling but this is gone since
> a few weeks.
>
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140310/9051f674/attachment.html>

2023-06-07 15:14:55

- reply

📅 Original date posted:2014-03-10
📝 Original message:2014-03-08 8:52 GMT+00:00 Jan Vornberger <jan at uos.de>:

> 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, thanks for sharing! Are the two devices on the same
> wifi network in the demo? In my experience transaction propagation
> through the Bitcoin network takes a couple of seconds longer on average,
> so I'm surprised it's that fast here.
>
No, devices on this video are not on the same network, and even if they
would - I cannot control what remote hosts my phone would connect to, so
transaction may anyway travel around the globe before coming to the POS
even if they would be on one LAN.
As for transaction times - I'd say it varies. From my extensive testing
most of transactions usually come through within 2-5 seconds, but roughly
one in ten transactions may take more time, sometimes much more time.
You probably share this view, but I just wanted to repeat, that from my
> experiments, I think that sending the transaction only over the Bitcoin
> network should be a rarely-used fallback. It usually takes a little
> longer than you would like for a POS solution and every so often you
> don't get the transaction at all until the next block. And then what do
> you do? Maybe you would need to ask the customer to pay again, to get
> things done now, and put the previous transaction in some kind of refund
> mode, where - when you finally get it - you send it back somewhere. But
> it's really a problematic corner case - but yet it will happen
> occasionally with network-only propagation.
>
Yes, I'm certain about that we need to switch to BIP70 asap. As I said
earlier - support among the wallets is the biggest problem here really.
Only Andreas' Wallet supports it right now AFAIK, and even in there it's
only as "LABS feature", so will be turned off for most of users.
In the context of this discussion, I would also like to share a video of
> a prototype system:
>
> https://www.youtube.com/watch?v=mguRpvf3aMc
>
> Here shown is the (currently no longer working) Bridgewalker client, but
> it is also fully compatible with Andreas' wallet. The client picks up
> the payment details via NFC (as a Bitcoin URI - could and should be
> updated to use payment protocol) and transmits a copy of the transaction
> via Bluetooth (using the simple convention first implemented by
> Andreas). One optimization I did in the Bridgewalker client is, that it
> already opens the Bluetooth connection when presenting the user with the
> confirmation dialog. This results in a little additional speed-up, as
> the connection is already "warmed up", when the user confirms. All code
> of this prototype is open source, as is the Bridgewalker client.
>
Yes, I've seen this demonstration, I think it was on reddit about two
month ago. Looks interesting, but by that time most of my client software
was already done, so I couldn't really use this.
> >From my testing, I can say that NFC for getting the payment details +
> Bluetooth for transmitting the transaction back works well. I'm a bit
> skeptical about using NFC also for the back-channel, but maybe for cases
> where there is no additional user confirmation it could work.
NFC
as
back channel
definitely
will not work
. Mike proposed something like a threshold to define minimal amount
available for spending without confirmation, but I don't see this thing
becoming widely used any time soon, and before that we will need to have
"confirm" button tap.
One problem with Bluetooth I see is, that it seems to be mostly turned
> off by users and many seem to perceive it as "insecure", to have it
> active, as a result of earlier Bluetooth hacks. So I'm not sure if that
> will turn out to be a problem for usability when rolled-out in practice.
>
Yes, this is a problem, I think bluetooth is offline on many devices, and
keeping it on all the time will harm security (if not real security, then
at least perceived by users) and also harm battery life, which will be seen
as huge problem by the users.
Would be great to be able to control BT state automatically from within
the wallet app with user permission given once on installation time, but
not sure if it's possible in Android.
>
> ------------------------------------------------------------------------------
> Subversion Kills Productivity. Get off Subversion & Make the Move to
> Perforce.
> With Perforce, you get hassle-free workflows. Merge that actually works.
> Faster operations. Version large binaries. Built-in WAN optimization and
> the
> freedom to use Git, Perforce or both. Make the move to Perforce.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140310/3d2ced81/attachment.html>

2023-06-07 15:14:55

- reply

📅 Original date posted:2014-03-06
📝 Original message:2014-03-06 17:03 GMT+00:00 Mike Hearn <mike at plan99.net>:
> 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 survive everyday intense use and
drops on the floor also.
- cheaper than phone/tablet. Usual phone/tablet costs few hundred bucks,
our device on mass scale will be definitely cheaper than that. Maybe a
noname chinese tablet will match on price, but then again what about
reliability?
- simpler than phone/tablet. Phone app needs some basic understanding to
operate. Cheap cashier employees hired by small corner shops might find
this a challenge.
- safer than phone/tablet. No option to install random apps on it. And no
temptation to steal it from the counter.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140306/c800007f/attachment.html>

2023-06-07 15:14:54

- reply

📅 Original date posted:2014-03-06
📝 Original message:2014-03-06 16:46 GMT+00:00 Andreas Schildbach <andreas at schildbach.de>:
> 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 make sure we support
all major wallets. And no other wallets actually support NFC by now, not
talking about bluetooth. So I imagine we will decide and implement together
some solution here, both on the wallet and POS sides, but I will have to
keep URI method and even QR codes for backwards compatibility, and wait for
other main wallets to accept innovations before we will be able to
completely switch to it.
As I said earlier - bluetooth support for my POS is not a problem, we can
plug it in easily and make it work. Support among all hardware/software and
polished user experience - this is a main thing here really.
I wonder about the receipt step -- are you generating a PDF on device
> and sending it via NFC? This is something that could be supported by the
> BIP70 payment protocol. We should try to avoid the second tap, its not
> intuitive.
>
No, I'm generating it on server and sending only URL via NFC. I think this
area will change before we launch in production. Ideally I want the device
to be completely autonomous, controlled on site by the merchant, probably
with an app on his phone. But right now we have a backend server that gives
merchant a dashboard with device configuration control, transactions
history, daily reconciliation data and copies of receipts. So the PDF is
sent from that server.
We should avoid second tap ideally, but we need to make sure receipts and
payment proofs are usable and understandable for both payers and payees.
Right now a paperless PDF-only process is already a huge leap ahead
comparing to numerous paper receipts printed for each transaction by
existing POS systems.
Implementing proof of payment based on BIP70 payment request+transaction in
the blockchain+memo will require even bigger shift in the merchant's view
on how business runs. Also it will need additional software on his side to
actually be able to view and confirm these proofs of payment. In theory -
yes, BIP70 will create a way to implement proof of payment. In practice in
real life right now I don't see it viable, it will take time to adopt and
few intermediary steps like PDF based paperless process I've implemented.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140306/a287f682/attachment.html>

2023-06-07 15:14:53

- reply

📅 Original date posted:2014-03-06
📝 Original message: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 connection. Far not ideal, but even this is supported only by
Andreas' Wallet, so we cannot move ahead alot really until other wallets
will have some support in this area.
As you see - it's taking just few seconds, most of which is manual payment
confirmation. Btw, ignore my first screen tap, where I'm selecting wallets
- it's an unlikely thing to happen IRL to have several wallets installed at
the same time.
Also, I think many people may not know about Oyster cards, so this might
need little bit of explanation. And btw, have you been to London lately?
Oyster readers now accept contactless cards directly along with Oyster
cards itself. I wonder if eventually in future we could add bitcoin support
into that system directly, without hardware replacements.
I cannot put much into the actual protocol discussion, but I'm happy to
provide feedback on the side of actual POS implementation needed and
testbase if required.
Have an idea - it's a good thing to cap confirmationless payments, but the
actual cap value definition can be tricky considering Bitcoin volatility.
Inless you want to tie it to some external price definition thirdparty
service it could be tied to transaction fees. I mean - if with Bitcoin v0.9
transaction fees will become really floating, and it should eventually
reach equilibrium that will reflect some real world value. Probably a tiny
value, but probably also rather stable value. So confirmationless payment
cap may be defined as <current_average_transaction_fee>x10000.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140306/38cc0863/attachment.html>

2023-06-07 15:14:28

- reply

📅 Original date posted:2014-03-21
📝 Original message:2014-03-21 14:51 GMT+00:00 Andreas Schildbach <andreas at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140321/7b851dbb/attachment.html>

2023-06-07 15:14:28

- reply

📅 Original date posted:2014-03-21
📝 Original message:2014-03-21 9:47 GMT+00:00 Andreas Schildbach <andreas at 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 address, and payment request ID can be
> > considered as request path. Probably "bt:<bt-mac>/
> > <random_id_of_payment_request>" would be more usual and easily
> > understandable.
>
> Agreed. I used the dash because I feared a slash would need to be
> escaped if used in an URL parameter.
>
It will need to be escaped, but HTTP URLs used in BIP72 have it already,
so don't see why we should bother.
> > I wonder how complex it would be to implement HTTP-over-Bluetooth. Not
> > like I'm willing to do that now, but HTTP is well known and proven to be
> > quite good for tasks like this, so in theory it would be handy to have
> > such capacities in here.
>
> Thought of that as well. On the other hand, HTTP might be overkill and
> we inherit its potential downsides as well.
>
It definitely is an overkill. Don't think we should do it now unless we
will see later during implementation that we really have to.
> > Well, do we need to be compatible? If the dev community decides
> Base43
> > PR QR's (or whatever other self-contained format) is the way to go,
> we
> > just implement, roll it out and use it.
> >
> > My PoS needs to be compatible with BIP21, as when I'm presenting QR code
> > or sending NFC message - I have no way to tell what wallet/phone is on
> > the accepting side, so I have to be compatible to existing widely
> > supported technologies.
>
> Agreed. All I wanted to say support for QR is still small enough that we
> might be able to switch to an incompatible standard. If we're determined
> that is.
Ok. Btw, I've tested QR possibilities on my PoS screen, in binary mode
it's limited to about 600 chars, so really I can include only unsigned and
rather short payment request. Signed requests longer than few hundred bytes
will not work.
> > Well, yes, it would be less efficient than base43. But did you
> > calculate how much less? It's a compatible and already widely used way
> > and loosing compatibility needs to have serious reasons, so would be
> > great to know exact figures here.
>
> Base 64 via binary QR: 64 chars / 256 chars
> ==> 6 bit / 8 bit = 0.75
>
> Base 43 via alphanum QR: 43 chars / 45 chars
> ==> 5.43 bit / 5.49 bit = 0.99
>
> That would be efficiency in terms of PR data size vs. amount space used
> in a QR code. Of course, the visual QR encoding also plays a role, for
> example its size is increased in discrete steps.
>
Ok, so base43-aphanum is winning about a quarter of capacity against
base64-binary. I probably will skip this anyway and go with bluetooth URI
scheme we've just agreed + old style payments over p2p network as fallback.
So no payment requests in QR codes at all from my side.
>
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140321/e73d4f4a/attachment.html>

2023-06-07 15:14:27

- reply

📅 Original date posted:2014-03-20
📝 Original message:2014-03-20 8:08 GMT+00:00 Andreas Schildbach <andreas at 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 to support BIP70. And also I want to avoid
> > using external servers, the concept of my POS is that everything is
> > happening between just payer's phone and payee's POS device. This means
> > that BIP72 HTTP(S) link inside Bitcoin URI is not suitable for me.
>
> We could use Bluetooth in the "r" parameter, not unlike we use Bluetooth
> in the payment_url. However, since multiple devices could access your
> machine at the same time, we need some for of adressibility of different
> payment requests. Something like
> "bt:<btmac>-
>
> <random_id_of_payment_request>".
I guess this would be best option. I'm also worried about potential QR
code capacity, since as I imagine we can encounter device that has your
Wallet installed and bluetooth enabled, but no NFC available, so we will
have to operate via onscreen QR codes + bluetooth.
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 address, and payment request ID can be considered
as request path. Probably "bt:<bt-mac>/<random_id_of_payment_request>"
would be more usual and easily understandable.
Really I don't think my PoS will now support multiple simultaneous
payments, but it's good to have this thing in place for the time I will
need it.
I wonder how complex it would be to implement HTTP-over-Bluetooth. Not like
I'm willing to do that now, but HTTP is well known and proven to be quite
good for tasks like this, so in theory it would be handy to have such
capacities in here.
> > You're also offering an option to include Base43 encoded PR body right
> > inside the Bitcoin URI, but in a way that is not backwards compatible
> > with BIP21.
>
> Well, do we need to be compatible? If the dev community decides Base43
> PR QR's (or whatever other self-contained format) is the way to go, we
> just implement, roll it out and use it.
>
My PoS needs to be compatible with BIP21, as when I'm presenting QR code or
sending NFC message - I have no way to tell what wallet/phone is on the
accepting side, so I have to be compatible to existing widely supported
technologies.
> I understand your intention behind base43 encoding and noncompatible URI
> > - you want to make most possible use of QR codes. But I wonder - did you
> > compare this base43 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?
>
> Alphanumeric QR codes have an alphabet of 45 chars, of which I am using
> 43. I skipped Space and '%' because they're not allowed in URIs. When I
> invented the Base43 format back in 2011, wanted it to be URI compatible
> so we can use the Android intent dispatcher.
>
> If we let go of the URI requirement, we can use binary QR codes as well.
> This means users will always have to manually start their Bitcoin app
> first. (Also, there is an implementation issue with the ZXing scanner
> I'm using, it returns Strings rather than a byte array so it will choke
> on \0 characters.)
>
> > And also maybe we can extend BIP72 to include encoded payment request in
> > the URL directly in a backwards compatible way?
>
> I took this into consideration. It would be space inefficient.
>
> The Base58-encoded address from BIP21 forces the QR code into binary
> mode. Still you can't encode the payment request extension (probably an
> URL parameter) as binary because it needs to stay compatible to the URI
> standard (RFC 3986). You could use one of the Base64 variants for the PR
> in this case, but still it would be inefficient.
Well, yes, it would be less efficient than base43. But did you calculate
how much less? It's a compatible and already widely used way and loosing
compatibility needs to have serious reasons, so would be great to know
exact figures here.
I can find out base64 size, but I don't have a working base43
implementation (since the only existing is in Java, and I don't speak it).
Can you give me a sample uncompressed PR file of moderate size and a base43
encoded version of it? And I'll convert it into base64 and compare.
------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140320/748182e6/attachment.html>

2023-06-07 15:14:24

- reply

📅 Original date posted:2014-03-20
📝 Original message:We'll see how it will go, maybe I will get to implement this somewhere soon.
Yes, I'm thinking exactly about radio MitM attacks possible with bluetooth.
I'll also look into using PKI inside the PoS for the merchant. It would be
great user experience if we would be able to provide a signed payment
request with human recognizable merchant identity name in the way you
described much earlier in Bitcoin 0.9 FAQ.
2014-03-20 18:31 GMT+00:00 Mike Hearn <mike at plan99.net>:
> With Java, in theory, you can use SSLSocketFactory.createSocket(btsocket,
> address, 1234, true) to wrap a bluetooth socket in SSL. However I have not
> tried it.
>
> For now, just prototype and build your product without the security. We
> can find someone to experiment with this, if you don't want to .
>
> Bluetooth needs encryption and MACs as well as signing to be secure,
> because 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 different
> things.
>
>
> On Thu, Mar 20, 2014 at 7:20 PM, Alex Kotenko <alexykot at gmail.com> wrote:
>
>> 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 a reliable secure solution here.
>>
>>
>> 2014-03-20 10:36 GMT+00:00 Mike Hearn <mike at plan99.net>:
>>
>>> Encoding entire payment requests into qrcodes is definitely not the way
>>> to go. They can already be large when signed and we're just at the start of
>>> adding features.
>>>
>>> Finishing off and standardising the bluetooth support is the way to go
>>> (r=bt:mac). Andreas' app already has some support for this I believe, so
>>> Alex you could prototype with that, but we need to:
>>>
>>> 1) Add an encryption/auth layer on top, because it runs over RFCOMM
>>> sockets. The authentication would require proof of owning the Bitcoin key
>>> that's in the address part of the URI (which is needed for backwards compat
>>> anyway).
>>>
>>> 2) Write a BIP for it and make sure it's interoperable
>>>
>>> For the auth layer we could either use SSL and then just ignore the
>>> server certificate and require signing of the session public key with the
>>> Bitcoin key, which should be easy to code up but is rather heavy on the
>>> air, or roll a custom lightweight thing where we just do a basic ECDH, with
>>> the servers key being the same as the address key. But rolling such
>>> protocols is subtle and I guess it'd need to be reviewed by people familiar
>>> with such things.
>>>
>>> This feels like a good opportunity to grow the community - perhaps we
>>> can find a volunteer in the forums who enjoys crypto.
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Learn Graph Databases - Download FREE O'Reilly Book
>>> "Graph Databases" is the definitive new guide to graph databases and
>>> their
>>> applications. Written by three acclaimed leaders in the field,
>>> this first edition is now available. Download your free book today!
>>> http://p.sf.net/sfu/13534_NeoTech
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140320/018d3730/attachment.html>

2023-06-07 15:14:24

- reply

📅 Original date posted:2014-03-20
📝 Original message: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 a reliable secure solution here.
2014-03-20 10:36 GMT+00:00 Mike Hearn <mike at plan99.net>:
> Encoding entire payment requests into qrcodes is definitely not the way to
> go. They can already be large when signed and we're just at the start of
> adding features.
>
> Finishing off and standardising the bluetooth support is the way to go
> (r=bt:mac). Andreas' app already has some support for this I believe, so
> Alex you could prototype with that, but we need to:
>
> 1) Add an encryption/auth layer on top, because it runs over RFCOMM
> sockets. The authentication would require proof of owning the Bitcoin key
> that's in the address part of the URI (which is needed for backwards compat
> anyway).
>
> 2) Write a BIP for it and make sure it's interoperable
>
> For the auth layer we could either use SSL and then just ignore the server
> certificate and require signing of the session public key with the Bitcoin
> key, which should be easy to code up but is rather heavy on the air, or
> roll a custom lightweight thing where we just do a basic ECDH, with the
> servers key being the same as the address key. But rolling such protocols
> is subtle and I guess it'd need to be reviewed by people familiar with such
> things.
>
> This feels like a good opportunity to grow the community - perhaps we can
> find a volunteer in the forums who enjoys crypto.
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140320/83e79cbf/attachment.html>

2023-06-07 15:14:22

- reply

📅 Original date posted:2014-03-23
📝 Original message: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 buy and
install it is probably not in the same situation as the other party that
didn't care to by anything dedicated.
In short - from PoS point of view there is a customer and a merchant. And
my goal is to make thing work in assumption of fast and reliable connection
on merchant side and no connection requirement at all from customer side.
I didn't put a silly example, as of my experience there are really a lot of
places where cellphone connection isn't good enough for reliable Bitcoin
operation. However, if we're talking about merchant establishments - we can
hope for private local WiFi or wired connection on PoS side, so PoS
internet connection shouldn't be an issue. So this is the use case I'm
designing around and this is why bluetooth based BIP70 implementation is
important for me.
I partly agree with Mike on user interface and IOU idea, but I have no
intention to implement anything like that right now.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140323/de4912b2/attachment.html>

2023-06-07 15:14:20

- reply

📅 Original date posted:2014-03-21
📝 Original message:2014-03-21 10:28 GMT+00:00 Andreas Schildbach <andreas at schildbach.de>:
> 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 least here in Germany.
Yes, it is a problem. Even in the middle of London you often can get into
situation when cellphone network connectivity is not good enough for quick
and reliable payment. Basement pubs, old buildings with thick walls,
overcrowded places with overloaded radio environment. We should not rely on
mobile connectivity in things like making payments.
>
>
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140321/6bbc9e09/attachment.html>

2023-06-07 15:14:19

- reply

📅 Original date posted:2014-03-20
📝 Original message:2014-03-20 17:31 GMT+00:00 Jeff Garzik <jgarzik at bitpay.com>:
> On Thu, Mar 20, 2014 at 8:12 AM, Adam Back <adam at 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 light conditions, such as
> paying via QR code on a printed receipt in a pub at night. That was
> one of the motivations for BIP 73.
>
Hmm, in this case I think base43 discussion is irrelevant. Even with best
space utilization we can get we will not be able to fit in anything bigger
than a smallest unsigned payment certificate. And that is not so useful. So
probably we should stick with BIP73 approach and bluetooth URI scheme we're
inventing.
>
>
> On Thu, Mar 20, 2014 at 4:09 AM, Andreas Schildbach
> <andreas at schildbach.de> 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.
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc. https://bitpay.com/
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140320/f588a88a/attachment.html>

2023-06-07 15:14:17

- reply

📅 Original date posted:2014-03-20
📝 Original message:Hi Andreas
I'm implementing support for BIP70 in my POS at the moment, and I've just
realized that with options you're proposing usecase I'm looking for is not
covered.
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 to support BIP70. And also I want to avoid
using external servers, the concept of my POS is that everything is
happening between just payer's phone and payee's POS device. This means
that BIP72 HTTP(S) link inside Bitcoin URI is not suitable for me.
You're also offering an option to include Base43 encoded PR body right
inside the Bitcoin URI, but in a way that is not backwards compatible with
BIP21.
In the end this all means that there is no way for me to at the same time
keep backwards compatibility with all wallets not supporting NFC and BIP70
(all other wallets right now), and keep things inside POS without need for
external servers.
I understand your intention behind base43 encoding and noncompatible URI -
you want to make most possible use of QR codes. But I wonder - did you
compare this base43 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,
Alex Kotenko
2014-03-02 11:50 GMT+00:00 Mike Hearn <mike at plan99.net>:
> Thanks Andreas.
>
> For BIP standardisation, I think the VIEW intent seems like an obvious
> one. Bluetooth support probably should come later if/when we put
> encryption/auth on the RFCOMM link (probably SSL).
>
>
> ------------------------------------------------------------------------------
> Flow-based real-time traffic analytics software. Cisco certified tool.
> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
> Customize your own dashboards, set traffic alerts and generate reports.
> Network behavioral analysis & security monitoring. All-in-one tool.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140320/bc8cc362/attachment.html>