📅 Original date posted:2015-07-18
📝 Original message:>
> Agreed, although I guess the bootstrap time for that is a little on
> the high side, and maybe a little too chunky on mobile devices
With warm Tor directory caches it's surprisingly fast - fast enough to be
usable and I'm a notorious stickler for low latency UX. If you want to do
LOTS of lookups so you can cross-check and merge their answers, that's
slower of course.
With cold Tor caches it's indeed too slow. However, reaching "tor by
default" is a part time hobby of the bitcoinj project for a while now and
there are plenty of ideas for how to make things fast enough. For instance,
using a cold cache whilst simultaneously refreshing it in the background,
doing nightly refreshes when charging, lengthening the expiry time, and the
Tor guys I believe want to implement directory differentials too which
would also help.
> My current thinking with Electrum (that ThomasV and I have bounced
> around) is to make the default policy DNSCrypt -> fallback to
> OpenAlias API pool (which can return DNSSEC data for verification) ->
> fallback to default resolver.
That seems reasonable for Electrum. I don't strongly care about these
protocols myself (and Justin knows this already), but whatever is decided
should give maximum freedom to wallet developers who disagree with you and
wish to explore other tradeoffs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150718/22387d55/attachment.html>;
Mike Hearn [ARCHIVE] /
npub17t…4qgyd
2023-06-07 15:42:16
in reply to nevent1q…shk4
Author Public Key
npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgydPublished at
2023-06-07 15:42:16Event JSON
{
"id": "4858fa0c72151baf3af33de59d29f6933629472c481add49c9e6213cde310ba1",
"pubkey": "f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2",
"created_at": 1686152536,
"kind": 1,
"tags": [
[
"e",
"2b792280c7c77e1a9146c50dbbc2a8f3336e57397d73b26f225d7fe35c48cd85",
"",
"root"
],
[
"e",
"aaf5e14b51234eab333a4caa0b83a3906d45677b4429220ee566a2b913583e8e",
"",
"reply"
],
[
"p",
"fada22460acfa5561480a4bf88a43b3c166bb0cbbda01f3099de15f2290f26fa"
]
],
"content": "📅 Original date posted:2015-07-18\n📝 Original message:\u003e\n\u003e Agreed, although I guess the bootstrap time for that is a little on\n\u003e the high side, and maybe a little too chunky on mobile devices\n\n\nWith warm Tor directory caches it's surprisingly fast - fast enough to be\nusable and I'm a notorious stickler for low latency UX. If you want to do\nLOTS of lookups so you can cross-check and merge their answers, that's\nslower of course.\n\nWith cold Tor caches it's indeed too slow. However, reaching \"tor by\ndefault\" is a part time hobby of the bitcoinj project for a while now and\nthere are plenty of ideas for how to make things fast enough. For instance,\nusing a cold cache whilst simultaneously refreshing it in the background,\ndoing nightly refreshes when charging, lengthening the expiry time, and the\nTor guys I believe want to implement directory differentials too which\nwould also help.\n\n\n\n\u003e My current thinking with Electrum (that ThomasV and I have bounced\n\u003e around) is to make the default policy DNSCrypt -\u003e fallback to\n\u003e OpenAlias API pool (which can return DNSSEC data for verification) -\u003e\n\u003e fallback to default resolver.\n\n\nThat seems reasonable for Electrum. I don't strongly care about these\nprotocols myself (and Justin knows this already), but whatever is decided\nshould give maximum freedom to wallet developers who disagree with you and\nwish to explore other tradeoffs.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150718/22387d55/attachment.html\u003e",
"sig": "1090be61295e82cafabc8a049fa3f534d9f5afb0f23694911f8fa8d28c72a3dba84570841b5d0b4f8b4b81dd5f92ff0e106f086a744bb251b895546eab3a1bc1"
}