<unnamed>

Public Key

npub14jv7tj33yt72yk8mljmvkck3p4xm5s3mxfpj289up38qqsn9dhkqeh00t4

Profile Code

nprofile1qqs2ex09egcj9l9ztraledktvtgs6nd6gganyse9rj7qcnsqgfjkmmqpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0ds0p2mug

Publishing to

relay.snort.social

relay.damus.io

nos.lol

Last Notes

2023-06-07 17:21:25 CEST

- 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 17:14:22 CEST

- 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 17:14:20 CEST

- 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 17:14:19 CEST

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