<unnamed>

Public Key

npub14jv7tj33yt72yk8mljmvkck3p4xm5s3mxfpj289up38qqsn9dhkqeh00t4

Profile Code

nprofile1qqs2ex09egcj9l9ztraledktvtgs6nd6gganyse9rj7qcnsqgfjkmmqpz4mhxue69uhhyetvv9ujumn0wd68ytnwv46qzrthwden5te0dehhxtnvdakqz9rhwden5te0wfjkccte9ejxzmt4wvhxjmcgqs6kv

Publishing to

relay.nostr.net

nos.lol

relay.damus.io

Last Notes

2023-06-07 15:23:26 UTC

- 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:24 UTC

- 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:22:46 UTC

- 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:21:59 UTC

- 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:27 UTC

- 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 UTC

- 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 UTC

- 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 UTC

- 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 UTC

- 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:55 UTC

- 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 UTC

- 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 UTC

- 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:27 UTC

- 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 UTC

- 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 UTC

- 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 UTC

- 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 UTC

- 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 UTC

- 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 UTC

- 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>